7. 多人协作
7.1 Git代码提交规范
- 提交代码需仔细
review编写的所有代码 - 提交测试前需按照测试用例充分自测
- 多线程数据读写必须注意线程安全,该加锁的加锁,尽量使用线程安全的容器
- 同分支代码更新强制要求使用，
Rebase，，以保持分支整洁。推荐用，AndroidStudio，自带版本控制工具避免出错。 - 分支之间的合并应该使用，
Merge，，以保持有完整的合并记录。 - 避免低级空指针错误
- java代码对象使用需判空
- java调用kotlin定义的函数，传参需注意是否可为空
- 遵循，
Alibaba Code Guide，代码中尽不要出现拼写错误，IDE遇到错误单词会警告，如出现警告要及时纠正，避免代码阅读困难 Bugfix版本原则只能修改bug相关的内容，不允许随意增加需求或者修改内容，修bug要找出bug的真正原因，避免为了修bug而引入新的问题
8 解决冲突
解决冲突不建议使用自带的diff工具,我们可以使用AndroidStudio自带的工具或者使用ByondCompare来处理
9 版本回退
10. 换行符兼容
11 撤销修改
- 什么时候会用到
sourceTree（Git）的撤销修改
12 其他操作
13 Git企业分支清理基本原则
- 定期做删除无用分支操作.
release分支一律保留，但是前提是需要统一命名规范.- 已经
merge过的分支过一个月后可以删除. - 未
merge的分支过三个月征求分支创建者同意后可以删除.
- 对分支创建者的补充：
- A、如果是release/bugfix这样的公用分支，可以不带有个人属性名称.
- B、如果是个人功能这样的分支的创建，统一带需求ID名称，例如: 031004
- C、如果无法确认分支创建者，须在群里沟通以确认是否可以删除再做定夺（如无人认领分支，则由清理人员自行定夺是否删除）.
14 从SVN迁移到Git
- 从
SVN迁移到Git，不仅需要源代码迁移，同时我们还希望SVN上的commit信息也能迁移。这里我们使用Subgit工具。
- 自上次提交后，你对源文件做了很多修改，你想一步就退回到初始状态，就是上次提交之后的状态
15 Git 管理历史
15.1 本地版本控制系统
15.2 集中管理控制系统
15.3 分布式控制系统
16 Git 和其他SVN的区别
- 16.1 一个集中控制，一个分布式；近乎所有操作都是本地执行;
- 16.2 直接记录快照，而非差异比较;
- 16.3 Git分支使用非常方便；
- 16.4 Git 一般只添加数据;一旦你提交快照到 Git 中，就难以再丢失数据，特别是如果你定期的推送数据库到其它仓库的话;
17 Git 常用命令流程图
18 Git 文件状态
