重基分支的git同步

我最近有一个关于多计算机git开发设置的讨论，我在那里得到的解决方案确实解决了我在

master

分支上的问题，但没有基于master的分支

以下是我当前的设置：

A--B--C--D  master
          \
           E--F--G--H  BUG_37

BUG_37

是一个分支，它正在为系统中的功能请求开发一个可选跟踪BUG的修复程序，最终将合并到主线中，但暂时是独立的。存储库处于这种状态，一台机器，我对

master

分支做了一些更改：

A--B--C--D--I--J--K  master
          \
           E--F--G--H  BUG_37

然后，我将

BUG_37

分支重新设置到

master

，以确保它作为最新更改的增强：

A--B--C--D--I--J--K  master
                   \
                    E1--F1--G1--H1  BUG_37

比如说，在重新基础最终确定之前，需要手动修复一些冲突。如果我将这些更改推送到一个远程存储库，现在希望将这些更改拉到另一个仍具有原始设置的开发系统上，那么最好的方法是什么

git pull--rebase

将再次运行rebase，我必须手动处理我第一次遇到的冲突，对吗？如果我在再次处理冲突时犯了一个小错误，使得E1-H1在这个新系统中略有不同，我将使存储库更加不同步

---

如何使本地存储库处于原始状态，远程存储库处于第三种状态，并更新本地存储库以与远程存储库完全匹配（删除更改E-H并将

BUG_37

的头部移动到新位置）？

删除分支，然后从远程存储库中拉出两个分支

git branch -D BUG_37
git pull origin master
git pull origin BUG_37:BUG_37

如果您不想在确保其正常工作之前删除本地BUG_37分支，请将远程分支拉入另一个本地分支：

git pull origin BUG_37:NEW_BUG_37

---

我不会在已经共享的分支上重新设置基础。虽然它会产生最干净的历史记录，但它会改变

BUG_37

中所有提交的哈希值。因此，在目标机器上，您需要完全删除

BUG_37

，然后再次拉取它。这可以做一次或两次，但作为一个常规的工作流程，这并不好

---

将

master

合并到

BUG_37

中会容易得多；然后，合并提交（您在其中修复了冲突）可以推送到其他机器上，而不需要删除分支。

我遵循相同的工作流程，基本上是在笔记本电脑和台式机之间切换。我将我的主要回购协议保存在台式机上，笔记本电脑克隆了台式机的回购协议。最终它们会失去同步，因为我想在更新

master

之后重新设置主题分支的基础

简单的答案是，不要使用git，而是使用

rsync

保持回购同步。如果你知道只有你一个人在做这件事，那么这是有道理的

嗯，我也不是那种解决方案的超级粉丝。所以，这可能有点“干净”。在笔记本电脑上，从桌面回购中提取重定基础的分支时：

git co topic
git fetch origin/topic
git reset --hard origin/topic

这将抛出任何不在桌面回购上的提交，因此请确保您确实希望这样做

---

此外，您可能只需

git pull

笔记本电脑的

master

分支，因为它应该总是快进的，因为您可能不需要重新设置它的基址。不过，我认为重新设置主题分支的基础是有意义的，否则在最后尝试将其合并回master是一件痛苦的事情。

我刚刚尝试过它，使用

git pull——当从重新设置基础的分支进行拉取时，重新设置基础是有效的。如果没有
--rebase
标志，提交将被复制，但是使用
--rebase
则提交不会被复制