1.命名以Android_项目名、IOS_项目名、后端直接使用项目名方式。
主分支（Master/Main）: 只用于生产环境。
开发分支（Develop）: 用于开发，所有新功能合并到这里。
功能分支（Feature）: 对于每个新功能，创建一个新分支，例如 feature/user-auth。
修复分支（Fix）: 用于修复bugs，例如 fix/login-issue。
发布分支（Release）: 准备发布的版本，允许最后时刻的修复，例如 release/v1.0。

2. 提交信息规范
提交信息应清晰、准确描述所做的更改。
使用简洁的标题行，后跟详细描述（如有必要）。
例如：
简洁版：Fix login form bug
详细版：
    css
    Copy code
    Fix login form bug
    
    - Adjust the API endpoint
    - Improve form validation

3. 合并请求（Merge Requests）/拉取请求（Pull Requests）
每个合并/拉取请求应只包含相关的更改。
提供详细的描述和更改理由。
在合并代码前进行代码审查。

4. 代码审查
代码审查是保证代码质量的关键。
审查者应检查代码的质量、性能和可读性。
强调建设性的反馈。

5. 标签使用
使用标签来标记发布版本。
遵循语义化版本命名，例如 v1.0.1。

6. 避免在公共历史中重写
不要使用 git push --force，除非在个人分支且确实必要。
公共分支的历史应该是干净且直接的。

7. 保持分支更新
定期从上游分支（如 develop 或 master）合并或变基以保持分支更新。

8. 处理冲突
及时解决合并冲突。
在合并之前，本地测试以确保更改没有引入任何问题。

9. 删除不再使用的分支
功能合并后，删除功能分支以保持仓库整洁。

10. 文档
保持文档更新，文档写在ReadMe中特别是关于如何设置和运行项目的文档。