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 [<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