GIT: HOW TO LIST BRANCHES(LOCAL/REMOTE)

Git is the best known distributed version control system at the moment. Sometimes you may require to list available branches within your git repository. In this post, we will see different ways to list available branches.

As we are aware GIT is distributed version control system, that said it has replicas of data locally and remotely repositories. This concept of remote and local applicable to branches as well. We can create local branches and do our work locally and once we are confident we can push those changes by creating a remote branch with the same name. This post is bit details on listing branches with examples for people who are new to git and experienced alike.

The listing of git branches has total three answers with the above explanation. Below are those three type of git branches.

Git list local branches
Git list only remote branches
Git list all branches

LIST ALL LOCAL GIT BRANCHES

git branch

Example:

surendra@linuxnix:~/code/sh/gittraining$ git branch
first_branch
* master

In the above output if you observe we have two branches locally available and master is my present branch(* indicates present branch) where I am located.

Note: We can execute git branch from any directory with in a repository.

LIST ALL REMOTE GIT BRANCHES

git branch -r

-r is for listing any remote branches our git knows.

Example:

surendra@linuxnix:~/code/sh/gittraining$ git branch -r
origin/HEAD -> origin/master
origin/master

LIST ALL REMOTE AND LOCAL GIT BRANCHES

git branch -a

Example:

surendra@linuxnix:~/code/sh/gittraining$ git branch -a
first_branch
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master

Note: If you observe above output, the coloring indicates remote(orange) and local branches(green)

GIT: How to Integrate Branches

Separating different topics into different branches is a crucial practice for any serious developer. By not mixing up code from one feature / bugfix / experiment with another, you avoid a lot of problems - and don't have to worry about breaking things in your development branches.

But at some point your code will (hopefully) reach a state where you'll want to integrate it with the rest of the project. This is where the "git merge" command comes in.

A Simple Example

Let's assume a very simple example scenario:

Our goal is to integrate the changes from "contact-form" back into "master".

Preparing to Merge

Before merging your code into one of your project's long-running branches (like a "development" or "master" branch), make sure that your local repository is up to date. Both your local feature / bugfix / <topic> branch and the receiving branch should be updated with the latest changes from your remote server.

Start with a "git fetch", followed by a "git branch -va":

$ git fetch
...

$ git branch -va
  master             87eab46 [behind 1] Fix #332
* contact-form       b320ab3 Ensure safe login

The [behind 1] remark tells us that "master" has received new changes on the remote. We must update "master" before we can integrate our own changes.

If properly configured, a plain "git pull" should suffice (after making "master" our active branch):

$ git checkout master
$ git pull

The last thing to check before actually starting the merge process is our current HEAD branch: we need to make sure that we've checked out the branch that should receivethe changes.

But since we just updated "master" and already performed a "git checkout master", we're good to go!

Starting the Merge

With such perfect preparation, the actual merge process itself is easy as pie:

$ git merge contact-form

Looking at our project's commit history, we'll notice that a new commit was created: a so-called "merge commit" that represents the actual "melting knot" that combines the two branches.

Our integration was successful and, if our feature work on "contact-form" is finished, we could safely delete that branch.

Dealing with Conflicts

Git will do what it can to make merging as easy as in our example. And in many cases, a merge will indeed be a walk in the park.

In some cases, however, the integration will not go as smoothly: if the branches contain incompatible changes, you will have to face (and solve) a "merge conflict". If you want to learn more about how to handle such a situation, have a look at Dealing with Merge Conflicts.

GIT: How to move a branch to a former status?

$git checkout branch

$git reset --HARD <SHA>

$git push --force origin ruby_on_pds_community_solr

GIT: Rebasing branches

36.1. Rebasing branches

You can use Git to rebase one branch on another one. As described, the merge command combines the changes of two branches. If you rebase a branch called A onto another, the git command takes the changes introduced by the commits of branch A and applies them based on the HEAD of the other branch. After this operation the changes in the other branch are also available in branch A.

The process is displayed in the following picture. We want to rebase the branch called branch_1 onto master.

Running the rebase command creates a new commit with the changes of the branch on top of the master branch.

Performing a rebase does not create a merge commit. The final result for the source code is the same as with merge but the commit history is cleaner; the history appears to be linear.

Rebase can be used to forward-port a feature branch in the local Git repository onto the changes of the master branch. This ensures that your feature is close to the tip of the upstream branch until it is finally published.

If you rewrite more than one commit by rebasing, you may have to solve conflicts per commit. In this case the merge operations might be simpler to be performed because you only have to solve merge conflicts once.

Also, if your policy requires that all commits result in correct software you have to test all the rewritten commits since they are "rewritten" by the rebase algorithm. Since merge/rebase/cherry-pick are purely text-based and do not understand the semantics of these texts they can end up with logically incorrect results. Hence, it might be more efficient to merge a long feature branch into upstream instead of rebasing it since you only have to review and test the merge commit.

You can use the rebase command to change your Git repository history commits.  This is called interactiverebase, see ? for information about this feature.

36.2. Good practice for rebase

You should avoid using the Git rebase operation for changes which have been published in other Git repositories. The Git rebase operation creates new commit objects, this may confuse other developers using the existing commit objects.

Assume that a user has a local feature branch and wants to push it to a branch on the remote repository. However, the branch has evolved and therefore pushing is not possible. Now it is good practice to fetch the latest state of the branch from the remote repository. Afterwards you rebase the local feature branch onto the remote tracking branch. This avoids an unnecessary merge commit. This rebasing of a local feature branch is also useful to incorporate the latest changes from remote into the local development, even if the user does not want to push right away.

Rebasing and amending commits is safe as long as you do not push any of the  changes involved in the rebase. For example, when you cloned a repository and  worked in this local repository. Rebasing is a great way to keep the history clean  before contributing back your modifications.

In case you want to rewrite history for changes you have shared with others you  need to use the -fparameter in your git push command and subsequently your  colleagues have to use fetch -f to fetch the rewritten commits. # using forced push git push -f

36.3. Example for a rebase

The following demonstrates how to perform a rebase operation.

# create new branch
git checkout -b rebasetest

# create a new file and put it under revision control
touch rebase1.txt
git add . && git commit -m "work in branch"

# do changes in master
git checkout master

# make some changes and commit into testing
echo "rebase this to rebasetest later" > rebasefile.txt
git add rebasefile.txt
git commit -m "create new file"

# rebase the rebasetest onto master
git checkout rebasetest
git rebase master

# now you can fast forward your branch onto master
git checkout master
git merge rebasetest

GIT: Using Branches

13.1. What are branches?

Git allows you to create branches, i.e. named pointers to commits. You can work on different branches independently from each other. The default branch is most often called master.

A branch pointer in Git is 41 bytes large, 40 bytes of characters and an additional new line character. Therefore, the creating of branches in Git is very fast and cheap in terms of resource consumption. Git encourages the usage of branches on a regular basis.

If you decide to work on a branch, you checkout this branch. This means that Git populates the working tree with the version of the files from the commit to which the branch points and moves the HEAD pointer to the new branch.

HEAD is a symbolic reference usually pointing to the branch which is currently checked out.

13.2. List available branches

The git branch command lists all local branches. The currently active branch is marked with *.

# lists available branches
git branch

If you want to see all branches (including remote-tracking branches), use the -a for the git branch command. See Remote tracking branches for information about remote-tracking branches.

# lists all branches including the remote branches
git branch -a

The -v option lists more information about the branches.

In order to list branches in a remote repository use the git branch -r command as demonstrated in the following example.

# lists branches in the remote repositories
git branch -r

13.3. Create new branch

You can create a new branch via the git branch [newname] command. This command allows to specify the commit (commit id, tag, remote or local branch) to which the branch pointer original points. If not specified, the commit to which the HEAD reference points is used to create the new branch.

# syntax: git branch <name> <hash>
# <hash> in the above is optional
git branch testing

13.4. Checkout branch

To start working in a branch you have to checkout the branch. If you checkout a branch, the HEAD pointer moves to the last commit in this branch and the files in the working tree are set to the state of this commit.

The following commands demonstrate how you switch to the branch called testing, perform some changes in this branch and switch back to the branch called master.

# switch to your new branch
git checkout testing

# do some changes
echo "Cool new feature in this branch" > test01
git commit -a -m "new feature"

# switch to the master branch
git checkout master

# check that the content of
# the test01 file is the old one
cat test01

To create a branch and to switch to it at the same time you can use the git checkout command with the -bparameter.

# create branch and switch to it
git checkout -b bugreport12

# creates a new branch based on the master branch
# without the last commit
git checkout -b mybranch master~1

13.5. Rename a branch

Renaming a branch can be done with the following command.

# rename branch
git branch -m [old_name] [new_name]

13.6. Delete a branch

To delete a branch which is not needed anymore, you can use the following command. You may get an error message that there are uncommited changes if you did the previous examples step by step. Use force delete (uppercase -D) to delete it anyway.

# delete branch testing
git branch -d testing
# force delete testing
git branch -D testing
# check if branch has been deleted
git branch

13.7. Push changes of a branch to a remote repository

You can push the changes in a branch to a remote repository by specifying the target branch. This creates the target branch in the remote repository if it does not yet exist.

If you do not specify the remote repository, the origin is used as default

# push current branch to a branch called "testing" to remote repository
git push origin testing

# switch to the testing branch
git checkout testing

# some changes
echo "News for you" > test01
git commit -a -m "new feature in branch"

# push current HEAD to origin
git push

# make new branch
git branch anewbranch
# some changes
echo "More news for you" >> test01
git commit -a -m "a new commit in a feature branch"
# push anewbranch to the master in the origin
git push origin anewbranch:master

# get the changes into your local master
git checkout master
git pull

This way you can decide which branches you want to push to other repositories and which should be local branches. You learn more about branches and remote repositories in Remote tracking branches.

13.8. Switching branches with untracked files

Untracked files (never added to the staging area) are unrelated to any branch. They exist only in the working tree and are ignored by Git until they are committed to the Git repository. This allows you to create a branch for unstaged and uncommitted changes at any point in time.

13.9. Switching branches with uncommitted changes

Similar to untracked files you can switch branches with unstaged or staged modifications which are not yet committed.

You can switch branches if the modifications do not conflict with the files from the branch.

If Git needs to modify a changed file during the checkout of a branch, the checkout fails with a "checkout conflict" error. This avoids that you lose changes in your files.

In this case the changes must be committed, reverted or stashed. You can also always create a new branch based on the current HEAD.

13.10. Differences between branches

To see the difference between two branches you can use the following command.

# shows the differences between
# current head of master and your_branch

git diff master your_branch

You can use commit ranges as described in Commit ranges with the double dot operator and Commit ranges with the triple dot operator. For example, if you compare a branch called your_branch with the master branch the following command shows the changes in your_branch and master since these branches diverged.

# shows the differences in your
# branch based on the common
# ancestor for both branches

git diff master...your_branch

See Viewing changes with git diff and git show for more examples of the git diff command.