Question

我在这里陷入了git-funk的困境。我需要自己动手做。

我加入了一个新团队，并创建了一个功能分支：

git checkout -b feature_branch

进行一些更改，然后将其提交/推送到分支。

git commit -am "Changes"
git push origin feature_branch

有人在我的PR上留下了评论，因此我进行了更改，然后签出以掌握分支并对其进行基础调整，然后再次提交/推送到该分支：

// from feature_branch make some changes
git commit -am "New changes"
git checkout master
git checkout feature_branch
git rebase origin/master
git push feature_branch

执行完此操作后，我注意到我的PR（在Github上）拾取了其他人的提交。然后我被告知，这个新团队中的典型方法是结帐以掌握并合并到我的分支机构INSTEAD中。

这是现在的时髦部分-我开始和git reset --hard混为一谈，并从其他人那里选择了我想要的提交。

一切都很好，或者我想。然后我把它推高了，似乎已经从我的PR中删除了其他人的承诺。

我今天早上检查了一下，现在还有很多其他人提交的其他提交。

所以现在我处于这种奇怪的状态。我看一下我的PR，几乎有30个提交（其中6个来自不同的人）。实际的差异（文件已更改）只是我触摸过的文件，这很好，但是历史记录本身看起来很可笑。

清理此问题的最佳方法是什么？一切都建议使用git rebase，但是，建议我不要使用rebase。

不幸的是，我需要保留这个分支。清除并删除除我以外的所有其他提交的最佳方法是什么？只需将其完全重置，然后将更改樱桃选择回分支？

请帮助：|

编辑：这是历史记录的示例：

Commits on Jul 30, 2018
<SOMEONE ELSES>

Commits on Jul 31, 2018
<SOMEONE ELSES>
<MY ORIGINAL COMMIT>
<SOMEONE ELSES>

Commits on Aug 1, 2018
<SOMEONE ELSES>
<MY COMMIT [Merge branch master into my feature branch]>
<MY COMMIT>
<SOMEONE ELSES>
<MY COMMIT>
<MY COMMIT>
<SOMEONE ELSES>
<MY COMMIT>

etc etc

Answer 1

您最好清理的东西可能是使用git rebase -i来基于分支中先前要进行的更改¹，然后再删除所有要清理的东西。从编辑器中的更改列表中删除不需要的更改（仅保留所需的更改）。这将重写更改，使其仅包括您的更改，并使您回到“相对”（相对）状态。

完成此操作后，您就可以按照git flow的建议从主服务器（或任何地方）git merge来

。

¹ _{可能是您最初想从中分支出来的更改，如果您想清除以前已重新建立基础/合并到分支中的所有内容，或者可能稍后再引用。您选择的点越早，可以清理的东西就越多，但也可能需要做更多的工作。}

Answer 2

// from feature_branch make some changes
git commit -am "New changes"
git checkout master
git checkout feature_branch
git rebase origin/master
git push feature_branch
这样做后，我注意到我的PR（在Github上）拾起了别人的提交。

如果您所做的只是基于origin/master的基础，那应该是不可能的。

但是，此序列有点混乱。您永远不会做git fetch，因此origin/master并不是最新的。如果确实发生了变基，则git push feature_branch应该会失败，因为变基无法快速转发。您将不得不使用git push -f feature_branch。

我怀疑您没有向我们展示其他信息出了问题。完整的命令历史记录将对您有所帮助。

使用rebase更新分支的正确顺序是这样。

# Update all your remotes
git fetch

# Rebase your branch on top of origin/master
git checkout feature_branch
git rebase origin/master

# Force push the branch
git push -f

幸运的是，您的旧提交在重新设置基准后不会丢失，它们只是没有连接任何东西。要找到它们，请使用git reflog。每当HEAD（即您当前的结帐）更改时，都会显示该信息。

在reflog中，寻找类似这样的东西...

081abed HEAD@{8}: rebase finished: returning to refs/heads/feature_branch
081abed HEAD@{9}: rebase: the last commit message from your branch
0a5b366 HEAD@{10}: rebase: another commit message
e9c4d18 HEAD@{11}: rebase: the first commit message from your branch
e6780bf HEAD@{13}: rebase: checkout origin/master
0ee63b1 HEAD@{14}: checkout: moving from master to feature_branch

0ee63b1将是您的旧分支提示。 git reset --hard 0ee63b1，并且您撤消了重新设置基准。

还有另一种解释：您是针对错误的分支进行PR的。仔细检查。

Answer 3

清理此问题的最佳方法是什么？一切都建议使用 git rebase，但是，建议我不要使用rebase。

即使团队自己没有使用重新编制工作流，也可能是修复未合并分支的更好方法。只要您确定没有另一个正在使用，并且您知道possible implications 并非如此。

注意：我假设您的遥控器名为起源，并且该分支是在 master 上创建。如果不是这种情况，只需将它们替换为合适的。

在进行任何操作之前，请先保存所有修改（如果有的话）：

git stash save

然后结帐到您的分支机构：

git checkout mybranch

（推荐）使用临时标签按原样备份分支：

git tag mybranch_bkp_rebase

变基

As mentioned，您可以重新定位到创建分支的位置，然后删除其提交与您的分支无关的行。

git rebase -i "$(git merge-base origin/master HEAD)"

这样，分支中剩下的唯一提交将是已经提交的创建分支时在那儿，加上行中的提交没有被删除。

（可选）在检查完所有内容后，您可以根据基准当前的主控：

git rebase origin/master

重置

如果您不想进行基准调整，则可以重置为以前的已知商品州。那可能是您自己分支中的提交，创建于当前母版上：

# Pick one
last_known_good_rev=hash_of_last_good_commit
last_known_good_rev="$(git merge-base origin/master HEAD)"
last_known_good_rev='origin/master'

git reset --hard "$last_known_good_rev"

然后用git log检查可能丢失的提交：

git log --oneline mybranch_bkp_rebase..HEAD

然后cherry-pick个他们：

git cherry-pick hash1 hash2 hash3

Answer 4

如果您的分支上有多个自己的提交，您可以将所有提交变基并将其压缩到最新提交中，这会将您的所有更改放在分支的尖端，这将停止 GitHub拉取在您提交之间发生的所有更改。

从那里你可以强制将 rebase 的分支推送到远程，它应该只显示你新压缩和 rebase 的提交。

重新设置错误后，删除我分支上其他人的提交

4 个答案:

变基

重置