Skip to content

Git - Life Cycle

Understanding the Git life cycle involves knowing the different states your files can be in and how you move them between these states. This chapter outlines the general workflow. We’ll cover the specific Git commands for each operation in detail in later chapters.

The typical Git workflow involves these key areas and transitions:

  1. Working Directory: This is your local filesystem where your project files reside. Files here can be:
  2. Untracked: New files that Git doesn’t know about yet.
  3. Tracked: Files Git knows about. Tracked files can be:
  4. Unmodified: No changes since the last commit.
  5. Modified: Changed since the last commit, but not yet staged.
  6. Staging Area (Index): This is an intermediate area where you prepare snapshots of your changes before committing them. When you git add a modified or new file, Git stages its current content.
  7. Local Repository (.git directory): This is where Git stores the project’s history, including all committed snapshots (commits). When you git commit, Git takes the staged changes and saves them as a new commit in your local repository.
  8. Remote Repository: A version of your project hosted on a server (e.g., GitHub, GitLab, or a private server). You interact with it using commands like git clone, git fetch, git pull, and git push.

A general workflow cycle for a developer is as follows:

  • You clone a remote Git repository to create a local working copy, or initialize a new Git repository locally (git init).
  • You modify files in your working directory (add new files, edit existing ones, delete files).
  • You selectively stage the changes you want to include in the next commit using git add. This moves changes from the working directory to the staging area.
  • You review the staged changes (git status, git diff --staged) to ensure they are correct.
  • You commit the staged changes to your local repository using git commit. This creates a permanent snapshot of your project at that point.
  • Periodically, you fetch changes from the remote repository (git fetch) to see what others have done, and then merge (git merge) or rebase (git rebase) those changes into your local work. Alternatively, git pull combines fetching and merging/rebasing.
  • You push your committed changes to the remote repository (git push) to share them with others.
  • If you make a mistake, Git provides tools to correct commits (e.g., git commit --amend, git reset, git revert).

This cycle of modifying, staging, committing, and synchronizing with a remote repository forms the core of daily Git usage.