开发技能之 Git使用笔记

Wayne鱼
254 阅读20分钟

一. git init & add & commit

  • git init 命令初始化一个 Git 仓库，Git 的很多命令都需要在 Git 的仓库中运行，所以 git init 是使用 Git 的第一个命令。

    在执行完成 git init 命令后，Git 仓库会生成一个 .git 目录，该目录包含了资源的所有元数据，其他的项目目录保持不变（Git 只在仓库的根目录生成 .git 目录）。

1. 初始化仓库

  • 使用当前目录作为Git仓库，我们只需使它初始化。

    git init

    该命令执行完后会在当前目录生成一个 .git 目录。

    使用我们指定目录作为Git仓库。

    git init test

    初始化后，会在 test 目录下会出现一个名为 .git 的目录，所有 Git 需要的数据和资源都存放在这个目录中。

2. 添加文件并提交

  • 如果当前目录下有几个文件想要纳入版本控制，需要先用 git add 命令告诉 Git 开始对这些文件进行跟踪，然后commit提交：

    $ git add *.py
$ git add test.txt #add的文件必须存在于本地仓库，不能是其他文件夹的
$ git commit -m 'add .py & txt files'
[master (root-commit) 94f7028] add tt.py and test.txt
 2 files changed, 2 insertions(+)
 create mode 100644 test.txt
 create mode 100644 tt.py

  • 以上命令将目录下以 .py结尾及test.txt文件提交到仓库中。

    几个概念：本地、服务器、中央服务器（远程服务器）。每一次commit是提交到本机的服务器，这个不需要联网，即所谓的版本管理，就是要方便我们知道每一个版本，比如回到之前的某个版本（这是其一），而且回退到某个之前的版本，也是从本机的服务器拿的数据，这些都不需要联网。只有在Push、pull 的时候需要联网，而我们平时更多的操作应是commit。

    简单解释一下git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。 git commit命令执行成功后会告诉你，2 files changed：2个文件被改动（我们新添加的两个文件）；2 insertions：插入了两行内容。

二. git status & diff & log & reset & reflog

1. 查看git状态

  • 现在已经成功提交了tt.py 和test.txt 两个文件，现在修改text.txt文件，运行git status命令看看结果：

    $ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
  
  modified:   test.txt
​
no changes added to commit (use "git add" and/or "git commit -a")

    git status命令可以让我们时刻掌握仓库当前的状态，上面的命令输出告诉我们，test.txt被修改过了，但还没有准备提交的修改。

2. 查看具体修改内容

  • 虽然Git告诉我们test.txt被修改了，可以用git diff命令看具体修改内容：

    $ git diff test.txt 
diff --git a/test.txt b/test.txt
index 5734b72..80efc7f 100644
--- a/test.txt
+++ b/test.txt
@@ -1 +1 @@
-ajfidajfia
+ajfidajfiaaaabbbcccddd
(END)

    git diff顾名思义就是查看difference，显示的格式正是Unix通用的diff格式。

    知道了对test.txt作了什么修改后，再把它提交到仓库就放心多了，提交修改和提交新文件是一样的两步：

    $ git add test.txt
$ git commit -m "modify test.txt"

3. 查看历史版本

  • 版本回退：

    再修改一次test.txt文件，内容改为：testtest。

    commit相当于一个快照。一旦文件改乱了或者误删了，还可以从==最近的一个==commit恢复，然后继续工作，而不是把几个月的工作成果全部丢失。

    现在，我们回顾一下test.txt文件一共有几个版本被提交到Git仓库里了：

    版本1：add tt.py and test.txt

    ajfidajfia

    版本2：modify test.txt

    ajfidajfiaaaabbbcccddd

    版本3：modify 2 test.txt

    testtest

    在实际工作中，我们怎么可能记得一个几千行的文件每次都改了什么内容，不然要版本控制系统干什么。版本控制系统肯定有某个命令可以告诉我们历史记录，在Git中，我们用git log命令查看：

    $ git log
commit ee7d4c28482da3c57b9d4a1dc6634b6998a4d698 (HEAD -> master)
Author: MR.YUAN <mryuan0428@126.com>
Date:   Mon Aug 10 23:19:49 2020 +0800
​
    modify 2 test.txt
​
commit cd5c4ce06f28ab3711a286e9a339015352db9b32
Author: MR.YUAN <mryuan0428@126.com>
Date:   Mon Aug 10 23:19:07 2020 +0800
​
    modify test.txt
​
commit 94f7028c9f1e252232f426f63fe2b472081fb642
Author: MR.YUAN <mryuan0428@126.com>
Date:   Mon Aug 10 22:50:33 2020 +0800
​
    add tt.py and test.txt

  • 版本号： 友情提示: 一大串类似ee7d4c284...的是commit id（版本号），和SVN不一样，Git的commit id不是1，2，3……递增的数字，而是一个SHA1计算出来的一个非常大的数字，用十六进制表示。

4. 版本回退

  • 启动时光穿梭机：准备把test.txt回退到上一个版本，也就是modify test.txt的那个版本，怎么做呢？

    首先，Git必须知道当前版本是哪个版本，==在Git中，用 ‘HEAD’ 表示当前版本==，也就是最新的提交ee7d4c284...上一个版本就是==HEAD^==，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

    现在，我们要把当前版本modify 2 test.txt回退到上一个版本modify test.txt，就可以使用git reset命令：

    $ git reset --hard HEAD^
HEAD is now at cd5c4ce modify test.txt

    --hard参数有啥意义？这个后面再讲，现在先放心使用。

    这样操作后，test.txt 文件就被还原了。

5. 版本回退撤销

  • 最新的那个版本modify 2 test.txt已经看不到了！好比你从21世纪坐时光穿梭机来到了19世纪，想再回去已经回不去了，肿么办？

    办法其实还是有的，只要上面的命令行窗口还没有被关掉，你就可以顺着往上找啊找啊，找到那个modify 2 test.txt的commit id是ee7d4c2...，于是就可以指定回到未来的某个版本：

    $ git reset --hard ee7d4c2
HEAD is now at ee7d4c2 modify 2 test.txt

    版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。test.txt又被还原了。

    Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL：

    ┌────┐
│HEAD│
└────┘
   │
   └──> ○ modify 2 test.txt
        │
        ○ modify test.txt
        │
        ○ add tt.py and test.txt

    改为指向add distributed：

    ┌────┐
│HEAD│
└────┘
   │
   │    ○ modify 2 test.txt
   │    │
   └──> ○ modify test.txt
        │
        ○ add tt.py and test.txt

    然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。

    现在，你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit id怎么办？

    在Git中，总是有后悔药可以吃的。当你用$ git reset --hard HEAD^回退到modify test.txt版本时，再想恢复到modify 2 test.txt，就必须找到modify 2 test.txt的commit id。Git提供了一个命令git reflog用来记录你的每一次命令：

    $ git reflog
cd5c4ce (HEAD -> master) HEAD@{0}: reset: moving to HEAD^
ee7d4c2 HEAD@{1}: reset: moving to ee7d4c2
cd5c4ce (HEAD -> master) HEAD@{2}: reset: moving to HEAD~2
2c47f69 HEAD@{3}: commit: modify 3 test.txt
bf60242 HEAD@{4}: commit: modify 2 test.txt
cd5c4ce (HEAD -> master) HEAD@{5}: reset: moving to HEAD^
ee7d4c2 HEAD@{6}: commit: modify 2 test.txt
cd5c4ce (HEAD -> master) HEAD@{7}: commit: modify test.txt
94f7028 HEAD@{8}: commit (initial): add tt.py and test.txt

    终于舒了口气，从输出可知，modify 2 test.txt的commit id是ee7d4c2，现在，你又可以乘坐时光机回到未来了。

三. 工作区与暂存区 git checkout & restore & rm

1. 工作区（Working Directory）

  • 在电脑里能看到的目录，比如现在的test文件夹就是一个工作区

2. 版本库（Repository）

  • 工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

    Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

  • 把文件往Git版本库里添加的时候，是分两步执行的：

    第一步是用git add把文件添加进去，==实际上就是把文件修改添加到暂存区==；

    第二步是用git commit提交更改，实际上就是==把暂存区的所有内容提交到当前分支==。

  • 创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。

3. 丢弃修改

  • 修改了test.txt 文件后，没有提交到暂存区，查看git status:

    $ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
modified:   test.txt
​
no changes added to commit (use "git add" and/or "git commit -a")

    不需手动修改，git checkout -- file可以丢弃工作区的修改：

    $ git checkout -- test.txt

    或者可以使用git restore test.txt:

    $ git restore test.txt

    命令git checkout -- test.txt意思就是，把test.txt文件在工作区的修改全部撤销，这里有两种情况：

    一种是test.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

    一种是test.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

    总之，就是让这个文件==回到最近一次 ‘git commit’或 ‘git add’ 时的状态==。

  • 修改了test.txt 文件并且提交到暂存区，查看git status:

    $ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
  modified:   test.txt

    不需手动修改，git reset HEAD <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区：：

    $ git reset HEAD test.txt

    或者可以使用git restore --staged test.txt:

    $ git restore --staged test.txt

    然后可以采用上一步的命令，从工作区丢弃修改。

  • 修改了test.txt 文件并且提交到版本库：git reset --hard HEAD^版本回退。

4. 删除文件

  • 在Git中，删除也是一个修改操作，先添加一个新文件a.txt到Git并且提交：

    $ git add a.txt
​
$ git commit -m "add a.txt"
[master 3a7e9d6] add a.txt
 1 file changed, 1 insertion(+)
 create mode 100644 a.txt

    删除a.txt 文件：

    $ rm a.txt

    这个时候，Git知道删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了：

    $ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
  deleted:    a.txt
​
no changes added to commit (use "git add" and/or "git commit -a")

    ==两个选择==: 一是确实要从版本库中删除该文件，那就用命令git rm <file>删掉，并且git commit：

    $ git rm a.txt
rm 'a.txt'
​
$ git commit -m "remove a.txt"
[master b6555b2] rm a.txt
 1 file changed, 1 deletion(-)
 delete mode 100644 a.txt

    现在，文件就从版本库中删除了。

    另一种情况是删错了，因为版本库里还有呢，所以可以把误删的文件恢复到最新版本：

    $ git checkout -- a.txt

    或者是

    $ git restore a.txt

    git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

    ==注意==：从来没有被添加到版本库就被删除的文件，是无法恢复的！

四. 远程仓库 git remote add & push & clone

1. GitHub远程仓库

  • 可以自己搭建一台运行Git的服务器，不过可以使用GitHub——提供仓库托管服务，Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：

    第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell创建SSH Key：

    $ ssh-keygen -t rsa -C "youremail@example.com"

    id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以告诉任何人。

    第2步：登陆GitHub，打开“settings”，“SSH Keys”页面：

    然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容

2. 添加远程仓库

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

    首先，登陆GitHub创建一个新的仓库 test。

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

    本地的test仓库下运行命令：

    $ git remote add origin git@github.com:mryuan0428/test.git

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

  • 下一步，就可以把本地库的所有内容推送到远程库上：

    $ git push -u origin master
The authenticity of host 'github.com (13.250.177.223)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com,13.250.177.223' (RSA) to the list of known hosts.
Enumerating objects: 14, done.
Counting objects: 100% (14/14), done.
Delta compression using up to 8 threads
Compressing objects: 100% (9/9), done.
Writing objects: 100% (14/14), 1.13 KiB | 1.13 MiB/s, done.
Total 14 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), done.
To github.com:mryuan0428/test.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

    把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。

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

  • 从现在起，只要本地作了提交，就可以通过命令：

    $ git push origin master

    ==报错，最后加 -f==。

    把本地master分支的最新修改推送至GitHub。

3. 从远程库克隆

  • 假设从零开发，那么最好的方式是先创建远程库，然后，从远程库克隆。

    首先，登陆GitHub，创建一个新的仓库，名字叫test2。

    远程库已经准备好了，下一步是用命令git clone克隆一个本地库：

    $ git clone git@github.com:mryuan0428/test2.git
Cloning into 'test2'...
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.

  • 如果多人协作开发，那么每个人各自从远程克隆一份就可以了。

    GitHub给出的地址不止一个，还可以用https://github.com/michaelliao/gitskills.git这样的地址。实际上，Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。

    使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。

五. 分支管理 git branch & checkout & merge & switch & stash & cherry-pick & remote & pull & rebase

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

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

1. 创建与合并分支

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

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

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

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

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

    假如我们在dev上的工作完成了，就可以把dev合并到master上。Git直接把master指向dev的当前提交，就完成了合并：

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

  • 开始实战：

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

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

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

      $ git branch dev
$ git checkout dev
Switched to branch 'dev'

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

      $ git branch
* dev
  master

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

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

      Creating a new branch is quick.

      然后提交：

      $ git add README.md 
$ git commit -m "branch test"
[dev 7eabc25] branch test
 1 file changed, 1 insertion(+)

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

      $ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.

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

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

      $ git merge dev
Updating 32fcb73..7eabc25
Fast-forward
 README.md | 1 +
 1 file changed, 1 insertion(+)

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

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

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

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

      $ git branch -d dev
Deleted branch dev (was 7eabc25).

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

    • switch命令：

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

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

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

      $ git switch -c dev

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

      $ git switch master

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

2. 解决冲突

  • 合并分支也有可能出现冲突

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

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

    修改README.md最后一行，改为：

    Creating a new branch is quick AND simple.

    在feature1分支上提交：

    $ git add README.md
​
$ git commit -m "AND simple"
[feature1 dd2bcfd] AND simple
 1 file changed, 1 insertion(+)

    切换到master分支：

    $ git switch 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.md文件的最后一行改为：

    Creating a new branch is quick & simple.

    提交：

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

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

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

    $ git merge feature1
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
Automatic merge failed; fix conflicts and then commit the result.

    Git告诉我们，README.md文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件：

    $ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
  (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:
  (use "git add <file>..." to mark resolution)
  both modified:   README.md
​
no changes added to commit (use "git add" and/or "git commit -a")

我们可以直接查看README.md的内容：

    test2
    Creating a new branch is quick.
    <<<<<<< HEAD
    Creating a new branch is quick & simple.
    =======
    Creating a new branch is quick AND simple.
    >>>>>>> feature1

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

    Creating a new branch is quick and simple.

再提交：

    $ git add README.md
$ git commit -m "and simple"
    [master 3fb2f1b] and simple

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

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

    $ git log --graph --pretty=oneline --abbrev-commit
*   3fb2f1b (HEAD -> master) and simple
    |\
    | * dd2bcfd (feature1) AND simple
    * | 2dd2e80 & simple
    |/
    * 2689e0e (origin/master, origin/HEAD) add a
    * 7eabc25 branch test
    * 32fcb73 Create README.md

最后，删除`feature1`分支：
​
```bash
$ git branch -d feature1
Deleted branch feature1 (was 14096d0).
```

3. 分支管理策略

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

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

    下面演示--no-ff方式的git merge：

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

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

    修改README.md文件，并提交一个新的commit：

    $ git add README.md
$ git commit -m "add merge"
[dev 34b876e] add merge
 1 file changed, 1 insertion(+)

    现在，我们切换回master：

    $ git switch 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.md | 1 +
 1 file changed, 1 insertion(+)

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

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

    $ git log --graph --pretty=oneline --abbrev-commit
*   12faa5b (HEAD -> master) merge with no-ff
|\
| * 34b876e (dev) add merge
| * 1414323 del a
|/
*   3fb2f1b and simple
|\
| * dd2bcfd AND simple
* | 2dd2e80 & simple
|/
* 2689e0e (origin/master, origin/HEAD) add a
* 7eabc25 branch test
* 32fcb73 Create README.md

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

  • 分支策略:

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

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

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

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

4. 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

    工作只进行到一半，没办法提交，怎么操作？

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

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

    现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复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，需要把“dev branch”改为“dev branch - master”，然后提交：

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

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

    $ git switch 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(-)

    再回到dev分支干活：

    $ git switch 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: 12faa5b merge with no-ff

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

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

    另一种方式是用git stash pop，恢复的同时把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

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

    $ git stash apply stash@{0}

  • dev分支是早期从master分支分出来的，所以，==这个bug其实在当前dev分支上也存在==。

    那怎么在dev分支上更简单地修复同样的bug？

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

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

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

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

5. Feature分支

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

    添加一个新功能时，肯定不希望因为一些实验性质的代码，把主分支搞乱。

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

    现在：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。

    于是准备开发：

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

    5分钟后，开发完毕：

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

    切回dev，准备合并：

    $ git switch dev

    假设此时接到要求，新功能取消！这个包含机密资料的分支必须就地销毁：

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

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

    现在我们强行删除：

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

    删除成功.

6. 多人协作

  • 从远程仓库克隆时，实际上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的地址。

  • 推送分支：

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

    $ git push origin master

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

    $ git push origin dev

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

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

    总之，就是在Git中，分支完全可以在本地自己藏着玩。

  • 抓取分支：

    多人协作时，大家都会往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分支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
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

  • 开发伙伴已经向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)
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分支的链接，根据提示，设置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成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再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

7. Rebase

  • 在上一节我们看到了，多人在同一个分支上协作时，很容易出现冲突。

    即使没有冲突，后push的不得不先pull，在本地合并，然后才能push成功。

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

    $ git log --graph --pretty=oneline --abbrev-commit
* d1be385 (HEAD -> master, origin/master) init hello
*   e5e69f1 Merge branch 'dev'
|\  
| *   57c53ab (origin/dev, dev) fix env conflict
| |\  
| | * 7a5e5dd add env
| * | 7bd91f1 add new env
| |/  
* |   12a631b merged bug fix 101
|\ \  
| * | 4c805e2 fix bug 101
|/ /  
* |   e1e9c68 merge with no-ff
|\ \  
| |/  
| * f52c633 add merge
|/  
*   cf810e4 conflict fixed

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

    Git有一种称为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，本地分支比远程分支快两个提交。

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

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

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

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

    再用git status看看状态：

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

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

    用git log看看：

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

    提交历史分叉了，这个时候，rebase就派上了用场：

    $ git rebase
First, rewinding head to replay your work on top of it...
Applying: add comment
Using index info to reconstruct a base tree...
M hello.py
Falling back to patching base and 3-way merge...
Auto-merging hello.py
Applying: add author
Using index info to reconstruct a base tree...
M hello.py
Falling back to patching base and 3-way merge...
Auto-merging hello.py

    再用git log看看：

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

    原本分叉的提交现在变成一条直线了，Git把本地的提交“挪动”了位置，放到了f005ed4 (origin/master) set exit=1之后，这样，整个提交历史就成了一条直线。rebase操作前后，最终的提交内容是一致的，但是本地的commit修改内容已经变化了，它们的修改不再基于d1be385 init hello，而是基于f005ed4 (origin/master) set exit=1，但最后的提交7e61ed4内容是一致的。

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

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

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

    再用git log看看效果：

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

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

六. 标签管理 git tag

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

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

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

    请把上周一的那个版本打包发布，commit号是6a5819e...——一串乱七八糟的数字不好找。

    换一个办法：

    请把上周一的那个版本打包发布，版本号是v1.2——按照tag v1.2查找commit就行。

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

1. 创建标签

  • 首先，切换到需要打标签的分支上：

    $ git branch
* dev
  master
$ git checkout master
Switched to branch 'master'

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

    $ git tag v1.0

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

    $ git tag
v1.0

    默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，可以找到历史提交的commit id，然后打上就可以了：

    $ git log --pretty=oneline --abbrev-commit
12a631b (HEAD -> master, tag: v1.0, origin/master) merged bug fix 101
4c805e2 fix bug 101
e1e9c68 merge with no-ff
f52c633 add merge
cf810e4 conflict fixed
5dc6824 & simple
14096d0 AND simple
b17d20e branch test
d46f35e 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

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

    $ git tag v0.9 f52c633

    再用命令git tag查看标签：

    $ git tag
v0.9
v1.0

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

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

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

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

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

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

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

2. 操作标签

  • 标签打错了也可以删除：

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

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

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

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

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

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

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

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

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

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

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

avatar
文章
阅读
粉丝