Jin-Git常用命令及工作流梳理

虽然使用github也有一段时间了，可是对于git的代码管理策略还是模糊不清，所以特地的花了几个小时来使用git，熟悉和理解git。

1. Git 常用命令

首先一般会初始化一下仓库的提交者信息， --global 表示初始化所有的仓库提交者。不过一般我都是不带--global参数。因为开发的时候会有公司项目和自己的项目，这两种场景下的提交者并不一样：

git config --global user.name "Yi-love"
git config --global user.email "438002896@qq.com"

git config  user.name "Yi-love"
git config  user.email "438002896@qq.com"

1.1 新建分支

  $ git branch 新分支名	
  #新建分支 develop
  $ git branch develop

1.2 分支切换

  $ git checkout 分支名	
  #切换到分支 develop
  $ git checkout develop

1.3 新增分支并切换到分支

  $ git branch -b 新建分支名
  #新开 develop 分支，并切换到此分支
  $ git checkout -b develop

1.4 查看分支

-a ：头带remotes/origin为远程分支

-r : 远程分支

  $ git branch -a | -r

1.5 向远程仓库提交分支

  $ git push origin 新建分支名
  #提交新建的 develop 分支
  $ git push origin develop

1.6 分支合并

  $ git merge 分支

1.7 分支删除

  $ git branch -d 分支名

1.8 分支删除

  $ git branch -d 本地分支名
  $ git push origin --delete 远程分支名

1.9 更新分支信息

  $ git fetch -p 更新分支信息

1.10 拉起远程仓库合并到本地分支

  $ git pull 分支

1.11 打tag

git tag -a v1.0.0 -m 'first tag'
git push origin --tags

1.12 文件移除版本库

git rm -r --cached file.js
git commit -m 'delete file'
git push origin develop

2.工作时常用的Git命令

  $ git add [filename] 添加文件
  $ git commit -m 'desc' 提交到缓存区
  $ git push origin [branchname] 提交修改到远程分支

3.Git工作流

本文的三种工作流程，有一个共同点：都采用”功能驱动式开发”（Feature-driven development，简称FDD）。它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。

3.1 Git flow工作流

特点：首先，项目存在两个长期分支。

  主分支master
  开发分支develop

前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。

git

其次，项目存在三种短期分支。

   功能分支（feature branch）
   补丁分支（hotfix branch）
   预发分支（release branch）

一旦完成开发，它们就会被合并进develop或master，然后被删除。

总结：优点：清晰可控；缺点：缺少相对复杂。

3.2 Github flow工作流

第一步：根据需求，从master拉出新分支，不区分功能分支或补丁分支。
第二步：新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request（简称PR）。
第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。
   对话过程中，你还可以不断提交代码。
第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。
   （先部署再合并也可。）

git

总结：优点就是简单，对于”持续发布”的产品，可以说是最合适的流程，缺点：缺少版本控制。

3.3 GitLab flow工作流

Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。

git

4.技巧

4.1 Pull Requests

Pull requests是Bitbucket提供的让开发者更方便地进行协作的功能，提供了友好的Web界面可以在提议的修改合并到正式项目之前对修改进行讨论。

4.2 Issue

Issue 用于 Bug追踪和需求管理。建议先新建 Issue，再新建对应的功能分支。功能分支总是为了解决一个或多个 Issue。功能分支的名称，可以与issue的名字保持一致，并且以issue的编号起首，比如”1-add-git.md”。开发完成后，在提交说明里面，可以写上”fixes #1”或者”closes #1”。Github规定，只要commit message里面有下面这些动词 + 编号，就会关闭对应的issue。

	close
	closes
	closed
	fix
	fixes
	fixed
	resolve
	resolves
	resolved

这种方式还可以一次关闭多个issue，或者关闭其他代码库的issue，格式是username/repository#issue_number。

Pull Request被接受以后，issue关闭，原始分支就应该删除。如果以后该issue重新打开，新分支可以复用原来的名字。

4.3 Merge分支合并

Git有两种合并：一种是”直进式合并”（fast forward），不生成单独的合并节点；另一种是”非直进式合并”（none fast-forword），会生成单独节点。

  $ git merge 分支名  #直进式合并
  $ git merge --no-ff 分支名   #非直进式合并

参考资料：

英文资料

Git 工作流程-阮一峰

Git工作流指南

Git 常用命令和 Git Flow 梳理

A successful Git branching model

git

Git常用命令及工作流梳理