事倍功半是蠢蛋64 git协作

二、PyCharm 图形界面方式（最简单）

这是大多数人使用的方法。
关键原则：要合并到哪个分支，就先切到哪个分支。

你想合并 dev → test：

步骤 1：切换到 test 分支

右下角分支选择 → 点击 test → Checkout

步骤 2：执行 Merge

右下角 Git 分支菜单：

Git Branches → Merge into Current...


然后选择：

dev   （或者你的 dev-wzc-xxx）


点 OK。

步骤 3：推送 test

右上角点击 Push。

🧪 完整流程示例（PyCharm）

切到 test
👉 右下角 → 选择 test → Checkout

合并 dev
👉 右下角 → Merge into Current → 选 dev

推送 test
👉 右上角 Push

⚠️ 注意事项（非常重要）

千万不要在 dev 分支去点 “Merge test into current”
否则方向反了！

合并后的冲突（如果出现）只需按提示解决后提交即可。

251208

1.分支 
主分支        		master  
每个人的开发分支      dev  
测试分支    			test 
bug修复分支  		fix

2.分支产生策略/分支功能使用流程

分支产生策略:
主分支master   - 1个 默认存在
开发分支dev    - 多个 每个人在开发的时候独立产生
测试分支       - 1个 默认存在
bug修复分支  	  -	fix的时候按需产生


分支功能使用流程:
主分支master=>每个人拉取到自己的开发分支（多个）dev-XXX=>测试分支test(1个) 如果要返工 
就再merge到自己的dev分支，再推送到test分支反复， 直到功能完成，在每个人开发完成后
=>（评审会议的时候合并）主分支master  

主分支上出现bug了 对于某个或某几个bug 单独分出来一个bug修复分支（fix分支）
在修复完成后，合并到主分支当中，最后删除这个fix分支。

3.分支的命名：
master
test
dev-rfv-260101-no_chinese_use_and_no_space （不要使用中文） 
fix-260101-tapd_100064（tapd_100064这个暂定）

*主分支上的bug需要版本回退的时候 使用 git tag

*只要任何一个分支合并到了master主分支当中，其他分支就都应该merge一次。
*无论多紧急 也不能直接推送到master。
**需要预演一遍操作流程

咱们这个我又想出2个问题：

1.test分支出现 bug 后难以追踪到底是哪个功能导致（你说的是对的，test分支是不是应该改成多个，一个功能的错误卡死了可能其他人没法测了，还是说dev分支应该做好了再往test分支合？一周讨论了一下 他觉得如果每个人都有test分支，测试压力会很大，应该只有一个出口，他说的也有道理。
2.没讨论release，没有指定合并的人
但是咱们这个只是初版而且只讨论了半个小时，可以在开发试一把团队协作后再试一个版本。