git版本控制

时间 2019-11-12

标签 git 版本控制栏目 Git 繁體版

原文原文链接

Git版本控制与工做流

文章做者：Sam_Lau
源自：www.jianshu.com/p/67afe711c731

这篇文章是针对git版本控制和工做流的总结，若是有些朋友以前还没使用过git，对git的基本概念和命令不是很熟悉，能够从如下基本教程入手：html

基本概念

Git是什么？git

Git是分布式版本控制系统，与SVN相似的集中化版本控制系统相比，集中化版本控制系统虽然可以令多个团队成员一块儿协做开发，但有时若是中央服务器宕机的话，谁也没法在宕机期间提交更新和协同开发。甚至有时，中央服务器磁盘故障，恰巧又没有作备份或备份没及时，那就可能有丢失数据的风险。github

但Git是分布式的版本控制系统，客户端不仅是提取最新版本的快照，并且将整个代码仓库镜像复制下来。若是任何协同工做用的服务器发生故障了，也能够用任何一个代码仓库来恢复。并且在协做服务器宕机期间，你也能够提交代码到本地仓库，当协做服务器正常工做后，你再将本地仓库同步到远程仓库。服务器

为何要使用Git

可以对文件版本控制和多人协做开发
拥有强大的分支特性，因此可以灵活地以不一样的工做流协同开发
分布式版本控制系统，即便协做服务器宕机，也能继续提交代码或文件到本地仓库，当协做服务器恢复正常工做时，再将本地仓库同步到远程仓库。
当团队中某个成员完成某个功能时，经过pull request操做来通知其余团队成员，其余团队成员可以review code后再合并代码。

Git有哪些特性

文件三种状态(modified, staged, committed)
直接记录快照，而非差别比较
多数操做仅添加操做
近乎全部操做都是本地执行
时刻保持数据完整性

有关以上特性的详细解释，请查看Pro git的git基础章节分布式

Git基本工做流程

在git版本控制的目录下修改某个文件
使用git add命令对修改后的文件快照，保存到暂存区域
使用git commit命令提交更新，将保存在暂存区域的文件快照永久转储到 Git 目录中

Git基本技巧

自动补全
Git 命令别名

关于具体如何使用自动补全和命名别名技巧，请查看Pro git的技巧和窍门ide

Git版本控制

建立仓库工具

git init
git clone
git config

保存修改学习

git add
git commit

查看仓库测试

git status
git log --oneline

撤销修改fetch

查看以前的commit

git checkout <commit> <file>
git checkout <commit>
git checkout <branch>

撤销公共修改

git revert <commit>

撤销本地修改

git reset
git clean

重写Git历史记录

git commit --amend
git rebase
git reflog

Git协做开发

分支

git branch
git checkout
git merge

仓库同步

git remote
git fetch
git pull
git push

Git工做流

因为git拥有强大的分支特性，它的工做流比较灵活而缺少约束，因而参考Atlassian Git Tutorial的Comparing Workflows章节提供四种Git工做流：

Centralized Workflow
Feature Branch Workflow
Gitflow Workflow
Forking Workflow

以上工做流只是参考指南，而不是具体规则。你能够根据本身实际状况来选择适合本身的工做流或微调来知足本身的须要。

Centralized Workflow

过渡到分布式版本控制系统看起来像一个艰巨的任务，但若是你充分利用好git的话，你没必要改变你既有的工做流，你的团队能够采用与以前使用SVN同样的方式来开发项目。

如何工做

Centralized Workflow

从远程仓库(central repository)克隆工程到本地仓库(local repository) ---git clone
在本地仓库编辑文件和提交更新 ---git add和git commit
fetch远程仓库已更新的commit到本地仓库和rebase到已更新的commit的上面 ---git fetch和gitrebase或git pull --rebase
push本地主分支(master branch)到远程仓库 ---git push

管理冲突

File Conflicts

什么时候发生冲突：在开发者发布它们功能以前，他们须要fetch远程仓库已更新的commit到本地仓库和rebase到已更新的commit的上面。有时，本地提交与远程提交会发生冲突，git会暂停rebase过程来让你手动解决冲突。
如何解决冲突：你可使用git status和git add来手动解决合并时冲突。

Feature Branch Workflow

Feature Branch Workflow的主要思想就是在开发每一个功能时都应该建立一个独立的分支而不仅是使用主分支。因为每一个分支是独立且互不影响，这就意味着主分支不会包含broken code，对持续集成环境是颇有帮助的。

如何工做

Feature Branch Workflow

仍然使用远程仓库(central repository)和主分支(master branch)仍记录官方工程的历史
开发者每次开发新功能时都建立一个新分支 ---git checkout -b
Feature branches应该推送到远程仓库(central repository) ---git push
发送pull request来请求管理员可否合并到主分支(master branch)
发布新功能到远程仓库(central repository)

Pull Request

Pull request是一种当开发者完成一个新功能后向其余团队成员发送通知的机制。它的使用过程以下：

开发者能够经过Github或Bitbucket发送pull request

Pull request on Github

其余的团队成员审查、讨论和修改代码
项目维护者合并新增功能分支到主分支(master branch)，而后关闭pull request

Gitflow Workflow

Feature Branch Workflow是一种很是灵活的开发方式。对于一些规模比较大的团队，最好就是给特定的分支赋予不一样的角色。除了功能分支(feature branch)，Gitflow Workflow还使用独立的分支来准备发布(preparing)，维护(maintaining), 和记录版本(recording releases)。下面我会逐个介绍这个几个分支：Historical Branches、Feature Branches、Release Branches和Maintenance Branches。

Historical Branches

Historical Branches

master分支保存官方发布历史
develop分支衍生出各个feature分支

Feature Branches

Feature Branches

feature分支使用develop分支做为它们的父类分支
当其中一个feature分支完成后，它会合并会develop分支
feature分支应该从不与master分支直接交互

Release Branches

Release Branches

release分支主要用来清理释放、测试和更新文档
一旦develop分支得到足够的功能来发布时，你能够从develop衍生出一个release分支
一旦准备好上架，release合并到master分支而且标记一个版本号
另外，还须要合并回develop分支

Maintenance Branches

Maintenance Branches.png

maintenance分支用来快速给已发布产品修复bug或微调功能
它从master分支直接衍生出来
一旦完成修复bug，它应该合并回master分支和develop分支
master应该被标记一个新的版本号

标记Tags

使用两个命令来给master分支标记版本号：

git tag -a 0.1 -m "Initial public release" master
git push origin master --tags

Forking Workflow

Forking Workflow与以上讨论的工做流很不一样，一个很重要的区别就是它不仅是多个开发共享一个远程仓库(central repository)，而是每一个开发者都拥有一个独立的服务端仓库。也就是说每一个contributor都有两个仓库：本地私有的仓库和远程共享的仓库。

Forking Workflow

Forking Workflow这种工做流主要好处就是每一个开发者都拥有本身的远程仓库，能够将提交的commits推送到本身的远程仓库，但只有工程维护者才有权限push提交的commits到官方的仓库，其余开发者在没有受权的状况下不能push。Github不少开源项目都是采用Forking Workflow工做流。

如何工做

在服务器上有一个官方公共的仓库
开发者fork官方仓库来建立它的拷贝，而后存放在服务器上

Fork official repository.png

当开发者准备好发布本地的commit时，他们push commit到他们本身的公共仓库
在本身的公共仓库发送一个pull request到官方仓库
维护者pull贡献者的commit到他本身的本地仓库
审查代码确保它不会破坏工程，合并它到本地仓库的master分支
push master分支到服务器上的官方仓库
其余开发者应该同步官方仓库。

扩展阅读