外包团队大家是怎么使用 git 的? 能不能分享一些经验

[edk24]

我们公司现在组织使用 git, 用码云托管 挂 webhook 部署

有个问题就是, 我们是做外包的, 经常改完保存就想上传看看效果 or 测试.

因为这个我还专门给他们写了个一键 push.sh 和 pull.sh

但还是感觉不太方便, 我有些疑问想请教下大家的经验

1.上传会比 ftp 慢一点

2.一键 push.sh 拿时间做 备注 来提交免输入, 又感觉失去了它的意义

3.频繁提交 (改两行 改一个字符马上提交代码测试) gitgit

这样做会不会不对, 我自己捣鼓了 git 想推广给大家使用, 又怕他们觉得麻烦而抵触. 我自己也怕 ftp 相互覆盖, 自动下载 导致一些代码丢失

[Mutoo]

分享一下澳洲的外包公司经验：这边向客户提供服务一般会有多个 web 服务器，testing / staging / production
testing 是公司内部使用，绑定的是 dev 分支，用于日常开发，一有新的变更，就通过内部的 teamcity 服务器发布；
staging 是预发布，绑定 master 分支，变更自动发布。用于预览客户的需求变更；
production 是线上版本，绑定的也是 master，不过是手动发布，客户满意 staging 上的变更后，同步到 production。

[keepeye]

不觉得外包公司和非外包公司在开发流程上有啥区别，主要还是人的问题

[murmur]

不是让他们提 pull request 么

[chinvo]

git flow 风格管理分支，各自在本地测各自的，testing 服务器上 ci cd dev 分支

[xiaoming1992]

@keepeye 人的问题就是最大的问题啊，同一体量的公司，外包公司人员素质可能相对来讲会稍低一些，比方说，他们可能不会用 git （咦，这是在说我吗？）...

[janus77]

你们不能本地测试吗？就你说的改一个字符还得非要先 push ？

[anonymous256]

这个流程没区别吧。

每个开发在各自的分支上提交代码，然后每天 Merge Request 到 dev 分支. 最好能每日自动构建。 如果体量比较大， 就考虑自建 Gitlab 的服务器。

[doomty]

gitlab flow + ci/cd

[no1xsyzy]

git 上传的是增量不可能比 ftp 慢啊
频繁提交就是自己动自己的 branch，小改动 amend 就行了
我只能理解每个提交独立可运行，如果最基本运行不起来就别提交了。

[qwertyzzz]

svn+钩子

[FaceBug]

1、dev 可以是本机，也可以搞一台服务器每个人一个文件夹，用 IDE 自带的 SFTP、FTP 实时同步，如果开发人员习惯用其他的 FTP 传也 OK 啊。
2、一旦确认单个功能点开发完了，git 提交到自己 branch 或者所属模块的 branch，项目负责人整合完多个开发人员的功能到 test 分支，在 test 目录 git pull 验收结果。

你不要关心他们自己开发过程中用什么方法，我也反对任何小改动都要 git 一下，你只关心关键节点，有没有正确提交到 git 就好了，比如一个迭代、或者每天下班的时候，有没有把阶段性的工作结果提交。

[Fule]

使用 Git 这个事情，肯定比使用其它源码管理方式麻烦、复杂一些，尤其是如果想用好、用规范的话。一套流程是必不可少的。所以，首先，你要有足够的权限 /权力去推动。其他人可以提出建议、意见，但只有推动管理和规范的那些才会被考虑接纳和改进，牢骚类的直接忽略乃至驳回。如果只是平级、没有强制力，遇到抵制没辙的话，还是放弃吧。

使用 git 的目的是规范化、流程化，而不是“最简化”，因此一键 push 这样的东西不可取。git 的提交节点树是非常有价值的代码历史追踪工具，上面主要分支的每一个提交及其 message，都必须明明白白的。这样在你回溯代码问题的时候会比较清晰。

另外鉴于 git 的使用方式、方法非常灵活，因此应该需要有一个人统管 git 流程和分支管理，这个人应该就是你啦。还有对于工作的分配也要注意，不要把一个涉及同一部分代码的任务分配到多个人身上，那样会极大增加代码提交冲突的可能性。公共模块的更新，尤其是大量的更新，最好统一归到某位“高级”员工身上。

鉴于楼主的描述，依我队楼主公司的开发流程的理解和推测，可以考虑这样使用 git：

1. 所有人可以都在一个分支上工作。假设这个分支叫 dev，那么服务器上的分支就是 origin/dev,本地分支叫 dev
2. 每个人在开始工作前，首先 pull origin/dev，就是从服务器上获取最新的代码。
3. 开始自己的工作。如果要实时看自己改动的效果，那只能在自己的电脑上查看（开发不都这样么），整块功能完成之后，提交自己的代码，形成一个 commit，commit 的 message 里需要写明这次提交的代码做了什么事情，比如“完成某某功能”、“修复某某 bug”等。message 是重要信息，*一定不能随便乱写*。
4. 鉴于自己的提交完成之时，服务器上的 origin/dev 可能已经有了别人提交的代码，此时 push 代码可能会被拒绝。因此 push 的时候，通常需要分 2 步：
4.1 Fetch 然后 Rebase，Fetch 的作用是从服务器上获取最新的 origin/dev 到本地，这样你本地的 origin/dev 就和服务器同步了，同时不会影响到本地的工作区。Rebase 的作用是将步骤 3 的提交内容以最新的 origin/dev 节点为父节点“重做”，这 2 步的结果是你本地的提交的父节点现在已经是服务器上的最新节点了。如果你当前提交的节点的父节点依然是服务器上的最新节点，那么 rebase 就等于一个空操作，没有任何效果。
4.1.1 git 重做的时候可能会产生代码冲突，因为服务器上的最新节点里可能也修改了你修改的代码，此时，你需要手工解决冲突。注意，这些代码冲突产生在你本地，所以并不会影响任何其他人。冲突解决之后，你的提交就准备好 push 到服务器了。
4.2 push 本地提交。因为你做了 4.1，所以现在 push 不会有任何冲突存在，你的提交应该顺利地更新到服务器了。

如果想及时查看自己的更新的全局整合效果，那么得配一个 CI 服务器进行持续集成。CI 服务器上也有一套 git，会通过钩子或者轮询获取最新的提交，一旦有新提交被获取就会自动生成并部署一个系统版本。

以上是一个基础流程，在这个基础上可以根据其它情况进一步演化。
使用 git 的时候，无论是工作分配和开发流程，都要注意减少代码冲突的可能性，例如上述步骤 2，就为了让自己的工作始终基于最新代码之上。另外代码冲突的处理也都在本地由提交代码者处理。
你可能注意到上述流程，没有牵涉到“merge"，那是因为 merge 被 Fetch & Rebase 取代了，好处是省掉一个 merge 节点，让整个提交树非常清爽。

[ClericPy]

https://github.com/nvie/gitflow 一把梭

不过看你说的, 好像是 CI / CD 方面的东西...

[zdt3476]

正常来说应该在自己本地有一套测试环境啊，这个和用不用 Git 关系不大。不过 git 还是得用的，版本管理好处不要太多

[yixiang]

0. 本地测试服务器要开起来，大部分时候不需要线上测试

1. 测试服务器上建一个文件夹，git init --bare，hooks 里 post-receive 设置部署脚本

2. 本地 git remote add dev ssh://服务器 ip/上面这个文件夹的路径

3. 要测试的时候 git push dev

4. 都测试没问题了再 push 到 origin

4. 善用 git gui 的 amend last commit 功能，避免出现多个 commit （这时你可能需要 git push dev -f ）

手把手教学，只能帮你到这了。

[unionx]

所以应该先把测试策略搞顺，开发才事半功倍

PS. git flow 的分支模型已经过时了

[walkfish]

ftp 不错了 我们还在刻光盘呢

[yoshiyuki]

@Fule 分享的非常棒，但是外包团队人员替换率一般都很高，招进来的人一般会 git push 就不错了，这套方法培训成本略高