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: github-primer.md
+64
Original file line number
Diff line number
Diff line change
@@ -110,3 +110,67 @@ You will then see a PR created on the original repo, which will incorporate your
110
110
111
111
(Whew.)
112
112
113
+
## Avoiding Merge Conflicts
114
+
115
+
A merge conflict means that some changes you made conflict (or seem to conflict) with some other changes made between when you started your edit (usually when you did a fork or clone) and when you ended your edit (usually when you submit your pull, though alternatively when someone looks at your PR if it's been sitting around for a while). (We say "seem to" because the GitHub merging isn't always as robust as we'd like and sometimes there are actually no changes to the section that you also changed but GitHub is just confused due to to other changes in the document.)
116
+
117
+
The only way to really avoid merge conflicts is to be quick: to make sure that your fork/clone is 100% up-to-date when you start making changes, and then to submit your PR as soon as possible. On the web, you can keep up-to-date by going to the main page of your fork and seeing if it's some number of "commits behind" and if so choosing to "Sync Fork"; on a local clone, you can similarly do so by "git pull"ing down changes before you make updates. Once you start making changes on your side, things get more complex, so do the update first!
118
+
119
+
## Resolving Merge Conflicts
120
+
121
+
When you don'd avoid a merge conflict (and obviously that's not always possible: sometimes you're working on things for a while and sometimes someone else is working exactly when you are), then the dreaded resolve-conflicts box shows up:
122
+
123
+
<imgwidth="1075"alt="Screenshot 2023-02-14 at 7 43 56 AM"src="https://user-images.githubusercontent.com/1110886/218817096-7587e07c-ce9d-47ce-aa77-b90c3d35572d.png">
124
+
125
+
This typically means that your fork/clone was some number of commits behind when you started making your own changes _and_ GitHub can't figure out how to integrate those two sets of changes (though often it'll be able to):
126
+
127
+
```
128
+
This branch is 4 commits ahead, 3 commits behind BlockchainCommons:master.
129
+
```
130
+
When you click on the "Resolve Conflicts" button, you see all the conflicted areas.
131
+
132
+
For example:
133
+
```
134
+
<<<<<<< update-dates
135
+
* **[European Blockchain Convention](https://eblockchainconvention.com)** 2023/02/15 - 2023/02/17 Barcelona
136
+
* **Real World Crypto 2023** 2023/03/27 - 2023/03/29 Tokyo, Japan
* 2023/11/07 - 2023/11/08 | Suntec Convention Centre, Singapore
154
+
>>>>>>> master
155
+
```
156
+
157
+
In each case, it shows your update between `<<<<<<< your-branch-name` and `=======` and the current state of the repo between `=======` and `>>>>>>> master`. So what you need to do is integrate the two conflicted states into a coherent whole and remove the `<<<<<<< your-branch-name`, `=======`, and `>>>>>>> master` lines.
158
+
159
+
Often it's really easy, and you just need to excise the old version and include your new version (or vice versa), because GitHub claimed there was a conflict when there wasn't.
160
+
161
+
The above example was a _real_ conflict. The new update had a URL for IIW, while the new master had a better organization. So a resolution might look something like the following: note the "IIW" line in particular, which takes elements from both branches:
0 commit comments