Open fayeah opened 4 years ago
现在的项目有一个特殊的情况,就是今年因为疫情,石油公司业务下滑严重,导致许多项目都停了;并且之前因为一个安全事故导致客户损失严重,所以客户爸爸做了一个决定不允许我们在外部连接VPN,只能在VDI里面访问代码仓库、TFS等等。 那么在这样一种“严峻”的情况下,我们如何进行开发工作呢?
首先,GIT是一个版本控制工具,能够使团队便捷地获取和更新代码。一般情况下,我们使用git pull/git pull --rebase/"git push"等命令即可完成我们想要的更新。
git pull
git pull --rebase
但是我们现在的情况是在VDI以外的环境都不可以访问内网。那么目前看来有两种方式:
在虚拟机里面进行开发工作。但是一般来讲虚拟机配置比较简单,只有基本的git环境和zoom等办公工具。再加上访问虚拟机本身需要花费时间成本,所以难以满足在虚拟机里面配置开发环境的需求。
手动更新/merge代码,这个也是我们现在协作的一种方式。分为两个部分,一个是从远端拉取最新代码,另外一个是将本地的代码更新到远端。
aaa
如果需要在某个区间打patch:git format-patch aaa..bbb,bbb的change也是会打出。 step3: 将打好的patch进行压缩(zip文件),然后通过邮件发送给自己,下载之后进行解压缩。 step4: 更新本地的代码,注意这个时候要特别小心,因为很有可能会有冲突,但是不管有没有冲突,冲突 的解决我们最后说。更新:
git format-patch aaa..bbb
bbb
git format-patch
git am C:\path\aaa.patch
),不支持。没错就是 一个一个patch去更新。 step5:如果没有冲突,完美。就可以直接执行push操作了,
世界上没有冲突该多好啊,但是不存在的,特别是长时间没有更新之后 冲突更多,那么手动更新代码如何解决冲突呢?
当运行git am *.patch的时候发现有以下这样 的错误,那么就是冲突来了,注意红色箭头 部分 :
git am *.patch
当有冲突的时候,找到是哪一个patch的冲突,然后运行git apply --reject vvv.patch,这里我们假设vvv.patch是冲突的那个patch,会生成一个以rej结尾的文件: 该文件的位置就在需要解决的冲突的后面,所以如果用idea打开就很方便解决冲突,具体如何解决就不说了,基本上是该删的删,该加的加,该修改的修改。 rej的内容大概长这个样子:
git apply --reject vvv.patch
rej
解决好 冲突之后,需要将rej文件删掉:rm /path/*.rej;
rm /path/*.rej
然后运行git add .,将解决好的文件添加到git的暂存区;
git add .
最后 运行git am --continue;
git am --continue
至此一个冲突解决完毕,保不准后面会接着有冲突,那就再继续按照上述 的步骤解决。知道没有冲突为止。
这个就是我们没办法自己在本地电脑checkin/checkout 代码带来的成本,一个星期大概花2-3个小时的时间更新代码,因为我们共有4个repository。后端其实相对还好,主要是前端冲突比较多。
其实我们这个项目是马上就要结束, 如果业务模块比较多,可以考虑不同的团队分开做,这样的话冲突也会少一些。另外一个团队 也为我们考虑了很多,他们利用分支策略,几天merge一次到master,一开始我们觉得还不错,但是时间久了发现,该merge的还是要merge只不过时间节点靠后了。
如果可以不要有这种情况了。
现在的项目有一个特殊的情况,就是今年因为疫情,石油公司业务下滑严重,导致许多项目都停了;并且之前因为一个安全事故导致客户损失严重,所以客户爸爸做了一个决定不允许我们在外部连接VPN,只能在VDI里面访问代码仓库、TFS等等。 那么在这样一种“严峻”的情况下,我们如何进行开发工作呢?
首先,GIT是一个版本控制工具,能够使团队便捷地获取和更新代码。一般情况下,我们使用
git pull
/git pull --rebase
/"git push"等命令即可完成我们想要的更新。但是我们现在的情况是在VDI以外的环境都不可以访问内网。那么目前看来有两种方式:
在虚拟机里面进行开发工作。但是一般来讲虚拟机配置比较简单,只有基本的git环境和zoom等办公工具。再加上访问虚拟机本身需要花费时间成本,所以难以满足在虚拟机里面配置开发环境的需求。
手动更新/merge代码,这个也是我们现在协作的一种方式。分为两个部分,一个是从远端拉取最新代码,另外一个是将本地的代码更新到远端。
aaa
,那么在VDI里面开始的索引就是aaa
,前开后闭的原则。如果需要在某个区间打patch:
git format-patch aaa..bbb
,bbb
的change也是会打出。 step3: 将打好的patch进行压缩(zip文件),然后通过邮件发送给自己,下载之后进行解压缩。 step4: 更新本地的代码,注意这个时候要特别小心,因为很有可能会有冲突,但是不管有没有冲突,冲突 的解决我们最后说。更新:git format-patch
; step2: 不知道为啥压缩之后VDI里面的outlook收不到邮件,所以我不压缩,直接将patch发送给自己; step3: 在VDI里面更新远端的代码,保证VDI里面的代码是最新的,git pull
; step4: 更新好代码之后,将补丁打到VDI里面去:git am C:\path\aaa.patch
。注意windows里面不能使用的方式去apply(`git am C:\path\.patch),不支持。没错就是 一个一个patch去更新。 step5:如果没有冲突,完美。就可以直接执行push操作了,
git push`。但是他们这个安全要求真的很高,我每次push都必须要填写自己的账号和token,否则没办法push,这里要提醒token一定要存到某个地方,邮件发给自己最保险了,否则不知道哪一天就丢了。世界上没有冲突该多好啊,但是不存在的,特别是长时间没有更新之后 冲突更多,那么手动更新代码如何解决冲突呢?
解决冲突
当运行
git am *.patch
的时候发现有以下这样 的错误,那么就是冲突来了,注意红色箭头 部分 :当有冲突的时候,找到是哪一个patch的冲突,然后运行
git apply --reject vvv.patch
,这里我们假设vvv.patch是冲突的那个patch,会生成一个以rej
结尾的文件: 该文件的位置就在需要解决的冲突的后面,所以如果用idea打开就很方便解决冲突,具体如何解决就不说了,基本上是该删的删,该加的加,该修改的修改。rej
的内容大概长这个样子:解决好 冲突之后,需要将
rej
文件删掉:rm /path/*.rej
;然后运行
git add .
,将解决好的文件添加到git的暂存区;最后 运行
git am --continue
;至此一个冲突解决完毕,保不准后面会接着有冲突,那就再继续按照上述 的步骤解决。知道没有冲突为止。
这个就是我们没办法自己在本地电脑checkin/checkout 代码带来的成本,一个星期大概花2-3个小时的时间更新代码,因为我们共有4个repository。后端其实相对还好,主要是前端冲突比较多。
其实我们这个项目是马上就要结束, 如果业务模块比较多,可以考虑不同的团队分开做,这样的话冲突也会少一些。另外一个团队 也为我们考虑了很多,他们利用分支策略,几天merge一次到master,一开始我们觉得还不错,但是时间久了发现,该merge的还是要merge只不过时间节点靠后了。
如果可以不要有这种情况了。