winney

It is never too old to learn.

0%
winney

git基本操作,一篇文章就够了!

git的通用操作流程如下图(来源于网络)

主要涉及到四个关键点:

  1. 工作区:本地电脑存放项目文件的地方,比如learnGitProject文件夹;

  2. 暂存区(Index/Stage):在使用git管理项目文件的时候,其本地的项目文件会多出一个.git的文件夹,将这个.git文件夹称之为版本库。其中.git文件夹中包含了两个部分,一个是暂存区(Index或者Stage),顾名思义就是暂时存放文件的地方,通常使用add命令将工作区的文件添加到暂存区里;

  3. 本地仓库:.git文件夹里还包括git自动创建的master分支,并且将HEAD指针指向master分支。使用commit命令可以将暂存区中的文件添加到本地仓库中;

    Git/RybyDemo/grit/.git/refs/heads 目录中修改master:

    1
    ebdec5ff037c7368b2b1827fadc66741d1ed14ed

    修改HEAD:

    1
    ref:refs/heads/master
  4. 远程仓库:不是在本地仓库中,项目代码在远程git服务器上,比如项目放在github上,就是一个远程仓库,通常使用clone命令将远程仓库拷贝到本地仓库中,开发后推送到远程仓库中即可;

更细节的来看:

日常开发时代码实际上放置在工作区中,也就是本地的XXX.java这些文件,通过add等这些命令将代码文教提交给暂存区(Index/Stage),也就意味着代码全权交给了git进行管理,之后通过commit等命令将暂存区提交给master分支上,也就是意味打了一个版本,也可以说代码提交到了本地仓库中。另外,团队协作过程中自然而然还涉及到与远程仓库的交互。

因此,经过这样的分析,git命令可以分为这样的逻辑进行理解和记忆:

  1. git管理配置的命令;

    几个核心存储区的交互命令:

  2. 工作区与暂存区的交互;

  3. 暂存区与本地仓库(分支)上的交互;

  4. 本地仓库与远程仓库的交互。

2. git配置命令

查询配置信息

  1. 列出当前配置:gitconfig --list;
  2. 列出repository配置:gitconfig --local --list;
  3. 列出全局配置:gitconfig --global --list;
  4. 列出系统配置:gitconfig --system --list;

第一次使用git,配置用户信息

  1. 配置用户名:gitconfig --global user.name "your name";
  2. 配置用户邮箱:gitconfig --global user.email "youremail@github.com";

其他配置

  1. 配置解决冲突时使用哪种差异分析工具,比如要使用vimdiff:gitconfig --global merge.toolvimdiff;
  2. 配置git命令输出为彩色的:gitconfig --global color.ui auto;
  3. 配置git使用的文本编辑器:gitconfig --global core.editor vi;

3. 工作区上的操作命令

新建仓库

  1. 将工作区中的项目文件使用git进行管理,即创建一个新的本地仓库:gitinit
  2. 从远程git仓库复制项目:git clone <url>,如:git clone git://github.com/wasd/example.git;克隆项目时如果想定义新的项目名,可以在clone命令后指定新的项目名:git clone git://github.com/wasd/example.git mygit

提交

  1. 提交工作区所有文件到暂存区:git add .
  2. 提交工作区中指定文件到暂存区:git add <file1><file2> ...;
  3. 提交工作区中某个文件夹中所有文件到暂存区:git add [dir];

撤销

  1. 删除工作区文件,并且也从暂存区删除对应文件的记录:gitrm<file1><file2>;
  2. 从暂存区中删除文件,但是工作区依然还有该文件:gitrm --cached <file>;
  3. 取消暂存区已经暂存的文件:git reset HEAD <file>...;
  4. 撤销上一次对文件的操作:git checkout --<file>。要确定上一次对文件的修改不再需要,如果想保留上一次的修改以备以后继续工作,可以使用stashing和分支来处理;
  5. 隐藏当前变更,以便能够切换分支:git stash
  6. 查看当前所有的储藏:git stash list
  7. 应用最新的储藏:git stash apply,如果想应用更早的储藏:git stash apply stash@{2};重新应用被暂存的变更,需要加上--index参数:git stash apply --index;
  8. 使用apply命令只是应用储藏,而内容仍然还在栈上,需要移除指定的储藏:git stash drop stash{0};如果使用pop命令不仅可以重新应用储藏,还可以立刻从堆栈中清除:git stash pop;
  9. 在某些情况下,你可能想应用储藏的修改,在进行了一些其他的修改后,又要取消之前所应用储藏的修改。Git没有提供类似于 stash unapply 的命令,但是可以通过取消该储藏的补丁达到同样的效果:git stash show -p stash@{0} | git apply -R;同样的,如果你沒有指定具体的某个储藏,Git 会选择最近的储藏:git stash show -p | git apply -R

更新文件

  1. 重命名文件,并将已改名文件提交到暂存区:git mv [file-original] [file-renamed];

查新信息

  1. 查询当前工作区所有文件的状态:git status;
  2. 比较工作区中当前文件和暂存区之间的差异,也就是修改之后还没有暂存的内容:git diff;指定文件在工作区和暂存区上差异比较:git diff <file-name>;

4. 暂存区上的操作命令

提交文件到版本库

  1. 将暂存区中的文件提交到本地仓库中,即打上新版本:git commit -m "commit_info";
  2. 将所有已经使用git管理过的文件暂存后一并提交,跳过add到暂存区的过程:git commit -a -m "commit_info";
  3. 提交文件时,发现漏掉几个文件,或者注释写错了,可以撤销上一次提交:git commit --amend;

查看信息

  1. 比较暂存区与上一版本的差异:git diff --cached;
  2. 指定文件在暂存区和本地仓库的不同:git diff <file-name> --cached;
  3. 查看提交历史:git log;参数-p展开每次提交的内容差异,用-2显示最近的两次更新,如git log -p -2;

打标签

Git 使用的标签有两种类型:轻量级的(lightweight)和含附注的(annotated)。轻量级标签就像是个不会变化的分支,实际上它就是个指向特定提交对象的引用。而含附注标签,实际上是存储在仓库中的一个独立对象,它有自身的校验和信息,包含着标签的名字,电子邮件地址和日期,以及标签说明,标签本身也允许使用 GNU Privacy Guard (GPG) 来签署或验证。一般我们都建议使用含附注型的标签,以便保留相关信息;当然,如果只是临时性加注标签,或者不需要旁注额外信息,用轻量级标签也没问题。

  1. 列出现在所有的标签:git tag;
  2. 使用特定的搜索模式列出符合条件的标签,例如只对1.4.2系列的版本感兴趣:git tag -l "v1.4.2.*";
  3. 创建一个含附注类型的标签,需要加-a参数,如git tag -a v1.4 -m "my version 1.4";
  4. 使用git show命令查看相应标签的版本信息,并连同显示打标签时的提交对象:git show v1.4;
  5. 如果有自己的私钥,可以使用GPG来签署标签,只需要在命令中使用-s参数:git tag -s v1.5 -m "my signed 1.5 tag";
  6. 验证已签署的标签:git tag -v ,如git tag -v v1.5;
  7. 创建一个轻量级标签的话,就直接使用git tag命令即可,连-a,-s以及-m选项都不需要,直接给出标签名字即可,如git tag v1.5;
  8. 将标签推送到远程仓库中:git push origin ,如git push origin v1.5
  9. 将本地所有的标签全部推送到远程仓库中:git push origin --tags;

分支管理

  1. 创建分支:git branch <branch-name>,如git branch testing
  2. 从当前所处的分支切换到其他分支:git checkout <branch-name>,如git checkout testing
  3. 新建并切换到新建分支上:git checkout -b <branch-name>;
  4. 删除分支:git branch -d <branch-name>
  5. 将当前分支与指定分支进行合并:git merge <branch-name>;
  6. 显示本地仓库的所有分支:git branch;
  7. 查看各个分支最后一个提交对象的信息:git branch -v;
  8. 查看哪些分支已经合并到当前分支:git branch --merged;
  9. 查看当前哪些分支还没有合并到当前分支:git branch --no-merged;
  10. 把远程分支合并到当前分支:git merge <remote-name>/<branch-name>,如git merge origin/serverfix;如果是单线的历史分支不存在任何需要解决的分歧,只是简单的将HEAD指针前移,所以这种合并过程可以称为快进(Fast forward),而如果是历史分支是分叉的,会以当前分叉的两个分支作为两个祖先,创建新的提交对象;如果在合并分支时,遇到合并冲突需要人工解决后,再才能提交;
  11. 在远程分支的基础上创建新的本地分支:git checkout -b <branch-name><remote-name>/<branch-name>,如git checkout -b serverfix origin/serverfix;
  12. 从远程分支checkout出来的本地分支,称之为跟踪分支。在跟踪分支上向远程分支上推送内容:git push。该命令会自动判断应该向远程仓库中的哪个分支推送数据;在跟踪分支上合并远程分支:git pull
  13. 将一个分支里提交的改变移到基底分支上重放一遍:git rebase <rebase-branch><branch-name>,如git rebase master server,将特性分支server提交的改变在基底分支master上重演一遍;使用rebase操作最大的好处是像在单个分支上操作的,提交的修改历史也是一根线;如果想把基于一个特性分支上的另一个特性分支变基到其他分支上,可以使用--onto操作:git rebase --onto <rebase-branch><feature branch><sub-feature-branch>,如git rebase --onto master server client;使用rebase操作应该遵循的原则是:一旦分支中的提交对象发布到公共仓库,就千万不要对该分支进行rebase操作

5.本地仓库上的操作

  1. 查看本地仓库关联的远程仓库:git remote;在克隆完每个远程仓库后,远程仓库默认为origin;加上-v的参数后,会显示远程仓库的url地址;
  2. 添加远程仓库,一般会取一个简短的别名:git remote add [remote-name] [url],比如:git remote add example git://github.com/example/example.git;
  3. 从远程仓库中抓取本地仓库中没有的更新:git fetch [remote-name],如git fetch origin;使用fetch只是将远端数据拉到本地仓库,并不自动合并到当前工作分支,只能人工合并。如果设置了某个分支关联到远程仓库的某个分支的话,可以使用git pull来拉去远程分支的数据,然后将远端分支自动合并到本地仓库中的当前分支;
  4. 将本地仓库某分支推送到远程仓库上:git push [remote-name] [branch-name],如git push origin master;如果想将本地分支推送到远程仓库的不同名分支:git push <remote-name><local-branch>:<remote-branch>,如git push origin serverfix:awesomebranch;如果想删除远程分支:git push [romote-name] :<remote-branch>,如git push origin :serverfix。这里省略了本地分支,也就相当于将空白内容推送给远程分支,就等于删掉了远程分支。
  5. 查看远程仓库的详细信息:git remote show origin
  6. 修改某个远程仓库在本地的简称:git remote rename [old-name] [new-name],如git remote rename origin org
  7. 移除远程仓库:git remote rm [remote-name]

6. 忽略文件.gitignore

一般我们总会有些文件无需纳入 Git 的管理,也不希望它们总出现在未跟踪文件列表。通常都是些自动生成的文件,比如日志文件,或者编译过程中创建的临时文件等。我们可以创建一个名为 .gitignore 的文件,列出要忽略的文件模式。如下例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 此为注释 – 将被 Git 忽略
# 忽略所有 .a 结尾的文件
*.a
# 但 lib.a 除外
!lib.a
# 仅仅忽略项目根目录下的 TODO 文件,不包括 subdir/TODO
/TODO
# 忽略 build/ 目录下的所有文件
build/
# 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt
doc/*.txt
# 忽略 doc/ 目录下所有扩展名为 txt 的文件
doc/**/*.txt
复制代码

参考资料

非常详细准确的git学习资料

git-cheat-sheet中文版

命令总结,资料一般,不够详细,作参考

常用命令很全

作者:你听___
链接:https://juejin.im/post/5ae072906fb9a07a9e4ce596
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

阮一峰网络日志:http://www.ruanyifeng.com/blog/2015/12/git-cheat-sheet.html

1.常用 Git 命令清单

我每天使用 Git ,但是很多命令记不住。

一般来说,日常使用只要记住下图6个命令,就可以了。但是熟练使用,恐怕要记住60~100个命令。

http://www.ruanyifeng.com/blogimg/asset/2015/bg2015120901.png

下面是我整理的常用 Git 命令清单。几个专用名词的译名如下。

§ Workspace:工作区

§ Index / Stage:暂存区

§ Repository:仓库区(或本地仓库)

§ Remote:远程仓库

一、新建代码库

1
2
3
4
5
6
7
8
9
10
 
# 在当前目录新建一个Git代码库
$ gitinit

# 新建一个目录,将其初始化为Git代码库
$ gitinit[project-name]

# 下载一个项目和它的整个代码历史
$ git clone [url]

二、配置

Git的设置文件为.gitconfig,它可以在用户主目录下(全局配置),也可以在项目目录下(项目配置)。

1
2
3
4
5
6
7
8
9
10
 
# 显示当前的Git配置
$ gitconfig--list

# 编辑Git配置文件
$ gitconfig-e [--global]

# 设置提交代码时的用户信息
$ gitconfig[--global] user.name "[name]"
$ gitconfig[--global]user.email"[email address]"

三、增加/删除文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
# 添加指定文件到暂存区
$ git add [file1][file2]...

# 添加指定目录到暂存区,包括子目录
$ git add [dir]

# 添加当前目录的所有文件到暂存区
$ git add .

# 添加每个变化前,都会要求确认
# 对于同一个文件的多处变化,可以实现分次提交
$ git add -p

# 删除工作区文件,并且将这次删除放入暂存区
$ gitrm[file1][file2]...

# 停止追踪指定文件,但该文件会保留在工作区
$ gitrm--cached [file]

# 改名文件,并且将这个改名放入暂存区
$ git mv [file-original][file-renamed]

四、代码提交

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
# 提交暂存区到仓库区
$ git commit -m [message]

# 提交暂存区的指定文件到仓库区
$ git commit [file1][file2]...-m [message]

# 提交工作区自上次commit之后的变化,直接到仓库区
$ git commit -a

# 提交时显示所有diff信息
$ git commit -v

# 使用一次新的commit,替代上一次提交
# 如果代码没有任何新变化,则用来改写上一次commit的提交信息
$ git commit --amend -m [message]

# 重做上一次commit,并包括指定文件的新变化
$ git commit --amend [file1][file2]...

五、分支

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
 
# 列出所有本地分支
$ git branch

# 列出所有远程分支
$ git branch -r

# 列出所有本地分支和远程分支
$ git branch -a

# 新建一个分支,但依然停留在当前分支
$ git branch [branch-name]

# 新建一个分支,并切换到该分支
$ git checkout -b [branch]

# 新建一个分支,指向指定commit
$ git branch [branch][commit]

# 新建一个分支,与指定的远程分支建立追踪关系
$ git branch --track [branch][remote-branch]

# 切换到指定分支,并更新工作区
$ git checkout [branch-name]

# 切换到上一个分支
$ git checkout -

# 建立追踪关系,在现有分支与指定的远程分支之间
$ git branch --set-upstream [branch][remote-branch]

# 合并指定分支到当前分支
$ git merge [branch]

# 选择一个commit,合并进当前分支
$ git cherry-pick [commit]

# 删除分支
$ git branch -d [branch-name]

# 删除远程分支
$ git push origin --delete [branch-name]
$ git branch -dr[remote/branch]

六、标签

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
# 列出所有tag
$ git tag

# 新建一个tag在当前commit
$ git tag [tag]

# 新建一个tag在指定commit
$ git tag [tag][commit]

# 删除本地tag
$ git tag -d [tag]

# 删除远程tag
$ git push origin :refs/tags/[tagName]

# 查看tag信息
$ git show [tag]

# 提交指定tag
$ git push [remote][tag]

# 提交所有tag
$ git push [remote]--tags

# 新建一个分支,指向某个tag
$ git checkout -b [branch][tag]

七、查看信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
 
# 显示有变更的文件
$ git status

# 显示当前分支的版本历史
$ git log

# 显示commit历史,以及每次commit发生变更的文件
$ git log --stat

# 搜索提交历史,根据关键词
$ git log -S [keyword]

# 显示某个commit之后的所有变动,每个commit占据一行
$ git log [tag] HEAD --pretty=format:%s

# 显示某个commit之后的所有变动,其"提交说明"必须符合搜索条件
$ git log [tag] HEAD --grep feature

# 显示某个文件的版本历史,包括文件改名
$ git log --follow [file]
$ gitwhatchanged[file]

# 显示指定文件相关的每一次diff
$ git log -p [file]

# 显示过去5次提交
$ git log -5--pretty --oneline

# 显示所有提交过的用户,按提交次数排序
$ gitshortlog-sn

# 显示指定文件是什么人在什么时间修改过
$ git blame [file]

# 显示暂存区和工作区的差异
$ git diff

# 显示暂存区和上一个commit的差异
$ git diff --cached [file]

# 显示工作区与当前分支最新commit之间的差异
$ git diff HEAD

# 显示两次提交之间的差异
$ git diff [first-branch]...[second-branch]

# 显示今天你写了多少行代码
$ git diff --shortstat"@{0 day ago}"

# 显示某次提交的元数据和内容变化
$ git show [commit]

# 显示某次提交发生变化的文件
$ git show --name-only [commit]

# 显示某次提交时,某个文件的内容
$ git show [commit]:[filename]

# 显示当前分支的最近几次提交
$ gitreflog

八、远程同步

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
# 下载远程仓库的所有变动
$ git fetch [remote]

# 显示所有远程仓库
$ git remote -v

# 显示某个远程仓库的信息
$ git remote show [remote]

# 增加一个新的远程仓库,并命名
$ git remote add [shortname][url]

# 取回远程仓库的变化,并与本地分支合并
$ git pull [remote][branch]

# 上传本地指定分支到远程仓库
$ git push [remote][branch]

# 强行推送当前分支到远程仓库,即使有冲突
$ git push [remote]--force

# 推送所有分支到远程仓库
$ git push [remote]--all

九、撤销

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
# 恢复暂存区的指定文件到工作区
$ git checkout [file]

# 恢复某个commit的指定文件到暂存区和工作区
$ git checkout [commit][file]

# 恢复暂存区的所有文件到工作区
$ git checkout .

# 重置暂存区的指定文件,与上一次commit保持一致,但工作区不变
$ git reset [file]

# 重置暂存区与工作区,与上一次commit保持一致
$ git reset --hard

# 重置当前分支的指针为指定commit,同时重置暂存区,但工作区不变
$ git reset [commit]

# 重置当前分支的HEAD为指定commit,同时重置暂存区和工作区,与指定commit一致
$ git reset --hard [commit]

# 重置当前HEAD为指定commit,但保持暂存区和工作区不变
$ git reset --keep [commit]

# 新建一个commit,用来撤销指定commit
# 后者的所有变化都将被前者抵消,并且应用到当前分支
$ git revert [commit]

# 暂时将未提交的变化移除,稍后再移入
$ git stash
$ git stash pop

十、其他

1
2
3
 
# 生成一个可供发布的压缩包
$ git archive

Git-W3C

Git教程

window平台下, 下载网址:https://gitforwindows.org/

安装完之后,在电脑 开始,输入 git 找到 Git Bash

查看git安装目录

有时候需要知道Git在电脑中的安装位置,这里简单介绍下:

  • Mac平台:在命令行中输入which git, 就会显示git的安装位置了;
  • Windows平台:打开cmd,输入where git就会显示git的安装路径了.

查看git的安装所在目录:

1
where git

用户信息

配置个人的用户名称和电子邮件地址:

1
2
git config --global user.name "w3c"
git config --global user.email w3c@w3cschool.cn

如果用了 –global 选项,那么更改的配置文件就是位于你用户主目录下的那个,以后你所有的项目都会默认使用这里配置的用户信息。

如果要在某个特定的项目中使用其他名字或者电邮,只要去掉 –global 选项重新配置即可,新的设定保存在当前项目的 .git/config 文件里。

查看配置信息

要检查已有的配置信息,可以使用 git config –list 命令:

1
git config --list

可以直接查阅某个环境变量的设定,只要把特定的名字跟在后面即可,像这样:

1
git config user.name 

Git 工作流程

一般工作流程如下:

  • 克隆 Git 资源作为工作目录。
  • 在克隆的资源上添加或修改文件。
  • 如果其他人修改了,你可以更新资源。
  • 在提交前查看修改。
  • 提交修改。
  • 在修改完成后,如果发现错误,可以撤回提交并再次修改并提交。

img


Git 工作区、暂存区和版本库

  • 工作区:就是你在电脑里能看到的目录。
  • 暂存区:英文叫stage, 或index。一般存放在”git目录”下的index文件(.git/index)中,所以我们把暂存区有时也叫作索引(index)。
  • 版本库:工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库。

img

图中左侧为工作区,右侧为版本库。在版本库中标记为 “index” 的区域是暂存区(stage, index),标记为 “master” 的是 master 分支所代表的目录树。

图中我们可以看出此时 “HEAD” 实际是指向 master 分支的一个”游标”。所以图示的命令中出现 HEAD 的地方可以用 master 来替换。

图中的 objects 标识的区域为 Git 的对象库,实际位于 “.git/objects” 目录下,里面包含了创建的各种对象及内容。

当对工作区修改(或新增)的文件执行 “git add” 命令时,暂存区的目录树被更新,同时工作区修改(或新增)的文件内容被写入到对象库中的一个新的对象中,而该对象的ID被记录在暂存区的文件索引中。

当执行提交操作(git commit)时,暂存区的目录树写到版本库(对象库)中,master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。

当执行 “git reset HEAD” 命令时,暂存区的目录树会被重写,被 master 分支指向的目录树所替换,但是工作区不受影响。

当执行 “git rm –cached “ 命令时,会直接从暂存区删除文件,工作区则不做出改变。

当执行 “git checkout .” 或者 “git checkout – “ 命令时,会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险,会清除工作区中未添加到暂存区的改动。

当执行 “git checkout HEAD .” 或者 “git checkout HEAD “ 命令时,会用 HEAD 指向的 master 分支中的全部或者部分文件替换暂存区和以及工作区中的文件。这个命令也是极具危险性的,因为不但会清除工作区中未提交的改动,也会清除暂存区中未提交的改动。


Git 创建仓库

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

初始化:

1
git init

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

1
git init winneyGit(指定的目录名称)

执行完这命令,在目录下新建一个winneyGit文件夹

从现有仓库克隆

克隆仓库的命令格式为:

1
git clone [url]

比如,要克隆 Ruby 语言的 Git 代码仓库 Grit,可以用下面的命令:

1
git clone git://github.com/schacon/grit.git 

执行该命令后,会在当前目录下创建一个名为grit的目录,其中包含一个 .git 的目录,用于保存下载下来的所有版本记录。如果要自己定义要新建的项目目录名称,可以在上面的命令末尾指定新的名字:

1
git clone git://github.com/schacon/grit.git mygrit

阮一峰网络日志:http://www.ruanyifeng.com/blog/2012/07/git.html

1、Git 工作流程

Git 作为一个源码管理系统,不可避免涉及到多人协作。

协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去。”工作流程”在英语里,叫做”workflow”或者”flow”,原意是水流,比喻项目像水流那样,顺畅、自然地向前流动,不会发生冲击、对撞、甚至漩涡。

http://www.ruanyifeng.com/blogimg/asset/2015/bg2015122301.png

本文介绍三种广泛使用的工作流程:

  • Git flow
  • Github flow
  • Gitlab flow

如果你对Git还不是很熟悉,可以先阅读下面的文章。

一、功能驱动

本文的三种工作流程,有一个共同点:都采用“功能驱动式开发”(Feature-driven development,简称FDD)。

它指的是,需求是开发的起点,先有需求再有功能分支(feature branch)或者补丁分支(hotfix branch)。完成开发后,该分支就合并到主分支,然后被删除。

二、Git flow

最早诞生、并得到广泛采用的一种工作流程,就是Git flow

2.1 特点

它最主要的特点有两个。

http://www.ruanyifeng.com/blogimg/asset/2015/bg2015122302.png

首先,项目存在两个长期分支。

  • 主分支master
  • 开发分支develop

前者用于存放对外发布的版本,任何时候在这个分支拿到的,都是稳定的分布版;后者用于日常开发,存放最新的开发版。

其次,项目存在三种短期分支。

  • 功能分支(feature branch)
  • 补丁分支(hotfix branch)
  • 预发分支(release branch)

一旦完成开发,它们就会被合并进develop或master,然后被删除。

Git flow 的详细介绍,请阅读我翻译的中文版《Git 分支管理策略》

2.2 评价

Git flow的优点是清晰可控,缺点是相对复杂,需要同时维护两个长期分支。大多数工具都将master当作默认分支,可是开发是在develop分支进行的,这导致经常要切换分支,非常烦人。

更大问题在于,这个模式是基于”版本发布”的,目标是一段时间以后产出一个新版本。但是,很多网站项目是”持续发布”,代码一有变动,就部署一次。这时,master分支和develop分支的差别不大,没必要维护两个长期分支。

三、Github flow

Github flow 是Git flow的简化版,专门配合”持续发布”。它是 Github.com 使用的工作流程。

3.1 流程

它只有一个长期分支,就是master,因此用起来非常简单。

官方推荐的流程如下。

http://www.ruanyifeng.com/blogimg/asset/2015/bg2015122305.png

第一步:根据需求,从master拉出新分支,不区分功能分支或补丁分支。

第二步:新分支开发完成后,或者需要讨论的时候,就向master发起一个pull request(简称PR)。

第三步:Pull Request既是一个通知,让别人注意到你的请求,又是一种对话机制,大家一起评审和讨论你的代码。对话过程中,你还可以不断提交代码。

第四步:你的Pull Request被接受,合并进master,重新部署后,原来你拉出来的那个分支就被删除。(先部署再合并也可。)

3.2 评价

Github flow 的最大优点就是简单,对于”持续发布”的产品,可以说是最合适的流程。

问题在于它的假设:master分支的更新与产品的发布是一致的。也就是说,master分支的最新代码,默认就是当前的线上代码。

可是,有些时候并非如此,代码合并进入master分支,并不代表它就能立刻发布。比如,苹果商店的APP提交审核以后,等一段时间才能上架。这时,如果还有新的代码提交,master分支就会与刚发布的版本不一致。另一个例子是,有些公司有发布窗口,只有指定时间才能发布,这也会导致线上版本落后于master分支。

上面这种情况,只有master一个主分支就不够用了。通常,你不得不在master分支以外,另外新建一个production分支跟踪线上版本。

四、Gitlab flow

Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点,既有适应不同开发环境的弹性,又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。

4.1 上游优先

Gitlab flow 的最大原则叫做”上游优先”(upsteam first),即只存在一个主分支master,它是所有其他分支的”上游”。只有上游分支采纳的代码变化,才能应用到其他分支。

Chromium项目就是一个例子,它明确规定,上游分支依次为:

  1. Linus Torvalds的分支
  2. 子系统(比如netdev)的分支
  3. 设备厂商(比如三星)的分支
4.2 持续发布

Gitlab flow 分成两种情况,适应不同的开发流程。

http://www.ruanyifeng.com/blogimg/asset/2015/bg2015122306.png

对于”持续发布”的项目,它建议在master分支以外,再建立不同的环境分支。比如,”开发环境”的分支是master,”预发环境”的分支是pre-production,”生产环境”的分支是production。

开发分支是预发分支的”上游”,预发分支又是生产分支的”上游”。代码的变化,必须由”上游”向”下游”发展。比如,生产环境出现了bug,这时就要新建一个功能分支,先把它合并到master,确认没有问题,再cherry-pick到pre-production,这一步也没有问题,才进入production。

只有紧急情况,才允许跳过上游,直接合并到下游分支。

4.3 版本发布

http://www.ruanyifeng.com/blogimg/asset/2015/bg2015122307.png

对于”版本发布”的项目,建议的做法是每一个稳定版本,都要从master分支拉出一个分支,比如2-3-stable、2-4-stable等等。

以后,只有修补bug,才允许将代码合并到这些分支,并且此时要更新小版本号。

五、一些小技巧

5.1 Pull Request

http://www.ruanyifeng.com/blogimg/asset/2015/bg2015122310.png

功能分支合并进master分支,必须通过Pull Request(Gitlab里面叫做 Merge Request)。

http://www.ruanyifeng.com/blogimg/asset/2015/bg2015122308.png

前面说过,Pull Request本质是一种对话机制,你可以在提交的时候,@相关人员团队,引起他们的注意。

5.2 Protected branch

master分支应该受到保护,不是每个人都可以修改这个分支,以及拥有审批 Pull Request 的权力。

GithubGitlab 都提供”保护分支”(Protected branch)这个功能。

5.3 Issue

Issue 用于 Bug追踪和需求管理。建议先新建 Issue,再新建对应的功能分支。功能分支总是为了解决一个或多个 Issue。

功能分支的名称,可以与issue的名字保持一致,并且以issue的编号起首,比如”15-require-a-password-to-change-it”。

http://www.ruanyifeng.com/blogimg/asset/2015/bg2015122311.png

开发完成后,在提交说明里面,可以写上”fixes #14”或者”closes #67”。Github规定,只要commit message里面有下面这些动词 + 编号,就会关闭对应的issue。

  • close
  • closes
  • closed
  • fix
  • fixes
  • fixed
  • resolve
  • resolves
  • resolved

这种方式还可以一次关闭多个issue,或者关闭其他代码库的issue,格式是username/repository#issue_number。

Pull Request被接受以后,issue关闭,原始分支就应该删除。如果以后该issue重新打开,新分支可以复用原来的名字。

5.4 Merge节点

Git有两种合并:一种是”直进式合并”(fast forward),不生成单独的合并节点;另一种是”非直进式合并”(none fast-forword),会生成单独节点。

前者不利于保持commit信息的清晰,也不利于以后的回滚,建议总是采用后者(即使用–no-ff参数)。只要发生合并,就要有一个单独的合并节点。

5.5 Squash 多个commit

为了便于他人阅读你的提交,也便于cherry-pick或撤销代码变化,在发起Pull Request之前,应该把多个commit合并成一个。(前提是,该分支只有你一个人开发,且没有跟master合并过。)

http://www.ruanyifeng.com/blogimg/asset/2015/bg2015122309.png

这可以采用rebase命令附带的squash操作,具体方法请参考我写的《Git 使用规范流程》

2、Git分支管理策略

如果你严肃对待编程,就必定会使用”版本管理系统“(Version Control System)。

眼下最流行的”版本管理系统”,非Git莫属。

http://www.ruanyifeng.com/blogimg/asset/201207/bg2012070501.png

相比同类软件,Git有很多优点。其中很显著的一点,就是版本的分支(branch)和合并(merge)十分方便。有些传统的版本管理软件,分支操作实际上会生成一份现有代码的物理拷贝,而Git只生成一个指向当前版本(又称”快照”)的指针,因此非常快捷易用。

但是,太方便了也会产生副作用。如果你不加注意,很可能会留下一个枝节蔓生、四处开放的版本库,到处都是分支,完全看不出主干发展的脉络。

http://www.ruanyifeng.com/blogimg/asset/201207/bg2012070502.png

Vincent Driessen提出了一个分支管理的策略,我觉得非常值得借鉴。它可以使得版本库的演进保持简洁,主干清晰,各个分支各司其职、井井有条。理论上,这些策略对所有的版本管理系统都适用,Git只是用来举例而已。如果你不熟悉Git,跳过举例部分就可以了。

一、主分支Master

首先,代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本,都在这个主分支上发布。

http://www.ruanyifeng.com/blogimg/asset/201207/bg2012070503.png

Git主分支的名字,默认叫做Master。它是自动建立的,版本库初始化以后,默认就是在主分支在进行开发。

二、开发分支Develop

主分支只用来分布重大版本,日常开发应该在另一条分支上完成。我们把开发用的分支,叫做Develop。

http://www.ruanyifeng.com/blogimg/asset/201207/bg2012070504.png

这个分支可以用来生成代码的最新隔夜版本(nightly)。如果想正式对外发布,就在Master分支上,对Develop分支进行”合并”(merge)。

Git创建Develop分支的命令:

1
git checkout -b develop master

将Develop分支发布到Master分支的命令:

  ### 切换到Master分支

1
git checkout master

  ### 对Develop分支进行合并

1
git merge --no-ff develop

这里稍微解释一下,上一条命令的–no-ff参数是什么意思。默认情况下,Git执行”快进式合并”(fast-farward merge),会直接将Master分支指向Develop分支。

http://www.ruanyifeng.com/blogimg/asset/201207/bg2012070505.png

使用–no-ff参数后,会执行正常合并,在Master分支上生成一个新节点。为了保证版本演进的清晰,我们希望采用这种做法。关于合并的更多解释,请参考Benjamin Sandofsky的《Understanding the Git Workflow》

http://www.ruanyifeng.com/blogimg/asset/201207/bg2012070506.png

三、临时性分支

前面讲到版本库的两条主要分支:Master和Develop。前者用于正式发布,后者用于日常开发。其实,常设分支只需要这两条就够了,不需要其他了。

但是,除了常设分支以外,还有一些临时性分支,用于应对一些特定目的的版本开发。临时性分支主要有三种:

  * 功能(feature)分支

  * 预发布(release)分支

  * 修补bug(fixbug)分支

这三种分支都属于临时性需要,使用完以后,应该删除,使得代码库的常设分支始终只有Master和Develop。

四、 功能分支

接下来,一个个来看这三种”临时性分支”。

第一种是功能分支,它是为了开发某种特定功能,从Develop分支上面分出来的。开发完成后,要再并入Develop。

http://www.ruanyifeng.com/blogimg/asset/201207/bg2012070507.png

功能分支的名字,可以采用feature-*的形式命名。

创建一个功能分支:

1
git checkout -b feature-x develop

开发完成后,将功能分支合并到develop分支:

1
2
3
git checkout develop

git merge --no-ff feature-x

删除feature分支:

1
git branch -d feature-x

五、预发布分支

第二种是预发布分支,它是指发布正式版本之前(即合并到Master分支之前),我们可能需要有一个预发布的版本进行测试。

预发布分支是从Develop分支上面分出来的,预发布结束以后,必须合并进Develop和Master分支。它的命名,可以采用release-*的形式。

创建一个预发布分支:

1
git checkout -b release-1.2 develop

确认没有问题后,合并到master分支:

1
2
3
git checkout master

git merge --no-ff release-1.2

对合并生成的新节点,做一个标签

1
git tag -a 1.2

再合并到develop分支:

1
2
3
git checkout develop

git merge --no-ff release-1.2

最后,删除预发布分支:

1
git branch -d release-1.2

六、修补bug分支

最后一种是修补bug分支。软件正式发布以后,难免会出现bug。这时就需要创建一个分支,进行bug修补。

修补bug分支是从Master分支上面分出来的。修补结束以后,再合并进Master和Develop分支。它的命名,可以采用fixbug-*的形式。

http://www.ruanyifeng.com/blogimg/asset/201207/bg2012070508.png

创建一个修补bug分支:

1
git checkout -b fixbug-0.1 master

修补结束后,合并到master分支:

1
2
3
4
5
git checkout master

git merge --no-ff fixbug-0.1

git tag -a 0.1.1

再合并到develop分支:

1
2
3
git checkout develop

git merge --no-ff fixbug-0.1

最后,删除”修补bug分支”:

1
git branch -d fixbug-0.1

3、常用 Git 命令清单

我每天使用 Git ,但是很多命令记不住。

一般来说,日常使用只要记住下图6个命令,就可以了。但是熟练使用,恐怕要记住60~100个命令。

http://www.ruanyifeng.com/blogimg/asset/2015/bg2015120901.png

下面是我整理的常用 Git 命令清单。几个专用名词的译名如下。

  • Workspace:工作区
  • Index / Stage:暂存区
  • Repository:仓库区(或本地仓库)
  • Remote:远程仓库

一、新建代码库

在当前目录新建一个Git代码库

1
git init

新建一个目录,将其初始化为Git代码库

1
git init [project-name]

下载一个项目和它的整个代码历史

1
git clone [url]

二、配置

Git的设置文件为.gitconfig,它可以在用户主目录下(全局配置),也可以在项目目录下(项目配置)。

显示当前的Git配置

1
git config --list

编辑Git配置文件

1
git config -e [--global]

设置提交代码时的用户信息

1
2
3
git config [--global] user.name "[name]"

git config [--global] user.email "[email address]"

三、增加/删除文件

添加指定文件到暂存区

1
git add [file1] [file2] ...

添加指定目录到暂存区,包括子目录

1
git add [dir]

添加当前目录的所有文件到暂存区

1
git add .

添加每个变化前,都会要求确认

对于同一个文件的多处变化,可以实现分次提交

1
git add -p

删除工作区文件,并且将这次删除放入暂存区

1
git rm [file1] [file2] ...

停止追踪指定文件,但该文件会保留在工作区

1
git rm --cached [file]

改名文件,并且将这个改名放入暂存区

1
git mv [file-original] [file-renamed]

四、代码提交

提交暂存区到仓库区

1
git commit -m [message]

提交暂存区的指定文件到仓库区

1
git commit [file1] [file2] ... -m [message]

提交工作区自上次commit之后的变化,直接到仓库区

1
git commit -a

提交时显示所有diff信息

1
git commit -v

使用一次新的commit,替代上一次提交

如果代码没有任何新变化,则用来改写上一次commit的提交信息

1
git commit --amend -m [message]

重做上一次commit,并包括指定文件的新变化

1
git commit --amend [file1] [file2] ...

五、分支

列出所有本地分支

1
git branch

列出所有远程分支

1
git branch -r

列出所有本地分支和远程分支

1
git branch -a

新建一个分支,但依然停留在当前分支

1
git branch [branch-name]

新建一个分支,并切换到该分支

1
git checkout -b [branch]

新建一个分支,指向指定commit

1
git branch [branch] [commit]

新建一个分支,与指定的远程分支建立追踪关系

1
git branch --track [branch] [remote-branch]

切换到指定分支,并更新工作区

1
git checkout [branch-name]

切换到上一个分支

1
git checkout -

建立追踪关系,在现有分支与指定的远程分支之间

1
git branch --set-upstream [branch] [remote-branch]

合并指定分支到当前分支

1
git merge [branch]

选择一个commit,合并进当前分支

1
git cherry-pick [commit]

删除分支

1
git branch -d [branch-name]

删除远程分支

1
2
3
git push origin --delete [branch-name]

git branch -dr [remote/branch]

六、标签

列出所有tag

1
git tag

新建一个tag在当前commit

1
git tag [tag]

新建一个tag在指定commit

1
git tag [tag] [commit]

删除本地tag

1
git tag -d [tag]

删除远程tag

1
git push origin :refs/tags/[tagName]

查看tag信息

1
git show [tag]

提交指定tag

1
git push [remote] [tag]

提交所有tag

1
git push [remote] --tags

新建一个分支,指向某个tag

1
git checkout -b [branch] [tag]

七、查看信息

显示有变更的文件

1
git status

显示当前分支的版本历史

1
git log

显示commit历史,以及每次commit发生变更的文件

1
git log --stat

搜索提交历史,根据关键词

1
git log -S [keyword]

显示某个commit之后的所有变动,每个commit占据一行

1
git log [tag] HEAD --pretty=format:%s

显示某个commit之后的所有变动,其”提交说明”必须符合搜索条件

1
git log [tag] HEAD --grep feature

显示某个文件的版本历史,包括文件改名

1
2
3
git log --follow [file]

git whatchanged [file]

显示指定文件相关的每一次diff

1
git log -p [file]

显示过去5次提交

1
git log -5 --pretty --oneline

显示所有提交过的用户,按提交次数排序

1
git shortlog -sn

显示指定文件是什么人在什么时间修改过

1
git blame [file]

显示暂存区和工作区的差异

1
git diff

显示暂存区和上一个commit的差异

1
git diff --cached [file]

显示工作区与当前分支最新commit之间的差异

1
git diff HEAD

显示两次提交之间的差异

1
git diff [first-branch]...[second-branch]

显示今天你写了多少行代码

1
git diff --shortstat "@{0 day ago}"

显示某次提交的元数据和内容变化

1
git show [commit]

显示某次提交发生变化的文件

1
git show --name-only [commit]

显示某次提交时,某个文件的内容

1
git show [commit]:[filename]

显示当前分支的最近几次提交

1
git reflog

八、远程同步

下载远程仓库的所有变动

1
git fetch [remote]

显示所有远程仓库

1
git remote -v

显示某个远程仓库的信息

1
git remote show [remote]

增加一个新的远程仓库,并命名

1
git remote add [shortname] [url]

取回远程仓库的变化,并与本地分支合并

1
git pull [remote] [branch]

上传本地指定分支到远程仓库

1
git push [remote] [branch]

强行推送当前分支到远程仓库,即使有冲突

1
git push [remote] --force

推送所有分支到远程仓库

1
git push [remote] --all

九、撤销

恢复暂存区的指定文件到工作区

1
git checkout [file]

恢复某个commit的指定文件到暂存区和工作区

1
git checkout [commit] [file]

恢复暂存区的所有文件到工作区

1
git checkout .

重置暂存区的指定文件,与上一次commit保持一致,但工作区不变

1
git reset [file]

重置暂存区与工作区,与上一次commit保持一致

1
git reset --hard

重置当前分支的指针为指定commit,同时重置暂存区,但工作区不变

1
git reset [commit]

重置当前分支的HEAD为指定commit,同时重置暂存区和工作区,与指定commit一致

1
git reset --hard [commit]

重置当前HEAD为指定commit,但保持暂存区和工作区不变

1
git reset --keep [commit]

新建一个commit,用来撤销指定commit

后者的所有变化都将被前者抵消,并且应用到当前分支

1
git revert [commit]

暂时将未提交的变化移除,稍后再移入

1
2
3
git stash

git stash pop

十、其他

生成一个可供发布的压缩包

1
git archive

4、Git 使用规范流程

团队开发中,遵循一个合理、清晰的Git使用流程,是非常重要的。

否则,每个人都提交一堆杂乱无章的commit,项目很快就会变得难以协调和维护。

下面是ThoughtBot 的Git使用规范流程。我从中学到了很多,推荐你也这样使用Git。

http://www.ruanyifeng.com/blogimg/asset/2015/bg2015080501.png

第一步:新建分支

首先,每次开发新功能,都应该新建一个单独的分支(这方面可以参考《Git分支管理策略》)。

获取主干最新代码

1
2
3
git checkout master

git pull

新建一个开发分支myfeature

1
git checkout -b myfeature

第二步:提交分支commit

分支修改后,就可以提交commit了。

1
2
3
4
5
git add --all

git status

git commit --verbose

git add 命令的all参数,表示保存所有变化(包括新建、修改和删除)。从Git 2.0开始,all是 git add 的默认参数,所以也可以用 git add . 代替。

git status 命令,用来查看发生变动的文件。

git commit 命令的verbose参数,会列出 diff 的结果。

第三步:撰写提交信息

提交commit时,必须给出完整扼要的提交信息,下面是一个范本。

1
2
3
4
5
6
7
Present-tense summary under 50 characters

* More information about commit (under 72 characters).

* More information about commit (under 72 characters).

http://project.management-system.com/ticket/123

第一行是不超过50个字的提要,然后空一行,罗列出改动原因、主要变动、以及需要注意的问题。最后,提供对应的网址(比如Bug ticket)。

第四步:与主干同步

分支的开发过程中,要经常与主干保持同步。

1
2
3
git fetch origin

git rebase origin/master

第五步:合并commit

分支开发完成后,很可能有一堆commit,但是合并到主干的时候,往往希望只有一个(或最多两三个)commit,这样不仅清晰,也容易管理。

那么,怎样才能将多个commit合并呢?这就要用到 git rebase 命令。

1
git rebase -i origin/master

git rebase命令的i参数表示互动(interactive),这时git会打开一个互动界面,进行下一步操作。

下面采用Tute Costa的例子,来解释怎么合并commit。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
pick 07c5abd Introduce OpenPGP and teach basic usage

pick de9b1eb Fix PostChecker::Post#urls

pick 3e7ee36 Hey kids, stop all the highlighting

pick fa20af3 git interactive rebase, squash, amend



Rebase 8db7e8b..fa20af3 onto 8db7e8b

\#

Commands:

p, pick = use commit

r, reword = use commit, but edit the commit message

e, edit = use commit, but stop for amending

s, squash = use commit, but meld into previous commit

f, fixup = like "squash", but discard this commit's log message

x, exec = run command (the rest of the line) using shell

\#

These lines can be re-ordered; they are executed from top to bottom.

\#

If you remove a line here THAT COMMIT WILL BE LOST.

\#

However, if you remove everything, the rebase will be aborted.

\#

Note that empty commits are commented out

上面的互动界面,先列出当前分支最新的4个commit(越下面越新)。每个commit前面有一个操作命令,默认是pick,表示该行commit被选中,要进行rebase操作。

4个commit的下面是一大堆注释,列出可以使用的命令。

  • pick:正常选中
  • reword:选中,并且修改提交信息;
  • edit:选中,rebase时会暂停,允许你修改这个commit(参考这里
  • squash:选中,会将当前commit与上一个commit合并
  • fixup:与squash相同,但不会保存当前commit的提交信息
  • exec:执行其他shell命令

上面这6个命令当中,squash和fixup可以用来合并commit。先把需要合并的commit前面的动词,改成squash(或者s)。

pick 07c5abd Introduce OpenPGP and teach basic usage

s de9b1eb Fix PostChecker::Post#urls

s 3e7ee36 Hey kids, stop all the highlighting

pick fa20af3 git interactive rebase, squash, amend

这样一改,执行后,当前分支只会剩下两个commit。第二行和第三行的commit,都会合并到第一行的commit。提交信息会同时包含,这三个commit的提交信息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
This is a combination of 3 commits.

The first commit's message is:

Introduce OpenPGP and teach basic usage



This is the 2nd commit message:

Fix PostChecker::Post#urls



This is the 3rd commit message:

Hey kids, stop all the highlighting

如果将第三行的squash命令改成fixup命令。



pick 07c5abd Introduce OpenPGP and teach basic usage

s de9b1eb Fix PostChecker::Post#urls

f 3e7ee36 Hey kids, stop all the highlighting

pick fa20af3 git interactive rebase, squash, amend

运行结果相同,还是会生成两个commit,第二行和第三行的commit,都合并到第一行的commit。但是,新的提交信息里面,第三行commit的提交信息,会被注释掉。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
This is a combination of 3 commits.

The first commit's message is:

Introduce OpenPGP and teach basic usage



This is the 2nd commit message:

Fix PostChecker::Post#urls



This is the 3rd commit message:

Hey kids, stop all the highlighting

Pony Foo提出另外一种合并commit的简便方法,就是先撤销过去5个commit,然后再建一个新的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
git reset HEAD~5

git add .

git commit -am "Here's the bug fix that closes #28"

git push --force

squash和fixup命令,还可以当作命令行参数使用,自动合并commit。



git commit --fixup

git rebase -i --autosquash

这个用法请参考这篇文章,这里就不解释了。

第六步:推送到远程仓库

合并commit后,就可以推送当前分支到远程仓库了。

1
git push --force origin myfeature

git push命令要加上force参数,因为rebase以后,分支历史改变了,跟远程分支不一定兼容,有可能要强行推送(参见这里)。

第七步:发出Pull Request

提交到远程仓库以后,就可以发出 Pull Request 到master分支,然后请求别人进行代码review,确认可以合并到master。

5、Git远程操作详解

Git是目前最流行的版本管理系统,学会Git几乎成了开发者的必备技能。

Git有很多优势,其中之一就是远程操作非常简便。本文详细介绍5个Git命令,它们的概念和用法,理解了这些内容,你就会完全掌握Git远程操作。

  • git clone
  • git remote
  • git fetch
  • git pull
  • git push

本文针对初级用户,从最简单的讲起,但是需要读者对Git的基本用法有所了解。同时,本文覆盖了上面5个命令的几乎所有的常用用法,所以对于熟练用户也有参考价值。

git

一、git clone

远程操作的第一步,通常是从远程主机克隆一个版本库,这时就要用到git clone命令。

1
git clone <版本库的网址>

比如,克隆jQuery的版本库。

1
git clone https://github.com/jquery/jquery.git

该命令会在本地主机生成一个目录,与远程主机的版本库同名。如果要指定不同的目录名,可以将目录名作为git clone命令的第二个参数。

1
git clone <版本库的网址><本地目录名>

git clone支持多种协议,除了HTTP(s)以外,还支持SSH、Git、本地文件协议等,下面是一些例子。

1
2
3
4
5
6
7
8
9
10
11
12
13
git clone http[s]://example.com/path/to/repo.git/

git clone ssh://example.com/path/to/repo.git/

git clone git://example.com/path/to/repo.git/

git clone /opt/git/project.git

git clone file:///opt/git/project.git

git clone ftp[s]://example.com/path/to/repo.git/

git clone rsync://example.com/path/to/repo.git/

SSH协议还有另一种写法。

1
git clone [user@]example.com:path/to/repo.git/

通常来说,Git协议下载速度最快,SSH协议用于需要用户认证的场合。各种协议优劣的详细讨论请参考官方文档

二、git remote

为了便于管理,Git要求每个远程主机都必须指定一个主机名。git remote命令就用于管理主机名。

不带选项的时候,git remote命令列出所有远程主机。

1
2
3
git remote

origin

使用-v选项,可以参看远程主机的网址。

1
2
3
4
5
git remote -v

origin [git@github](mailto:git@github).com:jquery/jquery.git (fetch)

origin [git@github](mailto:git@github).com:jquery/jquery.git (push)

上面命令表示,当前只有一台远程主机,叫做origin,以及它的网址。

克隆版本库的时候,所使用的远程主机自动被Git命名为origin。如果想用其他的主机名,需要用git clone命令的-o选项指定。

1
2
3
4
5
git clone -o jQuery https://github.com/jquery/jquery.git

git remote

jQuery

上面命令表示,克隆的时候,指定远程主机叫做jQuery。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
git remote show命令加上主机名,可以查看该主机的详细信息。


git remote show <主机名>
git remote add命令用于添加远程主机。


git remote add <主机名><网址>
git remote rm命令用于删除远程主机。


git remote rm <主机名>
git remote rename命令用于远程主机的改名。


git remote rename <原主机名><新主机名>

三、git fetch

一旦远程主机的版本库有了更新(Git术语叫做commit),需要将这些更新取回本地,这时就要用到git fetch命令。

1
git fetch <远程主机名>

上面命令将某个远程主机的更新,全部取回本地。

git fetch命令通常用来查看其他人的进程,因为它取回的代码对你本地的开发代码没有影响。

默认情况下,git fetch取回所有分支(branch)的更新。如果只想取回特定分支的更新,可以指定分支名。

1
git fetch <远程主机名><分支名>

比如,取回origin主机的master分支。

1
git fetch origin master

所取回的更新,在本地主机上要用”远程主机名/分支名”的形式读取。比如origin主机的master,就要用origin/master读取。

git branch命令的-r选项,可以用来查看远程分支,-a选项查看所有分支。

1
2
3
4
5
6
7
8
9
10
git branch -r

origin/master


git branch -a

*master

remotes/origin/master

上面命令表示,本地主机的当前分支是master,远程分支是origin/master。

取回远程主机的更新以后,可以在它的基础上,使用git checkout命令创建一个新的分支。

1
git checkout -b newBrach origin/master

上面命令表示,在origin/master的基础上,创建一个新分支。

此外,也可以使用git merge命令或者git rebase命令,在本地分支上合并远程分支。

1
git merge origin/master

或者

1
git rebase origin/master

上面命令表示在当前分支上,合并origin/master。

四、git pull

git pull命令的作用是,取回远程主机某个分支的更新,再与本地的指定分支合并。它的完整格式稍稍有点复杂。

1
git pull <远程主机名><远程分支名>:<本地分支名>

比如,取回origin主机的next分支,与本地的master分支合并,需要写成下面这样。

1
git pull origin next:master

如果远程分支是与当前分支合并,则冒号后面的部分可以省略。

1
git pull origin next

上面命令表示,取回origin/next分支,再与当前分支合并。实质上,这等同于先做git fetch,再做git merge。

1
2
3
git fetch origin

git merge origin/next

在某些场合,Git会自动在本地分支与远程分支之间,建立一种追踪关系(tracking)。比如,在git clone的时候,所有本地分支默认与远程主机的同名分支,建立追踪关系,也就是说,本地的master分支自动”追踪”origin/master分支。

Git也允许手动建立追踪关系。

1
git branch --set-upstream master origin/next

上面命令指定master分支追踪origin/next分支。

如果当前分支与远程分支存在追踪关系,git pull就可以省略远程分支名。

1
git pull origin

上面命令表示,本地的当前分支自动与对应的origin主机”追踪分支”(remote-tracking branch)进行合并。

如果当前分支只有一个追踪分支,连远程主机名都可以省略。

1
git pull

上面命令表示,当前分支自动与唯一一个追踪分支进行合并。

如果合并需要采用rebase模式,可以使用–rebase选项。

1
git pull --rebase <远程主机名><远程分支名>:<本地分支名>

如果远程主机删除了某个分支,默认情况下,git pull 不会在拉取远程分支的时候,删除对应的本地分支。这是为了防止,由于其他人操作了远程主机,导致git pull不知不觉删除了本地分支。

但是,你可以改变这个行为,加上参数 -p 就会在本地删除远程已经删除的分支。

1
git pull -p

等同于下面的命令

1
2
3
git fetch --prune origin 

git fetch -p

五、git push

git push命令用于将本地分支的更新,推送到远程主机。它的格式与git pull命令相仿。

1
git push <远程主机名><本地分支名>:<远程分支名>

注意,分支推送顺序的写法是<来源地>:<目的地>,所以git pull是<远程分支>:<本地分支>,而git push是<本地分支>:<远程分支>。

如果省略远程分支名,则表示将本地分支推送与之存在”追踪关系”的远程分支(通常两者同名),如果该远程分支不存在,则会被新建。

1
git push origin master

上面命令表示,将本地的master分支推送到origin主机的master分支。如果后者不存在,则会被新建。

如果省略本地分支名,则表示删除指定的远程分支,因为这等同于推送一个空的本地分支到远程分支。

1
git push origin :master

等同于

1
git push origin --delete master

上面命令表示删除origin主机的master分支。

如果当前分支与远程分支之间存在追踪关系,则本地分支和远程分支都可以省略。

1
git push origin

上面命令表示,将当前分支推送到origin主机的对应分支。

如果当前分支只有一个追踪分支,那么主机名都可以省略。

1
git push

如果当前分支与多个主机存在追踪关系,则可以使用-u选项指定一个默认主机,这样后面就可以不加任何参数使用git push。

1
git push -u origin master

上面命令将本地的master分支推送到origin主机,同时指定origin为默认主机,后面就可以不加任何参数使用git push了。

不带任何参数的git push,默认只推送当前分支,这叫做simple方式。此外,还有一种matching方式,会推送所有有对应的远程分支的本地分支。Git 2.0版本之前,默认采用matching方法,现在改为默认采用simple方式。如果要修改这个设置,可以采用git config命令。

1
git config --global push.default matching

或者

1
git config --global push.default simple

还有一种情况,就是不管是否存在对应的远程分支,将本地的所有分支都推送到远程主机,这时需要使用–all选项。

1
git push --all origin

上面命令表示,将所有本地分支都推送到origin主机。

如果远程主机的版本比本地版本更新,推送时Git会报错,要求先在本地做git pull合并差异,然后再推送到远程主机。这时,如果你一定要推送,可以使用–force选项。

1
git push --force origin 

上面命令使用–force选项,结果导致远程主机上更新的版本被覆盖。除非你很确定要这样做,否则应该尽量避免使用–force选项。

最后,git push不会推送标签(tag),除非使用–tags选项。

1
git push origin --tags

Git Cheat Sheet 中文版:Git-Cheat-Sheet

配置

列出当前配置:

1
git config --list

列出repository配置:

1
git config --local --list

列出全局配置:

1
git config --global --list

列出系统配置:

1
git config --system --list

设置用户名:

1
git config --global user.name “[firstname lastname]”

设置用户邮箱:

1
git config --global user.email “[valid-email]”

设置git命令输出为彩色:

1
git config --global color.ui auto

设置git使用的文本编辑器设:

1
git config --global core.editor vi

配置文件

Repository配置对应的配置文件路径[–local]:

1
<repo>/.git/config

用户全局配置对应的配置文件路径[–global]:

1
~/.gitconfig

系统配置对应的配置文件路径[–local]:

1
/etc/gitconfig

创建

复制一个已创建的仓库:

1
2
3
4
5
6
# 通过 SSH
git clone ssh://user@domain.com/repo.git


# 通过 HTTP
git clone http://domain.com/user/repo.git

创建一个新的本地仓库:

1
git init

本地修改

显示工作路径下已修改的文件:

1
git status

显示与上次提交版本文件的不同:

1
git diff

把当前所有修改添加到下次提交中:

1
git add .

把对某个文件的修改添加到下次提交中:

1
git add -p <file>

提交本地的所有修改:

1
git commit -a

提交之前已标记的变化:

1
git commit

附加消息提交:

1
git commit -m 'message here'

提交,并将提交时间设置为之前的某个日期:

1
git commit --date="`date --date='n day ago'`" -am "Commit Message"

修改上次提交

注:请勿修改已发布的提交记录!

1
git commit --amend

修改上次提交的committer date:

1
GIT_COMMITTER_DATE="date" git commit --amend

修改上次提交的author date:

1
git commit --amend --date="date"

把当前分支中未提交的修改移动到其他分支:

1
2
3
4
5
git stash

git checkout branch2

git stash pop

将 stashed changes 应用到当前分支:

1
git stash apply

删除最新一次的 stashed changes:

1
git stash drop

搜索

从当前目录的所有文件中查找文本内容:

1
git grep "Hello"

在某一版本中搜索文本:

1
git grep "Hello" v2.5

提交历史

从最新提交开始,显示所有的提交记录(显示hash, 作者信息,提交的标题和时间):

1
git log

显示所有提交(仅显示提交的hash和message):

1
git log --oneline

显示某个用户的所有提交:

1
git log --author="username"

显示某个文件的所有修改:

1
git log -p <file>

仅显示远端<remote/master>分支与远端<origin/master>分支提交记录的差集:

1
git log --oneline <origin/master>..<remote/master> --left-right

谁,在什么时间,修改了文件的什么内容:

1
git blame <file>

显示reflog:

1
git reflog show 

删除reflog:

1
git reflog delete

分支与标签

列出所有的分支:

1
git branch

列出所有的远端分支:

1
git branch -r

切换分支:

1
git checkout <branch>

创建并切换到新分支:

1
git checkout -b <branch>

基于当前分支创建新分支:

1
git branch <new-branch>

基于远程分支创建新的可追溯的分支:

1
git branch --track <new-branch><remote-branch>

删除本地分支:

1
git branch -d <branch>

强制删除一个本地分支:

注:将会丢失未合并的修改

1
git branch -D <branch>

给当前版本打标签:

1
git tag <tag-name>

给当前版本打标签并附加消息:

1
git tag -a <tag-name>

更新与发布

列出当前配置的远程端:

1
git remote -v

显示远程端的信息:

1
git remote show <remote>

添加新的远程端:

1
git remote add <remote><url>

下载远程端版本,但不合并到HEAD中:

1
git fetch <remote>

下载远程端版本,并自动与HEAD版本合并:

1
git remote pull <remote><url>

将远程端版本合并到本地版本中:

1
git pull origin master

以rebase方式将远端分支与本地合并:

1
git pull --rebase <remote><branch>

将本地版本发布到远程端:

1
git push remote <remote><branch>

删除远程端分支:

1
2
3
4
5
git push <remote> :<branch> (since Git v1.5.0)

or

git push <remote> --delete <branch> (since Git v1.7.0)

发布标签:

1
git push --tags

合并与重置(Rebase)

将分支合并到当前HEAD中:

1
git merge <branch>

将当前HEAD版本重置到分支中:

注:请勿重置已发布的提交!

1
git rebase <branch>

退出重置:

1
git rebase --abort

解决冲突后继续重置:

1
git rebase --continue

使用配置好的merge tool 解决冲突:

1
git mergetool

在编辑器中手动解决冲突后,标记文件为已解决冲突:

1
2
3
git add <resolved-file>

git rm <resolved-file>

合并提交:

1
git rebase -i <commit-just-before-first>

把上面的内容替换为下面的内容:

原内容:

1
2
3
4
5
pick <commit_id>

pick <commit_id2>

pick <commit_id3>

替换为:

1
2
3
4
5
pick <commit_id>

squash <commit_id2>

squash <commit_id3>

撤销

放弃工作目录下的所有修改:

1
git reset --hard HEAD

移除缓存区的所有文件(i.e. 撤销上次git add):

1
git reset HEAD

放弃某个文件的所有本地修改:

1
git checkout HEAD <file>

重置一个提交(通过创建一个截然不同的新提交)

1
git revert <commit>

将HEAD重置到指定的版本,并抛弃该版本之后的所有修改:

1
git reset --hard <commit>

用远端分支强制覆盖本地分支:

1
git reset --hard <remote/branch> e.g., upstream/master, origin/my-feature

将HEAD重置到上一次提交的版本,并将之后的修改标记为未添加到缓存区的修改:

1
git reset <commit>

将HEAD重置到上一次提交的版本,并保留未提交的本地修改:

1
git reset --keep <commit>

删除添加.gitignore文件前错误提交的文件:

1
2
3
4
5
git rm -r --cached .

git add .

git commit -m "remove xyz file"

Git-Flow

索引

安装

  • 你需要有一个可以工作的 git 作为前提。
  • Git flow 可以工作在 OSX, Linux 和 Windows之下
OSX Homebrew:
1
brew install git-flow
OSX Macports:
1
port install git-flow
Linux:
1
apt-get install git-flow
Windows (Cygwin):

安装 git-flow, 你需要 wget 和 util-linux。

1
wget -q -O - --no-check-certificate https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | bash

开始

  • 为了自定义你的项目,Git flow 需要初始化过程。
  • 使用 git-flow,从初始化一个现有的 git 库内开始。
  • 初始化,你必须回答几个关于分支的命名约定的问题。建议使用默认值。
1
git flow init

特性

  • 为即将发布的版本开发新功能特性。
  • 这通常只存在开发者的库中。

创建一个新特性:

下面操作创建了一个新的feature分支,并切换到该分支

1
git flow feature start MYFEATURE

完成新特性的开发:

完成开发新特性。这个动作执行下面的操作:

  1. 合并 MYFEATURE 分支到 ‘develop’
  2. 删除这个新特性分支
  3. 切换回 ‘develop’ 分支
1
git flow feature finish MYFEATURE

发布新特性:

你是否合作开发一项新特性? 发布新特性分支到远程服务器,所以,其它用户也可以使用这分支。

1
git flow feature publish MYFEATURE

取得一个发布的新特性分支:

取得其它用户发布的新特性分支。

1
git flow feature pull origin MYFEATURE

追溯远端上的特性:

通过下面命令追溯远端上的特性

1
git flow feature track MYFEATURE

做一个release版本

  • 支持一个新的用于生产环境的发布版本。
  • 允许修正小问题,并为发布版本准备元数据。

开始创建release版本:

  • 开始创建release版本,使用 git flow release 命令。
  • ‘release’ 分支的创建基于 ‘develop’ 分支。
  • 你可以选择提供一个 [BASE]参数,即提交记录的 sha-1 hash 值,来开启动 release 分支。
  • 这个提交记录的 sha-1 hash 值必须是’develop’ 分支下的。

git flow release start RELEASE [BASE]

创建 release 分支之后立即发布允许其它用户向这个 release 分支提交内容是个明智的做法。命令十分类似发布新特性:

1
git flow release publish RELEASE

(你可以通过 git flow release track RELEASE 命令追溯远端的 release 版本)

完成 release 版本:

完成 release 版本是一个大 git 分支操作。它执行下面几个动作:

  1. 归并 release 分支到 ‘master’ 分支。
  2. 用 release 分支名打 Tag
  3. 归并 release 分支到 ‘develop’
  4. 移除 release 分支。
1
git flow release finish RELEASE

不要忘记使用git push –tags将tags推送到远端

紧急修复

紧急修复来自这样的需求:生产环境的版本处于一个不预期状态,需要立即修正。有可能是需要修正 master 分支上某个 TAG 标记的生产版本。

开始 git flow 紧急修复:

像其它 git flow 命令一样, 紧急修复分支开始自:

1
git flow hotfix start VERSION [BASENAME]

VERSION 参数标记着修正版本。你可以从 [BASENAME]开始,[BASENAME]`为finish release时填写的版本号

完成紧急修复:

当完成紧急修复分支,代码归并回 develop 和 master 分支。相应地,master 分支打上修正版本的 TAG。

1
git flow hotfix finish VERSION
  • Git

    • 有人说是这3个单词的缩写

      • global 全局
      • information 信息
      • track 跟踪器
    • 版本控制工具

  • Github

    • Git和Linux之父,Linus

    • Github让Git变得更易用

    • 官网

      • 浏览器中使用

        • commit(当前版本)
        • 在提交版本的时候,还保存了父版本号,parent
    • 客户端

    • 客户端操作

      • 简单分支操作

        • master分支(一般是放到服务器跑的代码)。master分支是默认分支,是不可以被删除的。
        • 例如创建idea分支,用于开发测试性代码是非常方便的,不会对原来分支的有影响。
        • 当前分支是不能被删除的,要想删除idea分支,就要切换到其他分支,然后删除idea分支
        • 如果只想删除github上的idea分支,本地的idea分支不删除的话,选择unpublic,而不是使用delete,如果使用delete,就会将本地和github的都删除。
        • 可以在github修改默认分支,不是master,但一般不做这样的修改。
Commands

https://github.com/flyhigher139/Git-Cheat-Sheet/blob/master/Img/git-flow-commands.png

Git flow schema

https://github.com/flyhigher139/Git-Cheat-Sheet/blob/master/Img/git-flow-commands-without-flow.png