title | date | tags |
---|---|---|
简洁优雅的git工作流 |
2016-04-28 03:06:45 -0700 |
git-work-flow legit |
GIT是一个版本控制系统,
版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统。
版本控制系统分为3类:
- 本地版本控制系统
- 集中化版本控制系统
- 分布式版本控制系统
git属于分布式版本控制系统, 相比于本地版本控制, git可以实现多人协作; 相比于集中化的版本控制系统, git每一台工作机上都有一个完整的git仓库, 不会因为主仓库duang掉就导致所有人无法开发提交, 更加安全。
Git中有三个重要的"分区": 工作区, 暂存区, 历史记录区
当我们git init
初始化一个仓库时, 会创建一个**.git**目录,
Git仓库的特性就是因为.git目录而存在。
工作区
Git仓库所在的目录, 程序员进行开发改动的地方.
暂存区
.git目录下的index文件, 暂存区会记录git
add
添加文件的相关信息(文件名、大小、timestamp...),不保存文件实体(文件实体保存在object对象区),
通过id指向每个文件实体。git commit
后同步index的目录树到object.
可以使用git status
查看暂存区的状态(git status具体见文末补充1)。
历史记录区
保存commit记录
初始化一个git仓库, 会创建**.git**目录(版本库)
.gitignore中存在的后缀名文件会在提交时被忽视, 后面涉及到具体技术的工作流时会利用好这个.gitignore文件。
git add files
将files添加到暂存区, git add
.
添加所有(除被.gitignore忽略)的文件到暂存区(index).
可以看到对象区(object)中已经存在文件实体和id.(更多关于对象区的概念见文末补充2)
有两个git撤销操作
git reset
git revert
git reset [commit head]
用于将版本库回滚到某次commit时的状态, 有两个参数选项--hard/soft
,
默认是soft。这两个选项的区别在于--hard会强制删除这次commit,
而--soft则是先将改动保存在暂存区等待稍后checkout到工作区.
注意, git reset撤销操作后, 撤销的这次commit之后的所有commit都将回退到暂存区。
git revert
用于撤销某次操作, 用一次新的commit去进行撤销, 且直接撤销,
不会回退到暂存区。
那么使用哪个撤销呢? 一个总的原则就是, 如果你的提交已经被别人通过版本库clone(即存在于别人的提交记录中), 那么使用git revert而不用git reset, 因为git reset会毁坏你的提交历史, 导致冲突的发生, git revert用新的commit去执行撤销是一种比较简洁的方式。
git remote add origin git_url
添加远程仓库地址(url), 并用origin指代git remote rm origin
删除origin对应的远程仓库
git branch
显示所有分支git checkout -b branch
创建一个新分支branchgit checkout branch
进入branch分支git branch -d branch
删除branch分支
git merge
和 git rebase
merge和rebase(变基)都可以用于分支的合并。merge会把两个分支的最新快照以及二者最近的共同
祖先进行三方合并,合并的结果是生成一个新的快照(并提交)。而rebase命令则将提交到某一
分支上的所有修改都移至另一分支上。变基以后的提交树只有一条主干。
git merge
git rebase
git工作流其实就是一套使用git进行版本控制的流程规范, 有利于团队的项目协作。
结合木犀的产品开发, 总结的git工作流(场景如下)
1. 创建远程git仓库(github服务)
2. 确定主分支(一般为master分支)
: 主分支用于发布**正式版本**(可以打上tag)
: 主分支确定后一定不要更换
3. 确定开发分支(develop)
: 用于功能开发
: merge某个开发者分支的功能实现
: 完成特定阶段功能后合并到主分支
: 发布隔夜(Night)版本
4. 开发者fork+clone主仓库
: clone仓库后checkout新分支
: 新分支的名字清楚明了(比如: 修bug分支叫bug, 个人开发分支叫develop)
: 合并到develop分支后新分支就可以删除
5. hotfix分支
: 修复master正式版本出现的bug
: 修bug的开发者checkout hotfix分支
: bug修复后合并到develop和master两个分支
6. 其他
: 预发布分支: 进行AB test
Git工作时的注意事项
- 删除操作时尽量使用
git revert
rebase虽好, 可不要贪杯哦
, 绝大多数情况下merge就足够了- 频繁提交, 这样不至于一次提交时和其他开发者的版本库相差太大
- 项目的管理者在进行开发时也要pull request! pull request的代码才可以保证质量(代码测试、code review)
最后但仍然重要的是
CI(持续集成), 这个现在还在摸索, 但是很重要,
更多关于CI可以看一峰大师的博客
legit 是一个git work flow工具, 封装了git的命令, 用于快速实现git工作流操作(比如一个命令将功能分支合并到开发分支)。官方称"for human", 作者是Python界大名鼎鼎的Kennethreitz(requests作者, heroku创始人)。
团队一直使用git作为版本管理工具, 但是没有一个项目是很好的遵守Git工作流的, 学而先前主要
是两个人开发, 还好。冲突在官网这边体现的比较多, 可以看一下官网的分支和commit:
官网现在是git单分支。目前聪聪和斯蒂芬两个人,
如果再加2个人估计就要麻烦了。这个要想想办法, clean一下。
当执行 "git status" 命令扫描工作区改动的时候,先依据 .git/index 文件中记录的(工作区跟踪文件的)时间戳、长度等信息判断工作区文件是否改变。如果工作区的文件时间戳改变,说明文件的内容可能被改变了,需要打开文件,读取文件内容,和更改前的原始文件相比较(本地文件和与之对应的object库中的文件的内容进行对比),判断文件内容是否被更改。如果文件内容没有改变,则将该文件新的时间戳记录到 .git/index 文件中。因为判断文件是否更改,使用时间戳、文件长度等信息进行比较要比通过文件内容比较要快的多,所以 Git 这样的实现方式可以让工作区状态扫描更快速的执行,这也是 Git 高效的因素之一。