每个用户的GIT壁球

我见过的所有例子都涉及到只有一个提交者的分支。我试图实现的是自动git rebase -i，对于给定的分支，给定用户所做的所有提交将被压缩在一起。每个用户的GIT壁球

因此，如果3个人在分支上工作。当分支与主人合并时，我们在历史中只会看到3次提交..每个用户一个提交。与扭曲的用户一起的一种rebase + squash。

希望我自己清楚..; -/

任何指针会有所帮助，

真诚，

来源

2011-08-24 Olivier Refalo

你需要仔细考虑这个mre。你只想压缩同一用户的连续提交，否则如果你有一个提交命令（与作者A和B）A，B，A影响你压缩到AA，B的相同文件，你可以得到不同的结果。 – shelhamer

这是一个很好的观点。我希望这个过程（我正在寻找）会产生冲突来解决这个问题。 –

在很多情况下，一个人会产生冲突，但有一些微妙的非冲突性的溃烂，你也可以跑进去。 Rebase是一个非常有效的工具，但它不是很神奇（还）。 – shelhamer

我要试图说服你，你根本就没有原因有四做到这一点：

你正在抛弃历史。
服务器上的历史记录与所有提交者的历史记录不同，因为您正在进行重新推送后推送。所有提交者必须在每次执行此操作时处理共享主节点的非快速合并的麻烦。
您几乎肯定会通过将多个提交合并为一个“不抛弃历史记录”的必然结果来创建非原子提交。原子提交的重点是让历史易于理解，轻松识别回归的原因，甚至可以通过樱桃选择实现代码重用（也可能是我无法想象的其他很好的理由）。
正如我在评论中提到的，您可以更改更改并最终得到不是每个用户提交的总和的产品。考虑提交者A和B的情况，当他们的贡献像A，B，AA那样交织并且你挤压到AAA，B或B，AAA（其中AAA是南瓜）时，修改相同文件（尤其是相同文件中的相同内容）结果）。这会让你很难受。

来源

2011-08-24 21:24:40 shelhamer

＃4，肯定是一个问题。＃1不是一个问题，取决于上下文。＃2完全有道理..＃3好吧，我认为我相信！该死的，虽然我可以通过这样一个过程让我的生活更轻松;它显然会带来更多的问题，而不是利益。加上我不能使用pull --rebase b/c我失去了谁做了什么。想想我现在必须忍受一段肮脏的历史。 –

我不建议这样做，因为你会扔掉的历史。另外，做rebase的用户应该这样做，而不是你在中央存储库上，因为如果服务器修改客户端仍然有的东西，你将进入分歧历史。

至于重订基期，你可以尝试破解的东西在一起，就像这样（不实际工作，但可以帮忙）

# assuming you are on master 
git -i rebase origin/master 
//find out what file is opened by git when doing the interactive rebase 
regex search & replace pick with squash 
close file .. somehow continue git process (kill -9 the text editor maybe?)

通过阅读手册页我找不到任何方式进行合并的一切..你可以去更深，乱用Git的内部命令..但是这超出了我的知识..

来源

2011-08-24 21:10:59 Tigraine

谢谢，我现在确信这是一个非常糟糕的主意 –

每个用户的GIT壁球

回答

相关问题