If programmers knew exactly what they would need at a given point in time, all code would be a one time thing. Upgrades and updates wouldn’t exist. Products would be distinct and any change would warrant a brand new replacement. That is however, not the case. We have a versioning system in place for this reason.
A versioning system allows you to time travel your work. You can go back in time or forward so long as you marked the point. You can also have different versions of the same thing if you need to try out something. Even more to this is that the system supports collaboration so that many can work on the same product whilst enjoying all the fore mentioned features.
No one really holds a monopoly on ideas. There are different systems all aimed at versioning code albeit with specialized differences. I have four that come to mind. Git, Mercurial, Helix Core and Apache Subversion. For the purpose of this this article, we will use Git. Its the most popular of them all.
Think of the aforementioned examples as languages. So you cannot speak Mercurial in a Git universe. However the Git universe can have many worlds within which you can speak Git. We have BitBucket, GitLab and GitHub as world examples(among many more) within which you can speak Git. They all offer distinct services and its all a matter of preference. Think of this examples as cloud service providers.
Speaking git is simple; prefix a command with ‘git’. For kickers Open up a terminal and type ‘git’. A bunch of command suggestion is spat. This is the default help structure. They may seem intimidating but fear not; you will barely get to use most of them anyway.
This time we are going to use a git system to manage a marriage agreement between two developers developing the relationship.
Open a folder by typing ‘mkdir marriage’ Then type ‘cd marriage’. ‘mkdir’ tells the computer to {make a directory} that’s a folder. ‘cd marriage’ tells the computer to {change directory to marriage}. These are basic file operations not Git specific ones. Since Git needs a directory to point to; we give it one. The folder is now a project.
Now within the ‘marriage’ directory, type ‘git init .’ The period is important. This tells the Git system to {initialize everything within this project}. The period is a powerful command because it implies {apply the preceding command to all files in this project}.
Within the directory, create three text files namely; survival.txt, expectations.txt and auxiliary.txt. At this point you could ask Git {what is the project status so far?} by typing ‘git status’. The terminal will show the three files in red. The red highlights new changes done to the files but no Git action has been made to them.
At this point you probably want save the work at this particular point. Why? Because it gives Git a reference point to do some magic as we will come to observe. Typing ‘git add .’ simply tells Git to {stage all the work so far}. Staging meaning you are sure of the steps take thus far but it is a temporary measure. You can stage, do some more work and stage again. Staging is powerful in that you can undo all work that is yet to be staged that turned out to be a mistake.
Typing ‘git status’ will always yield two colors. Red is for work yet to be staged and green is staged work. Staging always precedes a commit. Commit is stage’s big brother.
Since you are sure that the three files will be sufficient to run project marriage, you decide to commit the changes. This is done by typing “git commit . -m’initial project files’ “. This implies {Git commit all files with the commit message ‘initial project files’}. A hash is appended if the command runs successfully. The number is guaranteed to be unique through out the commit history.
From now on, you can always ‘checkout’ a commit. Checkout allows you to hop to that specific commit. The unique number is very handy for this. You can type ‘git checkout <insert number here>’ to see files at that point in time.
To see your commit history just type ‘git log’. The out put will show details like time of commit, the commit messages, the respective times and the generated reference hash.
At this time You decide to invite your girlfriend into the project since, the terms set therein also affect her but since you don’t share location, you will have to upload it to the cloud. Whichever provider you choose, they must speak Git.
Enter Collaborations