git 一键同步脚本

[edk24]

为推行外包团队使用 git, 简化流程的一键脚本. 方便快捷. 专业团队请忽视

使用之后腰不酸腿也不疼了.

https://github.com/edk24/gitsync

---

在外包团队, php 后端我们能使用 ftp. 依旧有相互覆盖的风险, 而且造成后果不可逆;

前端我参与并见过最奇葩的开发方式是, 两个前端(A 和 B)各自开发一部分, B 完成后 QQ/wx 发文件给 A 手动合并.

A 再分发完整的压缩包给 B. 再循环

不仅浪费时间, 还可能经常有文件离奇失踪 [哭笑]

---

搞了这个东西后, 只需要简单的调教就可以上手了. 如果对你有用的话, 请不要吝啬你的 star :)

[yanqiyu]

有趣，小组作业可以丢给不会用 git 的同学
接下来就是等一个 AI 处理合并冲突了（不是

[yukiloh]

.md 的 dict 跳转没写好
我每次要部署了都是复制 run.sh 和 update.sh,到后来 git 怎么写都忘了...

[msg7086]

写脚本解决问题的精神值得钦佩，但是用这脚本搞出来的仓库树形图怕是要被我喷到死。
我还是建议，用 Git 的人学 Git 。

你学车以后就会开车。同理你学 Git 以后就会用 Git 了。
让不会用 Git 的人强行用脚本处理，就和给你一本说明书就让你踩着油门上大街一样可怕。

[edk24]

@yukiloh 这个给不会 git 的同学, 让他们更加不会 git 哈哈哈哈哈

想一想是不是很划算

[edk24]

@msg7086 我们是外包团队, 一般不看记录. 只是能达到恢复的目的以及自动合并就可以了

专业流程的团队是不建议使用的, 20 天 1000 多个提交, 我也很无奈. 但比 ftp 和手动发送文件合并方案要好.

我不地道的说一句, 我会就可以了, 他们也没心细学的.

[edk24]

@yanqiyu 那个倒是不必啊, 出现合并冲突让他们拿 vscode 处理就可以了 很香的[苦笑]

[24bit]

全局安装的话 git add . 只会添加当前目录下的吧，不如改成 git add --all 算了 >_>

[Acoolda]

出现冲突了不会 git 不就两眼一抹黑了嘛。还是得会 git 啊

[msg7086]

@edk24 非常无奈了。

[edk24]

@24bit 会以命令行所在目录为准

[evilic]

@msg7086 说的对，用 git 的人学 git 。

我觉得问题不应该是这样的。目的只是为了恢复的话，那就应该直接在 ftp 的服务器上部署脚本去备份，而不用写工具给那些人使用。
新的解决办法总会带来新的问题。我觉得这个是坑。
不如直接要求他们学 git，这样学会了对人家的技能也有提高<del>，简单的搞个工具，对别人什么益处也没有，只是方便了自己使用 git</del>。
花时间写这个工具，然后再告诉他们怎么用，不如花时间组织语言，如何简单通俗易懂的讲解 git，然后再给他们一个培训讲解……（然后再强制要求转换到 git 上……）

[edk24]

@evilic 大哥, 不是我说. 外包团队都是瞎来的. 很多还是刚毕业的. 让他们能自己理解工作区 暂存区 仓库 远程仓库 分支 储藏 巴拉巴拉一堆. 我头疼

很多干两三个月就走了, 说是方便他们, 不如是方便我. 恢复代码避免损失. 虽然对 php 后端用处不大. 但对前端提升的效率和便捷不是一点点. 而且干不久就走了 意义在哪里?

工具嘛, 我就说句不地道的话. 没打算教. 除非是自己公司的项目, 我会提议他们把工单系统之类的用起来

[edk24]

@evilic 你这个说法也有道理, 但对外包来说. 严格要求他们走流程是太难了, 4 个命令才能完成同步

而且我在团队中也不是领导, 没有话语权. 只能拖着走. 也许我也确实是有点小气了, 我费那么大劲才理解的东西干嘛白送别人. 我又没啥收益