Git笔记

作者: 珍珠林 | 来源:发表于2016-11-09 09:31 被阅读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基本操作

  • 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工具自动对齐进行测试。

相关文章

网友评论

      本文标题:Git笔记

      本文链接:https://www.haomeiwen.com/subject/yumzuttx.html