当Git或TortoiseGit存在冲突时，提交/推送的正确方法是什么？ [英] What is the right way to commit/push when there are conflicts in Git or TortoiseGit?

问题描述

我们正在使用git和合并工作流程。我们有很多git新手（包括
me），他们有SVN或CVS背景，或者根本没有版本控制背景
。

这是我们遇到的一个常见问题。许多团队成员使用TortoiseGit为
。由于并发的
更改 - 或者因为它们不是每天 pull ，所以合并冲突发生得相当频繁。一个用户会做一个拉，有
a合并冲突，解决合并冲突，然后看文件
的列表被提交回来。

<但是然后文件列表显示了很多文件，尽管只有几个文件涉及合并冲突
。在提交时，他没有选中所有其他文件
更改为他没有参与，提交结果并推送
提交。

结果：所有其他人在这个用户的
之前的提交和这个提交之间完成的所有提交丢失！ 首先，为什么Git或TortoiseGit是否只显示用户拥有
的文件列表中没有任何内容？其次，在这个
场景中做什么是正确的事情 - 从TortoiseGit透视图的任何答案都会有帮助。

解决方案

<你原来的问题是错误的。你的工作流程被破坏了，所以你得到了很多冲突。你应该解决这个问题。在发生合并冲突的情况下，树的状态是传入的更改会自动分阶段进行，需要手动干预的更改将位于工作环境中。对于每个未暂存的文件，用户需要解决冲突并进行更改。一切准备就绪后，您可以提交整个更改集。这将是一个合并提交，所以它不应该包含新的功能或逻辑。如果您在此期间卸载文件，则基本上会使用本地副本中的版本来覆盖传入的更改。

至于更深层次的问题工作流程，这听起来像人们直接承诺掌握。这是你的主要问题。没有人应该直接向你的主干提交。相反，人们应该开始在一个新的分支工作。即使更改是针对一个文件的，生产性的git工作流程也非常依赖分支。一旦分支中的工作完成，您可以将分支合并到主分支中，或将主合并到分支中。您也可以重新设置您的分支，以避免多次合并提交，尽管我发现这是不必要的。

我的工作流程如下所示：

p>

 ＃git checkout master 
＃git pull 
＃git branch newbranch 
。 
。 
工作
。 
＃git merge master<！ - 可选择从主服务器获取更改 - > 
 
。 
。 
＃git add< files> 
＃git commit 
＃git checkout master 
＃git merge newbranch 
  

We are using git and the merge workflow. We have lot of git newbies (including me) who either have an SVN or CVS background, or no version control background at all.

Here is a frequent issue we are running into. Many of the team members were using TortoiseGit. Merge conflicts happened fairly often because of concurrent changes - or since they did not pull every day. One user would do a pull, have a merge conflict, resolve the merge conflict, and then look at the list of files to be committed back.

But then the file list shows a lot of files, though there were merge conflicts involved in only a few files. While committing, he unchecked all the other files changes that he was not involved in, committed the results and pushed the commit.

Result: All the commits by other people that had been done between this user's previous commit and this one were lost!

First, why does Git or TortoiseGit just show a list of files that the user has nothing to do in the list? Second, what is the correct thing to do in this scenario - any answer from a TortoiseGit perspective will be helpful.

解决方案

Your original question is the wrong one. Your workflow is broken so you are getting lots of conflicts. You should fix that. In the case that you do get a merge conflict, the state of the tree is that incoming changes are automatically staged and changes that need manual intervention will be in the working environment. For each un-staged file, users need to resolve conflicts and stage the changes. Once everything is ready you can commit the entire change set. This will be a merge commit so it should not contain new functionality or logic. If you unstage a file during this time, you are essentially over-writing the incoming change with the version that is in your local copy.

As for the deeper problems in your workflow, it sounds like people are committing directly to master. This is your main problem. No one should be committing directly to your trunk. Instead, folks should start working in a fresh branch. Even if the change is for one file, a productive git workflow very much relies on branching. Once the work in the branch is complete, you can merge your branch into master, or merge master into your branch. You can also re-base your branch in order to avoid multiple merge commits, although I have found that to be unnecessary.

I work flow would look like this:

 # git checkout master
 # git pull
 # git branch newbranch
 .
 .
 Do work
 .
 # git merge master     <!-- Optional to pull in changes from master -->

 .
 .
 # git add <files>
 # git commit
 # git checkout master
 # git merge newbranch

这篇关于当Git或TortoiseGit存在冲突时，提交/推送的正确方法是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！