The way this is done is that every developer must merge changes before they commit a file. I have never used Mercurial so I don't know the commands or the exact process, but in any serious config management tool you will be warned if you try to check in "over the top" of someone else. When you get this warning you should merge the other changes in to your checked out copy, check the build and tests etc and then check in.
This is a very common issue, and merging in this way can be a real PITA, but that's life. The alternative approach of locking all checked out files prevents this issue, but has the serious drawback of blocking everyone else while you work on a file, which in turn leads to people editing uncontrolled versions and then all hell breaks loose...
Your plan sounds great! I think you are off to a really good start.
My only advice is in regard to you Developer Workflow. I think you're dev
branch may become problematic, because developers will be merging code willy-nilly then they think its ready.
If both branchA and branchB, C, and D are merged into dev
, and it fails, you can't be certain which parts are necessarily failing. Also, if someone pushes up something with a conflict, you dont know who it was. Madness and insanity are bound to ensue.
If a feature turns out not to be ready, and code needs to be backed out of dev
, other developers will have already pulled down their additions. Those developers then will merge back into dev
, unwittingly re-introducing the broken code. Madness and insanity are bound to ensue.
You're going to need a couple steps of separation to keep untested code away from tested code.
This all depends on the skill sets of your team, and how you actually work together. What follows is my solution to problems of a quickly expanding team with differing levels of git knowledge and different levels of developers code dependability.
I always try to tell people to not simply think about developer workflow, but testing procedure, and release process. They all need to be planned as part of a singular process.
- Lead Dev or Release Mngr (whoever) creates a new
release
branch based off master
. This branch will be a container for anything going on it in the next release.
- Lead/ReleaseMngr creates
integration
branch based off release.
- Developer creates new feature branch (or topic branch, whatever you want to call it), based off the current release branch.
- Developer tests locally, is happy.
- The developers feature branch deployed somewhere and tested by QA independently of any untested code.
- QA signs off on feature - it gets merged into an
integration
branch. (ideally, IMHO, only after the feature branch has been rebased off release
, to force the conflict resolutions )
- QA tests the
integration
branch which is just the release
branch + this one feature.
- QA signs off - integration is merged into release (if not signed off, integration is blown away and recreated based on
release
). This is the reason for integration
. No one pulls form this branch, and it can be blown away as needed.
- Now the feature is in release, and can be shared with other developers making features based off
release
branch.
- Release is good, merge to master. Deploy, make a new release branch based off master.
I know it sounds like a lot, but it really will save you from the headaches and, in my experience, are inevitable with large projects with logs of people having differing levels of knowledge.
If you have a small team with a simple release process, or a team that is very experienced - all this may not be necessary - but do be aware of the inherent problem with testing multiple people's code at the same time in your dev
branch.
All that said, its my understanding the GitHub team just lets everyone merge into master directly (after a brief code review) and auto deploys ~30 times a day.
Best Answer
First of all, Git is a decentralized VCS (as opposed to ClearCase, which is very centralized: see "What are the basic clearcase concepts every developer should know?")
That means, there is no central server to keep track of a "locked" file.
Secondly, you generally don't just pull, but you
pull --rebase
with autostash in order to replay your local (not yet pushed) modification on top of whatever concurrent modifications were published (pushed).This is the natural workflow to allow concurrent collaboration.
Note that ClearCase allows for concurrent modifications as well, at least in snapshot views (but you cannot easily tell which hijacked file was modified).
Finally, there isn't much going for the old (1985) ClearCase model (See "ClearCase advantages/disadvantages"). Using it in 2015 is an anachronism, as it doesn't scale well with large number of files, unless you are using dynamic views, and even then, any merge is dreadfully slow.
If you have to go on using an IBM tool, consider at least RTC (Rational Team Concert). It does have a locking mechanism.