直接以管窥天日常得到错误的结论,直接以文害辞平常获得错误的定论

1.7. 效仿用户C

那儿,A达成了feature a,然后提了P昂Cora,然后找旁人C
merge了。而后,B也实现了feature b,提了PR,须求review and merge。 C
review之后,approved, 然后D review, D merge。

那会儿,项目为主走上正式。feature一个1个丰富进去,重复此前的做事流程:
fetch -》 work -》 commit -》 push -》 PRAV4 -》 merged。
接下来,项目历史就成为了那样:

图片 1

一眼大致看起来幸亏,每一次都能收看提交历史,只要不是message写的越发少,大约能够通晓近日亲交配给的内容。但是,仔细一看,顺序好像不对。方今一共四个feature,但历史却远远超过2个。没关系,保证细粒度更便于反映开发进程。不过,这么些历史并不是比照feature的公布顺序,那么,当我想要找到feature
a的时候就很难串联起来。假若commit丰裕多,时间跨度丰裕大,甚至根本看不出来feature
a到底做了何等修改。

那儿想要使用图形化git 历史工具来提携领会历史:
图片 2

这里,辛亏,还勉强能来看走向。但当10个广大个人同时花费以来,线大概无法看了,时间跨度丰裕大的话,线也看不完。

就此,那种情势,正是大家同生共死眼下接纳的情势。差评。那还不算完,前面更大的劳碌来了。起头揭橥的feature
a出了难题,必须回滚。怎么实现。关于回滚,便是另一个话题了。
但大家应当精通使用revert而不是reset.
但revert只好回滚钦赐的commit,恐怕三番五次的commit,而且revert不可能revert
merge操作。那样,想回滚feature a,
大家即将找到a的一回提交的本子号,然后由于不是接连的,分别revert。那会招致复杂到不想处理了。幸而github给了造福的事物,PRAV4提供了revert的空子。找到从前的P中华V。

图片 3

但是,那纯属不是个好操作!


学习git工作流

参考来源

1.5. 仿照用户C

C review the PR and then merged it.

图片 4
那儿,github的野史如下:
图片 5
能够看来,merge的时候多了3次commit,message默许为 Merge pull request #1 from Ryan-Miao/a...
于今看起来,唯有a一位的历史记录,还算清楚,a做了二次提交。

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(+)

前言

一直在运用git做版本控制,也直接工作很顺遂,直到和别人产生争辨的时候。那才注意到git
工作流并不是那么简单。比如,在此之前境遇的清理历史。百度到的资料很多,重复性也很多,但实践性操作很少,笔者很难直接掌握其所表明的含义。直接一概而论常常获得错误的结论,只可以用时间去验证真理了,不然看到的结果都是似懂非懂,最终依旧一团糟。

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 git@github.com:Ryan-Miao/l4git-workflow.git
 * [new branch]      master -> C

图片 6

2. 推荐的工作流程

造成上述场景的来由是因为个别异步编制程序决定的。因为每一种人都得以随时间提交,最终合并起来的时候以提交时间戳来作为连串的依据,就会成为这样。由此,当要求交给的远程服务器的时候,借使能重写下commit的时刻为眼下时间,然后push到服务端,历史就会类别到终极了。

2.6 C 提PR

然后,create a Pull Request.
图片 7

2.2 模拟用户D

与此同时,D也供给开发新feature

$ git clone git@github.com: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.8 C发现提交次数过多,历史太乱,合并一些历史

那儿,发现3个标题,由于C在开发进度中付出了往往,而那五回提交的message其实没有多大趣味,只是因为C恐怕为了保留代码,也说不定是暂存。同理可得,C的前三遍提交的message的意义其实是一样的,都是创设C文件,都以贰个宗旨,那么为了掩护历史的绝望。最好把那3条音讯统十分之一一条C create file c.txt

参考git
合并历史
,大家要求将三次历史合并成呈现为二回。

查看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

备受关注,是要合并cf3f75713b7dde。那么找到前一个的版本号为7151f4c

git rebase - i 7151f4c

下一场进入互相界面,因为我们想要把第二次和第3次以及第③次提交新闻统一。将第③遍的类别修改为squash,
意思是和第①次联合。然后将第贰次的项目修改为squash,
同样是指合并的前3个commit。
图片 8
不相同git的彼此略有区别,在此以前在windows上的git
bash是全然依据vim的通令修改的。本次测试基于Ubuntu,发现存档命令为ctel + X。确认后进入下三个界面,合并3次提交后须求七个message

图片 9

剔除也许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 目录,作者猜忌您正处在此外2个变基操作
进度中。 假设是这么,请执行
git rebase (–continue | –abort | –skip)
即便不是那样,请执行
rm -fr “/home/ryan/temp/c/.git/rebase-merge”
接下来再重复履行变基操作。 为幸免丢失首要数据,笔者曾经停止当前操作。

这时,查看log, 鲜明,C的这1遍提交已经联合了。

$ 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

榜样

  1. 想保持树的清爽,方法正是:在git push此前,先git fetch,再git
    rebase。

git fetch origin master
git rebase origin/master
git push

或者

git pull --rebase origin master

若是你把变基命令当作是在推送前清理提交使之整洁的工具,并且只在没有推送至共用仓库的交付上推行变基命令,就不会有事。
假使在这一个已经被推送至共用仓库的付出上实施变基命令,并就此丢掉了一些人家的付出所依照的提交,那您就有大麻烦了,你的同事也会就此看不起你。

假定您或你的同事在一些景况下决定要那样做,请一定要通报各类人实行 git
pull –rebase 命令,那样即使无法幸免伤痛,但能享有缓解。

  1. 纯属不要在集体(远程分支)上rebase,也便是说,如若没有须求就绝不在github
    merge的时候选取rebase,而是用上述的法门,在地头本人的分段推送前rebase
  2. 相对不得以在国有分支上reset,也不用用–force
  3. 独立效能的屡屡提交要学会联合提交,保持提交的简短。
  4. 交付message尽量能归纳修改内容。

2.1 模拟用户C

C用户新下载代码。

$ git clone git@github.com: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

1. 最简易的施用,不推荐

1.2. 模拟用户A

git clone git@github.com: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 如下:

图片 10

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 git@github.com: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 git@github.com:Ryan-Miao/l4git-workflow.git
 * [new branch]      master -> master
分支 master 设置为跟踪来自 origin 的远程分支 master。

图片 11

2.2 模拟用户D

再者,D也急需开发新feature

$ git clone git@github.com: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.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 git@github.com:Ryan-Miao/l4git-workflow.git
   13b7dde..2c5ff94  master -> C

1. 最简便易行的选择,不引进

转载:http://www.cnblogs.com/woshimrf/p/git-workflow.html

参考来源

终极结出

在都没交给到server的时候,
历史是分散在依次开发者的当地,但commit时间有条理。
图片 12

按照rebase的用法,提交前rebase三次,就能够使得2个feature的交由串联到一同
图片 13

末尾在github的commit看起来也正是百发百中的多
图片 14

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 git@github.com:Ryan-Miao/l4git-workflow.git
 * [new branch]      master -> D

提P昂Cora, 那时候,即使运用merge:
图片 15

图片 16

结果一定发现,1)
d提交message被依据时间分散插入历史了(被插入到c的历史在此以前),
2)多了2回 Merge pull request #5 from Ryan-Miao/D..的提交音信。同初阶所述一样,历史先河变得非常不佳了。那么,那种难题如何是好吧?

目录

1.1.开立仓库
1.2.
效仿用户A

1.3.
仿照用户B

1.4.
模仿用户A

1.5.
模拟用户C

1.6.
仿照用户B

1.7.
效仿用户C

2.1
模拟用户C

2.2
模拟用户D

2.3
C继续支付

2.4
D继续支付

2.5 C
提交

2.6 C
提PR

2.7
C修改再push

2.8
C发现提交次数过多,历史太乱,合并一些历史

2.9
C再次push

2.10 新的merge方式:
rebase

2.11 那时候D也到位了
2.12 提交前rebase
最终结出

2. 推荐介绍的办事流程

致使上述现象的因由是因为个别异步编制程序决定的。因为各样人都得以随时间提交,最终合并起来的时候以提交时间戳来作为种类的依照,就会成为那样。由此,当必要交给的长距离服务器的时候,如若能重写下commit的时间为眼下光阴,然后push到服务端,历史就会类别到最后了。

1.5. 效仿用户C

C review the PR and then merged it.

图片 17
此刻,github的历史如下:
图片 18
可以见见,merge的时候多了二遍commit,message私下认可为 Merge pull request #1 from Ryan-Miao/a...
今日看起来,唯有a一人的历史记录,还算清楚,a做了一遍提交。

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 git@github.com:Ryan-Miao/l4git-workflow.git
 * [new branch]      a -> a

A created a Pull Request

图片 19
图片 20

2.10 新的merge方式: rebase

经过开头的一般性流程发现,每便merge的时候,都会多出一条新的交由新闻,那让历史看起来很想获得。那么,能够挑选rebase到master,变基,正是重复以master为主干,把当前的交给直接移动到master的末端。不会因为提交时间的离散导致数次commit的message被拆开。
选拔 rebase and merge
图片 21

图片 22

此时,能够看出C提交的五次新闻都以新型的,没有发出交叉。而且也尚未发出多余的merge信息。
图片 23

有人会问,那么岂不是看不到P逍客的地方了。点开C的野史。能够看到message下方是有P汉兰达的号码的:
图片 24

对了,刚开端的P瑞虎要记得close
图片 25

1.3. 效仿用户B

git clone git@github.com: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如下
图片 26

学习git工作流

最终结出

在都没交给到server的时候,
历史是散落在依次开发者的地方,但commit时间有程序。
图片 27

按照rebase的用法,提交前rebase三次,就足以使得1个feature的交给串联到一块
图片 28

末尾在github的commit看起来也正是顺风的多
图片 29

2.1 模拟用户C

C用户新下载代码。

$ git clone git@github.com: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.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(+)

1.2. 仿照用户A

git clone git@github.com: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 如下:

图片 30

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 git@github.com:Ryan-Miao/l4git-workflow.git
   13b7dde..2c5ff94  master -> C

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 git@github.com:Ryan-Miao/l4git-workflow.git
 * [new branch]      a -> a

A created a Pull Request

图片 31
图片 32

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.6 C 提PR

然后,create a Pull Request.
图片 33

1.6. 仿照用户B

用户B提交前先pull master,更新最新的代码到地头,幸免争持。

 git fetch
 git merge origin/master

那时log看起来有点乱。如下:
图片 34
令人感到混乱的是b原来的历史唯有和睦的提交,更新了master到当地之后,历史记录被插入了master中的历史。于是,发现原本本身到底的野史被中间插入多次commit。甚至四次merge
master的日志显得又长又碍眼。但不管怎么说,B依旧要付出的。

于是乎,B提交到长途分支b:
图片 35

2.9 C再次push

事先的push已经不能用了。须要开新支行推送过去。因为 rebase
只辛亏地头分支做。不要改动公共分支
 。

$ git push origin master:C
To git@github.com:Ryan-Miao/l4git-workflow.git
 ! [rejected]        master -> C (non-fast-forward)
error: 无法推送一些引用到 'git@github.com: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 git@github.com:Ryan-Miao/l4git-workflow.git
 * [new branch]      master -> C2

创办新的P凯雷德
图片 36

1.7. 模仿用户C

那会儿,A完结了feature a,然后提了P奥迪Q7,然后找别人C
merge了。而后,B也完结了feature b,提了P奥德赛,必要review and merge。 C
review之后,approved, 然后D review, D merge。

那时候,项目基本走上正式。feature一个二个增进进去,重复在此以前的干活流程:
fetch -》 work -》 commit -》 push -》 PRubicon -》 merged。
下一场,项目历史就改为了那般:

图片 37

一眼大约看起来万幸,每一次都能见到提交历史,只要不是message写的特别少,大约能够知道近来亲交配给的内容。不过,仔细一看,顺序好像不对。方今累计五个feature,但历史却远远超过三个。没关系,保证细粒度更便于反映开发进程。但是,那么些历史并不是遵照feature的揭发顺序,那么,当本人想要找到feature
a的时候就很难串联起来。如若commit丰盛多,时间跨度丰盛大,甚至一向看不出来feature
a到底做了如何修改。

那儿想要使用图形化git 历史工具来扶助精晓历史:
图片 38

此地,幸好,还勉强能来看走向。但当11个广大个人同时开发来说,线几乎不可能看了,时间跨度丰裕大的话,线也看不完。

于是,那种情势,正是大家团结日前应用的形式。差评。那还不算完,前边更大的诸多不便来了。最首发表的feature
a出了难点,必须回滚。怎么形成。关于回滚,就是另三个话题了。
但大家理应知道使用revert而不是reset.
但revert只能回滚钦点的commit,恐怕一而再的commit,而且revert无法revert
merge操作。那样,想回滚feature a,
大家即将找到a的一遍提交的本子号,然后由于不是接连的,分别revert。那会导致复杂到不想处理了。还好github给了方便人民群众的东西,PXC90提供了revert的空子。找到此前的P奥迪Q3。

图片 39

然则,那纯属不是个好操作!


1.3. 仿照用户B

git clone git@github.com: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如下
图片 40

转载:http://www.cnblogs.com/woshimrf/p/git-workflow.html

1.6. 效仿用户B

用户B提交前先pull master,更新最新的代码到地面,幸免争执。

 git fetch
 git merge origin/master

这儿log看起来有个别乱。如下:
图片 41
令人深感混乱的是b原来的历史唯有和谐的交给,更新了master到地点之后,历史记录被插入了master中的历史。于是,发现原来本身根本的野史被中间插入数十次commit。甚至一次merge
master的日志显得又长又碍眼。但不管怎么说,B照旧要提交的。

于是,B提交到长途分支b:
图片 42

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 git@github.com: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 git@github.com:Ryan-Miao/l4git-workflow.git
 * [new branch]      master -> master
分支 master 设置为跟踪来自 origin 的远程分支 master。

图片 43

前言

一贯在行使git做版本控制,也一直工作很顺遂,直到和人家爆发冲突的时候。那才注意到git
工作流并不是那么粗略。比如,在此之前碰到的清理历史。百度到的素材很多,重复性也很多,但实践性操作很少,笔者很难直接领悟其所发挥的意思。直接一概而论常常获得错误的下结论,只可以用时间去检查与审视真理了,不然看到的结果都以似懂非懂,最终照旧一团糟。

2.9 C再次push

事先的push已经无法用了。须求开新支行推送过去。因为 rebase
只还好地点分支做。不要涂改公共分支
 。

$ git push origin master:C
To git@github.com:Ryan-Miao/l4git-workflow.git
 ! [rejected]        master -> C (non-fast-forward)
error: 无法推送一些引用到 'git@github.com: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 git@github.com:Ryan-Miao/l4git-workflow.git
 * [new branch]      master -> C2

开立异的P汉兰达
图片 44

图片 45

2.12 提交前rebase

就好像C
rebase后merge到master一样。大家同样能够在地头做到这样的工作。在本地rebase,让大家这次feature的交付全部插到master节点过后,有序,而且简单revert。
此次,以新的E和F交叉commit为例子,最后将收获各自分离的野史

E:

$ git clone git@github.com: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 git@github.com: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 git@github.com: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 git@github.com:Ryan-Miao/l4git-workflow.git
 * [new branch]      master -> F

P卡宴, rebase and merge。 那时候看history:

图片 46

依照前四次的做法,E和F交叉在地方提交,每一趟commit的时日戳也是陆续,最终合并到master的时候,历史并没有被拆除。而是像大家盼望的同样,顺序下来。那才是大家想要的。通过看图形化界面也能来看区别:

乌紫的线是master
图片 47

那么,操作正是fetch-》rebase。事实上,能够二合一为:

git pull --rebase origin master

图片 48

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 git@github.com:Ryan-Miao/l4git-workflow.git
 * [new branch]      master -> D

提PRAV4, 那时候,要是利用merge:
图片 49

图片 50

结果肯定发现,1)
d提交message被依据时间分散插入历史了(被插入到c的历史以前),
2)多了叁回 Merge pull request #5 from Ryan-Miao/D..的交由音讯。同开端所述一样,历史起首变得一无可取了。那么,那种题材如何做吧?

目录

1.1.开立仓库
1.2.
模拟用户A

1.3.
模仿用户B

1.4.
模拟用户A

1.5.
仿照用户C

1.6.
效仿用户B

1.7.
仿照用户C

2.1
模拟用户C

2.2
模拟用户D

2.3
C继续支付

2.4
D继续支付

2.5 C
提交

2.6 C
提PR

2.7
C修改再push

2.8
C发现提交次数过多,历史太乱,合并一些历史

2.9
C再次push

2.10 新的merge方式:
rebase

2.11 那时候D也完了了
2.12 提交前rebase
最后结出

2.3 C继续支付

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

旗帜

  1. 想维持树的清洁,方法正是:在git push从前,先git fetch,再git
    rebase。

git fetch origin master
git rebase origin/master
git push

或者

git pull --rebase origin master

一经你把变基命令当作是在推送前清理提交使之整洁的工具,并且只在没有推送至共用仓库的交付上实施变基命令,就不会有事。
尽管在那么些已经被推送至共用仓库的付出上推行变基命令,并就此丢掉了一些人家的付出所根据的提交,那您就有大麻烦了,你的同事也会为此看不起你。

比方你或你的同事在某个景况下决定要如此做,请一定要公告各类人实践 git
pull –rebase 命令,那样即便不能够防止伤痛,但能享有缓解。

  1. 纯属不用在公私(远程分支)上rebase,也正是说,假如没有要求就无须在github
    merge的时候选用rebase,而是用上述的艺术,在该地自身的分支推送前rebase
  2. 纯属不得以在公私分支上reset,也并非用–force
  3. 单身功用的再三交由要学会联合提交,保持提交的简要。
  4. 付给message尽量能总结修改内容。

2.8 C发现提交次数过多,历史太乱,合并一些历史

此刻,发现三个标题,由于C在付出进程中付出了往往,而这一遍提交的message其实没有多大趣味,只是因为C或者为了保留代码,也或然是暂存。总而言之,C的前一次提交的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

眼看,是要统一cf3f75713b7dde。那么找到前一个的版本号为7151f4c

git rebase - i 7151f4c

接下来进入相互界面,因为我们想要把第②回和第贰回以及第③次提交音信统一。将首次的项目修改为squash,
意思是和第二次联合。然后将第③次的类型修改为squash,
同样是指合并的前1个commit。
图片 51
不等git的相互略有分歧,以前在windows上的git
bash是全然依照vim的命令修改的。本次测试基于Ubuntu,发现存档命令为ctel + X。确认后跻身下1个界面,合并2遍提交后须要一个message

图片 52

删去大概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 目录,作者猜忌您正处在此外2个变基操作
经过中。 固然是如此,请执行
git rebase (–continue | –abort | –skip)
倘诺不是这么,请执行
rm -fr “/home/ryan/temp/c/.git/rebase-merge”
然后再另行履行变基操作。 为幸免丢失首要数据,笔者已经终止当前操作。

那儿,查看log, 显著,C的那1遍提交已经联合了。

$ 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.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 git@github.com:Ryan-Miao/l4git-workflow.git
 * [new branch]      master -> C

2.12 提交前rebase

就像C
rebase后merge到master一样。大家一致能够在地面做到那样的事体。在地头rebase,让大家这次feature的付出全部插到master节点过后,有序,而且便于revert。
本次,以新的E和F交叉commit为例子,最后将获得各自分离的野史

E:

$ git clone git@github.com: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 git@github.com: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 git@github.com: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 git@github.com:Ryan-Miao/l4git-workflow.git
 * [new branch]      master -> F

PSportage, rebase and merge。 那时候看history:

图片 53

服从前四次的做法,E和F交叉在本土提交,每趟commit的时间戳也是交叉,最后合并到master的时候,历史并不曾被拆毁。而是像大家期望的平等,顺序下来。这才是大家想要的。通过看图形化界面也能看出分歧:

黑古铜色的线是master
图片 54

那就是说,操作正是fetch-》rebase。事实上,能够二合一为:

git pull --rebase origin master

图片 55

2.10 新的merge方式: rebase

经过伊始的一般性流程发现,每回merge的时候,都会多出一条新的交付消息,那让历史看起来很想获得。那么,能够挑选rebase到master,变基,正是重复以master为中央,把当前的交由直接移动到master的末尾。不会因为提交时间的离散导致数次commit的message被拆除与搬迁。
选用 rebase and merge
图片 56

图片 57

此时,能够见到C提交的一遍新闻都是流行的,没有发出交叉。而且也未曾生出多余的merge音信。
图片 58

有人会问,那么岂不是看不到PHighlander的地方了。点开C的历史。可以见见message下方是有P汉兰达的编号的:
图片 59

对了,刚开端的P冠道要记得close
图片 60

相关文章