Blog

One overwritten file can erase an afternoon of work. Folders named project-final, project-final-2, and project-really-final may feel like a backup plan, until you need to compare changes, recover one line, or combine work from another person. Git replaces that uncertainty with a history of intentional snapshots.

Git is a distributed version control system. It tracks changes in a project, lets you mark important points in its history, and helps several people work on the same files without overwriting each other’s edits. It is most commonly used for source code, but it also works well for configuration files, documentation, scripts, and other text-based assets.

What Git records and why it matters

Git does not simply save copies of files whenever you make an edit. You select a group of changes, explain them briefly, and create a commit. Each commit becomes a permanent entry in the project history and records the state of the selected files at that point.

A commit should usually represent one small, coherent piece of work, such as:

• Adding a method that validates an email address
• Fixing an off-by-one error in a C++ loop
• Updating installation instructions
• Changing a default security setting in a lab configuration

That history helps answer practical questions without relying on memory: Which change introduced a bug? What did a file contain last week? Why was a configuration value changed? Clear commit messages make those answers much easier to find.

Git is not a hosting service. Git runs on your computer and manages repository history locally. A remote hosting platform can store another copy online for collaboration and backup. You can learn Git entirely on your own machine before connecting a repository to any remote service.

The vocabulary that makes Git less confusing

Git reuses a small set of terms. Learn them early, and the commands become easier to understand.

Term	Meaning
Repository	A project folder managed by Git, including its version history.
Working directory	The files currently checked out on your computer and available for editing.
Staging area	A selection area where you choose exactly which changes will enter the next commit.
Commit	A recorded snapshot of staged changes with a message and unique identifier.
Branch	An independent line of development within the same repository.
Remote	A named connection to another copy of the repository, often hosted online.
Clone	A local copy of an existing repository, including its history.

The staging area is often the unfamiliar part. Think of it as a review tray between editing and committing. You might change five files but stage only the two that belong to one focused fix. The remaining three stay in your working directory until they are ready for a later commit.

Set up Git once

After installing Git, configure the name and email address that should appear in your commits. Choose an address appropriate for work you plan to publish or share. Git records these values in commit metadata, so avoid using private details in repositories that could become public.

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

Check the configuration with:

git config --global --list

The --global option applies these settings to repositories created under your user account. Individual projects can override them when necessary. Git can also open an editor for commit messages, though beginners may prefer to write messages directly on the command line at first.

Create your first local repository

Use a small practice folder for your first repository. This example creates a project, initializes Git, and adds a simple README file.

1. Create and enter a folder.
2. Initialize the repository.
3. Create or edit a file.
4. Inspect the changes.
5. Stage and commit the intended file.

mkdir hello-git
cd hello-git
git init
printf "# Hello Gitn" > README.md
git status
git add README.md
git commit -m "Add project README"

git init creates a hidden .git directory. It contains the repository database and history. Do not delete it unless you intentionally want the folder to stop being a Git repository.

git status is one of the safest commands to run often. It shows your current branch, untracked files, staged changes, and edits that have not been staged. Run it before and after Git operations you do not yet know well.

The everyday edit-stage-commit cycle

Suppose you add a second line to README.md. Git notices that the file differs from its last committed version, but it does not automatically place that edit in a new commit.

git status
git diff
git add README.md
git diff --staged
git commit -m "Describe the project purpose"

git diff shows unstaged changes. After git add, git diff --staged shows the contents of the next commit. Checking both views helps prevent accidental commits of debug output, generated files, or unfinished work.

Start commit messages with an action and describe the result: Add input validation, Fix null pointer check, or Document local setup. Messages such as updates and stuff are not very helpful when you review history later.

Reading history and recovering calmly

Use git log to view commits. Once a project has several entries, this compact form is handy:

git log --oneline

To inspect one commit in detail, use its abbreviated identifier:

git show a1b2c3d

For the history of a specific file, run:

git log -- README.md

Most mistakes do not require a dramatic recovery command. If you changed a tracked file but have not staged it, inspect the difference first. If you are certain that you want to discard those local edits, modern Git provides:

git restore README.md

This replaces the working copy with the file’s last committed version. It can destroy edits that are not saved elsewhere, so run git diff before restoring. If you are unsure what should remain, making a temporary copy first is usually the safer choice.

A committed change is usually best corrected with a new commit instead of rewriting shared history. The correction remains visible, which is safer when someone else may already be working from the original commit.

Ignore files that should not be tracked

Some files belong on a developer’s computer but not in a repository: build output, temporary logs, local editor settings, downloaded dependencies, and secrets. A .gitignore file tells Git to leave selected untracked files alone.

# Java build output
*.class
build/

# C++ build output
*.o
*.exe

# Local environment files
.env

# Editor files
.vscode/

Patterns in .gitignore do not remove files Git already tracks. If a secret or generated file was committed earlier, adding it to the ignore file does not erase it from repository history. Treat exposed credentials as compromised: revoke or rotate them through the relevant service, then remove them from active project files through an appropriate, reviewed process.

Keep API keys, passwords, private certificates, and tokens outside source files whenever possible. Use environment variables or local configuration files excluded by .gitignore. The same rule applies to coursework and security labs: commit scripts and notes only when they are safe to share and contain no sensitive lab credentials or private data.

Branches: separate work without copying folders

A branch lets you make related changes without disturbing the stable version on your main branch. Most current Git installations use main as the default branch name, although older repositories may use master.

Create a branch and switch to it:

git switch -c add-greeting

Make changes, stage them, and create commits as usual. To return to the main branch:

git switch main

When the work is ready to combine with the main branch, merge it:

git merge add-greeting

Git can merge changes automatically when they affect different parts of the project. A merge conflict happens when Git cannot safely choose between overlapping edits. It is not a failure; Git is asking for a human decision.

Resolving a merge conflict safely

When a conflict occurs, Git marks the affected sections in the file. Review both versions, edit the file into the intended final state, remove the conflict markers, then stage and commit the resolution.

git status
# Edit the conflicted file carefully
git add README.md
git commit -m "Resolve README merge conflict"

Run the project’s tests, or at least compile it, after resolving a conflict. A completed merge means only that the text conflict is gone; it does not prove that the combined program works as intended.

Working with remotes

A remote is another destination for your repository, usually used for synchronization and collaboration. To start with an existing remote project, use:

git clone REPOSITORY-ADDRESS

Cloning creates a folder, downloads the project history, and usually names the primary remote origin. If you created the repository locally, adding a remote often looks like this:

git remote add origin REPOSITORY-ADDRESS
git push -u origin main

The -u option associates your local main branch with its remote counterpart. After that, git push is usually enough to publish committed local work.

Before starting work in a shared repository, synchronize first:

git pull --ff-only

This updates your branch only when Git can move it forward cleanly, without creating an automatic merge commit. If it stops because local and remote histories differ, inspect the situation instead of forcing a push. In team projects, coordinate with contributors and resolve differences through the usual branch and review process.

A compact Git routine for beginner projects

Use this sequence after completing a small piece of work:

1. Check the repository state with git status.
2. Edit and test one focused change.
3. Review it with git diff.
4. Stage only related files with git add file-name.
5. Review the staged snapshot using git diff --staged.
6. Create a clear commit with git commit -m "Meaningful message".
7. Push when working with a configured remote.

Practice in a disposable folder until the commands feel routine. Create a file, commit it, change one line, inspect the diff, commit again, and view both entries with git log --oneline. The exercise reinforces the key idea: Git records the changes you select, not every keystroke you make.