Git

So, what is GIT exactly?

GIT is an Open Source Distributed Version Control System. Quite a mouthful huh? What it essentially does it enables developers to add code in parallels, and GIT helps in maintaining history of what changes have happened. GIT has a remote repository which is stored in a server. As GIT is distributed, the code in the remote repository is also present in all developers’ computers in the form of a local repository.

Why do we need GIT?

One, to ease the development of collaborative projects. Nowadays, projects usually have multiple developers working at the same time. GIT is needed to ensure there are no code conflicts between developers.

Several projects that run in parallel also sometimes use the same codebase. In such a case, the concept of branching in GIT is important.

Which GIT features have our team used?

Pull

git pull / git pull [alias] [branch]

Fetches and merge any commits from the tracking/remote branch. During development, our team constantly does this before pushing to the remote repository to ensure possible conflicts are resolved.

example in my end

git pull origin staging

In this case origin is our local pc and staging is the source pull

Add

git add [file]

Add a file as it looks now to your next commit (stage). After we make changes to the files, we always add them in order to stage them for commit. Usually we do it one by one, but when we only make small changes and can be compiled into one commit, we add it all at once by using git add .

git add .
git add base.html

In this case we use . to add all of change in one commit, or we can use specific file like base.html

Commit

git commit -m “[descriptive message]”

Commit your staged content as a new commit snapshot. Of course, we always do commits before we push the work we’ve done. Our commit message follows the standard of the course guideline.

git commit -m "[GREEN] Adding base.html"

the guideline is to add indicator red/green/ or refactor and comment what you do in this commit

Push

git push / git push [alias] [branch]

Transmit local branch commits to the remote repository branch. Pushing something to the remote repository is something we do all the time, as this is one of the most essential features of GIT.

git push origin staging

One of that we use a lot is staging, we can directly push to staging

Clone

git clone [url]

Retrieve an entire repository from a hosted location via URL. When we first initiated the project, each one of us cloned the remote repository to our local machine. Sometimes we also clone again when we need a clean slate or when unexplainable errors happen. One of the example that we use is

git clone https://gitlab.cs.ui.ac.id/ppl-fasilkom-ui/2021/CC/raising-star.git

Merge

git merge [branch]

Merge the specified branch’s history into the current one. We usually do this right before our sprint review, where we merge all our branches into staging to be deployed as a working product. One of the example that we use is

git merge staging

We merge staging into the current one

Rebase

git rebase [branch]

Apply any commits of current branch ahead of specified one. Git rebase integrates upstream changes into your local repository. Pulling in upstream changes with Git merge results in a superfluous merge commit every time you want to see how the project has progressed. On the other hand, rebasing is like saying, “I want to base my changes on what everybody has already done.”

Revert

git revert

Used to record some new commits to reverse the effect of some earlier commits (often only a faulty one). We have used it a couple of times when an unexpected error happens and triggers a pipeline failure. One of the example that we use is

git revert bf4d837b13185e6c56b2458fc9a507e0d827d11c

bf4d837b13185e6c56b2458fc9a507e0d827d11c stand from commit that we want to revert

Stash

git stash

Save modified and staged changes. Stash is used in the event where we’re in the middle of doing something in one branch, but suddenly need to make a critical change in another branch. The progress in the former branch is stashed, switch to the latter branch and do the necessary changes, then go back to the former branch and unstash the progress using git stash apply.

Remote

git remote

Manage the set of repositories (“remotes”) whose branches are currently tracked. As the name describes, all repositories that we track are added and managed using git remote. At the moment, we have our PPL-B5 repository with origin as its alias.

Checkout

git checkout [branch]

Switch to another branch and check it out into your working directory. As our team works on numerous branches, this command is used quite a number of times to switch between branches. The creation of a new branch also uses this command, where we add -b before the branch name, hence making the command git checkout -b [branch]. One of the example that we use is

git checkout -b PBI-8 (NEW PBI)

In this case we create new branch name PBI-8 and change branch to it

Branch

git branch

git branch is used to list your branches. a * will appear next to the currently active branch. As the description suggests, we use git branch to check the list of branches on each of our local machine, and sometimes to get the name of the branch we want to checkout to. One of the example that we use is

git branch PBI-17

This mean changing branch to PBI-17 in our local machine

What about GIT flow?

Our repository currently uses 5 different kinds of branches, which will be elaborated below.

Master

Branch that will contain the content from staging that is approved. This branch is protected, and the only person that can merge from the staging branch to master is the scrum master.

Staging

Branch that will contain the merged progress of our user story branches. Staging is used to produce a working product that can be demoed to the product owner. They will base their acceptance or rejection of the user story from this branch.

UserStory n

A set of branches that contains all our development work. One user story must have one individual branch dedicated for it. Example:

Coldfix

Branch used to a rollback from staging to erase changes. Usually used in the event where a user story is rejected.

Hotfix

Branch used to fix bugs from the master branch.