[关闭]
@gabe 2017-02-20T13:58:27.000000Z 字数 3798 阅读 2167

git的一些常用高层命令

原文链接


git config

git log

git status

git stage, git add

git checkout

git reset

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

diff, patch是*nix系统的工具

git diff, git apply

git format-patch, 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分支

cherry-pick

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

git的一些底层命令

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注