You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: branches.qmd
+32-16Lines changed: 32 additions & 16 deletions
Original file line number
Diff line number
Diff line change
@@ -41,7 +41,7 @@ However, deletion of the branch either locally or via GitHub **must** come *afte
41
41
As you can see from the above text and the below diagram, branches have a few more moving parts than the Git and GitHub operations we've discussed so far. That said, they can be a powerful tool in service of collaborative work because you can have multiple branches active at the same all working on separate tasks. This approach can be an easy (or at least eas*ier*) workflow for working together while avoiding conflicts (again, see "Appendix A: Conflicts").
<imgsrc="images/branches/git-branch-workflow.png"alt="Graphic demonstrating the process of using brances on a Git/GitHub repository. Essentially you pull the latest changes before making a branch, then make the branch and work in it. Once you're happy with your progress, you can submit a pull request to merge your work back into the 'main' branch and then you delete your branch"width="75%"/>
45
45
</p>
46
46
47
47
Now we've gone over this big picture overview, let's walk step-by-step through creating, working in and ultimately merging branches!
@@ -53,27 +53,27 @@ Before you create a branch, **<span style="color:blue">pull</span>** from GitHub
53
53
That done, click the **<spanstyle="color:purple">purple</span>** button in the Git tab of RStudio that shows two rectangles connected by a diamond at right-angles from one another.
<imgsrc="images/branches/branches-1-new-branch-button.png"alt="Screenshot of the set of buttons in RStudio's Git pane"width="75%"/>
57
57
</p>
58
58
59
59
In the resulting dialogue box, give your new branch an informative name. In this example we haven't given our new branch a great name but in a "real" repository you will greatly appreciate having concise but descriptive branch names.
60
60
61
-
Once you're happy with the name, click **"Create"** (you can ignore the other options and buttons on this dialogue box).
61
+
Once you're happy with the name, click "**Create**" (you can ignore the other options and buttons on this dialogue box).
<imgsrc="images/branches/branches-2-name-new-branch.png"alt="Screenshot of the menu that opens when you click the purple 'create branch' button in RStudio. Includes a text field for the branch name as well as a some other checkboxes/options (that can be safely left at their default settings in many cases)"width="65%"/>
65
65
</p>
66
66
67
67
This will create a confirmation message that is superficially similar to the format of messages returned by other Git actions.
<imgsrc="images/branches/branches-2c-new-branch.png"alt="Screenshot of RStudio's Git pane where it can be seen that the branch name has changed to the new branch created earlier"width="75%"/>
77
77
</p>
78
78
79
79
## Work in the Branch
@@ -97,13 +97,17 @@ On that page GitHub will helpfully have created a button at the top of the scree
<imgsrc="images/branches/branches-6-pull-request-start.png"alt="Screenshot of a repository in GitHub where the 'compare and pull request' button is being offered because GitHub detected a push in the branch"width="100%" />
102
+
</p>
101
103
102
104
You will then be prompted to write a title and message for your pull request to give some broader context for what the branch does. This is especially valuable if you are not the one reviewing pull requests as this can help someone quickly familiarize themselves with what you have done.
103
105
104
106
Once you're satisfied with your title and message, click the <spanstyle="color:green">green</span> "Create pull request" button.
<imgsrc="images/branches/branches-7-pull-request-msg.png"alt="Screenshot of GitHub when you open a pull request and are prompted to give it a title and description"width="100%" />
110
+
</p>
107
111
108
112
That done, GitHub will send you to a page that looks very much like a Github issue (see the chapter on issues). At the top is whatever title and message you just wrote when opening the pull request following by a list of all of the commits in that branch.
109
113
@@ -115,27 +119,37 @@ You or your team can post messages on a pull request as needed (see the text box
115
119
116
120
If you are ready to merge a pull request from your branch into the "main" branch click the intuitively-named <spanstyle="color:green">green</span> "Merge pull request" button.
<imgsrc="images/branches/branches-8-active-pull-request.png"alt="Screenshot of an open pull request on GitHub"width="100%" />
124
+
</p>
119
125
120
126
GitHub will open another text box where you can add a commit message to your acceptance of the pull request. If whoever opened the pull request was sufficiently detailed in their opening comment(s) this may not need to be terribly detailed but it can't hurt!
121
127
122
128
Once your message is written, click the <spanstyle="color:green">green</span> "Confirm merge" button.
<imgsrc="images/branches/branches-9-pull-request-accept-msg.png"alt="Screenshot of the menu that opens on GitHub when you click 'merge pull request' where you are prompted to add an optional description before clicking 'confirm merge'"width="100%" />
132
+
</p>
125
133
126
134
The green 'open' buttons will change to purple and will use the "merge" icon of two streams combining. As with GitHub issues you can continue to post comments on a merged pull request if you feel it will be valuable for posterity to do so.
127
135
128
136
GitHub will also handily create a "Delete branch" button at the bottom of the pull request's timeline. We recommend that you click it given that your branch's purpose is served and having irrelevant branches clutters your GitHub and may even cause problems if you have two similarly-named branches where one has been merged and the other has not.
<imgsrc="images/branches/branches-10-successful-merge.png"alt="Screenshot of a closed pull request on GitHub with a 'delete branch' button provided"width="100%" />
140
+
</p>
131
141
132
142
After you click "Delete branch" it will be replaced by a "Restore branch" button so you could always reclaim it if need be.
<imgsrc="images/branches/branches-11-deleted-branch.png"alt="Screenshot of a pull request on GitHub after the 'delete branch' button has been clicked and replaced by a 'restore branch' button"width="100%" />
146
+
</p>
135
147
136
148
Finally, return to the "Code" tab of your GitHub repository and you can see that the changes we implemented in the branch are now part of the repository's "main" branch. The branch name is displayed just above the last commit message and the first file in the repository but below the different tab names.
<imgsrc="images/branches/branches-12-github-repo-post-merge.png"alt="Screenshot of the GitHub repository after the pull request was merged showing that the most recent commit was the merging of the PR"width="100%" />
152
+
</p>
139
153
140
154
## Update Local Repository
141
155
@@ -144,19 +158,21 @@ Now that GitHub has been told to integrate your branch content with the "main" b
144
158
First, click the name of the branch to see all the branch names in your repository and select the "main" branch to flip your local repository over to that branch.
<imgsrc="images/branches/branches-14-switch-local-to-main.png"alt="Screenshot of RStudio after the branch name was clicked (in the Git pane) showing that the new branch and the 'main' branch are options"width="75%"/>
148
162
</p>
149
163
150
164
Notice though that our script went back to the pre-merge version but don't panic!
151
165
152
166
In order to update your local version of the repository all that you need to do is click the **<spanstyle="color:blue">pull</span>** button. This brings the content you just merged via GitHub (see above) into your local repository.
<imgsrc="images/branches/branches-15-notice-outdated-script.png"alt="Screenshot of RStudio after showing the original (pre-pull request) version of the script"width="100%" />
170
+
</p>
155
171
156
172
You will get a success message indicating the changes to each file in the same way any other **<spanstyle="color:blue">pull</span>** would. You can notice between this picture and the previous that the code automatically changes when the **<spanstyle="color:blue">pull</span>** is complete.
<imgsrc="images/branches/branches-16-pull-merged-repo.png"alt="Screenshot of the message in RStudio when you pull after merging a pull request on GitHub"width="75%"/>
160
176
</p>
161
177
162
178
Now that you merged your branch with the main branch on GitHub and pulled that merged content down to your local version you have successfully start-to-finish used branches in your workflow.
<imgsrc="images/conflicts/git-conflict-workflow.png"alt="Graphic indicating the process of resolving a conflict when one occurs. After the initial conflict (caused when pushing a file from your machine differs from the GitHub version of that file), the combined file is auto-generated on your machine and you must then resolve the changes manually. These changes can then be committed and pushed up to GitHub"width="60%"/>
33
33
</p>
34
34
35
35
## How Merge Conflicts Happen
@@ -39,86 +39,98 @@ Below is a common scenario that can lead to merge conflicts and then the steps t
39
39
Let's say we have a repository that we've shared with a collaborator. Currently there's a `README.md` and only one script, `test-script.R`, in it.
<imgsrc="images/conflicts/conflicts-1-example-repo.png"alt="Screenshot of a simple GitHub repository containing only a single script and a README"width="80%"/>
43
43
</p>
44
44
45
45
`test-script.R` contains one line. Suppose we want to work on this script and add more lines to it.
<imgsrc="images/conflicts/conflicts-2-test-script.png"alt="Screenshot of a script with a single comment line"width="80%"/>
49
49
</p>
50
50
51
51
Let's go commit our edits. The green lines highlight the fact that we've added two new lines to our script, lines 2 and 3. We type out our commit message, and click **Commit**.
52
52
53
-

53
+
<palign="center">
54
+
<imgsrc="images/conflicts/conflicts-3-birds.png"alt="Screenshot of a staged file with a commit message where a vector of bird names is being added"width="100%" />
55
+
</p>
54
56
55
57
Great! The message "Your branch is ahead of 'origin/main' by 1 commit" lets us know that everything is proceeding smoothly. Suppose that we decided to take a break and stepped away from our computer.
<imgsrc="images/conflicts/conflicts-4-birds-commit.png"alt="Screenshot of RStudio after a successful commit"width="100%" />
61
+
</p>
58
62
59
63
Then, unbeknownst to us, our collaborator made their edits to the same script and committed and pushed their changes to the GitHub repository. At the moment, here is what the shared repository looks like.
<imgsrc="images/conflicts/conflicts-5-flowers.png"alt="Screenshot of the earlier GitHub repository where someone has made edits to the script"width="80%"/>
63
67
</p>
64
68
65
69
When we get back to our computer, we're ready to **<spanstyle="color:green">push</span>** our changes to GitHub, but an error shows up. Basically, it is telling us that our GitHub repository contains changes that we do not have on our local computer. To remedy this, the message suggests that we pull the changes from GitHub to our machine to catch our local machine back up.
66
70
67
-

71
+
<palign="center">
72
+
<imgsrc="images/conflicts/conflicts-6-birds-push.png"alt="Screenshot of the message you get when a push is rejected because of a conflict"width="80%" />
73
+
</p>
68
74
69
75
After clicking **<spanstyle="color:blue">Pull</span>**, we get a new error message: "Merge conflict in test-script.R".
70
76
71
-

77
+
<palign="center">
78
+
<imgsrc="images/conflicts/conflicts-7-birds-pull.png"alt="Screenshot of the message you get when you pull after getting a conflict and Git (through RStudio) warns you that it created an automatic merge"width="80%" />
79
+
</p>
72
80
73
81
Looking closer, the merge conflict prompted a new version of `test-script.R` to pop up. This version contains our edits and our collaborator's edits, along with the delimiter lines that start with `<<<<<<<`, `=======`, and `>>>>>>>`. Git is urging us to manually fix the conflicted lines before continuing.
<imgsrc="images/conflicts/conflicts-8-conflicted-lines.png"alt="Screenshot of a script where there was a conflict now having rows of symbols separating the two versions of the conflicting line"width="80%"/>
77
85
</p>
78
86
79
-
Our file now has an **[U]{style="color:orange"}** icon, which stands for an unresolved merge conflict.
87
+
Our file now has an **<spanstyle="color:orange">U</span>** icon, which stands for an unresolved merge conflict.
<imgsrc="images/conflicts/conflicts-9-unresolved.png"alt="Screenshot of Rstudio's Git pane where the script with conflict now has two orange 'U' icons (for 'unresolved')"width="80%"/>
83
91
</p>
84
92
85
93
In general terms the steps that come before a merge conflict are displayed in the visual below. Note that though this has visual similarity to the workflow diagrams throughout this bookdown we do not recommend intentionally causing a merge conflict :)
<imgsrc="images/conflicts/git-conflict-cause.png"alt="Graphic of three vertical rectangles, the left and right ones labeled 'you' and 'other' while the center has a happy cloud emoji. Both side rectangles pull a given file from Github then edit that file in different ways. The first person is able to successfully push without issue but the second person to push gets a conflict"width="60%"/>
89
97
</p>
90
98
91
99
## Resolving Merge Conflicts
92
100
93
101
So how do we resolve this merge conflict? We need to edit the script so that it looks like how we want it. We can either pick our lines to keep, our collaborator's lines, some combination, or something new altogether. Be sure to communicate with your collaborator to discuss exactly how it should be fixed. After merging the changes wherever appropriate, delete the delimiter lines.
<imgsrc="images/conflicts/conflicts-10-resolved.png"alt="Screenshot of the script where the special characters have been removed and the conflict has been resolved"width="80%"/>
97
105
</p>
98
106
99
107
Then stage, commit the changes, and push them to GitHub!
<imgsrc="images/conflicts/conflicts-11-commit-resolved.png"alt="Screenshot of RStudio where the once-conflicted script is being staged and committed with issues resolved"width="100%" />
<imgsrc="images/conflicts/conflicts-12-push-resolved.png"alt="Screenshot of the success message from RStudio when a push works as desired"width="80%"/>
107
117
</p>
108
118
109
119
Let's check back on the shared repository. The latest commit shows that we've successfully pushed our changes to GitHub.
<imgsrc="images/conflicts/conflicts-14-checking-merged.png"alt="Screenshot of the repaired file in Github showing the latest changes"width="80%"/>
117
127
</p>
118
128
119
129
Navigating to the commit history, we see that first we committed our changes, then our collaborator committed and pushed their changes, causing a merge conflict since we were editing the same lines in the same file. To resolve this, we edited those lines directly in our RStudio and committed and pushed our changes once more. Finally, the merge conflict is resolved and all the necessary changes are merged.
<imgsrc="images/conflicts/conflicts-15-commit-history.png"alt="Screenshot of the commit history of the GitHub repository showing where the conflict appears in the history"width="100%" />
0 commit comments