How We Git Things Done in Crowd+

8 min readMay 25, 2021

What Git Is

Git is an open-source distributed version control system where developers can collaborate by accessing the same code repository, but make personal changes to the code through their own localized repositories. Git is:

a control system where code and other content can be stored and updated,
a version control system where the history of repository content modification can be tracked,
a distributed version control system where the repository is stored in a centralized server and localized on each developers’ computer.

The presence of Git is essential to product development. Because of Git, developers can work in parallel, access the same code at the same time, but modify that code on their own computers. This makes developers able to modify the code without worrying it will conflict with other developers’ progress. Furthermore, the history tracking Git provides helps developers to go back to previous modifications in case of change of requirements, hence making Git a great tool for agile development.

Git flow

In the development process of Crowd+, a data annotation crowdsourcing platform, we implemented a pattern of collaboration when using Git, or Git flow, as follows.

Branches

We utilize Git branches so every developer can work on their own local repository (called branch) and update their modifications to a centralized repository (master branch). In this development process, we divided the repository into several type of branches with each purpose as follows.

Master Branch

The master branch is the main branch that stores code that is ready to deploy into the production environment. Furthermore, the code in this branch is ready to be used by users.

Staging Branch

The staging branch is the main branch in the development process. This branch stores the main source code that is accessed and further modified by each developer in their own branches. After each developer is finished doing their task, each modification will be merged into this branch.

Product Backlog Item (PBI) Branch

This branch is where each developer creates code according to their assigned tasks, based on each product backlog item (PBI) defined during the sprint planning. After a PBI branch is finished, it will be merged into the staging branch.

Hotfix Branch

The hotfix branch is where bugs or errors in the master branch are fixed. After are bugs or errors are fixed, this branch will further be merged into the master branch.

Coldfix Branch

The coldfix branch is designated for rollbacks, in which any unfulfilled requirements in the staging branch are fulfilled in this branch, based on the acceptance criteria of each PBI. After the tasks in this branch are finished, this branch will further be merged into the staging branch.

The Git Flow

1. Master and Staging Branch Initialization

The master and staging branch is first initialized by the Git master. Because the master branch is a protected branch, developers, except the Git master, are not allowed to directly push changes into this branch. After approval from the product owner, the Git master can merge the staging branch into the master branch.

2. PBI Branch Initialization

Each PBI branch is then initialized by developers to implement the correlating PBI.

3. TDD Implementation

During the development process, developers have to implement test-driven development (TDD), which means to develop code in three consecutive steps: RED, in which code tests are created; GREEN, in which the previous tests are implemented; REFACTOR, in which the code performance is further improved. Furthermore, the tag CHORES can be used to implement code that does not correlate directly to the functionality of the product.

4. PBI Branch Merge to Staging Branch

After PBI branches are initialized and developed by each developer, all PBI branches have to be further merged into the staging branch to be further reviewed by the product owner. During the merge process, the responding developer has to propose a merge request that has to be reviewed by two other developers before actually merging it to the staging branch.

5. Staging Branch Merge to Master Branch

After a sprint review where the developed product in the staging branch is presented to the product owner, if the developed code is approved, the staging branch will be merged into the master branch. If there is disapproval, further modification of the code will be done in a coldfix branch that will be merged into the staging branch, prior to the merge of the staging branch into the master branch.

Git Tutorial

1. Create a Git repository

In order to create a local Git repository, Git has to be initialized to start tracking for version control.

git init

2. Clone

To create a local repository based on an existing remote repository, clone the remote repository in the wanted local directory. The clone includes all the project’s files, history, and branches.

# create a working copy of a local repository by running the command
git clone /path/to/repository# when using a remote server, your command will be
git clone username@host:/path/to/repository

3. Pull

In order to obtain the current state of source code in a branch, code in the remote repository has to be pulled. The Remote_URL can be named anything, but usually is named as origin.

git pull [Remote_URL] [Branch_Name]

4. Push

To modify the remote repository based on modifications in the local repository by the developer, the code in the local repository has to be pushed into the remote repository. The push process is done in three steps as follows.

Add modified files that want to be pushed

git add .

Create informative commit message

git commit -m "[Commit_Message]"

Push code

git push [Remote_URL] [Branch_Name]

5. Merge

To update the master branch based on modifications in another branch, merge the other branch into the master branch.

git merge [Branch_Name]

6. Rebase

To update commits in a branch that were done prior to all other commits in other branches, a rebase could be done to do that. This can help other branches to have updated changes before those other branches are merged.

git rebase [Branch_name]

7. Revert

It’s important to understand that git revert undoes a single commit — it does not “revert” back to the previous state of a project by removing all subsequent commits. In Git, this is actually called a reset, not a revert.

Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them. This requires your working tree to be clean (no modifications from the HEAD commit).

Note: git revert is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one). If you want to throw away all uncommitted changes in your working directory, you should see git-reset[1], particularly the --hard option. If you want to extract specific files as they were in another commit, you should see git-restore[1], specifically the --source option. Take care with these alternatives as both will discard uncommitted changes in your working directory.

See “Reset, restore and revert” in git[1] for the differences between the three commands.

8. Stash

Sometimes you might be working on something, and you’ll just want to rebase because there are some new changes someone else pushed that you want. You might also be in the middle of some changes. If you try to change branches, you may get an error due to possible merge conflicts. If this happens follow the commands:

git stash
git checkout <other branch>
git pull
git checkout <your branch>
git rebase <other branch>
… finish rebase …
git stash pop

So git stash will save everything you are currently working on, but haven’t committed yet. This will clean up your working environment so that you can change branches without any worries of conflicts. Then after all your rebasing, you can git stash pop, which takes the most recent thing you stashed and applies it to your current branch. You might have some merge conflicts, but you know how to resolve those already. Make sure that you keep track of what is at the top of your stash and what branch you are on. You won’t want to apply a stash to the wrong branch. git stash list is a good way to see what’s on the stash stack.

I can see that the stash stack has a commit hash and comment, which is the commit on which these changes were made. Also its shows which branch this stash was created from. I can check what branch I’m currently on, and then know that I can safely git stash pop with confidence I get my intended result.

9. Remote

The git remote command lets you create, view, and delete connections to other repositories. Remote connections are more like bookmarks rather than direct links into other repositories. Instead of providing real-time access to another repository, they serve as convenient names that can be used to reference a not-so-convenient URL.

For example, the following diagram shows two remote connections from your repo into the central repo and another developer’s repo. Instead of referencing them by their full URLs, you can pass the origin and john shortcuts to other Git commands.

The git remote command is also a convenience or 'helper' method for modifying a repo's ./.git/config file. The commands presented below let you manage connections with other repositories. The following commands will modify the repo's /.git/config file. The result of the following commands can also be achieved by directly editing the ./.git/config file with a text editor.

git remote add <name> <url>

Create a new connection to a remote repository. After adding a remote, you’ll be able to use as a convenient shortcut for in other Git commands.

git remote rm <name>

Remove the connection to the remote repository called .

git remote rename <old-name> <new-name>

Rename a remote connection from to .

In Git, “origin” is a shorthand name for the remote repository that a project was originally cloned from. More precisely, it is used instead of that original repository’s URL — and thereby makes referencing much easier. Note that origin is by no means a “magical” name, but just a standard convention.

10. Checkout

To switch on our new branch type in the command line:

git checkout new-branchgit checkout -b new-branch

new-branch — is a name of our new branch, -b is a hyphen and small letter b.

11. Branch

Make sure you are on a master branch;
create new branch and name it;
switch on it.

This could be done in two ways:

Method 1. Firstly, create new branch and then manually switch on it

To create new branch type in the command line the following:

git branch new-branch

new-branch is a name of our new branch. :)))