git的一些常用高层命令

git config

  • git config --system:系统配置
  • git config --global:全局配置
  • git config --local:本地配置
  • git config -e:编辑配置文件(可与--system, --global, --local组合使用)
  • git config --unset:删除某个配置
  • git config --get:显示某个配置的值
  • git config -l --list:列出所有配置
  • git config alias
  • git config push.default
  • git config pull.rebase

git log

  • git log --stat:简要显示增改行数统计
  • git log -p --patch:展开每次提交的差异
  • git log --name-status:显示新增、修改、删除的文件清单
  • git log --graph:以一些ASCII字符串表示的简单图形,形式地展示了每个提交所在分支及其分化衍合的过程
  • git log --oneline:以单行的简要方式显示log
  • git log --format=:格式化输出日志
  • git log --grep=:搜索匹配关键字的提交
  • git log --author=:过滤出对应作者的提交
  • git log --pretty=:[oneline, short, full, fuller, raw]
  • git log --since=:某个日期之后的提交
  • git log --until=:某个日期之前的提交

git status

  • git status -s:简化方式输出当前状态信息
  • git status --ignored:显示被忽略的文件

git stage, git add

  • git stage -a:暂存所有文件
  • git stage -u:暂存更新文件(包括删除)
  • git stage -i:以互动方式暂存文件
  • git stage -p:暂存文件的部分改动

git checkout

  • git checkout:汇总显示所有状态
  • git checkout path:对于path使用暂存区的内容覆盖工作区
  • git checkout commit -- path:对于path使用commit的内容覆盖工作区
  • git checkout branch:切换分支
  • git checkout -b branch [start-point]:以start-point创建新的分支branch(默认的start-point是HEAD)

git reset

  • git reset path [reset-point]:使用reset-point的内容覆盖暂存区
  • git reset --mixed [reset-point]:重置版本库的内容为reset-point,暂存区内容也被重置,工作区内容不变(git reset的默认动作)
  • git reset --soft [reset-point]:重置版本库的内容为reset-point,暂存区和工作区的内容都不改变
  • git reset --hard [reset-point]:重置版本库的内容为reset-point,暂存区和工作区的内容均被重置

一个神奇而有用的工具(diff&patch)

diff, patch是*nix系统的工具

  • diff用来对比两个文件的差异
  • patch可以看成是patch的反操作

git diff, git apply

  • 使用git diff和git apply本质上是git对diff, patch的一次再封装
  • 使用git diff生成补丁文件
  • 使用git apply应用补丁文件
  • git diff, git apply面向的补丁文件有一个实际意义上的标准,可以在不同的版本控制软件中交流使用

git format-patch, git am

  • 分别对应git diff, git apply的批量操作
  • 使用git format-patch可以对一批commit生成多个对应的补丁文件
  • 使用git send-mail可以将这些补丁文件发送给项目管理员
  • 项目管理员可以使用git am批量应用补丁
  • 实际上这就是开源软件一种工作流

修改提交历史

使用上一次提交历史git commit --amend

在上一次提交的基础上继续修改、删除、新增文件,提交时加上--amend选项,新提交的内容就会与上次提交的更新进行合并。也可以不做任何改动,直接使用git commit --amend来修改上次提交的说明信息

修改多次提交git rebase -i

git rebase -i [start-commit]..[end-commit]可以对指定范围内的提交进行合并、修改、切割等操作

注意:不管是git commit --amend还是git rebase -i,修改过的commit都会重新计算校验和,所以一定要注意不要去修改已经推送到公共版本库的提交,否则会引起人民群众的公愤。版本库管理员为了安全起见,也可以禁止使用--force选项进行推送,避免这种情况的发生

git的一些常用的工作流

集中式工作流

搭建一个中心版本库,所有成员从这个版本库里面克隆代码。
只使用一个分支master,所有提交均推送到这个分支。
所有成员设置pull.rebase为true,避免非快进式提交。
管理员在中心版本库配置receive.denyNonfastforwards为true,拒绝非快进式的推送。
这种工作流本质上是把git当成svn这种集中式版本控制系统来使用。

  • 优点:项目提交历史完全线性化,因此项目条理十分清晰,管理也十分简单
  • 缺点:模式过于简单,无法适应复杂的开发情景与多变的项目需求
  • 很少有项目只使用这种工作流,但这种工作流常常用来与其它工作流来配合使用

金字塔式工作流

项目有多个版本库,但有一个核心的、权威的版本库。
这个核心的版本库有一小批核心管理员,这些管理员有权限直接向核心版本库推送更新。
这个核心的版本库有一大批项目贡献者,每个贡献者者隶属于某个或某几个核心管理员,核心版本库对这些贡献者开放只读权限。
项目贡献者可以克隆核心库来创建自己的版本库,然后在此版本库上生成贡献代码,或通过pull requests,或通过send mail patch将贡献代码发给核心管理员
核心管理员在审核完贡献代码后,如果代码质量通过,管理员就会将贡献代码合并到核心库的某个分支上

  • 优点:结构灵活多变,可以从横向和纵向上来拓展工作流的结构,可以适应大型项目的复杂情景
  • 缺点:对核心管理员的要求极高
  • 几乎所有的大型开源项目都是使用这种工作流或这种工作流的变种

git-flow

搭建一个中心版本库,中心版本库保持一个长期的、稳定的分支。一般是master,也有项目是stable
中心版本库还会保持一个长期的、但经常更新的分支。一般分支名称是develop
平常情况下都是develop分支在演进,如果有某个特性需要开发,便从develop上分出一条分支feature/xxx。待特性基本开发完成后并入develop分支
如果要准备发布,可以从develop上分出一条分支release/xxx。后期所有和发布相关的提交均推送到这个release分支上。待release分支开发完成,并入develop和master分支。用master分支进行部署
如果生产环境发现紧急bug,从master上切出hotfix/xxx分支,修正后将该分支并入master和develop分支,必要时也并入release分支
定期清除一些过期的feature, release, hotfix分支

  • 优点:中心版本库的主分支只有两条,条理相较简单清晰,起码在人的能力控制范围内,项目成员可以直接参与项目贡献。同时,通过feature, release, hotfix三类分支的配合使用,也能适应复杂的情景
  • 缺点:工作流流程比较复杂,上手不是很容易,同时对项目成员的能力要求比较高。如果项目部署后,经常出现紧急bug,就要频繁的建立hotfix分支,甚至是release分支,一样会扰乱分支历史,难于管理。
  • 适用于小团队的项目开发管理,能适应项目成员能力平均和不平均的情景。同时,sourcetree这款git的图形界面软件也对这种工作流进行了一定程度的封装

cherry-pick

项目中心版本库维持多个长期支持分支,每个分支对应一个测试用例,即平常我们说的测服、真服
用于部署真服的分支一般是master,其它分支名字随意,假定部署测服的分支为develop
平常代码在develop上演进,每个提交必须基于一个主题,这个主题可以是一个特性、一个bug、一个模块、一个功能等等
每个主题必须要有一个唯一性标识,并且这个唯一性标识必须体现在提交说明上
在发布时基于要发布的主题,从develop上筛选出对应的提交,把这些提交分别并入master上,然后进行部署、测试、发布

  • 优点:中心版本库只有若干条主线,并且这些主线的提交历史是完全线性的。条理十分清晰。
  • 缺点:在开发分支的演进模式偏于简单,如果项目成员数过多,会有点适应不了。同时,对提交说明的书写要求很严格,如果漏掉说明,就很难基于主题定位到这个提交。这个可以通过git的钩子系统来检查
  • 这种工作流的单个分支上其实就是集中式工作流,适用于小团队的项目开发管理

git的一些底层命令

  • git rev-parse
  • git cat-file
  • git read-tree
  • git commit-tree
  • git ls-tree
  • git update-index
  • git update-ref
  • git hash-object
  • git reflog