In this tutorial, I’m going to cover the basics of how to open a program using Vim, make a small change to that program, save it then push the changed program up to the Github repository. All of this will be done from using the terminal so no extra programs need to be used. This is often the working scenario for people who work in a GUI-less environment or have to interface with headless servers. I’m taking into account that the person following this tutorial has already followed the instructions of setting up a Github account, repository and established an ssh key pair with their account. The instructions for setting up git are easy to follow and can be located here: https://help.github.com/articles/set-up-git.
Once a remote account and repository has been established then connected to a local directory, the rest is simply going through the motions of making it all work. For starters, open a terminal session such as Konsole, X-Term or whatever comes with the operating system.
Once the terminal is up and going then simply navigate to the directory that was created specifically for communicating with the established Github repository using git.
Now that we are working inside the established git directory, the next thing to do is open the particular program we are going to be working with. For this example, we are simply going to open the all-too-familiar “Hello World” starter using the Vi or (Vim) editor. Vim runs directly in the terminal rather than opening a separate program. This makes life much easier as we don’t have to leave the environment we are already working in. To open Vim and start working, just type in the following command:
Once this is executed, the terminal will automatically switch over to the Vim editor for making any necessary changes to the program.
Remember this is all happening without starting any external programs! Make any changes to the program using the Vim editor then save those changes. When the changes have been saved, Vim will automatically close and bring the user back to the command line where they left off.
The next step is to get a status report from git that shows us what has changed from the last time we accessed our local repository or git directory. The command to see any changes made is “git status”.
When this command is invoked, git is going to give a response that shows all the changes that have been made to any programs in the git directory we are currently working in.
In this case, we only modified one program and that modification is being reflected here in red text. If we had been busier and had multiple changes to many programs all in the same git directory, all those files would show in the list with hint notes of suggested actions based on the action to to do next.
In this basic example, we are simply going to invoke the command “git add” which is similar to clicking on a checkbox in a GUI and selecting the file to be added to the next operation. If there were more than one file, we could add one or a few to be added to our next commit which will get a specific message attached to it that lets others know what changes were made in case an entire group is working on the project the file is associated with.
Once the “git add” command is executed, git will not return any acknowledgement of what has been added unless the command is executed incorrectly. Sometimes I believe it would be nice to receive a confirmation of what has been added to our list but, I’m not a developer for git so they decide what is relevant and what isn’t.
Once all of the files to be added to the current commit have been added to our list of files, it is time to commit them to be pushed up to the remote repository. Git strongly suggests that comments be added to any commit as it is part of the “essence” of collaboration using a version control system (VCS). To make this process easy, we invoke the “-m” to our command and add a message to be associated with the file’s commit such as below.
The string contained in the quotes is the message to be added to our commit. This message will accompany all the files that were included in the “git add” process. As such, if we want to have a separate message associated with multiple commits, then only add certain files at a time that will receive any particular commit message. If for any reason the “-m” is left out of the commit syntax, the terminal editing program”nano” will execute by default and ask for the message to be attached to the commit. It’s much easier to just remember to include the “-m” in my opinion unless a person prefers the added step of using the nano editor.
When the commit command is executed, a message similar to the following will be displayed from git:
This message just reiterates the changes that were made to the file, the commit message that will be added to the commit as well as the relevant version control numbers that will be associated with the commit when pushed up. It should also be noted that it is completely acceptable to stop at this point and go work on something else. Each command is it’s own entity and therefore do not need to be executed immediately. For example, a person may want to only push all their changes to the remote repository on Friday afternoon or on Monday morning. Or, a person may simply run a cron job to have all their pushes done on a certain day of the week at a certain time automatically.
For this example though, we’re going to go through each step individually so that we get the basics of what’s going on before jumping into ideas of batch pushes or cron jobs. : )
The next operation to perform is just simply execute the command “push” like shown below:
Since this entire time we have been working in our established git local repository, the “push” command is going to push our local changes to our remote server repository located at Github. This how we share our work with others so we can all collaborate on the same project while working from anywhere. Once the “push” command is executed (in most circumstances) the following message will appear:
What this message is asking for is a password associated with a registered ssh key at the remote end. Having an ssh key pair is not a requirement to use Github VCS although, it should be noted that it is an excellent security and identity measure to verify that the changes being made in the repository are actually coming from you and not someone else. An ssh key pair is like a fingerprint that distinguishes a person and the computer they work on from everyone else in the world. Even if a person were to try and imposter someone from a different terminal, without the private key being on their machine to match with the public key registered at Github, the push would not be accepted. As such, a person needs to understand that using key pairs is beneficial from a security point of view but can also be a hindrance if working from a foreign machine.
From this point we type in our associated password that identifies us from everyone else and allows the ssh tunnel to push our code from our machine to the remote server securely and encrypted. When finished, git will give us a nice confirmation message that lets us know everything was completed as expected.
At this point we have finished editing our file and pushing it up to our remote repository and accomplished all of this without having to leave the terminal for any reason. The next step is to verify that our changes did in fact make it to their intended destination which involves opening a browser and navigating over to our Github account.
Once we do that, we should be able to go to the repository that is associated with our local git directory and find the file in question as well as the commit message we attached to that file.
As can be seen from this snippet image of the Github repository line, the file “hello_world.pl” was received and in the center is the commit message we added using the “-m” on thecommand line. Navigating the various links on Github will provide further details of our commit including the actual code and all associated changes highlighted for ourselves or others to refer to later.
I hope this tutorial has explained in detail the simplicity of using the command line to both edit files and push those edited files to the Github version control all done from the command line.
