A beginner’s guide to Git feature branches

Why Git

The proprietary software shaped the Version Control Systems (VCS) to fit its requirements:

the project has a strict release schedule

the team is collocated

the sprint goals are well-defined and the focus goes to a limited number of stories

branching is usually reserved for releases or risky development features

the centralized server is hidden from the outside world

This is the context in which centralized Version Control Systems (e.g. Subversion) have emerged, but that’s not a good fit for open-source projects because:

releases are not imposed by deadlines

the contributors may be scattered allover the globe

new ideas are welcomed, even if radical or time-consuming

branching becomes mandatory as developers work on features rather than sprints

the code is available to the whole world

Git is the quintessence of software development spirit. If the available tools are not suitable for your use cases you build your own tools. Git is a Distributed Version Control System (DVCS) addressing the impedance mismatch between open-source development and classic VCS.

When working with Subversion a User Interface like Tortoise SVN is more than sufficient, and I seldom had to use the Subversion command line. The trunk based development style simplifies the version control process and that’s why the UI can handle it.

Git offers multiple workflow styles to choose from. You can still use the trunk base development style (I use it for managing this blog source code examples), but if you plan on contributing to other open-source projects you have to get familiar with feature branching.

Why feature branches

Git makes branching a commodity and each feature can be developed in a separate branch. This is desirable since the merging process may be out of your control. If you develop on the default master default branch and a given committed feature is postponed, you will have to revert your changes prior to starting working on a completely different feature. Feature branching allows you to isolate changes and to simplify the merging process. But once you start using feature branches you realize that the command line is no longer optional. To properly understand Git and to successfully employ it, it’s advisable to first master its commands.

To notify the product owner of my contribution, we need to send a pull request:

The product owner can review the changes and decide if and when to merge them to the main branch. During the review process the product owner may ask for additional changes prior to merging your branch, so you need to:

commit new changes to the local metrics branch

re-squash commits to a single commit

force a push to your remote branch (e.g. git push -f)

As a rule of thumb, you don’t usually rewrite the commit history after you published your changes. This may affect other contributors that have used your branch as a starting point for their work. But your feature branch is not meant to be used by other contributors aside from the product owner who will only merge it once it’s ready.

Newsletter

Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

Email address:

Join Us

With 1,043,221 monthly unique visitors and over 500 authors we are placed among the top Java related sites around. Constantly being on the lookout for partners; we encourage you to join us. So If you have a blog with unique and interesting content then you should check out our JCG partners program. You can also be a guest writer for Java Code Geeks and hone your writing skills!

Disclaimer

All trademarks and registered trademarks appearing on Examples Java Code Geeks are the property of their respective owners. Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. Examples Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.