Tutorial of Git for PhD with no CS Background
基础知识
网络上的大量的教程供学习，先去搜索学习一段时间（2天）后再来看这个教程。
基本概念
（不一定精确）
Git 是代码管理的核心工具，通过命令行调用，完成所有的版本控制工作。
有很多 GUI 界面的工具可以提供更方便的操作形式，即鼠标点击，来完成大部分常用的版本控制工作。
所有的 GUI 本质上都是相同的，各有千秋，哪个最好只是玄学问题。
通常，掌握一个软件，即可很容易地掌握其它软件。
这里，我使用 SourceTree，因为它免费，跨平台，易学习。
This post will summarize how to use Git, based my experience, from a non-programmer viewpoint.
这篇文章里讲的，大部分都不是正统的软件工程中的代码管理方法，有很多地方都不符合标准的、安全的、合理的操作流程。 对于非编程专业出身的人，做理论工程研究，需要进行很多代码操作的人，本文比较合适。 有一定操作经验之后，推荐找更加专业的素材进行更深入的学习。 最好的素材应该就是官方文档和手册。
一些科研中的应用场景
调参
需要对参数进行调整，进行不同仿真时，每次调整前备份代码，找到一个比较好的值时备份代码，这样可以避免发现无生无法重现数据的问题。
重构、改进代码
在软件开发中，是要写测试文件的，这部分与开发算法和功能同样重要，甚至更重要。 简单讲，测试是指每次修改后的代码，要符合一些在测试文件中指定的输入输出。 如果有哪个测试不符合，则说明在修改过程中对代码的功能产生了影响，需要重新检查。 如果所有测试都顺利通过，也只能说明很大可能没有引入明显的错误，因为测试文件不是完备有。 也正因此，需要在改进代码的过程中，不断地添加补充测试文件。
但是，搞科研（非CS）的人，我很少见有写测试文件的。 我自己尝试过几次，都放弃了。 总体来讲，原因有几个：
- 科研注重的是结果的正确性、可重现性，不是完备性和兼容性。 所以很多时候过程中的代码已经天翻地覆，但是我只要求结果是正确的即可，对过程中发生的不严谨的地方，不是很在意。 这样的话，写测试文件就会变成一个巨大的负担。
技术问题
Fork 后继续更新源 repository
思路：
- 自己的本地repo与自己的远程repo同步，远程的叫
origin。 - 给自己的本地repo，添加与源repo同步的能力，这个源repo被称为
upstream。 origin和upstream的代码可以在本地被分别提取，然后进行各种操作，然后再把操作后的branch推送到相应的远程repo。- 远程的
origin应该不知道有upstream的存在。
为什么要这样做？ 因为这是逻辑上几乎唯一不会导致混乱，可溯源可追踪的方式，在目前Git的框架下。
【教程完】
（以下是个人使用笔记，不是教程）
.gitignore 的写法
具体参考官方文档的说明。
每次查每次忘，因为这个东西不是经常写的东西，很难一次记死。
总体来讲，文件的逻辑符合正常的思维习惯，只要注意一些特殊的约定即可：
- 井号
#开头是备注，复杂逻辑一定写好备注。 - 空格是换行，复杂逻辑一定用换行分块。
- 同一文件中，多条匹配的规则中，只有最后一条，起作用。
- 对
repo中已经包含的文件，不起作用。如果想要删除，需要手动取消跟踪（How?）。 !用来取反一条规则。用于要包含特定文件，比如先用\*排队所有文件，再用!\include.txt来包含某个或某些文件。- 要包含某个文件，先要保证它的所在目录没有被排除（符合直观逻辑）。（It is not possible to re-include a file if a parent directory of that file is excluded.）
- 规则最好用
/开头，因为/a/*.txt只匹配当前根目录（即/）下的a/*.txt，但是a/*.txt匹配所有最终以之结尾的文件，比如/arbitrary_folder/a/*.txt。 *匹配除/外任意字符，**匹配任意字符（包含/所以可以配置任意路径），?匹配任意一个字符（少用）- 文件名中一些特殊字符需要用
\转义，最好避免使用，比如：空格,\,\!, .gitignore可以存在很多地方，不要乱写乱放。
一些语法自洽的官方例子：
**/foo等价于foo，匹配任意位置的文件夹foo或者文件foo。
配到更复杂的需求，及时 google。