Using Git like a pro
Git is the most popular version control system used by all types of teams including members from 2 to 10,000+. The power of git comes from the ease of branching and merging the code base allowing for flexibility in development. Although a lot of teams fail to create and follow a branching model which best suits the style of team.
Each team is unique and has to take the time to iterate over which branching model suits them the best. In most cases a single model does not completely fit a teams dynamics, teams will then need to combine certain models and device standards to cater to business-specific needs.
Choosing the right branching model for your team is a crucial decision directly affecting the developer time in collaborating and not developing new code. A suitable model will save several hours or even days and a wrong choice of model will waste valuable developer time in merging code for several hours.
Few Branching Models
- Long Running Branches
- Feature Branches
- Environment Branches
And many more :
How to choose the right branching model
To decide which models work best for you consider the following pointers and make a decision based on them:
- Developer Proficiency
- Environments - Dev, Staging, Beta, Production etc
- How To Handle New Features
- How To Handle Hot Fixes
- How To Handle Deployments
- Versions And Tags
- Need For Branch Privacy
- Need To Integrate CI CD
- Branch Naming Strategy
- Commit Messages Information Requirement
- Pull Request Hierarchy
Where to start
When you are starting on a new project or shifting your codebase to git consider this guideline to shape your workflow.
- develop branch is the latest branch
- every new functionality needs to be done with a new feature branch
- a simple feature branch naming scheme like featurename_date serves well for developers to work on.
- commit message need to be sufficient understand what's included in the code. A very detailed commit message usually never get read in history.
- keep the Readme file updated.
- once a stable Dev code base is achieved developer can then push the code to staging.
- staging level bugs need to be fixed with feature branches into Dev then staging.
- after a few testing cycles, the stable staging code is pushed to production branch which could be master.
- tag all production release with a version of the software for trackability
- hot fixes from production can be handled based on criticality. Blocker issues could be fixed on production and then propagated down. Others need to follow the same cycle like a feature.
- maintain environment specific properties in branches. Fresh checked out code should be directly deployable. This allows you to automate the deployment using CI cd.
- If pull request control is a must for your team do at the staging level. Develop an environment should be handled by the developer for speed.
- Developer friendly as they are only concerned with develop, feature and hot fix branches.
- Multiple features can be developed and tested in parallel.
- Testers can tracks bugs by staging branch version.
- Production code is tagged for easy history tracking.
- CI and CD can be triggered by merge events in dev or staging reducing deployment efforts.
Git is a powerful tool to manage your codebase and combined with the right branching model and standards your team's can utilize its full potential.
Every team needs to undergo iterative cycles for enhancing and modifying the workflow according to what works best for developers and the business needs.
You can start your git branching strategy using the pointers mentioned above and customize as per your teams needs.