git 合并、推、拉混乱
git merge, push, pull confusion
我有一个 git 存储库 R，它克隆在机器 A 和 B 上。我对 A 和 B 上的代码进行了更改。然后我将 A 推回 R。现在我想合并 B 上的更改，并使 A 和 B 恢复同步。
B，我运行git拉。这做了一些事情。 （我不知道的是什么。我该如何检查或者我应该说：git pull --no-commit ？）
如果我现在 运行、git 推送，是否会将这些更改放入存储库？
如果是这样，我如何使 A 重新同步。这是git拉A吗？
谢谢。
在类 Unix OS 上，以下命令将设置您在问题中描述的情况。
mkdir play && cd play
mkdir Rtemp && cd Rtemp
git init
echo "This is file 1" > file1.txt
echo "This is file 2" > file2.txt
git add file?.txt && git commit -m "Initial Commit"
cd ..
git clone --bare Rtemp R
git clone R A
git clone R B
cd A
echo "edited file 1 in A" >> file1.txt
git commit -a -m "Edited file 1 in A"
cd ../B
echo "edited file 1 in B" >> file1.txt
echo "edited file 2 in B" >> file2.txt
git commit -a -m "Edited both files in B"
cd ..
此时您在 R 中有一个中央存储库，在 A 和 B 中有两个克隆。 file.txt 已在 A 和 B 中编辑，file2.txt 已在 B 中编辑。
现在您将 A 的更改上推到 R
$ cd A
$ git push origin master
Counting objects: 3, done.
Delta compression using up to 16 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 304 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To .../play/R
34307cc..2a925ac master -> master
此时，R 和 A 同步。 B 有本地更改，并且是 R 之后的一次提交 - 但直到您执行 git fetch（隐含在 git pull 中）才知道。
$ cd ../B
$ git fetch
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From .../play/R
34307cc..2a925ac master -> origin/master
$
fetch 的输出显示 git 已下载上游存储库的状态。 git status 会告诉你你的立场。
$ git status
On branch master
Your branch and 'origin/master' have diverged,
and have 1 and 1 different commit each, respectively.
(use "git pull" to merge the remote branch into yours)
这里的警告标志是Your branch and 'origin/master' have diverged的注释。这说你需要做一个合并，我设置的方式应该有冲突
$ git merge origin/master
Auto-merging file1.txt
CONFLICT (content): Merge conflict in file1.txt
Automatic merge failed; fix conflicts and then commit the result.
$ git status
Your branch and 'origin/master' have diverged,
and have 1 and 1 different commit each, respectively.
(use "git pull" to merge the remote branch into yours)
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: file1.txt
no changes added to commit (use "git add" and/or "git commit -a")
请注意，它只是在抱怨 file1.txt。 Git 能够将更改合并到 file2.txt，因为它仅在本地更改。如果现在 cat file1.txt 您将看到以下内容
$ cat file1.txt
This is file 1
<<<<<<< HEAD
edited file 1 in B
=======
edited file 1 in A
>>>>>>> origin/master
<<<<<<<和>>>>>>这对显示了冲突的区域。在真正的合并中，每个文件中可能有很多。现在您需要决定合并后 file1.txt 的外观，并对其进行编辑。假设我们想要保留这两行，我们的本地编辑发生在来自上游的那一行之后。所以我们编辑它，file1.txt 现在看起来像这样：
$ vi file1.txt
$ cat file1.txt
This is file 1
edited file 1 in A
edited file 1 in B
（注意我们删除了冲突标记）
现在我们需要完成合并，并将我们的提交推回到 R
$ git add file1.txt
$ git commit -m "Resolved conflicts"
[master 5454980] Resolved conflicts
$ git log --oneline
5454980 Resolved conflicts
1673d76 Edited both files in B
2a925ac Edited file 1 in A
34307cc Initial Commit
$ git push origin master
Counting objects: 7, done.
Delta compression using up to 16 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (7/7), 650 bytes | 0 bytes/s, done.
Total 7 (delta 0), reused 0 (delta 0)
To .../play/R
2a925ac..5454980 master -> master
此时，B和R同步，但现在A再次落后于master。
$ cd ../A
$ git fetch
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 7 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (7/7), done.
From /home/keith/play/gitplay/R
2a925ac..5454980 master -> origin/master
$ git status
On branch master
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
这次 git status 让我们知道我们可以“快进” - 这意味着不会有冲突。
$ git merge origin/master
Updating 2a925ac..5454980
Fast-forward
file1.txt | 1 +
file2.txt | 1 +
2 files changed, 2 insertions(+)
git merge origin/master
$ git log --oneline
5454980 Resolved conflicts
1673d76 Edited both files in B
2a925ac Edited file 1 in A
34307cc Initial Commit
最后，A、B 和 R 达成一致，两位开发人员可以继续工作。
这看起来工作量很大，但这是一个非常的基本工作流程，您很快就会习惯。
一旦您真正知道自己在做什么，您就会对 git 感到足够自在，从而安全地使用 git pull 及其邪恶（但非常有用）的形式 git pull --rebase。但在那之前，坚持 git fetch 和 git merge.
我有一个 git 存储库 R，它克隆在机器 A 和 B 上。我对 A 和 B 上的代码进行了更改。然后我将 A 推回 R。现在我想合并 B 上的更改，并使 A 和 B 恢复同步。
B，我运行git拉。这做了一些事情。 （我不知道的是什么。我该如何检查或者我应该说：git pull --no-commit ？）
如果我现在 运行、git 推送，是否会将这些更改放入存储库？ 如果是这样，我如何使 A 重新同步。这是git拉A吗？
谢谢。
在类 Unix OS 上，以下命令将设置您在问题中描述的情况。
mkdir play && cd play
mkdir Rtemp && cd Rtemp
git init
echo "This is file 1" > file1.txt
echo "This is file 2" > file2.txt
git add file?.txt && git commit -m "Initial Commit"
cd ..
git clone --bare Rtemp R
git clone R A
git clone R B
cd A
echo "edited file 1 in A" >> file1.txt
git commit -a -m "Edited file 1 in A"
cd ../B
echo "edited file 1 in B" >> file1.txt
echo "edited file 2 in B" >> file2.txt
git commit -a -m "Edited both files in B"
cd ..
此时您在 R 中有一个中央存储库，在 A 和 B 中有两个克隆。 file.txt 已在 A 和 B 中编辑，file2.txt 已在 B 中编辑。
现在您将 A 的更改上推到 R
$ cd A
$ git push origin master
Counting objects: 3, done.
Delta compression using up to 16 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 304 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To .../play/R
34307cc..2a925ac master -> master
此时，R 和 A 同步。 B 有本地更改，并且是 R 之后的一次提交 - 但直到您执行 git fetch（隐含在 git pull 中）才知道。
$ cd ../B
$ git fetch
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From .../play/R
34307cc..2a925ac master -> origin/master
$
fetch 的输出显示 git 已下载上游存储库的状态。 git status 会告诉你你的立场。
$ git status
On branch master
Your branch and 'origin/master' have diverged,
and have 1 and 1 different commit each, respectively.
(use "git pull" to merge the remote branch into yours)
这里的警告标志是Your branch and 'origin/master' have diverged的注释。这说你需要做一个合并，我设置的方式应该有冲突
$ git merge origin/master
Auto-merging file1.txt
CONFLICT (content): Merge conflict in file1.txt
Automatic merge failed; fix conflicts and then commit the result.
$ git status
Your branch and 'origin/master' have diverged,
and have 1 and 1 different commit each, respectively.
(use "git pull" to merge the remote branch into yours)
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: file1.txt
no changes added to commit (use "git add" and/or "git commit -a")
请注意，它只是在抱怨 file1.txt。 Git 能够将更改合并到 file2.txt，因为它仅在本地更改。如果现在 cat file1.txt 您将看到以下内容
$ cat file1.txt
This is file 1
<<<<<<< HEAD
edited file 1 in B
=======
edited file 1 in A
>>>>>>> origin/master
<<<<<<<和>>>>>>这对显示了冲突的区域。在真正的合并中，每个文件中可能有很多。现在您需要决定合并后 file1.txt 的外观，并对其进行编辑。假设我们想要保留这两行，我们的本地编辑发生在来自上游的那一行之后。所以我们编辑它，file1.txt 现在看起来像这样：
$ vi file1.txt
$ cat file1.txt
This is file 1
edited file 1 in A
edited file 1 in B
（注意我们删除了冲突标记）
现在我们需要完成合并，并将我们的提交推回到 R
$ git add file1.txt
$ git commit -m "Resolved conflicts"
[master 5454980] Resolved conflicts
$ git log --oneline
5454980 Resolved conflicts
1673d76 Edited both files in B
2a925ac Edited file 1 in A
34307cc Initial Commit
$ git push origin master
Counting objects: 7, done.
Delta compression using up to 16 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (7/7), 650 bytes | 0 bytes/s, done.
Total 7 (delta 0), reused 0 (delta 0)
To .../play/R
2a925ac..5454980 master -> master
此时，B和R同步，但现在A再次落后于master。
$ cd ../A
$ git fetch
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 7 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (7/7), done.
From /home/keith/play/gitplay/R
2a925ac..5454980 master -> origin/master
$ git status
On branch master
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)
这次 git status 让我们知道我们可以“快进” - 这意味着不会有冲突。
$ git merge origin/master
Updating 2a925ac..5454980
Fast-forward
file1.txt | 1 +
file2.txt | 1 +
2 files changed, 2 insertions(+)
git merge origin/master
$ git log --oneline
5454980 Resolved conflicts
1673d76 Edited both files in B
2a925ac Edited file 1 in A
34307cc Initial Commit
最后，A、B 和 R 达成一致，两位开发人员可以继续工作。
这看起来工作量很大，但这是一个非常的基本工作流程，您很快就会习惯。
一旦您真正知道自己在做什么，您就会对 git 感到足够自在，从而安全地使用 git pull 及其邪恶（但非常有用）的形式 git pull --rebase。但在那之前，坚持 git fetch 和 git merge.