源代码管理意见 [英] Source Control Opinion

查看:112
本文介绍了源代码管理意见的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个同事说,正确使用源代码控制是先部署到我们的生产环境中,然后等待一段时间(至少一天)以确保它是正确的,然后再将这些更改检查到我们的源代码控制生产部门".他说:这是进行源代码控制的尝试,真实和可接受的方法."

我已经提供了我的意见.我想听听别人.有人这样做吗?您有什么想法?

I have a coworker who says that the proper use of source control is "to deploy to our production environment and then waiting for a certain amount of time (at minimum a day) to make sure it is correct before checking those changes into our production branch of source control". He says "this is the tried, true and accepted way of doing source control".

I''ve already provided my opinion. I''d like to hear others. Does anyone do it this way? What are your thoughts?

推荐答案

我使用Subversion,我的规则是:仅在工作时检查并通过测试.
绝对,我不会等待发布到生产环境中-它会在我进入过程中被检入,以便您可以随行使用最新版本.

我可以看到他要去哪里-生产版本很严重,很难回滚.
I use Subversion, and my rule is: only check in when it works, and is tested.
Definitely, I would not wait for release to production - it gets checked in as I go, so that the latest version can be worked with as you go along.

I can see where he is going though - production release is serious, and very hard to roll back from.


我认为这不是正确的方法.源代码管理是一个非常广泛的主题,无法在一个问题下进行讨论.但是,源代码控制的方法取决于项目.代码签入应基于项目的迭代在开发分支之一上进行.然后,根据所采用的方法,将更改传播到集成,预发布和生产分支.

通常,代码的检入时间不应超过必要的时间.
I do not think its the correct way to do. Source control is very wide topic and can not be discussed under one question. However, Approach for source control depends on project. Code checkins should be done on one of the development branch based on the iteration of your project. Then the changes are propagated to integration, pre-release and production branch based on the approach taken.

And generally, code should not be checked in for longer than necessary.


与OriginalGriff类似,我们也使用Subversion,并且"trunk"应始终是工作副本.您的代码.您应该能够从干线下载完整副本,并且可以毫无问题地进行构建,并且应该能够在短时间内部署此代码.例如.需要修补程序

如果您的解决方案需要进行较大的修改,则可以在此处创建一个分支并开始针对该分支进行开发.同时,其他开发人员可能会反对主干,进行较小的修改或修正.

完成针对分支的开发后,您就可以在分支中将更改与主干合并,以创建一个新的"trunk"版本,其中包含了大型开发以及在该开发阶段进行的所有修复.


无论如何,这始终是我在源代码管理方面的经验!
Similar opinion to OriginalGriff on this one, we also use Subversion and the ''trunk'' should always be a working copy of your code. You should be able to download a complete copy from the trunk and be able to build with no problems, you should be able to deploy this code at short notice. E.g. a hotfix is required

If there is a large amendment required to your solution, then this is where you create a branch and begin developing against that. In the meantime, other developers maybe working against the trunk, making minor amendments or fixes.

When you''ve completed your development against the branch, this is where you merge in your branch changes against the trunk to create a new ''trunk'' version that incorporates the large development and all fixes that occurred during that development phase.


That''s always been my experience with source control anyway!


这篇关于源代码管理意见的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆