Hello everyone, I’m Dat here. Surely those of you who are doing BA have more or less heard of Git. So what is Git? Do I need to know Git as a BA? Let’s have a look at this article , Get go
Thin talk
You are doing BA, in some companies you have to work with the dev team to understand the project progress. There was a time when you heard a dev say: “The current code is in conflict on the staging branch, you have to wait for another dev to be present to solve it, but if you fix it, you will lose the code”.
If you do not understand the above sentence, you cannot report the project status to your boss. That’s when you need to know some Git basics.
What is Git? Common terms used in Git.
Git is a distributed version control system. Thanks to Git, code management and developer teamwork becomes simpler and more convenient.
Or to put it simply, Git is a place to manage code. Each member of the project can download other people’s code and upload their own code to become a common source code, which is the project source code.
And the good thing is, all source code changes are recorded by Git. Dev edits any file, adds a line of code, deletes a line of code, removes any extra marks, everything is saved.
Without further ado, let’s go over some Git terminology.
1. REPOSITORY
Repository is a repository, storing source code. In which there are two types of repositories:
- Local repository : Is the repository stored at the dev’s computer. Dev can add, edit, delete files to save but can’t use to share with others.
- Server repository : A repository stored at the server of hosting-services using Git (Github, Gitlab,…). Others who have access can download the source code.
2. BRANCH
Branch aka branch, a repository will have one or more branches. A branch can be understood as a feature of the app or a certain task of the dev, so that eventually the lines of code in this branch will be merged into the largest branch of the repository.
For example, in a project we might have:
- Master branch : is the largest branch aka grandpa branch =))) code in this branch is usually the last code of the app. Just changing the code in this branch will affect the current app, so leaders often have to review the code of members carefully before they can merge code into this branch.
- Staging branch : is also a big branch, but the app from this branch is not an official app to deliver to end-users. Apps exported from this fork are often pre-tested by company employees and stakeholders to see if there are any problems or bugs? If ok, then merge this branch code into master branch.
- And smaller branches : Like I said, branch naming can be a feature of the app or a dev task. When I was a dev I used to name branches like this:
"feature/add-post","task/update-api-login"=)))
So a question arises in a repository can have hundreds of branches? Yes, but for better management, developers often delete that branch when uploading code to the target branch. So on the Server repository , there will not be too many old branches without kicking anything anymore.
3. COMMIT
As a BA, I think it should be simple to understand to avoid confusion, is that when the dev wants to upload the code to a certain branch, it must commit. Commit contains some information such as:
- commit creator’s name and email
- message: this forces the devs to describe each time they commit, it is the content that describes what he did before. If you see any dev grandfather that commits “.” or like “#@!#@!2132” then sign his head immediately =)))
- commit id: this is convenient, if any dev loses his code, he can restore it based on the commit id
In addition, you will often hear some common terms like:
Clone : is to download the source code.
Pull code : also downloads the code but only downloads new changes, usually every morning the devs have to pull the code to start the next code. More precisely, when another dev grandfather pushes his code, the other devs have to pull the code to continue. The goal is to avoid the situation that 2 3 coders in the same file that are uploaded at the same time are overlapping code, leading to code conflict, loss of code.
Push code : is to push the code to the common source code
Create a merge request/Pull request : is to send a message to the lead/boss requesting a code review, the purpose is for him to apply the code to the common source.
Merge request : he applies the code to the source
Conflict : That is, the situation of code overlapping, occurs when two or more developers code the same function or file, one man’s code overlaps the other. My experience to avoid this situation is to have to pull the code often, when there is information that someone has pushed the code to the lead/boss to merge, then it must be pulled back.
summary
We’ve just gone over some Git basics. Hope this article will help some of you in your work.