Before getting into this topic it is suggested to be clear in git basics.

Here are my other blogs covering this section

What is Git Workflow?

A Git Workflow is a recommendation for how to use Git to accomplish work in a consistent and productive manner.

When working with a team on a Git managed project, it’s important to make sure the team is all in agreement on how the flow of changes will be applied. To ensure the team is on the same page, an agreed-upon Git workflow should be developed or selected.

How does a project workflow look like in Git?

In this section, a simple understanding of a workflow for a single developer or for a small team is explained. This also gives a general understanding of how large and complex projects work.

Workflow

Two developers working together with a shared repository.

Developer 1
Developer 2

Developer 1

Initially, the Developer 1 clones the repository

$ git clone <repository URL>

Now, some changes are made

$ git commit -m "Initial commit by Developer 1"

After making the changes Developer 1 commits

Developer 2

Developer 2 does the same thing. First clones the repository

$ git clone <repository URL>

Now, some changes are made

$ git commit -m "Initial commit by Developer 2"

After making the changes Developer 2 commits.

Now Developer 2 pushes the work to the server

$ git push origin master

This works just fine.

Shortly after this Developer 1 pushes his work to the same server

$ git push origin master

But this time it fails because of Developer 2’s earlier push.

The solution to this is Developer 1 must fetch Developer 2’s upstream changes and merge them into the local repository before pushing.

As a first step, Developer 1 fetches Developer 2’s work

$ git fetch origin

At this point, Developer 1’s local repository looks something like this

Now Developer 1 can merge Developer 2’s work

$ git merge origin/master

Developer 1’s updated history will now look like this

Now Developer 1 can finally push the new merged work to the server

$ git push origin master

In the end, Developer 1’s commit history will look like this

Meanwhile, Developer 2 has created a new branch called issue and made a couple of commits to that branch.

Developer 2 hasn’t fetched Developer 1’s changes yet, so the commit history looks like this

Developer 2 learns that Developer 1 has pushed some new work to the server. So now Developer 2 needs to fetch all new content from the server.

$ git fetch origin

Now Developer 2’s history looks like this

Developer 2 must know what part of Developer 1’s fetched work has to be merged into the work so that it can be pushed. Developer 2 runs $ git log command to find that out

$ git log --no-merges issue..origin/master

This issue..origin/master syntax is a log filter that asks Git to display only those commits that are on the latter branch (in this case origin/master) that are not on the first branch (in this case issue)

The solution here is Developer 2 merges the work into the master branch, merge Developer 1’s work(origin/master) into Developer 2’s master branch, and then push back to the server.

First, Developer 2 switches back to the master branch to implement this

$ git checkout master

Developer 2 can merge either origin/master or issue first. But the order doesn't matter here, the end result will be the same.

$ git merge issue

All clear. Now Developer 2 completes the local merging process by merging Developer 1’s earlier fetched work that is in the origin/master branch.

$ git merge origin/master

Now Developer 2’s history looks like this

Now finally it can be pushed to the server

$ git push origin master

In the end, Developer 2’s commit history will look like this

The general sequence for this overall process looks something like this.

This article was originally published by Dhayaalan Raju on medium.