Git笔记

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

1. 在GitHub上进行Fork

2. 将1的仓库clone至本地开发环境

3. 在本地环境中创建特性分支

4. 对特性分支进行代码修改并进行提交

5. 将特性分支push到1的仓库中

6. 在GitHub上对Fork来源仓库发送Pull Request

在无法给不特定的多数人赋予提交权限的公开软件开发中，这种流程能够防止仓库收到计划之外的提交。

然而在企业开发中，开发者每天见面，经常相互发送Pull Request就显得有些繁琐了。

GitHub Flow，是一个以部署为中心的开发流程。在实际开发中往往1天内会实施几十次部署，而支撑这一切的，就是足够简单的开发流程以及完全的自动化。

GitHub Flow的流程

1. 令master分支时常保持可部署状态

2. 进行新作业时要从master分支创建新分支，新分支名称要具有描述性

3. 在2新建的本地仓库分支中进行提交

4. 在GitHub端仓库创建同名分支，定期push

5. 需要帮助或反馈时创建Pull Request，以Pull Request进行交流

6. 让其他开发者进行审查，确认作业完成后与master分支合并

7. 与master分支合并后立刻部署

• 随时部署，没有发布的概念

  这个流程必须遵循“令master分支随时保持可以部署的状态”这一规则

• 部署作业完全自动化

  这一流程在一天当中需要多次部署，陈旧的开发模式按部署文档进行部署会浪费相当多的时间。需要选择一款web自动化部署工具,如Webistrano、Strano和Webhooks等

• 重视测试

  让测试自动化，开发者必须提交测试代码。push到远程仓库后，Jekins等CI工具自动对齐进行测试。