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

外包还 git ？我不是打击你，绝大多数还在用 svn 并拒绝换

每人一个分支，每人一个测试环境文件夹

Git Flow, Github Flow

svn git 都很简单啊，开不同分支就行了，master/develop，搞 ftp 做代码服务器，你们心真大！

1. git 本身不是问题，即使是外包，这个也是基础能力之一。
2. 做好 cr 是关键。
3. 如果团队大多数真的不会 git，提供工具也可以，但是有隐含的风险，一旦要回滚或者怎么样，半天操作不来。
4. 改了代码提交 git 不是很正常吗。要不怎么部署测试呢，本机启动？我看见的大公司是要 git 提交，然后机器部署一把的。这个流程很多人都在走。目前看来没有问题。

这是 XY 问题
你应该解决的是标准化本地开发环境或者是 CI/CD 的问题，他们和版本控制有关但不是版本控制能够解决的问题

看效果 or 测试 这不是应该本地测试环境看嘛，跟 git 有毛线关系。
测试服务器自动同步 webhook 完全没问题啊。也就几秒钟吧。。

多分支怎么样，生产 master，测试 dev，开发 2019_0X。

人的问题，不是 git 的问题，
楼主这种是一群人用一个分支（通过“使用一键 push.sh 和 pull.sh”了解到），
还不用考虑冲突解决，
那么我建议还是回去继续用 ftp 覆盖简单粗暴好了

楼主的头像是谁啊？

@zjsxwc ftp 太容易丢代码了, 有时候因为上传不成功都会丢. 怕了

git 几个命令学不会？ 以后怎么去 github 拷贝代码？ 怎么提升外包生产力？

ftp 90 年代才用吧，太恐怖了。
记得开始工作的时候用 MS 一个什么鸟东西，忘记了，可以锁定代码的。

后来就用一路用 CVS，SVN，HG/Git，最近 5，6 年一直用 Git，这台本本（ 14 年的）上根本就没安装 SVN 客户端了，上一个本上开发时还少量用了 SVN。

gitlab runner。

首先要让他们停止用 ftp，不然后面问题不断

测试为什么要频繁提交，本地测不行吗

我有跟你一样的场景，下面写出我的做法，供你参考
1，ftp 和 git 要同时用，ftp 用于快速发布代码到测试环境，git 用于代码归档、版本管理(主要是防两个人 ftp 互相覆盖问题)。
2，ftp 用的是 jetbrain 的自带插件，在 tool->deployment 里面可以找到，可以设置自动触发，保存文件的同时，就能发布到测试服务器，解决了发布成本高的问题，一行代码也可以轻松发布。
3，git 的使用和正常情况保持一致即可，git flow 模型是最佳选择，如果团队不会，也可以用同一个分支当 svn 那么用，主要是每完成一个小任务，都 commit 一次，并且必须附上有意义的 message

@cz5424 项目和项目之间可能环境依赖有冲突，本地难以调和，用 docker 成本有点高，直接要求客户给准备一个测试服务器是外包的一个好方案

一键 push 这个有点秀啊，如果不会用还是别用了，到时候给你 force push 了还得帮人擦屁股还原代码

一键 push 不可取，

频繁提交和代码测试的问题，可以参考 git flow，简单来讲就是开发、测试分支和发布的分支分开管理

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

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

不是让他们提 pull request 么

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

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

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

这个流程没区别吧。

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

gitlab flow + ci/cd

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

svn+钩子

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

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

使用 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 节点，让整个提交树非常清爽。

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

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

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

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 ）

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

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

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

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

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