部分合并的Git工作流程？

我有两个分支dev和a。我需要将a功能合并到dev中，但是我的队友已经在一个文件中做了某些功能，但尚未准备好进行合并。如果我只是合并并使用我的解决方案，git会将此文件中的更改标记为无效，而不是稍后允许这些更改合并，如果我尝试重新合并分支，则只需快速转发即可。如果我不解决冲突，git拒绝执行合并。部分合并的Git工作流程？

我的解决方法是创建一个分支放在一旁，抑制破损的特征，然后合并到这个分支中。问题是这个git命令有点复杂，所以我需要专家的帮助。

我想如果可能将这种类型的行为概括为git扩展名，我会调用git-cherrymerge的效果。

的步骤将如下所示：

重播由用户（也许这可以用一些策略被自动化）指定到一个临时分支提交
GIT中过滤器分支，以除去破碎文件
壁球临时分支，加入自动提交消息
合并临时分支到目标分支（这里它是DEV）

我不是filter-branch或rebase的专家，它看起来像我可以相当认真通过滥用他们的历史损坏。

我想我的问题是

将这项工作还是有更好的规范的方法来做到这一点？
我应该以什么顺序执行哪些git命令以避免意外损坏存储库历史记录。

来源

2017-04-09 awiebe

“* git将此文件中的更改标记为无效*”您的意思是“无效”？你的意思是有冲突吗？ – Schwern

@Schwern @Schwern基本上，如果我试图再次向上游合并，则早期历史中存在的那些更改被认为是“不好”的，并且永远不会被自动合并策略“应用”。 – awiebe

不是“坏”或“无效”。您已经告诉git您已合并这些文件并通过告知它如何应用这些更改来处理合并，您忽略了它们。 Git将不会在稍后重试合并，因为该提交已被合并。最好的办法是在合并之前处理这个问题，将工作分成两个不同的分支，一个可以合并，另一个不能。 –

你基本上已经有了正确的想法，你想把一个分支变成两个分支：一个分支，准备好要去的东西，还有一个分支就是不完整的变化。例如，一个分支可能包含一堆重构和错误修复，其中包含不完整的特征。

A - B - C - D [master] 
     \ 
      R1 - B1 - F1 - R2 - B2 - F2 [feature]

R1和R2是重构更改。 B1和B2是bug修改。 F1和F2是不完整的功能。你想要的是：

A - B - C - D [master] 
     \ 
      R1 - B1 - R2 - B2 [fixes] 
          \ 
          F1 - F2 [feature]

有两个步骤，重新排序提交并声明新的分支。使用git rebase -i对提交进行重新排序。这将出现如下所示：

pick f37beee Refactor 1 
pick 7f238ea Bugfix 1 
pick d100dd2 Feature 1 
pick aa1124b Refactor 2 
pick beadbee Bugfix 2 
pick 0123abc Feature 2

然后，您会在编辑器中重新排序它们。

pick f37beee Refactor 1 
pick 7f238ea Bugfix 1 
pick aa1124b Refactor 2 
pick beadbee Bugfix 2 
pick d100dd2 Feature 1 
pick 0123abc Feature 2

Git将通过以新顺序应用这些修补程序来重建分支。您可能需要解决冲突。有关更多信息，请参见Rewriting History in Pro Git。

然后你需要声明一个新的分支。这只是git branch fixes beadbee宣布从最后一次提交你想要的修复分支。

通常将修复程序修复到主设备，并在主设备上重新绑定功能。

但是通常情况下，提交并没有这么整齐地分离出来。如果您有一个包含多个更改的提交，并且您只需要其中一些更改，则可以将其更改为多个提交。

与以前一样使用git rebase -i，但将您想要分割的提交设置为edit而不是pick。

pick f37beee Refactor 1 
pick 7f238ea Bugfix 1 
pick aa1124b Refactor 2 
pick beadbee Bugfix 2 
edit beacd4a Messy commit 
pick d100dd2 Feature 1 
pick 0123abc Feature 2

然后Git将停止该提交，并允许您编辑它如何你喜欢。使用git add -p仅向分段区域（在其中创建提交的位置）添加更改的部分，并且仅将部分更改添加到git commit。直到每次更改都有自己的提交为止。例如，它可能会更改方法的名称，修复错误，但也会更改不相关的方法。你可以将它们分成三个提交：一个更改名称，一个更正错误，一个更改不相关的方法。

你可以在Interactive Staging了解更多。

我不是在过滤分支相当的专家或重订，它看起来像我可以很严重损坏历史被滥用武器。

是的，但你可以扭转这种错误，并没有什么会影响到其他人，除非你git push它。 Git不会重写历史，它会写下新的历史并一直假装它是这样。旧的历史仍然存在，有一段时间，你可以使用诸如ORIG_HEAD和git reflog之类的东西回到它。

最坏的情况下，delete your local repository and clone a new one。

来源

2017-04-09 23:28:38 Schwern

我标记为Schwern的答案是正确的，因为它是最一般的情况 - 但值得注意的是，对于我的情况，有一个非常简单的策略如下。因为无论如何我打算压缩这些变化，这意味着程序可以在一次提交中完成。仍然有必要创建一个新的分支，但可以使用软重置快速完成。如果只有一个小，你想推迟变化的易于管理的号码，我会推荐这一战略

结帐A
分公司的负责人一个临时党支部
Git的软复位到的A
提交更改不包括那些“根”你不想
合并为develop

来源

2017-04-10 21:43:34 awiebe

部分合并的Git工作流程？

回答

相关问题