标签：git

虽然git诞生距今已有12年之久，网上各种关于git的介绍文章数不胜数，但是依然有很多人（包括我自己在内）对于它的功能不能完全掌握。以下的介绍只是基于我个人对于git的理解，并且可能生编硬造了一些不完全符合git说法的词语。目的只是为了让git通俗化，使初学者也能大概了解如何快速上手git。同时，下面所有讨论，我们都假设只使用一个分支，也就是主分支master的情况，虽然这种作法并不符合git规范，但是现实情况中绝大部分用户是直接在master分支上进行工作的，所以在这里我们不去引入更加复杂的各种分支的情况，也不涉及标签tag的操作，只讲在最简单的主分支上如何回退。

基本概念

3个步骤

正常情况下，我们的工作流就是3个步骤，对应上图中的3个箭头线：

git add .
git commit -m "comment"
git push

1. git add .把所有文件放入暂存区；
2. git commit把所有文件从暂存区提交进本地仓库；
3. git push把所有文件从本地仓库推送进远程仓库。

4个区

git之所以令人费解，主要是它相比于svn等等传统的版本管理工具，多引入了一个暂存区(Stage)的概念，就因为多了这一个概念，而使很多人疑惑。其实，在初学者来说，每个区具体怎么工作的，我们完全不需要关心，而只要知道有这么4个区就够了：

• 工作区(Working Area)
• 暂存区(Stage)
• 本地仓库(Local Repository)
• 远程仓库(Remote Repository)

5种状态

以上4个区，进入每一个区成功之后会产生一个状态，再加上最初始的一个状态，一共是5种状态。以下我们把这5种状态分别命名为：

• 未修改(Origin)
• 已修改(Modified)
• 已暂存(Staged)
• 已提交(Committed)
• 已推送(Pushed)

检查修改

了解了基本概念之后，我们来谈一谈犯错误之后如何撤销的问题。首先，我们要了解如何检查这3个步骤当中每一个步骤修改了什么，然后才好判断有没有修改成功。检查修改的二级命令都相同，都是diff，只是参数有所不同。

已修改，未暂存

git diff

首先，我们来看一下，如果我们只是简单地在浏览器里保存了一下文件，但是还没有做git add .之前，我们如何检查有哪些修改。我们先随便拿一个文件来做一下实验：

我们在文件开头的第2行胡乱加了4个数字1234，存盘，这时文件进入了已修改状态，但是还没有进入暂存区，我们运行git diff，结果如下：

diff --git a/index.md b/index.md
index 73ff1ba..1066758 100644
--- a/index.md
+++ b/index.md
@@ -1,5 +1,5 @@
 ---
-layout: main
+1234layout: main
 color: black
 ---

git diff的结果告诉我们哪些文件已经做了哪些修改。

已暂存，未提交

git diff --cached

现在我们把修改放入暂存区看一下。先执行git add .，然后执行git diff，你会发现没有任何结果：

这说明git diff这个命令只检查我们的工作区和暂存区之间的差异，如果我们想看到暂存区和本地仓库之间的差异，就需要加一个参数git diff –cached：

diff --git a/index.md b/index.md
index 73ff1ba..1066758 100644
--- a/index.md
+++ b/index.md
@@ -1,5 +1,5 @@
 ---
-layout: main
+1234layout: main
 color: black
 ---

这时候我们看到的差异是暂存区和本地仓库之间的差异。

已提交，未推送

git diff master origin/master

现在，我们把修改从暂存区提交到本地仓库，再看一下差异。先执行git commit，然后再执行git diff –cached，没有差异，执行git diff master origin/master，可以看到差异：

在这里，master就是你的本地仓库，而origin/master就是你的远程仓库，master是主分支的意思，因为我们都在主分支上工作，所以这里两边都是master，而origin就代表远程。

撤销修改

了解清楚如何检查各种修改之后，我们开始尝试各种撤销操作。

已修改，未暂存

如果我们只是在编辑器里修改了文件，但还没有执行git add .，这时候我们的文件还在工作区，并没有进入暂存区，我们可以用：

git checkout .

或者

git reset --hard

来进行撤销操作。

可以看到，在执行完git checkout .之后，修改已被撤销，git diff没有任何内容了。
一对反义词 git add .的反义词是git checkout .。做完修改之后，如果你想向前走一步，让修改进入暂存区，就执行git add .，如果你想向后退一步，撤销刚才的修改，就执行git checkout .。

已暂存，未提交

你已经执行了git add .，但还没有执行git commit -m “comment”。这时候你意识到了错误，想要撤销，你可以执行：

git reset
git checkout .

或者

git reset --hard

git reset只是把修改退回到了git add .之前的状态，也就是说文件本身还处于已修改未暂存状态，你如果想退回未修改状态，还需要执行git checkout .。
或许你已经注意到了，以上两个步骤都可以用同一个命令git reset –hard来完成。是的，就是这个强大的命令，可以一步到位地把你的修改完全恢复到未修改的状态。

已提交，未推送

你的手太快，你既执行了git add .，又执行了git commit，这时候你的代码已经进入了你的本地仓库，然而你后悔了，怎么办？不要着急，还有办法。

git reset --hard origin/master

还是这个git reset –hard命令，只不过这次多了一个参数origin/master，正如我们上面讲过的，origin/master代表远程仓库，既然你已经污染了你的本地仓库，那么就从远程仓库把代码取回来吧。

已推送

很不幸，你的手实在是太快了，你既git add了，又git commit了，并且还git push了，这时你的代码已经进入远程仓库。如果你想恢复的话，还好，由于你的本地仓库和远程仓库是等价的，你只需要先恢复本地仓库，再强制push到远程仓库就好了：

git reset --hard HEAD^
git push -f

总结

以上4种状态的撤销我们都用到了同一个命令git reset –hard，前2种状态的用法甚至完全一样，所以只要掌握了git reset –hard这个命令的用法，从此你再也不用担心提交错误了。

Git是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目，可以有效、高速的处理从很小到非常大的项目版本管理。Git是Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

Git常用操作命令

1、远程仓库相关命令

检出仓库：$ git clone git://github.com/jquery/jquery.git
查看远程仓库：$ git remote -v
添加远程仓库：$ git remote add [name] [url]
删除远程仓库：$ git remote rm [name]
修改远程仓库：$ git remote set-url --push [name] [newUrl]
拉取远程仓库：$ git pull [remoteName] [localBranchName]
推送远程仓库：$ git push [remoteName] [localBranchName]

如果想把本地的某个分支test提交到远程仓库，并作为远程仓库的master分支，或者作为另外一个名叫test的分支，如下：

$git push origin test:master         // 提交本地test分支作为远程的master分支
$git push origin test:test              // 提交本地test分支作为远程的test分支

2、分支(branch)操作相关命令

查看本地分支：$ git branch
查看远程分支：$ git branch -r
创建本地分支：$ git branch [name] ----注意新分支创建后不会自动切换为当前分支
切换分支：$ git checkout [name]
创建新分支并立即切换到新分支：$ git checkout -b [name]
删除分支：$ git branch -d [name] ---- -d选项只能删除已经参与了合并的分支，对于未有合并的分支是无法删除的。如果想强制删除一个分支，可以使用-D选项
合并分支：$ git merge [name] ----将名称为[name]的分支与当前分支合并
创建远程分支(本地分支push到远程)：$ git push origin [name]
删除远程分支：$ git push origin :heads/[name] 或 $ gitpush origin :[name]

创建空的分支：(执行命令之前记得先提交你当前分支的修改，否则会被强制删干净没得后悔)

$git symbolic-ref HEAD refs/heads/[name]
$rm .git/index
$git clean -fdx

3、版本(tag)操作相关命令

查看版本：$ git tag
创建版本：$ git tag [name]
删除版本：$ git tag -d [name]
查看远程版本：$ git tag -r
创建远程版本(本地版本push到远程)：$ git push origin [name]
删除远程版本：$ git push origin :refs/tags/[name]
合并远程仓库的tag到本地：$ git pull origin --tags
上传本地tag到远程仓库：$ git push origin --tags
创建带注释的tag：$ git tag -a [name] -m 'yourMessage'

4、子模块(submodule)相关操作命令

添加子模块：$ git submodule add [url] [path] 如下：

$git submodule add git://github.com/soberh/ui-libs.git src/main/webapp/ui-libs
初始化子模块：$ git submodule init  ----只在首次检出仓库时运行一次就行
更新子模块：$ git submodule update ----每次更新或切换分支后都需要运行一下
删除子模块：（分4步走哦）

1) $ git rm --cached [path]
2) 编辑“.gitmodules”文件，将子模块的相关配置节点删除掉
3) 编辑“ .git/config”文件，将子模块的相关配置节点删除掉
4) 手动删除子模块残留的目录

5、忽略一些文件、文件夹不提交

在仓库根目录下创建名称为“.gitignore”的文件，写入不需要的文件夹名或文件，每个元素占一行即可，如下:

target
bin
*.db

Git 常用命令

git branch 查看本地所有分支
git status 查看当前状态
git commit 提交
git branch -a 查看所有的分支
git branch -r 查看本地所有分支
git commit -am "init" 提交并且加注释
git remote add origin [email protected]:ndshow
git push origin master 将文件给推到服务器上
git remote show origin 显示远程库origin里的资源
git push origin master:develop
git push origin master:hb-dev 将本地库与服务器上的库进行关联
git checkout --track origin/dev 切换到远程dev分支
git branch -D master develop 删除本地库develop
git checkout -b dev 建立一个新的本地分支dev
git merge origin/dev 将分支dev与当前分支进行合并
git checkout dev 切换到本地dev分支
git remote show 查看远程库
git add .
git rm 文件名(包括路径) 从git中删除指定文件
git clone git://github.com/schacon/grit.git 从服务器上将代码给拉下来
git config --list 看所有用户
git ls-files 看已经被提交的
git rm [file name] 删除一个文件
git commit -a 提交当前repos的所有的改变
git add [file name] 添加一个文件到git index
git commit -v 当你用－v参数的时候可以看commit的差异
git commit -m "This is the message describing the commit" 添加commit信息
git commit -a -a是代表add，把所有的change加到git index里然后再commit
git commit -a -v 一般提交命令
git log 看你commit的日志
git diff 查看尚未暂存的更新
git rm a.a 移除文件(从暂存区和工作区中删除)
git rm --cached a.a 移除文件(只从暂存区中删除)
git commit -m "remove" 移除文件(从Git中删除)
git rm -f a.a 强行移除修改后文件(从暂存区和工作区中删除)
git diff --cached 或 $ git diff --staged 查看尚未提交的更新
git stash push 将文件给push到一个临时空间中
git stash pop 将文件从临时空间pop下来
---------------------------------------------------------
git remote add origin [email protected]:username/Hello-World.git
git push origin master 将本地项目给提交到服务器中
-----------------------------------------------------------
git pull 本地与服务器端同步
-----------------------------------------------------------------
git push (远程仓库名) (分支名) 将本地分支推送到服务器上去。
git push origin serverfix:awesomebranch
------------------------------------------------------------------
git fetch 相当于是从远程获取最新版本到本地，不会自动merge
git commit -a -m "log_message" (-a是提交所有改动，-m是加入log信息) 本地修改同步至服务器端 ：
git branch branch_0.1 master 从主分支master创建branch_0.1分支
git branch -m branch_0.1 branch_1.0 将branch_0.1重命名为branch_1.0
git checkout branch_1.0/master 切换到branch_1.0/master分支
du -hs
-----------------------------------------------------------
mkdir WebApp
cd WebApp
git init
touch README
git add README
git commit -m 'first commit'
git remote add origin [email protected]:daixu/WebApp.git
git push -u origin master

以上为Git中常用的命令总结。

自己有自己的开源项目，工作有工作的闭源项目，两者往往通过不同的 Git 帐号进行 commit 操作，那如何为不同的项目设置不同的 Git 帐号呢？

我们一般的操作都是:

git config --global user.name
git config --global user.email

这两步来设置 Git 帐号名与邮箱，但是针对特定项目，比如：

我 Git 的 global 用户名是 liumapp，但在 B 项目下想使用 lm 这个用户名来进行提交。

这种情况下，我们需要进行下列操作：

• cd .git

• vim config

添加下列代码：

[user]
    name=lm
    [email protected]

• :wq 保存文件将立即生效，执行 commit 即可发现提交的用户为 lm。

今天在git push origin master时，竟然出现了错误 (gnome-ssh-askpass:32737): Gtk-WARNING **: cannot open display: error: unable to read askpass response from ‘/usr/libexec/openssh/gnome-ssh-askpass’根本原因是执行了该脚本

$ cat /etc/profile.d/gnome-ssh-askpass.sh
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass

解决方式

$ unset SSH_ASKPASS

再次执行git

$ git push origin master

不再提示错误。

Git可以使用reset重置来撤销提交。

方法一

撤销最后一次提交

git reset HEAD~1

执行后，状态重置为上一次提交，且撤回提交的文件的状态变回unstaged，即文件没有被git跟踪。

示例

$ git commit -m 'add test.html'
[master ade6d7e] add test.html
 1 file changed, 1 insertion(+)
 create mode 100644 test.html
$ git reset HEAD~1
$ git status
On branch master
Untracked files:
 (use "git add <file>..." to include in what will be committed)

    test.html

nothing added to commit but untracked files present (use "git add" to track)

撤回后test.html为Untracked files。

方法二

git reset --soft HEAD~1

使用–soft，执行后，状态重置为上一次提交，但撤回提交的文件add到git，被git跟踪。

示例

$ git commit -m 'add test.html'
[master 877b8f0] add test.html
 1 file changed, 1 insertion(+)
 create mode 100644 test.html

$ git reset --soft HEAD~1

clcaza@clcaza MINGW64 /d/webstormProjectsDemo/ngcli-demo (master)
$ git status
On branch master
Changes to be committed:
 (use "git reset HEAD <file>..." to unstage)

    new file: test.html

test.html状态为Changes to be committed

一、配置提交时的用户名与邮件名称(注:只是标识本次commit是谁提交的)

1.1 通过命令的方式

$ git config --global user.name "songshuiyang"
$ git config --global user.email [email protected]

注: global 全局配置,在此电脑上的所有项目的git提交都会用这个用户名和邮件

1.2 通过修改配置文件的方式

文件路径: 用户目录/.gitconfig 文件

把name email改成(新增)自己的配置即可

[user]
        name = songshuiyang
        email = [email protected]

二、配置 短命令

2.1 通过命令的方式

$ git config --global alias.st status
$ git config --global alias.ci commit
$ git congig --global alias.co checkout
$ git congig --global alias.br branch

2.2 通过修改配置文件的方式

[alias]
    co = checkout
    ci = commit
    st = status
    cm = commit -m
    br = branch
    bm = branch -m
    bd = branch -D
    cb = checkout -b
    df = diff
    ls = log --stat
    lp = log -p
    plo = pull origin
    plode = pull origin develop
    pho = push origin

三、配置文件

Git的三个配置文件

• 版本库级别的配置文件,文件路径: 项目路径/.git/config

• 全局配置文件, 文件路径: 用户目录/.gitconfig

• 系统级配置文件,文件路径: 安装目录/etc目录下

优先级: 版本库级别的配置文件 > 全局配置文件 > 系统级配置文件

四、文件 .git/index

实际上就是一个包括文件索引的目录树,像是一个虚拟的工作区,记录了文件名和文件的状态信息(时间戳和文件长度),文件的内容保存在.git/objects目录下,文件索引建立了文件和对象库中对象实体之间的对应

工作区,版本区,暂存区原理图

1、创建本地分支 local_branch

git branch local_branch

2、创建本地分支local_branch 并切换到local_branch分支

git checkout -b local_branch

3、切换到分支local_branch

git checkout local_branch

4、推送本地分支local_branch到远程分支 remote_branch并建立关联关系

a.远程已有remote_branch分支并且已经关联本地分支local_branch且本地已经切换到local_branch

git push

b.远程已有remote_branch分支但未关联本地分支local_branch且本地已经切换到local_branch

git push -u origin/remote_branch

c.远程没有有remote_branch分支并，本地已经切换到local_branch

git push origin local_branch:remote_branch

5、删除本地分支local_branch

git branch -d local_branch

6、删除远程分支remote_branch

git push origin  :remote_branch

git branch -m | -M oldbranch newbranch 重命名分支，如果newbranch名字分支已经存在，则需要使用-M强制重命名，否则，使用-m进行重命名。

git branch -d | -D branchname 删除branchname分支

git branch -d -r branchname 删除远程branchname分支

7、查看本地分支

git branch

8、查看远程和本地分支

git branch -a

前言

一直在使用git做版本控制，也一直工作很顺利，直到和别人发生冲突的时候。这才注意到git 工作流并不是那么简单。比如，之前遇到的清理历史。百度到的资料很多，重复性也很多，但实践性操作很少，我很难直接理解其所表达的含义。直接望文生义经常得到错误的结论，只能用时间去检验真理了，不然看到的结果都是似懂非懂，最后还是一团糟。

学习git工作流

一、最简单的使用，不推荐

1.1 创建仓库

$ pwd
/home/ryan/workspace/l4git-workflow
$ touch readme.md
$ ls
readme.md
$ touch .gitignore
$ git init
初始化空的 Git 仓库于 /home/ryan/workspace/l4git-workflow/.git/
$ touch test.txt
$ git add .
$ git commit -m "init"
[master （根提交） dae77d6] init
 3 files changed, 12 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 readme.md
 create mode 100644 test.txt
$ git remote add origin [email protected]:Ryan-Miao/l4git-workflow.git
$ git push -u origin master
对象计数中: 5, 完成.
Delta compression using up to 4 threads.
压缩对象中: 100% (3/3), 完成.
写入对象中: 100% (5/5), 388 bytes | 0 bytes/s, 完成.
Total 5 (delta 0), reused 0 (delta 0)
To [email protected]:Ryan-Miao/l4git-workflow.git
 * [new branch]      master -> master
分支 master 设置为跟踪来自 origin 的远程分支 master。

1.2 模拟用户A

git clone [email protected]:Ryan-Miao/l4git-workflow.git
git checkout a
touch a.txt
//write one
//....
$ git add .
$ git commit -m "one"
[a 53ff45e] one
 2 files changed, 34 insertions(+), 2 deletions(-)
 create mode 100644 a.txt

此时，a还没有提交到 origin 。 git log 如下：

1.3 模拟用户B

git clone [email protected]:Ryan-Miao/l4git-workflow.git
git checkout b

$ touch b.txt

//write something
//…

$ git add .
$ git commit -m "b write one"
[b 847078e] b write one
 1 file changed, 1 insertion(+)
 create mode 100644 b.txt

//write something
//….

$ git add . $ git commit -m "b write two" [b 3f30f41] b write two 1 file changed, 2 insertions(+), 1 deletion(-)

此时，git log如下

1.4 模拟用户A

A和B分别是在本地开发，所以这种顺序是未知的，也许A比B先commit一次，也许B先commit一次。这里的先后是指commit的时间戳。但都是在本地提交的代码。
write something

git add .
git commit -m "a write two"

wirte something

git add .
git commit -m "write three"

A push to server branch a

$ git push origin a:a
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:Ryan-Miao/l4git-workflow.git
 * [new branch]      a -> a

A created a Pull Request

1.5 模拟用户C

C review the PR and then merged it.

此时，github的历史如下：

可以看出，merge的时候多了一次commit，message默认为

Merge pull request #1 from Ryan-Miao/a...

现在看起来，只有a一个人的历史记录，还算清楚，a做了3次提交。

1.6 模拟用户B

用户B提交前先pull master，更新最新的代码到本地，防止冲突。

git fetch
git merge origin/master

此时log看起来有点乱。如下：

让人感到混乱的是b原来的历史只有自己的提交，更新了master到本地之后，历史记录被插入了master中的历史。于是，发现原来自己干净的历史被中间插入多次commit。甚至两次merge master的日志显得又长又碍眼。但不管怎么说，B还是要提交的。

于是，B提交到远程分支b：

1.7 模拟用户C

这时候，A完成了feature a，然后提了PR，然后找他人C merge了。而后，B也完成了feature b，提了PR，需要review and merge。 C review之后，approved， 然后D review， D merge。

此时，项目基本走上正规。feature一个一个添加进去，重复之前的工作流程： fetch -》 work -》 commit -》 push -》 PR -》 merged。
然后，项目历史就变成了这样：

一眼大概看起来还好，每次都能看到提交历史，只要不是message写的特别少，差不多可以理解最近提交的内容。然而，仔细一看，顺序好像不对。目前一共两个feature，但历史却远远超过2个。没关系，保证细粒度更容易体现开发进度。然而，这些历史并不是按照feature的发布顺序，那么，当我想要找到feature a的时候就很难串联起来。如果commit足够多，时间跨度足够大，甚至根本看不出来feature a到底做了哪些修改。

这时候想要使用图形化git 历史工具来帮助理解历史：

这里，还好，还勉强能看出走向。但当10个上百个人同时开发的话，线简直不能看了，时间跨度足够大的话，线也看不完。

因此，这种模式，正是我们自己当前采用的模式。差评。这还不算完，后面更大的困难来了。最先发布的feature a出了问题，必须回滚。怎么做到。关于回滚，就是另一个话题了。 但我们应该知道使用revert而不是reset. 但revert只能回滚指定的commit，或者连续的commit，而且revert不能revert merge操作。这样，想回滚feature a, 我们就要找到a的几次提交的版本号，然后由于不是连续的，分别revert。这会造成复杂到不想处理了。好在github给了方便的东西，PR提供了revert的机会。找到以前的PR。

但是，这绝对不是个好操作！

二、推荐的工作流程

造成上述现象的原因是因为各自异步编程决定的。因为每个人都可以随时间提交，最后合并起来的时候以提交时间戳来作为序列的依据，就会变成这样。因此，当需要提交的远程服务器的时候，如果能重写下commit的时间为当前时间，然后push到服务端，历史就会序列到最后了。

2.1 模拟用户C

C用户新下载代码。

$ git clone [email protected]:Ryan-Miao/l4git-workflow.git c正克隆到 'c'...
remote: Counting objects: 28, done.
remote: Compressing objects: 100% (17/17), done.
remote: Total 28 (delta 8), reused 22 (delta 4), pack-reused 0
接收对象中: 100% (28/28), 5.90 KiB | 0 bytes/s, 完成.
处理 delta 中: 100% (8/8), 完成.
检查连接... 完成。

然后编辑，提交

$ cd c
$ git config user.name "C"
$ ls
a.txt  b.txt  readme.md  test.txt
$ vim c.txt
$ git add .
$ git commit -m "C write one"
[master cf3f757] C write one
 1 file changed, 2 insertions(+)
 create mode 100644 c.txt

2.2 模拟用户D

同时，D也需要开发新feature

$ git clone [email protected]:Ryan-Miao/l4git-workflow.git d正克隆到 'd'...
remote: Counting objects: 28, done.
remote: Compressing objects: 100% (17/17), done.
remote: Total 28 (delta 8), reused 22 (delta 4), pack-reused 0
接收对象中: 100% (28/28), 5.90 KiB | 0 bytes/s, 完成.
处理 delta 中: 100% (8/8), 完成.
检查连接... 完成。
$ cd d
/d$ git config user.name "D"
/d$ vim d.txt
/d$ git add .
/d$ git commit -m "d write one"
[master db7a6e9] d write one
 1 file changed, 1 insertion(+)
 create mode 100644 d.txt

2.3 C继续开发

$ vim c.txt
$ git add .
$ git commit -m "c write two"
[master 01b1210] c write two
 1 file changed, 1 insertion(+)

2.4 D继续开发

/d$ vim d.txt
/d$ git add .
/d$ git commit -m "d write two"
[master a1371e4] d write two
 1 file changed, 1 insertion(+)

2.5 C 提交

$ vim c.txt 
$ git add .
$ git commit -m "c write three"
[master 13b7dde] c write three
 1 file changed, 1 insertion(+)

C开发结束，提交到远程

$ git status
位于分支 master
您的分支领先 'origin/master' 共 3 个提交。
  （使用 "git push" 来发布您的本地提交）
无文件要提交，干净的工作区
$ git push origin master:C
对象计数中: 9, 完成.
Delta compression using up to 4 threads.
压缩对象中: 100% (6/6), 完成.
写入对象中: 100% (9/9), 750 bytes | 0 bytes/s, 完成.
Total 9 (delta 3), reused 0 (delta 0)
remote: Resolving deltas: 100% (3/3), completed with 1 local object.
To [email protected]:Ryan-Miao/l4git-workflow.git
 * [new branch]      master -> C

2.6 C 提PR

然后，create a Pull Request.

2.7 C修改再push

然后，发现还有个bug要修复，再次修改提交到远程C

$ vim c.txt 
$ git add .
$ git commit -m "C finish something else"
[master 2c5ff94] C finish something else
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git push origin master:C
对象计数中: 3, 完成.
Delta compression using up to 4 threads.
压缩对象中: 100% (3/3), 完成.
写入对象中: 100% (3/3), 301 bytes | 0 bytes/s, 完成.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To [email protected]:Ryan-Miao/l4git-workflow.git
   13b7dde..2c5ff94  master -> C

2.8 C发现提交次数过多，历史太乱，合并部分历史

这时，发现一个问题，由于C在开发过程中提交了多次，而这几次提交的message其实没有多大意思，只是因为C可能为了保存代码，也可能是暂存。总之，C的前3次提交的message的含义其实是一样的，都是创建C文件，都是一个主题，那么为了维护历史的干净。最好把这3条信息合并成一条C create file c.txt。

参考git 合并历史，我们需要将3次历史合并成显示为一次。

查看git历史，找到需要合并的起始区间

$ git log --oneline
2c5ff94 C finish something else
13b7dde c write three
01b1210 c write two
cf3f757 C write one
7151f4c 记录操作。
0bfe562 Merge pull request #2 from Ryan-Miao/b_remote
d81ce20 Merge remote-tracking branch 'origin/master' into b
2d74cfb Merge pull request #1 from Ryan-Miao/a
b90a3dd write three
4b1629e a write two
3f30f41 b write two
847078e b write one
53ff45e one
dae77d6 init

显然，是要合并cf3f757到13b7dde。那么找到前一个的版本号为7151f4c

git rebase - i 7151f4c

然后进入交互界面，因为我们想要把第3次和第2次以及第1次提交信息合并。将第3次的类型修改为squash, 意思是和第2次合并。然后将第2次的类型修改为squash, 同样是指合并的前一个commit。

不同git的交互略有不同，之前在windows上的git bash是完全按照vim的命令修改的。本次测试基于Ubuntu，发现存档命令为ctel + X。确认后进入下一个界面，合并3次提交后需要一个message

删除或者anyway you like， 更改message。存档。完成。

$ git rebase -i 7151f4c
[分离头指针 e3764c5] c create  file c.txt
 Date: Fri Oct 20 22:06:24 2017 +0800
 1 file changed, 4 insertions(+)
 create mode 100644 c.txt
Successfully rebased and updated refs/heads/master.

Tips

当在rebase过程中出现了失误，可以使用git rebase –abort返回初始状态。如果发现冲突，则可以解决冲突，然后git rebase –continue .

好像已有 rebase-merge 目录，我怀疑您正处于另外一个变基操作
过程中。 如果是这样，请执行

git rebase (--continue | --abort | --skip)

如果不是这样，请执行

rm -fr "/home/ryan/temp/c/.git/rebase-merge"

然后再重新执行变基操作。 为避免丢失重要数据，我已经停止当前操作。

此时，查看log， 显然，C的那三次提交已经合并了。

$ git log --oneline
50b9fe9 C finish something else
e3764c5 c create  file c.txt
7151f4c 记录操作。
0bfe562 Merge pull request #2 from Ryan-Miao/b_remote
d81ce20 Merge remote-tracking branch 'origin/master' into b
2d74cfb Merge pull request #1 from Ryan-Miao/a
b90a3dd write three
4b1629e a write two
3f30f41 b write two
847078e b write one
53ff45e one
dae77d6 init

2.9 C再次push

之前的push已经不能用了。需要开新分支推送过去。因为 rebase 只能在本地分支做。不要修改公共分支 。

$ git push origin master:C
To [email protected]:Ryan-Miao/l4git-workflow.git
 ! [rejected]        master -> C (non-fast-forward)
error: 无法推送一些引用到 '[email protected]:Ryan-Miao/l4git-workflow.git'
提示：更新被拒绝，因为推送的一个分支的最新提交落后于其对应的远程分支。
提示：检出该分支并整合远程变更（如 'git pull ...'），然后再推送。详见
提示：'git push --help' 中的 'Note about fast-forwards' 小节。

选择推送的新分支C2

$ git push origin master:C2
对象计数中: 6, 完成.
Delta compression using up to 4 threads.
压缩对象中: 100% (5/5), 完成.
写入对象中: 100% (6/6), 569 bytes | 0 bytes/s, 完成.
Total 6 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 1 local object.
To [email protected]:Ryan-Miao/l4git-workflow.git
 * [new branch]      master -> C2

创建新的PR

2.10 新的merge方式： rebase

通过开始的普通流程发现，每次merge的时候，都会多出一条新的提交信息，这让历史看起来很奇怪。那么，可以选择rebase到master，变基，就是重新以master为基本，把当前的提交直接移动到master的后面。不会因为提交时间的离散导致多次commit的message被拆散。 选择 rebase and merge

这时候，可以看到C提交的两次信息都是最新的，没有发生交叉。而且也没有产生多余的merge信息。

有人会问，那么岂不是看不到PR的地址了。点开C的历史。可以看到message下方是有PR的编号的：

对了，刚开始的PR要记得close

2.11 这时候D也完成了

/d$ git push origin master:D
对象计数中: 10, 完成.
Delta compression using up to 4 threads.
压缩对象中: 100% (7/7), 完成.
写入对象中: 100% (10/10), 4.49 KiB | 0 bytes/s, 完成.
Total 10 (delta 2), reused 4 (delta 1)
remote: Resolving deltas: 100% (2/2), completed with 1 local object.
To [email protected]:Ryan-Miao/l4git-workflow.git
 * [new branch]      master -> D

提PR， 这时候，如果采用merge：

结果必然发现，1） d提交message被按照时间分散插入历史了(被插入到c的历史之前)， 2）多了一次 Merge pull request #5 from Ryan-Miao/D..的提交信息。同开头所述一样，历史开始变得混乱了。那么，这种问题怎么办呢？

2.12 提交前rebase

就像C rebase后merge到master一样。我们一样可以在本地做到这样的事情。在本地rebase，让我们本次feature的提交全部插到master节点之后，有序，而且容易revert。
本次，以新的E和F交叉commit为例子，最终将得到各自分开的历史

E:

$ git clone [email protected]:Ryan-Miao/l4git-workflow.git e
正克隆到 'e'...
remote: Counting objects: 52, done.
remote: Compressing objects: 100% (33/33), done.
remote: Total 52 (delta 18), reused 36 (delta 7), pack-reused 0
接收对象中: 100% (52/52), 7.91 KiB | 0 bytes/s, 完成.
处理 delta 中: 100% (18/18), 完成.
检查连接... 完成。

$ cd e
/e$ vim e.txt
/e$ git add .
/e$ git config user.name "E"
/e$ git commit -m "e commit one"
[master 77ecd73] e commit one
 1 file changed, 1 insertion(+)
 create mode 100644 e.txt

F:

$ git clone [email protected]:Ryan-Miao/l4git-workflow.git f
正克隆到 'f'...
remote: Counting objects: 52, done.
remote: Compressing objects: 100% (33/33), done.
remote: Total 52 (delta 18), reused 36 (delta 7), pack-reused 0
接收对象中: 100% (52/52), 7.91 KiB | 0 bytes/s, 完成.
处理 delta 中: 100% (18/18), 完成.
检查连接... 完成。

$ cd f
$ vim f.txt
$ git config user.name "F"
$ git add .
$ git commit -m "d write one"
[master b41f8c5] d write one
 1 file changed, 2 insertions(+)
 create mode 100644 f.txt

E:

/e$ vim e.txt
/e$ git add .
/e$ git commit -m "e write two"
[master 2b8c9fb] e write two
 1 file changed, 1 insertion(+)

F:

$ vim f.txt
$ git add .
$ git commit -m "f write two"
[master de9051b] f write two
 1 file changed, 1 insertion(+)

E:

/e$ vim e.txt 
/e$ git add .
/e$ git commit -m "e write three"
[master b1b9f6e] e write three
 1 file changed, 2 insertions(+)

这时候，e完成了，需要提交。提交前先rebase：

/e$ git fetch
/e$ git rebase origin/master
当前分支 master 是最新的。

然后，再提交

/e$ git push origin master:E
对象计数中: 9, 完成.
Delta compression using up to 4 threads.
压缩对象中: 100% (6/6), 完成.
写入对象中: 100% (9/9), 753 bytes | 0 bytes/s, 完成.
Total 9 (delta 3), reused 0 (delta 0)
remote: Resolving deltas: 100% (3/3), completed with 1 local object.
To [email protected]:Ryan-Miao/l4git-workflow.git
 * [new branch]      master -> E

然后， PR, merge.

同样F:

$ git status
位于分支 master
您的分支领先 'origin/master' 共 2 个提交。
  （使用 "git push" 来发布您的本地提交）
无文件要提交，干净的工作区
$ git fetch 
remote: Counting objects: 12, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 12 (delta 6), reused 6 (delta 3), pack-reused 0
展开对象中: 100% (12/12), 完成.
来自 github.com:Ryan-Miao/l4git-workflow
   24c6818..f36907c  master     -> origin/master
 * [新分支]          E          -> origin/E
$ git rebase origin/master
首先，回退分支以便在上面重放您的工作...
应用：d write one
应用：f write two

$ git push origin master:F
对象计数中: 6, 完成.
Delta compression using up to 4 threads.
压缩对象中: 100% (4/4), 完成.
写入对象中: 100% (6/6), 515 bytes | 0 bytes/s, 完成.
Total 6 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 1 local object.
To [email protected]:Ryan-Miao/l4git-workflow.git
 * [new branch]      master -> F

PR， rebase and merge。 这时候看history：

按照前几次的做法，E和F交叉在本地提交，每次commit的时间戳也是交叉，最终合并到master的时候，历史并没有被拆散。而是像我们期待的一样，顺序下来。这才是我们想要的。通过看图形化界面也能看出区别：

绿色的线是master

那么，操作便是fetch-》rebase。事实上，可以二合一为：

git pull --rebase origin master

三、最终结果

在都没提交到server的时候， 历史是分散在各个开发者的本地，但commit时间有先后。

按照rebase的用法，提交前rebase一次，就可以使得一个feature的提交串联到一起

最终在github的commit看起来也就是顺畅的多

四、金科玉律

想维持树的整洁，方法就是：在git push之前，先git fetch，再git rebase。

git fetch origin master
git rebase origin/master
git push

或者

git pull --rebase origin master

只要你把变基命令当作是在推送前清理提交使之整洁的工具，并且只在从未推送至共用仓库的提交上执行变基命令，就不会有事。 假如在那些已经被推送至共用仓库的提交上执行变基命令，并因此丢弃了一些别人的开发所基于的提交，那你就有大麻烦了，你的同事也会因此鄙视你。

如果你或你的同事在某些情形下决意要这么做，请一定要通知每个人执行 git pull –rebase 命令，这样尽管不能避免伤痛，但能有所缓解。

• 绝对不要在公共(远程分支)上rebase，也就是说，如果没有必要就不要在github merge的时候选择rebase，而是用上述的办法，在本地自己的分支推送前rebase
• 绝对不可以在公共分支上reset，也不要用–force
• 单独功能的多次提交要学会合并提交，保持提交的简洁。
• 提交message尽量能概括修改内容。