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

Question

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

该功能只有在完全完成后才能与 master 分支合并。但是，新功能的开发大约需要 3-4 个月。

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

1. 在我的功能分支上开发 (git add -u)
2. 提交并推送到功能分支 (git commit && git push)
3. 结账拉高手(git checkout master && git pull)
4. 每天检查功能分支并与master合并（git checkout feature-branch && git merge master）；在这里我向Git霸主祈祷我不会遇到讨厌的合并冲突
5. 冲洗并重复 1-4

首先，这种方法是 'correct' 方法吗（如果有正确的话）？或者 git rebase 是获得线性历史的首选方法吗？

真正让我烦恼的是日志的样子：

显然日志只会一天比一天宽，直到有一天我将功能分支合并到主分支。

Answer 1

我认为对于这种情况，您通常会使用 rebase 工作流程。也就是说，不是反复合并来自 master 分支的更改，而是定期将分支重新设置为 master 分支。

最终结果是一样的（如果master分支对你一直在编辑的相同代码进行了更改，你仍然需要解决冲突），但最终结果是你的分支总是出现分支离开 master 分支的尖端，而不是遥远路径中的某个点，由此产生的历史记录要清晰得多。

工作流程类似于：

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

您可以 git push 根据需要对您的分支进行更改，尽管 请注意，在变基后你需要 git push -f 因为你现在 更改了您分支的历史记录。

当您完成并准备合并时，您：

1. git结帐大师
2. git拉
3. git 合并你的功能分支
4. git推

This essay 似乎很好地概述了工作流程。