解决冲突（如果有）

Question

我正在努力找出适合这种情况的工作流程：

在共享仓库中，我们有这些分支：

-master
-feature

功能分支是共享分支，因为许多开发人员正在共同开发新功能。他们正在积极地将他们的更改推送到功能部门。

我试图避免在功能最终合并回 master 的那一天出现“冲突地狱”。目前，我看到了一些选择：

1）将主主动合并到功能中，并经常这样做。但是，这不建议在git docs中使用我开始明白为什么了。当我尝试这个时，我似乎一遍又一遍地解决同样的冲突。

2）以某种方式使用rebase。我已经阅读了这篇文章，但由于功能分支实际上是共享的，所以看起来它不会工作。所需要的只是一个开发人员做2个rebase，而其他开发人员可能会因错误的历史而产生冲突。

3）将功能分支转换为集成分支，让开发人员使用自己独立的功能分支进行重新定位，以保持理智。

4）完全不同的东西？

Answer 1

对于共享分支，我会使用＃3，并将其用作“集成”分支来整合他们的工作。
开发人员必须使用rebase在private之前不断重播他们的feature分支，然后再将他们的工作合并到feature，这样他们就是：

在本地解决任何合并冲突（在他们自己的回购中）
进行最终合并（从他们的private分支到feature）一个微不足道的（通常快进）

（如"git rebase vs. merge"回答中所述）

这个想法是，一旦feature分支必须在master中合并，feature上不再接受任何贡献（分支被“冻结”），你可以安全地首先在master之上将其重新绑定，或者将其直接合并到master 然后你开始一个新的feature分支（如果需要，它实际上可以与之前的feature分支并行开始）

Answer 2

您可以使用rerere来处理您多次看到的合并冲突。

Answer 3

（我不太热衷于选项1,2或3，所以我试图找到一个更好的工作流程;因此我在下面描述我是如何考虑接近问题的，希望有人会告诉我）

使用git修补程序队列工具之一在修补程序队列中转动功能分支。
使用单独的git存储库来控制补丁队列
使用常用的git方法在补丁队列上进行协作。

人们可能明智地将补丁队列转换回本地的功能分支。

Answer 4

Git Workflow for Feature分支

过程如下： -

第一次：

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

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

纠正共享功能分支的Git工作流程？

4 个答案:

解决冲突（如果有）