Version Control and Team Coding with Git
Have you ever felt like you and your team can’t work individually and have to group up to do coding together? Have you ever struggle to revert the changes you make to your code because your change just makes the program crash even more? Well, look no further because all your team need is to use Git.
What is Version Control System?
As a team of developers, usually, each person will work on different parts of the project and sometimes the work done by one developer might be incompatible to the work done by the other developers, not only that, it is not rare that you did some mistake and want to change it back to the way it was before. By using Version Control System (VCS), we can easily solve all those problems, VCS tracks the individual changes made by every developer and prevents works to conflict.
What is Git?
Git is a VCS (Version Control System) that is originally developed by Linus Torvalds in 2005 and it is one of the most popular VCS used by software developers to keep track of their source code. What I personally like about git is that with git, because of it’s distributed structure, every developer’s source code is also a repository which stores the history of the changes made before. Other than that, git is absolutely free! so everyone can easily have access to it.
Starting With Git
If you want to use git, the first things you need to learn are the commands! here is a list of the commands that you will often use:
1. git init
This command lets you create a new repository in your local machine.
2. git pull
This command will pull the changes from the remote repository to your local repository.
3. git add
before changes are committed to your local repository, you need to add those changes to the staging area by using git add.
you can also use “git add .” to add all files that have been changed to the staging area.
4. git commit
this command saves the changes in the staging area to your local repository, it is suggested to also include a message for each commit to help everyone understand what changes have been made.
5. git push
This command will push the changes from your local repository to the remote repository. To call this command you need to specify on which branch you want to push your changes to.
6. git clone
You can use this command to create a local copy of an already existing remote repository.
7. git merge
This command lets you combine the work in different branches. If there is a conflict, you have to resolve it first before proceeding with the merge.
8. git stash
If you don’t really want to commit your code but still wanna save it, you can use git stash to save your code in local and then use git pop to load it back again.
9. git remote
You can use this command to connect your local repository with other remote repositories. you need to provide the URL of the remote repository to connect it with your local repository.
10. git checkout
This command lets you switch position between branches.
11. git branch
This command lets you add more branch, delete a branch, and look at what branch you are currently in.
12. git rebase
this command lets you combine commit branches you already done to a new base commit. this is useful to keep a linear project history.
13. git revert
This command lets you undo your commit by inversing the changes made and then making a new commit to overwrite the commit we want to undo. to call this command you need to provide the parent number and the commit id of the target commit.
How Do We Work as A Team Using Git?
Now that we know the commands that are commonly used, next is to learn how to work as a team through git!
Well, first thing to do is to create a new repository and then make a staging branch from the master branch. The master branch will be our official release branch where it will store the ready to deploy program, while the staging branch will be our feature branch where we will store the source code from all the team members.
Each time a person wants to work on a feature, he/she will have to create a branch from the staging branch specifically to work on that feature, this way everyone can work at the same time. If someone finishes their work in their branch, he/she can then merge it to the staging branch, when this happens every other person that works on different feature need to apply this change by pulling from the staging branch. When we found a bug in the staging branch we need to create “coldfix branch” and then work to fix this bug, after it is fixed, we can then merge the coldfix branch with the staging branch.
If the source code in the staging branch is determined to be “ready to deploy”, we can then send it to the master branch to be deployed. In the occasion that we find a bug in the master branch, then we need to create a “hotfix branch” from the master branch specifically to fix the bugs, after it is fixed, we can then merge the hotfix branch into the master branch.
That’s pretty it for the git-flow, this will become a loop until there is no more feature to work on.
My Experience Using Git
I am currently working on a project as a student at the University of Indonesia, up until now, I think the command that I use really often are git init, clone, pull, push, add, and commit. Git init and clone I use at the start of the project to create my local repository, in my case, I use git clone because I am continuing the work of the old dev team. git add, commit, and push are probably going to be the command I use most often because there will be a lot of changes I need to push. At this point in time, I am currently in my first sprint and me and my team already created our own branches for each of our work using the git checkout command. I haven’t really merged anything to the staging branch because I still have something to be done in my branch.
That’s it for my blog, Thanks for reading!
I hope it can be helpful!