本文参考:
Git Reference
Git 分支模型
工欲善其事必先利其器,本文目的是列出常用的git命令,并简单回忆一下Git分支管理模型:
- 分支管理
- 查看
- 创建分支
- 提交
- 合并多个commit
- 选择合并某个commit
- 解决冲突
- 文本文件冲突
- zip文件冲突
- 版本回退
- 回退到某个commit
- 回退到某个操作
- 查看日志log
- 分支管理模型
- master 分支
- develop 分支
- feature 分支
- release 分支
- hotfix 分支
分支管理
查看分支
// 查看本地的分支
git branch
// 查看所有分支,本地和远程服务器
git branch -a
// 切换到develop分支
git checkout develop
本地分支创建
场景:新建一个功能/bugfix 分支
// 在当前分支创建并切换到feture_new
git checkout -b feture_new
拉取服务器的新分支到本地
场景:服务端多了一个新分支,想拉取下来合并,并解决冲突
git fetch origin develop
// git pull origin develop= git fetch origin develop+ git merge origin develop
git checkout -b develop origin/develop
提交
关于commit message格式规范的问题:git commit -m "[type] commit message"。如果是新功能,type=add;如果是bug修复type=bug,如果是合并分支type=merge...新功能提交,尽量描述增加了哪些新功能,罗列出来,bug也是如此。如此做法的一个好处是查看日志的时候知道每次的提交是什么,修改了哪里。
add-commit
git add .
git commit -m "[add] message"
合并分支时,将多个commit合并为一个
场景:新功能开发分支,按计划有很多个commit,完成开发后,合并到主分支,这时候不需要那么多commit,只需要一个即可。
git merge --squash other_branch
git commit -m "[your commit]"
选择合并某一个commit
场景:需要合并另一个分支上的某一个commit
// 查找要合并的commitId
git log
// 合并
git cherry-pick commitId
打tag
场景:发布版本后,release 分支合并到 develop 分支和 master分支,在master分支上打tag
// 2.0.0 是本次版本的版本号
git tag -a 2.0.0
解决冲突
在所冲突的文件中修改,解决冲突
在代码文件中解决冲突
git add .
git commit -m ""
使用本分支/合并的分支覆盖
如果是zip文件,显然是无法使用上面的方法解决冲突,这时候只能以某个分支上的更新覆盖
// 使用本分支的覆盖
git checkout --ours -- path/to/file
// 使用要合并的分支覆盖
git checkout --theirs -- path/to/file
版本回退
回滚到某个commit
使用场景:不小心提交了一个commit,然后想回退
// 先查看commit列表
git log
// 回滚到某个Log的commitId
git reset --hard commitId
回滚到某次操作
使用场景:不小心执行了很多操作,例如回退到某个commit,现在又反悔,想回退到那个commit。git的任何操作都可以反悔
// 查看操作日志
git log
// 回滚到某个操作
git reset --hard commitId
查看日志
log
git log [<options>] [<revision range>] [[\--] <path>…]
git reflog
分支管理模型
参考这篇文章:一个成功的 Git 分支模型,分支管理模型,主要围绕五个分支,理解它们的场景和生命周期,就基本理解整个模型。
master 分支
master 分支上的代码永远是可发行的,每发一个版本,须要将release分支合并到develop分支和master分支,然后在master分支上打一个tag。
develop 分支
整合分支,下一个版本中需要开发的功能,发出去的版本需要修复的bug,最后都需要合并到develop。所有功能开发完成,可以发版本了,从develop分支创建release分支。
feature 分支
特性分支,开发一个新功能时,从develop创建,开发完成后合并到develop分支,然后删除该feature分支。
release 分支
所有功能开发完成合并到develop分支后,可以发版本了,从develop分支创建release分支,release分支可以修改一些小bug,版本发布完成后,需要合并到develop分支和master分支,然后在master分支上打tag。
hotfix 分支
已发行的最新版本中出现了bug,这时需要从master分支上创建 hotfix 分支。修改完bug后,打上新的版本号,然后发布bugfix版本。完成后需要将hotfix 分支合并到develop 分支和master 分支,并在master分支上打tag
网友评论