Git工作流程，Nvie分支模型提前和落后 [英] Git Workflow, Nvie Branching Model Ahead and Behind

问题描述

遵循Nvie的git分支模型，为什么在将相同的'release'分支合并到两个分支后，为什么最终每个前进1和最后1个'develop'和'master'？如果同一个'release'分支被合并到每个分支中，不应该掌握和开发同意吗？

  x 84a628d（origin / develop ，开发）合并分支'release-v3.0.1'开发
 | \ 
 | | x 2e4d60b（HEAD，v3.0.1，origin / master，master）合并分支'release-v3.0.1'
 | | | \ 
 | | | / 
 | | / | 
 | x | 716ce96（release-v3.0.1）版本3.0.1 
 | / / 
 x | fe3b54d一些更多的代码
 x | 3683892更多代码
 x | 8c0b835'develop'分支代码
 | / 
 x d051b54（v3.0）基线合并。合并远程追踪分支'origin / master'
  

$ git log origin / master ^ origin / develop

 提交2e4d60b7d6760b4f6b2328ab06150b020b0d279f 
合并：d051b54 716ce96 
作者：Todd 
日期：星期二三月26 11 ：27：59 2013 -0400 
 
合并分支'release-v3.0.1'
  

$ git log origin / develop ^ origin / master

  commit 84a628d96653ed196faa6387c8b208badf23aa75 
合并：fe3b54d 716ce96 
作者：Todd 
日期：Tue Mar 26 26:31:53 2013 -0400 
 
将分支'release-v3.0.1'合并为
  
 
 
 
我缺少什么？
解决方案
 
  git log origin / master ^ origin / develop 
  
这个命令显示所有提交可从 origin / master 但不是从 origin / develop  
  git log origin / develop ^ origin / master 
  
该命令显示所有可从 origin / develop 但不是来自 origin / master  
 
 
 
上述命令的输出似乎与图形一致你已经显示了。
 
 
 
如果你打算找出2个分支内容的差异，你应该使用 git diff 命令。
  git diff origin / master..origin / develop 
  
如果您只需要不同的文件列表，可以使用  -  name-status 选项：
  git diff --name-status origin / master..origin / develop 
  
在git中，提交的SHA1是根据父提交的SHA1，提交消息，时间戳和批次的其他此类信息。虽然您已将 release-v3.0.1 分支合并到 master 和开发中，你已经在2个不同的时刻做了2次独立合并。这显然不会为两者产生相同的提交SHA1。
 
 
 
您应该做的是以下操作之一：
 
 
 
 选项1：  
 
 
  git checkout master：
 git merge release -v3.0.1 
 
 git checkout开发：
 git merge master 
 
 git checkout master 
＃这将是一个快速合并
 git merge开发
  
 选项2：  
 
 
  git checkout开发：
 git合并release-v3.0.1 
 
 git checkout master：
 git merge开发
 
 git checkout develop 
＃这将是一个快速合并）
 git merge master 
  
通过这种方式，您最终将得到 master 和 develop 分支指向相同的提交。
 
 
 
即使您现在通过将 master 合并到 develop 或者其他方式
 
 
  git checkout master 
 git合并开发$ b，并在另一分支上快速合并。
 
 $ b git checkout develop 
＃这将是一个快进合并
 git merge master 
  
 
Following Nvie's git branching model, why do I end up with 'develop' and 'master' each 1 ahead and 1 behind the other after merging the same 'release' branch into both? If the same 'release' branch is merged into each, shouldn't master and develop agree?
x   84a628d      (origin/develop, develop) Merge branch 'release-v3.0.1' into develop
|\  
| | x   2e4d60b  (HEAD, v3.0.1, origin/master, master) Merge branch 'release-v3.0.1'
| | |\  
| | |/  
| |/|   
| x | 716ce96    (release-v3.0.1) Version 3.0.1
|/ /  
x | fe3b54d      Some more more code
x | 3683892      Some more code
x | 8c0b835      'develop' branch code
|/  
x   d051b54      (v3.0) Baseline merge. Merge remote-tracking branch 'origin/master'
$ git log origin/master ^origin/develop
commit 2e4d60b7d6760b4f6b2328ab06150b020b0d279f
Merge: d051b54 716ce96
Author: Todd 
Date:   Tue Mar 26 11:27:59 2013 -0400

Merge branch 'release-v3.0.1'
$ git log origin/develop ^origin/master
commit 84a628d96653ed196faa6387c8b208badf23aa75
Merge: fe3b54d 716ce96
Author: Todd 
Date:   Tue Mar 26 11:31:53 2013 -0400

Merge branch 'release-v3.0.1' into develop
What am I missing?
解决方案
git log origin/master ^origin/develop
This command displays all commits reachable from origin/master but not from origin/develop
git log origin/develop ^origin/master
This command displays all commits reachable from origin/develop but not from origin/master

The output from both these above commands seem to be consistent with the graph you've shown.

If you intend to find out the difference in the contents of the 2 branches, you should be using the git diff command instead.
git diff origin/master..origin/develop
If you want only the list of files which are different, you can use the --name-status option:
git diff --name-status origin/master..origin/develop
In git, a commit's SHA1 is calculated based on the parent commit's SHA1, the commit message, the timestamps, and lot of other such information. Although you've merged the same release-v3.0.1 branch into both master and develop, you've done it as 2 independent merges at 2 different time instants. This would obviously not produce the same commit SHA1 for both.

What you should've done instead is one of the following:

Option 1:
git checkout master:
git merge release-v3.0.1

git checkout develop:
git merge master

git checkout master
# This would be a fast-forward merge
git merge develop
Option 2:
git checkout develop:
git merge release-v3.0.1

git checkout master:
git merge develop

git checkout develop
# This would be a fast-forward merge)
git merge master
This way you would end up with both master and develop branches pointing to the same commit.

You could get to the same state even now by merging either master into develop or the other way around, and doing a fast-forward merge on the other branch.
git checkout master
git merge develop

git checkout develop
# This would be a fast-forward merge
git merge master


                        
这篇关于Git工作流程，Nvie分支模型提前和落后的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！