Git Commands that are Useful in Collaborative Development

6 min readMar 21, 2021

Apart from being a version control system, the tools provided by Git can also help developers to collaborate. Some git commands are useful for developers when building projects together. Before continuing the discussion, I recommend you to be familiar with basic git commands such as git add, git commit, and git push.

Branching: Keep your code independent

Usually, a project consists of several features. When we are assigned to work on a feature, we want to do it independently so it doesn’t affect the work of others (before merging). With branches, we can prevent the right code from getting mixed up with the code we just built.

Create a branch and switch to it

$ git checkout -b [branch-name]

Push your code to a branch

$ git push [remote-name] [branch-name]

Note: remote is a variable that stores the repository address. You add this variable when you run the command git remote add [remote-name] [url-repository]

Switch branch

$ git checkout [branch-name]

View a list of existing branches

$ git branch

Delete branch

$ git branch -d [branch-name]

Change branch name

# move to the branch you want to rename
$ git checkout [old-branch-name]# rename branch name
$ git branch -m [new-name]# remove old branch from remote
$ git push [remote]: [old-name] [new- name]# reset the upstream branch name for the new branch
$ git push origin -u [new-name]

See the difference with the other branch

# see the difference with the other branch
$ git diff [source-branch] [target_branch]# see the differences of files with the other branch
$ git diff [branch-1]: [file-name] [branch-2]: [file-name]

Integrating changes: Merge vs Rebase

After the features have been built independently on each branch, we want to combine these features into one unified application. There are two ways to integrate code in these branches, either with git merge or git rebase.

# using git merge
$ git checkout feature
$ git merge master# using git rebase
$ git checkout feature
$ git rebase master

What is the difference?

The difference lies in how to integrate these differences. Git rebase moves our branch to the target branch (eg staging) or in other words rewrite history so that it helps keep the history clean, whereas git merge adds new commits and keeps the commit history.

Which is better to use for collaborative development?

Using git rebase can have an impact on other people on that branch (eg staging), so I recommend using git merge in collaborative development. Apart from that, git rebase also “removes” the history so it’s not good if other members want to see the commit history.

Pull: Getting the latest updates

When a project is done collaboratively, we want to get the latest updates from the main branch so we can continue the development. This can be done with the git pull [remote] [branch-name] command. However, it may cause conflicts due to the differences with our locales.

Here are some steps to handle it

# store the code locally
$ git stash# pull from the desired branch (Note: this command can overwrite local changes)
$ git pull [remote] [branch-name]# re-apply the changes to local (which we previously saved when entering the git stash command
$ git stash apply

Note: the git stash and git stash apply commands can also be used when you want to switch branches but some changes haven’t been committed

Revert: Cancel the code that has been merged

It is possible that we accidentally merged with the main branch while merging with the main branch requires approval from several parties. For example, in my Software Engineering Project course, it is not recommended to merge our branch to the staging branch without other member’s approval. If we accidentally did so, we have to undo the merge. Here are the steps to undo the merge

# move to the main branch
$ git checkout [main-branch-name]# get the id of the last merge commit (Note: commit id is the first 7 alphanumeric on the first line of the command's output)
$ git log --oneline# revert merge using the commit id we have obtained in the previous step
$ git revert -m 1 [merge-commit-id]# push changes to the remote repo
$ git push [remote] [main-branch]

Amend: Changing the commit message

When building a project collaboratively, the commit message is one of the important things so that other people involved in the project know a brief description of the commit. In projects that implement TDD, usually, the commit message contains the TDD tag phase such as “[RED]” when doing a commit for a test and “[GREEN]” when doing a commit for code implementation. People who are new to the implementation of TDD tend to forget to include those tags while committing.

Here are some steps to change the commit message

# change commit message
$ git commit --amend -m "New commit message."# force push
$ git push --force branch-name

Implementation: Using Git in My Project

In my Software Engineering Project course, my team and I create branches in both our backend and frontend repositories. These branches help us to build features independently without fear of affecting the right code (the right code is in the staging branch)

I am responsible for the signup feature on the backend. Therefore, I will create a branch for the signup feature and immediately switch to that branch with the git checkout command

Create a branch and switch to that branch

Then, I started creating a test for the signup feature. After finishing the test, I’ll push my code to the signup branch like in the TDD cycle.

Ooops, I forget to add the [RED] tag as a sign that the code I just added is a testing phase. I’ll change the commit message using git amend.

The commit message has now changed.

The commit message in GitLab has changed

After creating the test, I will implement the code. Then I push the implementation code to the signup branch with the [GREEN] tag.

Since I have finished implementing the signup feature, I will merge the signup and staging branches. Previously, I will first check the difference between them with the git diff command.

The differences between signup and staging branch

Apparently, the only difference lies in the code I implement in my branch. It means that I don’t have to pull from the staging branch. Now I’m going to merge signup and staging branches with the git merge command

Ooops, there are conflicts between my branch and staging. I will resolve the conflicts and push them.

Push the changes after resolving the conflicts

Finally, I’ve finished implementing the signup feature and integrated it into the staging branch. The staging branch is a branch where all features are integrated into one unified application.

I hope this article will help you in developing a project collaboratively.

Happy coding! :)