共享功能分支的正确git工作流程是什么？ [英] What is the right git workflow with shared feature branches?

问题描述

假设我有一个名为特性的分支，它已被分支为 master 。 developer1和developer2都签出功能。 developer1会对功能进行更改并将其推送。然后，developer3将东西推到 master 。此时 master 和功能 diverge，每个都有单独的提交。

如果有 master 到特性的最新消息，正确的方法是什么冲突？我应该将 master 转换为功能，还是将它合并到？

编辑：

我应该提到在这种情况下，我不想重写developer2上的历史记录。因为那会很糟糕。考虑到特性分支已经被共享，它应该不会被分配给其他分支。 在$ master （因为它改变了它的共享历史记录）。

从 master 到特性就足够了（没有推测为什么 dev3 被推送至$ master ）。

---

As 将即将到来的合并到 master（例如，来自修补程序分支，如我较早评论）

Say I have a branch named feature that has been branched off master. Both, developer1 and developer2 checkout feature. developer1 commits a change to feature and pushes it. Then developer3 pushes something to master. At this point master and feature diverge, each having a separate commit.

What's the right way to go about getting the latest from master into the feature, if there are conflicts? Should I rebase master into the feature, or merge it in?

EDIT:

I should mention that in this case I would not want to rewrite the history on developer2. Because that would be bad. Right?

解决方案

Considering feature branch is already shared, it shouldn't be rebased on master (as it changes its - shared - history).

A simple merge from master to feature will be enough (without speculating as why dev3 pushed to master in the first place).

---

As Adam Dymitruk comments, this is called a "back-merge", and, depending on the role you attribute to master, it is questionable: if master represents the stable production state, you should merge to master, not from master.

But again, my answer made no assumption on said role.

---

This is why the famous git-flow illustrates in its blog post merges which are coming to master (from, for instance, an hotfix branch, as I commented earlier)

这篇关于共享功能分支的正确git工作流程是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！