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

本文介绍了修正共享功能分支的Git工作流程？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

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

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

-master -feature

功能分支是共享分支，因为许多开发人员正在一起开发新功能。他们正在积极地将他们的改变推向功能分支。

我试图避免功能终于获得的'冲突地狱'合并回 master 。目前，我看到了一些选择：

主动将 master 合并到功能经常。但是，这不是在git文档中推荐的，我开始明白为什么。当我尝试这样做时，我似乎一次又一次修复了相同的冲突。

2）以某种方式使用rebase。仔细阅读，但它看起来不行，因为功能分支实际上是共享的。所需要的只是一名开发人员进行2次重组，而其他开发人员可能因不匹配的历史记录而产生冲突。

$ b 打开功能分支到一个集成分支，并让开发人员使用他们自己的独立功能分支和分派来保持事物的健全。

4）完全不同的东西

解决方案

，我会选择＃3，并将其用作整合分支来巩固他们的工作。 开发人员必须使用rebase来不断重播他们的 private 分支位于特性之上，这样它们就是： $ b $ ul

在本地解决任何合并冲突（在他们自己的仓库中）

进行最后的合并（从他们的 private 分支到特征）一个简单的（通常是快进）

（如 git rebase vs merge 回答）

这个想法是，一旦特性分支必须被合并到 master 中，那么在 FEA ture （该分支是冻结的），您可以安全地将其重新放在 master 之上，或者直接将其合并到 master 。 然后开始一个新的特性分支（它实际上可以并行地启动前一个功能如果需要的话）

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

On the shared repo, we have these branches:

-master -feature

The feature branch is a shared branch, 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 feature finally gets merged back into master. Currently, I see some options:

1) Actively merge master into 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.

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

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

4) Something completely different?

解决方案

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 private branch on top of feature before merging back their work to feature, that way they are:

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

(as described in "git rebase vs. merge" answer)

The idea is that, once feature branch 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 master first, or merge it directly to master. And then you start a new feature branch (which can actually start in parallel of the previous feature branch if needed)