Git 常用命令与分支管理模型总结

本文参考:
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 [] [] [[\--] …​]
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

你可能感兴趣的:(Git 常用命令与分支管理模型总结)