Code-Memo

Git

Git is a version control system. It tracks changes in files so you can:

• go back to older versions,
• work on features safely,
• collaborate with others,
• review history,
• undo mistakes.

Think of Git as 3 places:

1. Working directory — your files on disk.
2. Staging area — the “next commit” preview.
3. Repository — saved history of commits.

---

1) The core idea

A commit is a snapshot of your project at a point in time.

Typical flow:

git add .
git commit -m "message"
git push

Meaning:

• git add = choose what goes into the next snapshot
• git commit = save the snapshot locally
• git push = send it to remote like GitHub

---

2) First-time setup

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main

Useful settings:

git config --global core.editor "code --wait"
git config --global -l

---

3) Create or get a repository

Create a new repo:

git init

Clone an existing repo:

git clone <repo-url>

Example:

git clone https://github.com/user/project.git

---

4) See what is happening

These are the commands you use all the time:

git status
git diff
git diff --staged
git log
git log --oneline --graph --decorate --all

What they mean:

• git status = what changed?
• git diff = what changed but not staged?
• git diff --staged = what is staged and ready to commit?
• git log = commit history

---

5) Basic file states

A file can be:

• untracked — Git is not tracking it yet
• modified — tracked file changed
• staged — marked to be committed
• committed — saved in history

You usually move files like this:

edit -> git add -> git commit

---

6) Staging and committing

Add one file:

git add file.txt

Add all changes in current directory:

git add .

Commit:

git commit -m "Add login form"

Good commit messages are:

• short,
• clear,
• written like a summary of what changed.

Examples:

• Fix login redirect
• Add Docker support
• Remove unused helper

---

7) Undoing local changes

Discard changes in a file

git restore file.txt

This brings the file back to the last committed version.

Unstage a file

git restore --staged file.txt

This removes it from the staging area, but keeps the file changes.

Undo a commit but keep changes

git reset --soft HEAD~1

Use this when the last commit was wrong, but you want the changes back staged.

Undo a commit and unstage changes

git reset --mixed HEAD~1

This keeps the changes in your files, but unstaged.

Undo a commit and discard changes

git reset --hard HEAD~1

Be careful. This deletes local changes.

---

8) Commit history and navigation

View history

git log
git log --oneline

View a specific commit

git show <commit-hash>

Go to an old commit temporarily

git checkout <commit-hash>

Better modern form:

git switch --detach <commit-hash>

This puts you in detached HEAD state. It is okay for inspection, but not for normal work.

---

9) Branches

A branch is just a movable pointer to a line of work.

Main use:

• keep feature work separate,
• avoid breaking main,
• work on multiple things at once.

List branches

git branch

Create branch

git branch feature-login

Switch branch

git switch feature-login

Create and switch in one command:

git switch -c feature-login

Delete branch

git branch -d feature-login

Force delete:

git branch -D feature-login

---

10) Merge vs rebase

This is one of the most important Git concepts.

Merge

Combines branches by creating a merge commit.

git merge feature-login

Use merge when:

• you want to preserve exact branch history,
• you are working with others,
• you want the safest default.

Rebase

Moves your commits on top of another branch.

git rebase main

Use rebase when:

• you want a cleaner history,
• you are working on your own feature branch,
• you understand the risk.

Rule of thumb

• Do not rebase public branches that others already pulled.
• Rebase your local feature branch before merging if your team likes clean history.

---

11) Fast-forward merge

If the target branch has no new commits, Git can simply move the pointer forward.

git merge feature

This may create no merge commit if it can fast-forward.

---

12) Remote repositories

A remote is another copy of the repo, often on GitHub/GitLab.

See remotes

git remote -v

Add remote

git remote add origin https://github.com/user/repo.git

Push branch

git push -u origin main

-u sets the upstream, so later you can just run:

git push
git pull

Fetch remote updates

git fetch

This downloads new remote data but does not merge it into your branch.

Pull remote updates

git pull

This is basically:

git fetch
git merge

---

13) Push, fetch, pull in simple terms

• fetch = download changes
• pull = download and integrate changes
• push = upload your changes

If you want to be safer, use:

git fetch
git status
git log --oneline --graph --decorate --all

Then decide whether to merge or rebase.

---

14) Common collaborative workflow

A simple good workflow:

git switch main
git pull
git switch -c feature-x
# work...
git add .
git commit -m "Implement feature x"
git push -u origin feature-x

Then open a pull request / merge request.

---

15) Conflicts

A merge conflict happens when Git cannot decide how to combine changes.

Typical situation:

• you and someone else edited the same lines,
• or you rebased onto a branch with conflicting changes.

Git will mark conflict sections like this:

<<<<<<< HEAD
your changes
=======
their changes
>>>>>>> branch-name

Fix it by editing the file manually, then:

git add conflict-file.txt
git commit

If you are in the middle of a rebase:

git rebase --continue

If you want to stop and undo the rebase:

git rebase --abort

If you are in a merge and want to stop:

git merge --abort

---

16) Stash

Stash is temporary storage for unfinished work.

Use it when:

• you are mid-change,
• you need to switch branches quickly,
• you do not want to commit yet.

Stash changes

git stash

See stashes

git stash list

Re-apply stash

git stash pop

Keep stash but re-apply later

git stash apply

Remove a stash

git stash drop

---

17) Tagging releases

A tag marks an important commit, often a release.

git tag v1.0.0
git push origin v1.0.0

List tags:

git tag

Useful for releases and versioning.

---

18) Reset vs revert

This is a big one.

git reset

Moves branch history pointer. Mostly for local work.

git reset --soft HEAD~1
git reset --mixed HEAD~1
git reset --hard HEAD~1

git revert

Creates a new commit that undoes an old commit.

git revert <commit-hash>

Use revert when:

• the commit is already pushed,
• others may have pulled it,
• you want a safe public-history undo.

Rule of thumb

• reset = rewrite local history
• revert = safe undo in shared history

---

19) Cherry-pick

Apply one specific commit from another branch:

git cherry-pick <commit-hash>

Useful when you need one fix from somewhere else without merging everything.

---

20) Reflog: your safety net

Git remembers where HEAD and branches used to point.

git reflog

This is very useful after:

• bad reset,
• accidental delete,
• lost commit.

You can often recover a lost commit from reflog.

---

21) Clean working tree habits

Before you switch branches or commit, check:

git status

A clean state is easiest to manage.

Useful habits:

• commit small logical changes,
• avoid huge mixed commits,
• do not commit broken random stuff unless necessary,
• use branches for features/bugs.

---

22) Ignore files with .gitignore

Some files should not be tracked:

• logs,
• build artifacts,
• dependencies,
• local config,
• secrets.

Create .gitignore:

node_modules/
dist/
.env
*.log

Important:

• .gitignore only prevents new untracked files from being added.
• If a file is already tracked, adding it to .gitignore will not stop tracking it automatically.

To stop tracking a file but keep it locally:

git rm --cached file.txt

---

23) Useful inspection commands

See changed files:

git diff --name-only

See who changed lines:

git blame file.txt

See file history:

git log -- file.txt

See branch graph:

git log --oneline --graph --decorate --all

See a file at a commit:

git show <commit-hash>:path/to/file

---

24) Working with branches safely

Typical branch workflow:

git switch main
git pull
git switch -c fix-bug
# edit
git add .
git commit -m "Fix bug"
git push -u origin fix-bug

Later, after merge:

git switch main
git pull
git branch -d fix-bug

---

25) Pulling with rebase instead of merge

Sometimes teams prefer rebasing when pulling updates:

git pull --rebase

This keeps history more linear.

Use carefully, especially if your branch is shared.

---

26) Common mistakes and what they mean

“I committed the wrong file”

Use:

git reset --soft HEAD~1

Then fix staging and recommit.

“I changed a file and want to discard it”

Use:

git restore file.txt

“I staged the wrong file”

Use:

git restore --staged file.txt

“I need to switch branch but have unfinished work”

Use:

git stash
git switch other-branch
git stash pop

“I accidentally deleted something”

Check:

git reflog

---

27) Merge workflow in teams

A common professional flow:

1. Create branch
2. Work and commit
3. Push branch
4. Open pull request
5. Review
6. Merge into main
7. Pull main locally

This keeps main stable.

---

28) Rebase workflow in teams

A common clean-history flow:

git switch feature-x
git fetch origin
git rebase origin/main

Then resolve conflicts if any, continue, and push:

git push --force-with-lease

Important:

• Use --force-with-lease, not plain --force, when possible.
• Only do this on branches you own.

---

29) What HEAD means

HEAD points to your current position in history.

Usually:

• HEAD -> current branch -> latest commit

When detached:

• HEAD points directly to a commit

Example:

git show HEAD
git reset --soft HEAD~1

HEAD~1 means “one commit before HEAD”.

---

30) What origin means

origin is usually the default name for the remote repo you cloned from.

Example:

git push origin main
git pull origin main

You can have multiple remotes, but origin is the common one.

---

31) Daily Git commands you should memorize

These are the essentials:

git status
git add .
git commit -m "message"
git push
git pull
git fetch
git branch
git switch -c new-branch
git merge branch-name
git stash
git log --oneline --graph --decorate --all
git diff
git restore file.txt
git restore --staged file.txt
git reset --soft HEAD~1
git revert <commit>

---

32) Practical mental model for beginners

When something feels confusing, ask these questions:

1. What files changed?

   • git status

2. Are they staged?

   • git status, git diff --staged

3. Which branch am I on?

   • git branch

4. What is my history?

   • git log --oneline --graph --decorate --all

5. Do I need to save work first?

   • git stash or commit

6. Am I rewriting local history or shared history?

   • use reset for local, revert for shared

---

33) Practical cheat sheet by task

Start a project

git init
git add .
git commit -m "Initial commit"

Download an existing project

git clone <url>

Start a feature

git switch -c feature-name

Save work

git add .
git commit -m "Describe change"

Send work to GitHub

git push -u origin feature-name

Update your branch

git pull

Review changes

git status
git diff
git log --oneline --graph --decorate --all

Undo uncommitted changes

git restore file.txt

Undo last commit locally

git reset --soft HEAD~1

Undo a pushed commit safely

git revert <commit>

---

34) Best practices

• Commit often, but keep commits meaningful.
• Use branches for work.
• Pull before you start new work.
• Don’t rewrite shared history casually.
• Use revert for public undo.
• Read git status before every commit.
• Learn to resolve conflicts calmly.
• Keep .gitignore clean.
• Use git log --graph often to understand history.