Technical Snapshot
| Parameter | Description |
|---|---|
| Technical Topic | Git distributed version control |
| Primary Language | Shell / Bash |
| Common Protocols | SSH, HTTPS |
| Code Hosting | Remote repositories such as GitHub |
| Article Type | Git quick reference from beginner to advanced |
| Core Dependencies | git, ssh-keygen, credential.helper |
| Star Count | Not provided in the original source |
Git’s core value is traceable management of code evolution
Git is a distributed version control system. Its core capability is not simply to “save files,” but to record the differences and context of every change. Developers can roll back at any time, compare revisions, experiment in branches, and collaborate through remote repositories.
It solves three common problems: how to avoid overwriting each other’s work in team collaboration, how to isolate feature experiments, and how to restore historical versions precisely. Once you understand these problems, Git commands become much easier to reason about.
The working tree, staging area, and repository form Git’s commit pipeline
The working tree is the directory where you edit files directly. The staging area is a candidate snapshot before a commit, used to collect the changes you want to include in the next revision. The repository stores committed history.
At its core, git add moves changes from the working tree into the staging area, while git commit writes the staged content into the repository history. This two-step model gives you precise control over which changes become part of the permanent record.
AI Visual Insight: This diagram shows how changes flow from the working tree to the staging area and then into the repository. It highlights that modifications are first collected into a committable snapshot before entering history, which makes the responsibility boundary between add and commit easy to understand.
git init . # Initialize the repository
git add . # Add current changes to the staging area
git commit -m "Initial commit" # Commit staged content to the repository
git status # Show working tree and staging area statusThese commands complete the minimum Git lifecycle: initialize, stage, commit, and inspect status.
Local operations determine how safely you record ongoing development work
After initializing a repository, the first thing you should do is configure your commit identity. Otherwise, Git cannot create valid commit records. Use git log to review history, and use git stash when you need to interrupt your current work temporarily.
If you are in the middle of a feature and suddenly need to switch to an urgent task, stashing is cleaner than making a temporary commit because it avoids creating meaningless history entries.
git config --global user.name "Your Name" # Configure the commit username
git config --global user.email "[email protected]" # Configure the commit email
git log --oneline --graph --all # View history as a graph
git stash -u # Stash changes, including untracked files
git stash pop # Restore the most recent stashThese commands cover three high-frequency scenarios: identity configuration, history inspection, and temporary interruption recovery.
Clear boundaries between fetch, pull, and push are the key to remote operations
git fetch only downloads updates from the remote repository and does not merge them automatically, which makes it ideal when you want to review changes first. git pull is effectively “fetch and merge,” which is better suited for straightforward synchronization. git push sends your local commits to the remote repository.
Many collaboration issues come not from using the wrong command, but from mixing up fetch and pull, which causes local branches to merge remote changes before anyone has reviewed them.
git remote add origin https://github.com/user/repo.git # Add a remote repository
git fetch # Fetch remote updates only
git pull origin main # Fetch and merge main
git push origin main # Push local main
git clone https://github.com/user/repo.git # Clone a remote repositoryThese commands cover the basic path for connecting to a remote repository, synchronizing, and pushing changes.
Branching allows experimental development and mainline stability to coexist
A branch is essentially a movable reference to a commit. Creating a branch is almost free, so feature development, bug fixes, and release preparation should all use branches for isolation.
git switch is generally better for switching branches, while git checkout also handles branches, commits, and tags, which makes it useful for inspecting historical states.
git branch dev # Create the dev branch
git switch dev # Switch to dev
git checkout main # Check out the main branch
git checkout v1.0.0 # Check out a tag
git archive -o project.zip main # Export a code snapshot for a specific versionThese commands demonstrate three Git capabilities: isolated development, historical inspection, and release snapshot export.
The reset command changes the state of commits, the index, and the working tree
--soft rolls back only the commit while keeping the staging area intact. --mixed unstages changes but keeps the code in your working tree. --hard discards working tree changes directly. Understanding these three modes is critical if you want to avoid accidentally deleting code.
AI Visual Insight: This diagram compares the scope of soft, mixed, and hard reset. They affect HEAD, the staging area, and the working tree differently, which helps you quickly choose between “undo the commit but keep the code” and “fully roll back everything.”
git reset --soft HEAD~1 # Undo the commit, keep changes staged
git reset HEAD~1 # Undo the commit, unstage changes, keep the code
git reset --hard HEAD~1 # Fully roll back to the previous commitThese commands summarize the risk gradient of reset: soft is the safest, and hard is the most destructive.
Merge and rebase determine whether project history is more traceable or more linear
merge preserves branch divergence, which makes it suitable for team collaboration and auditing. rebase rewrites the commit base to produce a cleaner, more linear history, but you should not use it casually on branches that have already been shared.
The original content contained a typo in the rebase example. Semantically, it should be git rebase main, which means replaying the current branch’s commits on top of the latest commit in main.
AI Visual Insight: This diagram shows the non-linear commit history produced by merge. You can clearly see when two branches converge, which makes it useful for teams that want to preserve collaboration history.
AI Visual Insight: This diagram shows how rebase moves feature branch commits onto a new base to create a linear history. It is useful when you want a clean commit chain, but it changes the original commit relationships.
git switch main # Switch back to the main branch
git merge dev # Merge dev into main
git switch dev # Switch back to the development branch
git rebase main # Rebase dev onto the latest mainThese commands represent two different strategies: merging while preserving branch structure, and rewriting history into a linear form.
HEAD and conflict resolution complete your understanding of Git internals
You can think of HEAD as a pointer to the current checkout position. It usually points to the latest commit on the current branch, but it can also point temporarily to a historical commit, which creates a detached HEAD state.
A merge conflict occurs when two branches modify nearby parts of the same file. Git will try to merge automatically whenever possible. If it cannot determine the correct result, it marks the conflict and waits for manual resolution.
AI Visual Insight: This diagram shows how references such as HEAD, ORIG_HEAD, and FETCH_HEAD map onto the commit chain. It helps explain why checkout, fetch, and reset operations are fundamentally about moving pointers.
git status # Show files with conflicts
git add conflict.txt # Stage the file again after resolving conflicts manually
git commit -m "Resolve merge conflict" # Complete the conflict resolution commitThis flow shows that a conflict is not a failure. It is an intermediate merge state that requires a developer decision.
Authentication configuration determines whether you can connect to remote platforms reliably
SSH works well for long-term development environments because it avoids repeated credential prompts. HTTPS tokens are easier to configure and are useful for quick access. On GitHub, password-based login has largely been replaced by tokens.
ssh-keygen -t ed25519 -C "[email protected]" # Generate an SSH key pair
ssh-add ~/.ssh/id_ed25519 # Load the private key
git remote set-url origin [email protected]:xxx/xxx.git # Switch the remote URL to SSH
git config --global credential.helper store # Enable HTTPS credential storageThese commands cover the two most common authentication paths: SSH and HTTPS tokens.
FAQ
Why does a file not enter history immediately after I run git add?
Because git add only places changes into the staging area. The changes become a formal commit and enter repository history only after you run git commit.
Which should I prefer: git fetch or git pull?
If you need to inspect remote changes first and avoid automatic merges, prefer git fetch. If you only need to synchronize a simple branch and accept automatic merging, git pull is more efficient.
When should I avoid using git rebase casually?
If the branch has already been pushed and other people are collaborating on it, you should avoid rebasing it casually. Rebase rewrites commit history and can make other contributors’ local history diverge from the remote branch.
AI Readability Summary: This article restructures the original Git notes into a technical document designed for fast developer lookup and AI-friendly citation. It systematically explains the working tree, staging area, repository, local and remote operations, branch management, reset, tags, conflict handling, and authentication methods, while adding visual explanations and a practical FAQ. Keywords: Git, version control, branch merging.