How to pull Git remote branch? [3 Examples of command/GUI]

Prerequisites

You should have Git installed on your local machine. You can check if Git is installed on your computer and go through the installation process for your operating system by following this guide.

You’ll also need to have or create a GitHub account. You can do so through the GitHub website, github.com, and can either log in or create your account.

As of November 2020, GitHub removed password-based authentication. For this reason, you will need to create a personal access token or add your SSH public key information in order to access GitHub repositories through the command line.

Finally, you should identify an open-source software project to contribute to. You can become more familiar with open-source projects by reading through this introduction.

Video

#8. Check out the code

Always have two clones of a project on your computer at any one time. One for normal work, one for reviewing PRs. This way, you can put your current task on pause with zero overhead.

Once you have checked out the branch, press build and leave the build running while you switch back to the browser.

#12. Resist the urge to comment

The hardest thing about making comments is resisting the urge to make comments. The key to restraint is to be as hard on yourself as you are about to be on others. If you ever wonder how effective you are as a reviewer, go back through all of your comments and measure how many of your comments result in your suggestion being well received and implemented with minimal back and forth.

Here are some handy hacks to improve your comments:

What is a pull request?

Pull requests are the way we contribute to group projects or open source projects.

For instance, a user Harry forks a repository of ThanoshanMV and makes changes to that repository. Now Harry can make a pull request to ThanoshanMV, but it’s up to ThanoshanMV to accept or decline it. It’s like saying, “ThanoshanMV, would you please pull my changes?”

Examples of git pull

Working on a Branch

If you’re already working on a branch, it is a good idea to run git pull before starting work and introducing new commits. Even if you take a small break from development, there’s a chance that one of your collaborators has made changes to your branch. This change could even come from updating your branch with new changes from main.

It is always a good idea to run git status – especially before git pull. Changes that are not committed can be overwritten during a git pull. Or, they can block the git merge portion of the git pull from executing. If you have files that are changed, but not committed, and the changes on the remote also change those same parts of the same file, Git must make a choice. Since they are not committed changes, there is no possibility for a merge conflict. Git will either overwrite the changes in your working or staging directories, or the merge will not complete, and you will not be able to include any of the updates from the remote.

If this happens, use git status to identify what changes are causing the problem. Either delete or commit those changes, then git pull or git merge again.

Keep main up to date

Keeping the main branch up to date is generally a good idea.

For example, let’s say you have cloned a repository. After you clone, someone merges a branch into main. Then, you’d like to create a new branch to do some work. If you create your branch off of main before operating git pull, your branch will not have the most recent changes. You could accidentally introduce a conflict, or duplicate changes. By running git pull before you create a brach, you can be sure that you will be working with the most recent information.

Undo A git pull

To effectively “undo” a git pull, you cannot undo the git fetch – but you can undo the git merge that changed your local working branch.

To do this, you will need to git reset to the commit you made before you merged. You can find this commit by searching the git reflog. The reflog is a log of every place that HEAD has pointed – every place that you have ever been checked out to. This reflog is only kept for 30 to 90 days, depending on the commit, and is only stored locally. (The reflog is a great reason not to delete a repository if you think you’ve made a mistake!)

Run git reflog and search for the commit that you would like to return to. Then, run git reset --hard <SHA> to reset HEAD and your current branch to the SHA of the commit from before the merge.

Force git pull to Overwrite Local Files

If you have made commits locally that you regret, you may want your local branch to match the remote branch without saving any of your work. This can be done using git reset. First, make sure you have the most recent copy of that remote tracking branch by fetching.

git fetch <remote> <branch> ex: git fetch origin main

Then, use git reset --hard to move the HEAD pointer and the current branch pointer to the most recent commit as it exists on that remote tracking branch.

git reset --hard <remote>/<branch> ex: git reset --hard origin/main

_Note: You can find the remotes with git remote -v, and see all available remote tracking branches with git branch --all.

git pull with Rebase

If there have been new commits on both your local branch and the remote branch, a merge commit will be created when you git pull. This recursive merge is the default merge style when there are two splits in history being brought together. But, you may want history on a branch to be only one line.

You can update your local working branch with commits from the remote, but rewrite history so any local commits occur after all new commits coming from the remote, avoiding a merge commit. This is done with git pull --rebase.

Using git pull --rebase does not affect the integrity of the changes or the commits, but it does affect how history looks in the commit parent/child relationship.

Git Pull: Going Deeper

Time to understand git pull more in-depth.

What Is Git Pull, Really? How Does It Work?

Git pull, in a nutshell, is a two-part process. First, your remote-tracking branch is synced with the “true” branch in the remote repository.

Then, your local branch is compared to the remote-tracking branch and receives the new commits so it can catch up to the current state of the remote branch.

What Is the Difference Between Pull and Fetch in Git?

It’s common for beginners to mix up git pull and git fetch. Despite being related, they’re two different operations. Let’s see how they’re similar and how they’re not.

Git fetch, to put it simply, is the process of updating the remote-tracking branches. When you run this command, Git fetches the new commits from the remote. After fetching, you can merge the received commits into a local branch, using git merge.

And what about git pull? You can think of this command as a shortcut: it does all of the above in a single step. In other words: git pull = git fetch + git merge.

Git Pull vs. Git Push: What’s the Difference?

Another common question beginners have when it comes to git pull is how it compares with git push.

Well, they’re similar in that they’re both very common commands in Git and both are related to network operations. However, when it comes to results, they couldn’t be more different—they’re opposite operations.

Pulling means getting commits from the remote. Pushing means sending things to the remote.

Make Changes Locally

To demonstrate making a pull request, let’s use the example cloud_haiku repo and create a new file in our local copy. Use your preferred text editor to create a new file so that we can add a new haiku poem as explained in the contributing guidelines. For example, we can use nano and call our example file filename.md. You’ll need to call your file an original name with the .md extension for Markdown.

Next, we’ll add some text to the new file, following the contributing guidelines. We’ll need to use the Jekyll format and add a haiku with line breaks. The following file is an example file, as you’ll need to contribute an original haiku.

filename.md

Once you’ve included your text, save and close the file. If you used nano, do so by pressing CTRL + X, then Y, and then ENTER.

Once you have modified an existing file or added a new file to the project of your choice, you can stage it to your local repository, which we can do with the git add command. In our example, filename.md, we will type the following command.

We passed the name of the file we created to this command to stage it to our local repository. This ensures your file is ready to be added.

If you are looking to add all the files you have modified in a particular directory, you can stage them all with the following command:

Here, the full stop or period will add all relevant files.

If you are looking to recursively add all changes including those in subdirectories, you can type:

Or, alternatively, you can type git add -all for all new files to be staged.

With our file staged, we’ll want to record the changes that we made to the repository with the git commit command.

Git pull discussion

You can think of git pull as Git’s version of svn update. It’s an easy way to synchronize your local repository with upstream changes. The following diagram explains each step of the pulling process.

You start out thinking your repository is synchron

You start out thinking your repository is synchronized, but then git fetch reveals that origin’s version of main has progressed since you last checked it. Then git merge immediately integrates the remote main into the local one.

Let’s make our first pull request!

If you’re not very familiar with Git & GitHub, please go review The beginner’s guide to Git & GitHub.

1. Fork the repository

Fork the repository by clicking the fork button on the top of the page. This will create an instance of that entire repository in your account.

2. Clone the repository

Once the repository is in your account, clone it to your machine to work with it locally.

To clone, click on the clone button and copy the link.

Open the terminal and run the following command. It will clone the repository locally.

Now we have set up a copy of the master branch from the main online project repository.

We need to go to that cloned directory by running this command:

3. Create a branch

It’s good practice to create a new branch when working with repositories, whether it’s a small project or contributing to a group’s work.

Branch name should be short and it should reflect the work we’re doing.

Now create a branch using the git checkout command:

4. Make changes and commit them

Make essential changes to the project and save it.

Then execute git status , and you’ll see the changes.

Add those changes to the branch you just created using the git add command:

Now commit those changes using the git commit command:

5. Push changes to GitHub

In order to push the changes to GitHub, we need to identify the remote’s name.

For this repository the remote’s name is “origin”.

After identifying the remote’s name we can safely push those changes to GitHub.

6. Create pull request

Go to your repository on GitHub and you’ll see a button “Compare & pull request” and click it.

Please provide necessary details on what you’ve done (You can reference issues using “#”). Now submit the pull request.

Congratulations! You’ve made your first pull request.  

If your pull request is accepted you’ll receive an email.

7. Sync your forked master branch

Before submitting any pull requests to the original repository you have to sync your repository to the original one.

Even if you are not going to submit a pull request to the original repository, it’s better to sync with the original repository as some additional features and bug fixes may have been done since you forked the original repository.

Follow these steps to update/sync those changes to your master branch:

  1. First, check which branch you are in.

It’ll list all branches and indicates the current or active branch in green.

2. Switch to the master branch.

3. Add the original repository as an upstream repository.

In order to pull the changes from the original repository into your forked version, you need to add the original Git repository as an upstream repository.

Here, [HTTPS] is the URL that you have to copy from the owner’s repository.

4. Fetch the repository.

Fetch all of the changes from the original repository. Commits to the original repository will be stored in a local branch called upstream/master.

5. Merge it.

Merge the changes from the upstream/master into your local master branch. This will bring your fork’s master branch into sync with the upstream repository without losing your local changes.

6. Push changes to GitHub

At this point your local branch is synced to the original repository’s master branch. If you want to update the GitHub repository, you need to push your changes.

NOTE: After syncing your forked master branch you can remove that remote if you want to. But you’ll need to update/sync your repository in future too, so it’s best practice to keep it.

8. Delete the unnecessary branch

Branches are created for a special purpose. Once that purpose is accomplished, those branches aren’t necessary, so you can delete them.

You can delete the version of it on GitHub, too.

Git pull rebase instead of merge

The following example demonstrates how to synchronize with the central repository’s main branch using a rebase:

This simply moves your local changes onto the top of what everybody else has already contributed.

Tags