ConfigsApr 13, 2026·3 min read

Git — The Distributed Version Control System

Git is the most widely used version control system in the world. Created by Linus Torvalds for Linux kernel development, it tracks changes in source code with distributed repositories, branching, merging, and a complete history of every file modification.

TL;DR
Git tracks source code changes with distributed repositories, branching, merging, and staging for every developer.
§01

What it is

Git is the most widely used version control system in the world. Created by Linus Torvalds for Linux kernel development, it tracks changes in source code with distributed repositories, branching, merging, and a staging area. Every developer has a complete copy of the repository history, enabling offline work and fast operations.

Git is used by virtually every software development team and is the foundation for platforms like GitHub, GitLab, and Bitbucket.

§02

How it saves time or tokens

Git's branching model lets developers work on features, fixes, and experiments in isolation without affecting the main codebase. Branches are lightweight (just a pointer to a commit), so creating and switching branches is instant. The staging area lets you craft precise commits by selecting exactly which changes to include. Merge and rebase workflows enable teams to collaborate without stepping on each other's work.

§03

How to use

  1. Install and configure Git:
# macOS
brew install git

# Configure identity
git config --global user.name 'Your Name'
git config --global user.email 'you@example.com'
  1. Create a repository and make commits:
mkdir my-project && cd my-project
git init
echo '# My Project' > README.md
git add README.md
git commit -m 'Initial commit'
  1. Branch, develop, and merge:
git checkout -b feature/auth
# ... make changes ...
git add -A && git commit -m 'Add authentication'
git checkout main
git merge feature/auth
§04

Example

A typical Git workflow with remote repository:

# Clone a repository
git clone https://github.com/org/project.git
cd project

# Create a feature branch
git checkout -b feature/search

# Make changes, stage selectively
git add src/search.ts src/search.test.ts
git commit -m 'Add full-text search with pagination'

# Push and create pull request
git push -u origin feature/search
# Open PR on GitHub/GitLab

# After review, merge
git checkout main
git pull
git merge feature/search
git push
§05

Related on TokRepo

§06

Common pitfalls

  • Committing large binary files or sensitive data (API keys, passwords). Use .gitignore to exclude them and git-secrets or pre-commit hooks to prevent accidental commits.
  • Not pulling before pushing, leading to merge conflicts. Run git pull --rebase before pushing to keep a clean history.
  • Using git add . without reviewing changes. This can stage unintended files. Use git add -p for interactive staging or git diff --staged to review before committing.

Frequently Asked Questions

What is the difference between git merge and git rebase?+

Merge creates a merge commit that joins two branches, preserving the full branch history. Rebase replays your branch's commits on top of the target branch, creating a linear history. Merge is safer for shared branches; rebase produces a cleaner history for feature branches.

How do I undo the last commit?+

Use git reset --soft HEAD~1 to undo the commit but keep changes staged. Use git reset --mixed HEAD~1 to undo the commit and unstage changes. Use git revert HEAD to create a new commit that undoes the last commit without rewriting history.

What is the staging area?+

The staging area (or index) is a buffer between your working directory and the repository. You add specific changes to the staging area with git add, then commit them. This lets you craft commits that include only related changes, even if you modified many files.

How do I resolve merge conflicts?+

When Git cannot automatically merge changes, it marks conflicting sections in the file with conflict markers. Open the file, choose which changes to keep, remove the markers, then git add the resolved file and git commit.

Should I use SSH or HTTPS for Git remotes?+

SSH is recommended for regular development because it uses key-based authentication without entering passwords. HTTPS works everywhere and is easier to set up initially. Both are secure. Use SSH for convenience, HTTPS when SSH is blocked by firewalls.

Citations (3)

Discussion

Sign in to join the discussion.
No comments yet. Be the first to share your thoughts.

Related Assets