1. 初始设置
- 设置姓名和邮箱
$ git config --global user.name "zhutx"
$ git config --global user.email "16530202@qq.com"
- 提高命令输出的可读性
$ git config --global color.ui auto
会在"~/.gitconfig"中输出
[user]
name = zhutx
email = 16530202@qq.com
[color]
ui = auto
2. Git操作
2.1. Git基本操作
- git init---初始化仓库
$ mkdir git-tutorial
$ cd git-tutorial
$ git init
Initialized empty Git repository in D:/Program Files/Git/git-tutorial/.git/
git status---查看仓库状态
git add---添加文件到暂存区
git commit---提交修改
git commit -m "First commit"git log---查看提交日志
git log --pretty=short 只查看提交简短信息，轻松把握多个提交
git log README.md 指定目录或文件，查看具体目录或文件的提交只
git log -p README.md 查看提交日志及提交前后的差别
git log --graph 以图表形式输出提交日志，非常直观。可以清楚的看到分支的提交和合并git diff---查看更改前后的差别
git diff 查看当前和暂存区的差别
git diff -HEAD 查看当前和末次提交的差别（提交前最好养成这个好习惯）
2.2. Git分支操作
- git branch---浏览分支
- git checkout -b---创建并切换分支
$ git checkout -b feature-A
# 等同于
$ git branch feature-A
$ git checkout feature-A
# 分支修订后，回到master主干分支进行合并
$ git checkout -
- git merge---合并分支
$ git merge --no-ff feature-A
2.3. 更改提交的操作
- git reset---回溯历史版本
# 回溯到feature-A分支创建之前，创建一个名为fix-B的特性分支
# 先通过图表方式，把提交图表show出来，找出创建feature-A分支之前的commit的hash
$ git log --graph
# 然后我们就可以回溯到这个版本了
$ git reset --hard fd0cbf
# 然后就可以创建新分支了
$ git checkout -b fix-B
- git reflog---查看当前仓库执行过的操作日志
这个命令很有用。即便开发者错误执行了Git操作，基本也可以利用git reflog命令恢复到原先的状态
# git log只能查看以当前状态为终点的历史日志。如果我们的目标是要将fix-B的修改合并到已经合并了feature-A分支修改的master上，那么就可以用下面的命令查找出hash
$ git reflog
# 找到feature-A特性分支合并后的状态的hash值，恢复到这个状态
$ git reset --hard 83b094
# 合并fix-B分支的修改
$ git merge --no-ff fix-B
# 如果有冲突，编辑冲突后执行git add和git commit
- git commit --amend---修改上一次提交信息
2.4. 推送至远程仓库
先在GitHub上创建同名仓库。创建时不要勾选Initialize this repository with a README。因为一旦勾选，GitHub的仓库就会自动生成README文件，从而创建之初便于本地仓库失去了整合性。
# 将GitHub上创建的仓库设置成本地仓库的远程仓库。远程仓库的名称设置为origin（标识符）
$ git remote add origin git@github.com:zhutx/git-tutorial.git
- git push---推送至远程仓库
# 将本地仓库的master主干分支内容，推送至远程仓库的同名分支下
# -u参数可以在推送的同事，将origin仓库的master分支设置为本地仓库当前分支的upstream（上游）。添加了这个参数，将来运行git pull命令从远程获取内容时，本地仓库的这个分支就可以直接从origin的master分支获取内容，省去了另外添加参数的麻烦。
$ git push -u origin master
# 本地其他分支也可以这么推送给远程仓库分支
$ git push -u origin feature-D
# 现在，远程仓库的GitHub页面可以看到feature-D分支了。
2.5. 从远程仓库获取
- git clone---获取远程仓库
$ git clone git@github.com:zhutx/git-tutorial.git
# 同时查看本地仓库和远程仓库的分支信息
$ git branch -a
# 获取远程仓库的feature-D分支（即
以origin/feature-D作为来源，创建本地feature-D分支）
$ git checkout -b feature-D origin/feature-D
# 本地对feature-D进行相关修订后，用push推送
$ git push
- git pull--获取最新的远程仓库分支
2.6. 仓库的维护
Fork或clone来的仓库，一旦放置不管就会离最新的源代码越来越远。如果不以最新的源代码为基础进行开发，劳神费力地编写代码也很可能是白费力气。通常来说clone来的仓库实际上与原仓库没有任何关系。所以我们需要将原仓库设置为远程仓库，从该仓库fetch数据与本地仓库merge，让本地仓库的源代码保持最新状态。
# 比如我们在GitHub上fork了octocat/Spoon-Knife仓库，然后clone
$ git clone git@github.com:hirocastest/Spoon-Knife.git
$ cd Spoon-Knife
# 我们给原仓库设置upstream名称，将其作为远程仓库
$ git remote add upstream git://github.com/octocat/Spoon-Knife.git
# 从远程仓库获取最新数据
$ git fetch upstream
# 将upstream/master分支与当前分支合并
$ git merge upstream/master
3. GitHub
3.1. 设置SSH Key
使用https url克隆对初学者来说会比较方便，复制https url 然后到 git Bash 里面直接用clone命令克隆到本地就好了。而使用 SSH url 克隆却需要在克隆之前先配置和添加好 SSH key 。因此，如果你想要使用 SSH url 克隆的话，你必须是这个项目的拥有者。否则你是无法添加 SSH key 的。https url 在push的时候是需要验证用户名和密码的；而 SSH 在push的时候，是不需要输入用户名的，如果配置SSH key的时候设置了密码，则需要输入密码的，否则直接是不需要输入密码的。
# 先检查是否已有SSH Key
$ cd ~/.ssh
$ ls
# 不存在则创建SSH Key
$ ssh-keygen -t rsa -C "16530202@qq.com"
# 存在id_rsa id_rsa.pub文件，说明已生成过SSH Key了，直接复制公钥内容
clip < id_rsa.pub
在GitHub的设置中将SSH Key添加起来，验证一下通过本地私钥与GitHub进行认证和通信
$ ssh -T git@github.com
键入密码后，输出以下内容，说明SSH Key配置成功
Hi zhutx! You've successfully authenticated, but GitHub does not provide shell access.
3.2. Pull Request
3.3. 协作工具---Jekins（P162，待补充）
3.4. GitHub Flow---以部署为中心的开发模式
利用GitHub进行软件开发，想必会以下面的流程进行Pull Request
在GitHub上进行Fork
将1的仓库clone至本地开发环境
在本地环境中创建特性分支
对特性分支进行代码修改并进行提交
将特性分支push到1的仓库中
在GitHub上对Fork来源仓库发送Pull Request
在无法给不特定的多数人赋予提交权限的公开软件开发中，这种流程能够防止仓库收到计划之外的提交。
然而在企业开发中，开发者每天见面，经常相互发送Pull Request就显得有些繁琐了。
GitHub Flow，是一个以部署为中心的开发流程。在实际开发中往往1天内会实施几十次部署，而支撑这一切的，就是足够简单的开发流程以及完全的自动化。
GitHub Flow的流程
令master分支时常保持可部署状态
进行新作业时要从master分支创建新分支，新分支名称要具有描述性
在2新建的本地仓库分支中进行提交
在GitHub端仓库创建同名分支，定期push
需要帮助或反馈时创建Pull Request，以Pull Request进行交流
让其他开发者进行审查，确认作业完成后与master分支合并
与master分支合并后立刻部署
-
随时部署，没有发布的概念
这个流程必须遵循“令master分支随时保持可以部署的状态”这一规则
-
部署作业完全自动化
这一流程在一天当中需要多次部署，陈旧的开发模式按部署文档进行部署会浪费相当多的时间。需要选择一款web自动化部署工具,如Webistrano、Strano和Webhooks等
-
重视测试
让测试自动化，开发者必须提交测试代码。push到远程仓库后，Jekins等CI工具自动对齐进行测试。
