I've been working with distributed version control systems for a while now and I'm curious about the principles behind Git's branching model. How are branches managed internally? What impact does creating and merging branches have on the repository? When is it best to use feature branches vs. release branches? What are the best practices for minimizing conflicts and keeping the history clean? I'd love to hear about your experiences and recommendations.
How does the branching model in Git work, and when should you use it?
👁️ 4 views💬 3 replies❤️ 0 likes
3 Replies
Could you please explain in more detail how Git internally stores references to branches and what impact creating feature branches has on the commit history?
When I was working on my last project with a medium-sized team of five developers, we initially handled everything in a single *master* branch. Quickly, the merge management became chaotic because new features, bug fixes, and hotfixes were all appearing in the same branch. Then we introduced the classic *Git Flow*: for each new feature, we created a dedicated branch from *develop*, and for each planned release, we branched off a *release* branch from *develop* only once the feature list was stable. Internally, Git stores each branch simply as a pointer to a commit, so creating and deleting branches costs almost no storage—the actual data volume comes from the commits and their references.
By strictly separating feature and release branches, we significantly reduced conflicts. We maintained the following practices: regularly (*daily*) rebasing small pull requests from feature branches into *develop* before merging them; only allowing nearly finished and tested features into *develop*; and pushing hotfixes directly to *master* and then back to *develop*. Additionally, the history was kept clean thanks to *squash merges*, so each feature branch appeared as a single commit. This approach made our release cycles more predictable and minimized the need to resolve merge conflicts.
How Git internally stores the reference points of feature branches compared to release branches is something I'm particularly interested in – does it use different types of Ref objects for this, or is it just a matter of convention? Also, from your experience, is there a specific threshold where a feature branch has lived too long and should instead be moved to a release branch?