Git实现项目版本管理与控制
Git命令
（1）拉取远程代码
git pull
（2）保存本地
使用 git add . 命令将想要快照的内容写入缓存区， 而执行 git commit 将缓存区内容添加到仓库中。
git add. //添加文件到暂存区
git commit -m'feat：功能开发等等注释' //将暂存区内容添加到仓库中,使用 -m 选项以在命令行中提供提交注释）
（3）提交代码(上传远程代码并合并)
git push
（4）拉取克隆项目
git clone + 网址
（5）git status（查看所在的分支）
git status //以查看在你上次提交之后是否有修改。
（6）切换到想要的分支
git checkout dev //（dev是目标的分支名称）
（7）创建+切换分支
git checkout -b
（8）合并某分支到当前分支
git merge
（9）删除分支
git branch -d
（10）查看分支
git branch -r; // --remotes只列出远程分支，本地分支不会显示
git branch -a; // --all: 查看所有分支，包含本地分支和远程分支
git branch -v; // --verbose: 查看本地分支及其对应的提交记录
（11）查看历史记录
git log;
git log --oneline; // 查看历史记录的简洁版本
（12）暂存代码模块
git stash save "XXX"
git stash save “XXX”（ 如果当前已修改了代码文件，发现需要进行版本回退，可以使用，将当前文件缓存）
-
git stash save "XXX"（能够将所有未提交的修改（工作区和暂存区）保存至堆栈中，用于后续恢复当前工作目录）
-
git stash pop/apply 将当前stash中的内容弹出，并应用到当前分支对应的工作目录上。
注：pop将堆栈中最近保存的内容删除（栈是先进后出）,aplly不会删除保存的内容 -
git stash apply + stash名字（如stash@{1}）指定恢复哪个stash到当前的工作目录。
-
git stash clear （清除堆栈中的所有 内容）
（13）回退代码
git reset
git reset 有三个参数：
-
--hard 会将代码回退到修改前的状态，就相当于上次拉完代码的状态。所有增加、修改、删除的内容都不在了。（这个操作要慎重）
-
--mixed 会将代码回退到修改后的状态，可以再次对代码增加、修改、删除，保存，添加到暂存区，提交到仓库区。
-
--soft 会将代码回退到暂存区，可以继续往前回退，也可以重新提交到仓库区。
（14）查看远程分支
git remote -v
（15）删除远程分支
git remote rm origin
（16）连接远程仓库
git remote add origin 仓库的地址
项目中的分支管理
实际开发中，一个仓库（一般只放一个项目）主要有两个主分支：master 和 develop 分支。这两个分支的生命周期是整个项目的周期。
我们可能使用的不同类型的分支对项目进行管理是：
-
master：这个分支最为稳定，这个分支表明项目处于可发布的状态。
-
develop：做为开发的分支，平行于master分支。
-
Feature branches
功能分支（或有时称为主题分支）用于为即将发布或遥远的未来版本开发新功能。在开始开发某个功能时，将包含该功能的目标版本在那时很可能是未知的。功能分支的本质在于，只要该功能处于开发阶段，它就存在，但最终会被合并回
develop（明确将新功能添加到即将发布的版本中）或丢弃。功能分支通常只存在于开发者仓库中，而不存在于origin，并且必须从develop分支建立，完成后合并回develop分支。 -
Release branches
发布分支支持准备新的生产版本。它们允许在最后一刻打点 i 和交叉 t。此外，它们允许修复小错误并为发布准备元数据（版本号、构建日期等）。通过在发布分支上完成所有这些工作，该
develop分支被清除以接收下一个大版本的功能。从
develop分支拉取，且必须合并回develop和master分支命名约定：release-*从develop分支建立，完成后合并回develop与master分支。这个分支上能够作一些很是小的bug修复，固然，你也能够禁止在这个分支作任何bug的修复工做，而只作版本发布的相关操做，例如设置版本号等操做，那样的话那些发现的小bug就必须放到下一个版本修复了。若是在这个分支上发现了大bug，那么也绝对不能在这个分支上改，须要Featrue分支上改，走正常的流程。 -
Hotfix
修补程序分支与发布分支非常相似，因为它们也旨在为新的生产版本做准备，尽管是计划外的。它们产生于需要立即对现场制作版本的不良状态采取行动。当必须立即解决生产版本中的关键错误时，可以从标记生产版本的主分支上的相应标记中分支出一个修补程序分支。
Hotfix分支必须从master分支建立，完成后合并回develop与master分支。这个分支主要是解决线上版本的紧急bug修复的，例如忽然版本V0.1上有一个致命bug，必须修复。那么咱们就能够从master 分支上发布这个版本那个时间点 例如 tag v0.1（通常代码发布后会及时在master上打tag），来建立一个 hotfix-v0.1.1的分支，而后在这个分支上改bug，而后发布新的版本。最后将代码合并回develop与master分支。
GitFlow 协同工作流
我们为什么需要GitFlow这种git管理流程？原因有以下几点
（1）有一个稳定版本的代码分支，可以安心的用在线上发布； （2） 在代码提测前或者说是代码达到预发状态时，在测试交付的过程中程序员们还可以继续进行下一个版本的开发工作； （3）有个一个分支可以让我们及时的对线上的bug进行修复，这个过程中我们不希望将正在开发中的代码提交到线上生产中去。
因此，git-flow 并不会为 Git 扩展任何新的功能，它仅仅使用了脚本来捆绑了一系列 Git 命令来完成一些特定的工作流程。其次，定义一个固定的工作流程会使得团队协作更加简单容易。无论是一个 “版本控制的新手” 还是 “Git 专家”，每一个人都知道如何来正确地完成某个任务。
在项目中设置git-flow
当你想把你的项目 “切换” 到 git-flow 上后，Git 还是可以像往常一样工作的。这完全是取决于你在仓库上使用特殊的 git-flow 命令或是普通的 Git 命令。换句话说，git-flow 它不会以任何一种戏剧性的方式来改变你的仓库。
（1）git-flow 模式会预设两个主分支在仓库中：
- master 只能用来包括产品代码。你不能直接工作在这个 master 分支上，而是在其他指定的，独立的特性分支中（这方面我们会马上谈到）。不直接提交改动到 master 分支上也是很多工作流程的一个共同的规则。
- develop 是你进行任何新的开发的基础分支。当你开始一个新的功能分支时，它将是_开发_的基础。另外，该分支也汇集所有已经完成的功能，并等待被整合到 master 分支中。
这两个分支被称为长期分支。他们会存活在项目中的整个生命周期。而其他分支，例如针对功能开发的分支，只是临时存在而已。功能开发结束后合并到develop上就随之被删除了。
（2）开发新功能的基本命令：
git flow feature start rss-feed //创建新的功能分支
git flow feature finish rss-feed //完成功能开发，并且整合到develop分支上
git flow feature help //当你需要帮助时，可以用这个随时请求帮助
"feature finish" 命令会把我们的工作整合到主 “develop” 分支中去。在这里它需要等待：
- 一个在更广泛的 “开发” 背景下的全面测试。
- 稍后和所有积攒在 “develop” 分支中的其它功能一起进行发布。
之后，git-flow 也会进行清理操作。它会删除这个当下已经完成的功能分支，并且换到 “develop” 分支。
（3）管理releases（是一本修复好bug的稳定版本，已经被彻底的测试过了）
release 分支都是基于 “develop” 分支的。因为你不应该在一个还不完全稳定的开发分支上对产品代码进行地修复
$ git flow release start 1.1.5 // 创建release
// Switched to a new branch 'release/1.1.5'
release是使用版本号命名的，当完成了release后，git-flow会适当的自动去标记那些release提交。
有了一个release分支，再完成针对release版本号的最后准备工作（如果项目里的某些文件需要记录版本号），并且进行最后的编辑
git flow release finish 1.1.5
/**
这个命令会完成如下一系列的操作：
1. 首先，git-flow 会拉取远程仓库，以确保目前是最新的版本。
2. 然后，release 的内容会被合并到 “master” 和 “develop” 两个分支中去，这样不仅产品代码为最新的版本，而且新的功能分支也将基于最新代码。
3. 为便于识别和做历史参考，release 提交会被标记上这个 release 的名字（在我们的例子里是 “1.1.5”）。
4. 清理操作，版本分支会被删除，并且回到 “develop”。
*/
（4）hotfix
对产品代码进行修复，所以这个 hotfix 分支是基于 “master” 分支。
git flow hotfix start missing-link
git flow hotfix finish missing-link
/**
这个过程非常类似于发布一个 release 版本：
1. 完成的改动会被合并到 “master” 中，同样也会合并到 “develop” 分支中，这样就可以确保这个错误不会再次出现在下一个 release 中。
2.个 hotfix 程序将被标记起来以便于参考。
3.这个 hotfix 分支将被删除，然后切换到 “develop” 分支上去。
还是和产生 release 的流程一样，现在需要编译和部署你的产品（如果这些操作不是自动被触发的话）。
*/
