Git is a version control system that tracks changes in files over time, especially source code. It lets developers save snapshots called commits, compare versions, and return to earlier work when needed. Git matters because modern software is usually built by teams, and teams need a reliable way to coordinate edits without losing work.
A Git history also records why a project changed, not just what changed.
Understanding Version Control with Git
Git stores history as a connected set of commits. Each commit points back to an earlier commit, except the first one. This creates a timeline that can split and later join.
A branch is not a separate copy of every file. It is mainly a movable label pointing to one commit. When new work is committed on that branch, the label moves forward.
This design makes branches cheap to create. Students should think of a branch as a safe line of development, not as a folder on their computer.
The staging area gives a developer control over the next piece of history. A working folder may contain an unfinished experiment, a bug fix, and a formatting change. Only the selected changes need to go into the next commit.
This helps keep commits focused. Focused commits are easier to review, test, undo, or move into another branch.
A useful commit message explains the purpose of the change. "Fix login error message" is clearer than "updates" because a future reader can understand the decision without opening every file.
A merge combines work that began from a shared earlier commit. Git can merge automatically when different people changed different parts of the project. It can even combine nearby changes when they do not overlap.
A conflict occurs when Git cannot safely choose between two edits to the same section. Conflict markers appear in the file and must be replaced with the intended final text. This is not a sign that Git has failed.
It is Git refusing to guess. After resolving a conflict, developers run tests and read the file carefully. A conflict can create code that looks valid but behaves incorrectly.
Git usually works with both a local repository and a remote repository. The local copy allows commits without an internet connection. The remote copy, often hosted on a service such as GitHub or GitLab, is where a team exchanges work.
Before sharing changes, developers should bring in recent team work, inspect what changed, and test their own code. Teams often use pull requests to discuss a branch before it enters the main branch. Code review catches mistakes, but it also spreads knowledge about the project.
Beginners often make trouble by treating Git commands as magic. Read the output after every command. Check the current branch before editing.
Inspect a diff before staging or committing, since a diff shows the exact added and removed lines. Avoid committing passwords, private keys, large generated files, or unrelated edits. A .gitignore file can prevent many unwanted files from being tracked.
The most valuable habit is making small, tested commits. Small steps make it much easier to find when a bug appeared and to recover from a wrong turn.
Key Facts
- A commit is a saved snapshot of a project at a specific time.
- git status shows which files are modified, staged, or untracked.
- git add file.txt moves a file change into the staging area before committing.
- git commit -m 'message' records staged changes in the local repository.
- git branch feature creates a new branch, and git checkout feature or git switch feature moves to it.
- git pull = git fetch + git merge, which downloads remote changes and integrates them into the current branch.
Vocabulary
- Repository
- A repository is a project folder that Git tracks, including its files, history, branches, and configuration.
- Commit
- A commit is a recorded snapshot of staged changes with an identifier, author, timestamp, and message.
- Branch
- A branch is a movable pointer to a line of commits, often used to develop features without changing the main line.
- Merge
- A merge combines changes from one branch into another and may create a new merge commit.
- Remote
- A remote is a shared copy of a repository stored on another computer or service such as GitHub or GitLab.
Common Mistakes to Avoid
- Committing without checking git status is wrong because you may record missing files, unwanted debug code, or unrelated changes.
- Using git add . carelessly is wrong because it can stage temporary files, secrets, or large generated files that should not enter the repository.
- Pulling remote changes without saving local work is risky because uncommitted edits can conflict with incoming changes or make the update harder to understand.
- Resolving a merge conflict by deleting code you do not recognize is wrong because both sides may contain important work that must be compared and integrated carefully.
Practice Questions
- 1 A repository has commits A, B, and C on main. You create a feature branch from B and add commits D and E. How many commits are on the feature branch history, including inherited commits?
- 2 A project has 12 modified files. You run git add on 7 of them, then commit. How many modified files remain unstaged after the commit if no other changes occur?
- 3 A teammate pushes new commits to main while you are working on a feature branch. Explain why pulling or merging main into your branch before opening a pull request can reduce integration problems.