请问代码发布系统中，如何避免多人发布造成冲突而产生发布错了文件？

[pizida]

RT. 在下自己打算写一个发布系统，大概思路是通过打 tag 和线上版本进行对比，团队确认没有问题就通过 rsync 同步代码。但是现在有个问题，是假设 A 同事打了一个 tag1 ， tag1 和线上版本对比，只有 a 文件有修改。 但这个时候同事 b 也提交了一个 b 文件， b 同事也打了个 tag2 ，和线上版本对比，只有 b 文件有修改。这时候 b 同事先发布。 那么！问题来了，这个时候如果 a 同事进行发布（假设 a 延迟发布了），那么就会把 tag1 发出去，此时将 b 文件给覆盖了。要如何解决呢？我的思路是创建一个发布流程前就加锁，但是这样死感觉很有点 low 。

各位有好的办法吗？

[zhuyao]

设定权限？

[pizida]

@zhuyao 那这样只能一个人或者说一个账户来发布咯？

[skydiver]

后打的 tag 必须包含前一个的 tag 的内容。
或者直接规定只能在某一个分支上打 tag 。

[VeryCB]

感觉不是发布流程的问题，是开发流程的问题...可以看看 git flow

[SpicyCat]

按照 git commit 的思路，每个 commit 只记录变更。
同事 A 只改了文件 a ，那么上传的时候，系统只执行文件 a 的更改，其他不变。同理，同事 B 改了文件 b ，也只执行文件 b 的更改。
这样，不管同事 A 和同事 B 的发布顺序如何，都不会彼此覆盖。
除非同事 A 和同事 B 更改了同一文件的同一个地方，那么会有冲突。这时候，后提交的人就会被提示有冲突。

[domty]

没用过 git 吗

我们这里的方式是借用 git 的分支进行发布。只允许发布 master 分支。
平时的开发使用自建的开发分支，上线前将开发分支的代码合并到 master 。

这样像你这种情况下 a 如果等到 b 提交代码后进行发布的话会把 a 和 b 的代码一起发布。

[hxsf]

发布走队列，同一个项目只能同时发布一个版本。

[Felldeadbird]

为什么不基于版本库进行更新啊。

[kmahyyg]

git + code review

[cxbig]

一般小的提交+RP 用不着 Tag
不同的程序员接到不同的任务，怎么会有相同的 Tag 呢？这是管理问题吧？

[AccIdent]

噗莫名想到 false sharing

加锁可以（悲观），或者用版本号做检查（乐观）

[SoloCompany]

你这是拿 tag 当分支来用？
正常系统的 tag 必须从指定分支抓取（比如 master ）
即使你不走 review 流程，起码可以保证没人可以 force push 从而覆盖别人的变更

[guoqiao]

似乎是对 git 的使用不够了解才会引出这样的问题

[murmur]

上线之前还有仿真环境 仿真环境的代码才会推到生产服务器上

[paulagent]

目前一个项目，就是只有 master 才能发布到生产环境，开发人员在 branch 上开发，然后提交 merge ， 别的同事 review 万事，同意的话就 merge 到 master 上然后直接跑测试，通过后自动发布。谁先谁后不重要

[nicevar]

master 用来发布， tag 用于发版之后，开发在分支上并分配权限，搭个 gitlab 之类，分支上开发完成后发起 merge request ，有权限的人 review 后决定是否 merge

[lyao]

git town

[pizida]

@SpicyCat 公司项目用的是 svn

[pizida]

@domty 用过 git ，但是目前公司全都是用 svn 管理的。那这样是不是也可以用 svn 的 branch 各自开发，开发完毕后提交到 master ，然后 master 跟上一个发布版本对比一下，没问题就进行发布呢？

[pizida]

@Felldeadbird 不太了解，基于版本库更新是什么意思。目前用的是 svn ，每次都会先 svn up 的