Atom

思考、故事和创意

首页 链接 联系 关于

git

经常要搜一遍的 git 用法

不是什么高级技巧，也不是特别常用，不过常常忘掉。
git

全局的 gitignore 文件

执行这条命令，指定全局 gitignore 文件的路径

git config --global core.excludesfile '~/.gitignore'

在指定的路径（上面指定了 ~/.gitignore）里添加要忽略的内容。

删除远程仓库的分支

git config --global core.excludesfile '~/.gitignore'

优于

git push origin :<branchName>

使用 vimdiff 来进行 git diff

git config --global diff.tool vimdiff  # 设置 difftool 为 vimdiff
git config --global difftool.prompt false    # 在执行 git difftool 不询问是否打开某  diff 工具进行 diff（设置了默认 vimdiff）

执行 git difftool 就使用 vimdiff 进行 diff 了。

拉取远程分支

git fetch
# 然后，这样就可以！
git checkout <branchName>
# 如果 git 版本比较旧，上面的命令不生效，或者有多个远程仓库，用下面这个命令
git checkout -b <branchName> <remoteName>/<branchName>

持续添加……

利用 git 分支的开发流程

这篇 2010 年的文章 A successful Git branching model 讲了一个比较合适的使用 git 进行版本控制的流程。主要是有两个主要分支：master 和 develop 分支，和其他辅助分支：feature 分支、release 分支、hotfix 分支。

主要分支

每个 repo 包含两个永远都不删除的分支

  • master 生产环境的版本
  • develop 待发布的最新开发代码分支

develop 分支不会进行很大的功能、特性方面的开发。当 develop 分支稳定，准备发布了，把它（经过 release 辅助分支）合并到 master 分支，然后以版本号打一个标签。

辅助分支

辅助分支最终会被删除，一般是这几个分支类型：feature 分支、release 分支 和 hotfix 分支

feature 分支

  • 一般由 develop 分支创建
  • 必须合并回 develop 分支
  • 不要命名为 master, develop, release-*, hotfix-* 这样的分支名称

通常这类分支只在开发者本地仓库，不在远程代码仓库里。

流程示例

git checkout -b myfeature develop

git checkout develop
git merge --no-ff myfeature
git branch -d myfeature
git push origin develop

release 分支

  • 一般由 develop 分支创建
  • 必须合并回 develop 和 master 分支
  • 命名约定为 release-*

用在新的正式发布版本之前，进行一些很小的 bug 修改，版本号，构建日期的修改
等等。创建 release 分支之后，就暂时不要再把包含重大新特性的 feature 分支
往 develop 分支合并了。在创建 release 分支 时，就定下当前要发布的版本号
。

流程示例

git checkout -b release-1.2 develop
./bump-version.sh 1.2
git commit -a -m "Bumped version number to 1.2"

git checkout master
git merge --no-ff release-1.2
git tag -a 1.2

git checkout develop
git merge --no-ff release-1.2

git branch -d release-1.2

hotfix 分支

  • 一般从 master 分支创建
  • 必须合并回 develop 和 master 分支
  • 命名约定 hotfix-*

当线上版本出现需要立即修改的 bug 时，从 master 分支创建 Hotfix 分支。不影响其他分支的开发。

流程示例

git checkout -b hotfix-1.2.1 master
./bump-version.sh 1.2.1
git commit -a -m "Bumped version number to 1.2.1"

//fix bugs, then
git commit -m "Fixed severe production problem"

git checkout master
git merge --no-ff hotfix-1.2.1
git tag -a 1.2.1

git checkout develop
git merge --no-ff hotfix-1.2.1

如果当前有 release 分支，就要把 hotfix 分支先合并到 release 分支里，而不是develop 分支，release 分支最终还是会合并到 develop 分支里。

一点个人理解

  • master 分支不直接合并 develop 分支，更不直接合并 feature 分支。

  • feature 生存周期可长可短，由开发时长决定。多个 feature 可以同时开发，完成后合并到 develop 分支里，删除掉对应的feature分支

  • release 和 hotfix 分支的生存周期短，它们从比较稳定的 develop 和 master分支上创建出来，做小的改动后合并回 develop 和 master 分支，删除相应分支。可以说是“随用随删”的。

  • 在 release 分支里生成较大版本号，在 hotfix 分支里生成小版本号，在 master分支里按照版本号打上 tag 标签。

Tips

  • 合并分支时加上 --no-ff 参数，不要 fast-forward
  • 不要看国内的译名为“一个成功的 git 分支模型”的文章，翻译的像坨屎一样
  • 阮一峰写的Git分支管理策略 ，同样基于开头提到的文章，比较简洁清晰，比其他那些译文好一万倍。