Git小结

1.  版本管理工具有哪些？

a.      VSS 微软的版本控制管理工具，仅支持Windows系统，简单好用，单仅局限于团队级开发，不能胜任企业级开发工作。

b.      CVS 典型的C/S软件，功能相对单一，简陋，适合几个人的小型团队，在数据量不大的情况下性能可以接受。

c.      SVN 前身是CVS，包括了CVS的特点，也增加了一些新功能；

d.      ClearCase、StarTeam闭源集中式

e.      GIT、Mercurial、Monotone开源分布式

2.  GIT相比SVN和其他版本控制工具有什么优势？

2.1设计思想

1.      svn 是基于revision的也就是delta，git是基于状态的;

2.      svn单分支是一条revision的时间线，git则是由commits组成的DAG;

3.      branch的设计，svn是revision-on-writegit是DAG上加一个引用；

2.2使用体验

1.Git可以本地commit,可以随便保存各种历史痕迹，svncommit就到服务器了，发现commit错了就要回滚重来；

2.Git branch拉取和切换很简单，svn一个branch就是一个copy；

3.分布式去中心化使得团队的维护更加容易

4.分支的合并速度更快

5.微commit和微branch，每个微小的修改都可以使用branch和commit

2.3主要区别：

Svn是集中版本控制系统，版本库存放在中央服务器，干活时从中央服务器获得最新版本，干完活推到中央服务器，必须联网才行。

Git是分布式版本控制系统，没有中央服务器，每台电脑都是一个完整的版本库，这样工作时不需要联网，在多人协作时推送到远端就可以。

每个开发可以有属于自己的整个工程的本地拷贝。隔离的环境让各个开发者的工作和项目的其他部分修改独立开来 ——即自由地提交到自己的本地仓库，先完全忽略上游的开发，直到方便的时候再把修改反馈上去。

Git提供了强壮的分支和合并模型。不像SVN，Git的分支设计成可以做为一种用来在仓库之间集成代码和分享修改的『失败安全』的机制。

如你所见，仅使用几个Git命令我们就可以模拟出传统Subversion开发环境。对于要从SVN迁移过来的团队来说这太好了，但没有发挥出Git分布式本质的优势。

功能分支工作流背后的核心思路是所有的功能开发应该在一个专门的分支，而不是在master分支上。这个隔离可以方便多个开发者在各自的功能上开发而不会弄乱主干代码。 另外，也保证了master分支的代码一定不会是有问题的，极大有利于集成环境。

3.  GIT使用实践

3.1 Git常用命令流程

 

Workspace工作区、Index/Stage 暂存区、localrepository本地仓库区、remote repository 远程仓库区

3.2 Git常用命令

A．初始设置

git config --global user.name “James”

git config –global user.email "[e-mail]"

   B.本地操作

      #添加指定文件到暂存区

      git add [file1] [file2] [file3]…

      #添加指定目录到暂存区，包括子目录

      git add [dir]

      #添加当前目录的所有文件到暂存区

      git add .

      #删除工作区文件

      git rm [file1] [flie2]

      #检出独立分支(跟踪主分支)

      git checkout –b new-feature master

      #推送本地分支到远程

      git push –u origin new-feature

   C.远端操作

            #克隆远端代码到本地

      git clone <git 地址>

      #远端抓取

            git fetch

      #与本地当前分支合并

      git merge

      #抓取并合并

      git pull

      #推送到远端(在当前追踪分支时local branch和：可省略)

      git push [-f] [local branch]:[remote branch]

   D．分支操作

      #列出本地分支、远程分支、本地和远程分支

             git branch、git branch –r、git branch–a

      #新建分支，但仍停留在当前分支

       git branch [branch name]

      #新建分支，并切换到该分支

       git checkout –b [branch name]

      #新建分支，并与指定的远程分支建立追踪关系

       git branch  -- track  [branch name] [remote branch]

      #切换到指定分支(已存在的分支)

       git checkout [branch name]

      #切换到上一分支

       git checkout –

      #合并指定分支到当前分支(branch A为待合并的分支，当前分支可以省略)

       git merge [branch A]

       #删除本地分支

       git branch –d [branch name]

      #删除远程分支

       git push origin –delete [branch name]

       git branch –dr [remote branch]

E.代码提交

  #提交暂存区到仓库区（全部修改）

  git commit –m “message”

     #提交暂存区指定文件到仓库区

     git commit [file1] [file2]… -m “message”

     #提交工作区自上次commit之后的变化直接到仓库区（跳过暂存区）

     git commit –a

     #提交时显示所有diff消息

     git commit –v

     #使用一次新的commit 替代上次的提交

       如果代码没有任何新的变化，则用来修改上次的提交信息

     git commit –amend  -m “[message]”

F.查看信息

#显示有变更的文件

git status

#显示当前分支的历史版本

git log

#显示commit历史，以及每次commit发生变更的文件

git log –stat

#显示某个commit之后的所有改动，每个commit占据一行

git log HEAD –pretty=format:%s

#显示某个文件的历史版本

git log –follow [file]

git whatchanged [file]

#显示指定文件相关的每一次diff

git log –p [file]

#显示最近N次提交信息

git log –n –pretty –oneline

#显示所有提交过的用户，按提交次数排序

git shortlog –sn

#显示指定文件什么人在什么时间修改过

git blame [file]

#显示暂存区和工作区的区别

git diff

#显示n天之内修改了多少代码

git diff –shortstat “@{n day ago}”

#显示当前分支的最近几次的提交

git reflog

G.撤销操作

#恢复暂存区的指定文件到工作区

git checkout [file]

#恢复某个commit的指定文件到暂存区和工作区

git checkout [commit] [file]

#恢复暂存区的所有文件到工作区

git checkout .

#重置暂存区的指定文件与上一次commit保持一致，单工作区不变

git reset [file]

#重置暂存区和工作区，与上一次commit保持一致

git reset –hard

#重置当前分支的指针为指定的commit，同时重置暂存区，单工作区保持不变

git reset [commit]

#重置当前分支的HEAD为指定的commit，同时重置暂存区和工作区，与指定的commit保持一致

git reset –hard[commit]

#将未提交的变化移除

git stash

3.3 Git团队协作指南

A.      基本流程

1.对于没有合并权限限制的分支在本地建立跟踪分支和开发分支，在开发分支进行代码修改，完成修改之后pull最新远程分支，防止冲突，解决冲突之后提交到本地开发分支，再向本地跟踪分支合并，再从跟踪分支提交到远程分支，总之，开发分支对于远程是不可见的，本地跟踪分支是开发分支和远程分支中间件。

2.对于有合并权限的分支需要将本地开发分支推送到远程，再发起pull request，之后将推送到远程的本地开发分支删除。

 

B.      提交注释

1. Angular规范

git commit 遵循Angular规范，这是目前使用最为广泛的写法，比较合理和系统化，并有配套工具。

规范书写git commit message有以下好处:

1.方便快速浏览：每个message占据一行，只看行首就知道该次commit的目的

2.可以过滤某些message便于快速查找信息

3.可以直接从commitmeassge生成change log

2.Commit message的格式

Commit message 包括三个部分：Header Body Footer

其中Header是必须的，Body和Footer可以省略

Header包括：<type>(<scope>):<subject>

1.      type用于说明commit的类别，只允许使用以下7个标识：

feat：新功能（feature）

fix:修复bug

docs:文档

style:格式（不影响代码运行的改动）

refactor:重构

test:增加测试

chore:构建过程或者辅助工具的变动

2.      scope用于说明commit的影响范围，比如数据层、控制层等等，可选

3.      subject是本次commit的目的简短描述，不要超过50个字符

以动词开头，使用第一人称现在时

第一个字母小写

结尾不加句号.

C.       分支规范

所有项目采用分支开发方式，分支有：master分支、开发分支、新功能分支、修复分支、其他分支。

4.  GIT使用习惯

如果一个团队在使用 Git时没有一些规范，那么将是一场难以醒来的噩梦！然而，规范固然重要，但更重要的是个人素质，在使用 Git时需要自己养成良好的习惯。

4.1提交

除了3中提到的commit message的书写规范之外，还要养成如下习惯：

a.提交时的粒度是一个小功能点或者一个 bug fix，这样进行恢复等的操作时能够将「误伤」减到最低；

b.用一句简练的话写在第一行，然后空一行稍微详细阐述该提交所增加或修改的地方；

c.不要每提交一次就推送一次，多积攒几个提交后一次性推送，这样可以避免在进行一次提交后发现代码中还有小错误。

4.2推送、拉取、合并

4.3分支管理

成熟的git flow模型可以应对99%的场景。它只是一个模型，而不是一个工具；你可以用工具去应用这个模型，也可以用最朴实的命令行。所以，重要的是理解概念，不要执着于实行的手段。简单说来，Git Flow 就是给原本普普通通的分支赋予了不同的「职责」：

master——最为稳定功能最为完整的随时可发布的代码；

hotfix——修复线上代码的 bug；

develop——永远是功能最新最全的分支；

feature——某个功能点正在开发阶段；

release——发布定期要上线的功能。

   其中master和develop是主要分支，其他分支是基于它们派生出来的，主要分支每种类型只有1个，派生分支可以有多个。

Gitflow工作流通过为功能开发、发布准备和维护分配独立的分支，让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。

Gitflow工作流没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。除了使用功能分支，在做准备、维护和记录发布也使用各自的分支。当然你可以用上功能分支工作流所有的好处：PullRequests、隔离实验性开发和更高效的协作。

 

 

5.  参考资料

https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md

https://ourai.ws/posts/working-with-git-in-team/

http://nvie.com/posts/a-successful-git-branching-model/

                                                   by baiyt 2016.12.21