我开始从NASM源文件重写一些 Perl 程序。我已经对我自己的工作副本做了一些提交，我想知道我是否应该做而不是做git pull，如果我应该做git rebase。
我几乎已经决定我应该做一个git rebase，但我不知道如何重新设计我的存储库以达到这种效果，或者即使它是可能的。
问问题
8473 次
5 回答
6
这是可能的，Git Magic教程将解释如何做到这一点。但是如果其他人看到了你的分支，那就是不安全的。即使没有其他人看到您的分支，我也敦促您重新考虑。
为什么要有rebase？为什么不只是拉/合并？
变基的目的是重写历史，以便您的存储库反映您认为软件应该发展的方式，而不是它实际发展的方式。这在什么时候很重要？当您是分布式开发团队的初级成员，并且您没有提交权限时，您所能做的就是将补丁提交给看门人并希望它们被接受。为了最大限度地提高被接受的机会，您希望重写历史记录以使您的补丁尽可能干净和清晰。开发模式听起来很熟悉吗？
Manoj Srivastava对 rebase-vs-merge 进行了相当周到的分析。
于 2009-05-10T20:28:52.917 回答
2
我过去使用以下方法取得了成功：
对于这种方法，我添加了以下别名：
up = pull --rebase origin
- 将您的主分支分支到“dev”之类的东西
- 在开发中工作
- 当您完成添加和提交更改时
- 起床大师
- 切换到主
- git 合并开发
- git 推送
从远程仓库拉取更改时：
- 切换到主
- 起床
- 切换到开发
- 起床大师
YMMV
于 2009-05-10T18:31:25.853 回答
2
- 确保当前提交是合并提交：
git log - 首先，我们将 master 重新设置为上一个提交（合并之前的那个）：
git reset HEAD^- HEAD^表示：'HEAD 引用的提交之前的提交'
- 现在你可以做一个正常的变基：git rebase origin/master
下次我建议做 agit fetch然后 rebase 作为第 3 步。
我建议为您当前的 git 存储库创建一个小 tarball，以防变基出错。当您感到更有信心时，您会较少这样做（通常您可以使用 git 修复几乎所有内容，但有时 tarball 更快）。
于 2009-05-10T20:57:13.290 回答
0
您应该能够通过像这样更改分支来撤消上一次合并：
git branch your-changes <reflog of "Reworked test files...">
git branch -f master remotes/origin/master
之后，您可以尝试变基。
于 2009-05-10T20:50:12.553 回答
-1
作为 Dustin 回复的后续，它应该是“git config --global branch.master.rebase true”。
于 2009-08-26T18:53:53.763 回答