在冲突时，GitHub for Windows让我进入“rebasing”州，如何从那里去？ [英] On conflict, GitHub for Windows puts me in "rebasing" state, how to go from there?

问题描述

我最近开始使用 GitHub for Windows 。

我刚刚得到冲突。在命令行上，我会知道如何处理这个问题，但是GitHub for Windows选择将我置于我不熟悉的状态：

  C：\ Users \w\Documents\GitHub\CmisSync [（6026d18 ...）| REBASE +0〜1 -0！1 | +0〜0 -0 1]> git status 
＃目前没有任何分支。 
＃您目前正在重组。 
＃（修正冲突，然后运行git rebase -continue）
＃（使用git rebase --skip跳过这个补丁）
＃（使用git rebase  - abort检出原来的分支）
＃
＃要提交的更改：
＃（使用git reset HEAD< file> ...以取消存储）
 ... 
  

我修正了冲突，提交了这些文件，但是当我运行 git push 我被告知：

 致命：您当前不在分支上。 
现在使用
 
 git push origin HEAD：<远程分支名称> 
  

将我的合并提交给远程主服务器的建议方法是什么？

我怀疑 git push origin HEAD：master 会实现这一点。

解决方案

正如我们在 Simon Boudrias 所说的那样，如果您不确定在rebase期间所做的工作，最好的办法是使用 git rebase --abort 。正如动词所说，它会中止当前的rebase，并将您的存储库和工作副本留在与rebase开始之前相同的状态。

之后，您应该做你做过的任何事情，从而开始重建过程（我不认为你说过那是什么，但也不认为它真的很重要）。肯定rebase会重新开始，这里是你的原始问题开始被回答。

正如状态输出说，你似乎有冲突。你应该解决它们（我通常使用 git status --short 加上 git mergetool 以<$ c $解决它们c> meld ），然后 git add 文件。当状态正常时（比如说，每一个必须被提交的文件都被添加了，没有冲突），你应该 git rebase --continue 而不是 git commit 。

这个想法是， git rebase 应用了一组提交在给定的提交之上。我真的不知道什么是提交什么，但考虑到这一点很重要。请记住，可能会显示多个冲突，因为提交会逐个应用。使用 git log 来查看上次提交的应用是什么，我认为您的 .git / 目录中，并提交当前正在提交的提交消息。

这是一个常见的新手错误（我们都在那里:)）试图包含更改在冲突解决期间的文件中，不知道（或遗忘）它们将被后一个提交应用。

因此，希望解决一些冲突后，添加文件和 git rebase --continue 它们，你应该到达一个快乐的函数库，并且你将能够 git push 从那里开始。

最后，但并非最不重要的一点是：在所有rebase之后，使用 git log 检查你是否没有修改任何公开提交。假设你的新分支包含远程的HEAD提交。重新激活功能强大且非常危险。你不想重新公开承诺 - 这可能是你不想面对的唯一git痛苦：）

I recently started using GitHub for Windows.

I just got a conflict. On command line I would know how to handle this, but GitHub for Windows choosed to put me in a state I am not familiar with:

C:\Users\w\Documents\GitHub\CmisSync [(6026d18...)|REBASE +0 ~1 -0 !1 | +0 ~0 -0 !1]> git status
# Not currently on any branch.
# You are currently rebasing.
#   (fix conflicts and then run "git rebase --continue")
#   (use "git rebase --skip" to skip this patch)
#   (use "git rebase --abort" to check out the original branch)
#
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
...

I fixed the conflict, committed the files, but when I run git push I am told:

fatal: You are not currently on a branch.
To push the history leading to the current (detached HEAD) state now, use

    git push origin HEAD:<name-of-remote-branch>

What is the recommended way to get my merging commits to the remote master?
I doubt git push origin HEAD:master will achieve this.

解决方案

As we where saying with Simon Boudrias, if you don't really know what you've done during a rebase, the best thing to start off is with a git rebase --abort. As the verb says, it aborts the current rebase, and leaves you with your repository and working copy in the same state it was before the rebase started.

After that, you should do whatever you've done that started the rebase process (I don't think you said what it was, but don't think it's really important, either). Surely the rebase will start again, and here is where your original question begins to be answered.

As the status output says, you seem to have conflicts. You should resolve them (I usually use git status --short plus git mergetool to resolve them with meld), then git add the files. When status is OK (say, every file that would have to be commited is added, with no conflicts), you should git rebase --continue instead of git commit.

The idea is that git rebase applies a group of commits on top of a given commit. I don't really know what commits are being applied on top of what, but it's important to have that in mind. Keep in mind that there can show multiple conflicts, because commits apply one by one. Use git log to see what was the last commit applied, and I think there has to be a file in your .git/ directory with the commit message of the commit that's currently being applied.

It's a commmon newbie error (we've all been there :)) to try to include changes in the files during the conflict resolution without knowing (or forgetting) they were going to be applied by a latter commit.

So, hopefully, after resolving some conflicts, adding the files and git rebase --continueing them, you should arrive to a happy functional repository, and you'll be able to git push from there on.

Lastly, but not least important: after all the rebase stuff, use git log to check you're not modifying any public commit. Say, that your new branch contains the remote's HEAD commit. Rebasing is powerful and very dangerous. You don't want to rebase a public commit - it's maybe the only git pain you don't want to face :)

这篇关于在冲突时，GitHub for Windows让我进入“rebasing”州，如何从那里去？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！