共享功能分支的 Git 工作流程是否正确？

Question

我正在尝试找出适合这种情况的正确工作流程：

在共享存储库上，我们有这些分支：

-master
-feature

功能分支是一个共享分支，因为许多开发人员都在工作一起开发新功能。他们正在积极地将更改推送到功能分支。

我正在努力避免“冲突地狱”，因为有一天功能最终会合并回master。目前，我看到一些选项：

1）主动将master合并到feature中，并经常这样做。但是，在git中不建议这样做文档，我开始明白为什么。当我尝试这样做时，我似乎一遍又一遍地解决相同的冲突。

2）以某种方式使用变基。我已经阅读过这一点，但看起来它不起作用，因为 feature 分支实际上是共享的。只需要一名开发人员进行 2 次变基，其他开发人员可能会因历史记录不匹配而产生冲突。

3) 将功能分支转变为集成分支，并让开发人员使用自己的独立功能分支并进行变基以保持理智。

4）完全不同的东西？

Answer 1

对于共享分支，我会选择#3，并将其用作“集成”分支来巩固他们的工作。
开发人员必须使用 rebase 不断地在 feature 之上重放他们的 private 分支，然后再将他们的工作合并回 feature，这样他们就可以：

• 在本地（在他们自己的存储库中）解决任何合并冲突，
• 使最终合并（从他们的 private 分支到 feature）变得微不足道（通常是快进）

（如上所述在 "git rebase 与 merge< /code>"答案）

这个想法是，一旦 feature 分支必须合并到 master 中，feature< 就不再接受任何贡献/code> （该分支已“冻结”），您可以首先在 master 之上安全地对其进行变基，或者直接将其合并到 master。
然后启动一个新的 feature 分支（如果需要，它实际上可以与之前的 feature 分支并行启动）

Answer 2

您可以使用 rerere 来处理您的合并冲突都看过好多次了

Answer 3

（我不太热衷于选项 1、2 或 3，所以我正在尝试找到更好的工作流程；因此，我在下面描述我如何考虑解决该问题，希望有人能给我建议）

1. 使用 git 补丁队列工具之一将功能分支转入补丁队列。
2. 使用单独的 git 存储库对补丁队列进行版本控制
3. 使用常用的 git 方法在补丁队列上进行协作。

对于人们来说，将补丁队列重新转变为本地功能分支可能是明智的。

Answer 4

功能分支的 Git 工作流程

过程如下：-

第一次：

git pull
git checkout -b sprint-4
git pull origin sprint-4

• 上述命令将从 git 中拉取所有文件

• 将在我们的本地计算机上创建一个名为 sprint-4 的分支。

• 将把文件从服务器拉到我们的 sprint-4 分支。

对于每个新功能：-

git checkout -b <feature-branch>,  example: git checkout -n fer-181
git push -u origin <local-branch>:<remote-branch>, example git push -u     
origin fer-181:fer-181

• 在服务器上为此本地分支创建一个远程分支。
• 将文件从本地分支推送到远程分支。

每日：（在您的功能分支上）

git pull
git merge dev

• 解决冲突（如果有）

• 完成当天的工作

  git Push origin

功能已完成：

git pull
git merge dev

解决冲突（如果有）

git checkout dev
git merge <feature-branch>
git push origin dev

• 上述命令将合并我们功能中主分支的文件
  分支。
• 解决我们的功能分支中的冲突（如果有）。
• 将文件从功能分支合并到主分支。