Trusted answers to developer questions
Trusted Answers to Developer Questions

Related Tags

communitycreator
remote
github

Working on remote feature branches

Dale Sande

Grokking Modern System Design Interview for Engineers & Managers

Ace your System Design Interview and take your career to the next level. Learn to handle the design of applications like Netflix, Quora, Facebook, Uber, and many more in a 45-min interview. Learn the RESHADED framework for architecting web-scale applications by determining requirements, constraints, and assumptions before diving into a step-by-step design process.

Creating the feature branch is pretty simple. However, if you need to work on a co-workers branch, there are a few additional steps to follow.

Tracking remote branches

My local .git/ directory will, of course, manage all my local branches, but my local repo is not always aware of any remote branches. To see what knowledge my local branch has of the remote branch index, I add the -r flag to git branch so it will return a list:

$ git branch -r

To keep my local repo 100% in sync with deleted remote branches, I make use of this command:

$ git fetch -p

The -p or --prune flag, after fetching, will remove any remote-tracking branches that no longer exist.

Switching to a new remote feature branch

Doing a git pull or git fetch will update my local repo’s index of remote branches. As long as co-workers have pushed their branch, my local repo will know that feature branch.

By doing a git branch, you will see a list of your local branches. By doing a git branch -r, you will see a list of remote branches.

The process of making a remote branch into a local branch to work on is easy, simply use the command:

$ git checkout new-remote-feature-branch

This command will pull its knowledge of the remote branch and create a local instance to work on.

Keeping current with the master branch

Depending on how long you have been working with your feature branch and how large your dev team is, the master branch of your project may be really out of sync from where you created your feature branch.

If you have completed your update before creating a pull request, you not only have to be up to date in order to merge your new code, you also have to be confident that your code will still work with the latest version of master.

This is where some alternate schools of thought show up. Some teams don’t mind if you PULL the latest version from master with the command:

$ git pull origin master

This will fetch and merge any changes on the remote repo into the local branch with all the changes, thus allowing your feature branch to be merged. This works for the purpose of merging, but it’s kind of gross on the branch’s history graph.

Other teams, however, are not fans of this process because pulling from the origin can screw up the feature branch’s history, and make it harder to perform more advanced Git features. So, in these situations, it’s best to REBASE O_O.

Rebase to the rescue

Rebasing a feature branch is not as scary as most make it seem. All a rebase does is take the updates of the feature branch and move them to a new spot in the history so that they will be on top of the latest version of master; i.e., it’s as if you just created that feature branch and made the updates. This creates a very consistent branch history that is easy to follow and easy to work with in all situations.

To rebase your local feature branch off of the latest version of master, follow these steps.

$ git checkout master                        
  /* ensure you are on the master branch */

$ git pull                                   
  /* pull the latest from the remote */ 

$ git checkout my-feature-branch             
  /* checkout the feature branch */

$ git push origin my-feature-branch          
  /* update your copy in the repo */

$ git rebase master                          
  /* rebase on the master branch */

$ git push origin my-feature-branch --force  
  /* force update the remote */

And that’s it. This process will ensure that you have the latest version of master, take the commits from your feature branch, temporarily unset them, move them to the newest head of the master branch, and then re-commit them. As long as there are no conflicts, there should be no issues.

Force push? But …

Yes, there are those who are not fans of force pushing, but in the case of a feature branch, this is ok. However, force pushing to master is a really bad idea.

When performing operations like rebasing, you are (in effect) changing the branch’s history. When you do this, you can’t push to the remote as the histories are in conflict and you will get rejected. To address this, add the --force flag to force push to tell the remote to ignore that error and replace the previous history with the new one you just created.

Conflicts

In a worst-case scenario, there will be a conflict. This will happen even if you did the pull directly from master into the feature branch. To resolve a conflict, read the error report in the command prompt. This will tell you what file has a conflict and where the conflict is.

When opening the file, you will see a deliberate break in the file’s content and two parts that are essentially duplicated but slightly different. This is the conflict. Pick one of the versions​ and delete all the conflict syntax injected into the document.

Once the conflict(s) is/are resolved, add the following correction back into the command line:

$ git add .

Once the new updates are staged, you can’t commit again as this process is inside a previous commit. So, you need to continue with the rebase:

$ git rebase --continue

If, for any reason, you get stuck inside a rebase that you simply can’t make sense of, you can abort the rebase:

$ git rebase --abort

As long as there are no other issues, the rebase will continue and then complete with an output of the updates.

RELATED TAGS

communitycreator
remote
github

Grokking Modern System Design Interview for Engineers & Managers

Ace your System Design Interview and take your career to the next level. Learn to handle the design of applications like Netflix, Quora, Facebook, Uber, and many more in a 45-min interview. Learn the RESHADED framework for architecting web-scale applications by determining requirements, constraints, and assumptions before diving into a step-by-step design process.

Keep Exploring