If you’re moving from another source control management (SCM) system to Git, you will need to develop some operating procedures and make sure everyone on the team buys into those procedures.
Why? Git is a different type of SCM tool and its concepts are somewhat different than most SCMs. Git’s concept of “origin” repository with the use of “local” repository takes getting used to over a traditional SCM’s concept of the main repository. And Git promotes using the Master / Branch relationship differently than most SCMs.
Example: In Subversion the main code tree is in Trunk. I’ve seen companies do all their work within Trunk. Multiple developers submitting changes to Trunk, and when release time comes, a freeze on check-ins is enforced. Once the release is built and tagged, only then are developers permitted to continue working. What a waste of time!
Some companies will not do the tag, but copy release Trunk over to a branch. To see what is in production you have to locate the correct branch.
Other companies will work strictly out of branches. They create a branch off what they believe is the most recent release code base (trunk or a branch) and at some point “might” merge release work back into Trunk.
With Git, the direction is that all releases are out of Master (aka: Trunk). Branches are where the work happens. Branches get merged back into the Master for release builds. And Master is tagged for those release builds.
Keeping release code within Master and separating out current work into Branches helps to make logical breaks in features and dependencies. And you will not block your developers from checking in code.
With that in mind, here is a short list to get you started with your team’s Git procedures: Read More