In the world of programming, version control is one knowledge and concept that cannot be overemphasized. The word version control, cannot as well be mentioned without emphasis on a very popular tool called Git.
Git is a tool designed to coordinate work among programmers. It is a distributed version control system for tracking changes in source code during software development. Now that’s probably too ambiguous of a sentence, so let’s refrain from sounding like Wikipedia for a second.
For an illustration, imagine you had this beautiful website you built for a client, who suddenly has a change of heart, and asks for a change of color. Now that’s no big deal, we could simply rewrite our code and return for another review. Now imagine this client has you changing the background color back and forth, wouldn’t it be better to have a copy of all changes we’ve made to our code, so we don't have to rewrite it each time we want to return to a previous code? Well, that’s the basic problem solved by Git, and that in simple terms defines Version Control.
In this article, I’ll be introducing you to this very popular tool called Git, and hopefully getting you familiar with some basic codes, you will be using quite often. First, we’ll get over the codes, and then we will use them in a very simple scenario to help you understand more. To make the most of this guide, please ensure you have Git set up on your machine, if you don't already, check out Install Git on how to set up git in your machine. Also for the sake of this article, you should have at least a github account, and an idea about repos, github docs has a pretty good article on that.
FIRST A FEW TERMS TO UNDERSTAND
repo: This is a short term for the word repository, which is a file, in which a code is stored.
Github: a company that provides hosting for software development and version control using git.
Branch: Git’s branching functionality lets you create new branches of a project to test ideas, isolate new features, or experiment without impacting the main project.
Remote repo : a repo located on a hosting service. Eg GitHub
local repo: a repo located on your machine or computer, and accessible on that device.
Commit: a way to save changes to a local repo
BASIC GIT COMMANDS TO KNOW
git init: This initializes an empty git repository on your machine
git pull : This is used to update a local version of a repo from a remote one, and attempts to merge.
git fetch: this fetches the latest version of a remote repo, but does not merge them to the local repo.
git merge: attempts to merge the changes from a fetch request to the local repo
git push: pushes the latest version of a local repo to the remote repo on a hosting service
git status: this lists the current status of a local repo, usually displaying as modified, unstaged, or staged files.
git log : shows a broad list of commits in a repo
git log –oneline : shows a concise list of commits
git branch “branch name”: creates a branch with the name specified, without the quotes
git checkout “branch name”: enters git branch specified as branch name without quotes.
git checkout “commit id” : opens a read-only version of a previous commit, whose identification code is specified in “commit id”, without the quotes. This is generally considered safe.
git revert “commit id”: undo all changes before specified commit – considered fairly dangerous, but still safe.
git reset “commit”: completely reset a repo to the current commit, completely erasing all later commits. This is considered very dangerous and is only advised for experts' use.
git push -f origin master or git push –-force origin master: overwrite a remote repo.
git remote add origin “link to remote repo”: link a local repo to a remote repo, to allow for pull and push request to such repo in the future. This initializes a remote repo on an already created local repo.
I believe you must be overwhelmed by the list of jargon above, but not to worry, we’ll go through a simple scenario, where you will see most of them at work, and hopefully give you a clearer understanding. Again, ensure you have git set up before proceeding.
A SIMPLE SCENARIO
For a simple scenario, simply create a folder, where ever you want on your local machine, create a file called index.html into this folder and add a few texts inside.
Open your terminal and navigate to the location, or command prompt for window users. Now, run
git init
to initialize a new repo. Don't think anything happened? Enable your folder settings to show hidden files, or for linux users simply type
ls -a
to see all files in the folder. You should see a .git folder in your directory.
For step two, type
git status
and you would see index.html in red color, this means that the files are unstaged. To stage this file, type
git add .
to add every file in the unstaged area. Run git status once more, and notice index.html is now in bright green, now its staged and ready to be committed.
To make a commit, simply run
git commit -m “initial commit”
Where “initial commit” is a comment to help you remember when and details of the commit in the future. During a commit, git takes a snapshot of your current code, and saves it, this is how it maintains versions of your code, So basically, every commit is a different version of your code.
To confirm your commit, run
git log
Damn, too many details? Run
git log –-oneline
, to see it in a more concise view. We can’t push yet, to do so, we need to link our local repo to our remote repo, we could decide to clone this repo, and copy our files, but that would be unfair to our already created local repo, so let us just add the repo link. To do this, copy the repo link from github. Now run
git remote add origin “GitHub link eg: https://github.com/you-can-now-use-git/”,
this should set you up, now run git push, but don’t push yet. You can confirm your remote repo link by running
git remote -v
to see the alias. Now we are ready to push.
For a first push, run
git push -u origin master
instead of git push to prevent the very annoying upstream error, subsequently "git push" should work just fine, and enter your username and password if requested. Now checkout your GitHub on your browser, and you’d see your repo online, Wow right? You can easily pull changes to your local repo by simply running
git pull
as well as clone a remote repo to your local machine by running
git clone “link eg: https://github.com/you-can-now-use-git/”
That’s not all for the basic though, now let's see branches and I’ll let you go. For this, create a branch, and call it FeatureOne, to do this run
git branch featureOne
To see all created branches, run
git branch -a
You should see master and branch name listed. To enter our branch run,
git checkout featureOne
in our case, branch name would be FeatureOne. Run "git branch -a" again, and see that the asterisk is now on “FeatureOne”. If it’s not, then ensure you ran "git checkout FeatureOne".
Let’s continue, create a file called FeatureOne.html, and add some text inside. Repeat the add and commit, using "git add .", and "git commit -m “comment”". Your commits have been made. However, not particularly to the master branch, but FeatureOne now. Let’s test this new superpower, run
git checkout master
and notice FeatureOne.html no longer exists in your folder. That's because it wasn't created on the master branch. Cool right? Run
git checkout FeatureOne
and notice it returns.
The idea of branching, allows us to manage a version of our code without messing up our base code, we can now merge the new code when we feel it's ready and functional enough. This is done to avoid breaking our code, especially when we are unsure of the result of our new test feature.
To merge FeatureOne to master, simply run
git merge FeatureOne
and now if you run git checkout master, FeatureOne.html won’t disappear anymore.
This next feature isn't often done, but sometimes we want to delete a branch we no longer expect to ever work on, most probably branches used for test purposes. To do this, run
git branch -d FeatureOne
and the branch should be deleted. Note that using a “-D” would delete even an unmerged branch, so be careful when deleting branches from your project.
Pheew! That was a long one, but I believe we have done justice to some basic codes for GIT. If you have any questions or corrections, am happy to hear.
Happy Coding!