feat(feature) 意为：新功能

  1. git commit -m 'feat(xxx):xxx'

style 意为：样式上的变动，不影响代码逻辑

  1. git commit -m 'style(xxx):xxx'

fix 意为：修复（修复bug）有时可在相关commit上加上修复的bug的等级
如：
Blocker (中断) : 客户端程序无响应，无法执行下一步操作
Critical (严重)：功能点缺失
Major (较严重)：功能点没有满足需求
Normal (普通)：数值计算错误，js错误
Minor (次要)：界面UI与需求不符
Trivial (轻微)：辅助描述说明不清楚，提示语句错误之类…

  1. git commit -m 'fix(xxx):xxx'

test 意为：测试代码

  1. git commit -m 'test(xxx):xxx'

chore 意为：构建过程或辅助工具的变动，比如项目新加了别的js插件之类的

  1. git commit -m 'chore(xxx):xxx'

refactor 意为：重构，既不是修复bug也不是样式上的变动，有时可理解为优化

  1. git commit -m 'refactor(xxx):xxx'

[

](https://blog.csdn.net/summer942zjb/article/details/103975402)

前言

入职一家新公司，你的 leader 给你分配了仓库的权限后，如何配置本地的 Git 环境并拉取代码？莫慌，按照下面我讲的四个步骤走，保证你可以顺利使用 Git 进行拉取代码！

  1. 下载 Git 下载地址 ，选择自己系统对应的版本下载即可。
  2. 在你的电脑上生成 ssh 秘钥，打开终端，执行 ssh-keygen -t rsa -C "你公司内部邮箱地址"，如果执行成功，切换到 ~/.ssh 目录下，此时目录应该如下所示。复制 id_rsa.pub 的内容。

image.png

  1. 这里以 Github 为例，如下图所示，进入 settings -> SSH and GPG keys 通过 cat 命令查看文件 id_rsa.pub 的内容，然后复制过来，点击 add ssh key，这一步等于说把你的公钥放到了 Github 上进行托管。
    Git 版本管理 - 图2
  2. 全局配置 Git 的用户名和邮箱 
  1. git config --global user.name "xxx"
  2. git config --global user.email "xxx@xx.com"
  3. 复制代码

完成以上四步，你就可以愉快 pull 代码开发了。和 https 拉取方式不同的是，https 方式需要每次提交前都手动输入用户名和密码，ssh 的方式配置完毕后 Git 都会使用你本地的私钥和远程仓库的公钥进行验证是否是一对秘钥，从而简化了操作流程。

Git 的工作区域和流程

要想弄懂 Git 是怎么对我们的代码进行管理的，那首当其冲的是了解 Git 的工作区域是如何构成的。因为，只有彻底弄懂了 Git 工作区域的构成，你才可以在适当的区域使用合适的命令。如下图所示，此图包含了 Git 的4个工作区和一些常见的操作。

Git 版本管理 - 图3

Workspace：工作区，就是平时进行开发改动的地方，是当前看到最新的内容，在开发的过程也就是对工作区的操作

Index：暂存区，当执行 git add 的命令后，工作区的文件就会被移入暂存区，暂存区标记了当前工作区中那些内容是被 Git 管理的，当完成某个需求或者功能后需要提交代码，第一步就是通过 git add 先提交到暂存区。

Repository：本地仓库，位于自己的电脑上，通过 git commit 提交暂存区的内容，会进入本地仓库。

Remote：远程仓库，用来托管代码的服务器，远程仓库的内容能够被分布在多个地点的处于协作关系的本地仓库修改，本地仓库修改完代码后通过 git push 命令同步代码到远程仓库。

一般来说，Git 的工作流程分为以下几步

  1. 在工作区开发，添加，修改文件。
  2. 将修改后的文件放入暂存区。
  3. 将暂存区域的文件提交到本地仓库。
  4. 将本地仓库的修改推送到远程仓库。

Git 基本操作

git add

添加文件到暂存区

  1. # 添加某个文件到暂存区，后面可以跟多个文件，以空格区分
  2. git add xxx
  3. # 添加当前更改的所有文件到暂存区。
  4. git add .

git commit

  1. # 提交暂存的更改，会新开编辑器进行编辑
  2. git commit 
  3. # 提交暂存的更改，并记录下备注
  4. git commit -m "you message"
  5. # 等同于 git add . && git commit -m
  6. git commit -am
  7. # 对最近一次的提交的信息进行修改,此操作会修改commit的hash值
  8. git commit --amend

git pull

  1. # 从远程仓库拉取代码并合并到本地，可简写为 git pull 等同于 git fetch && git merge 
  2. git pull <远程主机名> <远程分支名>:<本地分支名>
  3. # 使用rebase的模式进行合并
  4. git pull --rebase <远程主机名> <远程分支名>:<本地分支名>

git fetch

与 git pull 不同的是 git fetch 操作仅仅只会拉取远程的更改，不会自动进行 merge 操作。对你当前的代码没有影响

  1. # 获取远程仓库特定分支的更新
  2. git fetch <远程主机名> <分支名>
  3. # 获取远程仓库所有分支的更新
  4. git fetch --all

Git 进阶小操作

版本回退

分支

分支在实际中有什么用呢？假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

创建与合并分支

在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

Git 版本管理 - 图4

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

Git 版本管理 - 图5

你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

Git 版本管理 - 图6

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

Git 版本管理 - 图7

所以Git合并分支也很快！就改改指针，工作区内容也不变！

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

Git 版本管理 - 图8

真是太神奇了，你看得出来有些提交是通过分支完成的吗？

下面开始实战。

首先，我们创建dev分支，然后切换到dev分支：

  1. $ git checkout -b dev
  2. Switched to a new branch 'dev'

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

  1. $ git branch dev
  2. $ git checkout dev
  3. Switched to branch 'dev'

然后，用git branch命令查看当前分支：

  1. $ git branch
  2. * dev
  3.   master

git branch命令会列出所有分支，当前分支前面会标一个*号。

然后，我们就可以在dev分支上正常提交，比如对readme.txt做个修改，加上一行：

  1. Creating a new branch is quick.

然后提交：

  1. $ git add readme.txt 
  2. $ git commit -m "branch test"
  3. [dev b17d20e] branch test
  4.  1 file changed, 1 insertion(+)

现在，dev分支的工作完成，我们就可以切换回master分支：

  1. $ git checkout master
  2. Switched to branch 'master'

切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变：

Git 版本管理 - 图9

现在，我们把dev分支的工作成果合并到master分支上：

  1. $ git merge dev
  2. Updating d46f35e..b17d20e
  3. Fast-forward
  4.  readme.txt | 1 +
  5.  1 file changed, 1 insertion(+)

git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。

注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。

合并完成后，就可以放心地删除dev分支了：

  1. $ git branch -d dev
  2. Deleted branch dev (was b17d20e).

删除后，查看branch，就只剩下master分支了：

  1. $ git branch
  2. * master

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

switch

我们注意到切换分支使用git checkout <branch>，而前面讲过的撤销修改则是git checkout -- <file>，同一个命令，有两种作用，确实有点令人迷惑。

实际上，切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支：

创建并切换到新的dev分支，可以使用：

  1. $ git switch -c dev

直接切换到已有的master分支，可以使用：

  1. $ git switch master

使用新的git switch命令，比git checkout要更容易理解。

小结

Git鼓励大量使用分支：

查看分支：git branch

创建分支：git branch <name>

切换分支：git checkout <name>或者git switch <name>

创建+切换分支：git checkout -b <name>或者git switch -c <name>

合并某分支到当前分支：git merge <name>

删除分支：git branch -d <name>

解决冲突

人生不如意之事十之八九，合并分支往往也不是一帆风顺的。

准备新的feature1分支，继续我们的新分支开发：

  1. $ git switch -c feature1
  2. Switched to a new branch 'feature1'

修改readme.txt最后一行，改为：

  1. Creating a new branch is quick AND simple.

在feature1分支上提交：

  1. $ git add readme.txt
  3. $ git commit -m "AND simple"
  4. [feature1 14096d0] AND simple
  5.  1 file changed, 1 insertion(+), 1 deletion(-)

切换到master分支：

  1. $ git switch master
  2. Switched to branch 'master'
  3. Your branch is ahead of 'origin/master' by 1 commit.
  4.   (use "git push" to publish your local commits)

Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。

在master分支上把readme.txt文件的最后一行改为：

  1. Creating a new branch is quick & simple.

提交：

  1. $ git add readme.txt 
  2. $ git commit -m "& simple"
  3. [master 5dc6824] & simple
  4.  1 file changed, 1 insertion(+), 1 deletion(-)

现在，master分支和feature1分支各自都分别有新的提交，变成了这样：

Git 版本管理 - 图10

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：

  1. $ git merge feature1
  2. Auto-merging readme.txt
  3. CONFLICT (content): Merge conflict in readme.txt
  4. Automatic merge failed; fix conflicts and then commit the result.

果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件：

  1. $ git status
  2. On branch master
  3. Your branch is ahead of 'origin/master' by 2 commits.
  4.   (use "git push" to publish your local commits)
  6. You have unmerged paths.
  7.   (fix conflicts and run "git commit")
  8.   (use "git merge --abort" to abort the merge)
  10. Unmerged paths:
  11.   (use "git add <file>..." to mark resolution)
  13.     both modified:   readme.txt
  15. no changes added to commit (use "git add" and/or "git commit -a")

我们可以直接查看readme.txt的内容：

  1. Git is a distributed version control system.
  2. Git is free software distributed under the GPL.
  3. Git has a mutable index called stage.
  4. Git tracks changes of files.
  5. <<<<<<< HEAD
  6. Creating a new branch is quick & simple.
  7. =======
  8. Creating a new branch is quick AND simple.
  9. >>>>>>> feature1

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：

  1. Creating a new branch is quick and simple.

再提交：

  1. $ git add readme.txt 
  2. $ git commit -m "conflict fixed"
  3. [master cf810e4] conflict fixed

现在，master分支和feature1分支变成了下图所示：

Git 版本管理 - 图11

用带参数的git log也可以看到分支的合并情况：

  1. $ git log --graph --pretty=oneline --abbrev-commit
  2. *   cf810e4 (HEAD -> master) conflict fixed
  3. |\  
  4. | * 14096d0 (feature1) AND simple
  5. * | 5dc6824 & simple
  6. |/  
  7. * b17d20e branch test
  8. * d46f35e (origin/master) remove test.txt
  9. * b84166e add test.txt
  10. * 519219b git tracks changes
  11. * e43a48b understand how stage works
  12. * 1094adb append GPL
  13. * e475afc add distributed
  14. * eaadf4e wrote a readme file

最后，删除feature1分支：

  1. $ git branch -d feature1
  2. Deleted branch feature1 (was 14096d0).

工作完成。

小结

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

用git log --graph命令可以看到分支合并图。

分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

下面我们实战一下--no-ff方式的git merge：

首先，仍然创建并切换dev分支：

  1. $ git switch -c dev
  2. Switched to a new branch 'dev'

修改readme.txt文件，并提交一个新的commit：

  1. $ git add readme.txt 
  2. $ git commit -m "add merge"
  3. [dev f52c633] add merge
  4.  1 file changed, 1 insertion(+)

现在，我们切换回master：

  1. $ git switch master
  2. Switched to branch 'master'

准备合并dev分支，请注意--no-ff参数，表示禁用Fast forward：

  1. $ git merge --no-ff -m "merge with no-ff" dev
  2. Merge made by the 'recursive' strategy.
  3.  readme.txt | 1 +
  4.  1 file changed, 1 insertion(+)

因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。

合并后，我们用git log看看分支历史：

  1. $ git log --graph --pretty=oneline --abbrev-commit
  2. *   e1e9c68 (HEAD -> master) merge with no-ff
  3. |\  
  4. | * f52c633 (dev) add merge
  5. |/  
  6. *   cf810e4 conflict fixed
  7. ...

可以看到，不使用Fast forward模式，merge后就像这样：

Git 版本管理 - 图12

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

Git 版本管理 - 图13

小结

Git分支十分强大，在团队开发中应该充分应用。

合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

Bug分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：

  1. $ git status
  2. On branch dev
  3. Changes to be committed:
  4.   (use "git reset HEAD <file>..." to unstage)
  6.     new file:   hello.py
  8. Changes not staged for commit:
  9.   (use "git add <file>..." to update what will be committed)
  10.   (use "git checkout -- <file>..." to discard changes in working directory)
  12.     modified:   readme.txt

并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

  1. $ git stash
  2. Saved working directory and index state WIP on dev: f52c633 add merge

现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。

首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

  1. $ git checkout master
  2. Switched to branch 'master'
  3. Your branch is ahead of 'origin/master' by 6 commits.
  4.   (use "git push" to publish your local commits)
  6. $ git checkout -b issue-101
  7. Switched to a new branch 'issue-101'

现在修复bug，需要把“Git is free software …”改为“Git is a free software …”，然后提交：

  1. $ git add readme.txt 
  2. $ git commit -m "fix bug 101"
  3. [issue-101 4c805e2] fix bug 101
  4.  1 file changed, 1 insertion(+), 1 deletion(-)

修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：

  1. $ git switch master
  2. Switched to branch 'master'
  3. Your branch is ahead of 'origin/master' by 6 commits.
  4.   (use "git push" to publish your local commits)
  6. $ git merge --no-ff -m "merged bug fix 101" issue-101
  7. Merge made by the 'recursive' strategy.
  8.  readme.txt | 2 +-
  9.  1 file changed, 1 insertion(+), 1 deletion(-)

太棒了，原计划两个小时的bug修复只花了5分钟！现在，是时候接着回到dev分支干活了！

  1. $ git switch dev
  2. Switched to branch 'dev'
  4. $ git status
  5. On branch dev
  6. nothing to commit, working tree clean

工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：

  1. $ git stash list
  2. stash@{0}: WIP on dev: f52c633 add merge

工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：

一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了：

  1. $ git stash pop
  2. On branch dev
  3. Changes to be committed:
  4.   (use "git reset HEAD <file>..." to unstage)
  6.     new file:   hello.py
  8. Changes not staged for commit:
  9.   (use "git add <file>..." to update what will be committed)
  10.   (use "git checkout -- <file>..." to discard changes in working directory)
  12.     modified:   readme.txt
  14. Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)

再用git stash list查看，就看不到任何stash内容了：

  1. $ git stash list

你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：

  1. $ git stash apply stash@{0}

在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。

那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了？

有木有更简单的方法？

有！

同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。

为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：

  1. $ git branch
  2. * dev
  3.   master
  4. $ git cherry-pick 4c805e2
  5. [master 1d4b803] fix bug 101
  6.  1 file changed, 1 insertion(+), 1 deletion(-)

Git自动给dev分支做了一次提交，注意这次提交的commit是1d4b803，它并不同于master的4c805e2，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。

有些聪明的童鞋会想了，既然可以在master分支上修复bug后，在dev分支上可以“重放”这个修复过程，那么直接在dev分支上修复bug，然后在master分支上“重放”行不行？当然可以，不过你仍然需要git stash命令保存现场，才能从dev分支切换到master分支。

小结

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；

当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；

在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

Feature分支

软件开发中，总有无穷无尽的新的功能要不断添加进来。

添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。

现在，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。

于是准备开发：

  1. $ git switch -c feature-vulcan
  2. Switched to a new branch 'feature-vulcan'

5分钟后，开发完毕：

  1. $ git add vulcan.py
  3. $ git status
  4. On branch feature-vulcan
  5. Changes to be committed:
  6.   (use "git reset HEAD <file>..." to unstage)
  8.     new file:   vulcan.py
  10. $ git commit -m "add feature vulcan"
  11. [feature-vulcan 287773e] add feature vulcan
  12.  1 file changed, 2 insertions(+)
  13.  create mode 100644 vulcan.py

切回dev，准备合并：

  1. $ git switch dev

一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。

但是！

就在此时，接到上级命令，因经费不足，新功能必须取消！

虽然白干了，但是这个包含机密资料的分支还是必须就地销毁：

  1. $ git branch -d feature-vulcan
  2. error: The branch 'feature-vulcan' is not fully merged.
  3. If you are sure you want to delete it, run 'git branch -D feature-vulcan'.

销毁失败。Git友情提醒，feature-vulcan分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用大写的-D参数。。

现在我们强行删除：

  1. $ git branch -D feature-vulcan
  2. Deleted branch feature-vulcan (was 287773e).

终于删除成功！

小结

开发一个新feature，最好新建一个分支；

如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。

多人协作

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。

要查看远程库的信息，用git remote：

  1. $ git remote
  2. origin

或者，用git remote -v显示更详细的信息：

  1. $ git remote -v
  2. origin  git@github.com:michaelliao/learngit.git (fetch)
  3. origin  git@github.com:michaelliao/learngit.git (push)

上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。

推送分支

推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

  1. $ git push origin master

如果要推送其他分支，比如dev，就改成：

  1. $ git push origin dev

但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？

  • master分支是主分支，因此要时刻与远程同步；
  • dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
  • bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
  • feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！

抓取分支

多人协作时，大家都会往master和dev分支上推送各自的修改。

现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆：

  1. $ git clone git@github.com:michaelliao/learngit.git
  2. Cloning into 'learngit'...
  3. remote: Counting objects: 40, done.
  4. remote: Compressing objects: 100% (21/21), done.
  5. remote: Total 40 (delta 14), reused 40 (delta 14), pack-reused 0
  6. Receiving objects: 100% (40/40), done.
  7. Resolving deltas: 100% (14/14), done.

当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：

  1. $ git branch
  2. * master

现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支：

  1. $ git checkout -b dev origin/dev

现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程：

  1. $ git add env.txt
  3. $ git commit -m "add env"
  4. [dev 7a5e5dd] add env
  5.  1 file changed, 1 insertion(+)
  6.  create mode 100644 env.txt
  8. $ git push origin dev
  9. Counting objects: 3, done.
  10. Delta compression using up to 4 threads.
  11. Compressing objects: 100% (2/2), done.
  12. Writing objects: 100% (3/3), 308 bytes | 308.00 KiB/s, done.
  13. Total 3 (delta 0), reused 0 (delta 0)
  14. To github.com:michaelliao/learngit.git
  15.    f52c633..7a5e5dd  dev -> dev

你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送：

  1. $ cat env.txt
  2. env
  4. $ git add env.txt
  6. $ git commit -m "add new env"
  7. [dev 7bd91f1] add new env
  8.  1 file changed, 1 insertion(+)
  9.  create mode 100644 env.txt
  11. $ git push origin dev
  12. To github.com:michaelliao/learngit.git
  13.  ! [rejected]        dev -> dev (non-fast-forward)
  14. error: failed to push some refs to 'git@github.com:michaelliao/learngit.git'
  15. hint: Updates were rejected because the tip of your current branch is behind
  16. hint: its remote counterpart. Integrate the remote changes (e.g.
  17. hint: 'git pull ...') before pushing again.
  18. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：

  1. $ git pull
  2. There is no tracking information for the current branch.
  3. Please specify which branch you want to merge with.
  4. See git-pull(1) for details.
  6.     git pull <remote> <branch>
  8. If you wish to set tracking information for this branch you can do so with:
  10.     git branch --set-upstream-to=origin/<branch> dev

git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接：

  1. $ git branch --set-upstream-to=origin/dev dev
  2. Branch 'dev' set up to track remote branch 'dev' from 'origin'.

再pull：

  1. $ git pull
  2. Auto-merging env.txt
  3. CONFLICT (add/add): Merge conflict in env.txt
  4. Automatic merge failed; fix conflicts and then commit the result.

这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push：

  1. $ git commit -m "fix env conflict"
  2. [dev 57c53ab] fix env conflict
  4. $ git push origin dev
  5. Counting objects: 6, done.
  6. Delta compression using up to 4 threads.
  7. Compressing objects: 100% (4/4), done.
  8. Writing objects: 100% (6/6), 621 bytes | 621.00 KiB/s, done.
  9. Total 6 (delta 0), reused 0 (delta 0)
  10. To github.com:michaelliao/learngit.git
  11.    7a5e5dd..57c53ab  dev -> dev

因此，多人协作的工作模式通常是这样：

  1. 首先，可以试图用git push origin <branch-name>推送自己的修改；
  2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
  3. 如果合并有冲突，则解决冲突，并在本地提交；
  4. 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

这就是多人协作的工作模式，一旦熟悉了，就非常简单。

小结

  • 查看远程库信息，使用git remote -v；
  • 本地新建的分支如果不推送到远程，对其他人就是不可见的；
  • 从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；
  • 在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
  • 建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
  • 从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。

Rebase

在上一节我们看到了，多人在同一个分支上协作时，很容易出现冲突。即使没有冲突，后push的童鞋不得不先pull，在本地合并，然后才能push成功。

每次合并再push后，分支变成了这样：

  1. $ git log --graph --pretty=oneline --abbrev-commit
  2. * d1be385 (HEAD -> master, origin/master) init hello
  3. *   e5e69f1 Merge branch 'dev'
  4. |\  
  5. | *   57c53ab (origin/dev, dev) fix env conflict
  6. | |\  
  7. | | * 7a5e5dd add env
  8. | * | 7bd91f1 add new env
  9. | |/  
  10. * |   12a631b merged bug fix 101
  11. |\ \  
  12. | * | 4c805e2 fix bug 101
  13. |/ /  
  14. * |   e1e9c68 merge with no-ff
  15. |\ \  
  16. | |/  
  17. | * f52c633 add merge
  18. |/  
  19. *   cf810e4 conflict fixed

总之看上去很乱，有强迫症的童鞋会问：为什么Git的提交历史不能是一条干净的直线？

其实是可以做到的！

Git有一种称为rebase的操作，有人把它翻译成“变基”。

Git 版本管理 - 图14

先不要随意展开想象。我们还是从实际问题出发，看看怎么把分叉的提交变成直线。

在和远程分支同步后，我们对hello.py这个文件做了两次提交。用git log命令看看：

  1. $ git log --graph --pretty=oneline --abbrev-commit
  2. * 582d922 (HEAD -> master) add author
  3. * 8875536 add comment
  4. * d1be385 (origin/master) init hello
  5. *   e5e69f1 Merge branch 'dev'
  6. |\  
  7. | *   57c53ab (origin/dev, dev) fix env conflict
  8. | |\  
  9. | | * 7a5e5dd add env
  10. | * | 7bd91f1 add new env
  11. ...

注意到Git用(HEAD -> master)和(origin/master)标识出当前分支的HEAD和远程origin的位置分别是582d922 add author和d1be385 init hello，本地分支比远程分支快两个提交。

现在我们尝试推送本地分支：

  1. $ git push origin master
  2. To github.com:michaelliao/learngit.git
  3.  ! [rejected]        master -> master (fetch first)
  4. error: failed to push some refs to 'git@github.com:michaelliao/learngit.git'
  5. hint: Updates were rejected because the remote contains work that you do
  6. hint: not have locally. This is usually caused by another repository pushing
  7. hint: to the same ref. You may want to first integrate the remote changes
  8. hint: (e.g., 'git pull ...') before pushing again.
  9. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

很不幸，失败了，这说明有人先于我们推送了远程分支。按照经验，先pull一下：

  1. $ git pull
  2. remote: Counting objects: 3, done.
  3. remote: Compressing objects: 100% (1/1), done.
  4. remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0
  5. Unpacking objects: 100% (3/3), done.
  6. From github.com:michaelliao/learngit
  7.    d1be385..f005ed4  master     -> origin/master
  8.  * [new tag]         v1.0       -> v1.0
  9. Auto-merging hello.py
  10. Merge made by the 'recursive' strategy.
  11.  hello.py | 1 +
  12.  1 file changed, 1 insertion(+)

再用git status看看状态：

  1. $ git status
  2. On branch master
  3. Your branch is ahead of 'origin/master' by 3 commits.
  4.   (use "git push" to publish your local commits)
  6. nothing to commit, working tree clean

加上刚才合并的提交，现在我们本地分支比远程分支超前3个提交。

用git log看看：

  1. $ git log --graph --pretty=oneline --abbrev-commit
  2. *   e0ea545 (HEAD -> master) Merge branch 'master' of github.com:michaelliao/learngit
  3. |\  
  4. | * f005ed4 (origin/master) set exit=1
  5. * | 582d922 add author
  6. * | 8875536 add comment
  7. |/  
  8. * d1be385 init hello
  9. ...

对强迫症童鞋来说，现在事情有点不对头，提交历史分叉了。如果现在把本地分支push到远程，有没有问题？

有！

什么问题？

不好看！

有没有解决方法？

有！

这个时候，rebase就派上了用场。我们输入命令git rebase试试：

  1. $ git rebase
  2. First, rewinding head to replay your work on top of it...
  3. Applying: add comment
  4. Using index info to reconstruct a base tree...
  5. M    hello.py
  6. Falling back to patching base and 3-way merge...
  7. Auto-merging hello.py
  8. Applying: add author
  9. Using index info to reconstruct a base tree...
  10. M    hello.py
  11. Falling back to patching base and 3-way merge...
  12. Auto-merging hello.py

输出了一大堆操作，到底是啥效果？再用git log看看：

  1. $ git log --graph --pretty=oneline --abbrev-commit
  2. * 7e61ed4 (HEAD -> master) add author
  3. * 3611cfe add comment
  4. * f005ed4 (origin/master) set exit=1
  5. * d1be385 init hello
  6. ...

原本分叉的提交现在变成一条直线了！这种神奇的操作是怎么实现的？其实原理非常简单。我们注意观察，发现Git把我们本地的提交“挪动”了位置，放到了f005ed4 (origin/master) set exit=1之后，这样，整个提交历史就成了一条直线。rebase操作前后，最终的提交内容是一致的，但是，我们本地的commit修改内容已经变化了，它们的修改不再基于d1be385 init hello，而是基于f005ed4 (origin/master) set exit=1，但最后的提交7e61ed4内容是一致的。

这就是rebase操作的特点：把分叉的提交历史“整理”成一条直线，看上去更直观。缺点是本地的分叉提交已经被修改过了。

最后，通过push操作把本地分支推送到远程：

  1. Mac:~/learngit michael$ git push origin master
  2. Counting objects: 6, done.
  3. Delta compression using up to 4 threads.
  4. Compressing objects: 100% (5/5), done.
  5. Writing objects: 100% (6/6), 576 bytes | 576.00 KiB/s, done.
  6. Total 6 (delta 2), reused 0 (delta 0)
  7. remote: Resolving deltas: 100% (2/2), completed with 1 local object.
  8. To github.com:michaelliao/learngit.git
  9.    f005ed4..7e61ed4  master -> master

再用git log看看效果：

  1. $ git log --graph --pretty=oneline --abbrev-commit
  2. * 7e61ed4 (HEAD -> master, origin/master) add author
  3. * 3611cfe add comment
  4. * f005ed4 set exit=1
  5. * d1be385 init hello
  6. ...

远程分支的提交历史也是一条直线。

小结

  • rebase操作可以把本地未push的分叉提交历史整理成直线；
  • rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。

说说你对git rebase 和 git merge的理解？区别？

一、是什么

在使用 git 进行版本管理的项目中，当完成一个特性的开发并将其合并到 master 分支时，会有两种方式：

  • git merge
  • git rebase

git rebase 与 git merge都有相同的作用，都是将一个分支的提交合并到另一分支上，但是在原理上却不相同

用法上两者也十分的简单：

git merge

将当前分支合并到指定分支，命令用法如下：

git merge xxx

git rebase

将当前分支移植到指定分支或指定commit之上，用法如下：

git rebase -i

常见的参数有--continue，用于解决冲突之后，继续执行rebase

git rebase --continue

二、分析

git merge

通过git merge将当前分支与xxx分支合并，产生的新的commit对象有两个父节点

如果“指定分支”本身是当前分支的一个直接子节点，则会产生快照合并

举个例子，bugfix分支是从master分支分叉出来的，如下所示：

Git 版本管理 - 图15

合并bugfix分支到master分支时，如果master分支的状态没有被更改过，即 bugfix分支的历史记录包含master分支所有的历史记录

所以通过把master分支的位置移动到bugfix的最新分支上，就完成合并

如果master分支的历史记录在创建bugfix分支后又有新的提交，如下情况：

Git 版本管理 - 图16

这时候使用git merge的时候，会生成一个新的提交，并且master分支的HEAD会移动到新的分支上，如下：

Git 版本管理 - 图17

从上面可以看到，会把两个分支的最新快照以及二者最近的共同祖先进行三方合并，合并的结果是生成一个新的快照

git rebase

同样，master分支的历史记录在创建bugfix分支后又有新的提交，如下情况：

Git 版本管理 - 图18

通过git rebase，会变成如下情况：

Git 版本管理 - 图19

在移交过程中，如果发生冲突，需要修改各自的冲突，如下：

Git 版本管理 - 图20

rebase之后，master的HEAD位置不变。因此，要合并master分支和bugfix分支

Git 版本管理 - 图21

从上面可以看到，rebase会找到不同的分支的最近共同祖先，如上图的B

然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件（老的提交X和Y也没有被销毁，只是简单地不能再被访问或者使用）

然后将当前分支指向目标最新位置D, 然后将之前另存为临时文件的修改依序应用

三、区别

从上面可以看到，merge和rebasea都是合并历史记录，但是各自特性不同：

merge

通过merge合并分支会新增一个merge commit，然后将两个分支的历史联系起来

其实是一种非破坏性的操作，对现有分支不会以任何方式被更改，但是会导致历史记录相对复杂

rebase

rebase会将整个分支移动到另一个分支上，有效地整合了所有分支上的提交

主要的好处是历史记录更加清晰，是在原有提交的基础上将差异内容反映进去，消除了 git merge所需的不必要的合并提交

标签管理

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。

Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。

Git有commit，为什么还要引入tag？

“请把上周一的那个版本打包发布，commit号是6a5819e…”

“一串乱七八糟的数字不好找！”

如果换一个办法：

“请把上周一的那个版本打包发布，版本号是v1.2”

“好的，按照tag v1.2查找commit就行！”

所以，tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起。

创建标签

在Git中打标签非常简单，首先，切换到需要打标签的分支上：

  1. $ git branch
  2. * dev
  3.   master
  4. $ git checkout master
  5. Switched to branch 'master'

然后，敲命令git tag <name>就可以打一个新标签：

  1. $ git tag v1.0

可以用命令git tag查看所有标签：

  1. $ git tag
  2. v1.0

默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？

方法是找到历史提交的commit id，然后打上就可以了：

  1. $ git log --pretty=oneline --abbrev-commit
  2. 12a631b (HEAD -> master, tag: v1.0, origin/master) merged bug fix 101
  3. 4c805e2 fix bug 101
  4. e1e9c68 merge with no-ff
  5. f52c633 add merge
  6. cf810e4 conflict fixed
  7. 5dc6824 & simple
  8. 14096d0 AND simple
  9. b17d20e branch test
  10. d46f35e remove test.txt
  11. b84166e add test.txt
  12. 519219b git tracks changes
  13. e43a48b understand how stage works
  14. 1094adb append GPL
  15. e475afc add distributed
  16. eaadf4e wrote a readme file

比方说要对add merge这次提交打标签，它对应的commit id是f52c633，敲入命令：

  1. $ git tag v0.9 f52c633

再用命令git tag查看标签：

  1. $ git tag
  2. v0.9
  3. v1.0

注意，标签不是按时间顺序列出，而是按字母排序的。可以用git show <tagname>查看标签信息：

  1. $ git show v0.9
  2. commit f52c63349bc3c1593499807e5c8e972b82c8f286 (tag: v0.9)
  3. Author: Michael Liao <askxuefeng@gmail.com>
  4. Date:   Fri May 18 21:56:54 2018 +0800
  6.     add merge
  8. diff --git a/readme.txt b/readme.txt
  9. ...

可以看到，v0.9确实打在add merge这次提交上。

还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：

  1. $ git tag -a v0.1 -m "version 0.1 released" 1094adb

用命令git show <tagname>可以看到说明文字：

  1. $ git show v0.1
  2. tag v0.1
  3. Tagger: Michael Liao <askxuefeng@gmail.com>
  4. Date:   Fri May 18 22:48:43 2018 +0800
  6. version 0.1 released
  8. commit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (tag: v0.1)
  9. Author: Michael Liao <askxuefeng@gmail.com>
  10. Date:   Fri May 18 21:06:15 2018 +0800
  12.     append GPL
  14. diff --git a/readme.txt b/readme.txt
  15. ...

小结

  • 命令git tag <tagname>用于新建一个标签，默认为HEAD，也可以指定一个commit id；
  • 命令git tag -a <tagname> -m "blablabla..."可以指定标签信息；
  • 命令git tag可以查看所有标签。

操作标签

如果标签打错了，也可以删除：

  1. $ git tag -d v0.1
  2. Deleted tag 'v0.1' (was f15b0dd)

因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。

如果要推送某个标签到远程，使用命令git push origin <tagname>：

  1. $ git push origin v1.0
  2. Total 0 (delta 0), reused 0 (delta 0)
  3. To github.com:michaelliao/learngit.git
  4.  * [new tag]         v1.0 -> v1.0

或者，一次性推送全部尚未推送到远程的本地标签：

  1. $ git push origin --tags
  2. Total 0 (delta 0), reused 0 (delta 0)
  3. To github.com:michaelliao/learngit.git
  4.  * [new tag]         v0.9 -> v0.9

如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：

  1. $ git tag -d v0.9
  2. Deleted tag 'v0.9' (was f52c633)

然后，从远程删除。删除命令也是push，但是格式如下：

  1. $ git push origin :refs/tags/v0.9
  2. To github.com:michaelliao/learngit.git
  3.  - [deleted]         v0.9

要看看是否真的从远程库删除了标签，可以登陆GitHub查看。

小结

  • 命令git push origin <tagname>可以推送一个本地标签；
  • 命令git push origin --tags可以推送全部未推送过的本地标签；
  • 命令git tag -d <tagname>可以删除一个本地标签；
  • 命令git push origin :refs/tags/<tagname>可以删除一个远程标签。

使用Github

我们一直用GitHub作为免费的远程仓库，如果是个人的开源项目，放到GitHub上是完全没有问题的。其实GitHub还是一个开源协作社区，通过GitHub，既可以让别人参与你的开源项目，也可以参与别人的开源项目。

在GitHub出现以前，开源项目开源容易，但让广大人民群众参与进来比较困难，因为要参与，就要提交代码，而给每个想提交代码的群众都开一个账号那是不现实的，因此，群众也仅限于报个bug，即使能改掉bug，也只能把diff文件用邮件发过去，很不方便。

但是在GitHub上，利用Git极其强大的克隆和分支功能，广大人民群众真正可以第一次自由参与各种开源项目了。

如何参与一个开源项目呢？比如人气极高的bootstrap项目，这是一个非常强大的CSS框架，你可以访问它的项目主页https://github.com/twbs/bootstrap，点“Fork”就在自己的账号下克隆了一个bootstrap仓库，然后，从自己的账号下clone：

  1. git clone git@github.com:michaelliao/bootstrap.git

一定要从自己的账号下clone仓库，这样你才能推送修改。如果从bootstrap的作者的仓库地址git@github.com:twbs/bootstrap.git克隆，因为没有权限，你将不能推送修改。

Bootstrap的官方仓库twbs/bootstrap、你在GitHub上克隆的仓库my/bootstrap，以及你自己克隆到本地电脑的仓库，他们的关系就像下图显示的那样：

  1. ┌─ GitHub ────────────────────────────────────┐
  2. │                                             │
  3. │ ┌─────────────────┐     ┌─────────────────┐ │
  4. │ │ twbs/bootstrap  │────>│  my/bootstrap   │ │
  5. │ └─────────────────┘     └─────────────────┘ │
  6. │                                  ▲          │
  7. └──────────────────────────────────┼──────────┘
  8.                                    ▼
  9.                           ┌─────────────────┐
  10.                           │ local/bootstrap │
  11.                           └─────────────────┘

如果你想修复bootstrap的一个bug，或者新增一个功能，立刻就可以开始干活，干完后，往自己的仓库推送。

如果你希望bootstrap的官方库能接受你的修改，你就可以在GitHub上发起一个pull request。当然，对方是否接受你的pull request就不一定了。

如果你没能力修改bootstrap，但又想要试一把pull request，那就Fork一下我的仓库：https://github.com/michaelliao/learngit，创建一个`your-github-id.txt`的文本文件，写点自己学习Git的心得，然后推送一个pull request给我，我会视心情而定是否接受。

小结

  • 在GitHub上，可以任意Fork开源仓库；
  • 自己拥有Fork后的仓库的读写权限；
  • 可以推送pull request给官方仓库来贡献代码。

使用Gitee

使用GitHub时，国内的用户经常遇到的问题是访问速度太慢，有时候还会出现无法连接的情况（原因你懂的）。

如果我们希望体验Git飞一般的速度，可以使用国内的Git托管服务——Gitee（gitee.com）。

和GitHub相比，Gitee也提供免费的Git仓库。此外，还集成了代码质量检测、项目演示等功能。对于团队协作开发，Gitee还提供了项目管理、代码托管、文档管理的服务，5人以下小团队免费。

使用Gitee和使用GitHub类似，我们在Gitee上注册账号并登录后，需要先上传自己的SSH公钥。选择右上角用户头像 -> 菜单“修改资料”，然后选择“SSH公钥”，填写一个便于识别的标题，然后把用户主目录下的.ssh/id_rsa.pub文件的内容粘贴进去：

Git 版本管理 - 图22

点击“确定”即可完成并看到刚才添加的Key：

Git 版本管理 - 图23

如果我们已经有了一个本地的git仓库（例如，一个名为learngit的本地库），如何把它关联到Gitee的远程库上呢？

首先，我们在Gitee上创建一个新的项目，选择右上角用户头像 -> 菜单“控制面板”，然后点击“创建项目”：

Git 版本管理 - 图24

项目名称最好与本地库保持一致：

然后，我们在本地库上使用命令git remote add把它和Gitee的远程库关联：

  1. git remote add origin git@gitee.com:liaoxuefeng/learngit.git

之后，就可以正常地用git push和git pull推送了！

如果在使用命令git remote add时报错：

  1. git remote add origin git@gitee.com:liaoxuefeng/learngit.git
  2. fatal: remote origin already exists.

这说明本地库已经关联了一个名叫origin的远程库，此时，可以先用git remote -v查看远程库信息：

  1. git remote -v
  2. origin    git@github.com:michaelliao/learngit.git (fetch)
  3. origin    git@github.com:michaelliao/learngit.git (push)

可以看到，本地库已经关联了origin的远程库，并且，该远程库指向GitHub。

我们可以删除已有的GitHub远程库：

  1. git remote rm origin

再关联Gitee的远程库（注意路径中需要填写正确的用户名）：

  1. git remote add origin git@gitee.com:liaoxuefeng/learngit.git

此时，我们再查看远程库信息：

  1. git remote -v
  2. origin    git@gitee.com:liaoxuefeng/learngit.git (fetch)
  3. origin    git@gitee.com:liaoxuefeng/learngit.git (push)

现在可以看到，origin已经被关联到Gitee的远程库了。通过git push命令就可以把本地库推送到Gitee上。

有的小伙伴又要问了，一个本地库能不能既关联GitHub，又关联Gitee呢？

答案是肯定的，因为git本身是分布式版本控制系统，可以同步到另外一个远程库，当然也可以同步到另外两个远程库。

使用多个远程库时，我们要注意，git给远程库起的默认名称是origin，如果有多个远程库，我们需要用不同的名称来标识不同的远程库。

仍然以learngit本地库为例，我们先删除已关联的名为origin的远程库：

  1. git remote rm origin

然后，先关联GitHub的远程库：

  1. git remote add github git@github.com:michaelliao/learngit.git

注意，远程库的名称叫github，不叫origin了。

接着，再关联Gitee的远程库：

  1. git remote add gitee git@gitee.com:liaoxuefeng/learngit.git

同样注意，远程库的名称叫gitee，不叫origin。

现在，我们用git remote -v查看远程库信息，可以看到两个远程库：

  1. git remote -v
  2. gitee    git@gitee.com:liaoxuefeng/learngit.git (fetch)
  3. gitee    git@gitee.com:liaoxuefeng/learngit.git (push)
  4. github    git@github.com:michaelliao/learngit.git (fetch)
  5. github    git@github.com:michaelliao/learngit.git (push)

如果要推送到GitHub，使用命令：

  1. git push github master

如果要推送到Gitee，使用命令：

  1. git push gitee master

这样一来，我们的本地库就可以同时与多个远程库互相同步：

  1. ┌─────────┐ ┌─────────┐
  2. │ GitHub  │ │  Gitee  │
  3. └─────────┘ └─────────┘
  4.      ▲           ▲
  5.      └─────┬─────┘
  6.            │
  7.     ┌─────────────┐
  8.     │ Local Repo  │
  9.     └─────────────┘

Gitee也同样提供了Pull request功能，可以让其他小伙伴参与到开源项目中来。你可以通过Fork我的仓库：https://gitee.com/liaoxuefeng/learngit，创建一个your-gitee-id.txt的文本文件， 写点自己学习Git的心得，然后推送一个pull request给我，这个仓库会在Gitee和GitHub做双向同步。