Git-Get

Quick reference for frequent Git operations

Installation of Git

Git isn't a service running in the background; it’s an executable program that only runs when you call it. sudo systemctl won't work.

Check if git is installed:

git --version

Install git if necessary:

sudo apt update
sudo apt install git

Git Operations

Rename git main branch name from master to main

git branch -m main

Add and remove files from a commit

Add a file

git add correct_file.txt
git add .
git add *
git add -A

Remove a file from the staging area

git reset HEAD wrong_file.txt 
git restore --staged wrong_file.txt

Check Status and History

Check status and all branches created:

git status

git branch

(This lists all your branches and puts a * next to your current one).

Check commit history:

# up to current HEAD position
git log
git log --oneline

# all commits regardless HEAD position
git log --all
git log --all --oneline

# all commits in a branch without checking it out
git log main

Count commits:

git rev-list --count HEAD

Moving Up and Down Commit History

To go up by 1 commit

git checkout main^
git checkout HEAD^
git checkout HEAD~1

To go up the commit history tree n levels

# git checkout HEAD~n
git checkout HEAD~2

Git allows moving only up the commit history, because each commit can have numerous branches. To go down the commit history, you need to specify exactly where to go.

To go down the commit history tree:

# go to precise position:
git checkout ce85b75

# go one commit down:
git checkout -

# return to the tip of the branch:
git checkout main

Branching

git branch feature3
git checkout feature3

git checkout -b feature3

Merge commits from the branch to main

(Standard way)

Merging always happens from the perspective of the branch you want to receive the changes.

You must be on the branch that is receiving the updates.

git checkout main
git merge feature3

Even after being merged, branches remain. To delete merged branches to create a clean chronological commit history:

git branch -d feature3
git btrach -d feature4

(Note: The lowercase -d is a "safe" delete. Git will actually stop and warn you if you try to use -d on a branch that hasn't been merged into main yet).

Merge commits with rebase -i

git checkout main
# combine last two commits
git rebase -i HEAD~2
# change pick to squash to branch being squashed
pick 0af55bd feature3
squash bb19d1e feature4

save a close change the commit comment for the joined commit and save: Updated text of the comment

Rebasing code on top of updated code

The time you do use rebase with other people's code is when you want to update your private branch with their newly merged work.

Imagine you are working on feature4. Meanwhile, your coworker finishes feature5, merges it into main, and pushes it to the server. Your local main is now outdated.

Here is the professional way to catch up:

git checkout main  # position onto main branch
git pull           # pull new commits
git checkout feature4 # move to your project branch
git rebase main    # rebase to <target branch>
# now main is followed by feature4
git checkout main
git merge feature4

Remove a commit

git reset (local branch only)

git reset literally moves your HEAD and branch pointer backward in time, effectively erasing the commits that came after it. Only use this on commits you have NOT pushed to a remote server.

You use it by telling Git where you want to go back to (e.g., git reset HEAD~1 to go back one commit).

When you travel back in time, Git needs to know what to do with the files you were just working on. You give it one of three flags:

1. Use case: You made a commit, but immediately realized you forgot to add a file to it.

git reset --soft HEAD~1

(The "Oops, I forgot a file" reset)

• Moves the commit history back by 1.
• Keeps all your changed files exactly as they are.
• Leaves them staged (ready to be committed again).

2. Use case (The Default): You made a commit, but realize you want to break that work up into two separate, smaller commits. (If you just type git reset HEAD~1 without a flag, it defaults to --mixed).

git reset --mixed HEAD~1

• Moves the commit history back by 1.
• Keeps all your changed files exactly as they are.
• Leaves them unstaged.

3. Use case: Your recent code is a disaster, it's completely broken, and you just want to wipe the slate clean and start over from the last good commit. (Be very careful with this one!)

git reset --hard HEAD~1

(The "Burn it with fire" reset)

• Moves the commit history back by 1.
• Deletes all your changes completely. Your files are reverted to exactly how they looked at that older commit.

git revert (remote branch only)

git revert does not delete any history. Instead, it creates a brand new commit that does the exact mathematical opposite of the commit you want to undo.

If Commit A added 5 lines of code and deleted 1 line, reverting Commit A will create Commit B, which deletes those 5 lines and restores the 1 line.

How to use it: Find the hash of the commit you want to undo using git log --oneline (let's say it's ce85b75), and run:

git revert ce85b75

Git will pop open your text editor to let you save the commit message (which defaults to something like "Revert 'feature2'"). Save and close.

When to use it: Use this if you pushed a feature to your team's GitHub repository, and an hour later someone realizes it broke the server. You cannot use git reset because your team has already downloaded your bad commit. You use git revert to push a "fix" that undoes the damage while keeping the project history intact for everyone.

Trashing uncommitted changes to start over

To overwrite all your current modifications and restore the files to exactly how they looked at the last commit:

git restore .
# or
git checkout .

If you made a massive mess, modified files, and created a bunch of new files that you just want to completely destroy, you can force your working directory to perfectly mirror your last commit:

git reset --hard HEAD
git clean -fd

(-f force clean, -d delete entire directories)

Connecting to remote

Connecting your Local Repo to GitHub

Important Prep Step: When you create the new repository on GitHub, do NOT check the boxes to add a README, .gitignore, or License. You want the GitHub repository to be completely, 100% empty. If you add files on GitHub first, Git will complain that the two repositories have different histories.

nce you have your empty GitHub repo, copy the URL (HTTPS or SSH, whichever you normally use).

1. Add the remote:

git remote add origin https://github.com/....your repor.git

git remote -v # lists the URL

2. Ensure local branch is named 'main':

git branch -m main

3. Push and Link Now, you need to push your local code up to the server. Because this is the very first time, you need to use the -u (upstream) flag. This permanently links your local main branch to the main branch on origin.

git push -u origin main

Syncing to shared project repository

git pull --rebase

When you add the --rebase flag, it changes that invisible second step. Instead of git fetch + git merge, it becomes git fetch + git rebase.

1. It downloads your coworker's new commit from GitHub.
2. It temporarily unplugs your new local commit.
3. It places your coworker's commit onto your local main branch.
4. It plugs your local commit back in on top of the coworker's commit.

It results in a perfectly straight line of history. It looks as if you waited for your coworker to finish, downloaded their work, and then started yours. There are no messy merge commits, and you can now git push cleanly to the server!

Replacing a remote repository with local project

1. Copy the repository link
2. Connect to the remote

git remote add origin https://github.com/your-username/your-repo-name.git

(check: git remote -v) 3. Soft push (retain origin commits)

git pull origin main --allow-unrelated-histories

3. Force push (replace origin with local)

git push -u origin main --force

Useful Links

1. https://learngitbranching.js.org/