原文出处: 刘耀柱(@Sam_Lau_Dev) 欢迎分享原创到伯乐头条
Git Version Control
这篇文章是针对git版本控制和工作流的总结,如果有些朋友之前还没使用过git,对git的基本概念和命令不是很熟悉,可以从以下基本教程入手: 基本概念Git是什么?Git是分布式版本控制系统,与SVN类似的集中化版本控制系统相比,集中化版本控制系统虽然能够令多个团队成员一起协作开发,但有时如果中央服务器宕机的话,谁也无法在宕机期间提交更新和协同开发。甚至有时,中央服务器磁盘故障,恰巧又没有做备份或备份没及时,那就可能有丢失数据的风险。 但Git是分布式的版本控制系统,客户端不只是提取最新版本的快照,而且将整个代码仓库镜像复制下来。如果任何协同工作用的服务器发生故障了,也可以用任何一个代码仓库来恢复。而且在协作服务器宕机期间,你也可以提交代码到本地仓库,当协作服务器正常工作后,你再将本地仓库同步到远程仓库。 为什么要使用Git
Git有哪些特性
有关以上特性的详细解释,请查看Pro git的git基础章节 Git基本工作流程
Git基本技巧
关于具体如何使用自动补全和命名别名技巧,请查看Pro git的技巧和窍门 Git版本控制创建仓库
保存修改
查看仓库
撤销修改查看之前的commit
撤销公共修改
撤销本地修改
重写Git历史记录
Git协作开发分支
仓库同步
Git工作流由于git拥有强大的分支特性,它的工作流比较灵活而缺乏约束,于是参考Atlassian Git Tutorial的Comparing Workflows章节提供四种Git工作流:
以上工作流只是参考指南,而不是具体规则。你可以根据自己实际情况来选择适合自己的工作流或微调来满足自己的需要。 Centralized Workflow过渡到分布式版本控制系统看起来像一个艰巨的任务,但如果你充分利用好git的话,你不必改变你既有的工作流,你的团队可以采用与之前使用SVN一样的方式来开发项目。 如何工作
Centralized Workflow
管理冲突
File Conflicts
Feature Branch WorkflowFeature Branch Workflow的主要思想就是在开发每个功能时都应该创建一个独立的分支而不只是使用主分支。由于每个分支是独立且互不影响,这就意味着主分支不会包含broken code,对持续集成环境是很有帮助的。 如何工作
Feature Branch Workflow
Pull RequestPull request是一种当开发者完成一个新功能后向其他团队成员发送通知的机制。它的使用过程如下:
Pull request on Github
Gitflow WorkflowFeature Branch Workflow是一种非常灵活的开发方式。对于一些规模比较大的团队,最好就是给特定的分支赋予不同的角色。除了功能分支(feature branch),Gitflow Workflow还使用独立的分支来准备发布(preparing),维护(maintaining), 和记录版本(recording releases)。下面我会逐个介绍这个几个分支:Historical Branches、Feature Branches、Release Branches和Maintenance Branches。 Historical Branches
Historical Branches
Feature Branches
Feature Branches
Release Branches
Release Branches
Maintenance Branches
Maintenance Branches.png
标记Tags使用两个命令来给master分支标记版本号:
Forking WorkflowForking Workflow与以上讨论的工作流很不同,一个很重要的区别就是它不只是多个开发共享一个远程仓库(central repository),而是每个开发者都拥有一个独立的服务端仓库。也就是说每个contributor都有两个仓库:本地私有的仓库和远程共享的仓库。
Forking Workflow
Forking Workflow这种工作流主要好处就是每个开发者都拥有自己的远程仓库,可以将提交的commits推送到自己的远程仓库,但只有工程维护者才有权限push提交的commits到官方的仓库,其他开发者在没有授权的情况下不能push。Github很多开源项目都是采用Forking Workflow工作流。 如何工作
扩展阅读 |
|