-
Notifications
You must be signed in to change notification settings - Fork 334
/
git-branches.Rmd
136 lines (103 loc) · 4.89 KB
/
git-branches.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
# Branches {#git-branches}
Branching means that you take a detour from the main stream of development and
do work without changing the main stream.
It allows one or many people to work in parallel without overwriting each other's work.
It allows a someone working solo to work incrementally on an experimental idea, without jeopardizing the state of the main product.
Branching in Git is very lightweight, which means creating a branch and
switching between branches is nearly instantaneous.
This means Git encourages workflows which create small branches for exploration or new features, often merging them back together quickly.
## Create a new branch
You can create a new branch with `git branch`, then checkout the branch with `git checkout`.
To distinguish it from the main stream of development, presumably on `main`, we'll call this a "feature branch".
```console
git branch issue-5
git checkout issue-5
```
You can also use the shortcut `git checkout -b issue-5` to create and checkout the branch all at once.
Once you have switched to a branch, you can commit to it as usual.
## Switching branches
You use `git checkout` to switch between branches.
But what do you do if you are working on a branch and need to switch,
but the work on the current branch is not complete?
One option is the [Git stash](https://git-scm.com/book/en/v2/ch00/_git_stashing), but generally a better option is to safeguard the current state with a temporary commit.
Here I use "WIP" as the commit message to indicate work in progress.
```console
git commit --all -m "WIP"
git checkout main
```
Then when you come back to the branch and continue your work, you
need to undo the temporary commit by [resetting](#reset) your state.
Specifically, we want a mixed reset.
This is "working directory safe", i.e. it does not affect the state of any files.
But it does peel off the temporary WIP commit.
Below, the reference `HEAD^` says to roll the commit state back to the parent of the current commit (`HEAD`).
```console
git checkout issue-5
git reset HEAD^
```
If this is difficult to remember, or to roll the commit state back to a different previous state, the reference can also be given as the SHA of a specific commit, which you can see via `git log`.
This is where I think a graphical Git client can be invaluable, as you can generally right click on the target commit, then select the desired type of reset (e.g., soft, mixed, or hard).
This is exactly the type of intermediate-to-advanced Git usage that often feels more approachable in a graphical client.
## Merging a branch
Once you have done your work and committed it to the feature branch, you can switch back to `main` and merge the feature branch.
```console
git checkout main
git merge issue-5
```
## Dealing with conflicts
Most of the time, the merge will go smoothly.
However if both the branches you are merging changed the same part of the same file you will get a merge conflict.
```console
git merge issue-5
# Auto-merging index.html
# CONFLICT (content): Merge conflict in index.html
# Automatic merge failed; fix conflicts and then commit the result.
```
The first thing to do is **NOT PANIC**.
Merge conflicts are not the end of the world and most are relatively small and straightforward to resolve.
The first step to solving a merge conflict is determining which files are in
conflict, which you can do with `git status`:
```shell
git status
# On branch main
# You have unmerged paths.
# (fix conflicts and run "git commit")
#
# Unmerged paths:
# (use "git add <file>..." to mark resolution)
#
# both modified: index.html
#
# no changes added to commit (use "git add" and/or "git commit -a")
```
So this shows only `index.html` is unmerged and needs to be resolved.
We can then open the file to see what lines are in conflict.
```html
<<<<<<< HEAD:index.html
<div id="footer">contact : [email protected]</div>
=======
<div id="footer">
please contact us at [email protected]
</div>
>>>>>>> issue-5:index.html
```
In this conflict, the lines between `<<<<<< HEAD:index.html` and `======` are
the content from the branch you are currently on.
The lines between `=======` and `>>>>>>> issue-5:index.html` are from the feature branch we are merging.
To resolve the conflict, edit this section until it reflects the state you want in the merged result.
Pick one version or the other or create a hybrid.
Also remove the conflict markers `<<<<<<`, `======` and `>>>>>>`.
```html
<div id="footer">
please contact us at [email protected]
</div>
```
Now run `git add index.html` and `git commit` to finalize the merge.
CONFLICTS RESOLVED.
### Bailing out
If, during the merge, you get confused about the state of things or make a
mistake, use `git merge --abort` to abort the merge and go back to the state
prior to running `git merge`.
Then you can try to complete the merge again.
Git Basic Branching and Merging:
<https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging>