Git Pull vs Git Fetch: Choosing the Right Command for Your Feature Branch Workflow

Note: This post assumes you have a basic understanding of how Git works and the commands.

If you’ve ever tried implementing proper Git feature branch workflow when developing on a team, you have more than likely had to use either the command ‘git pull’ or ‘git fetch’ at some point throughout that process. While these commands are similar in intention, there are a few key differences that are important to understand in order to properly implement them into a feature branch.

Before diving into their differences, it’s important to note how they are similar. Both ‘pull’ and ‘fetch’ are used to download new data from a remote repository. This is vital in ensuring that your local repository matches the remote version, so that you are building features and merging features locally on the most recent build.

For those who may be unaware, here is a basic breakdown of the Git branch workflow:

The first thing you need to do is clone down the remote repository onto your local machine in whatever location you need it to be in by running:

$ git clone [url for repo]

Once you have the repo cloned, navigate to it from your terminal:

$ cd [folder name]

and run the command:

$ git branch

This allows you to see which branch you are currently working in as well as the other branches that exist in this repo locally.

In proper Git branch workflow, there should be a remote branch that is separate from the origin master branch where the project contributors can then branch off from and push features to. For this example, let’s say the branch is called ‘dev-master’. You will need to create a local branch that tracks that remote branch in order to branch off into your features. You do that through the command:

$ git checkout -b dev-master origin/dev-master

where the first argument after ‘-b’ is what you would like to name your local branch (it should typically be named the same as the remote version), and the second argument is which remote branch you want your local branch to track.

After that, you can now run:

$ git branch

again and you should see that you are currently on the new dev-master branch that is tracking the remove dev-master. From here, you will want to create another branch that you will merge your features into, and you do this through the command:

 $ git checkout –b [branch name]

(this branch is typically names something like ‘dev’ to specify that it is different from the remote tracking branch).

Once on your new branch, you can now begin building branches specific for features using the same command used to make the previous branch. Throughout the development process, be sure that you are making regular commits with detailed commit messages on what you changed. Once you are finished with the feature, you will want to navigate back to your local dev branch (not the remote tracking one) with the:

 $ git checkout [branch name] 

command and merge in your feature branch with:

 $ git merge [branch name]

The final steps in this process is where fetching and pulling come in.

After the feature branch is merged on your local dev branch, you will want to navigate back to your dev-master branch. While you were working on your feature, it is likely that changes have been pushed and merged to the remote dev-master branch. This means that before you can merge in your feature, you will need to pull down and merge from the remote branch to your local tracking branch.

It is at this point where you must decide if you want to fetch or pull.

$ git fetch origin [remote branch]

If you do a fetch, you are simply telling Git that you want to download the new data from the remote repository, but you don’t want to integrate it into your project files just yet. It is a great way to get an overall view of what was changed without directly affecting the files you were working on, making it seemingly harmless. This means that you can fetch as many times as you would like throughout your development process and you will never have to worry about your files being changed. When you are ready to integrate the changes, you would perform a merge just like you would for any other branch.

$ git pull origin [remote branch]

If you do a pull, you are essentially doing a fetch and a merge all in on command. It will fetch the files from whatever branch you specified, and automatically merge them into your current working branch. This often causes merge conflicts to be harder to combat, as you are then unable to review what changes were made individually before having them attempt to integrate into your project. Because of this, it is recommended that you do a ‘git pull’ only on a clean working copy.

With whatever option you choose, it is important to remember that you should not be integrating your new feature into the local remote tracking branch until after the pull request has been approved and merged into the remote branch.

To perform a pull request, simply do:

$ git push origin [local dev branch] 

in your terminal, then navigate to the Github repository on the client. You should be able to go into the repo, select the ‘Pull Requests’ tab, and create a new pull request from the branch you just pushed. If there are any conflicts, you will have the option to resolve them from the client, and then submit the request for review. It is then up to the administrator of the repository to approve this request and merge it into the remote dev-master branch.

Once approved, you can go back to your local remote tracking branch, preform a pull or a fetch, and begin working on the next feature following the same process as before.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.