如何推/拉Git rebase

Question

我想使用git rebase它来干净地合并主分支中的一个功能(在较少的提交中或至少在更改日志的顶部).请注意,我是唯一一个在存储库上工作的人.

在阅读了Git工作流程和rebase vs merge问题之后,我发现它git rebase会非常好,就像Micah一样,我想重新git push定义更改只是因为我正在从不同的地方工作(例如:我的笔记本,我的家,另一台PC. ..)

所以这里有两个解决方案(对于双向难看的合并):

1. 使用git push -f推送,然后拉动其他机器,但如何在其他机器上干净利落地获得最新版本？
2. 使用merge将主更改合并到功能分支,git push/pull,并且一旦成熟,就执行一个rebase(在一个或多个提交中干净利落)

(2)如下所示:

git co -b feature-a
... change files
git push origin feature-a
... moving to another PC
git pull origin feature-a
... change files
git merge master
... change files (not the "special rebase")
git rebase master
git co master
git merge feature-a
git branch -d feature-a
git push origin :feature-a

您认为哪种解决方案有效？到目前为止,我还没有尝试过其中任何一种(主要是因为害怕让我的日志变得更加混乱).

Answer 1

我总是确保从我离开的任何机器上提交并推送(-f)所有内容.

当我到达其他机器时:

 git fetch -v
 git checkout mybranch # Already checked out with old HEAD
 git reset --hard origin/mybranch

这很有效,因为我知道在我离开之前,不同计算机上的其他"我"一直在提交和推送(因此我到达的机器上没有未按下的更改)

Answer 2

请记住,git rebase重播更改并创建新提交.通过重新定位和强制推动整个地方,你将违背工具的粒度.请注意文档中的"从上游rebase恢复"部分的git rebase开头(更加强调):

重新定位(或任何其他形式的重写)其他人基于其工作的分支是一个坏主意:它下游的任何人都被迫手动修复其历史记录.本节介绍如何从下游的角度进行修复.然而,真正的解决方法是首先避免重新定位上游.

即使您是唯一的开发人员,在其他克隆中工作时,您仍然会成为其他人(从一个回购的角度来看).如您所见,这个工作流程很麻烦.

让你的变化在分支中烹饪.当分支准备好进入黄金时段时,然后重新绑定,将其合并到主服务器中,并删除其主题分支.如果你让分支的寿命缩短,范围缩小,你的生活将变得最简单.