Git: The Savior of Developers
Git does save us all developers when doing team coding. Let’s say that you have a team and are working on a project. Of course, there will be different codes between you and your team. Now, that will confuse you all on how to merge and maintain those different codes. That’s when git will come to the rescue!
How do we do the right Team Coding?
Many of you must wonder how to do the right team coding. But before that, I will give you the definition of team coding first. Team coding is a project management technique for planning assignment distribution in software development, which includes the task of a team to work collaboratively by assigning tasks per team member. So for me, one of the best ways to implement the right team coding is to use a version control system. According to Hacker Noon, the #1 Version Control System is Git.
Git? Version Control System? What is this?
Git is a version control system. Meanwhile, version control is a system that keeps or tracks files over a period of time, so that they can be used or reached the specific version later in time.
As illustrated above in the picture, that is what git looks like. So we have a certain version of a set of files that we can look back to. Git makes things easy when we make a fault and then we want to go back to a certain version of files. Aha! Now you know a brief understanding of what is Git and version control.
Now moving on to the detail of version control. There are 3 types of version control systems:
- Local Version Control System
Local Version Control System keeps multiple versions of files in your computer (locally). For example, if you are working on a programming project and you clone the folder so that you can keep your previous works that means you are using the Local Version Control System method. If you are still confused, you can look at the illustration above for a more visual example. But the drawback of using this type is you got a mumble jumble of copied folders or files on your computer. - Centralized Version Control System
Centralized Version Control System keeps multiple versions of files in a centralized server. But the drawback of using this type is once the server is down, you cannot access your files. - Distributed Version Control System
Distributed Version Control System solves the drawbacks from Local Version Control System and Centralized Version Control System, by combining both of them. It combines both of the previous version control systems by having a centralized server but can also be accessed by us locally too by cloning to our local computer. So if the server is down, we can still use the version control system locally. One example of the distributed version control system is Git.
The main purpose of Git
Git helps us in team coding by maintaining tons of versions of files in a distributed way. Therefore, we can see and maintain the codes of our team easily.
Wow, that explains it all! Now you know what is Git and how it is correlated with the version control system.
Git Manual 101
Now let’s move to the next topic, which is how to use Git using Gitlab/Github.
1. Git Repository Initialization
Before everything, let’s have a 101 on git repository for a sec. In Git, a repository is a folder that contains files that will be included inside the version control system. Eureka! Now you know what is a Git repository. Now, we can initialize a Git repository by using this code below:
git init
2. Adding git remote to your Gitlab/Github
After you initialize a git repository on your local computer, now we have to add a remote to your Gitlab/Github repository for having your repository connected online. You can add a git remote by using the code below:
git remote add <remote_name> <url>example:
git remote add origin https://gitlab.com/gafiirfandi/testrepo.git
3. Adding and Committing Files
The above picture is an illustration of the flow for adding and committing in Git. So, you can add files to move your chosen files to a staging area. In the staging area, you can still undo your added files (which we will cover later). After you add the chosen files, you can commit your files to move the added files to your local repository. How do we do it? you can add and commit your files to make a version for your current files by using this command below:
#adding filesgit add <file> #adding 1 file
git add <file1> <file2> #adding multiple files
git add . #adding all files#committing filesgit commit -m <commit_message>
4. Pushing your committed files to Gitlab/Github
Before you push your committed files, let’s learn about branch first.
A Git branch is essentially an independent line of development. You can take advantage of branching when working on new features or bug fixes because it isolates your work from that of other team members.
Now, you can push (send) your committed files to a remote repository (Gitlab/Github) by using this code below:
git push <remote_name> <branch> #the default branch is masterNice! Now you have done the basic flow of using git to have a local and server repository of your files.
Other features when using Git
1. Branch
Now that you know what is a branch in git from the previous explanation, we can achieve making a branch by using this code below:
git branch <branch_name> #making a new branchNow many of you must wonder how can we switch branch to our new branch. In the next feature, we will explore how to do it.
2. Checkout and Stash
This feature is used to move to another branch in your git repository. We can achieve such by using this code below:
git checkout <branch_name>We can also make a new branch and move to the new branch immediately by doing this:
git checkout -b <branch_name>Now in git, if you are working on one branch and you want to move your work to another branch and commit on the other branch, you can’t just do git checkout to another branch and commit it there. The solution is you have to use the git stash feature.
The git stash command takes your uncommitted changes (both staged and unstaged), saves them away for later use.
https://www.atlassian.com/git/tutorials/saving-changes/git-stash
Aha! Now you have an overview of what is git checkout, we can implement it by using the code below:
git stash #to save current working stategit stash remove #to delete current working state
3. Pull
There is push, so what is pull now? Git pull is a git method that allows you to pull (get) the latest version of files in the remote repository (Gitlab/Github). We usually do this as the first step to merge our committed files to the files in the remote repository. Wait! what do you mean by “merge”? Merge is combining our locally committed files with the remote files so that we can avoid such conflicts. Now, we can do the git pull by using this code below:
git pull <remote_name> <branch_name>4. Merge and Status
If you are still confused about what is merge, we will discuss more about merge in Git in this section. Say that you have 2 branches in your local repository, and you want to merge the 2nd branch into the 1st branch. Now, we can use the git merge method to achieve such by using this code below:
Let's say that you have the "master" and "my_feature" branches, and you want to merge the "my_feature" branch into the "master" branch. You have to be on the "master” branch, you can check which branch you are on by using git status:
git statusAfter you are sure that you are in the “master ”branch, you can do the following code to merge from the “my_feature” branch to the “master” branch
git merge my_feature5. Clone: quick remote+pull method
As an alternative to remote, we can quickly add a remote and pull from the remote repository by using the git clone feature. So basically, the git clone does the git remote and git pull feature at once. Usually, we do the git clone if we don’t have the local repository. We can achieve this by executing the following code:
git clone <remote_url>6. Rebase
Rebasing is the process of moving or combining a sequence of commits to a new base commit.
So for example, if you are working on your feature branch and the master branch has progressed as well, and you want to get the latest updates in the master to your branch while keeping your branch history clean. You can achieve this by using git rebase. Here’s how you can implement git rebase:
git rebase <base>7. Revert
Git revert is helpful when we make a mistake by committing something we should have not. So we can go back to a certain point of commit using git revert by using the code below:
git revert <commit_name>Git merge vs git rebase
Git rebase and merge both integrate changes from one branch into another. Where they differ is how it’s done. Git rebase moves a feature branch into a master. Git merge adds a new commit, preserving the history.
There are different benefits of using git merge and rebase, so you can choose the most suitable for you. Here are the benefits from git merge and git rebase:
Git rebase
- Streamlines a potentially complex history.
- Avoids merge commit “noise” in busy repos with busy branches.
- Cleans intermediate commits by making them a single commit, which can be helpful for DevOps teams.
Git Merge
- Simple and familiar.
- Preserves complete history and chronological order.
- Maintains the context of the branch.
Git flow in my PPL project
In my PPL project, there is a convention for the git flow that the lecturers made. Here are the rules and ways for the git flow:
- Branches
- Master: the master branch stores the source code that is ready for production.
- Staging: the staging branch stores the source code of the combined work of each developer
- PBI[1..N]: the PBI branch stores the implementation of a Product Backlog Item
- Hotfix: the hotfix branch is a branch to fix bugs that occurred in the master branch
- Coldfix: the coldfix branch is a branch to roll back all changes
of all product backlog item branches. - Commits
- [RED] <test_message> : commit for making test before implementing the test (TDD).
- [GREEN] <implement_message>: commit for implementing test
- [REFACTOR] <refactor_message>: commit for refactoring code.
- [CHORES] <chores_message>: commit for adding assets (non-code files)
Conclusion
So to conclude this article above, git is really a savior for developers when doing team coding. Git has a lot of features that will help developers to work remotely at this time of the year, and following a git flow is very important to be clear to your teammates. That’s all from me, hope this article can help you!
Source:
https://i.redd.it/05b6u19pseoz.png
https://www.perforce.com/blog/vcs/git-rebase-vs-merge-which-better
