[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” /][/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″ module_alignment=”left” max_width_tablet=”50px”]
Originally published: IT Jungle on 3/03/2015
Updated author notes: The GitHub.com interface is always changing so please be cognizant of that when navigating their site as it relates to the screenshots in this article.
In the [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 is 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 we need to setup 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.
They 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 on 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 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/et9cDxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxiz//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 setup 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 the [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’d 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” our 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 ice-burg. Git has many features and is flexible because it has to be – it manages entire operating systems of source code (the reason for it’s 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!
[/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” module_alignment=”left”]
Need Git training for your IBM i developers? Let’s chat.
[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]