Basic Git Operations

Git is a version control system that records and manages file change history. It lets you save the current state of code, just like taking a photo. You can always return to a saved point (a commit), and multiple people can edit the same project safely.

Checking Whether Git Is Installed

Git comes preinstalled on Mac. Check it from the terminal:

git --version
# If something like git version 2.46.0 is shown, you are good

If nothing is shown, install it with Homebrew:

brew install git

Initial Setup

Before using Git for the first time, register your name and email address. This information is used in commit records.

git config --global user.name "Your Name"
git config --global user.email "your@email.com"

Check the settings with:

git config --list

The Basic Git Concept: Three Areas

Git manages files by moving them through three areas:

Working Directory      Staging Area           Repository
   files are edited   ->  git add  ->     git commit stores

Area	Description
Working Directory	Where you actually edit files
Staging Area	Where you choose which changes will be committed
Repository	Where committed history is stored

Main Commands

Initializing a Repository

git init

Run this inside a project folder to make Git manage it. A hidden .git folder will be created.

Checking the Current State

git status

Shows which files have changed and which ones are staged. It is one of the most frequently used commands.

Staging Changes

git add .             # Stage all changes
git add index.html    # Stage only one file

Committing

git commit -m "message"

Records the staged changes. Write the message as a short description of what you changed.

# Example commit messages
git commit -m "Fix login screen design"
git commit -m "Add setup instructions to README"

Viewing History

git log            # Detailed history
git log --oneline  # Short one-line history

Viewing Diffs

git diff           # Changes before staging
git diff --staged  # Changes after staging

Creating .gitignore

.gitignore is the file that tells Git which files and folders to exclude from tracking. Files that contain passwords or are generated automatically should not be committed.

Create a file called .gitignore in the project root and write:

node_modules/
.env
.DS_Store
dist/

Excluded Item	Reason
node_modules/	npm packages can be recreated with npm install
.env	May contain API keys or passwords
.DS_Store	File automatically created by Mac
dist/	Build output can be regenerated

⚠️ If you commit .env, passwords and API keys may be exposed. Always add it to .gitignore.

Basic Workflow Summary

# 1. Initialize Git in the project folder
git init

# 2. Edit files in your editor

# 3. Check the current state
git status

# 4. Stage the changes
git add .

# 5. Commit the changes
git commit -m "Initial commit"

# 6. View history
git log --oneline

Common Beginner Mistakes and Fixes

You forgot the commit message

git commit   # Without -m, an editor opens
# If you cannot enter the editor, press Ctrl + C and use -m
git commit -m "message"

You staged the wrong file by mistake

git restore --staged index.html  # Undo staging for one file
git restore --staged .           # Undo staging for everything

You want to change the most recent commit message

git commit --amend -m "updated message"

⚠️ Do not use --amend for commits that have already been pushed to GitHub, because it rewrites history.

You want to undo changes before committing

git restore index.html  # Restore a file to the last committed state

FAQ

Q. What is the difference between git init and git clone?

git init creates a new repository from scratch. git clone downloads and copies an existing repository, such as one on GitHub.

Q. How often should I commit?

The basic rule is to make one commit for one meaningful change. Even a small fix in one file is fine. Committing often makes it easier to go back if something goes wrong.

Q. Can commit messages be written in Japanese?

Yes, for personal projects or Japanese-speaking teams. English is more common in international projects. Follow your team’s rules.