写在前面：
你好，欢迎关注！
- 我热爱技术，热爱分享，热爱生活， 我始终相信：技术是开源的，知识是共享的！
- 博客里面的内容大部分均为原创，是自己日常的学习记录和总结，便于自己在后面的时间里回顾，当然也是希望可以分享自己的知识。目前的内容几乎是基础知识和技术入门，如果你觉得还可以的话不妨关注一下，我们共同进步！
- 个人除了分享博客之外，也喜欢看书，写一点日常杂文和心情分享，如果你感兴趣，也可以关注关注！
- 公众号：傲骄鹿先生
部分内容转自： https://www.cnblogs.com/best/p/7474442.html
目录
前言
本文不对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是非常优秀的的版本管理工具，但是我们面对版本管理的时候，依然有非常大得挑战，我们都知道大家工作在同一个仓库上，那么彼此的代码协作必然带来很多问题和挑战，如下：
- 如何开始一个Feature的开发，而不影响别的Feature？
- 由于很容易创建新分支，分支多了如何管理，时间久了，如何知道每个分支是干什么的？
- 哪些分支已经合并回了主干？
- 如何进行Release的管理？开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时候，开发人员可以继续开发新的功能？
- 线上代码出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
