Git合并分支https://bitbucket.org/xxx/yyy的'主' [英] Git Merge branch 'master' of https://bitbucket.org/xxx/yyy
问题描述
- User1更改a.java并将其推送到远程服务器。
- User2对b.java进行了更改。他不能马上推（SVN的偏差，但没关系）。他需要先从远程服务器拉出，然后将其更改推送到远程服务器。这将显示为一个单独的合并提交，并已在这里在stackoverflow本身美丽地解释
- 现在是有趣的部分。如果我们推断这是多个文件，那么与User2更改的其中一个文件可能会发生冲突。这一次，git无法进行自动提交。 User2将必须解决冲突，然后进行合并。
由于没有进行更改的用户许多文件会怀疑将它们作为此合并提交的一部分提交（特别是在SVN背景下）。如果此用户现在只提交他解决冲突并推送到远程的文件，则Git会停止提供他未推送的最新版本的文件。这带来了我在团队的其他方面失去了工作的感觉。
在这个漫长的故事之后，我的问题是，为什么它会这样做？为什么GIT不应该保留其他文件的最新版本？作为自动合并的一部分，git是否应该知道用户没有提交所有带给用户机器的文件？我们可以避免犯这个错误吗？
首先让我澄清一下 git pull 在本地提交未触及的文件中不会导致合并冲突。所以用户只需要处理他真正触及的文件。
如果这些合并提交对您来说是个问题，那么您应该考虑切换您的工作流程。与git进行交互的方式并未陷入困境，并且已建立的工作流程存在很大差异。例如， PostgreSQL项目完全可以在没有任何合并提交的情况下使用git。另一方面，有一个工作流程，它以有意义的方式使用合并提交。。为了获得类似于SVN工作流的行为，将 - rebase 传递给 git pull ，但在此之前，请仔细阅读 man git-rebase 以了解其含义。或者，您可以在提交之前使用 git stash 来提取远程更改，但这些选项中的任何一个都会将冲突解决步骤置于不同的位置。
检查你的最后一个问题：Git将一个工作树视为你项目的快照。如果它将较旧的文件与较旧的文件混合在一起，则不同的文件将具有不同的版本，这是与git不同的概念。如果你想要这样的功能，你需要寻找CVS（没有玩笑）。这里有一个权衡：任何版本控制系统都必须做出能够跟踪文件移动或能够跟踪不同版本的不同文件的决定。 Git选择了前者。
We have come to git after using SVN for years and at times, I must admit, it is confusing. Take the following example -
- User1 makes a change to a.java and pushes to the remote server.
- User2 makes a change to b.java. He can't push straight away (a deviation from SVN but that is OK). He needs to first pull from remote server, and then push his change to the remote server. This would be shown as a separate merge commit and has been beautifully explained in here on stackoverflow itself
- Now is the interesting part. If we extrapolate this to multiple files, there is a possibility of a conflict with one of those changed by User2. This time, git can't make an auto-commit. User2 would have to resolve the conflicts and then commit this merge.
This is confusing since the user who hasn't made changes to so many files would be skeptical about committing them as part of this merge commit (especially with the SVN background). If this user now just commits the files which he resolved the conflicts for and pushes to the remote, Git stops giving the latest versions of the files that he didn't push. This brings the perception of I lost my work in the rest of the team.
My question after this long story is, why does it do so? Why shouldn't GIT keep the other files at their latest revision? Should git know that the user is not committing all the files that it brought to the user's machine as part of this auto-merge? Could there be a mechanism by which we can avoid making this mistake?
First let me clarify that a git pull cannot cause a merge conflict in files that were not touched by a local commit. So a user will only ever have to deal with files he actually touched.
If these merge commits are a problem to you, you should consider switching your work flow. The way to interact with git is not set into stone and there are large differences in established work flows. For instance the PostgreSQL project works with git entirely without any merge commits. On the other hand there is a workflow that uses merge commits in a meaningful way. To obtain a behaviour that resembles the SVN workflow a bit, pass --rebase to git pull, but before doing so, read man git-rebase carefully to understand the implications. Alternatively you can use git stash to pull remote changes before committing, but any of these options just places the conflict resolution step in a different spot.
To examine your last question: Git treats a working tree as a snapshot of your project. If it were mixing newer files with older files, different files would have different versions, a concept that is foreign to git. If you want such a feature, you need to look for e.g. CVS (no joke). There is a tradeoff being made here: Any version control system has to make the decision of either being able to track file moves or being able to track different files in different versions. Git chose the former.
这篇关于Git合并分支https://bitbucket.org/xxx/yyy的'主'的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
