Git To GitHub

In my last article, the git tooling was introduced as a mechanism to track changes made to source code. This article expounds on that by showing how to make your local IFS git repository (“repo” for short) publicly available to others. I say “publicly” because that is the purpose of this article, though it could just as easily be applied to a situation where you wanted a private repo for a specific set of users (i.e., co-workers and/or consultants).

For the purposes of this article we will be walking through setting up a GitHub.com public repo. Note, GitHub has been the largest open source website in the world since about 2011 (beating out the likes of sourceforge.net).

First head over to GitHub.com and create an account (free and easy, so I won’t be documenting the process). Next set up SSH key-based authentication between your IBM i machine and profile, and your newly created GitHub account. SSH keys are a way to authenticate without the need for passwords, which can speed up software development without sacrificing security.

The way SSH keys work is you need to generate a key on your IBM i that can then be input into your GitHub account. To generate a key you will need the no charge license program. “5733SC1 IBM Portable Utilities for i5/OS *BASE & Option 1,” which includes the ssh-keygen command.

From the command line do CALL QP2TERM (to get into a PASE shell) and run the ssh-keygen command, as shown below. You will be prompted for a passphrase for the key being created. You can enter one or leave it empty. You can recreate it later with a passphrase if you leave it empty for this tutorial.

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/AARON/.ssh/id_rsa): /home/aaron/.ssh/id_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/aaron/.ssh/id_rsa.
Your public key has been saved in /home/aaron/.ssh/id_rsa.pub.
The key fingerprint is:
ac:99:a4:99:a6:99:6e:99:70:99:a2:99:99:99:fa:99 aaron@ibmi_name.COM

If the .ssh directory didn’t exist in your /home directory it will be created. What will also be created are the id_rsa and id_rsa.pub files, as shown below.

-bash-4.2$ ls -a /home/aaron/.ssh
id_rsa       id_rsa.pub   known_hosts

The id_rsa.pub file’s contents is what we need to copy and paste into the newly created GitHub account. Use the cat command to display the contents to the screen or open the file with the editor of your choice. I masked the code below with x’s so I don’t expose my key to the world.

$ cat /home/aaron/.ssh/id_rsa.pub
ssh-rsa
JuXZgxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxH8y/vc09XUXXx+Y
AAAABxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx7/GFrYolIvf
2GxdtxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxkItjoo3POIG2slEOLc
UAFOoAFiYdxxxxxxxxxxd/7uC4lYYVwNwk1Lc8W6qcOlSK/et9cDxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxiz//ffQkfbgI77HboKSAaLtxzu31rT/CIpFlgRU4bCQ== 
aaron@ibmi_name.COM

Now go to your GitHub account and click the cog icon (a.k.a. settings) so we can add the SSH key we generated in the previous step.

Once on the settings page select the SSH keys tab, then select Add SSH key, then enter the Title and Key, and finally select the Add key button.

At this point your IBM i is set up to communicate with your GitHub account and the next step is to create a GitHub repo that we can place our IFS code into.

Using the below screenshot, start the process of creating a new GitHub repository.

On the next page you will be presented with the below form where you will specify the name of the repository and whether it is public or private.

After selecting the “Create repository” button you should be redirected to a page declaring the full URL path and also some handy commands showing how to push an existing repository, which is our situation, to GitHub.

Now go back to the PASE shell session on your IBM i (i.e. CALL QP2TERM) and cd to the folder containing the git repo created in my last article as shown below.

$ cd /home/aaron/git/itjungle_4_git

Next, copy and paste command “git remote add origin…” from the GitHub page onto the command line and run it, as shown below. This declares the remote GitHub repo to our local repo so that when we do a “push” it will know where to push it to. If you like, you can use the git remote -v command to get a listing of existing remotes.

$ git remote add origin git@github.com:aaronbartell/itjungle_4_git.git

The last step is to “push” the local commits to the remote GitHub repo. This is done with the git push command, as shown below. Notice how we weren’t prompted for authentication? That’s the SSH key at work. Since we only have a single remote repo that we are connecting to the “-u origin master” portion of command git push is somewhat redundant. It is essentially declaring the name of the remote repo, origin, and the name of the branch to push to, master in this case. Uses for git branches will be covered in a future article, but for now you can read more about them here.

$ git push -u origin master
Counting objects: 22, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (22/22), 2.20 KiB | 0 bytes/s, done.
Total 22 (delta 1), reused 0 (delta 0)
To git@github.com:aaronbartell/itjungle_4_git.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

As we can see from the above log everything successfully made it to the GitHub repo, and we can prove that by bringing up the itjungle_4_git repo in the browser, as shown below.

Clicking on the “commits” link allows you to see how the code repo has changed over time in visual fashion (i.e. what files and lines within), as shown below.

And here we see the changes that took place in a particular commit. Very nice!

As I mentioned at the end of my last article, we are only touching the tip of the git iceburg. Git has many features and is flexible because it has to be; it manages entire operating systems of source code (the reason for its creation by Linus Torvalds, the primary creator of the Linux operating system). Play around some more on the GitHub site by exploring “Issues” and “Forking,” two features that have brought about the term “social coding”.

Stay tuned for more articles on Ruby and the Rails web framework!

Aaron Bartell is Director of IBM i Innovation for Krengel Technology, Inc. Aaron facilitates adoption of open source technologies on IBM i through professional services, staff training, speaking engagements, and the authoring of best practices within industry publications and www.litmis.com. With a strong background in RPG application development, Aaron covers topics that enable IBM i shops to embrace today’s leading technologies including Ruby on Rails, Node.js, Git for RPG source change management and RSpec for unit testing RPG. Aaron is a passionate advocate of vibrant technology communities and the corresponding benefits available for today’s modern application developers. Connect with Aaron via email at abartell@krengeltech.com. Aaron lives with his wife and five children in Southern Minnesota. He enjoys the vast amounts of laughter having a young family brings, along with camping and music. He believes there’s no greater purpose than to give of our life and time to help others.

RELATED STORIES

Git To It

Knee-Deep In Ruby Waters

Testing The Ruby Waters

Bash Is Not A Shell Game