![]() I chiefly just want to impress upon you that a merge conflict is, of itself, not necessarily bad. ![]() I could say much more about the actual mechanisms involved in a merge conflict - what Git does behind the scenes when a situation like this arises, and what other sorts of situation can count as a conflict. Ultimately, when all conflicted files are fixed and added, say git merge -continue and the merge will be completed. ![]() When you’re done editing, save the file and then git add the file. So don’t be afraid go ahead, open the file in your favorite text editor and edit it! Use the information given to make the file look the way you want it. ![]() If you replaced all of those lines with just "Goodbye world", for example, that would be a possible resolution. Your job at this point is to eliminate everything in that clump of lines that isn’t what you actually want. So Git has written some markers into your file, describing the merge conflict. That shows you both branches (termed ours and theirs ) along with the merge base, so you can really see what happened here. Git then rewrites the conflicted file with even more information, like this: > theirs So, for instance, suppose we are in this situation: otherbranchĪs you can see, that’s a crude but effective way of showing you that one branch, the one we are on, has "Hello everyone" at this point, and the other branch, otherbranch, has "Goodbye world".Ī cool trick for getting even more information at this point is to say: % git checkout -conflict diff3 The new commit has a remarkable feature: it has two parents, the master commit you were on before you said merge, and the commit pointed to by otherbranch, in that order. You are working on master, so this new commit is created on master - meaning that the master branch name pointer is advanced to point to the new commit. Git now creates, out of whole cloth, a completely new commit combining the contributions of both branches. This means you are merging otherbranch into master. You say git merge otherbranch (or whatever the name of some other branch is). You are “on” a branch, usually a primary branch of some sort let’s say it’s master. Most characteristically, then, this is how a merge proceeds: However, the commits in question will almost always have branch names, and it is natural to think of this operation as merging one branch into another. When you merge with Git, you merge commits. Other commits that you might think of as “on” a branch are more properly considered as reachable through the parent chain from the commit that the branch name points to. Recall that a branch in Git is just a name pointing to a single commit. Let’s start with a review of what I said about merging in the earlier article. If Git is often misunderstood, merging is one of the most misunderstood things about it! In this article, I’ll try to clear up some misunderstandings about merging with Git. Carrying on from my earlier article about some ways in which Git is commonly misunderstood - and how I think one should understand Git - I’d like to dive a bit deeper into one of the most important things Git knows how to do: merging.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |