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:

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:

• 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

The following image summarizes the basic git workflow:

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:

 

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:

 

Summary

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?