我和一位同事正在使用git和一个远程源代码库。我们都提交本地,然后推送到源。当我们工作时,自然会有一些分歧。
一旦到了推送到原点的时候,我怀疑我们可以合并本地,然后推送到原点。我希望在没有描述合并的情况下得到一个相当直接的版本历史。
从相当复杂的版本地铁地图和不断重复的合并分支‘主’消息判断,我猜我们做了一些不太正确的事情。
我有一种感觉,这个问题以前已经在这里得到了回答,但我不能完全理解我收集的信息。
发布于 2012-10-15 20:55:56
我想你是在找git rebase
。
从“保留真实历史”的角度来看,记录在您的历史中的每个合并都是必需的。您的分支在这一点上出现了分歧,随后被合并(请注意,两个分支的提交都是唯一的,因此快进是不可能的。
如果你改变基址,当前的提示(包括来自你同事的更改)将成为新的分支点,除非他们在两者之间推入,否则您的更改可以通过快进应用,给人一种线性开发的印象(但具有非单调的时间戳)。
发布于 2012-10-15 21:02:15
我们有一个类似的案例。虽然我们使用中央主存储库,但我们经常让单个开发人员生成合并分支“master”消息。我们的解决方案是让开发人员在从远程主存储库中提取数据时执行git pull --rebase
。
发布于 2020-01-17 23:04:48
你做的一切都是对的。你在并发开发,你在不时地集成你的同级的变化,而git
忠实地记录了这段历史。
虽然您可以通过重新基址来“避免”合并提交,但通常更好的做法是坚持mergy历史:每当您对提交进行重新基址时,您实际上是在创建一个新的提交,它会告诉您关于它是如何产生的谎言。而且,虽然这些谎言通常是良性的,但它们可能会在以后造成麻烦。如果您跳过在每次重新基址提交时重新运行测试套件,这一点尤其正确。
我认为,“创建线性历史”的整个想法有点被误导了。你不会真的想要一个线性的历史。你想要一个真实的历史,每一次提交都经过了实际的测试。因为这样可以让您稍后运行git bisect
并获得有意义的结果。
不要改变你的习惯。他们本来就很好。在未来,你可能会对他们心存感激。
https://stackoverflow.com/questions/12895980
复制相似问题