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

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

配置非常简单：

1
2

$ git config user.name "zachary"
$ git config user.email [email protected]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

话分两头，别人也有自己的本地master，并且别人已经合并了之前的提交 C6 到 C7 ，如下图所示：

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

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

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

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

1

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

第二行为空行。

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

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

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