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的冲突，然后运行
该文件的位置就在需要解决的冲突的后面，所以如果用idea打开就很方便解决冲突，具体如何解决就不说了，基本上是该删的删，该加的加，该修改的修改。
git apply --reject vvv.patch，这里我们假设vvv.patch是冲突的那个patch，会生成一个以rej结尾的文件：rej的内容大概长这个样子：解决好 冲突之后，需要将
rej文件删掉:rm /path/*.rej;然后运行
git add .，将解决好的文件添加到git的暂存区；最后 运行
git am --continue；至此一个冲突解决完毕，保不准后面会接着有冲突，那就再继续按照上述 的步骤解决。知道没有冲突为止。
这个就是我们没办法自己在本地电脑checkin/checkout 代码带来的成本，一个星期大概花2-3个小时的时间更新代码，因为我们共有4个repository。后端其实相对还好，主要是前端冲突比较多。
其实我们这个项目是马上就要结束， 如果业务模块比较多，可以考虑不同的团队分开做，这样的话冲突也会少一些。另外一个团队 也为我们考虑了很多，他们利用分支策略，几天merge一次到master，一开始我们觉得还不错，但是时间久了发现，该merge的还是要merge只不过时间节点靠后了。
如果可以不要有这种情况了。