Git and Version Control Basics

Git is a distributed version control system (DVCS) that tracks changes in files over time. Unlike centralized systems such as SVN, every Git clone contains the full history of the project, so you can work offline and commit locally. A repository (repo) is a directory managed by Git; it stores snapshots of your project in a hidden .git folder. Each snapshot is called a commit, identified by a unique SHA-1 hash. Git also provides branching and merging, allowing multiple lines of development. You interact with Git through the command line (e.g., git init, git add, git commit) or graphical clients. It is free, open-source, and runs on Windows, macOS, and Linux. Git is not the same as GitHub, GitLab, or Bitbucket—those are hosting services for Git repositories. Understanding Git means you can track your own work, revert mistakes, and collaborate without overwriting others' changes.

Version control is essential for any project that changes over time. Without it, you risk losing work, overwriting files, or being unable to answer "what changed and why?" Git solves these problems by recording every commit with an author, timestamp, and message. You can revert to any previous state, compare versions, and see who changed what. For teams, Git enables parallel work through branches: one developer can fix a bug while another adds a feature, then merge their changes. It also supports code review via pull requests on hosting platforms. Even for solo learners, Git is a safety net—you can experiment freely and discard bad ideas. Many employers expect Git skills, and open-source contribution relies on it. Learning Git early builds good habits: small, focused commits; clear messages; and a clean history. It also integrates with continuous integration and deployment pipelines. In short, Git turns a folder of files into a managed, collaborative project.

Git thinks of data as a series of snapshots. When you commit, Git stores a reference to that snapshot in its object database. Files can be in three main states: modified (changed but not staged), staged (marked to go into the next commit), and committed (safely stored). The basic workflow is: edit files, stage changes with git add, then commit with git commit. The staging area (index) lets you craft commits precisely. Branches are lightweight movable pointers to commits; the default branch is often called main or master. HEAD points to your current branch. Merging combines histories: a fast-forward merge moves the pointer; a three-way merge creates a merge commit. Remotes are named URLs (e.g., origin) where you push or pull commits. Git uses SHA-1 hashes to identify objects, ensuring integrity. Conflicts occur when the same part of a file is changed differently; you resolve them manually, then git add and git commit. Understanding these concepts prevents confusion.

Suppose you start a new project. Open a terminal and run:

mkdir my-project
cd my-project
git init
echo "# My Project" > README.md
git add README.md
git commit -m "Add README"

Now you have a local repo with one commit. Edit README.md, then check status:

git status

Stage and commit the change:

git add README.md
git commit -m "Update README"

To see history, run git log --oneline. To create a branch and switch to it:

git checkout -b feature

Make a change, commit it, then switch back to main and merge:

git checkout main
git merge feature

If you want to share, create a remote on a hosting service, then:

git remote add origin https://example.com/your/repo.git
git push -u origin main

This example shows the core cycle: edit, stage, commit, branch, merge, and push.

Beginners often commit too much or too little. Committing every tiny change clutters history; committing rarely makes it hard to isolate issues. Aim for logical units. Another mistake is forgetting to stage files before committing—git commit only includes staged changes. Also, writing vague messages like "fix stuff" reduces history's value. Use imperative mood: "Fix login bug". Many learners accidentally commit sensitive data (passwords, API keys). Once pushed, removing them is difficult; use .gitignore and environment variables. Confusing git pull with git fetch is common: pull fetches and merges, which can cause unexpected merges. Another error is working directly on main instead of a feature branch, making it harder to review and revert. Merge conflicts intimidate beginners; they are normal—edit the file to keep the desired lines, remove conflict markers, then git add and git commit. Finally, don't panic if you make a mistake: Git rarely loses committed data, and commands like git reflog can help you recover.

Practice Git daily on small projects. Start by initializing a repo for a personal notes folder or a simple script. Make a commit after each meaningful change. Use git log and git diff to review. Create branches for experiments: git checkout -b experiment, make changes, then merge or discard. Try resolving a conflict intentionally: create two branches that edit the same line, merge them, and fix the conflict. Learn to undo: git checkout -- file discards unstaged changes; git reset HEAD file unstages; git commit --amend fixes the last commit. Use git stash to temporarily save work. Set up a remote on GitHub or GitLab and practice push/pull. Collaborate with a friend: one creates a pull request, the other reviews. Read the official Git book (Pro Git) for depth. Use interactive tools like git add -p to stage parts of files. Keep a cheat sheet of commands. Over time, these actions become muscle memory, and you'll appreciate Git's power.

What is the difference between Git and GitHub? Git is the version control tool installed on your computer; GitHub is a website that hosts Git repositories and adds collaboration features like issues and pull requests. You can use Git without GitHub. How do I undo a commit? If you haven't pushed, git reset --soft HEAD~1 undoes the commit but keeps changes staged; --mixed keeps them unstaged; --hard discards them. If you have pushed, use git revert to create a new commit that reverses the changes. What is a merge conflict and how do I fix it? It happens when Git cannot automatically combine changes from two branches. Open the conflicted file, look for <<<<<<<, =======, and >>>>>>> markers, edit to the desired content, remove the markers, then git add and git commit. Practice with a friend to build confidence.