文中内容部分参考来源：《GitHub 入门与实践》——【日】大塚弘记

使用 Git 会给开发带来哪些变化？

Git 的出现使得当今世界的软件开发带来了翻天覆地的变化。此前大部分的协同工作软件逐渐退出历史舞台，Git 工作流上位，变革了团队开发的协作方式。

能看到更多其他团队的软件

Git 并不局限于开发团队内部使用，只需要将仓库添加 watch ，就可以跟踪项目进度，看到别的团队每天都在开发什么功能。如果可以，你还可以进一步交流，分割公用的库，或者参与到项目开发，相互优化，成了不同开发者团队间协作的美谈。

社会化编程（Social Coding）

Git 的出现，为开源世界带来了社会化编程的概念，软件开发者因此拥有了真正意义上的源代码，世界上任何人都可以比以前更加容易的获取源代码，将其自由更改并加以公开。

在 类似 GitHub 的平台出现之前，软件开发中只有一小部分人拥有更改源代码的权利，这个特权阶级掌握着开发的主导权。开发者在改写、发布源代码之外，往往需要花更多时间和精力去说服这个特权阶级。这导致了许多起初效率很高的流行软件越发保守化，最终被时代所抛弃。

但是，GitHub 的出现为软件开发者的世界带来了真正意义上的“民主”，让所有人都平等地拥有了更改源代码的权利。这在软件开发领域是一场巨大的革命。而革命领导者 GitHub 的口号便是“社会化编程”。

为什么需要社会化编程

当今的 IT 业界已经没有了终身雇佣制，人才流动性日益增大。可以说，每个月我们都能在一些著名开发者的博客中看到这种现象： 月末刚发布“辞职了”的消息，月初就又“入职了”。

您是程序员的面试官，两者之间您会选择哪一位呢？

能查看到以前所写代码的程序员 or 无法查看的程序员 精通最新软件的程序员 or 不精通的程序员 对语言或软件差异带来的不同文化有所理解的程序员 or 不理解的程序员

为了不成为后一种程序员，理解社会化编程至关重要。

除了 Git 三连，实际工作中还有哪些常用操作

如果你平时使用命令行提交代码，那么一定很熟悉 Git 三连：

git add . // 向暂存区添加文件

git commit -m 'xxx' // 保存仓库历史记录

git push // 推送更改到远程
复制代码

git log--查看历史提交日志

git log命令可以查看以往仓库中提交的日志， 包括可以查看什么人在什么时候进行了提交或合并，以及操作前后有怎样的差别。

只显示提交信息的第一行：

git log --pretty=short
复制代码

显示文件的改动：

git log <file>
复制代码

查看文件更改前后的差别：

git diff
复制代码

git branch--显示分支一览表

branch 命令可以将分之名以列表的形式展示，同时可以确认当前所在的分支名

查看远程分支列表：

git branch -a
复制代码

git checkout--创建、切换分支，放弃本地修改

checkout 命令在分支操作上经常使用，同时支持本地文件的操作

创建并切换到新分支：

git checkout <branch> // 切换到分支

git chekcout - // 切换到上一次使用的分支

git checkout -b <branch> // 创建并切换
复制代码

放弃某个文件的修改：

git checkout <file>

git checkout . // 放弃所有文件修改
复制代码

git reset--回退历史版本

Git 的另一特征便是可以灵活操作历史版本。借助分散仓库的优势，可以在不影响其他仓库的前提下对历史版本进行操作。

回退到某个历史提交：

git reset <commit> // 回退到某个版本，不回退文件
git reset --hard <commit> // 回退到某个版本，并回退文件
复制代码

git merge--合并分支

当开发到一定程度后，需要将开发分支的代码合并到测试或者主干分支，这时候，需要用到 merge 命令。

git merge <branch> // 合并某个分支到当前分支
复制代码

git pull 的时候，发生了什么？

很多人不理解 Git 的拉取pull和获取fetch的区别，其实当执行 git pull 的时候，经历了两个步骤，一个是获取fetch，并自动合并merge

而获取则支持单纯的执行fetch，并不会自动合并。

如下例子：

git fetch origin master:temp //从远程仓库 master 获取，并建立本地分支 temp

git diff temp //对比修改

git merge temp //合并tmp
复制代码

修改了文件，突然发现分支不对，怎么办？

有时候当我们修改了文件后发现，分支忘了切回开发分支了，除了笨笨的复制文件，然后切换回正确分支，再恢复代码，还有更好的操作吗？

执行 git stash 暂存修改到缓存后，切换到正确分支，并将修改出栈：

git stash // 暂存修改

git checkout <branch> // 切换分支

git stash pop // 将修改出栈（恢复）
复制代码

Git分支管理规范

master 主分支

作为正式环境分支（稳定版），只读，不可修改，可被merge 正式服务器应当切换为此分支

release 预发布分支

作为验收环境分支，不可修改，可被merge 验收或正式服务器上线前应当切换为此分支

develop 测试分支

作为测试环境分支，可修改，可被merge 测试服务器应当切换为此分支

feature/ 开发（功能）分支

作为开发环境分支，本地开发和开发服务器应当切换为此分支

hotfix/ 修复BUG分支

作为修复BUG分支，应从线上或测试分支拉取一个hotfix分支，BUG解决后merge到测试或线上分支

Git工作流模型推荐