Not So Basic Intro About Git
Git is a very popular version control system (VCS). It is widely used due to their fast, yet lightweight size, while also having many features that we could not find in another version control system. It is so synonymous with software development, that nearly every software developer have used it at least once. In this writing, I will try to introduce you to Git and a brief guide of using git in your project. Grab your seat, get your popcorn ready, and have fun reading this article!
What is version control system?
Taken from git-scm.com, they define version control system as:
Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.
It is created for collaborative programming, giving us the ability to develop our own code and merge it later, with another code from our team. Thus, you can say good bye to copy and paste data manually from external disk!
What is Git?
Git is a version control system that is created by the creator of Linux, Linus Torvald to maintain Linux kernel development with four strict requirements:
1. Use concurrent version system.
2. Distributed workflow support.
3. Insusceptible to corruption, either accidental or malicious.
4. Blazingly fast!
Due to no version control that met his criteria, he decided to make it himself, and thus, Git was born. Git treats changes differently than other VCS. Instead of storing it as a list of file-based changes, Git store it as a series of snapshots. With this, git reconsider almost every changes, due to the nature of detail of a snapshots compared to list, and also making it a lot easier and cheaper to create a branch (You can just create a pointer to those snapshots).
Creating a git repository
Before you use git at all, you must initiate a local git repository first. To create a git repository, you can just enter git init command in your command. It will create a .git folder which will keep track off all changes that you made in that folder. It is a hidden folder, so you may want to turn on your hidden files settings (In windows) to see it.
git initAfter that, you need to connect your local git repository to a common repository (internal or code hosting service server) which can be accessed by all members of your team. How do we instruct git to add a new repository? Git provides git remote command that will add a remote repository and named it for an easier access. An example of git remote can be seen below.
Take a note that origin is just a name that mostly used in git. You can change it to whatever you want.
Another alternative of creating a git repository, is by cloning an existing remote repository. Git command git clone <url> will automatically initiate a git repository, add remote repository that is specified in the <url> to our git repository, and pull its data to your local repository. Much easier, right?
Making changes to your data
I have done changes to my local repository already, how do I send it into my remote repository? There are several steps that we must take to do that.
The first one is git add. Just like what the command intuitively tell us, it will add all changes to a file in git directory that usually referenced as staging area. After that, we store snapshot of our changes to our local git repository with git commit -m <message> command. Our message for this commit will be added by -m option. After that, we can store our changes to remote repository by calling git push <remote_name> <branch> command. Remote name is the name that we gave to the stored remote repository in our git repository, while branch is a named pointer that refer to a commit (Details will be explained in branching part).
git add .
git commit -m <message>
git push <remote> <branch>Adding message in our commit is the most important part of collaborative programming. By adding clear, concise message to our commit, our team can understand what we do in this commit without the need of examining all of the code one by one.
What if you accidentally pushed a false commit? Here comes git revert to the rescue. Git revert, accompanied with your commit hash as argument, will create an inverses of the change that is specified.
git revert <commit_hash_code>Version Control and Branching
Branching is the “killer feature” that git has to offer. It is so tempting for developer because of its lightweight cost. Unlike other vcs that copy entire directory to a new source folder, git utilizes a pointer to refer to a certain commit. We named those pointer with a name, such as master, and called it as a branch. The usage of this pointer, along with snapshot that store all information of version control for that commit, create a fast, lightweight branch without the need of copying entire directory to a new folder. Branch allow us to develop our code separately without affecting each other and merge it whenever we want.
To create and navigate to a new branch, we use this following command
git checkout -b <branch_name>“-b” options in the first command, means that we instructed git to create a new branch with branch_name as its name. If we want to navigate to already created branch, just remove “-b” options from the command.
Another options to create a branch in git is by git branch command. git branch allow us to create, delete, and list all of branches in our git repository.
git branch //list all command
git branch [new_branch] //create new branch
git branch -d [branch_name] //delete branchWell what is the different between them then? git checkoutfocus on switching branch, while git branch is a command for CRD(create-update-deletion) of branch in git. It just that git checkout -b, just like git clone, is a merge of git branch and git checkout command (Create and navigate). Thus, git checkout -b is preferred (Lesser command is what we want, isn’t it?).
Getting changes from remote repo
Before you start making changes in your local repository, you need to pull from a branch in remote repository first. To do that, we can use git pull command.
git pull <remote_repo> <branch_name>Why do we need to even bother doing that first? Well, all of this is to prevent our worst nightmare (which is seriously a pain).
What if you already making changes in your file? That’s where stash step in and save you from this tricky situation. You can do this in your git repository:
git stash .
git stash apply //apply your current working stategit stash command will record current working state and going back into clean working directory. Meanwhile, apply argument will instruct git to try restore the last working state that is stored, and try to merge it into your current working state. And… voila! No more merge conflict nightmare (Well it still can happen, but at least you can minimize it).
Branching
After we have finished syncing our branch, its time to merge our branch with other branch. Depending on the situations you are in, there are two available options:
- Merging
git merge <source_branch> <target_branch>command lets us take independent branches of development and combine them into a single branch. It preserves all history of commit in source branch and give vital information from which branch it is being merged (Useful to detect error and debugging it). - Rebasing
git rebase <source_branch> <target_branch>command combine two branch (its source and target branch), by replaying all commits in each other branch (Source will replay target branch commit, vice versa). This will create a history that looks like we are working in 1 branch. This will also remove merge commit that considered “noisy” for some developers.
An illustration for these two concept can be seen below:
Which one you should be using? Although it depends on your requirements, in a collaborative environment, I would suggest you to use merge instead of rebase. This is due to merge create a merge commit and preserve all commit history in source branch, which can be an indicator who is the one responsible for certain features. It also made error debugging much easier (You can just check which merge commit causes an error and fixed it in the feature branch).
Gitflow
Gitflow is a branching model for git, that was made to structure our branch as clean as possible with certain standard structure. Gitflow is very popular in collaborative and development programming because of its scalability. In short there are at least 4 kind of branches that we need to make in our git branch structure:
- Master: this is a place where our production code lies on
- Develop: Also known as staging, this is a branch that used for deployment testing and source of all code from developers. All feature branches are generated from this branch.
- Hotfixes: A branch from master that is used to solve bug or error that occured in master branch.
- Feature Branch: A branch from develop that is used to develop spesific feature and tested, before being merge into develop branch.
- Coldfixes: A branch that is used to rollback all of your changes.
A sample of this implementation can be seen in my Software Development (PPL) group project:
Hotfixes and coldfixes were not being implemented for now, because no feature were in need of repair nor bug detected in our master branch (Our master branch is still empty ahaha). We named our feature as PBI, along with its code number and its description. It allow us to easily determine which branch we will be working for, and creating a branch that is focused on 1 task only.
At last we have arrived at the end of this article. There are much more to be learned from git and its functionality, but I guess this is sufficient enough for basic git usage. Now there is no need to worry in collaborating your code and you can code with your friends at peace, knowing that you can control its version if one of them messed up. You can read more from the git documentation and from the article that I reference below. Have fun coding with your peers!
