Git 是什么？
Git 是一个分布式的代码管理容器，本地和远端都保有一份相同的代码。 Git 仓库主要是由是三部分组成：本地代码，缓存区，提交历史
Git 有哪些常规操作？
Git的常规操作你了解吗？那让我们来简单说说Git的简单操作吧！
克隆代码
?克隆远端代码
git clone + 远程库地址
?查看本地的代码状态
// 可以明确的呈现出本地仓库的状态
// 哪些文件发生改动，哪些文件已经提交到本机
// 以及一些操作指示。
git status
?同步远端分支变化
// 拉取指定分支的变化
git fetch origin master
// 拉取所有分支的变化
git fetch
// 拉取所有分支的变化，并且将远端不存在的分支同步移除【推荐】
git fetch -p
?同步远端代码变化。
// 都是先 git fetch，然后执行合并操作
// 不同的是，git pull 执行的是 git merge，git pull -r 执行的是git rebase
git pull origin master
git pull -r origin master
本地代码
首先我们要明确一个概念：就是每个 commit 都是一份完整的代码状态，用一个 commitID 来唯一标志。
从某个角度上来说，Git维护的就是一个commitID树，分别保存着不同状态下的代码。 所以你对代码的任何修改，最终都会反映到 commit 上面去。
?新增 commit
// 添加文件到缓存区，然后提交到本地仓库
git add files
git commit -m '提交备注'
?撤销 commit
// 会将提交记录回滚，代码不回滚
git reset b14bb52
// 会将提交记录和代码全部回滚
git reset --hard b14bb52
// 将部分代码文件回滚
git checkout -- files
?合并 commit 合并 commit，本质上合并两份不同状态下的代码。
// Git 提供了两种合并 commit 的方式
git merge master
git rebase master
?那么 git rebase 和 git merge 到底有什么区别呢？
merge是两个分支处理冲突后，新增一个 commit 追加到master上。 rebase是将someFeature分支上的commit记录追加到主分支上，值得注意的是，这个时候他的commit其实已经发生变化。
git merge 处理冲突更直接，而git rebase 能够保证清晰的 commit 记录。
合并 commit 的时候，通常会发生冲突。那么，这个时候我们可以做什么呢？首先全局搜索特殊字符比如<<<，找到需要处理的代码位置，然后认真分析应该保留哪一部分代码。
操作分支
所谓的分支其实就是一个指向 commitID 的指针，你可以去.git/refs/heads里去看看。通常情况下，我们建议分支至少能够明确的标记功能名称，如果能标记用户就更好了，比如qixiu/feature。
?查看分支
可以同时看到本地分支和远端分支，配合上前文介绍的git fetch -p可以第一时间查看到最新的分支信息。
?新增本地分支 其实就是创建一个指针指向某一个 commitID。
// git branch qixiu/feature + git checkout qixiu/feature
// 从当前分支新增一个新的分支qixiu/feature
// 一般情况下，我们应该从master或者其他稳定分支来新增分支
git checkout -b qixiu/feature // 新建分支
git checkout qixiu/feature // 切换分支
?删除本地分支 其实就是移除一个指向 commitID 的指针。
// 删除本地分支，如果本地还有未合并的代码，则不能删除
git branch -d qixiu/feature
// 强制删除本地分支
git branch -D qixiu/feature
?新增远端分支 通常情况下，我们是新建本地分支，然后更新到远端的方式来新增一个远端分支
git push origin qixiu/feature
?删除远端分支 同样，我们也是通过更新到远端的方式来删除一个远端分支
// 等同于git push origin -d qixiu/feaure
git push origin :qixiu/feature
最后我们来汇总一下平常用的比较多的操作，学会这些操作应付日常是没有问题啦~
git status // 查看本地代码状态
git add files // 添加代码到缓存区
git commit -m '提交内容的备注' // 提交代码到本地仓库
git checkout -b branchName // 不加-b就是普通切换分支
git fetch -p // 同步远端分支状态
git pull -r origin branchName // fetch远端代码到本地，并且以rebase的方式合并代码
git push origin branchName // 更新本地代码到远端
Git 有哪些比较好的实践？
Git 有一些成熟的开发流程，比较主流的有两种：基于功能分支的开发流程和GitFlow开发流程。如果是做比较简单的项目的话，前者会更好；如果是做比较复杂的大型项目，那么后者会更好哟！
基于功能分支的协作模式
基于功能分支的开发流程其实就是一句话：用分支来承载功能开发，开发结束之后就合并到 master 分支。 他的优点是能够保证master分支的整洁，同时还能让分支代码逻辑集中，也便于 CodeReview。
?从 master 切出一个新分支
git checkout -b qixiu/newFeature
?开发一些新功能，然后提交 建议较多频次的提交代码到本地仓库，以便能够更灵活的保存或撤销修改。
git status
git add files // 挑选需要提交的文件，或者全部提交
git commit -m '提交备注'
git push origin qixiu/newFeature
?如果功能开发完成，可以发起一个CodeReview流程 ，如果代码测试通过，合并到 master，然后准备上线
// 冗余版 合并到 master
git checkout master
git pull -r origin master
git checkout qixiu/newFeature
git rebase master // 处理冲突
git checkout master
git merge qixiu/newFeature
git push origin master
// 精简版 合并到 master
git checkout qixiu/newFeature
git pull -r origin master // 将master的代码更新下来，并且rebase处理冲突
git push origin master // 将本地代码更新到远端
注意！!不要在master合并代码，保证master的可用性很重要。 确保在正确的分支执行正确的操作。 无论是处理冲突还是更新远端代码，请保有敬畏之心。
分支命名规范
推荐使用如下格式：ownerName/featureName。这样既便于知道分支覆盖的功能，也便于找到分支的负责人。
GitFlow 比前文讲的基于功能分支的开发流程要复杂得多，它更适合大型的复杂项目。 它围绕项目发布流程定义了一个严格的分支模型，所有的开发流程都是围绕这个严格的分支模型进行。 而这个模型约定了每个分支的角色，以及他们如何沟通。
GitFlow 开发流程中几个约定的分支
?Master分支：用于存放线上版本代码，可以方便的给代码打版本号。
?Develop分支：用于整合 Feature 分支。
?Feature分支：某个功能的分支，从 Develop 分支切出，并且功能完成时又合并回 Develop 分支，不直接和 Master 分支交互。
?Release分支：通常对应一个迭代。将一个版本的功能全部合并到 Develop 分支之后，从 Develop 切出一个 Release 分支。这个分支不在追加新需求，可以完成 bug 修复、完善文档等工作。注意！代码发布后，需要将其合并到 Master 分支，同时也要合并到 Develop 分支。
?Hotfix分支：紧急修复的分支，是唯一可以从 Master 切出的分支，一旦修复了可以合并到 Master 分支和 Develop 分支。
从每个分支的功能和约定可以看出，它流程多约束多，对于小规模应用并不适合。 当然 GitFlow 有一些辅助工具 gitflow 可以自动化的完成这些任务，对于大型项目也很有帮助。