Mastering git, Part 7, git branch

It quite often happens that a software product is on a git server and developers add new features to the product. To make the job easier, developers usually create branches beside the master branch (which is the default branch) and work on their branch and once the changes are confirmed and tested, they will be merged to the master branch. So let’s get started:

ok now let’s create two branches, one for developer1 and one for developer2,

git branch <BRANCH_NAME> creates a new branch but leaves you on the same branch.
git checkout -b <BRANCH_NAME> creates a new branch and checks out the new branch.

In Fact it does the following:
git branch # create a new branch
git switch # then switch to the new branch

let’s make some work on the first branches:

and some changes in the second branch:

now you should see this in git gui or if you go to Repositories> Visualize all Branch History or

You can add the later as an alias so you dont’t have to type it everytime:

Now in the git gui, go to merge>local merge and choose b1, you will get the following error because of the merge conflict:

so call the following to solve the conflict:

choose C and save and then:

 

Working with branches in nutshell:

Creating a local branch

or short version:

Creating a remote branch

First, you create your branch locally:

The remote branch is automatically created when you push it to the remote server:

you might want to make the relation persistent by using:

Other people in your team can reach your branch, by doing:

if instead of git checkout <branch-name> you use the following:

you will enter a enter a detached HEAD state.

Track a remote branch

If you have already created a local branch and you want to track it with remote branch you just pulled down, or want to change the upstream branch you’re tracking,:

Please pay attention to the -to at the end of “–set-upstream-to”. There is a depricated flag “–set-upstream” (without to at the end) which is no longer supported.

View branches

To view local branches

To see only remote branches:

To view both remote branches and local branches

To view branches of a remote: git remote show <remote-name>, i.e:

To see the tracked branches:

Deleting both local and remote branch

local and remote branches actually have nothing to do with each other, even if you’ve established a tracking connection. They are completely separate objects in Git and deleting one wouldn’t delete the other If you want any branch item to be deleted, you need to delete it explicitly.

To delete a local branches:

-D, which is an alias for –delete –force, which deletes the branch “irrespective of its merged status

To delete a remote branch:

As of Git v1.7.0, you can delete a remote branch using:

summary:

In most cases the remote name is origin.

Pushing into the wrong branch

Deeper Look

The way Git thinks about its data is what sets it apart from all other VCS (CVS, Subversion, Perforce, Bazaar, and so on). Most other systems store data in the form of a list of file-based changes. This is commonly described as delta-based version control

Image courtesy of git-scm.com
Image courtesy of git-scm.com

Git considers its data to be a set of snapshots of a miniature filesystem.
Any time you commit, or save the state of your project, Git takes a snapshot of all your files at that particular moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored.

When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged. This object also contains the author’s name and email address, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents):

  1. zero parents for the initial commit,
  2. one parent for a normal commit,
  3. multiple parents for a commit that results from a merge of two or more branches.

Let’s make an example:

Now we have 5 objects in our repository, 3 blob , which you can see them by:

one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata.

If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it.

A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you start making commits, you’re given a master branch that points to the last commit you made. Every time you commit, the master branch pointer moves forward automatically.

Because a branch in Git is actually a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy.

How does Git know what branch you’re currently on? It keeps a special pointer called HEAD.

 

Ref [1], [2], [3], [4]

0 0 votes
Article Rating
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x