Git is a powerful distributed version control system that not only preserves the history of your code but also facilitates collaboration for development teams.
Branches are at the heart of Git’s workflow, making it easy to experiment, fix bugs, and develop new features without messing with your main codebase. You can create, delete, compare, merge, rebase, publish, and track changes — all without breaking a sweat.
Whether you’re working independently or as part of a team, understanding how to use branches effectively will elevate your Git workflow. Let’s dive in.
A remote branch is a reference to a specific commit that exists on a remote repository, such as GitHub, GitLab, or Bitbucket. Remotes allow developers to collaborate effectively by keeping track of changes made by others and ensuring everyone stays in sync.
Remote branches are essential for sharing code, reviewing updates, and maintaining a smooth workflow in team projects. They help developers stay aligned with the latest changes while providing a structured way to contribute without interfering with the main branch.
At this point, you might be wondering, how do you switch between branches? We’ll cover checking out a remote branch in detail later in this guide. For now, just know that this process plays a key role in making remote branches such a powerful collaboration tool.
Before working with remote branches in Git, let’s discuss a few prerequisites:
Make sure that you have Git installed on your local machine. If you are unsure, verify the status with the following command:
git -v or Git –version
Whether you’re working solo or in a collaborative environment, ensure you have a local copy of the remote repository. Run the following command to clone said repository:
git clone <repository URL>
Familiarity with basic Git commands like pull, status, merge, etc., makes managing remote branches less daunting.
Knowing the available remote branches is good practice, especially in a collaborative environment. While this is possible with the graphical user interface (GUI), working in the command line is the best practice — not to mention that it’s faster. This section will cover different ways to view and manage remote branches effectively.
If you are going solo or in a collaborative environment and you want to view or list out all the branches that exist on the remote repository, you can use the following command:
git branch -r
The -r flag ensures that the list only contains remote branches. Below is an example of what it would return:
origin/HEAD → origin/mainThe main branch is the default branchorigin/develop — A develop branch that exists remotelyorigin/feature/auth — A feature/auth branch that exists on the remote repositoryorigin/feature/post-ad — A feature/post-ad branch that exists remotelyorigin/main — A main branch that exists remotelyIt is important to note that a remote repository can have from one to any number of branches, depending on the project.
To list out all the local and remote branches, use the following command:
git branch -a
This is an example of what the command will return:
git branch -r and git branch -aThe git branch -r command lists out only all the remote branches.
git branch -a, on the other hand, also lists out branches but combines both local and remote branches.
Git allows for comprehensive information about a specific remote repository, providing details like the remote repository’s branches, use, and many more. This is achieved using the following command:
git remote show origin
Your output will be:
Let’s discuss some of these elements:
Learn more →Fetch and pull URLs — Define where Git pulls from and pushes toHEAD branch — Shows that the main branch is the default branch of the remote repositorygit pull — Define which local branches are tracking the remote branchesgit push — Define which local branches are set up for pushing changes to the remote repositorySometimes, there are just too many branches. You might want to filter out the ones of interest so you don’t have to mindlessly wade through the entire list. To filter remote branches, you can use the following command:
git branch -r |grep feature
This lists out all the remote branches that have feature in them. The output looks like this:
In Git, developers have a fair amount of freedom in how they name branches. If the project is collaborative, naming conventions are typically specific to the team.
Still, Git enforces a small set of naming rules that must be abided by when naming branches. The rules are as follows:
. at the beginning of the branch path component (e.g., origin/feature/.new-feature).lock since it is a reserved extension.. (e.g., origin/feature/new..feature)@{If you break any of these rules while naming a branch, Git will refuse to create the branch and throw up an error telling you exactly what’s wrong. You can also check if a name is fit for a branch name by running the following command:
git check-ref-format –branch <branch name>
If the branch name is valid, that command will return the name. If the name violates any of the Git branch naming rules above, it returns an error message.
Fetching is how Git downloads all of the changes committed to a remote repository. Fetching also allows you to review them before merging into your local branches.
git fetch?When a remote repository is cloned from a remote server to a local repository, all the remote branches are not mapped to local branches on the local repository by default. This happens no matter how many branches there are inside.
git fetch is a Git command that helps download the changes committed to a remote repo. It allows you to review the changes before you make the decision to merge the revisions into the local branches. This command updates the remote-tracking branches, ensuring that you can work on the most recent version of the remote repository.
Start with the command:
git fetch origin develop
This will generate the following:
Fetching is not exclusive to only one remote repository; there are also cases where there are multiple remote repos. If that’s the case, use this command:
git fetch - - all
Fetching before checking out is critical. The process guarantees that you have the latest information on your remote branches. Let’s take, for instance, a case where a features/auth branch is created locally when it already exists remotely. In this case, there is no way local Git will know. This means a duplicate branch is created locally and does not keep track of the remote branch.
If you run git pull, there will be conflicts. To avoid that unnecessary headache, git fetch first, then git checkout -b <branch name>
git pull vs. git fetchUnder the hood, we have git pull as a shortcut for git fetch, followed by git merge. So, git fetch downloads all the commits or changes from the remote repository into the local repository. This is Git’s internal database (.git folder) where changes are stored and managed but not placed into the working tree. The working tree shows the current state of your files that are actively edited on your local machine.
For changes to reflect on the working tree, you can then run git merge. You won’t see any visible effect on the working tree without this last command.
The git checkout command tells Git which branch should receive new commits and changes. A branch is simply a pointer to a specific commit, and a commit represents a snapshot of your repository at a given point in time.
There are several ways to check out a branch. In this section, we’ll explore different methods for checking out a remote branch and discuss best practices for setting up tracking branches.
git checkout -bStart with the following:
git checkout -b <local branch name> <remote name>/<remote branch name>
Let’s break down these elements:
-b — This flag will create a new local branch<local branch name>—This is the name of the local branchremote name>/<remote branch name> — This specifies the remote branch you want to track with the local branch you intend to createHere’s an example:
git checkout -b develop origin/develop
Followed by the output:
checkout <remote name>/<remote branch name>Unlike in method one, the command git checkout origin/develop does not create a local branch for tracking a specific remote branch. Instead, Git enters a detached HEAD state, meaning any changes you make won’t be associated with a branch and could be lost when switching branches.
If you find yourself in a detached HEAD state but want to create a local branch from it, use:
git checkout -b <new-branch-name>
This creates a new local branch based on the detached HEAD, ensuring that you can save and push your changes properly:
So, what are tracking branches? They’re local branches that maintain a direct connection to a corresponding remote branch. This setup ensures that when you run git pull or git push, Git knows exactly where to fetch changes from and where to push updates.
Using the recommended git checkout method tells Git to automatically set up a relationship between a local and remote branch, where the former automatically tracks the latter.
It’s always good practice to confirm that you’re on the intended/correct branch before pushing commits/changes. To verify your current branch, use the git branch command.
This command lists all local branches, but the current branch is highlighted with an asterisk:
git status works just like the git branch in showing your current branch. This command gives us more details, including the tracking information:
git branch -vv checks if the branches are correctly tracking their corresponding remote branches. It basically shows us the tracking information for all the local branches:
To keep your local working tree up to date, you’ll need to merge your local branch with its remote counterpart. But how does this work in practice?
When you set up a remote branch, Git maintains local copies of all remote branches. These copies reflect the state of the remote branch as of your last git pull or git push.
The git pull origin <remote-branch-name> can be used. In context, this might look something like: git pull origin main.
Regularly pulling changes is a best practice — it keeps your local branch in sync with the latest updates from the remote repository and helps prevent merge conflicts down the line.
Even though Git is powerful, some things don’t happen automatically — like keeping your local list of remote branches updated. Here are a few common issues and how to fix them.
Git doesn’t automatically update your local list of remote branches when new branches are added or deleted.
To solve this, run the following command to refresh the list and remove references to deleted branches:
git fetch -prune
The command updates the list and prunes the references to deleted branches, if any.
In collaborative environments, a remote branch may be deleted, but it could still appear in your local list.
Simply remove stale remote branches with:
bash Copy code git remote prune origin
If you’re unsure whether a branch exists on the remote repository, check the available remote branches.
To solve this, list all remote branches with:git branch--r.
To ensure a smooth experience when working with Git, particularly with remote branches, here are some best practices to follow:
This will ensure that your local repository reflects the latest changes from the remote and removes references to deleted branches.
Before adding new commits, it’s good practice to pull the latest changes from the remote. This ensures your local branch is in sync with the remote, reducing the chances of conflicts.
This is especially the case when you are in a collaborative environment. This helps everyone on the team understand the purpose of the branch without extra explanation.
One of the most important things about working with Git in a team is having one feature in one branch. It is good practice to ensure that every feature or bug has its remote branch, allowing multiple people to work on multiple features without worrying about overriding each other’s code. Also, this style keeps things organized.
To ensure the stability of your main or master branch, avoid committing directly to it. Always create a new branch for your changes and open a pull request to merge your feature branch into the main branch. This process helps prevent untested code from introducing bugs into the codebase.
Mastering the process of using git checkout for remote branches is crucial for a smooth and efficient development workflow. By understanding how to check out, track, and update remote branches, you’ll have the tools you need to collaborate effectively, avoid common pitfalls, and streamline your Git practices.
This guide has provided an in-depth look at how to git checkout remote branch, along with key strategies for managing your branches and working in a team. By implementing these best practices, you’ll keep your Git workflow organized, minimize merge conflicts, and enhance collaboration within your development environment.
With these Git strategies under your belt, you’re equipped to take your version control skills to the next level. Happy coding!
Hey there, want to help make our blog better?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Check out Kiro, AWS’s AI-powered IDE, see what makes it different from other AI coding tools, and explore whether it lives up to the hype.
Here’s how three design patterns solved our Go microservices scaling problems without sacrificing simplicity.
Explore six principled design patterns (with real-world examples) to help you protect your LLM agents from prompt injection attacks.
As AI tools take over more routine coding work, some companies are cutting early-career dev roles — a short-sighted move that could quietly erode the next generation of tech leaders if we aren’t careful.
