目录
下面的例子将演示Gitflow流程如何被用来管理一次产品发布。
Git使用方法
Gitflow工作流程 - Jeffery-Zou - 博客园
一. Git的工作空间和文件状态
一个很简单的操作步骤:
git init //初始化仓库
git add . //添加文件到暂存区
git commit //将暂存区内容添加到本地仓库中
二. Git基本操作
1. 设置账户并查看(需要和github账户设置一致)
git config --global user.name "xxx"
git config --global user.email "xxx@xxx.com"
git config --list
2. 创建git本地仓库
git init
3. 查看git状态
git status
一般来说会显示需要提交的文件(uncommited)和未追踪的文件(untracked)
- uncommited:已有的,刚被修改尚未提交的
- untracked:原先没有的,新建的
4. 添加git文件到暂存区
git add xxx
5. git提交文件
git commit -m "xxx"
6. git删除本地仓库文件(夹)
# 删除文件
git rm xxx
# 删除文件夹
git rm -r xxx
可以用下面两种操作在版本库中删除文件:
# (1)
git rm test.txt
git commit -m 'delete a file'
# (2)"-a"的作用是:可以把还没有执行add命令的修改一起提交。
rm test.txt
git commit -a -m 'delete a file'
7. git 还原、撤销、版本回退操作
(1)git checkout --
该命令用于拉取暂存区文件,并将其替换成工作区文件。简单的说,就是当我们把工作区弄乱了,可以帮我们拉取 暂存区 来恢复 工作区。
# 丢弃工作区的操作,但不会丢失暂存区的操作(add操作能将更改添加到暂存区)
git checkout -- xxx
(2)git commit --amend
可以修改上一次 commit -m 提交的信息,相当于把上一次提交的信息给覆盖了。
(3)git reset
git reset命令既可以回退版本,也可以把暂存区的修改回退到工作区。
# 回退到上一个版本
git reset --hard HEAD^
# 回退到上上个版本
git reset --hard HEAD^^
# 工作区修改了文件,而且执行了add,但还没执行commit,暂存区是可以撤销的
git reset HEAD xxx
8. git remote 操作
# 列出所有远程主机
git remote
# 使用-v选项,可以参看远程主机的网址
git remote -v
# 可以查看该主机的详细信息
git remote show <主机名>
# 添加远程主机
git remote add <主机名> <网址>
# 删除远程主机
git remote rm <主机名>
# 修改远程主机名称
git remote rename <原主机名> <新主机名>
(1)为 gitee 添加远程仓库:
git remote add origin git@gitee.com:xxx/xxx.git //ssh方式
如果报错:fatal: remote origin already exists. 则说明本地库已经关联了一个名叫origin的远程库,此时可以先用git remote -v 查看远程库信息:
origin git@github.com: xxx/xxx.git (fetch)
origin git@github.com: xxx/xxx.git (push)
表示本地库已经关联了github上的origin远程库,需要先删除已有的github库。
git remote rm origin
再关联 gitee 的远程库:
git remote add gitee git@gitee.com:xxx/xxx.git //ssh方式
(2)使用多个远程库:
Git 给远程库起的默认名称是origin,如果有多个远程库,需要用不同的名称来标识不同的远程库。
# 先删除已关联的名为origin的远程库
git remote rm origin
# 然后,先关联Github的远程库,注意这里远程库的名称叫github不叫origin了
git remote add github git@github.com:xxx/xxx.git
#接着关联gitee远程库
git remote add gitee git@gitee.com:xxx/xxx.git
#查看远程库信息
git remote -v
#推送
git push github master //推送至GitHub
git push gitee master //推送至Gitee
(3)将远程仓库的分支克隆为本地仓库
git clone
默认情况下,从远程clone到本地的库只能看到master分支,如果要将远程的分支同步到本地,则:
git checkout -b <本地分支名> <远程主机名>/<远程分支名>
9. git pull 操作
git fetch 和 git pull 的区别如下。
(1)git fetch:
相当于是从远程获取最新版本到本地,不会自动合并。
# 首先从远程获取最新版本到本地,不会自动合并。
git fetch origin master
# 然后比较本地的master分支和origin/master分支的区别。
git log -p master..origin/master
#最后合并。
git merge origin/master
(2)git pull:
git pull <远程主机名> <远程分支名>:<本地分支名>
从远程获取最新版本并 merge 到本地。相当于git fetch和git merge。
# 拉取origin主机的master分支,与本地的new分支合并
git pull origin master:new
# 如果远程master分支是与当前分支合并,则冒号后可以省略
git pull origin master
# 合并需要采用 rebase 模式
git pull --rebase <远程主机名> <远程分支名>:<本地分支名>
10. git push操作
推送本地分支到远程仓库。
git push <远程主机名> <本地分支名>:<远程分支名>
如果省略远程分支名,则表示将本地分支推送与之存在“追踪关系”的远程分支,如果该远程分支不存在,则会被创建。eg:
git push origin master
如果当前分支与多个主机存在追踪关系,则可以使用-u选项指定一个默认主机,这样以后就可以不加任何参数使用 git push。
git push -u origin master
11. git branch操作
# (1)查看本地分支
git branch
# (2)查看远程分支
git branch -r
# (3)创建本地分支(注意新分支创建后不会自动切换为当前分支)
git branch [name]
# (4)切换分支
git checkout [name]
# (5)创建新分支并立即切换到新分支,相当于(3)(4)一起
git checkout -b [name]
# (6)强制删除一个分支
git branch -D [name]
# (7)合并分支(将名称为[name]的分支与当前分支合并)
git merge [name]
12. 忽略特殊文件
在Git工作区的根目录下,用记事本创建一个 .gitignore 文件,然后把要忽略的文件名填进去,Git会自动忽略这些文件。如下所示:
如果怀疑 .gitignore 写的有问题,需要查找哪个规则写错了,可以用git checkout-ignore命令,如下所示:
git checkout-ignore -v app.cpp
出现 .gitignore:3:*.cpp app.cpp
表示 .gitignore 的第三行规则忽略了app.cpp这个文件。
13. 为命令配置别名
# git st表示git status
git config --gloal alias.st status
# git co表示git checkout
git config --gloal alias.co checkout
# git br表示git branch
git config --gloal alias.br branch
# git ci表示git commit
git config --gloal alias.ci commit
14. git tag操作
# 创建tag
git tag -a <tagname> -m "there is a tag description" master
# 对指定的commit版本创建tag
git tag -a <tagname> -m "there is a tag description" [<commitid>]
# 查看tag,显示顺序是按字母顺序排列的
git tag
# 删除tag
(1)本地删除
git tag -d <tagname>
(2)如果标签已推送到远程,先删本地,再删远程
git tag -d <tagname>
git push origin:refs/tags/<tagname>
# 推送标签至远程
git push origin <tagname>
# 或者一次性推送全部未推送到远程的本地标签
git push origin --tags
三. Gitflow 工作流程
在Gitflow流程中,master只用于保存官方发布历史,而develop分支才是用于集成各种功能开发的分支。也即,在创建新的功能开发分支时,父分支应该选择develop,功能开发永远不要直接牵扯到master。
Release分支:
基于develop分支建立的,用于产品发布的分支。
这个分支的创建意味着一个发布周期的开始,也意味着本次发布不会再增加新的功能——在这个分支上只能修复bug,做一些文档工作或者跟发布相关的任务。
在一切准备就绪的时候,release分支会被合并入master,并且用版本号打上标签。另外,发布分支上的改动还应该合并入develop分支。(在发布周期内,develop分支仍然在被使用,一些开发者会把其他功能集成到develop分支。)
Hotfix分支:
唯一一个可以直接基于master创建的分支。
用于发布后的维护工作或紧急问题修复。
所做改动应该被合并入master和develop分支(或者用于当前发布的分支),之后master上还要使用更新的版本号打好标签。
下面的例子将演示Gitflow流程如何被用来管理一次产品发布。
假设你已经创建好了一个中央仓库。
1. 创建develop分支
第一步是给默认的master配备一个develop分支。
一种简单的做法是:让一个开发者在本地建立一个空的develop分支,然后把它推送到服务器。
git branch develop
git push -u origin develop
develop分支将包含项目的所有历史,而master会是一个缩减版本。现在,其他开发者可以clone中央仓库,并且为develop创建一个追踪分支。
git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop
至此,所有人都把包含有完整历史的分支(develop)在本地配置好了。
2. 小马和小明开始分别开发新功能
我们的故事从小马和小明要分别开发新功能开始。
他们俩各自建立了自己的分支。注意,他们在创建分支时,父分支不能选择master,而要选择develop。
# 本地创建feature分支,并关联到远程的develop
git checkout -b feature origin/develop
他们俩都在自己的功能开发分支上开展工作。
通常就是这种Git三部曲:
git status
git add <some-file>
git commit
3. 小马把她的功能开发好了
在提交过几次代码之后,小马觉得她的功能做完了。
如果她所在的团队使用“拉拽请求”,此刻便是一个合适的时机——她可以提出一个将她所完成的功能合并入develop分支的请求。
或者,她可以自行将她的代码合并入本地的develop分支,然后再推送到中央仓库,像这样:
# 先拉取远程最新的代码
git pull origin develop
# 切换到develop
git checkout develop
# 合并
git merge feature
# 推送
git push
# 删除feature分支
git branch -d feature
第一条命令确保了本地的develop分支拥有最新的代码——这一步必须在将功能代码合并之前做。
4. 小马开始准备一次发布
尽管小明还在忙着开发他的功能,小马却可以开始准备这个项目的第一次正式发布了。类似于功能开发,她使用了一个新的分支来做产品发布的准备工作。在这一步,发布的版本号也最初确定下来。
git checkout -b release-0.1 origin/develop
一旦小马创建了这个分支并把它推向中央仓库,这次产品发布包含的功能也就固定下来了。任何还处于开发状态的功能只能等待下一个发布周期。
5. 小马完成了发布
一切准备就绪之后,小马就要把发布分支合并入master和develop分支,然后再将发布分支删除。注意,往develop分支的合并是很重要的,因为开发人员可能在发布分支上修复了一些关键的问题,而这些修复对于正在开发中的新功能是有益的。
# 合并到master
git checkout master
git merge release-0.1
git push
# 合并到develop
git checkout develop
git merge release-0.1
git push
#删除release分支
git branch -d release-0.1
发布分支扮演的角色是功能开发(develop)与官方发布(master)之间的一个缓冲。无论什么时候你把一些东西合并入master,你都应该随即打上合适的标签。
# 创建tag
git tag -a <tagname> -m "Initial public release" master
git push --tags
6. 用户发现了一个bug
当一次发布完成之后,小马便去与小明一起开发其他功能了。突然,某个用户提出当前发布的产品里有bug。为解决这个bug,小马基于master创建了一个用于维护的分支Hotfix,并在这个分支上修复了那个bug,然后把改动的代码直接合并入master。
git checkout -b issue-#001 master
\# Fix the bug
git checkout master
git merge issue-#001
git push
跟用于发布的分支一样,在维护分支上的改动也需要合并入develop分支,这一点是很重要的!因此,小马务必不能忘了这一步。随后,她就可以将维护分支删除。
git checkout develop
git merge issue-#001
git push
git branch -d issue-#001