背景描述
Centos 7/RedFlag 7/Asianux 7 上的 Git 版本太陈旧,在使用过程中会遇到问题,比如不支持目录分支(release/v01 这种格式会在检出的时候报错),因此需要升级 Git 版本。
安装依赖包
源代码安装和编译git,需安装一些依赖。
Centos 7/RedFlag 7/Asianux 7 上的 Git 版本太陈旧,在使用过程中会遇到问题,比如不支持目录分支(release/v01 这种格式会在检出的时候报错),因此需要升级 Git 版本。
源代码安装和编译git,需安装一些依赖。
当前git是大部分开发团队的首选版本管理工具,一个好的流程规范可以让大家有效地合作,像流水线一样有条不紊地进行团队协作。
业界包含三种flow:
当在团队开发中使用版本控制系统时,商定一个统一的工作流程是至关重要的。Git 的确可以在各个方面做很多事情,然而,如果在你的团队中还没有能形成一个特定有效的工作流程,那么混乱就将是不可避免的。
基本上你可以定义一个完全适合你自己项目的工作流程,或者使用一个别人定义好的。
在这章节中我们将一起学习一个当前非常流行的工作流程 git-flow。
一旦安装安装 git-flow,你将会拥有一些扩展命令。这些命令会在一个预定义的顺序下自动执行多个操作。是的,这就是我们的工作流程!
git-flow 并不是要替代 Git,它仅仅是非常聪明有效地把标准的 Git 命令用脚本组合了起来。
严格来讲,你并不需要安装什么特别的东西就可以使用 git-flow 工作流程。你只需要了解,哪些工作流程是由哪些单独的任务所组成的,并且附带上正确的参数,以及在一个正确的顺序下简单执行那些对应的 Git 命令就可以了。当然,如果你使用 git-flow 脚本就会更加方便了,你就不需要把这些命令和顺序都记在脑子里。
最新的git bash已经支持,不用安装,或者使用 Sourcetree。
要了解安装 git-flow 细节,请阅读下面这个文档 official documentation。
当你想把你的项目 “切换” 到 git-flow 上后,Git 还是可以像往常一样工作的。这完全是取决于你在仓库上使用特殊的 git-flow 命令或是普通的 Git 命令。换句话说,git-flow 它不会以任何一种戏剧性的方式来改变你的仓库。
话虽如此,git-flow 却存在一些限制。让我们开始在一个新的项目上初始化它吧,之后我们就会有所发现:
当在项目的根目录执行 “git flow init” 命令时(它是否已经包括了一个 Git 仓库并不重要),一个交互式安装助手将引导您完成这个初始化操作。听起来是不是有点炫,但实际上它只是在你的分支上配置了一些命名规则。
尽管如此,这个安装助手还是允许你使用自己喜欢的名字。我强烈建议你使用默认的命名机制,并且一步一步地确定下去。
git-flow 模式会预设两个主分支在仓库中:
这两个分支被称作为 长期分支。它们会存活在项目的整个生命周期中。而其他的分支,例如针对功能的分支,针对发行的分支,仅仅只是临时存在的。它们是根据需要来创建的,当它们完成了自己的任务之后就会被删除掉。
让我们开始探索一些在现实应用中可能遇到的案例吧!
对于一个开发人员来说,最平常的工作可能就是功能的开发。这就是为什么 git-flow 定义了很多对于功能开发的工作流程,从而来帮助你有组织地完成它。
让我们开始开发一个新功能 “rss-feed”:
概念
在这些命令的输出文本中,git-flow 会对刚刚完成的操作打印出一个很有帮助的概述
当你需要帮助的时候,你可以随时请求帮助。例如:
正如上面这个新功能一样,git-flow 会创建一个名为 “feature/rss-feed” 的分支(这个 “feature/” 前缀 是一个可配置的选项设置)。你已经知道了,在你做新功能开发时使用一个独立的分支是版本控制中最重要的规则之一。
git-flow 也会直接签出这个新的分支,这样你就可以直接进行工作了。
经过一段时间艰苦地工作和一系列的聪明提交,我们的新功能终于完成了:
最重要的是,这个 “feature finish” 命令会把我们的工作整合到主 “develop” 分支中去。在这里它需要等待:
之后,git-flow 也会进行清理操作。它会删除这个当下已经完成的功能分支,并且换到 “develop” 分支。
Release 管理是版本控制处理中的另外一个非常重要的话题。让我们来看看如何利用 git-flow 创建和发布 release。
当你认为现在在 “develop” 分支的代码已经是一个成熟的 release 版本时,这意味着:第一,它包括所有新的功能和必要的修复;第二,它已经被彻底的测试过了。如果上述两点都满足,那就是时候开始生成一个新的 release 了:
请注意,release 分支是使用版本号命名的。这是一个明智的选择,这个命名方案还有一个很好的附带功能,那就是当我们完成了release 后,git-flow 会适当地自动去标记那些 release 提交。
有了一个 release 分支,再完成针对 release 版本号的最后准备工作(如果项目里的某些文件需要记录版本号),并且进行最后的编辑。
现在是时候按下那个危险的红色按钮来完成我们的release了:
这个命令会完成如下一系列的操作:
从 Git 的角度来看,release 版本现在已经完成。依据你的设置,对 “master” 的提交可能已经触发了你所定义的部署流程,或者你可以通过手动部署,来让你的软件产品进入你的用户手中。
很多时候,仅仅在几个小时或几天之后,当对 release 版本作做全面测试时,可能就会发现一些小错误。
在这种情况下,git-flow 提供一个特定的 “hotfix” 工作流程(因为在这里不管使用 “功能” 分支流程,还是 “release” 分支流程都是不恰当的)。
这个命令会创建一个名为 “hotfix/missing-link” 的分支。因为这是对产品代码进行修复,所以这个 hotfix 分支是基于 “master” 分支。
这也是和 release 分支最明显的区别,release 分支都是基于 “develop” 分支的。因为你不应该在一个还不完全稳定的开发分支上对产品代码进行地修复。
就像 release 一样,修复这个错误当然也会直接影响到项目的版本号!
在把我们的修复提交到 hotfix 分支之后,就该去完成它了:
这个过程非常类似于发布一个 release 版本:
还是和产生 release 的流程一样,现在需要编译和部署你的产品(如果这些操作不是自动被触发的话)。
最后,在结束这个章节之前,我要再次强调几个重点。
首先,git-flow 并不会为 Git 扩展任何新的功能,它仅仅使用了脚本来捆绑了一系列 Git 命令来完成一些特定的工作流程。
其次,定义一个固定的工作流程会使得团队协作更加简单容易。无论是一个 “版本控制的新手” 还是 “Git 专家”,每一个人都知道如何来正确地完成某个任务。
记住,使用 git-flow 并不是必须的。当积攒了一定的使用经验后,很多团队会不再需要它了。当你能正确地理解工作流程的基本组成部分和目标的之后,你完全可以定义一个属于你自己的工作流程。
我们使用 Git Flow
来进行版本管理控制,它相对于 GitHub Flow
更适合在产品开发中快速迭代,这种代码管理模式应该已经广泛使用了。
另外,我们鼓励使用 Git 客户端 SourceTree
,它集成了 Git Flow 的一些基本操作。如果严格遵循 Git Flow 的流程进行版本管理控制,那么我们只用管开始和结束一个 Feature/Release/Hotfix
,基本上是不用手动 merge 分支的。
Pull Request是当功能开发者
完成一个新功能后向项目维护者
发送合并请求通知的机制。它的使用过程如下:
功能开发者
可以通过Gitlab页面发送pull request开发管理员
自己或组织其他的团队成员审查、讨论和修改代码开发管理员
合并新增功能分支到develop分支,然后关闭pull request,并且可以选择删除新增分支1. 由开发管理员
负责在Gitlab上创建空白的仓库,并clone到本地,在sourcetree的git flow菜单中选择初始化仓库,并push到远端。
2. 在Gitlab上设置保护分支,把master、develop分支保护起来,只有指定人可push。
3. 功能开发者
clone代码到本地,先在sourcetree的git flow菜单中选择初始化仓库。
4. 然后再开始新建功能分支,进行开发工作。
5. 新功能开发全部完成或部分完成后,功能开发者
把最新代码push到远端同样的新功能分支里,并在Gitflow发起pull request给开发管理员
6. 开发管理员
review代码,选择合并代码到develop,并可选择删除已经合并的新功能分支
7. 当开发管理员
处理完合并请求后,开发者,切换到develop分支,直接删除自己的本地分支及远程分支,不要点击完成(Finish Feature),此时开发者pull远端develop分支最新代码即可,可忽视本地的push提醒。
8. release、hotfix分支和feature分支操作类似。
9. 不可点击完成新功能、完成发布版本、完成修复补丁,因为这样会导致自动合并代码到master或develop分支
到此为止,我们发现整个的工作流还算可以接受,但是执行 git flow release 的时候,会发现由于 Git Flow 总是假定我们合并的分支可以立即部署到生产环境,所以如果我们的工作流程符合这个过程,是很简单的。
但是更多的时候,我们会遇到同时开发可功能模块A、B、C,最终上线只上线A、C的情况,这种情况下,会涉及到版本会退的问题,这个时候 git flow 反倒是不方便使用了。
这种情况下,GitLab Flow 流程可能更适合我们的工作流程。
创建的 .gitignore 文件无法提交到 git 上
在log
路径下创建了.gitignore
文件, 文件内容:
想着忽略当前文件夹的所有内容. 此时想将 .gitignore
文件提交上去, 运行git status
发现没有.gitignore
文件的变动.
于是想着可能没反应过来, 就直接提交吧, 运行命令: git add .gitignore
, 提示信息如下:
如此看来, 是我将这个文件忽略了, 运行命令检查是那里将其忽略了git check-ignore -v .gitignore
. 输出结果:
表明, 是在.gitignore
文件的第一行, 规则*
忽略了此文件.
吆西, 明白了, 解决方法也简单, 修改.gitignore
文件内容, 将此文件排除即可, 修改后的内容:
此时就可以正常提交。
Windows 下检出代码的时候报错:
前提: 在排除没有配置公钥的情况下。
Git > etc > ssh
文件夹下找到 ssh_config
文件windows git ssh 方式提示 no matching host key type found. Their offer: ssh-rsa,ssh-dss
这里就不再赘述关于SVN与Git的区别以及为什么要迁移源码到Git了,毕竟Git是当前的主流DVCS了,而且已经公认地非常好用,如果你还在使用SVN的话该考虑换了,是时候迁移那些遗留代码了,有兴趣可以参阅 Why Git 和 Perforce to Git 了解更多。
通常来说,在项目开发过程中,难免会遇到一些老项目代码正被SVN管理着,但基于当下诸多原因,或是扩展开发,或是战略转移,或是为了更好地开发体验,需要将这些在维护的遗留项目源码迁移为Git管理。
那如何有效地迁移源码?并且如何保留提交记录、分支记录以及开发成员等信息呢?笔者前一段时间就经历了这样的迁移工作,还是有必要分享一下,也算是一种总结了。
1. 下载源码
2. 设置git用户的邮箱和姓名
3. 修改文件后commit
4. 生成patch文件
5. 设置git的smtp参数
6. 发送邮件给development@lists.ipfire.org
输入ipfire-devel邮箱地址development@lists.ipfire.org, 回车两次就完成.
7.查看是否提交成功
发送邮件过一段时间后,在这里能查到https://lists.ipfire.org/mailman/listinfo/development,不同的模块有对应的邮件列表地址。
8.常见错误
测试中发现有时候 git apply 应用git format-patch创建的补丁文件的时候,可能报告如下错误:
也就是应用补丁的时候会失败,造成这种情况的原因一般是同一份代码配置了多个远程仓库导致的。
比如我同步了一份代码到自己的服务器上,这样就容易出现这种情况。
解决方法一般是克隆一份独立的代码,单独在这个独立的代码中创建代码补丁。
git 的钩子放在 git 项目下的 .git/hooks
目录。
如果我们所有项目都需要一个通用的钩子,那么我们需要在所有的项目中都放置钩子文件。挨个复制显然不是一个可行的方案。
我们可用模板目录来解决这个问题。
在 git init
或者 git clone
时,如果指定有模板目录,会使用拷贝模板目录下的文件到 .git/
目录下。
好了,那么解决方案就是:把统一的钩子文件放到模板目录,然后在 git init
/ git clone
时候指定模板目录?
不行,这样还是太麻烦了。
模板目录固定在一个地方,我们可以把模板目录写入全局配置。
在 git init
或者 git clone
时,会自动拷贝钩子文件到项目的钩子目录。 已有项目,执行 git init
重新初始化项目即可。
代码提交时候,自动格式化的参考代码如下:
使用的时候,简单的拷贝到.git/hooks
目录下,并重新命名为pre-commit
。然后执行:
这样,每次提交代码的时候,都会自动格式化代码了。
和其它版本控制系统一样,Git 能在特定的重要动作发生时触发自定义脚本。 有两组这样的钩子:客户端的和服务器端的。 客户端钩子由诸如提交和合并这样的操作所调用,而服务器端钩子作用于诸如接收被推送的提交这样的联网操作。 你可以随心所欲地运用这些钩子。
钩子都被存储在 Git 目录下的 hooks
子目录中。 也即绝大部分项目中的 .git/hooks
。 当你用 git init
初始化一个新版本库时,Git 默认会在这个目录中放置一些示例脚本。这些脚本除了本身可以被调用外,它们还透露了被触发时所传入的参数。 所有的示例都是 shell 脚本,其中一些还混杂了 Perl 代码,不过,任何正确命名的可执行脚本都可以正常使用 —— 你可以用 Ruby 或 Python,或其它语言编写它们。 这些示例的名字都是以 .sample
结尾,如果你想启用它们,得先移除这个后缀。
把一个正确命名且可执行的文件放入 Git 目录下的 hooks
子目录中,即可激活该钩子脚本。 这样一来,它就能被 Git 调用。 接下来,我们会讲解常用的钩子脚本类型。
客户端钩子分为很多种。 下面把它们分为:提交工作流钩子、电子邮件工作流钩子和其它钩子。
Note
|
需要注意的是,克隆某个版本库时,它的客户端钩子 并不 随同复制。 如果需要靠这些脚本来强制维持某种策略,建议你在服务器端实现这一功能。(请参照 使用强制策略的一个例子 中的例子。)
|
前四个钩子涉及提交的过程。
pre-commit
钩子在键入提交信息前运行。 它用于检查即将提交的快照,例如,检查是否有所遗漏,确保测试运行,以及核查代码。 如果该钩子以非零值退出,Git 将放弃此次提交,不过你可以用 git commit --no-verify
来绕过这个环节。 你可以利用该钩子,来检查代码风格是否一致(运行类似 lint
的程序)、尾随空白字符是否存在(自带的钩子就是这么做的),或新方法的文档是否适当。
prepare-commit-msg
钩子在启动提交信息编辑器之前,默认信息被创建之后运行。 它允许你编辑提交者所看到的默认信息。 该钩子接收一些选项:存有当前提交信息的文件的路径、提交类型和修补提交的提交的 SHA-1 校验。 它对一般的提交来说并没有什么用;然而对那些会自动产生默认信息的提交,如提交信息模板、合并提交、压缩提交和修订提交等非常实用。 你可以结合提交模板来使用它,动态地插入信息。
commit-msg
钩子接收一个参数,此参数即上文提到的,存有当前提交信息的临时文件的路径。 如果该钩子脚本以非零值退出,Git 将放弃提交,因此,可以用来在提交通过前验证项目状态或提交信息。 在本章的最后一节,我们将展示如何使用该钩子来核对提交信息是否遵循指定的模板。
post-commit
钩子在整个提交过程完成后运行。 它不接收任何参数,但你可以很容易地通过运行 git log -1 HEAD
来获得最后一次的提交信息。 该钩子一般用于通知之类的事情。
你可以给电子邮件工作流设置三个客户端钩子。 它们都是由 git am
命令调用的,因此如果你没有在你的工作流中用到这个命令,可以跳到下一节。 如果你需要通过电子邮件接收由 git format-patch
产生的补丁,这些钩子也许用得上。
第一个运行的钩子是 applypatch-msg
。 它接收单个参数:包含请求合并信息的临时文件的名字。 如果脚本返回非零值,Git 将放弃该补丁。 你可以用该脚本来确保提交信息符合格式,或直接用脚本修正格式错误。
下一个在 git am
运行期间被调用的是 pre-applypatch
。 有些难以理解的是,它正好运行于应用补丁 之后,产生提交之前,所以你可以用它在提交前检查快照。 你可以用这个脚本运行测试或检查工作区。 如果有什么遗漏,或测试未能通过,脚本会以非零值退出,中断 git am
的运行,这样补丁就不会被提交。
post-applypatch
运行于提交产生之后,是在 git am
运行期间最后被调用的钩子。 你可以用它把结果通知给一个小组或所拉取的补丁的作者。 但你没办法用它停止打补丁的过程。
pre-rebase
钩子运行于变基之前,以非零值退出可以中止变基的过程。 你可以使用这个钩子来禁止对已经推送的提交变基。 Git 自带的 pre-rebase
钩子示例就是这么做的,不过它所做的一些假设可能与你的工作流程不匹配。
post-rewrite
钩子被那些会替换提交记录的命令调用,比如 git commit --amend
和 git rebase
(不过不包括 git filter-branch
)。 它唯一的参数是触发重写的命令名,同时从标准输入中接受一系列重写的提交记录。 这个钩子的用途很大程度上跟 post-checkout
和 post-merge
差不多。
在 git checkout
成功运行后,post-checkout
钩子会被调用。你可以根据你的项目环境用它调整你的工作目录。 其中包括放入大的二进制文件、自动生成文档或进行其他类似这样的操作。
在 git merge
成功运行后,post-merge
钩子会被调用。 你可以用它恢复 Git 无法跟踪的工作区数据,比如权限数据。 这个钩子也可以用来验证某些在 Git 控制之外的文件是否存在,这样你就能在工作区改变时,把这些文件复制进来。
pre-push
钩子会在 git push
运行期间, 更新了远程引用但尚未传送对象时被调用。 它接受远程分支的名字和位置作为参数,同时从标准输入中读取一系列待更新的引用。 你可以在推送开始之前,用它验证对引用的更新操作(一个非零的退出码将终止推送过程)。
Git 的一些日常操作在运行时,偶尔会调用 git gc --auto
进行垃圾回收。 pre-auto-gc
钩子会在垃圾回收开始之前被调用,可以用它来提醒你现在要回收垃圾了,或者依情形判断是否要中断回收。
除了客户端钩子,作为系统管理员,你还可以使用若干服务器端的钩子对项目强制执行各种类型的策略。 这些钩子脚本在推送到服务器之前和之后运行。 推送到服务器前运行的钩子可以在任何时候以非零值退出,拒绝推送并给客户端返回错误消息,还可以依你所想设置足够复杂的推送策略。
pre-receive
处理来自客户端的推送操作时,最先被调用的脚本是 pre-receive
。 它从标准输入获取一系列被推送的引用。如果它以非零值退出,所有的推送内容都不会被接受。 你可以用这个钩子阻止对引用进行非快进(non-fast-forward)的更新,或者对该推送所修改的所有引用和文件进行访问控制。
update
update
脚本和 pre-receive
脚本十分类似,不同之处在于它会为每一个准备更新的分支各运行一次。 假如推送者同时向多个分支推送内容,pre-receive
只运行一次,相比之下 update
则会为每一个被推送的分支各运行一次。 它不会从标准输入读取内容,而是接受三个参数:引用的名字(分支),推送前的引用指向的内容的 SHA-1 值,以及用户准备推送的内容的 SHA-1 值。 如果 update 脚本以非零值退出,只有相应的那一个引用会被拒绝;其余的依然会被更新。
post-receive
post-receive
挂钩在整个过程完结以后运行,可以用来更新其他系统服务或者通知用户。 它接受与 pre-receive
相同的标准输入数据。 它的用途包括给某个邮件列表发信,通知持续集成(continous integration)的服务器,或者更新问题追踪系统(ticket-tracking system) —— 甚至可以通过分析提交信息来决定某个问题(ticket)是否应该被开启,修改或者关闭。 该脚本无法终止推送进程,不过客户端在它结束运行之前将保持连接状态,所以如果你想做其他操作需谨慎使用它,因为它将耗费你很长的一段时间。