新手提问提醒！！！我刚刚开始使用 Git，尤其是 Sourcetree，它似乎是一个很好的可视化应用程序。在我的第一次测试中，它进行得很好，分支和合并（见上图）。我知道这种结构意味着我错误地使用了开发和主分支，但这很好，因为至少它有效。
但是，在我第二次尝试时，我似乎无法想象任何分支，即使它们都在完成工作，它们似乎出现在一个分支中（带有“7提前”注释），当我尝试合并时似乎什么都没有发生。希望第二个屏幕截图足以让有人告诉我这里发生了什么？如果没有，我会尝试提供更多信息。
我现在只是在玩，所以仍然要掌握正确的工作流程，只是试图通过 Sourcetree 以一致的方式进行基本的分支和合并操作。任何帮助将不胜感激。
在第二张图片中有分支。在本地，您有 2 个分支，master和develop。不过，两个分支都在同一个提交上休息。如果您想像第一张图片中那样“查看分支”，您可以在develop上进行提交，但是该图仍然看起来是线性的。如果您愿意，您可以在那时将开发合并 为master 。
如果您想看到图表发散，请尝试在master上提交。然后你会开始看到更像第一张照片的东西。
要了解 git 如何与这样的可视化程序一起工作，我建议您按照我上面建议的方式执行操作，并查看每个中间步骤的图表。
这里发生了一些事情。首先，了解 Git 中的分支实际上只是粘在特定提交上的“标签”，并且当您提交到分支时会自动移动，这很有用；Git 将使用新的提交哈希创建新的提交，并更新分支/标签以指向新的提交。（你可能会问，这和标签有什么不同呢？一个标签被粘在同一个提交上，当你调用 git commit 时不会得到更新。）
当您创建一个新分支时，所发生的一切就是 Git 创建一个新标签，指向您所在的同一提交。只有在签出此新分支时创建新提交时，您才会看到新分支与另一个分支不同。
当您再次开始合并分支时，真正的混乱开始了，这主要是由于 Git 称之为“快进合并”的奇怪事情，默认情况下它会这样做。让我们以您的第二个示例为例，假设您的 master 和 develop 位于最初的 origin/master 和 origin/develop 所在的位置：
当你要求 Git 将一个分支合并到另一个分支时，Git 会去弄清楚它需要做什么才能将这些分支之间的差异合并到目标分支中。假设你想将你为开发所做的更改合并到 master 中，所以你告诉 git：
$ git checkout master
$ git merge develop
Git 会查看分支，发现 develop 比 master 快了几个提交，但没有比这更复杂的了。因此，它将进行“快进”合并，只需将主标签粘贴到开发指向的提交上即可。任务完成，以前只在开发中的变化现在也掌握了。
如果每个分支都有额外的提交，就像在将 master 合并到开发之前的第一个示例中那样，“更复杂的事情”正在发生。你在 master 上做了一个提交，然后做了一个 git checkout develop，在那里做了一个提交，然后让 Git 将 master 合并回 development。Git 现在不能再通过移动分支标签来“作弊”了。它将需要弄清楚如何将两个分支的更改统一到其控制下的文件的单一状态中（假设，现在，它总是能够做到这一点，这与事实相差不远；它的很擅长。如果不能，你就有一个合并冲突，这真的没有听起来那么糟糕）。
合并后的新内容既不会是第一个分支的最后一个状态，也不会是第二个分支的状态。因此，它需要用一个全新的提交来表示，这就是您在第一个示例顶部看到的内容；Git 创建了它所谓的“合并提交”来表示新状态，其中每个分支的更改合并到一个状态中。
最后，您可以强制 Git 始终创建合并提交，即使严格来说，从技术上讲，它是不需要的。在命令行中，您可以使用标志 --no-ff 来执行此操作，以禁止快进。图形客户端将有一个复选框来完成相同的事情（在 SourceTree 中，它当前标记为“即使通过快进解决合并也创建提交”）。许多人（包括我自己）实际上建议只使用 --no-ff 合并，因为这样合并的行为总是记录在历史中，无论技术上是否有可能只是移动分支指针。
我刚刚遇到了同样的问题，发现SourceTree中有一个设置为“合并时不要快进，总是创建提交”。确保已选中，您将看到它们的分支结构。
此设置位于首选项中的 Git 选项卡上。
您可以通过在工具/选项中启用“合并时不要快进，始终创建提交”来防止分支在源树中永久消失。
如果您想为每个合并操作做出决定，在“合并”对话框中有一个选项“即使可以快进也可以创建新提交”。
另外，我建议参考Eelke Blok的技术细节答案。