What guides or standards do you use for version control in your team?

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)
• Rele开发者_运维百科ase 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?

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:

1. Checking in breaking changes will result in a kicking.

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

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.