[et_pb_section bb_built=”1″ fullwidth=”on” specialty=”off” _builder_version=”3.0.64″ next_background_color=”#000000″][et_pb_fullwidth_post_title admin_label=”Blog Post Header” _builder_version=”3.17.2″ title=”off” meta=”off” categories=”off” comments=”off” featured_placement=”background” text_orientation=”center” module_class=”blog_post_header” title_font_size=”60px” background_blend=”saturation” title_font=”Raleway|on|||” title_text_color=”#274060″ title_letter_spacing=”2px” meta_font=”Raleway||||” meta_font_size=”20″ meta_text_color=”#274060″ meta_letter_spacing=”2px” background_position=”bottom_center” /][/et_pb_section][et_pb_section bb_built=”1″ _builder_version=”3.0.63″ prev_background_color=”#000000″][et_pb_row _builder_version=”3.0.63″][et_pb_column type=”4_4″][et_pb_text admin_label=”Blog Post” _builder_version=”3.17.2″]
Originally published: IT Jungle on 2/10/2015
Updated author notes: IBM is now delivering Git for IBM i in license program 5733OPS. Use IBM’s version instead of the one reference in this article.
In the last article we learned about Ruby methods and encapsulation.
During the various exercises, there were many code changes made and we didn’t really have a simple way to keep track of how the code changed from one version to the next. That’s where source change management (SCM) tools like git come into play and is what we will be diving into today.
The git website says: “Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.”
My history with SCM tools is Aldon for RPG, Subversion for Java, and a number of homegrown efforts. All served their purpose and I was glad to have them, but git has some very useful things that allow me to operate similarly to how my workday flows (i.e. work on 3 different projects and multiple versions within each of those projects at any given time). There are many ways and scenarios to use git and for this article, we will be focusing on setting it up on IBM i and maintaining a small local repository with an eventual goal of sharing it with other developers.
As we learned in the aforementioned description, git is a “distributed version control system” (DVCS for short). You can learn the benefits of DVCS by reading the git docs and also it would be good to read the Git Basics page as they describe it quite well. The main point to understand is that each developer has an entire copy of the repository in their environment. This means they can continue work and create “commits” even while not connected to the central repository. Then at a later time, they can choose to sync back up with the server.
For the purposes of this article, our development environment will be a directory in the IFS. This means your IBM i is actually the client in this scenario. The first step is to install git and the simplest way to do that is to obtain the free PowerRuby from PowerRuby.com. Git is also available here on the YiPs website.
Once git is installed you will need to start up a shell session via ssh or CALL QP2TERM – where most git interaction takes place. One of the first things you need to do is configure your git profile by entering the following two commands in PASE; make sure to replace with your pertinent information. These settings will be used to signify your changes vs. those of other developers.
$ git config --global user.email "me@domain.com" $ git config --global user.name "My Full Name"
Next, create a directory structure where the Ruby code will be stored. I like to create a directory named git with a sub-directory of each repository I am working with, itjungle_4_git in this case.
$ mkdir -p /home/aaron/git/itjungle_4_git
Now cd to the new directory and run the git init command to initialize this directory as a git repository.
$ cd /home/aaron/git/itjungle_4_git $ git init
Running command ls -la will show that you have a new .git directory.
This is where everything pertaining to this git repository is stored. Everything within, and including, the current directory is now part of this git repository. That means git will keep track of changes and additions made to files. To test this let’s use the echo command to direct some content to a file named README.md. Note, .md extensions stand for “Markdown” and is a very common file to have in the root of your git repository to describe the purpose of the files contained within.
$ echo "Some text" >> README.md
Now we can run the git status command to learn the repository status.
As you can see it recognized a new file was added and it is telling us to use git add to track it. Now run the following command to add README.md to the git repository.
$ git add README.md
Now if we run git status again we can see the file is being tracked and is ready to commit. A commit is a unit of work that marks a point in history of your repository. In a typical RPG scenario you might have changed an RPG module, added a copybook, etc. Each changed file would have the git add command invoked against it. It is also worth noting you don’t have to include all files you’ve changed. Sometimes I want to logically break things up based on the changes I’ve made and I use commits to accomplish that.
Now we are ready to commit this to the local repository (i.e. the .git directory) with the following command and corresponding message.
$ git commit -m 'Initial commit with README'
Running git status again shows us the following. Notice the 29293ec value. This is the commit hash that is computed based on the contents of all files. This gives us an exact representation of what all source files looked like at a certain point in history. This is a hugely beneficial feature, especially when application changes are coupled with database changes to learn about all parts of an application that changed in a single commit.
Now that the git repository is set up it is time to work through the motions of what we originally set out to do – create a history of the previous article’s Ruby code so we can see how it changed over time. To accomplish this I went through the motions of creating IFS files, changing them, and doing git add and git commit commands repeatedly. You can see the full shell history here and the commit history here (which was produced with the git log command). There are many ways to edit IFS files: RDi, RPGNextGen, EDTF, joe, or create a network mapped drive and use your favorite PC editor – you pick what works best for you.
You have now had your first exposure to git and I hope you can see some of the advantages of this technology. It’s worth noting we’ve only touched the tip of the iceberg of how git, and corresponding tools, can be used to aid in your source change management. Let me bait the hook by stating you can also use git for your RPG source code. Stay tuned for more on this topic in future articles!
[/et_pb_text][/et_pb_column][/et_pb_row][et_pb_row][et_pb_column type=”4_4″][et_pb_text admin_label=”Contact Form Title” _builder_version=”3.17.2″ background_layout=”dark” text_font=”Raleway|on|||” text_text_color=”#f45d01″ text_font_size=”26″ text_letter_spacing=”2px”]
We can help with your Git adoption!
Contact us.
[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]