zoukankan      html  css  js  c++  java
  • Git系列二之数据管理

    1.Git基本管理

    git常用的基本操作

    1.1提交数据

    我们可以简单的把工作目录理解成是一个被Git服务程序管理的目录,Git会时刻的追踪目录内文件的改动,另外在安装好了Git服务程序后,默认就会创建好了一个叫做master的分支,我们直接可以提交数据到了

    1.创建本地工作目录demo,并初始化为git工作目录

    [root@git-node1 ~]# mkdir demo
    [root@git-node1 ~]# cd demo/
    [root@git-node1 git-demo]# git init
    Initialized empty Git repository in /root/demo/.git/

    2.创建readme.txt文件

    [root@rabbitmq demo]# vi index.html 
    welcome nulige

    3.查看git状态

    [root@rabbitmq demo]# git status
    # On branch master
    # Changed but not updated:
    #   (use "git add <file>..." to update what will be committed)
    #   (use "git checkout -- <file>..." to discard changes in working directory)
    #
    #       modified:   index.html
    #
    no changes added to commit (use "git add" and/or "git commit -a")

    4.提示使用git add添加文件至暂存区

    [root@rabbitmq demo]# git add index.html  #添加到暂存区
    
    [root@rabbitmq demo]# git status   #查看变更状态
    # On branch master
    # Changes to be committed:
    #   (use "git reset HEAD <file>..." to unstage)
    #
    #       modified:   index.html
    #

    5.使用git cmmit提交暂存区文件至git版本仓库 -m:提交描述信息(提交至远程需添加远程仓库)

    [root@git-node1 demo]# git commit -m "the first commit index.html"
    [master(根提交) 85bd268] the first commit index.html
    1 file changed, 0 insertions(+), 0 deletions(-)
    create mode 100644 index.html

    1.2移除数据

    有些时候会将已经添加到暂存区的文件移除,但仍然希望文件在工作目录中不丢失,换句话说,就是把文件从追踪清单中删除。

    1.建立新文件

    [root@git-node1 demo]# vi index.php

    Hello nuloge

    2.添加新文件至暂存区

    [root@git-node1 demo]# git add index.php    #添加到暂存区
    [root@git-node1 demo]# git status
    # On branch master
    # Changes to be committed:
    #   (use "git reset HEAD <file>..." to unstage)
    #
    #       new file:   index.php
    #

    3.将新文件从暂存区撤出(并不会删除工作目录内的数据)

    [root@git-node1 demo]# git add index.php  #文件添加到暂存区
    
    [root@git-node1 demo]# git status   #查看文件状态
    # On branch master
    # Changes to be committed:
    #   (use "git reset HEAD <file>..." to unstage)
    #
    #       new file:   index.php
    
    
    [root@git-node1 demo]# git reset HEAD index.php   #从暂存区撤消文件
    
    [root@git-node1 demo]# git status //index.php   #文件状态为未跟踪
    fatal: '//index.php' is outside repository
    
    [root@git-node1 demo]# git status  #查看文件状态
    # On branch master
    # Untracked files:
    #   (use "git add <file>..." to include in what will be committed)
    #
    #       index.php
    nothing added to commit but untracked files present (use "git add" to track)
    #提交为空,但是存在尚未跟踪的文件(使用 "git add" 建立跟踪)
    
    #如果想将文件数据从git暂存区和工作目录一起删除,可以做如下操作。
    [root@git
    -node1 demo]# git add index.php #添加文件到暂存区 [root@git-node1 demo]# git rm index.php #文件已经放入暂存区域,防止误删 error: 'index.php' has changes staged in the index #有变更已暂存至索引中 (use --cached to keep the file, or -f to force removal) #(使用 --cached 保存文件,或用 -f 强制删除) [root@git-node1 demo]# git rm -f index.php #使用追加强制删除-f参数或者-cache保存 rm 'index.php' [root@git-node1 demo]# git status #查看当前状态 # On branch master #位于分支 master nothing to commit (working directory clean) #无文件要提交,干净的工作区 [root@git-node1 demo]# ls #文件已经不存在 index.html

    1.3移动数据

    有些时候会将已经添加到暂存区的文件重新修改名称,可使用如下操作完成。 
    1.git重新命名文件名称,使用git mv操作。

    [root@git-node1 demo]# ls
    index.html
    [root@git-node1 demo]# git mv index.html index.php

    2.使用git status查看更改状态

    [root@git-node1 demo]# git status
    # On branch master
    # Changes to be committed:
    #   (use "git reset HEAD <file>..." to unstage)
    #
    #       renamed:    index.html -> index.php
    #

    3.使用git commit 提交git仓库,并描述提交信息

    [root@git-node1 demo]# git commit -m "chaned name index.html->index.php"
    [master ca24753] chaned name index.html->index.php
     1 files changed, 0 insertions(+), 0 deletions(-)
     rename index.html => index.php (100%)

    1.4历史数据

    在提交了若干更新之后,想回顾下提交历史,可以使用 git log 命令查看提交历史记录。 
    1.查看提交历史记录

    [root@git-node1 demo]# git log
    commit ca24753faac356ae926c89f6d8c2da2ee69d67ec
    Author: nulige <nulige@nulige.com>
    Date:   Mon May 8 20:48:46 2017 +0800
    
        chaned name index.html->index.php
    
    commit 90596d4d1fdcc37e175d18778e2f07a98c42f86b
    Author: root <root@git-node1.(none)>
    Date:   Mon May 8 20:26:08 2017 +0800
    
        the first commit index.html

    2.查看历史1次提交记录

    # -n  (n是一个正整数),查看最近n次的提交信息

    [root@git-node1 demo]# git log -1 commit ca24753faac356ae926c89f6d8c2da2ee69d67ec Author: nulige <nulige@nulige.com> Date: Mon May 8 20:48:46 2017 +0800 chaned name index.html->index.php commit 90596d4d1fdcc37e175d18778e2f07a98c42f86b Author: root <root@git-node1.(none)> Date: Mon May 8 20:26:08 2017 +0800 the first commit index.html

    3.显示提交的内容差异,例如仅查看最近2次差异

    [root@git-node1 demo]# git log -p -2  #显示最近二次更新
    commit ca24753faac356ae926c89f6d8c2da2ee69d67ec
    Author: nulige <nulige@nulige.com>
    Date:   Mon May 8 20:48:46 2017 +0800
    
        chaned name index.html->index.php
    
    diff --git a/index.html b/index.html
    deleted file mode 100644
    index 6e599f4..0000000
    --- a/index.html
    +++ /dev/null
    @@ -1 +0,0 @@
    -welcome nulige
    diff --git a/index.php b/index.php
    new file mode 100644
    index 0000000..6e599f4
    --- /dev/null
    +++ b/index.php
    @@ -0,0 +1 @@
    +welcome nulige
    
    :
    commit ca24753faac356ae926c89f6d8c2da2ee69d67ec
    Author: nulige <nulige@nulige.com>
    Date:   Mon May 8 20:48:46 2017 +0800
    
        chaned name index.html->index.php
    
    diff --git a/index.html b/index.html
    deleted file mode 100644
    index 6e599f4..0000000
    --- a/index.html
    +++ /dev/null
    @@ -1 +0,0 @@
    -welcome nulige
    diff --git a/index.php b/index.php
    new file mode 100644
    index 0000000..6e599f4
    --- /dev/null
    +++ b/index.php
    @@ -0,0 +1 @@
    +welcome nulige
    
    commit 90596d4d1fdcc37e175d18778e2f07a98c42f86b
    Author: root <root@git-node1.(none)>
    Date:   Mon May 8 20:26:08 2017 +0800
    
    : 退出按 q
    4.简要显示数据修改行数
    #--stat: 列出文件的修改行数
    [root@git-node1 demo]# git log --stat commit ca24753faac356ae926c89f6d8c2da2ee69d67ec Author: nulige <nulige@nulige.com> Date: Mon May 8 20:48:46 2017 +0800 chaned name index.html->index.php index.html | 1 - index.php | 1 + 2 files changed, 1 insertions(+), 1 deletions(-) commit 90596d4d1fdcc37e175d18778e2f07a98c42f86b Author: root <root@git-node1.(none)> Date: Mon May 8 20:26:08 2017 +0800 the first commit index.html index.html | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
     
    5.根据不同的格式展示提交的历史信息
     1 [root@git-node1 demo]# git log --pretty=oneline
     2 95734131860ef7c9078b8a208ff6437d0952380b chnged name index.html->index.php
     3 85bd2680bd4b70aeded9dbd230c07ab086712ff9 the first commit index.htm
     4 可以使用format参数来指定具体的输出格式,这样非常便于后期编程的提取分析哦,常用的格式有:
     5 %s 提交说明。
     6 %cd 提交日期。
     7 %an 作者的名字。
     8 %cn 提交者的姓名。
     9 %ce 提交者的电子邮件。
    10 %H 提交对象的完整SHA-1哈希字串。
    11 %h 提交对象的简短SHA-1哈希字串。
    12 %T 树对象的完整SHA-1哈希字串。
    13 %t 树对象的简短SHA-1哈希字串。
    14 %P 父对象的完整SHA-1哈希字串。
    15 %p 父对象的简短SHA-1哈希字串。
    16 %ad 作者的修订时间。
    17 定制详细的日志输出
    18 [root@git-node1 demo]# git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset %cn"' --abbrev-commit --date=relative 19 * 5f3f588 - (HEAD, origin/master, –r, tt, master) merge branch linux readme.txt (68 分钟之前) xulia 20 | 21 | * 4580c3b - (linux) touch readme.txt (80 分钟之前) xuliangwei" 22 * | 4c7a145 - touch readme.txt (72 分钟之前) xuliangwei" 23 |/ 24 * 9573413 - (tag: v1.0.0) chnged name index.html->index.php (5 小时之前) xuliangwei" 25 * 85bd268 - the first commit index.html (5 小时之前) xuliangwei" 26 配置.git/config文件,增加如下2行,以后即可使用 git hlog代替如上复杂命令 27 [root@git-node1 demo]# tail -2 .git/config 28 [alias] 29 hlog = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset %cn' --abbrev-commit --date=relative 30 //以后使用git hlog即可实现复杂的命令 31

    1.5还原数据(称为:回滚)

    将文件hello boos写成了hello nulige,但是已经提交至远程仓库,现在想要撤回重新提交。 
    (本小结涉及远程仓库,可先学习后面章节,在回头学习本章节) 
    1.查看index.html文件

    [root@git-node1 demo]# git checkout -b dev //内容存在dev分支
    [root@git-node1 demo]# cat index.html
    hello boss
    [root@git-node1 demo]# echo "hello nulige" >> index.html

    2.追加内容至index.html,并提交至远程仓库

    [root@git-node1 demo]# git add index.html
    [root@git
    -node1 demo]# git commit -m "hello nulige" [master 1941990] boss dou 1 file changed, 1 insertion(+)
    [root@git
    -node1 demo]# git push origin dev Counting objects: 5, done. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 298 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To git@git-node1:root/git_demo.git 507bf99..1941990 dev -> dev

    3.此时觉得写的不妥,想还原上一次提交的文件快照,找出历史信息

    [root@git-node1 demo]# git log -2
    * 1941990 - (HEAD, origin/dev, dev) boss dou (2 分钟之前) nulige
    * 507bf99 - hello (30 分钟之前) nulige

    4.回滚:找到历史还原点的值后,就可以还原(值不写全,系统会自动匹配)

    [root@git-node1 demo]# git reset --hard 507bf99   #从暂存区那个点,回滚到工作区
    HEAD 现在位于 507bf99 hello
    [root@git-node1 nulige]# git push origin dev -f //强制推送至dev分支
    [root@git-node1 demo]# cat index.html
    hello boss

    5、git reflog 用来记录你的每一次命令

    [root@git-node1 Bastion-of-machine]# git reflog
    08f962f HEAD@{0}: commit (initial): first commit

    1.6 删除操作

    在Git中,删除也是一个修改操作,我们实战一下,先添加一个新文件test.txt到Git并且提交:

    [root@git-node1 demo]# vi test.txt
    I am nulige

    添加到暂存区

    [root@git-node1 demo]# git add .
    [root@git-node1 demo]# git commit -m "add test.txt"
    [master ac0cb7b] add test.txt
     2 files changed, 2 insertions(+), 0 deletions(-)
     create mode 160000 Bastion-of-machine
     create mode 100644 test.txt

    一般情况下,你通常直接在文件管理器中把没用的文件删了,或者用rm命令删了

    [root@git-node1 demo]# rm test.txt 
    rm:是否删除普通文件 "test.txt"?  #回车
    
    #这个时候,Git知道你删除了文件,因此,工作区和版本库就不一致了,git status命令会立刻告诉你哪些文件被删除了: [root@git
    -node1 demo]# git status # On branch master # Changed but not updated: # (use "git add/rm <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # deleted: index.php # deleted: test.txt # no changes added to commit (use "git add" and/or "git commit -a")

    现在你有两个选择,一是确实要从版本库中删除该文件,那就用命令git rm删掉,并且git commit

    [root@git-node1 demo]# ll
    总用量 8
    drwxr-xr-x 3 root root 4096 5月   8 22:12 Bastion-of-machine
    -rw-r--r-- 1 root root   12 5月   8 23:50 test.txt
    
    [root@git-node1 demo]# rm test.txt 
    rm:是否删除普通文件 "test.txt"?
    
    [root@git-node1 demo]# git rm test.txt
    rm 'test.txt'
    
    
    [root@git-node1 demo]# git commit -m "remove test"
    [master 7b5310a] remove test
     1 files changed, 0 insertions(+), 1 deletions(-)
     delete mode 100644 test.txt

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

    另一种情况是删错了,因为版本库里还有呢,所以可以很轻松地把误删的文件恢复到最新版本:

    [root@git-node1 demo]# git checkout -- test.txt

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

    1.7、理解工作区和暂存区

    Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。

    先来看名词解释。

    工作区(Working Directory

    就是你在电脑里能看到的目录,比如我的git_trainning文件夹就是一个工作区:

    1
    2
    ls git_trainning/
    first_git_file.txt

    版本库(Repository)

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

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

    分支和HEAD的概念我们以后再讲。

    前面讲了我们把文件往Git版本库里添加的时候,是分两步执行的:

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

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

    因为我们创建Git版本库时,Git自动为我们创建了唯一一个master分支,所以,现在,git commit就是往master分支上提交更改。

    你可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改。

    俗话说,实践出真知。现在,我们再练习一遍,先对first_git_file.txt做个修改,比如加上一行内容:

    1
    2
    3
    4
    5
    6
    First time using git, excited! update ...
    insert line here..改之前的.
    第一次用git哈哈
    insert line again haha...
    加点新内容
    update v5

    然后,在工作区新增一个readme.md文本文件(内容随便写)。

    先用git status查看一下状态:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    $ git status
    On branch master
    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:   first_git_file.txt
     
    Untracked files:
      (use "git add <file>..." to include in what will be committed)
     
        readme.md
     
    no changes added to commit (use "git add" and/or "git commit -a")

    Git非常清楚地告诉我们,first_git_file.txt被修改了,而readme.md还从来没有被添加过,所以它的状态是Untracked

    现在,使用命令git add . ,再用git status再查看一下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    $ git add .
    $ git status
    On branch master
    Changes to be committed:
      (use "git reset HEAD <file>..." to unstage)
     
        modified:   first_git_file.txt
        new file:   readme.md
    </file>

    现在,暂存区的状态就变成这样了:

    (盗图关系, 这里readme.txt = first_git_file.txt , LICENSE = readme.md)

    所以,git add命令实际上就是把要提交的所有修改放到暂存区(Stage),然后,执行git commit就可以一次性把暂存区的所有修改提交到分支。

    1
    2
    3
    4
    $ git commit -m "知道暂存区stage的意思了"
    [master 9d65cb2] 知道暂存区stage的意思了
     2 files changed, 2 insertions(+)
     create mode 100644 readme.md

    一旦提交后,如果你又没有对工作区做任何修改,那么工作区就是“干净”的:

    1
    2
    3
    $ git status
    On branch master
    nothing to commit, working directory clean

    现在版本库变成了这样,暂存区就没有任何内容了:

    (盗图关系, 这里readme.txt = first_git_file.txt , LICENSE = readme.md)

     暂存区是Git非常重要的概念,弄明白了暂存区,就弄明白了Git的很多操作到底干了什么。

    1.8、远程仓库

    注册一个GitHub账号,就可以免费获得Git远程仓库。

    由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的,所以,需要一点设置:

    第1步:创建SSH Key。在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsaid_rsa.pub这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key:

    [root@git-node1 demo]# ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key (/root/.ssh/id_rsa): 
    Enter passphrase (empty for no passphrase): 
    Enter same passphrase again: 
    Your identification has been saved in /root/.ssh/id_rsa.
    Your public key has been saved in /root/.ssh/id_rsa.pub.
    The key fingerprint is:
    16:02:9f:cd:58:e5:c1:7c:b2:e9:6b:51:87:e3:f8:2a root@git-node1
    The key's randomart image is:
    +--[ RSA 2048]----+
    |    .   .+o      |
    |     o * .+..    |
    |      = + .= .   |
    |       . .o + .  |
    |        S. + o   |
    |       .  + .    |
    |           +     |
    |        E o .    |
    |         o..     |
    +-----------------+
    [root@git-node1 demo]# ls ~/.ssh/
    id_rsa  id_rsa.pub
    
    [root@git-node1 demo]# cat ~/.ssh/id_rsa.pub
    ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0twNMooyMj25MeCKQoBcarKeXpPSy3mGDnmFeE0qrZ+jqQ8O8DSqaQYXVUPov3axtDS6Sdq+J63fXmZksuMYAWIRzHXzqwyKgU/exu1HAf+
    /UwN/nrS1wAVEPEZM5+yutFSnUpZG0Nr2lTyTHnNBugBXr/xyxDtJErOkSbKXwzJevVIYElcLOZMfsWvJBF/zqfgvdAr6bh7nmnyEguiXL6l5CmcC7k5A/WGqFUJRzhFtNK5hTGp6YBsMBv
    j3fyr9+nPexMf7TuJO3HvGps0rW0EsXJD092EO4k8cUKwVtlNoonpRChKapyRDQW1kA9dewUGdU/uRsVcCamEyp98b8w== root@git-node1

    可以在用户主目录里找到.ssh目录,里面有id_rsaid_rsa.pub两个文件,这两个就是SSH Key的秘钥对,id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可以放心地告诉任何人。

    第2步:登陆GitHub,打开“Account settings”,“SSH Keys”页面:

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

    点“Add Key”,你就应该看到已经添加的Key

      为什么GitHub需要SSH Key呢?因为GitHub需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以,GitHub只要知道了你的公钥,就可以确认只有你自己才能推送。

      当然,GitHub允许你添加多个Key。假定你有若干电脑,你一会儿在公司提交,一会儿在家里提交,只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往GitHub推送了。

      最后友情提示,在GitHub上免费托管的Git仓库,任何人都可以看到喔(但只有你自己才能改)。所以,不要把敏感信息放进去。

      如果你不想让别人看到Git库,有两个办法,一个是交点保护费,让GitHub把公开的仓库变成私有的,这样别人就看不见了(不可读更不可写)。另一个办法是自己动手,搭一个Git服务器,因为是你自己的Git服务器,所以别人也是看不见的。这个方法我们后面会讲到的,相当简单,公司内部开发必备。

    确保你拥有一个GitHub账号后,我们就即将开始远程仓库的学习。

    1.9、分支管理

    分支就是科幻电影里面的平行宇宙,当你正在电脑前努力学习Git的时候,另一个你正在另一个平行宇宙里努力学习SVN。

    如果两个平行宇宙互不干扰,那对现在的你也没啥影响。不过,在某个时间点,两个平行宇宙合并了,结果,你既学会了Git又学会了SVN!

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

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

    其他版本控制系统如SVN等都有分支管理,但是用过之后你会发现,这些版本控制系统创建和切换分支比蜗牛还慢,简直让人无法忍受,结果分支功能成了摆设,大家都不去用。

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

    2.0、创建与合并分支

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

    下面开始实战

    首先,我们创建dev分支,然后切换到dev分支:

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

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

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

    然后,用git branch命令查看当前分支:

    1
    2
    3
    $ git branch
    * dev
      master

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

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

    1
    Creating a new branch is quick.

    然后提交:

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

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

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

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

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

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

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

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

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

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

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

    删除后,查看branch,就只剩下master分支了:

    1
    2
    $ git branch
    * master

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

    解决冲突

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

    准备新的feature1分支,继续我们的新分支开发:

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

    修改readme.txt最后一行,改为:

    1
    added this line from branch feature 1

    feature1分支上提交:

    $ git add readme.txt 
    $ git commit -m "add feature"
    [feature1 75a857c] 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.
    

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

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

    1
    added this line from master

    提交:

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

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

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

    1
    2
    3
    4
    $ git merge feature1
    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也可以告诉我们冲突的文件:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    $ git status
    # On branch master
    # Your branch is ahead of 'origin/master' by 2 commits.
    #
    # Unmerged paths:
    #   (use "git add/rm <file>..." as appropriate to mark resolution)
    #
    #       both modified:      readme.txt
    #
    no changes added to commit (use "git add" and/or "git commit -a")

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

    1
    2
    3
    4
    5
    6
    7
    #git study repo
    Creating a new branch is quick.
    <<<<<<< HEAD
    added this line from master
    =======
    added this line from branch feature 1
    >>>>>>> feature1

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

    1
    2
    3
    4
    #git study repo
    Creating a new branch is quick.
    added this line from master
    added this line from branch feature 1

    再提交

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

    现在,master分支和feature1分支变成了下图所示:

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

    1
    2
    3
    4
    5
    6
    7
    8
    $ git log --graph --pretty=oneline
    *   feedd786cad3e18323a41846fcc1b0d52fc0c98e fix conflict
    | * 01f8f8d168e113fac9fbe24c4cfa6d4c351a9821 update from branch
    * | 743ccee30f3d74f1993f17e7312032b7399b1306 from master
    |/ 
    * edfbc29982927236596539e0f1971b0575f803c0 branch test
    * 8675486bfeeb340914369e80d2cfcf3e854e88a3 add home page

      

    2.1、分支策略

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

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

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

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

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

    2.2、bug分支  

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

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

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    $ 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,怎么办?

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

    1
    2
    3
    $ git stash
    Saved working directory and index state WIP on dev: 6224937 add merge
    HEAD is now at 6224937 add merge

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

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

    1
    2
    3
    4
    5
    $ git checkout master
    Switched to branch 'master'
    Your branch is ahead of 'origin/master' by 6 commits.
    $ git checkout -b issue-101
    Switched to a new branch 'issue-101'

    现在修复bug,需要把“Git is free software ...”改为“Git is a free software ...”,然后提交:

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

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

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

      

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

    1
    2
    3
    4
    5
    $ git checkout dev
    Switched to branch 'dev'
    $ git status
    # On branch dev
    nothing to commit (working directory clean)

      

    工作区是干净的,刚才的工作现场存到哪去了?用git stash list命令看看:

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

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

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

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

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    $ 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} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)

    再用git stash list查看,就看不到任何stash内容了:

    1
    $ git stash list

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

    1
    $ git stash apply stash@{0}

    2.3、分支策略

    多人协作  

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

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

    1
    2
    $ git remote
    origin

    或者,用git remote -v显示更详细的信息:

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

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

    2.4、 推送分支

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

    1
    $ git push origin master

    如果要推送其他分支,比如dev,就改成:

    1
    $ git push origin dev

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

    • master分支是主分支,因此要时刻与远程同步;

    • dev分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;

    • bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;

    • feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。

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

    2.5、抓取分支

    多人协作时,大家都会往masterdev分支上推送各自的修改。

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

    1
    2
    3
    4
    5
    6
    7
    $ git clone git@github.com:triaquae/gitskills.git
    Cloning into 'gitskills'...
    remote: Counting objects: 16, done.
    remote: Compressing objects: 100% (7/7), done.
    remote: Total 16 (delta 0), reused 10 (delta 0), pack-reused 0
    Receiving objects: 100% (16/16), done.
    Checking connectivity... done.

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

    1
    2
    $ git branch
    * master

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

    1
    $ git checkout -b dev origin/dev

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

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    $ git add .
    $ git commit -m "small updates"
     
    [dev f1b762e] small updates
     2 files changed, 5 insertions(+), 1 deletion(-)
    Alexs-MacBook-Pro:gitskills alex$ git push origin dev
    Counting objects: 4, done.
    Delta compression using up to 8 threads.
    Compressing objects: 100% (3/3), done.
    Writing objects: 100% (4/4), 438 bytes | 0 bytes/sdone.
    Total 4 (delta 0), reused 0 (delta 0)
    To git@github.com:triaquae/gitskills.git
       33ec6b4..f1b762e  dev -> dev

      

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

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    $ git add .
    $ git commit -m "add Dog class"
    [dev 7e7b1bf] add Dog class
     2 files changed, 7 insertions(+)
     
     
    $ git push origin dev
     
    To git@github.com:triaquae/gitskills.git
     ! [rejected]        dev -> dev (fetch first)
    error: failed to push some refs to 'git@github.com:triaquae/gitskills.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.

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

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    $ git pull
    remote: Counting objects: 4, done.
    remote: Compressing objects: 100% (3/3), done.
    remote: Total 4 (delta 0), reused 4 (delta 0), pack-reused 0
    Unpacking objects: 100% (4/4), done.
    From github.com:triaquae/gitskills
       33ec6b4..f1b762e  dev        -> origin/dev
    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分支的链接,根据提示,设置devorigin/dev的链接:

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

    再pull:

    1
    2
    3
    4
    5
    6
    $ git pull
    Auto-merging hello.py
    CONFLICT (content): Merge conflict in hello.py
    Auto-merging branch_test.md
    CONFLICT (content): Merge conflict in branch_test.md
    Automatic merge failed; fix conflicts and then commit the result.

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

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    $ git add .
    $ git commit -m "merge & fix hello.py"
    [dev 93e28e3] merge & fix hello.py
     
    $ git push origin dev
     
    Counting objects: 8, done.
    Delta compression using up to 8 threads.
    Compressing objects: 100% (7/7), done.
    Writing objects: 100% (8/8), 819 bytes | 0 bytes/sdone.
    Total 8 (delta 1), reused 0 (delta 0)
    remote: Resolving deltas: 100% (1/1), done.
    To git@github.com:triaquae/gitskills.git
       f1b762e..93e28e3  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 branch-name origin/branch-name

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

    2.6、 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,以及你自己克隆到本地电脑的仓库,他们的关系就像下图显示的那样:

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

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

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

    小结

    • 在GitHub上,可以任意Fork开源仓库;

    • 自己拥有Fork后的仓库的读写权限;

    • 可以推送pull request给官方仓库来贡献代码。

    2.7、 忽略特殊文件.gitignore

    有些时候,你必须把某些文件放到Git工作目录中,但又不能提交它们,比如保存了数据库密码的配置文件啦,等等,每次git status都会显示Untracked files ...,有强迫症的童鞋心里肯定不爽。

    好在Git考虑到了大家的感受,这个问题解决起来也很简单,在Git工作区的根目录下创建一个特殊的.gitignore文件,然后把要忽略的文件名填进去,Git就会自动忽略这些文件。

    不需要从头写.gitignore文件,GitHub已经为我们准备了各种配置文件,只需要组合一下就可以使用了。所有配置文件可以直接在线浏览:https://github.com/github/gitignore

    忽略文件的原则是:

    1. 忽略操作系统自动生成的文件,比如缩略图等;
    2. 忽略编译生成的中间文件、可执行文件等,也就是如果一个文件是通过另一个文件自动生成的,那自动生成的文件就没必要放进版本库,比如Java编译产生的.class文件;
    3. 忽略你自己的带有敏感信息的配置文件,比如存放口令的配置文件。

    举个例子:

    假设你在Windows下进行Python开发,Windows会自动在有图片的目录下生成隐藏的缩略图文件,如果有自定义目录,目录下就会有Desktop.ini文件,因此你需要忽略Windows自动生成的垃圾文件:

    1
    2
    3
    4
    # Windows:
    Thumbs.db
    ehthumbs.db
    Desktop.ini

    然后,继续忽略Python编译产生的.pyc.pyodist等文件或目录:

    1
    2
    3
    4
    5
    6
    7
    # Python:
    *.py[cod]
    *.so
    *.egg
    *.egg-info
    dist
    build

    加上你自己定义的文件,最终得到一个完整的.gitignore文件,内容如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    # Windows:
    Thumbs.db
    ehthumbs.db
    Desktop.ini
     
    # Python:
    *.py[cod]
    *.so
    *.egg
    *.egg-info
    dist
    build
     
    # My configurations:
    db.ini
    deploy_key_rsa

    最后一步就是把.gitignore也提交到Git,就完成了!当然检验.gitignore的标准是git status命令是不是说working directory clean

    使用Windows的童鞋注意了,如果你在资源管理器里新建一个.gitignore文件,它会非常弱智地提示你必须输入文件名,但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。

    有些时候,你想添加一个文件到Git,但发现添加不了,原因是这个文件被.gitignore忽略了:

    1
    2
    3
    4
    $ git add App.class
    The following paths are ignored by one of your .gitignore files:
    App.class
    Use -f if you really want to add them.

    如果你确实想添加该文件,可以用-f强制添加到Git:

    1
    $ git add -f App.class

    或者你发现,可能是.gitignore写得有问题,需要找出来到底哪个规则写错了,可以用git check-ignore命令检查:

    1
    2
    $ git check-ignore -v App.class
    .gitignore:3:*.class    App.class  

    Git会告诉我们,.gitignore的第3行规则忽略了该文件,于是我们就可以知道应该修订哪个规则。

    小结

    • 忽略某些文件时,需要编写.gitignore

    • .gitignore文件本身要放到版本库里,并且可以对.gitignore做版本管理!

    2.8、基本操作小结

    相信大家对Git的基本操作有一定的了解,下面进行一下简单的梳理总结:

      1. 命令 git config --global user.name "name" #配置git使用用户
      2. # git config --global user.email "mail" #配置git使用邮箱
      3. # git config --global color.ui true #配置颜色
      4. # git config --list #查看当前配置
      5. # git init #初始为git工作目录
      6. # git status #查看git状态
      7. # git reflog #查看未来历史更新点
      8. # git reset --hard 4bf5b29 #找到历史还原点的SHA-1值,就可以还原(值不写全,系统会自动匹配)
      9. # git checkout -- file #恢复暂存区至上一版本
      10. # git add [file1] [file2] ... #添加指定文件至暂存区
      11. # git add [dir] #添加指定目录至暂存区,包括子目录(递归添加)
      12. # git add . #添加当前目录所有文件至暂存区
      13. # git rm [file1] [file2] ... #删除工作区文件,并将这次删除放入暂存区
      14. # git rm –cached [file] #停止追踪指定文件,但该文件会保留在工作区
      15. # git mv [file-old] [file-new] #重命名文件,修改后放入暂存区
  • 相关阅读:
    关于数据库字符集编码及通用软件产品的设计表结构的注意事项
    记一次调用第三方接口,对方获取到参数乱码问题
    Java获取固定格式日期&计算日期相差时长
    Redis之雪崩、穿透、击穿
    [LeetCode] 两数相加 (JavaScript 解法)
    React hooks 获取 dom 引用
    PHP + Redis 实现定任务触发
    测试PHP几种方法写入文件的效率与安全性
    如何调整firefox鼠标滚轮速度
    美美Apple ID 注册教程
  • 原文地址:https://www.cnblogs.com/nulige/p/6825597.html
Copyright © 2011-2022 走看看