哪种方式与git合并？ [英] Which way to merge with git?

问题描述

假设我有两个分行
$ b $ pre $ $ $ $ c $ master $ A $ - $ - $ - $合并
\ /
\- develop - B - C

现在，如果我想合并它将是一个快速前进，但我应该做

  git checkout develop 
 git merge master 
 
 code> 

或

  git checkout master 
 git merge develop 
  

如果我有可能发生冲突
$ b

  master  -  A  -  D  -   -   -   -   -  --merge 
 \ / 
 \- develop  -  B  -  -  C 
  

现在我应该合并开发还是成为主人？这有点令人困惑，所以一个很好的解释将非常值得赞赏

解决方案

缺少工作流程任务

首先，您的工作流程中缺少一些内容，难以以现实世界的方式回答您的问题。例如：

1. 在合并分支之前，您应始终从上游取出。其他人可能以您尚未说明的方式更改开发或 master 。

你还没有确定哪个是你长期存在的发展路线。一个假设开发，但这只是一个猜测，因为你没有确定你的分支在合并之后会发生什么。

重新分配长存分行的一般最佳实践

所以，假设您已经更新了分行的时间，而且 都是长寿命的分支，而 master 是已完成代码的官方分支，应该按照这些方法做一些事情。

1. 根据 develop 创建一个临时rebasing分支 p>
   
   

     git checkout -b tmp develop 
     




2. 将您的工作重新分配到 master 以确保干净的快速合并。我喜欢将它作为交互式底图，但以任何您想要的方式进行。例如：
   
   

     git rebase -i master 
     




3. 合并到 master 上。我更喜欢强制合并成为快进，但你可以做任何适合你的。

     git checkout master 
    git merge --ff-only tmp 
     




4. 确保合并的分支干净地按下。

     git push origin 
     




5. 如果一切顺利，请处置您的临时分支。
   
   

     git branch -d tmp 
     




6. 将 master 与开发作为合并提交，而不是快进。这将使您的开发与继续工作的主分支一致。

     git checkout开发
    git merge master 
    git push origin 
     

自然后果 h3>

这样做可以确保您的 master 分支上的历史记录相对线性并且不受合并冲突的影响，并且仍然允许您在需要时进行重新绑定而不会造成混乱出版分行。这是所有积极的东西。然而，这个过程可以让开发的复杂合并历史记录，因为从 master重新合并 可能并不总是快速合并。这本身并不是问题，它只是任何工作流程的自然结果，其中包括重新绑定。这是值得注意的，但在我看来，这是一个值得付出的代价，它为团队提供了灵活性。

Say I have two branches

master -- A -   -   -   -   -  - merge
          \                    /
           \- develop -- B -- C

Now if I want to merge it will be a fast forward, but should I do

git checkout develop
git merge master

or

git checkout master
git merge develop

And what if I have possible conflicts

master -- A - D -  -  -  -  -  -merge
          \                   /
           \- develop -- B -- C

Should I now merge in to develop or into master? This is a bit confusing, so a good explanation would be really appreciated

解决方案

Missing Workflow Tasks

First of all, there are a few things missing in your workflow that make it hard to answer your question in a real-world way. For example:

1. You should always pull from upstream before merging branches. Others may have changed develop or master in ways that you haven't accounted for.

2. You haven't identified which is your long-lived line of development. One assumes develop, but that's just a guess because you haven't identified what happens to your branches after the merge.

General Best Practices for Rebasing Long-Lived Branches

So, assuming that you've updated your branches ahead of time, and that master and develop are both long-lived branches and that master is the "official" branch for completed code, then you should do something along these lines.

1. Make a temporary rebasing branch based on develop.

   git checkout -b tmp develop
   

2. Rebase your work onto master to ensure a clean fast-forward merge. I like to make this an interactive rebase, but do it any way you want. For example:

   git rebase -i master
   

3. Merge onto master. I prefer to force the merge to be a fast-forward, but you can do whatever suits you.

   git checkout master
   git merge --ff-only tmp
   

4. Make sure the merged branch pushes cleanly.

   git push origin
   

5. If all went well, dispose of your temporary branch.

   git branch -d tmp
   

6. Re-merge master with develop as a merge commit, rather than a fast-forward. This brings your development into line with the master branch for continued work.

   git checkout develop
   git merge master
   git push origin
   

Natural Consequences

Doing this ensures that the history on your master branch is relatively linear and free from merge conflicts, and still allows you to rebase when needed without screwing up published branches. This is all positive stuff.

However, this process can leave develop with a complex merge history since the re-merging from master to develop may not always be a fast-forward merge. This isn't a problem, per se, it's just a natural consequence of any workflow that includes rebasing. It's something to be aware of, but in my opinion it's a price worth paying for the flexibility it offers the team.

这篇关于哪种方式与git合并？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！