我已经分叉了一个遵循所谓的"git flow"的存储库,并且必须开发/主/工厂分支.我将从现在开始引用我的fork origin和主存储库作为upstream.
在打开一个问题并与repo维护者谈论/同意一些事情后,我开始研究它.我做的第一件事是创建一个功能分支跟踪(origin/develop).
经过几次临时提交临时丢失临时坏名称后,我创建了一个PR并推送.我想到的想法最终是将我的所有提交压缩到一个,然后提供一个正确的提交名称/描述,以便维护者能够将所有这些合并到上游/开发没有任何问题,我的主要目标是制作对于我和上游维护者来说,整个过程尽可能顺利,一旦合并,我很乐意删除我的本地分支,完成工作,轻松腻......
我天真的想法会如此顺利!
无论如何我都不是一个git专家,而且我认为PR会如此顺利地发展(当你不知道你正在使用的工具时会发生这种情况).在某个时刻,我已经停止了我的公关工作几天,显然上游/发展继续发展并在我的公关前走得很远,我的公关还没有通过测试,整个公关仍未完成未完成的工作.
几天后,我决定回到那个公关,并尝试恢复我的工作,在上游/开发后我看到许多上游提交已经远离我的公关,我真的不知道什么是最好的在那种特殊情况下的选择,我不知道,我仍然不知道合并或变基是否是最佳选择......
由于对合并或变基的可能影响知之甚少,我认为合并不会那么糟糕,一切都有可能最终整理,对吧？好吧,结果,在合并并推送一些更临时的提交后,我的本地历史变得有点乱,我不知道这是否可以以某种方式清理而不会弄乱上游历史.
假设历史看起来像PR = c1-> c2-> c3-> upstream1-> upstream2-> upstream3-> c4-> c5.在那个例子中,c1..c6将是我的本地更改而upstream1..upstream3将从上游提交.
我想整个线程可以通过询问当上游远离你包含多个临时提交的未完成的PR时最好的方法来总结.
就最终结果而言，合并和变基是相同的...但是，就所产生的历史记录以及能够“孤立地”移动工作的容易程度而言，它们是截然不同的...如果你工作，然后合并，然后更多工作...然后合并...然后更多工作等等，很难单独看到构成此功能的所有修订。
所有这一切都是为了说：只需变基即可。应该做什么？转到上游/开发的提示，挑选构成功能工作的真正修订（不合并）...这样，您就清理了分支...将本地功能指针设置到这一点并继续工作...如果在上游/开发上完成了更多工作，则在其之上进行变基。