If you are not yet familiar with Git, or haven’t adopted Git as your version control tool, now is a great opportunity to get to know this popular tool. I won’t go into the origins and history of Git here, but I recommend checking them out. This article will not cover the basic operations of Git (there are many excellent tutorials online), but rather share some thoughts on using Git and practical experiences in project management.

Git Basics Review

When you first start using Git, you might think it’s very simple. You just need to understand three core concepts:

  • Workspace
  • Index/Staging Area
  • Repository

The following diagram clearly shows the operational relationship between different areas:

flowchart LR Remote[(Remote)] Repository[(Repository)] Index[(Index)] Workspace[/"Workspace"/] Remote -- fetch/clone --> Repository Repository -- checkout --> Workspace Workspace -- add --> Index Index -- commit --> Repository Repository -- push --> Remote Remote -- pull --> Workspace
  • git add: Submit changes from the workspace to the staging area.
  • git commit: Submit changes from the staging area to the local repository.
  • git push: Synchronize changes from the local repository to the remote repository.

Note that the local repository is the real version library; all operations before push are local.

HEAD (Pointer to the Current Working Branch)

HEAD is a special pointer that always points to the latest commit of the branch you are currently working on. It can be understood as “your current location”.

  • Specific Functions:
    • Identifies the tip (latest state) of the current working branch.
    • When you execute git commit, a new commit is created, and HEAD automatically points to this new commit.
    • You can use git checkout to switch the branch HEAD points to (e.g., git checkout dev will make HEAD point to the latest commit of the dev branch).
    • Special case: HEAD can also point directly to a specific commit (called “detached HEAD” state), at which point you are not working on any branch.

index (Staging Area)

The index, also known as the “staging area” or “cache”, is a temporary area between the workspace (working directory) and the repository.

  • Specific Functions:
    • Used to temporarily store modifications you are preparing to submit (content added via the git add command).
    • When you execute git commit, Git only submits the content in the index to the repository, not all modifications in the workspace directly.
    • It can be understood as a “preview area before submission”, allowing you to precisely control which modifications should be included in the next commit.
  • Related Operations:
    • git add <file>: Add modifications from the workspace to the index.
    • git status: View the difference between the workspace and the index (which files are modified but not staged, which are staged to be committed).
    • git reset HEAD <file>: Undo modifications to the specified file in the index (put them back to the workspace).

Branch Management

Git’s branching is one of its powerful features. A branch can be seen as an independent line of development; changes on a branch do not affect other branches. Common commands:

git branch      # View and manage branches
git checkout    # Switch branches
git merge       # Merge branches
git rebase      # Rebase

Branching Strategy

How to use branches depends on the team’s development process. Common patterns include:

  1. Single Branch Mode Small projects or personal projects can use just one branch, but this is rarely used in actual work.
  2. Feature Branch Mode Each feature is developed on an independent branch and merged into the main branch upon completion. Suitable for small to medium teams, simple and easy to use.
  3. Branch per Environment Branches are named according to the deployment environment, such as dev, staging, prod. Suitable for multi-environment deployment, but less commonly used in practice.
  4. Branch per Developer Each person has a branch to develop their own features independently, then merge into the main branch. Common in teams.
  5. Git Flow A standardized process. Although it looks complex, the actual operational experience is good. It is worth learning to master, especially for large teams or complex projects.

Commit Standards

The importance of commit messages goes without saying:

  • Clear Change Log: Easy to read and trace history.
  • Generate Changelog or Daily Reports: Good commits can automatically generate development documentation.

Commit Suggestions

  1. Reasonable Task Splitting A single commit should not be too large or too small. Each commit should represent the completion of a small task or a logically independent change.
  2. Distinguish Types Different types of changes, such as format adjustments and code logic modifications, should be submitted separately.
  3. Clearly State Purpose The commit message should describe “why it changed”, not just “what changed”.

Merge vs Rebase

Regarding code synchronization, a common question is the difference between merge and rebase:

  • Rebase: Used to synchronize changes from upstream (remote or main branch) to the current branch, keeping the history linear.
  • Merge: Used to merge changes from a downstream branch into an upstream branch, retaining the complete branch history.

Principle:

Sync upstream code → Use rebase Merge downstream code → Use merge

Summary

Git commands themselves are simple, but when combined with team development, project management, CI/CD, etc., there is a lot to consider. In practice, not only do you need to master branching strategies and commit standards, but you also need to understand how to integrate with GitHub/GitLab, code reviews, and Jenkins deployment. These are key to improving development efficiency.