Get To Know Git

Priya Srinivasan

One of the most commonly used version control systems is Git. One should follow a proper workflow to perform the tasks in a efficient and consistent manner. Git was originally created by Linus Torvalds in 2005. Git has a great support for branching, merging, and rewriting repository history. Git is considered to be a standard for software development.

Summary of the workflow

  1. Create a central repository
  2. Cloning the central repository
  3. Perform changes and commit
  4. Rebase (solving any merge conflicts that arises)
  5. Push the commits
  6. Create a merge/pull request
  7. Review and merge the pull/merge request

Create a Central Repository

The easiest way to set up a remote repository as a central point for collaboration is to use a service like GitLab or GitHub. In our team we use GitLab.com as this service is free to use, well-designed, has all the features we need and allows us to share our code outside our group. Using GitLab and GitHub are pretty straightforward so we won’t describe that here.

We can also easily set up a simple remote server for collaboration without using such a service. Setting up a server via SSH allows you to create a remote repository that is hosted on a server you control.

Here’s how one can do this. We set up a “bare” repository on a remote server: this is a Git workspace where no local commits can be made as it doesn’t have a working tree, i.e. a directory where all the project files reside.

Use the following command to initialize a repository:

ssh user@host git init --bare /path/to/repo.git
  • user indicates SSH username.
  • host indicates the domain or IP address of the server
  • /path/to/repo.git is the location where repository has to be stored.
  • --bare tells Git to create a bare repository.

The Git SCM book describes this in more detail.

Cloning the Central Repository

Every developer has to create their own local copy of the entire repository before starting to work on it. The following command is used to clone the repository:

git clone ssh://user@host/path/to/repo.git

Perform changes and commit

Once the repository is cloned, a developer can make their own changes. The developer also has the option to commit only the files that he wants to commit, with the help of staging, changes that they don’t want to commit can stay under untracked files.

To view the current status of the branch:

git status

To stage a particular file:

git add <file-name>

To commit the changes:

git commit -m "commit-message"

These commands create local commits, lets the developer save their work.

Git Rebase

To understand this better let us look at an example scenario, consider a collaborative environment where multiple developers work to main a project, Suppose there is one developer working on a feature branch in a Git repository, and their colleague has pushed some changes to the main branch that you need to incorporate into the first developer’s work. However, the first developer also has some commits on their feature branch that are not yet on the main branch. Using “git merge” without rebasing can create a merge commit, which can complicate the project history and create conflicts for repository maintainer(s) when merging changes back to the main branch. Rebasing creates a linear project history, which is easier to follow and can help avoid conflicts and other issues.

Before pushing one’s commits to the repository, the developer’s commit history may have diverged from the central repository, hence one should perform git rebasing in order to download the commits done by other team members to the remote repository and merge them into their own local repository. This will be helpful in keeping the commit history linear.

To check out to main and pull changes on it, perform:

git checkout main
git pull

Now checkout to the feature branch and perform rebase. To rebase in interactive mode:

git rebase -i main

In the case of local changes directly conflicting with upstream commits, Git pauses rebase process, and gives a chance to solve any merge conflicts that arises. Once the changes are made, one can add it using git add command and continue rebasing git rebase --continue, once the rebase is successfully done, push the changes using git push --force.

To conclude, rebasing allows for a linear project history, reduces unnecessary merge commits, simplifies code reviews, and can help resolve conflicts. It helps create a cleaner, more organized repository and promotes better collaboration.

Create, Review and Merge the pull request

After pushing the changes to the remote repository, one can create a merge (or pull) request, where changes can be compared against the main branch, be reviewed by others, and eventually merged into the main development stream.