如何查看贡献分支整个生命周期中一个git分支对另一个git分支的净贡献

时间：2019-10-31 10:43:26

标签： git

我们有一个中央MASTER分支和多个单独的任务分支，我们的生命周期如下：

  
      
  1. 从MASTER创建单个任务分支A
    2.   
  2. 完成A并完成任务
    3.   
  3. 将A合并回MASTER
    4.   
  4. ...如果测试确定了A中需要进行的其他更改，则将最新的MASTER合并到A中（使A可以快速完成任务   B，C，...。在此期间可能已合并为MASTER）
    5.   
  5. 解决分支A中的问题
    6.   
  6. 将A合并回MASTER
    7.   
  7. （重复4 => 6，直到签署工作为止）
    8.   

上面的方法很好，但是在第7步之后我们需要做的是识别（通过某种GIT差异）：

在上述生命周期完成之后，A引入MASTER的净变化。

因此有效地，我们正在寻找一个单向差异A => MASTER，该差异显示在两个分支之间双向合并之后，A引入MASTER的净变化。

将非常感谢我对此提供的任何意见-谢谢！

2 个答案:

答案 0 :(得分：1)

您的生命周期模型与在合并到基线之前能够查看所有更改的目标相冲突，特别是在完成测试之前将主题分支合并到主的步骤。

相反，将所有更改都保留在topic分支中，直到最终签署之前 之后。寿命较长的主题分支可能需要 母版进行一些合并，即

git fetch
git merge origin/master

通过这种方式，您可以在主题分支的步骤4至7中执行测试和所有其他活动。在最终签收之前，只需简单地查看累积的更改

git fetch
git diff origin/master

最后，合并的确切机制将取决于您的工作流程。

如果您不介意基线中可能存在混乱的历史记录，只需合并主题分支即可。

git fetch
git checkout master
git merge --ff-only origin/master
git merge topic/fix-potrzebie

如果您的软件质量组织擅长壁球合并

git checkout master
git merge --ff-only origin/master
git merge --squash topic/fix-potrzebie
... fix merge conflicts ...
git commit -m 'PROJ-1234 Fix potrzebie ...'
git push origin master

保存证据表明存在主题分支，但将其折叠为单个提交。用困难而冒险的方式做

根据最新基准创建主题分支的新最终版本。

git fetch
git checkout -b topic/fix-potrzebie-final origin/master

将开发主题分支折叠为单个提交。

git merge --squash topic/fix-potrzebie
... fix merge conflicts ...
git commit -m 'PROJ-1234 Fix potrzebie ...'

将其合并回基线。

git checkout master
git merge topic/fix-potrzebie-final
git push origin master

但是没有理由再次进行所有合并，这也带来了风险，即您可能会将与测试对象不同的代码合并到基准中。已经合并并实际测试的代码可寻址为topic/fix-potrzebie^{tree}，即与主题分支顶端的提交相关联的树对象。用

的代码作为最后一棵树的单次提交进行一次小小的尝试 
git fetch
git checkout master
git merge --no-ff -m 'Integrate PROJ-1234' \
  $(echo 'PROJ-1234 Fix potrzebie ...' |
      git commit-tree topic/fix-potrzebie^{tree} \
        -p $(git rev-parse origin/master))

最后一个命令中有一些巫术。它创建表单的历史记录

$ git lola
*   df6bbc7 (HEAD -> master) Integrate PROJ-1234
|\
| * 0c180a8 PROJ-1234 Fix potrzebie ...
|/
| * 0156bc9 (topic/fix-potrzebie) Updates after testing
| * 0ae9d12 Potrzebie changes
|/
* 61993d0 (origin/master) PROJ-1233 Previous history ...

请注意，git lola是非标准的，但对别名很有用

git log --graph --decorate --pretty=oneline --abbrev-commit --all

还要注意，新的master提示和主题分支之间没有任何变化

$ git diff master topic/fix-potrzebie
[ no output, indicating no differences ]

，但实际上它们与相同，即 。它们具有相同的SHA-1哈希，因此共享同一棵树。

$ git rev-parse master^{tree} topic/fix-potrzebie^{tree}
9a4fc1bb6230e80bc3a1928a00cb404da6424153
9a4fc1bb6230e80bc3a1928a00cb404da6424153

要理解该命令，请按从右到左的顺序阅读。

  1. echo $MSG2 | git commit-tree $TREE -p $PARENT是git plumbing，它创建一个新的提交，其树为$TREE，其父级为$PARENT，其提交消息为$MSG2。
    • 该树与主题分支顶端已经提交的树相同。
    • 父级是origin/master，即当前的基线 ，但是使用git rev-parse从人类可读的引用名转换为SHA-1哈希。
    • git commit-tree的输出是新提交的SHA-1哈希，在…中变成$COMMIT_HASH。
  2. git merge --no-ff -m "$MSG1" $COMMIT_HASH将新提交合并到master中。即使我们将其设计为快速前进的方法，--no-ff开关仍保留了短暂的发散然后合并颠簸作为历史上的人工产物。
    • 这里的解释从单引号到双引号是一致的，但我希望不要与环境变量的值混淆。

此时，您可以使用以下方式删除现在过时的主题分支

git branch -D topic/fix-potrzebie

产生表格的整洁历史

$ git lola
*   df6bbc7 (HEAD -> master) Integrate PROJ-1234
|\
| * 0c180a8 PROJ-1234 Fix potrzebie ...
|/
* 61993d0 (origin/master) PROJ-1233 Previous history ...

最后，与其他团队成员共享

git push origin master

答案 1 :(得分：0)

请改用gitk来在用户界面中查看差异和其他差异。

相关问题
最新问题