git版本控制管理

git

Git是目前世界上最先进的分布式版本控制系统,没有之一。

git的安装

ubuntu

sudo apt-get install git

MAC_OS_X

一般自带git管理,安装有两种方式:

  • 1.安装homebrew包管理器,终端输入

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

然后通过homebrew安装Git,终端输入

brew install git

使用 Homebrew 方式安装,Git 被安装在 /usr/local/Cellar/git/<version>/ 中,可执行程序自动在 /usr/local/bin 目录下创建符号连接,可以直接在终端程序中访问。

  • 2.从AppStore安装Xcode,Xcode集成了Git,不过默认没有安装,你需要运行Xcode,选择菜单“Xcode”->“Preferences”,在弹出窗口中找到“Downloads”,选择“Command Line Tools”,点“Install”就可以完成安装了。

windows

从Git官网直接下载安装程序git,一路next默认选项安装即可。开始菜单或者右键菜单里找到“Git”->“Git Bash”即代表安装完成。

全局设置

安装完成后,还需要最后一步,设置提交代码时的用户信息,

git config -l

查看当前本机git的配置清单,在命令行输入:

git config --global user.name "Your Name"
git config --global user.email "email@example.com"

注意git config命令的--global参数,用了这个参数,表示你这台机器上所有的Git仓库都会使用这个配置,当然也可以对某个仓库指定不同的用户名和Email地址。

Git的基本命令

Git

Git的工作流程

git是分布式版本控制系统,每一台客户端都是一个独立的git仓库(有git工作的全套机制)

Git

1、工作区workspace:平时写代码的地方

2、暂存区index:把一些写好的代码暂时存储的地方

3、历史区Repository:生成一个个版本记录的地方(本地版本库)

常用的git命令:

git add (工作区=>暂存区)

git commit (暂存区=>版本库)

git push (版本库=>远程仓库)

文件的版本库管理

首先这里再明确一下,所有的版本控制系统,其实只能跟踪文本文件的改动,比如TXT文件,网页,所有的程序代码等等,Git也不例外。版本控制系统可以告诉你每次的改动,比如在第5行加了一个单词“Linux”,在第8行删了一个单词“Windows”。而图片、视频这些二进制文件,虽然也能由版本控制系统管理,但没法跟踪文件的变化,只能把二进制文件每次改动串起来,也就是只知道图片从100KB改成了120KB,但到底改了啥,版本控制系统不知道,也没法知道。另外,Microsoft的Word格式是二进制格式,因此,版本控制系统是没法跟踪Word文件的改动的。

创建版本库

通过git init命令把当前目录变成Git可以管理的仓库,即创建了一个本地git仓库,当前目录下多了一个.git的目录,这个目录是Git来跟踪管理版本库的,没事千万不要手动修改.git这个目录里面的文件,不然改乱了,就把Git仓库给破坏了。

如果你没有看到.git目录,那是因为这个目录默认是隐藏的,macos用ls -ah命令,ubuntu可以按快捷键ctrl+h,windows设置文件夹显示隐藏就可以看见。

添加文件到本地Git仓库分两步

1.把工作区的内容提交到暂存区

使用命令git add <file>,注意,可反复多次使用,添加多个文件;

git add . 把所有修改的文件(修改和新增的包含,删除的不包含)

git add -u 把所有修改的文件(包含修改和删除的,但是不包含新增的)

git add -A 是 . 和 U 的结合体,所有修改、新增、删除的信息都会提交到暂存区 (但是真实效果中两者效果差不多,用哪个都可以)

查看文件状态

git status 查看当前文件的状态,要随时掌握工作区的状态,使用此命令。

git diff 可以查看修改内容。

2.把暂存区内容提交到历史区

使用命令git commit -m <message>完成。

文件的撤销修改及删除

撤销修改

1.修改还未使用git add添加到暂存区时,手动修改或者git checkout -- file丢弃工作区的修改。注意:git checkout -- file命令中的--很重要,没有--,就变成了“切换到另一个分支”的命令。

2.修改并且git add到暂存区,还未commit时,用命令git reset HEAD <file>可以把暂存区的修改撤销掉(unstage),重新放回工作区

删除文件

当你要删除文件的时候,比如终端可以用命令: rm test.txt

这个时候(也就是说这个时候只执行了rm test.txt)有两种情况

第一种情况:的确要把test.txt删掉,那么可以执行

git rm test.txt
git commit -m "remove test.txt"

然后文件就被删掉了

第二种情况:删错文件了,不应该删test.txt,注意这时只执行了rm test.txt,还没有git commit提交到版本库,所以可以执行git checkout test.txt将文件恢复。如果提交到版本库了,那么就需要git reset --hard 版本号来回退

版本回退

当你不断对文件进行修改,然后不断提交修改到版本库,就好比玩RPG游戏时,每通过一关就会自动把游戏状态存盘,如果某一关没过去,你还可以选择读取前一关的状态。有些时候,在打Boss之前,你会手动存盘,以便万一打Boss失败了,可以从最近的地方重新开始。Git也是一样,每当你觉得文件修改到一定程度的时候,就可以“保存一个快照”,这个快照在Git中被称为commit。一旦你把文件改乱了,或者误删了文件,还可以从最近的一个commit恢复,然后继续工作,而不是把几个月的工作成果全部丢失。

git log命令显示从最近到最远的 commit 提交日志,每提交一个新版本,实际上Git就会把它们自动串成一条时间线,每个提交都有一个特有的SHA1计算出来的十六进制commit id

如何回退

首先,Git必须知道当前版本是哪个版本,在Git中, HEAD 表示当前版本,要把当前版本回退到其他版本,就可以使用git reset命令:

git reset --hard commit_id

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

在Git中,总是有后悔药可以吃的。当你用 git reset --hard 回退到以前的版本时,再想恢复到操作前的版本,就必须找到操作前的commit id。Git提供了一个命令git reflog用来记录你的每一次命令

以上操作为没有远程库的情况下,真实开发中如果存在远程库,当你本地库进行回退操作后,可能会导致本地库与远程库版本不一致而提交失败的情况,例如:

On branch master
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)

这种情况是为什么呢?假设一开始你的本地和远程都是:

a -> b -> c

你想把HEAD回退到b,那么在本地就变成了:

a -> b

这个时候,如果没有远程库,你就接着怎么操作都行,比如:

a -> b -> d

但是在有远程库的情况下,你push会失败,因为远程库是 a->b->c,你的是 a->b->d

两种方案:

push的时候用--force,强制把远程库变成a -> b -> d,大部分公司严禁这么干,会被别人揍一顿

做一个反向操作,把自己本地变成a -> b -> c -> d,注意b和d文件快照内容一莫一样,但是commit id肯定不同,再push上去远程也会变成 a -> b -> c -> d

简单地说就是你无法容易地抹去远程库的提交信息,所以本地提交怎么都行,push前想好了,

另外还有一种解决方案是,如果本地版本回滚了,然后想让远端的版本也回滚,git reset之后再git push就一直报错让先git pull,pull下来之后HEAD又指回了原来的位置,这样就陷入了一个死循环,永远都没办法把本地reset之后的东西push到远端了,解决办法是使用 git revert <commit_id>操作实现以退为进, git revert 不同于 git reset 它不会擦除”回退”之后的 commit_id ,而是正常的当做一次”commit”,产生一次新的操作记录,所以可以push,不会让你再pull

远程仓库

创建远程仓库

第1步

创建SSH Key

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

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

你需要把邮件地址换成你自己的邮件地址,然后一路回车,使用默认值即可。

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

第2步

关联SSH Key

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

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

本地库添加远程库关联

使用命令:

git remote add origin git@git**.com:*************.git

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

下一步,就可以把本地库的所有内容推送到远程库上:git push -u origin master

由于远程库是空的,我们第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来,此后,每次本地提交后,只要有必要,就可以使用命令git push origin master推送最新修改;

从远程库克隆

到所在目录后git clone git@git**.com:**********.git

Git支持多种协议,默认的git://使用ssh,但也可以使用https等其他协议。

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

分支管理

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

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

创建合并分支

查看分支:git branch

创建分支:git branch <name>

切换分支:git checkout <name>

创建+切换分支:git checkout -b <name>

合并某分支到当前分支:git merge <name>

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

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

删除分支:git branch -d <name>

分支强行删除,需要使用大写的-D参数: git branch -D <name>

解决分支冲突

——o—————o—————————o— master(HEAD)
         \
           ·——————o— feature

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

git status也可以告诉我们冲突的文件,cat <fileName>直接查看冲突文件的内容,

Git用<<<<<<<=======>>>>>>>标记出不同分支的内容,修改后保存再提交:


——o—————o—————————o——————————o— master(HEAD)
         \                  /
           ·——————o———————·    feature

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

分支管理策略

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

一、主分支Master

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

Git

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

二、开发分支Develop

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

Git

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

Git创建Develop分支的命令:

git checkout -b develop master

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

# 切换到Master分支
git checkout master

# 对Develop分支进行合并
git merge --no-ff develop

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

Git

使用–no-ff参数后,会执行正常合并,在Master分支上生成一个新节点。为了保证版本演进的清晰,我们希望采用这种做法 Git

三、临时性分支

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

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

* 功能(feature)分支

* 预发布(release)分支

* 修补bug(fixbug)分支

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

功能分支

功能分支,是为了开发某种特定功能,从Develop分支上面分出来的。开发完成后,要再并入Develop。 Git 功能分支的名字,可以采用feature-*的形式命名。

创建一个功能分支:

git checkout -b feature-x develop

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

git checkout develop

git merge --no-ff feature-x

删除feature分支:

git branch -d feature-x

预发布分支

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

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

创建一个预发布分支:

git checkout -b release-1.2 develop

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

git checkout master

git merge --no-ff release-1.2

# 对合并生成的新节点,做一个标签
git tag -a 1.2

再合并到develop分支:

git checkout develop

git merge --no-ff release-1.2

最后,删除预发布分支:

git branch -d release-1.2

修补bug分支

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

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

Git

创建一个修补bug分支:

git checkout -b fixbug-0.1 master

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

git checkout master

git merge --no-ff fixbug-0.1

git tag -a 0.1.1

再合并到develop分支:

git checkout develop

git merge --no-ff fixbug-0.1

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

git branch -d fixbug-0.1

多人协作

git remote

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

为了便于管理,Git要求每个远程主机都必须指定一个主机名。要查看远程库的信息,用git remote或者,用git remote -v显示更详细的信息.

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

git clone -o jQuery https://github.com/jquery/jquery.git
git remote

jQuery(克隆的时候,指定远程主机叫做jQuery)

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 push

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

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

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

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

git push origin master

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

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

git push origin :master
# 等同于
git push origin --delete master

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

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

git push origin

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

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

git push

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

git push -u origin master

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

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

git config --global push.default matching
# 或者
git config --global push.default simple

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

git push --all origin

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

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

git push --force origin 

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

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

git push origin --tags

抓取分支

git pull

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

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

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

git pull origin next:master

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

git pull origin next

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

git fetch origin
git merge origin/next

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

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

git branch --set-upstream master origin/next

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

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

git pull origin

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

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

git pull

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

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

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

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

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

git pull -p
# 等同于下面的命令
git fetch --prune origin 
git fetch -p

git fetch

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

git fetch <远程主机名>

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

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

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

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

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

git fetch origin master

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

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

git branch -r
origin/master

git branch -a
* master
  remotes/origin/master

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

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

git checkout -b newBrach origin/master

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

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

git merge origin/master
# 或者
git rebase origin/master

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

多人协作的工作模式通常是这样:

首先,可以试图用git push origin <branch-name>推送自己的修改;

如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并;

如果合并有冲突,则解决冲突,并在本地提交;

没有冲突或者解决掉冲突后,再用git push origin <branch-name>推送就能成功!

如果git pull提示no tracking information,则说明本地分支和远程分支的链接关系没有创建,用命令 git branch --set-upstream-to <branch-name> origin/<branch-name> 建立链接关系

标签管理

创建标签

在Git中打标签非常简单,首先,切换到需要打标签的分支上:git branch git checkout <brancheName>

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

默认标签是打在最新提交的commit上的,git tag <name> commit_id指定历史提交的 commit id

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

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

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

操作标签

如果标签打错了,也可以删除:git tag -d <tagName>(本地库标签)

从远程库删除标签,删除命令是push,但是格式如下:git push origin :refs/tags/<tagName>

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

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

或者,一次性推送全部尚未推送到远程的本地标签:git push origin --tags

Git的三种工作流程

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

协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去。

常见的工作流程有三种:

# Git flow
# Github flow
# Gitlab flow

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

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

Git flow

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

它最主要的特点有两个。

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

主分支master
开发分支develop

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

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

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

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

详情参考上文 => Git分支管理

Github flow

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

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

官方推荐的流程如下。

Git

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

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

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

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

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

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

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

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

Gitlab flow

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

上游优先

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

持续发布

Gitlab flow 分成两种情况,适应不同的开发流程。 Git 对于”持续发布”的项目,它建议在master分支以外,再建立不同的环境分支。比如,”开发环境”的分支是master,”预发环境”的分支是pre-production,”生产环境”的分支是production。

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

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

版本发布

Git

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

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

Done! By suki,引用请注明出处作者。
License CC BY-NC-SA 3.0.

0%