Agile with Gitlab
This article was written to help you with basic knowladge of Gitlab and as an individual review assignment of PPL CSUI 2021
In agile methodology, Agile provides the ability to rapidly adapt to the changing requirements and better collaboration between different smaller teams. The need to periodically distribute code changes is a sure thing. On the other side, DevOps promotes a fully automated continuous integration and deployment(CI/CD) pipeline to enable frequent releases. One of the tools to help DevOps with it is Gitlab.
Before we going deep into Gitlab. Let’s understand Continous Integration(CI) and Continous Delivery/Deployment(CD).
Continuous Integration(CI) is an automation process for the development team. Because the app needs to develop in many platforms and tools, the new code changes need to be regularly built, tested and merged into a shared repository. It establishes an automated and consistent way to build, and test applications.
Continuous Delivery/Deployment (CD) takes part after the CI ends. CD makes automation to releases the deliverable application to the production environment. It takes the main part in software deployment.
Gitlab is a collaboration tool to connect you and your team to work efficiently and enjoyable. It helps your team with automating the testing and deployments, gives your team free to focus on developing the application.
let’s dive deeper into Gitlab!
Git Start!
Gitlab has two kinds of repository(place to stored code), local and remote repository. Local repository for codes that you working on your local computer. On the other hand, remote repository stores codes in a server (we don’t know exactly where it’s). The Remote repository is accessible using the internet and you able to freely store or fetch from the server.
First of all, you need to clone your project from the remote repository. Clone means you copy the original repository of your project to your local computer.
from the example of the Gitlab repository above, go to your terminal any type
git clone
Now your project was stored in your local computer, it is called a local repository.
Branches
Branching is a way for developers to create their own repository. In Agile methodology, we work using three kinds of branches; Master, Staging, and Feature branches.
The Master branch is a repository for the final deployment that delivers the final application to the customer. It is a protected branch that only the product owner can make a change on it.
The second branch is Staging. Staging is a repository that developers set up to test the program in an observable environment. It is a repository of merged features that have been implemented by developers to be tested in the environment.
The third branch is the Feature branch. Just like the name, The Feature branch is a repository used by developers to works on implementing a feature. When the developer finishes their job, they push it into this branch and merge it to the Staging branch to be tested.
To create a branch, you can use type these command in terminal
git checkout -b <new_branch> <source_branch>
It will make a new branch that identical to your source_branch or if you want to move from a branch to another branch, you can use
git checkout <branch_name>
Hotfix and Coldfix Branch
Coldfix is a branch whenever you do revert to a condition before a commit is pushed (in scenario roll-back a commit message).
git revert -m <parent_number> <commit_id_merged>
The coldfix branch is a branch that stores a repository before a commit is pushed. You can do merge requests in the coldfix branch when you have finished the change and let your teammates review and approve the merge request.
Hotfix branch is a new branch that creates from the Master Branch if there a bug or error occurs in the Master. Here, you can resolve the error in the hotfix branch and merge it back to the Master branch once it is fixed.
Feature Branch Life Cycle
Now, you had understood about Repository, Clone, and Branch. In the next step, we will talk about how to make a change in our code.
When you have finished your work working on a local repository and going to push it to your remote repository. You need to follow this step
First, you need to add the files that you want to push.
git add <files-to-add>
Then you need to wrap all the changed files into a commit. The commit message is meaningful information about the change that you do in the file.
git commit -m <commit-massage>
After you do a commit, don’t forget to push it to the remote repository. The target_branch is the branch that you working on.
git push origin <target_branch>
Here, you should consider that conflicts can happen. — force is the last option and use it wisely because it enforces to push your local repository to the branch and overwrite it with your local repository. My advice if you got conflicts, try to resolve them with pull
git pull origin
This will try to match the file to the one on the remote. If the problem still occurs, you can do to stash the repository and resolve the conflict in your local next. Try to find a solution on google especially the stack overflows (this is very helpful).
Additional
Git rebase is a feature in Gitlab to modified commit history. It is a way to integrate changes from one branch to another. Its moves all commit history from a branch to the HEAD of another branch.
git checkout <source_branch>
git rebase <target_branch>
Git Stash is a feature to save all progress that had been made since the last commit without making a new commit for the progress. It is useful when you want to work in another branch and you don’t want to remove current work.
git stash
git stash pop
Git Remote is a feature to create a remote repository in Gitlab when you already have a project in your local repository. It will save your project to the remote repository.
git remote add origin <remote_repository_url>
End Words
Thank you for your enthusiasm to learn Gitlab. I hope this article can help you with your project and assignment.
See you next time!