In my previous article I gave you an insight into the new open source editor Orion on the IBM i.
If you haven’t yet read my Orion PowerWire article, it can be found here.
As promised in that article I said I would now move on to Git, which is closely integrated with Orion, and the majority of other IDEs.
So what is Git? Git is an open-source software package for software change management, which has recently been ported to the IBM i, thanks for that IBM.
IBM has ported this tool into option 6 of the Open Source Licensed Programs 5733OPS.
As a recap, here are all the parts of the 5733OPS licensed programs at this time, taken from the IBM fix central site.
• Option 1, Node.js v0.12 for i
• Option 2, Python 3.4 for i
• Option 3, Chroot and GCC for i
• Option 4, Python 2.7 for i
• Option 5, Node.js v4 for i
• Option 6, Git for i V2.8
• Option 7, Tools for i
• Option 8, Eclipse Orion for i
• Option 9, Cloud-Init for i
Additionally, IBM has provided a PTF group just for the open source products, it is SF99225.
On the IBM website, it states this PTF group will be updated every three to four months, although on a recent webcast, IBM hoped it would be more frequent than this.
Make sure you have installed PTF SI61060 to give the Git option.
Git is command line based, which we run in PASE – hold on there, I hear you say – ‘Green screen commands are fine, but UNIX ……’ – that would have been my comment a few years ago, but honestly, give it a go, it’s not as bad as you think!
How is Git different from other version control programs?
Traditionally we see change control systems on our IBM that are centrally based. The change control software will have a library/libraries of all our changes, we then check out a source, make our amendments, then promote up to test, production etc. All centrally managed.
With Git, all the developers have a local copy of all the changes/amendments, therefore, it makes no difference if we do not have a connection to the main server, we can still make all our changes and have a full history of each change. If the main server has a failure, we can recover from any one of the local repositories.
A totally different way of thinking of change control than we have been used to over the past 30 odd years.
With Git, you do practically anything offline, because everybody has their own repository.
Git allows groups of people to work on the same source at the same time, and without stepping on each other’s toes. It’s a distributed version control system.
The files in a Git repository can be in one of the following states;
The basic Git workflow goes something like this:
• You modify files in your working area
• You stage the files, adding snapshots of them to your staging area
• You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory
• Then go back, using your favourite editor, to make you next set of changes.
Using Git Locally
In the first part of this article, I’ll show you how we can use Git locally. This will give us the opportunity to get in the mind set of Git with its own set of terminology and, hopefully, make incorporating Git with our IBM i straightforward.
Installing Git couldn’t be easier, get the download from https://Git-scm.com/downloads and run the executable.
Then using windows file explorer, pick a folder you will use to have a play with Git. Right click the folder and then select Git Bash Here (Bash is a command line emulator to Git).
Typing in Git –version (two minus signs there), will show which version of Git we have installed.
The first stage we have to do is to tell Git our name and email address.
This is entered in the Bash emulation using the following syntax:
Git config –global user.name “Andy Youens”
Git config –global user.email “Andy@FormaServe.Co.Uk”
These are one-off commands; we don’t have to worry about them again.
To check our global settings, type the command Git config –list
Next, we tell Git we want to use its version control on this folder, by running the Git Init command.
This command creates a hidden folder called .Git – if we want to stop tracking our files, all we need to do is to delete this folder.
The rest of the time we can ignore this hidden folder; Git will take care of it for us.
So we now have a Git repository.
In my PowerWire directory, I have two text files, one called FormaServe.txt, which we will be making modifications to and a file call Settings.txt. The Settings.txt file contains configuration data that is only applicable to my machine, we do not want Git to move this around.
To get Git to leave alone our settings file, we create a file called .gitignore. This can easily be created within our emulator by using the touch command.
Then use your favourite text editor, I’m using Notepad++ here, to add the name of the file we want Git to ignore. We can also place wildcard names in the .gitignore file if we want to exclude multiple file names.
Let us now run git status.
We can see Git has now disregarded our Settings.txt file.
Remembering the first figure of this article, we are in the working directory.
Now we want to move our FormaServe.txt file to the staging area. This is achieved by running the command Git Add FormaServe.txt (Be aware of case!)
Now the status shows the FormaServe.txt file in the staging area and the .gitignore file still in our working directory.
If you want to add all your files to the staging area use the Git add -A, or Git add . command.
Let us now do our first commit.
We use the command Git Commit -m “First Version” the comment in quotes is important, input something meaningful.
Git status now shows we only have the .gitignore in our working directory, everything else has been committed.
So tracking is now in place for our readme.txt file.
Another Git command to introduce here is the Git log command.
Below we can see our FormaServe.txt file committed on the 22/08, showing the commit text I entered.
So here we are, Git is now tracking our file – result!
Git Status shows we have nothing to commit now, everything is now in our repository, everything is committed.
Let us make a change to our readme file and start the process all over again.
Git status will now show we have modified our FormaServe.txt file, and it is not in the staging area, it is still in the working directory.
So let’s move it to staging using Git add . command
And viola, our file is now in the staging area.
As we now know, the next step is to commit them to our repository.
Once again, Git commit -m “with our message… “
Git log will now show our change history.
So you can now see the cycle we are going around.
To see the differences between two commits, we use the Git Diff command.
Hopefully, you all now have an insight into the basics of Git, next time we will show you how we can use your IBM i as a Git server.
Recap
So, a quick summary of the Git commands we have used:
Git init – Will make a directory known to the Git version control
Git config – show/update the current configuration
Git add file.name – will add a file to the staging area
Git commit -m “Commit message” – commits a file, or files, to the repository
Git log – will show the versions of our files
Git status – provides a status of where your files are at that moment in time.
Git diff – will show the difference of versions
Top Tip – Use clear command in Git Bash to give you a clean window.
Conclusion
If you are used to some of the main stay IBM i change control applications like Remains TD/OMS or Turnover etc., they provide, as to be expected, greater functionality over Git, for example, Git will not know that if you change a physical file/table you need to recompile all the programs that reference it, but as an option, take a look at Git, it is available on our favourite server and it is well worth a look.
In my next article, I will explore how we can use different IDEs, RDi, Zend Studio, Orion, to fully utilise Git into our development cycle and use some of the more advanced features such as branching.
Don’t forget the next i-UG meeting on 19th October 2016, held in Wolverhampton UK. Details can be found at https://www.i-ug.co.uk/#!i-ug-event-registration-page/c1pb7/?utm_source=SM&utm_medium=SM&utm_campaign=JUNE
Andy Youens is an IBM i consultant/instructor at Milton Keynes, UK-based FormaServe Systems.