Cherrypicking与Rebasing [英] Cherrypicking versus Rebasing

问题描述

以下是我通常所面对的场景：

您有一组提交 master 或 design ，我想把它放在 production 分支的顶部。

我倾向于创建一个新的分支，其基址为 production cherry-pick这些提交并将它合并到 production $ b

然后，当我将 master 合并到生产中时，我面临合并冲突，因为即使所做的更改都是相同的，但由于樱桃选择而被注册为不同的提交。

我已经找到了一些解决方法来处理这个问题，所有这些都很费力，可以被称为hacks 。

虽然'我没有做太多重新绑定，我相信也会创建一个新的提交哈希。

我应该在挑选的地方使用重新装订。你应该做一个 rebase --interactive

code>您的设计分支位于生产之上，其中：

• 您可以重新排序您的提交，从您需要的生产


• 然后，您可以将生产合并到您希望合并的设计的最后一个提交中（快进）

 
 -x  -  x  -  x1  -  x  -  x2（设计）
 \ 
 p  -  p（生产）
 

需要将x1和x2包含在制作中：

  git checkout design 
 git rebase --interactive production 
 
 -x 
 \ 
 p  -  p（production）
 \ 
 x1'-x2' -  x' -  x'（design）
  

然后：

  git checkout制作
 git合并x2'
 -x 
 \ 
 p  -  p  -  x1' -  x2'（生产）
 \ 
 x' -  x'（设计）
  

允许您：

• 对设计提交进行重新排序 / li>
  
• 包括生产中的第一批


• 允许从设计到生产的后续合并成为快速合并。

---

Lakshman Prasad 补充说：

我大部分时间在一天结束时推送更改。所以并没有太大的帮助。对于推送的主分支，你的答案会如何变化

我会这样做，但是只为操作创建一个专用分支：

  git checkout master 
 git checkout -b master-private 
  

 
 -x  -  x  -  x1  -  x  -  x2（master，master-private）
 \\ \\ 
 p  -  p（生产）
 

，然后rebase，这次与私人分支（即一个分支不会推）。

  git rebase  - 交互式制作
 
 -x  -  x -  x1  -  x  -  x2（master）
 \ 
 p  -  p（production）
 \ 
 x1'-x2' -  x' - x'（master-private）
  

然后：

  git checkout production 
 git merge x2'
 
 -x  -  x  -  x1  -  x  -  x2（master）
 
 p  -  p  -  x1' -  x2'（production）
 \ 
 x' -  x'（master-p ）
  

master 不会受益于（更合理的顺序），但至少你可以随时推送 master 。

并且 production 仍然可以包含它所需的内容。

如果后续对 master 的提交具有同样的问题（有些需要被包括在 production 中，其他的将在以后），我会：

• 删除 master-private （我们并不真正关心那些x'，来自master的x提交副本）


• 在master的顶部创建一个 master-private 分支
  
• 重新执行 rebase --interactive ，并带有一个粗糙的冲突解决策略（除了 master-private 分支的第一次提交之外，因为那些需要集成到 b
  
  $ x
  
  
  
  
  
  $ b $ -x1 - x - x2 - x - x3 - x（主）
  \
  p - p - x1' - x2' - x3'（production）
  | \
  | x'' - x''（主 - 私人）
  \
  x'.. x'（来自第一个主 - 私人的旧x）
  

  
  

  The following is a scenario I commonly face:

  You have a set of commits on master or design, that I want to put on top of production branch.

  I tend to create a new branch with the base as production cherry-pick these commits on it and merge it to production

  Then when I merge master to production, I face merge conflicts because even tho the changes are same, but are registered as a different commit because of cherry-pick.

  I have found some workarounds to deal with this, all of which are laborious and can be termed "hacks".

  Altho' I haven't done too much rebasing, I believe that too creates a new commit hash.

  Should I be using rebasing where I am cherrypicking. What other advantages does that have over this.

  解决方案

  You should make a rebase --interactive your design branch on top of production, where:

  • you can reorder your commits, starting with the ones you need in production
  • you can then merge production to the last commit of design you want to incorporate (fast forward)

      -x--x--x1--x--x2 (design)
        \
         p--p (production)
  

  With x1 and x2 needing to be included in production:

  git checkout design
  git rebase --interactive production
  
  -x
    \
     p--p (production)
         \ 
          x1'-x2'--x'--x' (design)
  

  Then:

  git checkout production
  git merge x2'
  -x
    \
     p--p--x1'--x2' (production)
                  \
                   x'--x' (design)
  

  That allows you:

  • to validate current design commits against the production commits (durung the rebase)
  • reorder the design commits
  • include the first ones in production
  • allows subsequent merges from design to production to be a fast-forward one.

  ---

  Lakshman Prasad adds:

  I push the changes at the end of the day most of the time. So doesn't really help that much. How would your answer change for the pushed master branch

  I would do the same, but with a private branch created just for the operation:

  git checkout master
  git checkout -b master-private
  

      -x--x--x1--x--x2 (master, master-private)
        \
         p--p (production)
  

  , then the rebase, this time with the private branch (i.e. a branch you won't ever push).

  git rebase --interactive production
  
  -x--x--x1--x--x2 (master)
    \
     p--p (production)
         \ 
          x1'-x2'--x'--x' (master-private)
  

  Then:

  git checkout production
  git merge x2'
  
  -x--x--x1--x--x2 (master)
    \
     p--p--x1'--x2' (production)
                  \
                   x'--x' (master-private)
  

  master won't benefit from the commit reordering (with a more logical order), but at least you can push master whenever you want.

  And production can still include exactly what it needs.
  If subsequent commits to master have the same issue (some need to be included to production, other will later), I would:

  • delete master-private (we don't really care about those x', copy of x commits from master)
  • make a master-private branch on top of master
  • re-do the rebase --interactive, with a crude conflict resolution tactic (except for the first commits of that master-private branch, since those ones need to be integrated in the production branch)

      -x--x--x1--x--x2--x--x3--x (master)
        \
         p--p--x1'--x2'--x3' (production)
                     |     \
                     |      x''--x'' (master-private)
                      \
                       x'..x' (old x' from the first master-private)
  

  这篇关于Cherrypicking与Rebasing的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！