这是一个创建于 2848 天前的主题，其中的信息可能已经有所发展或是发生改变。
RT. 在下自己打算写一个发布系统，大概思路是通过打 tag 和线上版本进行对比，团队确认没有问题就通过 rsync 同步代码。但是现在有个问题，是假设 A 同事打了一个 tag1 ， tag1 和线上版本对比，只有 a 文件有修改。 但这个时候同事 b 也提交了一个 b 文件， b 同事也打了个 tag2 ，和线上版本对比，只有 b 文件有修改。这时候 b 同事先发布。 那么！问题来了，这个时候如果 a 同事进行发布（假设 a 延迟发布了），那么就会把 tag1 发出去，此时将 b 文件给覆盖了。要如何解决呢？我的思路是创建一个发布流程前就加锁，但是这样死感觉很有点 low 。
各位有好的办法吗？
 |
1
zhuyao 2017-03-10 17:21:38 +08:00
设定权限？
|
 |
3
skydiver 2017-03-10 17:50:06 +08:00
后打的 tag 必须包含前一个的 tag 的内容。
或者直接规定只能在某一个分支上打 tag 。 |
 |
4
VeryCB 2017-03-10 17:54:27 +08:00 via iPhone
感觉不是发布流程的问题，是开发流程的问题...可以看看 git flow
|
 |
5
SpicyCat 2017-03-10 18:05:06 +08:00
按照 git commit 的思路，每个 commit 只记录变更。
同事 A 只改了文件 a ，那么上传的时候，系统只执行文件 a 的更改，其他不变。同理，同事 B 改了文件 b ，也只执行文件 b 的更改。 这样，不管同事 A 和同事 B 的发布顺序如何，都不会彼此覆盖。 除非同事 A 和同事 B 更改了同一文件的同一个地方，那么会有冲突。这时候，后提交的人就会被提示有冲突。 |
 |
6
domty 2017-03-10 18:55:50 +08:00
没用过 git 吗
我们这里的方式是借用 git 的分支进行发布。只允许发布 master 分支。 平时的开发使用自建的开发分支，上线前将开发分支的代码合并到 master 。 这样像你这种情况下 a 如果等到 b 提交代码后进行发布的话会把 a 和 b 的代码一起发布。 |
 |
7
hxsf 2017-03-10 19:28:33 +08:00
发布走队列，同一个项目只能同时发布一个版本。
|
 |
8
Felldeadbird 2017-03-10 23:01:41 +08:00 via iPhone
为什么不基于版本库进行更新啊。
|
 |
9
kmahyyg 2017-03-11 00:32:17 +08:00 via Android
git + code review
|
 |
10
cxbig 2017-03-11 00:37:12 +08:00
一般小的提交+RP 用不着 Tag
不同的程序员接到不同的任务，怎么会有相同的 Tag 呢？这是管理问题吧？ |
 |
11
AccIdent 2017-03-11 00:38:41 +08:00
噗莫名想到 false sharing
加锁可以（悲观），或者用版本号做检查（乐观） |
 |
12
SoloCompany 2017-03-11 04:21:58 +08:00
你这是拿 tag 当分支来用？
正常系统的 tag 必须从指定分支抓取（比如 master ） 即使你不走 review 流程，起码可以保证没人可以 force push 从而覆盖别人的变更 |
 |
13
guoqiao 2017-03-11 05:54:50 +08:00 via iPhone
似乎是对 git 的使用不够了解才会引出这样的问题
|
 |
14
murmur 2017-03-11 07:09:31 +08:00
上线之前还有仿真环境 仿真环境的代码才会推到生产服务器上
|
 |
15
paulagent 2017-03-11 08:22:06 +08:00
目前一个项目，就是只有 master 才能发布到生产环境，开发人员在 branch 上开发，然后提交 merge ， 别的同事 review 万事，同意的话就 merge 到 master 上然后直接跑测试，通过后自动发布。谁先谁后不重要
|
 |
16
nicevar 2017-03-11 09:09:50 +08:00 via iPhone  1
master 用来发布， tag 用于发版之后，开发在分支上并分配权限，搭个 gitlab 之类，分支上开发完成后发起 merge request ，有权限的人 review 后决定是否 merge
|
 |
17
lyao 2017-03-11 10:13:05 +08:00 via Android
git town
|
 |
19
pizida OP @domty 用过 git ，但是目前公司全都是用 svn 管理的。那这样是不是也可以用 svn 的 branch 各自开发，开发完毕后提交到 master ，然后 master 跟上一个发布版本对比一下，没问题就进行发布呢？
|
|
20
pizida OP @Felldeadbird 不太了解，基于版本库更新是什么意思。目前用的是 svn ，每次都会先 svn up 的
|
|
21
pizida OP @SoloCompany 你好，我用的是 svn 管理项目。是不是应该新建分支开发（ svn branch ），然后测试 ok 就 merge 到 master 。然后发布 master 。
|
|
22
pizida OP @paulagent 如果 merge 到 master 之后，发现有点问题，这个时候没有回滚，但是其他同事就发布出去了呢？
|
 |
25
Infernalzero 2017-03-11 19:13:32 +08:00
基于 svn 的这种蛋疼发布系统我之前也有搞过，无非就是仅同步想要发布的文件， php 之类的可能还好些， java 的话一旦有人漏提交就会导致 build 失败，而且还得去发布系统填个发布请求，填上对应的文件，特别蛋疼，只会降低工作效率。讲道理，发布系统就不应该管版本控制的事，做些静态检查倒是可以的，版本控制用 git 或者 hg 完全足够了
|
|
26
Felldeadbird 2017-03-11 22:31:35 +08:00 via iPhone
svn 的话我没解决的方案。
我在的公司内部是用 git 的。每个人都通过分支开发，然后我进行合并到 master 分支。最后通过发布系统推送到对应的服务器。 |
 |
27
akira 2017-03-12 01:23:02 +08:00
svn 的话 你要看看分支代码的合并那一块怎么处理的
|
Select Language