在一线互联网公司就职，对技术工作充满热爱，希望一生走技术的道路。
2018年（4）
分类： IT职场
2018-08-08 19:59:05
如果你还是 git 的新手，请先看下这个简明 git 教程 ，以及 git 中最核心的概念:commit 和 branch 的原理（这个如果暂时看不懂可以先不管） ，还有 git-flow 的介绍http://blog.jobbole.com/76867/
本文将用纯命令行从 初始化一个项目，开发一个需求，发布，修复线上问题，回滚操作 5个方面来介绍 git-flow 的全流程，需要具备入门级的 git 知识。如果用熟悉了之后，也可以使用SourceTree,或者git-flow 命令行来走git flow的流程，更易用。
你在 git.oa 的相应组织中的权限需要是 Master 级别。另外，我们在应用git-flow的过程中，在最后一步，release合并到master的过程中加入了review流程，禁止了直接提交master，所以，从release合并到master不能在本地进行合并，而且要在git.oa.com 申请一个merge request去合并。
新建并打开你的项目文件夹
mkdir project && cd project
添加一个gitignore文件，可以在找到不同语言的demo
vi .gitignore
添加一些项目说明
vi readme.md
初始化一个git项目
git init
添加所有的文件到暂存区
git add *
向本地仓库提交当前的变动，-a可以省略，-a,用于只修改了文件没有新增文件的情况，加了之后就可以省略git add 这一步了。
git commit -m "for init" -a
在 创建一个项目,创建好之后，把本地初始化的之后 git 项目 push 上去，注意这里最好切到ssh的地址，以后可以免输密码提交或更新，还没有生成sshkey并添加到git.oa平台的，请参照，操作完成之后再进行下面的操作。下面两句话是复制你在 git.oa 创建项目之后 git.oa 上的给的示例初始化的命令中节选的
git remote add origin .com:group-name/project-name.git git push -u origin master
在 项目设置 Settings->Protected Branches 里面，可以看到 master 分支已经被默认设置为 protected 了，把 Allowed to push 改为 Owner,然后点击 Edit ,Review 的2个选项都勾上，然后填下你的项目组里的其它同事作为 Suggest reviewers，这样，只有别人中的任何一个人同意，你的 merge 才能被合并到 master ,保存即可
再回到本地，在这之后就要开一个 develop 分支了
git checkout -b develop
把 develop 分支推到远程仓库（并-u设置为当前分支默认 pull 的远程分支）,这个分支将会永远存在
git push -u origin develop
now，你项目的2个一直会存在的分支 master/develop 已经建好了，接下来开始开发你的第一个需求吧,你需要搞个新 feature 分支
git checkout develop
git checkout -b feature/my-first-feature
比如说先搞个新文件
vi index.js
暂存变更(或者也可以暂存所有 git add .)
git add index.js
提交变更
git commit -m "for index js" -a
如果是多人合作的话，这个分支也可以先提交到远程仓库，等整个特性开发完成之后再把它删除
git push origin feature/my-first-feature
开发/转测的过程中需要不断地把当前 develop 上最新的更新给更新下来,防止合并的时候出现较多冲突
git fetch origin develop
git merge origin/develop # 上面这两句也可以合并为 git pull origin develop
开发完成之后就继续在这个分支上转测，修bug
这个时候假如这个特性已经开发和测试完了，这个时候需要先把当前特性合并到 develop 分支，先切换到 develop 分支
git checkout develop
把服务器上最新的 develop 分支 pull 下来
git pull origin develop
在 develop 分支 merge 你的特性
git merge feature/my-first-feature
merge 完毕就可以删掉你的 feature 分支了，本地的和远程的都删掉（如果提交到远程的话）
git branch -d feature/my-first-feature
git push origin --delete feature/my-first-feature
最后把 develop 提交到远程仓库的 develop 分支
git push
这个时候准备发布这个特性了,从 develop 分支新建个 release 分支
git checkout -b release/v0.0.1
这个时候进行最后的发布验证,如果有 bug ，那就在这个分支下修改，改完提交并完成全部的验证之后，把 release 的提交合并到 develop 分支.
vi xxx.js
git add xxx.js git commit -m "for release update" # 发布验证bug已修复完成之后，把更新的提交合并到develop分支里，并提交 git checkout develop
git merge release/v0.0.1 git push
准备正式发布了。这个时候把 release 分支给 push 到远程仓库
git checkout release/v0.0.1 git push origin release/v0.0.1
然后在 git.oa 平台里，把本次 release 的特性，创建一个 merge request，选择从 release/v0.0.1 merge 到 master，选择 review 的人，你的小伙伴会收到 review 的通知，他需要进行 review，review 之后，同意并进行合并。
提交 merge 界面：
review merge 界面：
review 人从 merge 请求链接进去可以查看变更
同意变更
操作 merge
发布正式版,在本地切换到 master 分支，然后 pull 最新的更新
git checkout master
git pull origin master
发布完成之后，就可以在本地删掉这个 release 分支了
# 因为刚在界面上合并到 master 的时候把远程的 release 分支删掉了，所以先同步远程分支的变更 git fetch origin -p # 删除本地的 release 分支 git branch -d release/v0.0.1
2个选择，一个是在 master 分支，新建一个 hotfix 分支来解决这个bug,另一个是回滚到前面的某个稳定版本,优先推荐新建 hotfix 来解决 bug ，因为回滚如果不熟悉的话，可能对项目造成一些影响。
先 checkout 到 master 分支
git checkout master
更新到远程 master 最新的代码
git pull origin master
在这个分支上 checkout 出一个新的 hotfix 分支
git checkout -b hotfix/my-first-bug
改 bug
vi xx.js git add xx.js git commit -m "for xx bug"
在当前分支验证 bug 是否修复 ok ,如果 ok ，把当前分支 push 到远程仓库
git push origin hotfix/my-first-bug
然后就和 release 发布正式版一样，在 git.oa 创建一个 merge request，选择从 hotfix/my-first-bug merge 到 master，选择 review 的人，你的小伙伴会收到 review 的通知，他需要进行 review，review 之后，同意并进行合并并删除原 hotfix 的分支
合并之后就可以发布了,在本地切换到 master 分支，然后 pull 最新的更新
git checkout master
git pull origin master
发布完成之后，就可以在本地删掉这个 hotfix 分支了
# 因为刚在界面上合并到 master 的时候把远程的 hotfix 分支删掉了，所以先同步远程分支的变更 git fetch origin -p # 删除本地的 hotfix 分支 git branch -d hotfix/my-first-bug
对于前端项目的回滚，这里只列举2种最常用的回滚，分别是针对单个文件的回滚和针对项目维度的回滚
如果你只是想回滚某个文件到某个版本的话，git 很友好，只需要把文件回滚到某个版本，然后创建一个新的提交就可以了。
先从 master 新建一个分支
git checkout master
git checkout -b hotfix/xx-file-bug
查找文件的历史，找到你要回滚的那个版本的 commitId
git log xx.js
把暂存区的该文件重置到某个特定版本（这步操作会把该文件的3265xxx版本放在暂存区，而工作目录里的该文件依然是最新版）
git reset 32652635a5d3a50c2acf8d2b7ccff3bbdb77b8cb xx.js
直接提交
git commit -m "for xx.js bug"
在当前分支验证 bug 是否修复 ok ,如果 ok ，把当前分支 push 到远程仓库
git push origin hotfix/xx-file-bug
然后就和 release 发布正式版一样，在 git.oa 创建一个 merge request，选择从 hotfix/xx-file-bug merge 到 master，选择 review 的人，你的小伙伴会收到 review 的通知，他需要进行 review，review 之后，同意并进行合并并删除原 hotfix 的分支
合并之后就可以发布了,在本地切换到 master 分支，然后 pull 最新的更新
git checkout master
git pull origin master
发布完成之后，就可以在本地删掉这个 hotfix 分支了
# 因为刚在界面上合并到 master 的时候把远程的 hotfix 分支删掉了，所以先同步远程分支的变更 git fetch origin -p # 删除本地的 hotfix 分支 git branch -d hotfix/xx-file-bug
针对项目的回滚有几种方式，由于是前端项目，我们的需求只是回滚到某个特定的版本，然后把特定版本的文件编译发布出去，所以不建议用回滚远程仓库的方式去回滚（远程仓库回滚后可能需要每个使用该远程仓库的人在本地做一些操作）。这里只介绍一种不影响别人，先把特定版本快速发布上线，然后再在最新的版本上建分支修复 bug。
保证当前工作目录是干净的，先把当前的未提交的东西先提交到相应的分支，然后找到你要回滚的版本，可以是 commidId,或者是 tag
git checkout <commitId or tag>
这个时候你当前的工作目录就已经是对应的版本的文件了，在当前目录下操作编译，打包，发布就可以了，操作完成之后再切回 master 分支，按照上面的 hotfix 分支解决问题的步骤去修复问题就可以了。