Git笔记

2016-11-09  本文已影响0人  珍珠林

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基本操作


$ mkdir git-tutorial

$ cd git-tutorial

$ git init

Initialized empty Git repository in D:/Program Files/Git/git-tutorial/.git/

2.2. Git分支操作

$ git checkout -b feature-A
# 等同于
$ git branch feature-A
$ git checkout feature-A
# 分支修订后，回到master主干分支进行合并
$ git checkout -

$ git merge --no-ff feature-A

2.3. 更改提交的操作

# 回溯到feature-A分支创建之前，创建一个名为fix-B的特性分支
# 先通过图表方式，把提交图表show出来，找出创建feature-A分支之前的commit的hash
$ git log --graph
# 然后我们就可以回溯到这个版本了
$ git reset --hard fd0cbf

# 然后就可以创建新分支了

$ git checkout -b fix-B

这个命令很有用。即便开发者错误执行了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

2.4. 推送至远程仓库

先在GitHub上创建同名仓库。创建时不要勾选Initialize this repository with a README。因为一旦勾选，GitHub的仓库就会自动生成README文件，从而创建之初便于本地仓库失去了整合性。


# 将GitHub上创建的仓库设置成本地仓库的远程仓库。远程仓库的名称设置为origin（标识符）

$ git remote add origin git@github.com:zhutx/git-tutorial.git



# 将本地仓库的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@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

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分支合并后立刻部署

上一篇下一篇

猜你喜欢

热点阅读