Git Basics & Workflows
Git can be summed-up into three steps. Once a git repository is initialized, you introduce changes to the files, you add the files and then you commit. What really happens behind the scenes is that, the files are added on to a staging area which is also known as the index, which can later be committed. When you commit, the changes are added to the git repository from the staged area. And then you pull the changes from the origin (the online repo) taking in the changes from the other developers, and you push your changes to the origin.

Every commit that is there live on some branch. A branch can be identified as a lightweight movable pointer to each commit. A commit contains 3 pieces of information:
- How the files changed from previously
- A reference to the commit that was done before it (parent commit)
- A hash code (eg: 2d2ec5069fc6776c80b3ad6b7cbde3cade4e)
Master branch comes as default when a new git repository is created.
You can create a new branch with the command
git checkout -b <branch-name>
When working with a number of branches it becomes necessary to integrate changes from branch to branch. This can be done in two ways:
- Merging
- Rebasing
Merging is a way of putting forked history back together. Different commits from different branches are combined/merged in to a single branch.
Merging are of two types
- Fast-forward merge
- 3 -way merge
When you try to merge one commit with a commit that can be reached by following the first commit’s history, git simplifies things by moving the pointer forward because there is no divergent work to merge together — this is called a “fast-forward merge”.
In a 3-way merge, commits with different histories will be combined and form a new commit called a ‘merge commit’. A merge commit has two different parent commits.

Rebasing is an alternate and a slightly advanced way of integrating changes. The difference is that, it does not overwrite commits. In fact it preserves the original commits. The project’s history would look like it has evolved from a single line.

This is how merging and rebasing look like:

In merging forked history is combined in to a single commit, whereas in rebase the commit history is a single line.
In addition to this, there is another very useful feature in git called stash.
Stash
Suppose you have made changes to a number of files in a git repository locally, and suddenly you realize you’re working in the wrong branch! — What you normally do is, save a backup, checkout to the other branch and manually copy paste the changes. This happens a lot and this process is way too time consuming and cumbersome.
Stashing can make things easier and faster. It saves the uncommitted changes (modified tracked files and staged changes) on to an array, which can later be reapplied.
Give,
git stash
on to your current branch with the unfinished changes.Then checkout to the branch where you want the changes to be applied and do a
git stash pop
All the changes from the first branch to the current branch can be reapplied this way.
Git Workflows
A workflow is simply a way of using git to accomplish work in a consistent and productive manner.
There are many git workflows out there. In this article I will discuss four such approaches.
- All in one branch
- Feature branch
- Git flow
- Git-hub flow
All in one branch workflow — As the name suggests, everything is in a single branch. In most cases this is the master branch. All the developers in the team commit their code into a single centralized branch.

Suppose locally your master branch has commits D, E, F and G. And on the origin master there are these new commits A, B and C from other developers. You code is up-to-date only up to commit E. So this is what will happen after a:
git pull,

After commit G, the new commits A, B and C will be combined with the new merge commit H.
git pull -rebase,

After commit E, the new commits A,B and C will be added, preserving the original commit history. No merge commit will be created here.
Feature Branch Workflow — Here, a new branch is created when developing a new feature or for a bug fix. The changes will be pushed in to this branch and not the master branch. It will be later merged to master. This approach works well with smaller teams.
Git Flow — In this workflow, you basically have to maintain five types of branches:
- Master
- Develop
- Feature
- Release
- Hot-fix

The Master branch is a stable branch which is directly sent to production. The Develop branch is checked out from the master branch. All the feature changes will be pushed to this branch.
A Feature branch is created for each feature change, which is checked out from Develop, and once done,this will be pushed back to the Develop branch. For immediate bug fixes, a Hotfix branch is created, which is checked out from Master and later will be merged to Master and Develop branches. Finally a Release branch is created for every new release, which will be checked out from Develop, which contains all the bug fixes and new features. This is merged to Master and Develop branches.
Git-flow workflow is a famous workflow. A drawback that can be seen here is, the git history looks messy and hard to follow.
Git-Hub Flow — This is also called the forking workflow. This is mainly used in open-source, public projects in GitHub. This is, in-fact the way how developers contribute to open-source projects in GitHub. Contributions can be done by any developer. Once a pull request is made, the changes can be merged with the approval of the project maintainer/ owner.
The fact to be understood about workflows is that, there is no one-size-fits-all workflow out there. It should be adjusted according to our requirements. A successful git workflow has the following features:
- Simple
- Enhances the productivity and effectiveness of the team
- Dependent on our business requirements
- Not a burden
Thanks for reading! Clap if this helped you and let me know what you think. Cheers!
