基于 Git 版本管理的多人协作项目的详细操作

基于 Git 版本管理的多人协作项目的详细操作

      • 1. 添加协作伙伴
      • 2. IDEA-Git 操作
      • 3. 被邀请的协作者操作
      • 4. 公共仓库账号合并代码
      • 5. (测过OK)将 dev 分支合并到 master 主分支
      • 6. 最高频坑:代码冲突

基于 Git 版本管理的多人协作项目的详细操作_第1张图片

整体流程:

Git 公共仓库账号 → 邀请协作伙伴 → 协作伙伴都同意。

Git 公共仓库账号 → 搭好项目架子上传 → Git链接 → 作为基础代码可以被 被邀请者 pull(拉) 到本地。

Git 公共仓库账号 → 创建 dev 分支 → push 远程仓库(即上传,此时 dev 分支代码同 master 代码)

协作者 → IDEA登陆 Git → 打开Git链接 → Fork到自己仓库 → IDEA创建以自己仓库链接为源码的项目

协作者 → 更新代码 → Add → Commit → Commit Message(必填)

协作者 → dev分支 → Push 推送 → 页面操作创建 pull request

Git 公共仓库账号 → 收到新的 pull request → review 代码没问题(相当于过了测试阶段) → Merge(默认合并到主分支)

1. 添加协作伙伴

先注册一个公共 Git 账号,创建公共仓库,用于存放代码、更新项目代码。

该公共仓库所属账号,邀请所有协作伙伴(多个),伙伴均同意成为伙伴。

基于 Git 版本管理的多人协作项目的详细操作_第2张图片

基于 Git 版本管理的多人协作项目的详细操作_第3张图片

基于 Git 版本管理的多人协作项目的详细操作_第4张图片

邮件里点击按钮,进入页面直接同意邀请即可。

基于 Git 版本管理的多人协作项目的详细操作_第5张图片

2. IDEA-Git 操作

公共仓库账号需要操作的是:将基础架子代码上传。名称不变,描述信息要写。

  • 推主分支上一份 基础的架子 代码。

基于 Git 版本管理的多人协作项目的详细操作_第6张图片

基于 Git 版本管理的多人协作项目的详细操作_第7张图片

基于 Git 版本管理的多人协作项目的详细操作_第8张图片

  • 创建 dev 分支

基于 Git 版本管理的多人协作项目的详细操作_第9张图片

Ctrl + Shift + ` >> Git >> 操作分支,将 dev 分支推到远程仓库。

基于 Git 版本管理的多人协作项目的详细操作_第10张图片

远程仓库中可以看到 dev 分支代码(截止目前 dev 和 master 主分支代码相同)。

基于 Git 版本管理的多人协作项目的详细操作_第11张图片

3. 被邀请的协作者操作

  • 准备工作:需要协作开发的人员在 IDEA 中登陆自己的 Git 账号。

其他所有被邀请者登陆自己的账号,登陆之后才能进行相关的 pull(拉) 和 push(推) 代码的操作,切记不能使用 公共仓库的账号直接推库(会影响所有被邀请者的本地代码提交->冲突)。

基于 Git 版本管理的多人协作项目的详细操作_第12张图片

  • 打开公共仓库的 git 地址,Fork 一份到自己仓库中

基于 Git 版本管理的多人协作项目的详细操作_第13张图片

  • 然后使用自己仓库中 fork 下来的代码的 git 路径创建工程

基于 Git 版本管理的多人协作项目的详细操作_第14张图片

基于 Git 版本管理的多人协作项目的详细操作_第15张图片

  • 右下角,切换到 dev 分支,进行代码更新和上库

image-20200713204615352

基于 Git 版本管理的多人协作项目的详细操作_第16张图片

  • 更新上库步骤三步走:Add(添加到暂存库) → Commit(提交到本地仓库) → Push(推送的远程仓库)

要求:必须填写 commit message!不填不予合并!

基于 Git 版本管理的多人协作项目的详细操作_第17张图片

image-20200713205707122

分支推送才算真正的推送成功:遇到 TimeOut 超时错误提示,不用怕,网络问题,继续 Push即可。

基于 Git 版本管理的多人协作项目的详细操作_第18张图片

基于 Git 版本管理的多人协作项目的详细操作_第19张图片

image-20200713210155223

看到上面这句,恭喜你,已经推送到 分支 成功了!

  • 然后,提交 pull request (才能被 公共仓库 账号合并到主分支,测试、发布上线)

基于 Git 版本管理的多人协作项目的详细操作_第20张图片

如果看不到 Compare & pull request 按钮的提示,那么做如下操作也是一样:

基于 Git 版本管理的多人协作项目的详细操作_第21张图片

基于 Git 版本管理的多人协作项目的详细操作_第22张图片

4. 公共仓库账号合并代码

收到新的 pull request(1)

基于 Git 版本管理的多人协作项目的详细操作_第23张图片

基于 Git 版本管理的多人协作项目的详细操作_第24张图片

基于 Git 版本管理的多人协作项目的详细操作_第25张图片

基于 Git 版本管理的多人协作项目的详细操作_第26张图片

基于 Git 版本管理的多人协作项目的详细操作_第27张图片

基于 Git 版本管理的多人协作项目的详细操作_第28张图片

5. (测过OK)将 dev 分支合并到 master 主分支

公共仓库账号需要的操作:

基于 Git 版本管理的多人协作项目的详细操作_第29张图片

基于 Git 版本管理的多人协作项目的详细操作_第30张图片

基于 Git 版本管理的多人协作项目的详细操作_第31张图片

基于 Git 版本管理的多人协作项目的详细操作_第32张图片

基于 Git 版本管理的多人协作项目的详细操作_第33张图片

继续 Merge 即可。

image-20200713213737265

6. 最高频坑:代码冲突

项目组 n 个人共同协作开发公司项目,项目的代码版本从 01 版本开始迭代。(01是什么意思?如图)

基于 Git 版本管理的多人协作项目的详细操作_第34张图片

第一天,A B C 三个程序猿一大早就从Git链接创建了工程,开始写自己部分的代码。

假定 A 写登陆注册、B写购物车、C写列表页详情页等,都是写后台 API 接口

早上拉下来的代码,大家都是一样的 01 版本(即 commit id,非项目自定义版本号)。

临近下班时,A 写完了自己的功能,add→commit→push了代码,测试测过了,主管 merge 了代码,此时 Git 的版本号即 commit id 已经变为了 02 了。

那么问题来了:B 和 C 的代码是基于早上拉下来的 01 写的,B与C不论谁再次提交都会冲突且无法提交!

解决办法:

[B写好的代码 1份] → 合并 → [git clone xxx.git 为 02 版本的代码一份]

Beyond Compare 代码对比工具,将 B 写好的代码合并到基于 02 版本(与库上一致)后,通过 git bash 命令行进行 Push 操作。

(B提交后,dev 分支版本变为 03,然后 C 需要重复 B 的操作,基于 03 开始合代码提交,这是必然且必须的

基于 Git 版本管理的多人协作项目的详细操作_第35张图片

# git config --global user.name "xxx"
# git config --global user.email "xxx"
git add filename  # 【添加】到暂存库(==内存)
git commit -m "commit message"  # 【提交】到本地仓库(==硬盘)
git push origin dev  # 【推送】到远程 dev 分支(==远端服务器)

基于 Git 版本管理的多人协作项目的详细操作_第36张图片

GitHub 提 pull request,公共仓库账号查看并合并 pull request 里的代码到 dev,测试拉取 dev 分支最新代码进行测试,测试OK后,公共仓库账号再将 dev 直接合并到 master,作为正式版本发布上线。

你可能感兴趣的:(GitHub,git,java,github,svn)