Question

我遵循的是git分支模型，该模型具有两个长期运行的分支（dev，master），其中功能分支主要基于master（有时有时称为dev），然后合并到dev，然后在少数特征之后将dev合并到master（所有合并都是非ff合并）。

git checkout -b feature master
// work
git checkout dev
git merge --no-ff feature
// after n features
git checkout master
git merge --no-ff dev

现在将开发人员与主人员合并5次之后

git rev-list --left-only --count master...dev
5

给人的印象是，母版中有更改，而开发人员中没有。

在将开发者与开发者合并之后，我一直在通过开发者来解决这个问题。实际运行中的分支将基于ff合并为master之前的dev（下面为391355d而不是ca386a7）。有没有比这更好的方法了？

*   ca386a7 - Sun 05-Aug-2018 11:00 (6 days ago) (HEAD -> dev, master)
|\    Merge branch 'dev' - hIpPy
| *   391355d - Sun 05-Aug-2018 10:50 (6 days ago)
| |\    Merge branch 'cutg' into dev - hIpPy
| | * 53ca791 - Sun 05-Aug-2018 10:42 (6 days ago)
| |/    cutg: Teach to exclude binary files - hIpPy
|/|   
| *   269e4c7 - Sat 04-Aug-2018 13:14 (7 days ago)
| |\    Merge branch 'while-loop' into dev - hIpPy
| | * 356f50d - Sat 04-Aug-2018 13:01 (7 days ago)
| |/    while-loop: Fix bash while loop - hIpPy
| *   56a121a - Sat 04-Aug-2018 00:20 (8 days ago)
| |\    Merge branch 'pipe' into dev - hIpPy

Answer 1

简短版本：如果您选择no-ff作为工作流程，则会引入新的真实提交，而git无法将它们与其他提交区分开（afaik）。

>

分支只是提交的指针，它们实际上不是树结构的一部分。另一方面，提交是代表变化的物理事物。如果您选择将此更改作为空的占位符，那就是您的特权，但但是git仍会将其标识为真实提交，而无法将其与其他提交区分开（就GIT而言，没有任何区别）被关注到）。 印象不是假的，确实有额外的提交，这是更改的唯一衡量标准，而不是文件。

关于还原，这两个是：

O-O------M<-master
   \    /
     O-X-O-O<-dev

O-O
   \   
     O-X-O-O<-dev
       ^
      master

将允许轻松恢复到X。但是第一个有一个额外的提交。因此，实际上必须做出的工作流程决定：

在主标记合并上进行额外提交（尽管-no-ff正是针对这些类型的事情，您似乎不希望这样做）。
我们在主要开发分支上使用的另一种解决方案，在master分歧以准备新版本之前使用它。
如果您的注释足够有意义，则可以使用git log进行标识，并在需要时使用它来还原。

最后两个当然是ff，所以master和dev将指向同一分支，尽管master可能会落后。从git的角度来看，这是有道理的，因为它们实际上是相同的。关于这些解决方案：

标记提交时，{git tag "Added f1"）在gitk上看起来很好看并且呈黄色，而且很容易看到。您可以使用git tag -l列出它们，并查看添加的内容等。这是我们的首选方法。
完成功能时，可以确定一个特定的前缀，例如“ feat：”，然后可以使用git log -all -grep="^feat:找到它们。

在GIT之上，有一些工作流程可以强制执行所有这些工作流程（包括no-ff）（在Google周围，您会引入新功能，例如开始功能和结束功能等）

由于无ff合并提交至master，因此dev分支有所不同

1 个答案: