策略

主线开发，使用主线开发策略可以大幅度降低集成成本。

统一软件版本

建议在项目开始时更新软件到最新版本，然后设置更新计划，如半年一次，这样可以享受到软件更新带来的新功能、性能提升，同时又维持较长时间的稳定。

  • Git
  • Git LFS

工作流

先提交后拉取

为了保留文件的所有改动，一定要先提交。只要提交后文件就会进入 Git 仓库中。就算之后出现任何问题，也可以通过 git reflog 快速恢复。

但是如果先提交，那么拉取时就会产生合并提交，可以参考下面的方案解决。

准备

建议在做操作时保证工作目录与暂存区是干净的，这样可以在出现任何问题时都能恢复现场。

保持干净的方法有几种：

  1. 将使用的文件提交
  2. 将不用的文件丢弃
  3. 将不属于自己修改的文件丢弃
  4. 将有用但暂时不提交的文件储藏

注意：可以将未追踪的文件暂存后再储藏

  1. 强烈建议使用提交，因为提交会将文件及其当时对应的父提交状态保存。
  2. 储藏只会保存文件的改动，并不会记录父提交状态，导致应用在不同父提交时出现冲突，无法完整取出储藏的内容。

维护要求

  1. 所有人需要保证工作目录中要么是干净的，要么是只有自己的文件。
  2. 当出现不认识的文件时，可以点击查看历史，然后让最后一次修改的人去处理。
  3. 处理完成后需要马上提交推送，其他人拉取更新后恢复工作目录到正常状态。

减少无用合并提交

之前在 使用 Git 管理 Unity 项目 - 狂飙 中已经介绍了减少无用合并提交的思路与方法，最终确定的方案是本地修改拉取默认的行为：

1
2

git config pull.rebase true
git config rebase.autoStash true

在本地有提交时，通过将拉取默认的行为由合并改为变基，拉取后可以让提交的历史变成一条直线，非常简洁。

解决变基时遇到的冲突

在对团队成员进行培训时需要强调这一点：

Sourcetree 中拉取后遇到冲突，需要手动处理冲突。处理完冲突后需要再次点击拉取按钮，选择继续变基，变基完成后才整个过程算结束。

冲突的解决方案：

修改 - 文件同时被双方修改了

  • 选择一个修改的版本，“暂存”

删除 - 文件被某一方删除了

  • 选择是否删除，不删除的话“暂存”，删除的话“移除”

注意：由于使用了变基，那么拉取后解决冲突的方案就完全变了：原来是我们的版本是指本地修改的版本，现在是指远程修改的版本，他们的版本同理。

操作中断

一定要记得所有的操作都有对应的中断命令，如果未正确执行中断命令就继续工作的话，很有可能在后续处理中丢失数据。

  1. 在变基中需要 git rebase --abort 中断变基
  2. 在合并中需要 git merge --abort 中断合并
  3. 在拣选中需要 git cherry-pick --abort 中断拣选

杂项

文件名大小写修改方法

  1. 剪切文件到临时目录中，在 Sourcetree 中暂存删除的文件。
  2. 将临时目录中文件的文件名大小写修改正确。
  3. 剪切临时目录中的文件到原来位置，在 Sourcetree 中暂存添加的文件。

最后看到的效果即是暂存区中文件处于改名的状态，然后提交即可。

操作有时无法完成

Windows 系统中，如果有进程打开了某个文件，那么其他进程对此文件进行的操作都会被拒绝。有进程占用 Git 仓库中使用的文件时，要关闭对应的程序再进行 Git 操作。

因此当有 Excel、Word、Photoshop、Maya 之类的程序打开文件时，更新中包含对应文件的修改时，拉取更新会失败。

在某些情况下，由于无法找到占用文件的进程，可以尝试重启机器。