git - 重用 merge 的开发分支/使用 git 重新 merge 到未更改的稳定分支

Question

两个程序员 A 和 B 正在使用 github 托管存储库开发一个项目:

分支主管存在。

程序员A根据最新的master创建devBranchA

master$ git checkout -b devBranchA

程序员B根据最新的master创建devBranchB

master$ git checkout -b devBranchB

他们决定尽可能将稳定的更改 merge 到 master 中。

商定的工作流程是:

[在 devBranch 上]

git commit -m 'Stuff to make branch stable enough to merge'

git checkout master

git pull origin master 

git merge devBranch [fix merge conflicts if any]

git checkout devBranch

git commit -m 'New cool stuff'

但是，如果自上次 merge 以来没有对 master 的提交，则无法将 devbranch merge 回 master(除非创建了一个新的 dev 分支，而不是重用旧分支)

在这种情况下，当程序员 B 来将他的工作 merge 到 master 分支时，它不会是当前预期的 master，而是 merge 前 master 的状态。

如果没有临时提交，有没有办法在 merge 时自动强制 master 分支将自身更新为 dev 分支的头部？

使用 git 和集中式 github 存储库时，预期的多用户工作流程是什么？我感觉好像我没有按预期使用 git。

Answer 1

查看 git fetch;git rebase origin/master 或 git pull --rebase，两者都遵循 master 存储库中的提交顺序，因为它 rebase ，坚持本地提交在上面。无论如何，您不会像本地分支机构那样关心本地提交的顺序，因为只有您拥有它们。尝试一下，但要小心使用，例如在 rebase 之前复制一个分支，直到你习惯为止。

一般来说，您谈论的是 git 工作流，我发现有两个您应该熟悉的通用工作流。请注意，我是根据个人经验谈论如何最大程度地减少冲突:

• Rebase-first 工作流程(为了获得最干净的提交历史，通常将冲突的负担推给未提交的代码)
• merge 工作流程(有时当有很多会发生冲突的更改时会更简单，我通常只将其用作后备)

示例初始工作流

git checkout master // For the sake of argument, let's say the latest commit in your local master is from august 1st or something old like that.
git branch temp_branch // copy of the master
git checkout temp_branch
git add changedFiles;git commit changedFiles; // A change from november 2nd.

git log // Now your dev branch has a new commit on top of an otherwise old branch.

git log origin/master // You get a listing of the commits from the origin repository, the master branch.  

通常我使用 origin/master 进行开发阶段，git 标签代表实时发布的提交。

现在这里是问题发生的地方，也是工作流选择发挥作用的地方:假设有一个提交来自另一个开发存储库，例如 master 10 月 15 日的提交。可能是其他开发人员所为，也可能是您自己所为。

您的选择: merge 或 rebase 。

merge

引入额外的提交，在规范(原始/主)历史上尊重您的本地(未推送)分支开发历史，导致更多潜在的冲突其他和其他分支。本质上，您是在说“我的提交顺序将与主分支提交顺序混合”，而不是重新排序提交历史。

git merge origin/master // merge commit introduced
... // Resolve any conflicts, and finalize the merge commit.
git checkout master;git rebase temp_branch // Move the changes to master.
git push origin/master // Pushing changes, including merge commit, to origin/master

最后，提交历史将类似于:August-October-November-MergeCommit

rebase

没有额外的提交，荣誉提交已经在规范存储库(origin/master)中超过本地提交，发生的冲突通常发生在开发人员尚未提交的提交上(因此没有其他人可以解释)。

git rebase origin/master // 
... // Resolve any conflicts...
git rebase --continue or git rebase --abort
... // Resolve any conflicts...
git checkout master;git rebase temp_branch // Get the branch changes without a merge commit into master.
git push // Push all changes to the canonical repository.

注意:如果您最终不得不执行两个以上的冲突解决方案，-那么-现在是git rebase --abort 并返回进行 merge 的好时机。

---

试试这个过程，看看它对你是否有意义!在您真正获得适合您的 git 开发的策略之前，需要进行一些实验，我猜是因为一旦您实现去中心化，就会有更多的方法。