Git基础和规范-协同开发

2018-01-30 11:18:35 浏览数 (1)

关于版本控制

什么是版本控制：

官方说法：版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统，你可以对任何类型的文件进行版本控制。

版本控制系统变迁

要做好版本控制，少不了相应的系统，版本控制系统也经历过不少变迁：

原始 —— 本地版本控制系统：用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。适合于个人开发，手动打版。

进化 —— 集中式版本控制系统：是为了解决开发者协同工作问题，诸如 CVS 、Subversion 。它们都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。

再进化 —— 分布式版本控制系统：为了解决单点备份问题，进化出了分布式版本控制系统，最有名的莫过于 Git。客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。

当然，Git 除了能解决单点故障问题，还有诸如离线提交、快速切换分支、方便合并、更少的仓库污染等特性。 在技术层面上，Git绝对是一个无中心的分布式版本控制系统，但在管理层面上，我建议你保持一个中心版本库（Origin），如下图所示：

Git历史

  1. 诞生于 2005 年
  2. 由Liunx的缔造者 Linus Torvalds 主导开发
  3. 他之所以自己开发版本控制系统的原因，是因为商用的不给用，免费的不好用，那就自己来吧（牛人就是牛人）。
  4. Git的设计目标：
  • 速度
  • 简单的设计
  • 对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
  • 完全分布式
  • 有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）

Git基础

Git安装和配置

1. 安装

Linux：

代码语言：javascript复制
　　sudo apt-get install git-core

Windows：Git for windows

2. 配置

查看配置：

代码语言：javascript复制
　　git config --list/-l

更改配置：

代码语言：javascript复制
　　git config --global user.name "X-兵戈"　　git config --global user.email "770581715@qq.com"

作用域：

代码语言：javascript复制
　　--system --global --local

Git基础命令

初学Git时，尽量动手敲过所有命令行。以下是一些Git最基础的命令，需要烂熟于心。

代码语言：javascript复制
　　* git clone/git ini
　　* git add/git commit（必须带message）
　　* git branch/git checkout
　　* git fetch/git pull/git push（不要用---force参数）
　　* git status/git log　　* gitk：图形化界面看记录
　　* .gitignore：忽略文件

附上之前同事总结的Git常用命令：

Git本地操作常用命令
Git远程操作常用命令

Git分支规范

参考业界常用的Git分支规范，总结理财技术的规范如下：

主分支-master

  • 代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。
  • Git主分支的名字，默认叫做 Master 。
  • 初始化工程 　　git clone git@git.oschina.net:xbingo/android-app.git 　　cd Medusa 　　touch README.md 　　git add README.md 　　git commit -m "add README" 　　git push -u origin master

开发分支-develop

  • 主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做 develop。
  • 如果想正式对外发布，就在Master分支上，对develop分支进行"合并"（ merge ）。
  • Git创建Develop分支的命令： 　　git checkout -b develop master
  • 将Develop分支发布到Master分支的命令： 　　# 切换到master分支　　git checkout master 　　# 对develop分支进行合并　　git merge --no-ff develop

功能分支-feature

  • 功能分支，它是为了开发某种特定功能，从develop分支上面分出来的。开发完成后，要再并入develop。
  • 功能分支的名字，可以采用 feature-* （功能名）的形式命名。
  • 创建一个功能分支： 　　git checkout -b feature-x develop *开发完成后，将功能分支合并到develop分支： 　　git checkout develop 　　git merge --no-ff feature-x
  • 删除feature分支： 　　git branch -d feature-x

修补分支-fixbug

  • 修补分支：软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。
  • 修补bug分支是从master分支上面分出来的。修补结束以后，再合并进master和develop分支。它的命名，可以采用 fixbug-* （日期）的形式。
  • 创建一个修补bug分支： 　　git checkout -b fixbug-0.1 master
  • 修补结束后，合并到master分支： 　　git checkout master　　git merge --no-ff fixbug-0.1　　git tag -a 0.1.1
  • 再合并到develop分支： 　　git checkout develop 　　git merge --no-ff fixbug-0.1
  • 最后，删除"修补bug分支"： 　　git branch -d fixbug-0.1

其他分支-tag/release

tag分支 ：打版本分支，每次上线前需要打一个版本，可以采用 tag-版本号 的命名方式。还可以作为回滚的分支

release分支 ：小项目一般用不上，我建议理解为里程碑项目版本分支。常用于上线发布前的准备工作及代码修复，严禁新功能的并入，新功能应该是被合并到“develop”分支的。起源于develop分支，最终归于“develop”或“master”分支。可以采用 release-版本号 的命名方式

分支责任分工

分支

职责描述

master

配置管理员 ：统一创建、部署、维护（不允许手动提交）

develop

配置管理员 ：统一创建、部署 开发人员 维护（feature测试通过后merge至"develop"分支）

feature

开发人员 ：各模块自行创建、部署、维护（测试通过后merge至"develop"分支）

fixbug

配置管理员 ：统一创建、部署、维护（测试通过后自动merge至“master”和“develop”） <br> 开发人员 ：修复bug，协助解决自动merge中发生的冲突

tag

配置管理员 ：统一创建（每次上线前创建）

分支对应的环境

分支

环境

Master/fixbug

线上环境

develop

测试环境/联调环境/预发环境

feature

各模块测试环境

Git资料

  • Pro Git ： 官网文档，非常推荐
  • 《Git权威指南》 ： 权威
  • Git在线学习 ：非常有意思。寓教于乐，学习Git
  • 国内Git教程 ： 除了广告多了点，其他都不错

✦ ✦ ✦ ✦ ✦ ✦ ✦ ✦

作者：黄云一鹤 原文：

https://my.oschina.net/xbingo/blog/532262

git svn

0 人点赞