Git学习篇（2）

之前的git学习是在本地进行操作过程，但是如果要进行多人写作，交互版本库中的内容，势必要使用到github上的远程仓库。

因此，在本地创建了一个Git仓库后，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作

远程仓库

一、创建远程仓库+本地库与远程库同步

1. 登陆GitHub，然后，在右上角找到“Create a new repo”按钮，创建一个新的仓库

2. 目前，在GitHub上的这个gitLearned仓库还是空的，GitHub告诉我们：

   • 可以从这个仓库克隆出新的本地仓库

     • 

   • 也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到GitHub仓库

     • 

3. 在本地仓库A下，运行git remote add origin git@github.com:<用户名>/<远程仓库名>.git将本地仓库A和远程仓库名指定的仓库进行关联

   • 在git bash中进入一个已经用git init初始化好的本地版本库

   • 通过git remote add origin git@github.com:<用户名>/<远程仓库名>.git将该本地版本库和远程仓库相连

     • 远程库的名字就是`origin`，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。

   • 通过git push将本地版本库的内容推送到远程github仓库

     • 用git push命令，实际上是把当前分支master推送到远程。

     • 由于远程库是空的，我们**第一次**推送`master`分支时，**加上了`-u`参数**，Git不但会把本地的`master`分支内容推送的远程新的`master`分支，还会**把本地的`master`分支和远程的`master`分支关联起来，在以后的推送或者拉取时就可以简化命令**。

     • 此时，GitHub页面中看到远程库的内容已经和本地一模一样

       

4. 只要本地作了提交，就可以通过命令

   $ git push origin master

   把本地master分支的最新修改推送至GitHub，现在，就拥有了真正的分布式版本库

二、从远程库克隆

1. 登陆GitHub，创建一个新的仓库，名字叫gittest2s，勾选Initialize this repository with a README，这样GitHub会自动为我们创建一个README.md文件。

2. 用命令git clone将远程仓库gittest2克隆成为一个本地库

   

3. GitHub给出的地址不止一个，还可以用https://github.com/spidermana/gitstest2.git这样的地址。实际上，Git支持多种协议：

   • 默认的git://使用ssh
   • 但也可以使用https等其他协议。
   • 使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令【为了安全性】，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https协议。

三、小结

• 关联

  • 要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；
  • 关联后，使用命令git push -u origin master第一次推送master分支的所有内容；
  • 此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；

• 克隆

  • 要克隆一个仓库，首先必须知道仓库的地址，然后使用git clone命令克隆。
  • Git支持多种协议，包括https，但通过ssh支持的原生git协议速度最快。
• 分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作，当有网络的时候，再把本地提交推送一下就完成了同步！【而SVN在没有联网的时候是拒绝干活的！】

分支管理

一、引入分支的缘由

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

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

Git的分支是与众不同的，无论创建、切换和删除分支，Git在1秒钟之内就能完成！无论你的版本库是1个文件还是1万个文件。

二、创建和合并分支

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

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

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

1.分支创建

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

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

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

2.分支合并

假如我们在dev上的工作完成了，就可以把dev合并到master上。

Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交【而后HEAD再指向master】，就完成了合并：

• 切换当前分支为master—->git checkout master

  

• git merge dev：将当前分支和dev分支合并【当前分支HEAD此时指向master】,也就是将master分支和dev分支合并

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

3.分支删除

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

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

4.小结

• 创建并切换分支：git checkout -b dev

  • 

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

    $ git branch dev   //创建分支
    $ git checkout dev //切换当前分支到dev
    Switched to branch 'dev'
    

• 查看[当前]分支：git branch

  • git branch命令会列出所有分支
  • 当前分支前面会标一个*号。
  • 切换到dev为当前分支以后，git commit将为提交到该版本库的dev分支上，即修改文件+git add+git commit -m”"将会提交到版本库的当前分支上。

• 切换分支：git checkout <分支名>

  • 如果add+commit提交修改到dev分支，那么切换当前回master，那个提交的修改将不会再master中体现。【原因在于提交是在dev分支上，而master分支此刻的提交点并没有变】

    

• 合并分支：git merge <分支名>

  • 将当前分支和分支名指定的分支进行合并

  • 

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

    $git checkout master
    $git merge dev
    Updating d46f35e..b17d20e
    Fast-forward
     readme.txt | 1 +
     1 file changed, 1 insertion(+)
    

    • git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。
    • 注意到上面的`Fast-forward`信息，Git告诉我们，这次合并是“快进模式”，也就是直接把`master`指向`dev`的当前提交，所以合并速度非常快。
    • 当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。

• 删除分支：git branch -d <分支名>

  • 合并不代表，原来的分支【dev】没了，只是当前的分支【master】更新了。

• 分支语句小结

  • 查看分支：git branch
  • 创建分支：git branch <name>
  • 切换分支：git checkout <name>
  • 创建+切换分支：git checkout -b <name>
  • 合并某分支到当前分支：git merge <name>
  • 删除分支：git branch -d <name>

三、分支冲突

合并分支往往不是一帆风顺的。

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

$ git checkout -b feature1
Switched to a new branch 'feature1'

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

Creating a new branch is quick AND simple.

在feature1分支上提交：

$ git add readme.txt

$ git commit -m "AND simple"
[feature1 14096d0] AND simple
 1 file changed, 1 insertion(+), 1 deletion(-)

切换到master分支：

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

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

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

Creating a new branch is quick & simple.

提交：

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

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

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

$ git merge feature1   //即使有冲突也尝试合并了，最后是HEAD是指向带有冲突的合并分支master
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.

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

$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)

You have unmerged paths. //存在无法合并清楚的部分
  (fix conflicts and run "git commit") //要么人为修复，再提交
  (use "git merge --abort" to abort the merge) //要么丢弃不能合并的部分

Unmerged paths: //存在无法自动合并好的paths
  (use "git add <file>..." to mark resolution)

    both modified:   readme.txt //都修改了readme.txt，而且有修改部分重叠且修改不同，从而导致git不知道最终选择重叠修改的哪个进行合并

no changes added to commit (use "git add" and/or "git commit -a")

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

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD   //①
Creating a new branch is quick & simple. //②
=======      //③
Creating a new branch is quick AND simple.
>>>>>>> feature1  //④

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们手动修改一下readme.txt【删掉①-④】

然后后保存，再提交：

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

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

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

$ git log --graph --pretty=oneline --abbrev-commit
*   cf810e4 (HEAD -> master) conflict fixed  //合并为master分支，HEAD指向master
|\  
| * 14096d0 (feature1) AND simple   //feature1分支
* | 5dc6824 & simple   //master分支
|/  
* b17d20e branch test
* d46f35e (origin/master) remove test.txt
* b84166e add test.txt
* 519219b git tracks changes
* e43a48b understand how stage works
* 1094adb append GPL
* e475afc add distributed
* eaadf4e wrote a readme file

最后，删除feature1分支：

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

工作完成。

小结

• 当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
• 解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。
• 用`git log --graph`命令可以看到分支合并图。

四、分支管理策略

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

如果要强制禁用Fast forward模式【–no-ff】，Git就会在merge时生成一个新的commit【也就是最终的合并分支会再往前走一个节点】，这样，从分支历史上就可以看出分支信息。

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

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

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

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

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

现在，我们切换回master：

$ git checkout master
Switched to branch 'master'

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

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

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

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

$ git log --graph --pretty=oneline --abbrev-commit
*   e1e9c68 (HEAD -> master) merge with no-ff
|\  
| * f52c633 (dev) add merge
|/  
*   cf810e4 conflict fixed //没有标明的就是当前分支master
...

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

多人协作分支策略

• 在实际开发中，我们应该按照几个基本原则进行分支管理：
  • 首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
  • 干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
  • 你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
• 所以，团队合作的分支看起来就像这样：

小结

• 合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支【否则分支合并以后，就看不出来以前有过合并，就合并成为一条主线了】，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。
• 如果是冲突合并，那么历史分支会保留，因为此时不是fast forward合并

五、Bug分支

当前工作区只有一个，这个工作区跑在某个分支上，但是可能你在进行工作的时候，有别的分支要修复，那么你就得切换到另外分支去修复任务。但是工作区只有一个，这个分支的任务没有完成，如果你没法提交【因为还没做完】，那么这个工作区就是脏的，这时候如果切换到别的分支去修复bug，那么这个工作区的内容就没了，变成切换到的分支的工作区状态了。

那么怎么办？

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

$ git status
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   hello.py

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   readme.txt

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

1.暂存工作现场git stash

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

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

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

2.在某个分支A上创建bug分支来修复bug，在bug分支修复完再合并到分支A，删除bug分支

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

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
  (use "git push" to publish your local commits)

$ git checkout -b issue-101
Switched to a new branch 'issue-101'

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

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

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

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
  (use "git push" to publish your local commits)

$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 readme.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

$ git checkout dev
Switched to branch 'dev'

$ git status
On branch dev
nothing to commit, working tree clean

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

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

3.还原工作现场

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

• 一是用git stash list查看stash栈/列表的情况【暂存了所有需要暂存的工作区】，确定需要回复工作区stash标识，通过命令git stash apply恢复【后跟stash标识，比如git stash apply stash@{0}】，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

• 另一种方式是用git stash pop【pop出stash栈顶的那个stash内容到工作区】，恢复的同时把stash内容也删了：

$ git stash pop
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   hello.py

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   readme.txt

Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)

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

$ git stash list

4.小结

• 修复bug时，通过创建新的bug分支进行修复，然后合并，最后删除bug分支；
• 当手头工作没有完成时，先把工作现场git stash一下【暂存工作区】，【切换分支，工作区变成那个分支的工作区】然后去修复bug，修复后，再git stash pop，回到工作现场。

六、Feature分支

• 每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。

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

  • 没有合并过的分支直接删除会提示：error: The branch ‘feature-vulcan’ is not fully merged.
  • 因为没有合并，那么如果删除，将丢失掉修改
  • 如果要强行删除，需要使用大写的-D参数

七、多人协作

1.远程仓库信息

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

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

$ git remote
origin

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

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

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

2.推送分支

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

$ git push origin master

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

$ git push origin dev

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

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

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

3.抓取分支

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

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

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

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

$ git branch
* master

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

$ git checkout -b dev origin/dev  //创建远程仓库中的dev分支到本地的dev分支，并且切换到dev分支

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

$ git add env.txt

$ git commit -m "add env"
[dev 7a5e5dd] add env
 1 file changed, 1 insertion(+)
 create mode 100644 env.txt

$ git push origin dev  //将本地的dev分支推送到远程仓库origin中
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 308 bytes | 308.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
   f52c633..7a5e5dd  dev -> dev                //本地的dev分支会推送到远端的对应分支上，即dev

4.多人推送同一个分支

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

$ cat env.txt
env

$ git add env.txt

$ git commit -m "add new env"
[dev 7bd91f1] add new env
 1 file changed, 1 insertion(+)
 create mode 100644 env.txt

$ git push origin dev
To github.com:michaelliao/learngit.git
 ! [rejected]        dev -> dev (non-fast-forward)   
 //rejected，拒绝了dev和远程dev的合并或说拒绝了对远程dev的更新，因为合并冲突
error: failed to push some refs to 'git@github.com:michaelliao/learngit.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

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

$ git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

    git pull <remote> <branch>

If you wish to set tracking information for this branch you can do so with:

    git branch --set-upstream-to=origin/<branch> dev

git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接【因为不知道拉到哪里，默认是拉到本地的同名分支，因此要建立链接，否则就要指定具体拉到的分支位置git pull <remote> <branch>】，根据提示，设置`dev`和`origin/dev`的链接：

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

再pull：

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

这回git pull成功，但是合并有冲突，需要手动解决【现在将远程的dev拉到本地了，因为远程push合并的时候产生了冲突，因此肯定拉下来也会和本地的dev产生冲突，因此现在要在本地解决冲突】，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push：

$ git commit -m "fix env conflict"
[dev 57c53ab] fix env conflict

$ git push origin dev
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (6/6), 621 bytes | 621.00 KiB/s, done.
Total 6 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
   7a5e5dd..57c53ab  dev -> dev

5.多人协作工作模式

• 多人协作的工作模式通常是这样：
  • 首先，可以试图用git push origin <branch-name>推送自己的修改；
  • 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
  • 如果合并有冲突，则解决冲突，并在本地提交；
  • 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！
• 如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to=origin/<branch-name> <本地branch-name> 。

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

6.小结

• 查看远程库信息，使用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【补】

• rebase操作可以把本地未push的分叉提交历史整理成直线；

• rebase的目的是使得我们在查看历史提交的变化时更容易，因为分叉的提交需要三方对比。

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

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

  注意到Git用(HEAD -> master)和(origin/master)标识出当前分支的HEAD和远程origin的位置分别是582d922 add author和d1be385 init hello

九、标签管理

1.引入原因

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

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

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

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

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

如果换一个办法：

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

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

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

3.对commit打标签

• 命令git tag <tagname>用于新建一个标签，默认为HEAD，也可以指定一个commit id；
  • git checkout <branch-name>:切换到需要打标签的分支
  • git tag v1.0：标签v1.0打在默认当前分支的最新commit上
  • git tag v0.9 f52c633:对当前分支的历史打标签，可以找到历史提交的commit id，然后打上标签
• 命令git tag -a <tagname> -m "blablabla..."可以创建带有说明的标签；
  • -a指定标签名
  • -m指定说明文字
• 命令git show <tagname>：查看某个标签的具体信息
• 命令git tag可以查看所有标签。
  • 标签不是按时间顺序列出，而是按字母排序的。
• 标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签。

4.操作标签

• 命令git tag -d <tagname>可以删除一个本地标签；
  • 因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
• 命令git push origin <tagname>可以推送一个本地标签到远程；
• 命令git push origin --tags可以推送全部未推送过的本地标签到远程；
• 删除远程标签
  • 先从本地删除git tag -d v0.9
  • 再从远程删除标签，删除命令也是push，通过命令git push origin :refs/tags/<tagname>
    • git push origin :refs/tags/v0.9
    • 登陆GitHub查看是否真的删除

十、其他

• 命令总览

  

• 配置Git的时候，加上--global是针对当前用户起作用的，如果不加，那只针对当前的仓库起作用。

• 当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中

  • cat .gitconfig

• 配置别名：git config --global alias.<别名> <原名>

  • --global参数是全局参数，也就是这些命令在这台电脑的所有Git仓库下都有用。

  • 还有人丧心病狂地把lg配置成了：

    git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
    

    来看看git lg的效果：

    

• Previous
  Git学习（1）
• Next
  “hitcon pwn writeUp（一）”