如何在跨月的特性分支中正确开发

Question

我目前的情况是，我必须为一个现有的、仍在大力开发中的项目开发一个特性。

只有当主分支完全完成时，该特性才应该与主分支合并。然而，新功能的开发将需要大约3-4个月的时间。

所以我现在的工作流程大概是：

1. 在我的特性分支(git add -u)上开发
2. 提交并推送到特性分支(git commit && git push)
3. 签出和拉出母版(git checkout master && git pull)
4. 结帐特性分支，并每天与主人合并(git checkout feature-branch && git merge master)；在这里，我向Git霸主祈祷，不要有令人讨厌的合并冲突。
5. 冲洗并重复1-4

首先，这种方法是否“正确”(如果有正确的东西)？还是git rebase是获得线性历史的首选方法？

真正困扰我的是日志的样子：

​

​

很明显，日志只会越来越宽，直到有一天我将特性分支合并到主分支中。

Answer 1

我认为，在这种情况下，您将更多地使用rebase工作流。也就是说，与其重复合并主分支中的更改，不如定期将分支重新基于master。

最终结果是相同的(如果主分支对您所编辑的相同代码进行了更改，则仍然需要解决冲突)，但最终的结果是，您的分支总是从master分支的顶端分支，而不是在遥远的路径中的某个点，由此产生的历史非常清晰。

工作流看起来类似于：

1. 在您的特性分支上进行开发
2. 提交您的更改
3. 定期刷新master分支的本地副本(git remote update)
4. 基于主站的重基(git rebase origin/master)
5. 冲洗和重复

您可以根据需要对分支上的更改进行git push，不过请注意，在重基之后，您需要git push -f，因为您现在已经更改了分支的历史。

当你们都准备好要合并的时候，你：

1. git结账母版
2. 吉特拉力
3. git合并您的功能分支
4. git推送

这篇文章似乎是工作流的一个很好的概述。