Home Articles Git Branching

Git Branching

PDF Print E-mail

 

Variant Management is usually handled by branching the code at a specific point in time. Some folks use branches to plan releases or track features. We will show examples of these approaches in future articles. In this article, we address the most essential branching pattern which is branching from a known baseline (as represented by a tag). For this example, I created a new git repository and simply added one readme file containing a date and time stamp. I tagged the repository at several points to make it easier to understand the example.

 

[bob@myserver ~]$ mkdir gitexample

[bob@myserver ~]$ cd gitexample

 

[bob@myserver gitexample]$ git init

Initialized empty Git repository in /home/bob/gitexample/.git/

 

[bob@myserver gitexample]$ date > readme.txt

 

[bob@myserver gitexample]$ git add readme.txt

 

[bob@myserver gitexample]$ git commit -a -m'first commit'

Created initial commit de0d064: first commit

1 files changed, 1 insertions(+), 0 deletions(-)

create mode 100644 readme.txt

 

[bob@myserver gitexample]$ git tag v1.0

 

[bob@myserver gitexample]$ git show v1.0

commit de0d0643cf32a032bb31cd9791ec758fb7d03348

Author: Bob Aiello < This e-mail address is being protected from spambots. You need JavaScript enabled to view it >

Date: Wed May 30 17:07:23 2012 -0700

 

first commit

 

diff --git a/readme.txt b/readme.txt

new file mode 100644

index 0000000..184f470

--- /dev/null

+++ b/readme.txt

@@ -0,0 +1 @@

+1. Wed May 30 17:06:55 MST 2012

 

At this point I have one readme file with a single date stamp that has been labeled v1.0. Next I will add another date stamp, commit the change and then baseline again using a tag called v2.0.

 

[bob@myserver gitexample]$ date >> readme.txt

 

[bob@myserver gitexample]$ git commit -a -m'second time'

Created commit 907832f: second time

1 files changed, 1 insertions(+), 0 deletions(-)

 

[bob@myserver gitexample]$ git tag v2.0

 

Next we examine (using the git show command) the two tags that were just created – v1.0 and v2.0. Note the cryptographic hash on the commit as shown below.

 

 

[bob@myserver gitexample]$ git show v1.0

commit de0d0643cf32a032bb31cd9791ec758fb7d03348

Author: Bob Aiello < This e-mail address is being protected from spambots. You need JavaScript enabled to view it >

Date: Wed May 30 17:07:23 2012 -0700

 

first commit

 

diff --git a/readme.txt b/readme.txt

new file mode 100644

index 0000000..184f470

--- /dev/null

+++ b/readme.txt

@@ -0,0 +1 @@

+1. Wed May 30 17:06:55 MST 2012

 

[bob@myserver gitexample]$ git show v2.0

commit 907832f7650b5c504ec7c41d3d418f25d27a9e2c

Author: Bob Aiello < This e-mail address is being protected from spambots. You need JavaScript enabled to view it >

Date: Wed May 30 17:09:05 2012 -0700

 

second time

 

diff --git a/readme.txt b/readme.txt

index 184f470..b861d3f 100644

--- a/readme.txt

+++ b/readme.txt

@@ -1 +1,2 @@

1. Wed May 30 17:06:55 MST 2012

+2. Wed May 30 17:08:40 MST 2012

 

The branch can be created using the hash associated with v1.0. I verify that the readme.txt file has two date stamps as expected. Then I checkout the branch created based upon the first baseline and verify that the readme file has only one date stamp as expected. We have effectively gotten into our version control time machine and created a branch for our development using the original baseline. This is exactly what you need to do when you are creating a bugfix branch.

 

[bob@myserver gitexample]$ git branch br1.0 de0d0643cf32a032bb31cd9791ec758fb7d03348

 

[bob@myserver gitexample]$ cat readme.txt

Wed May 30 17:06:55 MST 2012

Wed May 30 17:08:40 MST 2012

 

[bob@myserver gitexample]$ git checkout br1.0

Switched to branch "br1.0"

 

[bob@myserver gitexample]$ cat readme.txt

Wed May 30 17:06:55 MST 2012

 

 

 

Using the cryptographic hash as the starting point helps me to really understand how git works, but it's pretty ugly. Let's try creating branches based upon the tag names which is much easier to read. In the following example, we create branch br-v1.0 based upon tag v1.0. We then checkout the branch that we just created and verify that we only see one datestamp.

 

[bob@myserver gitexample]$ cat readme.txt

Wed May 30 17:06:55 MST 2012
Wed May 30 17:08:40 MST 2012

 

[bob@myserver gitexample]$ git branch br-v1.0 v1.0


[bob@myserver gitexample]$ git checkout br-v1.0

Switched to branch "br-v1.0"

[bob@myserver gitexample]$ ls -lt

total 4

-rw-rw-r-- 1 bob bob 32 May 30 18:09 readme.txt

[bob@myserver gitexample]$ cat readme.txt

1. Wed May 30 17:06:55 MST 2012

Next we will create a new branch based upon the v3.0 tag. This time checking out the new branch that we just created shows the readme file with the second datestamp.

[bob@myserver gitexample]$ git branch br-v3.0 v3.0

[bob@myserver gitexample]$ git checkout br-v3.0

Switched to branch "br-v3.0"

[bob@myserver gitexample]$ ls -lt

total 4

-rw-rw-r-- 1 bob bob 64 May 30 18:11 readme.txt

[bob@myserver gitexample]$ cat readme.txt

1. Wed May 30 17:06:55 MST 2012

2. Wed May 30 17:08:40 MST 2012

 

 

 

Git has some pretty cool features and effective use of tags and branches are essential for managing baselines and code variants. Please drop me a line and tell me about your own experiences coming up to speed with Git!

 

 

 

 



More articles by this author

Micro Focus Completes Acquisition of Serena Software, Inc. Application Lifecycle Management Acquisition Boosts Micro Focus’s DevOps Capability ROCKVILLE, Md., May 2, 2016 /PRNewswire/ -- Micro Focus (LSE: MCRO.L) today announced the completion of its acquisition of Serena Software, a leading provider of Application Lifecycle Management (ALM) software, under the terms of the definitive agreement disclosed on March 22, 2016. "Our customers continue to look at DevOps as a way to deploy critical applications and services quickly and with greater reliability to meet business demands," said Stephen Murdoch, CEO, Micro Focus. "The Serena acquisition extends our ability to help customers meet these challenges so they can drive greater innovation faster with lower risk." According to industry analyst firm Gartner, "DevOps implementations utilize technology, especially automation tools, that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective."1  The experience and expertise which the Serena business brings will enable Micro Focus to help its customers develop and release applications and services faster, with greater speed and accuracy. Serena adds capabilities in software application development; software configuration and change management; and business process management to Micro Focus's portfolio of ALM solutions spanning mainframe environments, distributed systems and cloud. The combination of Micro Focus and Serena allows companies to better: Design and build business applications and services with greater accuracy, reliability and predictability; Continuously deploy existing core business applications on a wider variety of platforms to meet changing business needs; and Improve the speed and efficiency of new business services through automated release and deployment solutions. About Serena Software Serena is among the largest Application Lifecycle Management vendors with more than 2,500 enterprise customers. Serena helps the highly regulated large enterprise move fast without breaking things – increasing velocity of the software development lifecycle while enhancing security, compliance, and performance. More information is available at www.serena.com. About Micro Focus Micro Focus (LSE: MCRO.L) is a global enterprise software company helping customers innovate faster with lower risk. Our software helps customers build, operate and secure IT systems that bring together existing business logic and applications with emerging technologies to meet increasingly complex business demands. For more information, visit: www.microfocus.com. 1I&O Must Combine ITIL and DevOps to Deliver Business Value for Bimodal IT," by George Spafford and Ian Head, March 18, 2016.
Hi, I am excited to invite you to subscribe to our new online publication which provides guidance on Configuration Management Best Practices, Agile Application Lifecycle Management (including videos) and, of course DevOps. Our publication explains hands-on best practices required to implement just enough process to ensure that you can build software and systems that are reliable and secure. Based upon our new book, Agile Application Lifecycle Management - Using DevOps to Drive Process Improvement, the Agile ALM DevOps Journal seeks to promote a dialogue that is really needed in the industry today. We will discuss practical approaches to implementing the Agile ALM using DevOps best practices including continuous integration, delivery and deployment. We will also discuss process improvement strategies that work in large organizations that must comply with federal regulatory guidelines, along with smaller teams that may very well grow as they become successful. We are taking this journey together and our goal is to ensure that you have a voice and can share your experiences along with learning from other colleagues too. Enjoy Leslie Sachs's amazing column: Personality Matters and Bob Aiello's column: Behaviorally Speaking. We will also report on major incidents where organizations clearly need to improve on their ability to develop and deliver software effectively, including the recent Southwest systems glitches which resulted in thousands of flights being cancelled and thousands more being delayed. We will also bring you exciting technical product announcements such as jfrog's new xray, which helps to scan your runtime objects, including docker images, for vulnerabilities. This is an exciting time to be in the technology field. Join the revolution! You can submit your articles for publication to share your own knowledge and experience!  Subscribe to receive your copy and register so that you can comment online Bob Aiello http://www.linkedin.com/in/BobAiello @bobaiello, @agilealmdevops, @cmbestpractices This e-mail address is being protected from spambots. You need JavaScript enabled to view it  
 
Copyright © 2017 CM Best Practices. All Rights Reserved.
Joomla! is Free Software released under the GNU/GPL License.
 

Product News

Live Online Training

Jobs