Git and Version Control Explained

Everyone who writes for long enough ends up with files named final, final2 and really_final_this_time. Version control replaces that mess with a proper history: every meaningful change recorded, every earlier state recoverable, every collaborator's work merged without losing anyone's contribution. Git is the most widely used version control system, and a working knowledge of it is expected in most technical jobs and many courses. The commands can look cryptic, but the underlying ideas are small. This guide builds the mental model first, then the commands.

Git has many commands and options, and interfaces vary. This guide covers the essential workflow, and you should check the official documentation for details and your operating system.

Why version control matters

• History. You can see what changed, when and why.
• Safety. If a change breaks something, you can go back.
• Experimentation. You can try ideas on a separate line of work without risking the main version.
• Collaboration. Several people can work on the same project and combine their changes.
• Accountability and learning. Commit messages document decisions.
• Professional habit. Employers expect it.

Version control is not only for code. It also suits documents written in plain text, notes and data files that are not too large.

The mental model

Git keeps a database of snapshots of your project. Three areas matter.

1. Working directory: the files you see and edit.
2. Staging area (index): a holding area where you prepare what the next snapshot will include.
3. Repository (history): the permanent record of snapshots, called commits.

The usual cycle: edit files, stage the changes you want to record, commit them with a message. Staging lets you group related changes into a clean commit instead of recording everything at once.

Each commit has a unique identifier, a message, an author, a time and a pointer to its parent commit. The chain of commits forms history.

Setting up

1. Install Git from the official source for your operating system.
2. Tell Git who you are, by setting your name and email in its configuration, so that commits carry your identity. Consider using an email address that does not reveal more than you want, especially for public repositories.
3. Create or clone a repository.

To start tracking a folder:

git init

To copy an existing repository:

git clone <address>

Keep your accounts secure with strong passwords and two-factor authentication.

The essential commands

Check what is happening

git status

Shows which files are modified, staged or untracked. Use it constantly.

git diff

Shows changes you have not staged yet.

Stage and commit

git add filename
git commit -m "Describe what changed and why"

You can stage several files, or parts of files, before committing. Commit small, logical units of work.

View history

git log

Shows commits. Variants display compact or graphical views.

Compare and inspect

git show <commit>
git diff <commit1> <commit2>

Show details of a commit or differences between two.

Write good commit messages

Messages are for your future self and your teammates.

• Start with a short summary in the imperative, such as "Add login validation."
• Keep the summary short (around fifty characters is a common convention).
• Add detail in the body when needed, explaining why.
• Commit one logical change at a time.
• Avoid vague messages such as "fix" or "stuff."
• Don't commit broken code to shared branches.

Clear history makes debugging and collaboration much easier.

Branches

A branch is a movable pointer to a commit, which lets you develop a feature in isolation.

git branch
git switch -c new-feature

The first command lists branches. The second creates and moves to a new branch called new-feature. You then commit as usual. When ready, you merge it into the main line.

git switch main
git merge new-feature

Ideas for using branches:

• Keep the main branch working.
• One branch per feature or fix.
• Name branches clearly.
• Delete merged branches to avoid clutter.
• Pull updates from the main branch into your branch regularly to reduce conflicts.

Merging and conflicts

Often Git merges changes automatically. When two branches change the same lines, it cannot decide, and you get a merge conflict. Git marks the conflicting sections in the files.

To resolve:

1. Open the file and find the conflict markers.
2. Decide what the final code should be: keep one side, the other or a combination.
3. Remove the markers.
4. Stage the file and commit.
5. Test the result.

Conflicts are normal in collaboration. Communicate with teammates to reduce them, work in small increments and pull often. Many editors offer tools for resolving conflicts visually.

Remotes: sharing your work

A remote is a copy of the repository hosted elsewhere.

git remote -v
git push origin main
git pull origin main

• Push sends your commits to the remote.
• Pull fetches and merges changes from the remote.
• Fetch downloads changes without merging, giving you a chance to inspect first.

Pull before you push to avoid rejected pushes. Be careful with force pushing, which can overwrite others' work. Avoid it on shared branches.

Undoing things safely

Mistakes happen. Choose the right tool.

• Discard changes in a file you have not staged: restore the file from the last commit. This permanently loses uncommitted edits, so be sure.
• Unstage a file: remove it from the staging area without losing changes.
• Fix the last commit message or add a forgotten file: amend the most recent commit, but only if you have not shared it.
• Undo a commit already shared: create a new commit that reverses it, which keeps history intact.
• Return to an earlier state: check out an old commit to look around, or reset a branch with care.
• Recover lost work: Git keeps a reference log of where branches have been, which can help recover commits that seem lost.

Learn the safe commands first. Commands that rewrite history, such as hard reset and rebase, are powerful and can cause problems on shared branches. If unsure, make a backup branch first.

Ignore files you should not track

Some files should stay out of the repository.

• Secrets: passwords, keys and tokens.
• Personal or sensitive data.
• Generated files such as compiled output.
• Dependencies that can be reinstalled.
• Operating system and editor files.
• Large binary files.

Create an ignore file listing patterns of files to exclude. If you accidentally commit a secret, treat it as exposed: revoke and replace it, since removing it later does not erase it from history.

Collaboration workflows

Simple shared workflow

Everyone works on branches, opens a pull request on a hosting platform, gets feedback and merges after review.

Forking workflow

Contributors copy the project, change their copy and propose changes back. This is common in open source.

Small team habits

• Agree on branch names and commit message styles.
• Review each other's code.
• Merge frequently.
• Use issues to track tasks.
• Protect the main branch from direct changes if the platform allows.

Rebase, in a nutshell

Rebase moves a branch's commits onto a new base, producing a linear history. It can make history tidier, but rewriting commits that others have seen causes trouble. As a beginner, prefer merging, and learn rebase later with guidance.

Useful extras

• Stash: temporarily put aside uncommitted changes so that you can switch tasks.
• Tags: label important points, such as releases.
• Blame: see who last changed each line, useful for understanding history rather than assigning fault.
• Bisect: find the commit that introduced a bug by binary search.
• Hooks: scripts that run automatically at certain points.
• Aliases: shortcuts for common commands.

You do not need these on day one.

Graphical tools

Many editors and applications provide visual interfaces for Git. They can help you understand history and resolve conflicts. Learn the underlying commands too, because they work everywhere and help in troubleshooting.

Practice exercises

1. Create a repository for a small project. Make five commits with clear messages.
2. Create a branch, make changes, merge it and delete the branch.
3. Create a conflict deliberately by changing the same line in two branches, then resolve it.
4. Undo a mistake: commit a wrong change, then revert it.
5. Set up an ignore file and test that it works.
6. Clone a repository, make a change and push it to your own copy.
7. Work with a friend: share a repository, make changes in parallel and merge.
8. Write a README for your project.

Repeat until the workflow feels natural.

Common errors and what they mean

• Nothing to commit: you have no staged changes. Check status.
• Rejected push: the remote has changes you do not. Pull first.
• Detached head: you are looking at an old commit, not on a branch. Create a branch if you want to keep changes.
• Merge conflict: resolve as above.
• Permission or authentication errors: check credentials and access.
• Untracked files would be overwritten: move or remove them, or stash.

Read messages carefully. They usually suggest what to do.

Common mistakes

• Committing everything at once with vague messages.
• Committing secrets or large files.
• Force pushing to shared branches.
• Working on the main branch all the time.
• Not pulling before pushing.
• Fear of experimenting.
• Never reading status output.

A quick checklist

• Do I understand working directory, staging and commits?
• Can I branch, merge and resolve a conflict?
• Do I write clear commit messages?
• Have I set up ignore rules and kept secrets out?
• Do I know safe ways to undo mistakes?

Final thoughts

Git feels complicated until you see the simple model underneath. Commit small, meaningful snapshots, use branches to experiment and write clear messages. Keep secrets and large files out, and learn safe ways to undo changes. With a few exercises, version control becomes a quiet, reliable habit that supports every project you build.