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:

 

1. Remote Repository to Local Repository

• Cloning (git clone): This creates a local copy of a remote repository. It initializes a local repository, copies all the files, and sets up remote tracking branches.
• Fetching (git fetch): This updates the local copy of the remote repository without merging any changes into your working directory. It’s useful for getting updates that others have pushed to the remote repository without altering your current working state.

 

2. Local Repository to Remote Repository

Pushing (git push): This command sends your committed changes from the local repository to the remote repository. It updates the remote with your local commits along the branches that you have in common.

 

3. Working Directory to Staging Area

Adding (git add): Moves changes from the working directory to the staging area. This is where you prepare changes before committing them to the local repository. The staging area is a snapshot of what your next commit will look like, allowing you to select and group changes for commit.

 

4. Staging Area to Local Repository

Committing (git commit): Takes whatever is in the staging area and commits it to the local repository. A commit is a snapshot of the project’s history at a certain point in time, which can later be referenced or reverted to.

 

5. Local Repository to Working Directory

• Checkout (git checkout): This is used to switch between branches or restore working directory files to a saved state. For example, git checkout branch_name switches to another branch, and git checkout -- file_name discards changes in the working directory.
• Reset (git reset): Moves the current branch back to a previous state (or commit), optionally updating both the staging area and the working directory to match. This is useful for undoing changes permanently in the local repository.

 

6. Additional Useful Transitions

Merging and Rebasing:

• Merging (git merge): Combines multiple sequences of commits into one unified history. Merging is a common way to integrate branches in Git.
• Rebasing (git rebase): Reapplies changes from one branch to another. It’s useful for maintaining a clean, linear project history by moving the entire branch to the tip of another base.
• Pulling (git pull): A combination of git fetch followed by git merge. This updates your current branch with the latest changes from the remote repository by fetching the data and then merging it into your current branch.

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 run git add on an untracked file, you perform two actions: you start tracking the file, and you immediately stage it for the next commit. This means the file goes from being untracked directly to being both tracked (in a general sense) and staged (specifically for the next commit).
• A tracked file can be in one of three states:
  • Unmodified: The file has not changed since the last commit.
  • Modified: The file has changes that have not yet been staged for a commit.
  • Staged: The file has changes that have been staged, meaning these changes are ready to be committed to the repository.
• 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:

 

Let us consider and example:

1. Editing: You edit a file called example.txt.
2. Staging: You stage example.txt for commit by using git add example.txt.
3. Committing: You commit the change with git commit -m "Update example.txt".
4. Post-Commit State: After the commit, example.txt is in the unmodified state because the version in your working directory now matches the version in the commit you just made.

 

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.

Git Branching - Branching Workflows
What is a Git workflow?