架构师工具箱（一）Git

 

写在前面：

你好，欢迎关注！

• 我热爱技术，热爱分享，热爱生活， 我始终相信：技术是开源的，知识是共享的！
• 博客里面的内容大部分均为原创，是自己日常的学习记录和总结，便于自己在后面的时间里回顾，当然也是希望可以分享自己的知识。目前的内容几乎是基础知识和技术入门，如果你觉得还可以的话不妨关注一下，我们共同进步！
• 个人除了分享博客之外，也喜欢看书，写一点日常杂文和心情分享，如果你感兴趣，也可以关注关注！
• 公众号：傲骄鹿先生

部分内容转自： https://www.cnblogs.com/best/p/7474442.html

---

目录

一、什么是Git以及Git的工作原理

二、Git常用命令

三、Git冲突怎么引起的，怎么解决

四、架构师职责：Git Flow规范团队git使用规程

---

前言

本文不对Git进行详解，若想详细学习，可以看以下地址的博文，强烈推荐。https://www.cnblogs.com/best/p/7474442.html

还有一个过关式游戏的教程，有模型解读知识，强烈推荐。https://learngitbranching.js.org/?demo

一、什么是Git以及Git的工作原理

1、什么是Git？

Git 是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。

Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

Git 与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持。

2、Git的工作原理

2.1、工作区域

Git本地有三个工作区域：工作目录（Working Directory）、暂存区(Stage/Index)、资源库(Repository或Git Directory)。如果在加上远程的git仓库(Remote Directory)就可以分为四个工作区域。文件在这四个区域之间的转换关系如下：

• Workspace：工作区，就是你平时存放项目代码的地方
• Index / Stage：暂存区，用于临时存放你的改动，事实上它只是一个文件，保存即将提交到文件列表信息
• Repository：仓库区（或本地仓库），就是安全存放数据的位置，这里面有你提交到所有版本的数据。其中HEAD指向最新放入仓库的版本
• Remote：远程仓库，托管代码的服务器，可以简单的认为是你项目组中的一台电脑用于远程数据交换

本地的三个区域确切的说应该是git仓库中HEAD指向的版本

• Directory：使用Git管理的一个目录，也就是一个仓库，包含我们的工作空间和Git的管理空间。
• WorkSpace：需要通过Git进行版本控制的目录和文件，这些目录和文件组成了工作空间。
• .git：存放Git管理信息的目录，初始化仓库的时候自动创建。
• Index/Stage：暂存区，或者叫待提交更新区，在提交进入repo之前，我们可以把所有的更新放在暂存区。
• Local Repo：本地仓库，一个存放在本地的版本库；HEAD会只是当前的开发分支（branch）。
• Stash：隐藏，是一个工作状态保存栈，用于保存/恢复WorkSpace中的临时状态。

2.2、工作流程

git的工作流程一般是这样的：

１、在工作目录中添加、修改文件；

２、将需要进行版本管理的文件放入暂存区域；

３、将暂存区域的文件提交到git仓库。

因此，git管理的文件有三种状态：已修改（modified）,已暂存（staged）,已提交(committed)

2.3、图解教程

个人认为Git的原理相比别的版本控制器还是复杂一些的，有一份图解教程比较直观：

图解教程英文原版

图解教程中文版

二、Git常用命令

git diff                # 对比工作区和本地仓库
git diff --cached # 对比缓存区和本地仓库
git log               # 查看当前版本之前所有的提交记录
git reflog           # 查看所有的提交记录
git log -n 2        # 显示最近几条数据
git log -p          # 对比每提交的差异
git log --format="%an:%ae:%s" # 自定义输出格式
git reset --hard 版本号        # 回滚到指定版本
git chekout --file            # 将文件回滚到最近的一次提交 
git status                    # 查看状态
git reset HEAD file           # 将指定的文件从缓存区拉取到工作区

# 工作区必须有变动
# 保存开发状态
git stash  # 快照
git stash pop # 恢复并删除快照
git stash list # 查看所有快照
git stash apply stash{id} # 恢复指定快照
git stash drop # 删除快照

git branch  # 查看分支
git branch dev # 创建dev分支
git checkout dev # 切换到dev分支
git branch -d dev # 删除分支
git checkout -b dev1 # 创建分支并切换分支

# 合并分支,在合并到的分支上执行
git merge dev  # 在master主分支上执行，(将dev的代码合并到master)

# 冲突
# 不同的分支在对同一行代码进行修改,在代码合并时会发生冲突
"""
1、合并时间不能太长,一般2-3天合并一次
2、完成一个小功能合并一次
3、合并的时候所有人都要在
"""

# 克隆分支
git checkout -b dev origin/dev [指定以origin/dev为模板创建一个分支

# 删除远程仓库的分支
git checkout --delete origin

# tag
git tag  # 查看标签
git tag -a name -m '提交信息'
git tag -a name -m '提交信息' hash值 # 以哈希值为模板创建一个标签tag
git tag -d name   # 删除本地tag
git push origin :refs/tags/v0.5  # 删除远程仓木的tag(给远程仓库推送了一个空的tag

# 忽略文件
# 把不想上传的文件写在.gitignore文件中
vim .gitignore
    - db.py

# rebase
变基 将提交记录变成一条直线

# 切换git用户
git config --global --unset user.name "xxx"
git config --global --unset user.email "xxx"

三、Git冲突怎么引起的，怎么解决

1、git冲突的场景

• 情景一：多个分支代码合并到一个分支时；
• 情景二：多个分支向同一个远端分支推送代码时；

实际上，push操作即是将本地代码merge到远端库分支上。关于push和pull其实就分别是用本地分支合并到远程分支 和 将远程分支合并到本地分支，所以这两个过程中也可能存在冲突。

git的合并中产生冲突的具体情况：
　　<1>两个分支中修改了同一个文件（不管什么地方）
　　<2>两个分支中修改了同一个文件的名称
两个分支中分别修改了不同文件中的部分，不会产生冲突，可以直接将两部分合并。

2、冲突解决方法

• 情景一：在当前分支上，直接修改冲突代码--->add--->commit。
• 情景二：在本地当前分支上，修改冲突代码--->add--->commit--->push

 注：借用vim或者IDE或者直接找到冲突文件，修改。

3、实战演示

（1）情景

本地库中两个不同分支，修改同一个文件同一代码块，两分支先后将修改合并到master分支上，master在合并第二个分支代码时，报错：合并冲突。

（2）本地库

<1>master分支

<2>建立两个分支

<3>两分支修改提交

aBranch分支：

bBranch分支：

（3）合并分支产生冲突

合并aBranch分支（将aBranch分支合并到当前master分支上）：

注：
git merge：默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向Develop分支。
使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，建议采用这种方法。

再合并bBranch分支，产生冲突：

mergeTest.txt 文件内容：

（4）解决冲突

--->在当前分支上（master），找到冲突文件，直接修改冲突代码，add，commit。

 注：简单方法，使用vim修改，cat查看冲突文件。（注意要删除git自动生成的冲突代码分隔符）

（5）完成冲突解决

注：提交或者合并都会生成git节点。每个节点对应一个代码版本

四、架构师职责：Git Flow规范团队git使用规程

虽然Git是非常优秀的的版本管理工具，但是我们面对版本管理的时候，依然有非常大得挑战，我们都知道大家工作在同一个仓库上，那么彼此的代码协作必然带来很多问题和挑战，如下：

1. 如何开始一个Feature的开发，而不影响别的Feature？
2. 由于很容易创建新分支，分支多了如何管理，时间久了，如何知道每个分支是干什么的？
3. 哪些分支已经合并回了主干？
4. 如何进行Release的管理？开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时候，开发人员可以继续开发新的功能？
5. 线上代码出Bug了，如何快速修复？而且修复的代码要包含到开发人员的分支以及下一个Release?

大部分开发人员现在使用Git就只是用三个甚至两个分支，一个是Master, 一个是Develop, 还有一个是基于Develop打得各种分支。这个在小项目规模的时候还勉强可以支撑，因为很多人做项目就只有一个Release, 但是人员一多，而且项目周期一长就会出现各种问题。

1、Git Flow

就像代码需要代码规范一样，代码管理同样需要一个清晰的流程和规范。

2、Git Flow常用的分支

• Production 分支

也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改

• Develop 分支

这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支

• Feature 分支

这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release

• Release分支

当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支

• Hotfix分支

当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release

3、Git Flow如何工作

初始分支

所有在Master分支上的Commit应该Tag

Feature 分支

分支名 feature/*

Feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支，但是我们也可以保留

Release分支

分支名 release/*

Release分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)

发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。

维护分支 Hotfix

分支名 hotfix/*

hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag

Git Flow代码示例

a. 创建develop分支

git branch develop
git push -u origin develop    

b. 开始新Feature开发

git checkout -b some-feature develop
# Optionally, push branch to origin:
git push -u origin some-feature    

# 做一些改动    
git status
git add some-file
git commit    

c. 完成Feature

git pull origin develop
git checkout develop
git merge --no-ff some-feature
git push origin develop

git branch -d some-feature

# If you pushed branch to origin:
git push origin --delete some-feature    

d. 开始Relase

git checkout -b release-0.1.0 develop

# Optional: Bump version number, commit
# Prepare release, commit

e. 完成Release

git checkout master
git merge --no-ff release-0.1.0
git push

git checkout develop
git merge --no-ff release-0.1.0
git push

git branch -d release-0.1.0

# If you pushed branch to origin:
git push origin --delete release-0.1.0   


git tag -a v0.1.0 master
git push --tags

f. 开始Hotfix

git checkout -b hotfix-0.1.1 master    

g. 完成Hotfix

git checkout master
git merge --no-ff hotfix-0.1.1
git push


git checkout develop
git merge --no-ff hotfix-0.1.1
git push

git branch -d hotfix-0.1.1

git tag -a v0.1.1 master
git push --tags

4、Git flow工具

实际上，当你理解了上面的流程后，你完全不用使用工具，但是实际上我们大部分人很多命令就是记不住呀，流程就是记不住呀，肿么办呢？

总有聪明的人创造好的工具给大家用, 那就是Git flow script.

安装

• OS X

brew install git-flow

• Linux

apt-get install git-flow

• Windows

wget -q -O - --no-check-certificate https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | bash

使用

• 初始化: git flow init

• 开始新Feature: git flow feature start MYFEATURE

• Publish一个Feature(也就是push到远程): git flow feature publish MYFEATURE

• 获取Publish的Feature: git flow feature pull origin MYFEATURE

• 完成一个Feature: git flow feature finish MYFEATURE

• 开始一个Release: git flow release start RELEASE [BASE]

• Publish一个Release: git flow release publish RELEASE

• 发布Release: git flow release finish RELEASE
  别忘了git push --tags

• 开始一个Hotfix: git flow hotfix start VERSION [BASENAME]

• 发布一个Hotfix: git flow hotfix finish VERSION