Git Workflow | Git Lifecycle | Gitflow Tutorial

In this tutorial, we will learn about Git workflow in detail. We will cover different levels that make up a Git system. These levels represent the stages that content moves through, as it makes it way from the local development directory to the server-side (remote) repository. One way to think about and understand these levels is to compare them to another well-known model, a dev-test-prod environment.


dev-test-prod levels vs git levels

The following diagram represents dev-test-prod environment. Most organizations follow similar version of this model in their software development and release processes:
Git Workflow | Git Lifecycle | Gitflow Tutorial


To give you a better understanding of this environment, I'll briefly describe the purpose of each of the levels in my reference model.

  • At the bottom, you start with a Dev area (a development workspace) where content is created, edited, deleted, and so on. Some other names that might be used for this level include sandbox, playpen, workspace, and working directory.
  • When the code is deemed adequate, it can be moved to the Test area (the testing level). Not all of the code has to be moved to Test at the same time.
  • Once a set of code has passed the testing phase, it can be promoted to the Prod (or production) area; this is where it is considered ready and officially released.
  • Then we add another level, Public for reference purpose, which represents an area where the production code is put, to be shared with others. An example might be a website where content is deployed so that others can see it and access it.


Now let's compare this lifecycle model with git levels:
Git Workflow | Git Lifecycle | Gitflow Tutorial

  • Starting at the bottom is the working directory where content is created, edited, deleted, and so on. Any new content must exist here before it can be put into (tracked by) Git. This serves the same purpose as the Dev area in the dev-test-prod-public model.
  • Next is the staging area. This serves as a holding area to accumulate and stage changes from the working directory before they are committed into the next level—the local repository. You can think of this process as being similar to how you might move content to the testing stage in your dev-test-prod-public model.
  • After the staging area comes the local repository. This is the actual source repository where content that Git manages is stored. Once content is committed to the local repository, it becomes a version in the repository and can be retrieved later.
  • The combination of the working directory, staging area, and local repository make up your local environment. These are the parts of the Git system that exist on your local machine—actually, within a special subdirectory of the root (top-level) directory of your working directory.
  • The remote repository is a separate Git repository intended to collect and host content pushed to it from one or more local repositories.

We have combined different git workflow areas into Local and Remote Environment in the following diagram:

Git Workflow | Git Lifecycle | Gitflow Tutorial

Git WorkFlow

The following image summarizes the basic git workflow:
Git Workflow | Git Lifecycle | Gitflow Tutorial

Let us explore the different git workflows in this image:


Working Directory to Staging Area

The add command stages content from the working directory to the staging area. Contrary to what the name implies, you always use the git add command to stage anything, even content that is not new and that has been staged before.



Staging Area to Local Repository

The command that is used to promote things from the staging area to the local repository is the git commit command. Think of it as making a commitment to put your changes into the official source management repository. This is most similar to what you might see as check-in in other source management systems, but note that it only takes content from the staging area.


Local Repository to Remote Repository

To synchronize changes from a local repository to the corresponding remote repository, the command is git push. Unlike commits into the local repository, merge conflicts from content pushed by other users can be encountered here. Also, being able to push to a particular remote repository assumes appropriate access and permissions via whatever protocol and permissions checking is being used.


Local Repository to Working Directory

The git checkout command is used to retrieve content (as flat files) from the local repository into the working directory. This is usually done by supplying a branch name and telling Git to get the latest copy of content from that branch. Checkout also tells Git to switch the branch that you are currently working with.

The following table summarizes the different git levels and commands involved in the workflow:

From To git command Notes
Working Directory Staging Area git add Stages local changes
Staging Area Local Repository git commit Commits only content in staging area
Local Repository Remote Repository git push Syncs content at time of push
Local Repository Working Directory git checkout Switches current branch
Remote Repository Local Environment git clone Creates local repository and working directory
Remote Repository Local Repository git fetch Updates references for remote branches
Remote Repository Local Repository and Working Directory git pull Fetches and merges to local branch and working directory


File Status Lifecycle in Git

In a Git repository, files pass through some different states:

  • When you first create a file in the working tree, Git notices it and tells you there's a new untracked file which Git has never seen before.
  • When you add it, it becomes a tracked file.
  • If you commit the file, then it goes in an unmodified state; this means Git knows it, and the current version of the file in the working tree is the same as the one in the HEAD commit.
  • If you make some changes, the file goes to a modified state.
  • Adding a modified file to the staging area makes it a staged file.

Following image summarizes the file status lifecycle in git:

Git Workflow | Git Lifecycle | Gitflow Tutorial



In this tutorial, we learned about the Git workflow model, a way of thinking about the different levels of Git and how content is moved between them. These levels include the remote repository, the local repository, the staging area, and the working directory. The last three levels make up what I refer to as your local environment, where you develop content and do source management locally before making it more widely available by pushing to the remote.

We also learned about the basic file status lifecycle in git. There are the three basic operations of track, stage, and commit. We also explored the Git workflow of initialization, tracking, committing and pushing a repository.


Further Readings

Git Branching - Branching Workflows
What is a Git workflow?

Didn't find what you were looking for? Perform a quick search across GoLinuxCloud

If my articles on GoLinuxCloud has helped you, kindly consider buying me a coffee as a token of appreciation.

Buy GoLinuxCloud a Coffee

For any other feedbacks or questions you can either use the comments section or contact me form.

Thank You for your support!!

3 thoughts on “Git Workflow | Git Lifecycle | Gitflow Tutorial”

  1. This is most clearly written git discussion I have seen. Nice work!

    There is a table reference on but the table is not presented.

    In the “Local Repository to Working Directory” section, the following text appears:

    The following table summarizes the different git levels and commands involved in the workflow:
    [table id=123 responsive="scroll" /]

    There is no table presented.

  2. After leaving this comment, the page has been refreshed and now the table appears. Odd.

    If I open the page in a new browser window, the table again is not presented.

    • Thank You for highlighting this. I have fixed it. Please let me know if you still face issues. I had actually disabled that plugin on this page as I didn’t realised I was actually using it 🙂


Leave a Comment