公司内部项目私搭 GitLab 服务器，使用 Git 版本控制，需要 fork 和 pull request 吗？

简单点，每个人一个分支，做完功能，push，在网站提交 pr，等有权限的人 merge 到 master，就完事了。

如果自己的开发分支功能做了很久，可以时不时把最新的 master merge 到自己分支。

开个自己的分支就好了。没必要 fork

个人觉得越简单越好，无论是分支还是 fork 对于版本控制，和线上业务回滚来说都过于复杂。对于功能的迭代可以在代码里做开关，进行控制。

在开发功能之前 从 master 上切一个分支出来 功能做完之后推到远端 在发起合并。分支建议以名字 + 日期 + 功能命名。而且分支多一点也无所谓吧 这些开发的分支在开发完之后都能删掉

@largezhou ，@勺颠颠， @Epona , @Jinrenjie , @zxx123 , 比如说，有如下场景：我的源仓库固定两个分支：develop （团队成员开发的源分支），master (主分支，发布上线版本用， 代码永远来源于 develop 分支)。现在我开发一个功能，我从 develop 拉取代码到本地，然后在本地，开一个功能分支，开发完毕，提交到本地仓库，合并分支到本地 develop , 并删除功能分支。那么，现在我本地的 develop 分支代码是如何提交到源仓库的 develop 分支？1. 提交到一个新的分支，然后 pull request，请求管理员合并到 develop 分支，然后删除新的分支？ 2. 直接有权限提交到 develop 分支？

@matteao 你先区分下推（git push）和提交（git commit）。

我们现在也是两个分支，一个 master（产线），一个 test（测试机）。

开发流程：

pull master 分支。

checkout -b my_name_dev 分支开发。

开发完，commit 后，切换到 test 分支，把 my_name_dev 合并到 test。

push test。这个 test 是都有权限 push 的。

测试没问题后。

push my_name_dev 分支。这一步之前，偶尔会先更新本地的 master 分支，再合并到自己的分支，解决冲突。

在网站上提交 pr，有权限的人看到后，审核代码，并确认合并。

线上是会有很多个人开发分支，，，合并完的自己删掉就行，不知道有没有什么定期自动删的。

我们的做法和他们是一样的 而且不用太在意远程仓库上有很多分支啊。如果真的有洁癖 那么提交 pr 的时候把这两个选项勾上，这样当你的分支合并入主分支就会把 该分支删掉

看你愿意操心到什么程度，一般内部企业来说，根据分支提 PR 就可以了
1. 最省心的方式，全部都往 master 上推送，这样也没什么大问题，直接撸代码就可以了，甚至对 git 不了解的开发者也能很快的就提交上来他们的代码

2. 稍微操心一点的方式，其余的人随便建什么本地分支都可以，master 设置成保护分支，不允许开发者推送合并 master，只有发起合并请求或让管理员进行合并才可以

3. 再操心一点的方式，建立 dev 分支，所有人只能推送或发起合并请求到 dev 分支上， dev 分支可直接用于开发和测试环境使用，然后直接合并最终版本的 dev 分支到 master 上， 当然了还是得管理员负责这个

4. 再再多加一点关注的方式，在 3 的基础上，周期性的从最新的 dev 分支上建立对应开发任务的分支 比如 task-1， 所有开发人员对于该 task-1 再进行分发，比如 task-1-01，只能提交合并到 task-1 上，然后任务分支合并到 dev 分支上，用于测试， 测试通过再合并到 master 上，这个最好额外配合一些项目管理系统使用， 可以直接使用上面的任务 id 来做分支，这样保证了规范和可追踪

另外再说一个我接触过一些日本开发项目， 他们的项目只能接受 PR, 所以只能 fork 后进行处理，因为项目不大，只有一个 master，这样的话，其实对于分支来说比较无所谓了

这个合理的分支策略看场景、项目、团队多个因素吧，可以简单来，也可以严格来，我这边基本分支分三系：

• 1 生产分支 master -> 生产 HotFix 或小需求维护分支 master-release
• 2 测试分支 develop
• 3 开发分支：一般推荐都是自己本地新建一个基于 develop 的分支，做开发分支，这个分支也要 push 到远程，分支名字后缀加开发人的名字

为什么不用 develop 做 master 的日常维护，因为做的项目是内部项目，迭代周期很长的，基本 develop 和 master 提交会差很多，只有正式要上线 develop 所有功能的时候，才会把 develop 合向 master。
本地开发结束，需要给测试人员测试的时候，有专门 code review 将开发人员的开发分支合向 develop