在C#项目存储库中,
我从master分支创建了一个功能分支,然后在功能分支上做了一些工作。那时,我还没有git add
或git commit
我的工作。
我试着看看我的改变的C#项目是否可以编译,但它不能。然后我意识到一些同事已经更改了主分支,所以我检查了主分支并运行git pull
来更新master,然后将master合并到我的功能分支,我手动解决了一些合并冲突。然后可以编译C#项目。此时,未分阶段的更改包括我的工作和手动更改以解决合并冲突。
然后我继续在我的功能分支上工作。完成后,我运行了git add
和git commit
来创建一个新的提交,其中包含我在功能分支上的所有工作以及我的更改以解决合并冲突。然后我将我的功能分支推送到GitHub,创建了一个拉取请求,将其合并到GitHub上的master,并指派一个协作者来检查拉取请求。
但是,如果我再次遇到类似的情况(即在处理功能分支的过程中,发现我无法编译我的项目而没有拉动主人并将其合并到功能分支),我不确定如何将我的工作的合并和更改更改分成不同的提交。 那我该怎么办?
感谢。
答案 0 :(得分:1)
这个答案分为两部分:1。如何解决手头的情况,以及2.如何避免将来出现同样的问题。这两部分需要完全不同的方法。
解决手头的情况。
问题是,您发布了一个提交,其中包含已包含在其他提交中的更改。这很糟糕,因为它会在以后产生合并冲突。
要解决此问题,您需要从右侧基础提交重新创建功能分支。您可以使用以下命令执行此操作:
git checkout feature-broken
# git status to ensure that the working directory and index are clean
git reset --mixed <the-commit-you-actually-want-to-base-your-work-on>
# git status and git diff, to see what changes your feature branch actually wanted to introduce
git checkout -b feature-repaired
git add ...
git commit ...
在此序列中,您将获取工作目录的状态,因为您的损坏的功能分支将其置于其中,并创建具有完全相同内容但具有不同父提交的不同提交。这就是您需要的所有修复(当然,除了缩回feature-broken
之外)。
我不确定,你确实想要使用哪个基本提交。您的问题听起来好像您之前没有在已损坏的功能分支上提交的工作,在这种情况下,要使用的基本提交将是master
。如果您已经在已损坏的功能分支上提交了工作,那么您将创建一个合并提交,通过冲突解决方案来解决您的更改。在这种情况下,您应首先为先前提交的更改创建一个干净的合并提交,并将git reset --mixed
基于该新提交。
将来如何避免这种情况。
答案是git stash
。在您完成上游更改之前,只需发出git stash
即可完成本地更改。一旦你正确地提交你的工作,只需做一个git stash pop
来获取你的本地更改(修复你遇到的任何合并冲突)。