The idea behind using feature branches is that feature development takes place in a dedicated branch rather than disturbing the base branch. It also allows different contributors to the project to work on the same feature. The feature branch is only merged with the base branch after the PR is approved by peers. This also encourages collaborative workflow in the project.

Ideally it is encouraged to follow this branch structure:

develop -> Base branch for development

staging -> Staging environment

beta -> Beta environment (optional)

master -> Production environment

In this guide, develop is considered as the base branch.

The Feature branch workflow insists instead of committing directly to their local develop branch, developers create a new branch every time they start work on a new feature. Feature branches should have descriptive names, like animated-menu-items or issue-#1061. The idea is to give a clear, highly-focused purpose to each branch. Git makes no technical distinction between the develop branch and feature branches, so developers can edit, stage, and commit changes to a feature branch.

The following is a walk-through of the life cycle of a feature branch.

All feature branches are created of the latest code state of a project.

git checkout develop

git fetch origin

git reset –hard origin/develop

This switches the repo to the develop branch, pulls the latest commits, and resets the repo’s local copy of develop to match the latest version.

Use a separate branch for each feature or issue you work on. After creating a branch, check it out locally so that any changes you make will be on that branch.

This checks out a branch called new-feature based on develop, and the -b flag tells Git to create the branch if it doesn’t already exist.

On this branch, edit, stage, and commit changes in the usual fashion, building up the feature with as many commits as necessary. Work on the feature and make commits like you would any time you use Git.

Rebasing is the process of moving or combining a sequence of commits to a new base commit. Rebasing is most useful and easily visualized in the context of a feature branching workflow. The general process can be visualized as the following:

From a content perspective, rebasing is changing the base of your branch from one commit to another making it appear as if you’d created your branch from a different commit.

The primary reason for rebasing is to maintain a linear project history. For example, consider a situation where the master branch has progressed since you started working on a feature branch. You want to get the latest updates to the master branch in your feature branch, but you want to keep your branch’s history clean so it appears as if you’ve been working off the latest master branch.

A more real-world scenario to use git rebase would be:

You have two options for integrating your feature into the master branch: merging directly or rebasing and then merging. The former option results in a 3-way merge and a merge commit, while the latter results in a fast-forward merge and a perfectly linear history.

Git rebase in standard mode will automatically take the commits in your current working branch and apply them to the head of the passed branch.

This automatically rebases the current branch onto develop, which can be any kind of commit reference (for example an ID, a branch name, a tag, or a relative reference to HEAD).

Running git rebase with the -i flag begins an interactive rebasing session. Instead of blindly moving all of the commits to the new base, interactive rebasing gives you the opportunity to alter individual commits in the process. This lets you clean up history by removing, splitting, and altering an existing series of commits.

This rebases the current branch onto develop but uses an interactive rebasing session. This opens an editor where you can enter commands (described below) for each commit to be rebased. These commands determine how individual commits will be transferred to the new base.

The rebasing edit commands are as follows:

If, instead of “pick”, you specify “squash”, Git applies both that change and the change directly before it and makes you merge the commit messages together. So, if you want to make a single commit from these three commits, you make the script look like this:

When you save and exit the editor, Git applies all three changes and then puts you back into the editor to merge the three commit messages:

When you save that, you have a single commit that introduces the changes of all three previous commits.

Push the feature branch up to the central repository

This command pushes a new feature to the central repository (origin), and the -u flag adds it as a remote-tracking branch. After setting up the tracking branch, git push can be invoked without any parameters to automatically push the new-feature branch to the central repository.

To get feedback on the new feature branch, create a pull request in Git.

Now teammates comment and approve the pushed commits. Resolve their comments locally, commit, and push the suggested changes to Git. Your updates appear in the pull request.

Before you merge, you may have to resolve merge conflicts if others have made changes to the repo. When your pull request is approved and conflict-free, you can add your code to the develop branch. Merge from the pull request in Github.