Git技巧

虽然一直使用sourcetree,还是应该对git指令做一些了解的。本篇将列举使用中遇到的关于git的一些使用技巧。不定期更新。

自定义 git config

给自己的项目提交代码的时候,有些时候虽然提交成功,但是 github 提交记录的小绿块上并没有记录。这是因为你的项目可能有很多人能提交代码,github 区分不同的人需要靠提交代码的人的邮箱,而这个邮箱你可能没有配置或者配置错了。

比如 sourcetree 会有一个统一的配置:

也就是说所有使用 sourcetree 的提交,用户名和邮箱都是这个。但是如果你公司有另外一个 gitlab 的账号呢?还是使用这个账号的邮箱提交就不会记入你 gitlab 账号的提交记录上。所以你需要配置 git config。

配置非常简单:

1
2
$ git config user.name "zachary"
$ git config user.email 759740844@qq.com

git rm

ios中pod的第三方库经常会被gitignore掉,让使用者自己下载。

想要达到一个效果:使文件脱离git的版本管理,但不是会删除它.

使用命令行

可以使用git rm --cached file
Git 将不再跟踪此文件,尽管它仍然是在您的硬盘上.
对于文件夹,可以使用git rm -r --cached file取消关联整个文件夹。

使用sourcetree

在sourcetree中操作要麻烦一些。在添加完gitignore后,将想要ignore的文件移出git目录,然后commit该操作,再将文件移回来。这个时候文件就被ignore了。

需要注意的是,一定要先执行commit操作。因为,在.git中存在了pod的版本控制的文件关联,添加了gitignore后,git并不会主动将pod文件关联删掉。
因此,需要先用commit将该文件关联删除,才能正确ignore该文件夹。

总结

这里的移除相当于执行了 rm 文件的操作,因而需要使用commit,而使用命令行的git rm 文件则是通过git指令,直接移除了关联。

git add

不管是什么项目总是需要添加新文件的。添加新文件即add,但是从github上clone的框架总是不能自动添加到本地的git版本里。可能是由于clone的框架本生带有.git的缘故吧。

因此,如果当git不能自动添加文件关联的时候,需要使用git add 文件的方式手动添加。

使用sourcetree时,也可以将要添加的部分先保存在其他地方,然后将文件夹内的文件复制到想要放的地方。这样隐藏的.git不会被复制,文件也就能添加进sourcetree了。

merge

merge可以说是很常用的一个功能,用于代码合并。只要是关乎于不同branch的代码进行合并都可以用merge啊

合并分支

merge 有一个名词叫“快进式合并”,合并的时候会直接将会直接将一个分支分支指向另一个分支:
fast-merge
但是有的时候,为了保证版本演进的清晰,我们希望在合并的分支上生成一个新节点表示做过合并操作,就要采用“非快进式合并”:
no-fast-merge
那么在 sourcetree 怎么做呢?勾选“无论是否可以快进更新都创建新的提交”
select
最后提交合并的记录即可:
commit

临时性分支

除了Master和Develop。前者用于正式发布,后者用于日常开发。其实,常设分支只需要这两条就够了,不需要其他了。

但是,除了常设分支以外,还有一些临时性分支,用于应对一些特定目的的版本开发。临时性分支主要有三种:

  • 功能(feature)分支
  • 预发布(release)分支
  • 修补bug(fixbug)分支

这三种分支都属于临时性需要,使用完以后,应该删除,使得代码库的常设分支始终只有Master和Develop。

功能分支,它是为了开发某种特定功能,从Develop分支上面分出来的。开发完成后,要再并入Develop。

预发布分支,它是指发布正式版本之前(即合并到Master分支之前),我们可能需要有一个预发布的版本进行测试。预发布分支是从Develop分支上面分出来的,预发布结束以后,必须合并进Develop和Master分支。

软件正式发布以后,难免会出现bug。这时就需要创建一个分支,进行bug修补。修补bug分支是从Master分支上面分出来的。修补结束以后,再合并进Master和Develop分支。

几种分支的命名方式分别为 feature-*,release-*,fixbug-* 的形式。

rebase

变基操作是git常用的一个功能,这里不再说明其作用,而是强调一下他的风险。

变基操作的一条准则是:不要对在你的仓库外有副本的分支执行变基

变基操作的实质是丢弃一些现有的提交,然后相应地新建一些内容一样但实际上不同的提交。

也就是说:变基操作将强行改变仓库的提交情况。注意,是丢弃不是删除,git对于这种丢弃没有任何记录。

如下图所示,C5是其他分支的合并。先将master重置到C1的提交,然后rebaseC5所在分支,得到新的提交C4'。一般情况下,git是不允许这样的提交到remote的,但是可以使用git push --force强制覆盖remote的仓库。这样C4 C6就不复存在了。
git_rebase_1

话分两头,别人也有自己的本地master,并且别人已经合并了之前的提交C6C7,如下图所示:
git_rebase_2

由于别人的本地git并不知道C4 C6已经由于rebase被删除。比对仓库信息后,在它看来,就是remote的master有了一个新的提交C4',于是就拉取,但是本地git一看远端提交C4'和本地提交C4 C6都修改了相同的文件,那就产生冲突了啊。那么别人就必须要合并这两条提交历史的内容,生成一个新的合并提交,最终仓库会如图所示:
git_rebase_3

这样就比较尴尬了,因为当时使用rebase就是为了删掉C4 C6,但是别人这么一合并一提交,C4 C6又全回来了。

如果只是单人开发,变基操作没有任何危险,想怎么变怎么变。但是在多人开发,切记只把变基命令当作是在推送前清理提交使之整洁的工具,并且只在从未推送至共用仓库的提交上执行变基命令。假如你在那些已经被推送至共用仓库的提交上执行变基命令,并因此丢弃了一些别人的开发所基于的提交,那么问题就大了。

sourcetree 无法看到提交记录

点击 sourcetree 中提交记录,可以看到详细的提交信息。但是有些时候点击提交项的时候看不到详细的提交信息。

可以在终端内输入以下命令,然后重启 sourcetree 解决:

1
defaults delete com.torusknot.SourceTreeNotMAS "NSSplitView Subview Frames repowindow_LogViewDescSplitter"

commit message 规范

基本规范

第一行为对改动的简要总结,建议长度不超过 50 个字符,用语采用命令式而非过去式。第一行结尾不要留句号。第一个单词的第一个字母要大写。

第二行为空行。

第三行开始,是对改动的详细介绍,可以是多行内容,建议每行长度不超过 72 个字符。主要用来写明白为什么要这样改

避免注释不清晰。比如只有「修正 BUG」、「改错」、「升级」、「添加某文件」等,没有其他内容,等于没说。 6.「提交」的概念是具有独立的功能、修正等作用。小可以小到只修改一行,大可以到改动很多文件,但划分的标准不变,一个提交就是解决一个问题的。

注意,每次提交之后一定是要能正常运行的。不能把不能通过编译的代码提交上去。

主要前缀

  • Add 新加入的需求
  • Fix 修正bug
  • Change 修改功能
  • Update 完成任务或者模块后的更新
  • Remove 移除功能
  • Refactor 重构功能

思路

有些时候发现不知道该如何写。那么遵循 what-why-how 的形式。写第一行的时候问自己这个 commit 是做了什么事,后面详细写清楚为什么这么做和怎么做到的。