Git/Sourcetree 基本分支和合并

Git/Sourcetree basic branching and merging

提问by Chris

Newbie question alert!!! I am just starting to get into using Git, and particularly Sourcetree which seems like a good application for visualizing it. On my first test it went along pretty well, branching and merging (see the top diagram). I know this structure means I'm using the development and master branch the wrong way round, but that's fine because at least it worked.

新手问题提醒！！！我刚刚开始使用 Git，尤其是 Sourcetree，它似乎是一个很好的可视化应用程序。在我的第一次测试中，它进行得非常好，分支和合并（见上图）。我知道这种结构意味着我以错误的方式使用 development 和 master 分支，但这很好，因为至少它有效。

On my second try though, I couldn't seem to visualise any branches, even though work was being done in both of them they seem to appear in one single branch (with a '7 ahead' note), and when I try and merge nothing seems to happen. Hopefully the second screenshot is enough for someone to tell me what is happening here? If not I will try and give some more info.

但是，在我第二次尝试时，我似乎无法想象任何分支，即使它们都在完成工作，它们似乎出现在一个分支中（带有“7 前面”注释），并且当我尝试合并时似乎什么也没有发生。希望第二个屏幕截图足以让某人告诉我这里发生了什么？如果没有，我会尝试提供更多信息。

I'm just playing around at the moment, so still getting to grips with proper workflow, just trying to get the basic branching and merging actions to take place in a consistent manner through Sourcetree. Any help will be appreciated.

我现在只是在玩，所以仍然掌握正确的工作流程，只是试图通过 Sourcetree 以一致的方式进行基本的分支和合并操作。任何帮助将不胜感激。

采纳答案by quickshiftin

In the second picture there are branches. Locally you have 2 branches, master& develop. Both branches are resting at the same commit though. If you want to 'see branches' as in the first picture you can make a commit on develop, however the graph will still apear to be linear. You'll be able to mergedevelopinto masterat that point if you want.

在第二张图中有分支。在本地，您有 2 个分支，master和develop。尽管如此，两个分支都在同一个提交中休息。如果您想像第一张图片那样“查看分支”，您可以在develop上进行提交，但是该图仍将显示为线性。如果需要，您可以在那时将develop合并到master中。

If you want to see the graph diverge, try putting a commit on masteras well. Then you will start to see something more like the first picture.

如果您想看到图表发散，也可以尝试在master 上提交一个提交。然后你会开始看到更像第一张图片的东西。

To get an idea of how git works with a visualization program like this, I suggest you do actions like I suggested above, and take a look at the graph at each intermediate step.

要了解 git 如何与这样的可视化程序一起工作，我建议您执行我上面建议的操作，并查看每个中间步骤的图表。

回答by Eelke Blok

There's a few things going on here. First, it's useful to understand that branches in Git are really just "labels" that are stuck to a particular commit, and that will be moved automatically when you commit to the the branch; Git will create the new commit, with a new commit hash, and update the branch/label to point to the new commit. (You might ask, how is this different from tags, then? A tag is stuck to the same commit, and will not get updates when you call git commit.)

这里发生了一些事情。首先，理解 Git 中的分支实际上只是粘在特定提交上的“标签”是有用的，当你提交到分支时它会自动移动；Git 将使用新的提交哈希创建新的提交，并更新分支/标签以指向新的提交。（你可能会问，这与标签有什么不同？标签被卡在同一个提交上，并且在调用 git commit 时不会得到更新。）

When you create a new branch, all that happens is that Git creates a new label, pointing to the same commit you were on. Only when you create a new commit while this new branch is checked out, will you see the new branch diverge from the other branch.

当您创建一个新分支时，所发生的一切就是 Git 创建一个新标签，指向您所在的同一个提交。只有在签出此新分支的同时创建新提交时，您才会看到新分支与其他分支不同。

The real confusion starts when you start merging branches again, and this is largely due to a weird thing Git calls "fast forward merging", which it does by default. Let's take your second example and imagine that your master and develop are where originally origin/master and origin/develop were:

当您再次开始合并分支时，真正的困惑就开始了，这主要是由于 Git 称为“快进合并”的奇怪事情，它默认情况下会这样做。让我们以您的第二个示例为例，假设您的 master 和 develop 位于最初的 origin/master 和 origin/develop 所在的位置：

When you ask Git to merge one branch into another, Git will go and figure out what it needs to do to get the difference between those branches into the target branch. Let's say you want to merge the changes you made to develop into master, so you tell git:

当您要求 Git 将一个分支合并到另一个分支时，Git 会找出它需要做什么才能将这些分支之间的差异合并到目标分支中。假设您想将您所做的更改合并到 master 中，因此您告诉 git：

$ git checkout master
$ git merge develop

Git will look at the branches, and see that develop is just ahead of master by a few commits, but there's nothing more complicated going on than that. So, it will do a "fast forward" merge, by simply taking the master label and sticking it to the commit where develop is pointing. Mission accomplished, changes that were only in develop before are now also in master.

Git 会查看分支，并发现 develop 仅在几次提交之前领先于 master，但没有比这更复杂的事情了。因此，它将通过简单地获取主标签并将其粘贴到 develop 指向的提交来进行“快进”合并。任务完成，以前只在开发中的更改现在也在主中。

Should each branch have extra commits, like in your first example right before merging master into develop, "something more complicated" isgoing on. You made a commit on master, then did a git checkout develop, made a commit there, and thenasked Git to merge master back into develop. Git can now no longer "cheat" by just moving branch-labels around. It will need to figure out how to unify the changes from the two branches into a single state of the files under its control (let's assume, for now, it is always able to do that, which is not that far from the truth; its quite good at it. If it can't, you have a merge conflict, which is really not as bad as it sounds).

如果每个分支都有额外的提交，就像在将 master 合并到 develop 之前的第一个示例中那样，“更复杂的事情”正在发生。您在 master 上进行了提交，然后进行了 git checkout develop，在那里进行了提交，然后要求 Git 将 master 合并回 develop。Git 现在不能再通过移动分支标签来“欺骗”了。它将需要弄清楚如何将来自两个分支的更改统一到其控制下的文件的单一状态（让我们假设，现在它总是能够做到这一点，这与事实相去不远；它的非常擅长它。如果它不能，你有一个合并冲突，这真的没有听起来那么糟糕）。

The new content, after the merge, will neither be the last state of the first branch, nor will it be the state of the second branch. So, it needs to be represented with a brand new commit, which is what you see at the top of your first example; Git created what it calls a "merge commit" to represent the new state with the changes from each branch merged into a single state.

合并后的新内容既不会是第一个分支的最后状态，也不会是第二个分支的状态。所以，它需要用一个全新的提交来表示，这就是你在第一个例子的顶部看到的；Git 创建了它所谓的“合并提交”来表示新状态，其中每个分支的更改合并为一个状态。

Lastly, you can force Git to always create a merge commit, eventhough it is strictly, technically, not needed. In the command line, you can do this with the flag --no-ff, for no fast forward. Graphical clients will have a checkbox that will accomplish the same thing (in SourceTree, it is currently labeled "Create a commit even if merge resolved via fast-forward"). Many (including myself) actually recommend to just merge with --no-ff, because that way the act of merging is always recorded in history, regardless of technicallities like whether it would technically be possible to just move branch pointers around.

最后，您可以强制 Git 始终创建合并提交，即使严格来说，技术上不需要。在命令行中，您可以使用标志 --no-ff 执行此操作，以免快进。图形客户端将有一个复选框来完成同样的事情（在 SourceTree 中，它当前被标记为“即使通过快进解决合并，也创建提交”）。许多人（包括我自己）实际上建议只与 --no-ff 合并，因为这样合并的行为总是被记录在历史中，而不管技术上是否可以只移动分支指针。

回答by Guney Ozsan

You can prevent branches from disappearing in Source Tree permanently by enabling "Do not fast-forward when merging, always create commit"in Tools/Options.

您可以通过在Tools/Options 中启用“合并时不要快进，始终创建提交”来永久防止分支在源树中消失。

If you want to decide for each merge operation, there is an option "Create a new commit even if fast-forward is possible" in the Merge dialog box.

如果要为每个合并操作决定，合并对话框中有一个选项“即使快进是可能的，也创建新提交”。

Also I suggest referring Eelke Blok's answerfor the technical details.

此外，我建议指Eelke勃洛克的答案的技术细节。

回答by Jason Alford

I just ran into this same problem and found that there's a setting in SourceTree to "Do not fast-forward when merging, always create commit". Make sure that's checked and you'll see the branch structure from them on.

我刚刚遇到了同样的问题，发现 SourceTree 中有一个设置为“合并时不要快进，总是创建提交”。确保选中它，您将看到它们的分支结构。

This setting is found on the Git tab in preferences.

此设置位于首选项的 Git 选项卡上。