您的团队使用哪些指南或标准进行版本控制？
我开始在公司内进行少量开发。我打算使用 Git 进行版本控制，并且我有兴趣了解人们在其组中围绕版本使用哪些指南或标准，类似于通常在组内为组编写的编码标准。
我假设会有类似的事情；
- 经常提交（至少每天/每周/会议等）
- 发布版本始终从主分支进行
- 在发布之前，将创建一个新分支用于测试并标记为这样。从此时开始仅修复错误。最终版本将被标记为这样，并且错误修复会合并回主干
- 每个开发人员都会有一个公共存储库
- 新功能应该有自己的分支
显然这很大程度上取决于您使用的 VCS 以及您的方式已经结构化了。
I'm starting to do a small amount of development within my company. I'm intending to use Git for version control, and I'm interested to see what guidelines or standards people are using around version in their groups, similar to coding standards are often written within the group for the group.
I'm assuming there will be things like;
- Commit often (at least every day/week/meeting etc)
- Release builds are always made from the master branch
- Prior to release, a new branch will be created for Testing and tagged as such. only bug fixes from this point onwards. The final release of this will be tagged as such and the bug fixes merged back into the trunk
- Each developer will have a public repo
- New features should get their own branch
Obviously a lot of this will depend on what VCS you're using and how you've structured it.
Similar Questions;
git branch naming best practices
Is there a standard naming convention for git tags?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
在我目前工作的地方，版本控制系统是最先进、最成熟的系统之一。我们就是这样做的。
我们有一个称为“主”分支的东西，它将是生产中的代码库。请注意，代码库位于一个巨大的庞大结构中。假设如果有一个新项目到来，我们将必须对其进行范围界定并预订发布周。现在我们必须开始努力。因此，我们从 main 中切出一个分支，称为功能分支。团队或开发人员组继续在该特定功能分支中工作。请注意，将从主分支同时切出许多功能分支。
现在，一旦开发结束，通常会将代码合并回主程序。我们不会直接这样做，因为这可能会因明显的关键性问题而造成严重破坏。因此，我们从主分支中又切出了一个分支，称为预发布。我们将所有代码合并到该版本库中。并在完整的代码库上进行构建。构建应该会通过。当它这样做时，我们提取一个绿色时间戳（最后通过的构建）。一旦获得绿色时间戳，代码将从预发布分支合并到主分支，并最终确定发布。
一旦代码投入生产，如果我们遇到一些错误，我们就会从 main 中删除一个分支，称为错误修复分支。做所有的改变。并将其合并回 main；始终遵循预发布/绿色时间戳流程。这是不可避免的。
重新基地。好的，所以最初我说我们会在我们的功能分支必须完成时进行预订。在此期间，main 上将会发生大量代码更新。因此，您非常有必要不断更新当前的功能分支以与主分支保持同步。为此，完成了称为变基的过程。这就像从 main 获取最新的代码，这样您就不会在过时的分支中工作。在我当前的组织中，尽管政策建议 1 周，但每 2-3 周就会触发一次变基。
更有趣的功能：假设我目前正在一个所谓的功能分支上工作，我想从也在自己的功能分支中工作的其他团队之一获取一些代码（这种情况虽然看起来不常见，但经常发生）。为此，我们将更改我们的配置规范（ClearCase 是我们的版本控制系统），以指向其他项目所需的那些文件。可以使用 LATEST 或指定 TIMESTAMP 来提取来自其他功能分支的文件。
项目上线一段时间后，我们削减的功能分支几乎不再需要了。如果空间受到限制，一年后，它可以从系统中终止。
In the current place I work, the version control system is one of the most advanced and matured. This is how we do.
We have something called as a "main" branch which is the code base that will be in production. Note, the code base in one single huge gargantuan structure. Say if a new project comes, we will have to do a scoping for it and will book a release week. Now we have to starting working on it. So, we cut a branch from main called as feature branch. The team or the group of developers keep working in that particular feature branch. Note there will be a lots of feature branch cuts simultaneously from the main branch.
Now once the development is over its customary to merge the code back to main. We will not do it directly as it might cause havoc due to obvious criticality issues. So we have a one more branch cut from main called pre-release. We merge all our code to that release base. And do a build on the full code base. The build should pass. When it does so, we extract a green timestamp (last passed build). Once the green time stamp is got, code will be merged from the pre-release branch to main and the release is finalized.
Once the code is put into production and say if we face some bugs, we cut a branch from main called as bug-fix branch. Do all the changes. And merging it back to main; always follows the pre-release/green timestamp process. Its inevitable.
Re-base. Ok, so initially I said that we would have booked when our feature branch has to be completed. During this time period, there will be lot of code update would have happened on main. So, its pretty much necessary that you keep updating your current feature branch to be in sync with main. For that a process called as rebase is done. Its like getting the latest code from main so that you are not working in a branch that is so outdated. In my current org, a rebase will be triggered every 2-3 weeks although policies recommend 1 week.
More interesting features: Say I am currently working on a so called Feature branch and I want to get some code from one of the other teams who are also working in their own feature branch (this scenario although seems uncommon happens frequently). For that we will change our config-spec (ClearCase is our version control system), to point to those files required from the other project. Either LATEST can be used or a TIMESTAMP can be specified to extract those files coming from the other feature branch.
After a good amount of time after the project goes live, the feature branch which we cut is pretty much not needed. It can be terminated from the system say after a years time should space be a constraint.
只有一个标准：
Only one standard:
我的“cvs”是TFS，所以请珍惜它的价值。
如果有人破坏了构建，则适用甜甜圈规则（第二天带来一盒甜甜圈）
您提到经常根据天、周或会议进行提交。
这个系统不会引入不完整的代码吗？
代码审查后提交可能会更稳定。
首先设置单元测试是一个很好的做法，因为这就像让第二个 QA 团队通宵工作（当这些单元测试作为通宵构建的一部分运行时）。
至于每个功能都有一个分支，这不是我使用的东西，而是当有人破坏构建时我们讨论的东西，因为如果一个团队破坏了一个功能，其余的东西仍然会构建。为此，您的安装程序必须足够灵活，即使缺少可选功能，也能够构建和部署。
按这样的功能进行构建可以提高生产力，因为 QA 可以在第二天开始测试，而不是被损坏的构建所阻碍，直到下午晚些时候修复它，甚至推迟到下一天才看到另一个类似的问题发生。
CVS 众所周知，但如果我要启动一个开发团队/项目，我可能会考虑看看 Jira Studio
http://www.youtube.com/watch?v=2w2uN3c8pfA
http://www.youtube.com/watch?v=c9pm_r8vSwM&feature=相关
my 'cvs' is TFS so take it for what it's worth.
If someone breaks the build, the doughnut rule applies(brings box of doughnut the next day)
You mentioned committing often, based on day, week or meeting.
Wouldn't this system introduce incomplete code?
It might be more stable to commit after code review.
Setting up unit tests would be good practice to start off with, since it's like having a second QA team working overnight(when those unit tests run as part of the overnight build).
As for having a branch per feature, it's not something I used but something we talked about when someone broke the build, since if one team broke a feature, the rest of the stuff still built. For this to work, your setup program has to be flexible enough to build and be able to deploy even if optional features are missing.
Building by feature like this can increase productivity since QA can start testing the very next day instead of being blocked by a broken build until it's fixed later in the afternoon or even pushed back the next only to see another similar problem happen.
CVS is well known, but if I would be starting a development team/project, I might consider having a look at Jira Studio
http://www.youtube.com/watch?v=2w2uN3c8pfA
http://www.youtube.com/watch?v=c9pm_r8vSwM&feature=related
一旦您拥有主分支，您想要使用的任何任务或功能都应该在其自己的分支中开发。尝试始终保持主分支稳定并做好生产准备。每当你有任务时，分叉一个分支，在那里完成你的工作，修复任何错误，然后合并回 master。
无需每天（或任何其他时间单位）签到。我们总是根据功能完成情况进行签入，不一定是完整的功能集，而是以小的逻辑可管理块的形式进行。这使我们能够比每天签入所有代码（无论是否相关）更容易地发现错误。
保持你的提交信息清晰、切中要点，这将在你重新访问你的代码时给你带来巨大的帮助。
git 的一个小问题是，当你分叉一个分支时，它是从你当前所在的分支分叉的，而不是从 master 分叉的。这是显而易见的事情，但在分叉新分支之前，请务必仔细检查当前分支。
使用 .gitignore 文件将您不想跟踪的文件保留在版本控制之外，而不是弄乱您的 git 状态消息或覆盖本来就不应该在版本控制中的文件（数据库配置等）
Once you have your master branch, any task or feature you want to work in should be developed in its own branch. Try to keep the master branch stable and production ready at all times. Whenever you have a task, fork a branch, do your work there, fix any bugs, then merge back with master.
No need to check-in per day (or any other time unit). We always do our check-ins based on feature completion, not necessarily a complete feature set, but in small logical manageable chunks. This allows us to find bugs more easily than having a daily check-in of all code whether it is related or not.
Keep your commit messages clear and to the point, this will help you tremendously when you revisit your code.
A small gotcha with git, when you fork a branch it is forked from the branch you are currently on, not from master. This is an obvious thing, but always double check your current branch before forking a new branch.
Use the .gitignore file to keep files you don't want to track out of version control instead of cluttering your git status messages or overwriting a file that should not be in version control in the first place (DB config and such)
仅将工作代码签入（或升级，具体取决于您的工具）到“主”分支/流/仓库/存储库（选择您自己的“主”定义）。这个“主”分支应该始终保持可编译和可测试。
Only check in (or promote, depending on your tool) working code to the "main" branch/stream/depot/repository (pick your own definition of "main"). This "main" branch should remain compilable and testable at all times.