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

Correct Git workflow for shared feature branch?

提问by Ben

I am trying to figure out the right workflow for this situation:

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

On the shared repo, we have these branches:

在共享仓库中，我们有以下分支：

-master
-feature

The featurebranch is a sharedbranch, since many developers are working on a new feature together. They are actively pushing their changes to the feature branch.

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

I'm trying to avoid 'conflict hell' for the day that featurefinally gets merged back into master. Currently, I see some options:

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

1) Actively merge masterinto feature, and do it often.However, this is not recommended in the git docs, and I'm starting to see why. When I try this, I seem to fix the same conflicts over and over again.

1)积极将master合并到feature 中，并且经常这样做。但是，在 git 文档中不推荐这样做，我开始明白为什么。当我尝试这个时，我似乎一遍又一遍地解决相同的冲突。

2) Use rebase in some way.I've read up on this, but it looks like it wont work since the featurebranch is actually shared. All it takes is one developer to do 2 rebases, and other developers could have conflicts from mismatched history.

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

3) Turn the featurebranch into an integration branch,and have the developers use their own independent feature branches with rebasing to keep things sane.

3)将功能分支变成集成分支，让开发人员使用他们自己的独立功能分支和 rebase 来保持正常。

4) Something completely different?

4）完全不同的东西？

采纳答案by VonC

For a shared branch, I would go with #3, and use it as an "integration" branch to consolidate their work.
The developers would have to use rebase to constantly replay their privatebranch on top of featurebefore merging back their work to feature, that way they are:

对于共享分支，我会选择 #3，并将其用作“集成”分支来整合他们的工作。
开发人员将不得不使用 rebase 不断地重播他们的private分支，feature然后再将他们的工作合并回feature，这样他们：

• solving any merge conflict locally (in their own repo)
• making the final merge (from their privatebranch to feature) a trivial one (normally fast-forward)

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

(as described in "git rebasevs. merge"answer)

（如“ git rebasevs. merge”答案中所述）

The idea is that, once featurebranch has to be merged in master, no more contribution is accepted on feature(the branch is "frozen"), and you can safely rebase it on top of masterfirst, or merge it directly to master.
And then you start a new featurebranch (which can actually start in parallel of the previous featurebranch if needed)

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

回答by Daenyth

You can use rerereto handle the merge conflicts you're seeing multiple times.

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

回答by Dickon Reed

(I'm not too keen on options 1, 2 or 3 so I'm trying to find a better workflow; I'm therefore describing below how I'm thinking of approaching the problem in the hope someone will advise me)

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

1. Turn the feature branch in a patch queue using one of the git patch queue tools.
2. Use a separate git repository to version control the patch queue
3. Use the usual git approaches to collaborate on the patch queue.

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

It might be sensible for people to turn the patch queue back into a feature branch locally.

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

回答by Vikas Kukreti

Git Workflow for Feature branch

功能分支的 Git 工作流

The process is follows:-

流程如下：-

First Time:

第一次：

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

• The above commands will pull all the files from git

• Will make a branch with name sprint-4 on our local machine.

• Will pull the files from server to our sprint-4 branch.

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

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

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

For every new feature:-

对于每个新功能：-

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

• Create a remote branch for this local branch on the server.
• Will push files from our local branch to remote branch.

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

Daily:(on your feature branch)

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

git pull
git merge dev

• resolve conflicts if any

• do your work for the day

  git push origin

• 解决冲突（如果有）

• 做你当天的工作

  git push 原点

Feature is complete:

功能齐全：

git pull
git merge dev

resolve conflicts if any

解决冲突（如果有）

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

• The above commands will merge files from main branch in our feature branch.
• Resolve conflicts in our feature branch if any.
• Merge the files from feature branch to main branch.

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