使用 git 提交到同一个分支

committing to the same branch with git

提问by jaras

Let's say that there are two people working on a git branch, they check out at the same time but one of them commits first and then the other commits after. Will the newest commit still be merged with the former commit or can multiple people work on the same branch simultaneously?

假设有两个人在一个 git 分支上工作，他们同时签出，但其中一个先提交，然后另一个提交。最新的提交是否仍会与之前的提交合并，还是可以多人同时在同一个分支上工作？

回答by araqnid

Well, when you clone a git repository (is that what you meant by "check out"?), you're effectively creating a new branch. Git branches are local to each repository, not global. Having said that, you have a protocol for how updates to branches are transmitted between repositories-- when you pull from a remote, by default the remote's "master" branch gets merged into your "master" branch, for instance. And when you push, your "master" branch can be appendedto the remote's master branch. So your master and remote's master ("origin/master", if you will) are different branches, but related by convention.

好吧，当您克隆一个 git 存储库时（这就是您所说的“签出”吗？），您实际上是在创建一个新分支。Git 分支对于每个存储库都是本地的，而不是全局的。话虽如此，您有一个关于如何在存储库之间传输分支更新的协议——例如，当您从远程拉取时，默认情况下远程的“主”分支会合并到您的“主”分支中。当您推送时，您的“主”分支可以附加到远程的主分支。所以你的主人和远程的主人（“origin/master”，如果你愿意的话）是不同的分支，但按照惯例是相关的。

Getting back to the point--- you notice I said your master branch can be appendedwhen you push to a remote. If two people have taken a copy of origin/master and made independent changes (remember this is just like making changes on two branches locally), once one person has pushed their changes, the other's person's changes aren't a simple append onto origin/master any more--- they have to be merged. This can't happen when you push, only when you pull (confusingly, "pull" isn't quite the opposite of "push": "fetch" is the opposite of push- a pull is a fetch followed by a merge (or a rebase)).

回到正题——你注意到我说过当你推送到远程时可以附加你的主分支。如果两个人拿了一份 origin/master 的副本并进行了独立的更改（记住这就像在本地的两个分支上进行更改一样），一旦一个人推送了他们的更改，另一个人的更改就不是简单的附加到 origin/不再掌握 --- 它们必须合并。这不会发生在你推时，只有当你拉时（令人困惑的是，“拉”与“推”并不完全相反：“取”是推的反义词——拉是取，然后是合并（或变基））。

So if you're in this situation, whoever is trying to push their changes first needs to pull back from the updated origin/master, merge or rebase their version of master, and then push. By default you can't remove someone's changes to a branch and replace them with your own: you need to at least do "git push -f" to do that, and the remote repository can have settings or hooks to make it considerably harder.

因此，如果您处于这种情况，那么尝试推送更改的人首先需要从更新的源/主服务器中撤回，合并​​或重新设置他们的主版本，然后再推送。默认情况下，您无法删除某人对分支的更改并将其替换为您自己的：您至少需要执行“git push -f”来执行此操作，并且远程存储库可以具有设置或挂钩以使其变得更加困难。

Or the two of them could cooperate beforehand: one of them pull the other's changes, do the merge, and then push the result. This can be a good thing to do if it's likely the changes are going to overlap or affect each other. Remember the First Law of version control systems: a VCS is not a replacement for communication.

或者他们两个可以事先合作：一个拉另一个的变化，做合并，然后推送结果。如果更改可能会重叠或相互影响，这可能是一件好事。记住版本控制系统的第一定律：VCS 不是通信的替代品。

回答by Dan Moulding

In Git, branches are strictly local. One developer cannot change another developer's remote branches (see note at bottom). However, in the case of a barerepository, you can "push" your changes to it in order to update the remote repository's branches, if your changes will result in a fast-forward.

在 Git 中，分支是严格本地的。一个开发者不能改变另一个开发者的远程分支（见底部注释）。但是，对于裸存储库，如果您的更改会导致快进，您可以将更改“推送”到它以更新远程存储库的分支。

But if two developers are committing to the same remote repository, then only one will be able to fast-forward the remote branch without first bringing their branch back up-to-date.

但是，如果两个开发人员提交到同一个远程存储库，那么只有一个开发人员能够在不首先将他们的分支更新到最新的情况下快进远程分支。

For example, let's say Alice and Bob are both working on the master branch in their local repositories, each cloned from a shared (bare) repository on a server. If Alice finishes her work first, when she pushes her committed changes to the shared bare repository, it will fast-forward the bare repo's master branch.

例如，假设 Alice 和 Bob 都在其本地存储库中的 master 分支上工作，每个分支都是从服务器上的共享（裸）存储库克隆的。如果 Alice 先完成她的工作，当她将提交的更改推送到共享裸存储库时，它将快进裸存储库的主分支。

Now Bob cannot fast-forward the bare repo's master branch without first updating his local branch to include the commits that Alice has added (because the commits he's added are not ancestors of the commits that Alice created).

现在 Bob 不能在没有首先更新他的本地分支以包含 Alice 添加的提交的情况下快进裸仓库的主分支（因为他添加的提交不是 Alice 创建的提交的祖先）。

One way Bob can do this is to pull (or preferably rebase) from the bare repo after Alice has pushed her commits. This will merge Alice's changes into Bob's branch and make it possible for Bob to fast-forward the bare repo's master branch with a push.

Bob 可以做到这一点的一种方法是在 Alice 推送她的提交后从裸仓库中拉取（或最好是变基）。这会将 Alice 的更改合并到 Bob 的分支中，并使 Bob 可以通过推送快进裸仓库的主分支。

Other workflows are possible: Alice and Bob could cooperatively pull from each other directly without using a shared bare repository. There are almost endless possibilities, really. But in general, merging in Git is done by pullingchanges.

其他工作流程也是可能的：Alice 和 Bob 可以直接相互协作，而无需使用共享的裸存储库。几乎有无限的可能性，真的。但一般来说，在 Git 中合并是通过拉取更改来完成的。

[note: it actually is possible to push into non-bare repositories, and thereby update other people's branches, however this often yields unintuitive results, is not considered a typical git workflow, and is generally not encouraged]

[注意：实际上可以推入非裸存储库，从而更新其他人的分支，但这通常会产生不直观的结果，不被认为是典型的 git 工作流程，通常不鼓励]

回答by robinr

A shorter answer is this:

一个简短的答案是这样的：

commit -m "my changes"

Retrieve the shared version

检索共享版本

git fetch sharedrepo

oneof these two to sync your local branch with the other repo

一个这两个与其他回购同步您的本地分支

git merge sharedrepo/sharedbranch
git rebase sharedrepo/sharedbranch

Rebase serializes the history if you do not want a lot of branches in the final history. Both options may force you to solve conflicts before you are done.

如果您不希望最终历史记录中有很多分支，则 Rebase 会序列化历史记录。这两种选择都可能迫使您在完成之前解决冲突。

After merge/rebase and resolving conflicts you push back to repo

合并/变基并解决冲突后，您推回回购

git push sharedrepo HEAD:sharedbranch

Do not use -f here as this should be a fast-forward. If you are unlucky someone else may have pushed a new version. If that happens you restart this procedure.

不要在这里使用 -f，因为这应该是一个快进。如果你不走运，其他人可能已经推送了一个新版本。如果发生这种情况，请重新启动此过程。

回答by digout

You can work separately and then whenever you need to push / pull changes do:

您可以单独工作，然后在需要推送/拉取更改时执行以下操作：

git add --all .
git commit -m "Commit desc"
git pull
git push

Explained:

解释：

git add --all .

Add all changes, including removed files

添加所有更改，包括删除的文件

git commit -m "Commit desc"

Declare the commit

声明提交

git pull

First pull, which will merge, you may need to fix conflicts

第一拉，这将合并，你可能需要解决冲突

git push

Push the latest merged version [optional - if you want to submit your changes]

推送最新的合并版本 [可选 - 如果您想提交更改]

If you want further control such as being able to work on multiple local/remote versions simultaneously then take a look at branches.

如果您想要进一步的控制，例如能够同时处理多个本地/远程版本，请查看分支。

I recommend this simple yet useful page as a suggested workflow http://genomewiki.ucsc.edu/index.php/Working_with_branches_in_Gitcovers some great procedures.

我推荐这个简单而有用的页面作为建议的工作流程http://genomewiki.ucsc.edu/index.php/Working_with_branches_in_Git涵盖了一些很棒的程序。

回答by Chealion

Multiple people can work on the same branch at the same time. When you pull (or have the other person push) their changes to you git will merge the changes together resulting in a branch with both of your changes.

多人可以同时在同一个分支上工作。当您拉（或让其他人推送）他们对您的更改时，git 会将更改合并在一起，从而产生一个包含您的两个更改的分支。