As a developer since 2008, I’ve witnessed the evolution of version control systems firsthand. Starting with SVN and eventually transitioning to Git, I’ve seen how these tools have become indispensable in our daily workflows. Let me share a detailed branching strategy that has proven effective in managing codebases, ensuring stability, and facilitating collaboration.
Main Branches
-
main(ormaster) Branch:- The production-ready code.
- Only contains thoroughly tested and stable code.
- Direct commits are restricted; only allowed through pull requests (PRs) after code review and approval.
-
developBranch:- The latest codebase reflecting the current state of development.
- All features and fixes are integrated into this branch before being merged into
main. - Serves as a base for all new feature branches.
Supporting Branches
-
Feature Branches:
-
Naming Convention:
feature/<feature-name> -
Created from:
develop - Purpose: For developing new features or enhancements.
-
Merging: Once complete and tested, merge back into
develop.
-
Naming Convention:
-
Bugfix Branches:
-
Naming Convention:
bugfix/<issue-id> -
Created from:
develop(orreleaseif the fix is for an upcoming release) - Purpose: For fixing bugs identified during development.
-
Merging: Merge back into
develop(orreleaseif applicable) once fixed.
-
Naming Convention:
-
Release Branches:
-
Naming Convention:
release/<version-number> -
Created from:
develop - Purpose: To prepare for a new production release.
- Activities: Final testing, bug fixing, and preparing release notes.
-
Merging: Merge into both
mainanddeveloponce ready.
-
Naming Convention:
-
Hotfix Branches:
-
Naming Convention:
hotfix/<issue-id> -
Created from:
main - Purpose: For urgent fixes that need to go directly into production.
-
Merging: Merge into both
mainanddeveloponce applied.
-
Naming Convention:
Branch Workflow
-
Feature Development:
- Create a branch from
developusingfeature/<feature-name>. - Implement the feature, commit changes, and push the branch to the repository.
- Open a pull request to merge the feature branch into
develop. - Conduct code reviews, perform necessary tests, and merge the changes into
develop.
- Create a branch from
-
Bug Fixing:
- Create a branch from
developusingbugfix/<issue-id>. - Fix the bug, commit changes, and push the branch.
- Open a pull request to merge the bugfix branch into
develop. - After reviews and tests, merge the changes into
develop.
- Create a branch from
-
Release Preparation:
- Create a branch from
developusingrelease/<version-number>. - Perform final testing, fix any last-minute bugs, and update documentation.
- Merge the release branch into both
mainanddeveloponce ready.
- Create a branch from
-
Hotfixes:
- Create a branch from
mainusinghotfix/<issue-id>. - Apply the fix, commit changes, and push the branch.
- Open a pull request to merge the hotfix branch into
main. - Merge changes into
developto include the fix in ongoing development.
- Create a branch from
Best Practices
-
Regular Merges: Merge
developinto feature branches regularly to stay updated and avoid integration issues. - Code Reviews: Conduct mandatory code reviews before merging any branch to ensure quality and adherence to standards.
- Automated Testing: Implement continuous integration with automated testing to catch issues early and maintain code quality.
- Documentation: Keep all changes well-documented, including comments in code, update logs, and comprehensive commit messages.
Demystifying Advanced Git Commands: A Simple Guide
Explore More: AI Development Phases
If you're interested in expanding your knowledge beyond Git branching strategies, check out our latest post on AI Development Phases. This comprehensive guide covers the key stages involved in developing AI solutions, from initial planning to deployment and maintenance. Whether you're a beginner or an experienced professional, this post provides valuable insights to help you navigate the complex landscape of AI development.
Read the AI Development Phases Post
SVN vs. Git Comparison
SVN (Subversion)
- Centralized Version Control: SVN relies on a central server to store all versions of the project files.
- Commit Structure: Changes are committed directly to the central repository.
- Branching: Branches are typically created on the server, and branching operations can be slow and resource-intensive.
- Merging: Merging can be more complex and less efficient compared to Git.
Git
- Distributed Version Control: Git allows every developer to have a local copy of the entire project history.
- Commit Structure: Changes are committed locally first and can be pushed to a remote repository.
- Branching: Branching is lightweight and fast, encouraging the use of feature branches.
- Merging: Git’s merging capabilities are more advanced, making it easier to integrate changes from different branches.
I hope this guide helps you as much as Git has helped me since it became my everyday buddy. Happy coding!
Top comments (28)
Hello Amit K,
thanks for your article.
I regularly use Git in combination with GitHub and your guide is very insightful.
The only thing I (and I bet many others) have concerns automated testing. If you ever have the time and desire to write something about this for beginners, I would love it.
Keep it up!
Thank you for your kind words! I'm glad you found the guide insightful. Automated testing is indeed a crucial aspect of the development process. I'll definitely consider writing a beginner's guide on it in the future. Stay tuned, and happy coding!
In personal projects when I started I only used commits on the main branch. I’ve been continuously adding more complexity to my git workflow. Every time I add something it is so worth it. Might try this on my next project! Thanks for the direction!
I'm glad you found it helpful! Adding structure to your git workflow can definitely enhance project management. Good luck with your next project!
I think the organization of this issue will depend on the structure and the number of members in the team. For example, my team is quite small, and we don't even use an intermediate branch. All branches like fixes/xxx, hotfixes/xxx, and features/xxx are based on the master branch. Once testing is completed, they can be merged directly into the master. Subsequent branches are responsible for merging the master branch to continue their work.
Thank you for sharing your approach! Indeed, the branching strategy can vary based on team size and structure. Your streamlined method works well for smaller teams and ensures efficiency. It's always interesting to see different workflows in action!
Consider a scenario where multiple teams working together and each team has there own environment and each has separate delivery goals.That is T1 code has to go to production June 1st week but T2 goal is only on July and there is only one develop branch for the apis(there is no team wise develop branch every teams feature and bug fixes gets merged to same develop branch).Whats the ideal branching strategy in that scenario?
A lot of developers consider GitFlow to be outdated and poorly optimized for modern development shops. What are your thoughts about trunk based development?
Thank you for your feedback! Trunk-based development is indeed gaining traction for its simplicity and speed. While GitFlow has its strengths, especially for controlled releases, many teams find TBD aligns better with modern CI/CD practices and reduces integration issues.
Trunk-based dev with feature flags and no branches (outside of an occasional spike/prototype branch) has been a huge benefit for our teams. We no longer have to think about deployments since they can happen as soon as code is pushed and all we ever have to talk about is when we're ready to release a feature by turning its flag on!
I've lost track of "git workflow" variations, but I do feel like "develop" branches are something I'm seeing less and less of lately. It would be interesting to do a statistical survey (wouldn't be hard to batch-scrape) from GitHub repositories to fit what recent trends in branch naming are.
Thank you for your insight! A statistical survey on branch naming trends sounds fascinating and could provide valuable insights into evolving workflows.
This is indeed something that's followed in most companies that are bigger than maybe 100 devs or so.
While indie devs or smaller companies may not find too much of a benefit from this, as you work with more devs you'll definitely want structure wherever you can implement it.
Good stuff!
Excellent! thank you for sharing such valuable information.
I have one question. suppose there are 10 developers working on different features and merging their branches into develop everytime. now we need to push only 2 features on main branch, it is feasible to make that new feature branch from develop branch? because develop branch contain all other modules.
I think we should create branch for new features from main branch only.
Thank you for your kind words! You're correct; if you need to push only specific features to the main branch, creating a feature branch from the main branch is a good approach. This way, you can ensure the feature branch contains only the desired changes without other developments from the develop branch. This approach maintains a clean and controlled release process.
I think git cherry-pick will do the trick for picking some feature from develop branch to production (main) branch.
Absolutely! Using
git cherry-pickis a great way to selectively apply specific commits from the develop branch to the main branch. However, there will be potential risks like introducing conflicts or other issues.Hello this is a sample text
"Looks like this sample text skipped the develop branch and went straight to production!"
Great post Amit! Thanks.
Thank you :)
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more