Tutorials

• 1: Introduction to Git
• 2: Getting started with GIT
• 3: The Three Stages in Git
• 4: Introduction
• 4.1: Working with Branches
• 4.2: Creating Branches
• 4.3: Understanding HEAD
• 4.4: Merging Branches
• 4.5: Handling Merge Conflicts
• 4.6: Deleting Branches
• 4.7: Understanding Remote Branches
• 4.8: Understanding Upstream Branches
• 4.9: Renaming Branches
• 4.10: Rebasing Branches
• 4.10.1: Interactive Rebase in Git
• 4.10.2: Squash Commits with Interactive Rebase
• 4.10.3: Reordering Commits with Interactive Rebase
• 4.11: Reordering Commits
• 4.12: Branching Workflows
• 4.13: Branch Protection
• 4.14: Bonus Concepts
• 5: Stashing Changes in Git
• 6: Working with Remotes
• 7: Best Practices for Using Git
• 8:

1 - Introduction to Git

Git is an open source, distributed version control system (VCS) that helps you track changes in your code and collaborate with others efficiently.

Imagine you’re writing a book. You make changes every day—sometimes adding new chapters, sometimes fixing typos. After a few weeks, you wonder: What if I want to see the old draft? What if two people are editing the same chapter?

This is where Git comes in.

What is a Version Control System?

A Version Control System (VCS) keeps track of all the code added to a project. It preserves the history of your project, allowing you to:

• Roll back to earlier versions if bugs are introduced
• See how your software developed over time
• Audit and review changes

Why is Git Distributed?

Git is called distributed because the codebase isn’t stored on just one server. Each developer has their own full copy of the project. They can make changes independently and later merge their work back into the main project.

Why Git?

Git is a core topic in MIT’s Missing Semester, a course covering essential but often untaught tools for students and developers.

You don’t need to be a Git expert—just knowing the basics is enough to maintain your repository and contribute to others. You can learn more advanced features as you go.

Key Benefits of Git for Open Source

1. Integrity of History
   Project history lets users trust the software. Anyone can see how the software evolved, when components were added, and track new changes. This transparency helps contributors focus on testing and auditing new code.

2. Long-term Maintainability
   Git lets you associate commits with descriptive messages and author information. This helps future maintainers understand the code and contact past contributors if needed.

My Approach to Learning Git

Many Git workshops focus on GitHub and treat Git as a side utility. Typically, they walk you through forking a repo, making a minor change via the GitHub web interface, and creating a pull request. While this is a good start, it misses important concepts.

I recommend putting Git at the center. Learning the command line utility will serve you well throughout your journey. Once you know Git, you can use any hosting service—not just GitHub.

Tip: GitHub has a user-friendly UI, but mastering the command line gives you more power and flexibility.

A Note About Git GUI Programs

I’m not against GUI programs. Occasionally, I use them too! But while learning, it’s best to use the command line client. This way, you understand what’s happening under the hood and strengthen your knowledge.

Further Learning

Recorded lectures from The Missing Semester are free to view. Check out their website for more resources!

2 - Getting started with GIT

1. Installation

You only need to install Git once.

• Windows: Download from GIT and install.

• Mac:

  brew install git
  

• Linux (Ubuntu/Debian):

  sudo apt update && sudo apt install git
  

  • ArchLinux

  sudo pacman -Syu && sudo pacman -S git
  

Check if it’s installed:

git --version

2. The Git Workflow (The Big Picture)

Before typing anything, let’s understand how Git thinks.

Every project has:

1. Working Directory → where you edit files.

2. Staging Area → a “waiting room” where you prepare files you want to save.

3. Repository (Repo) → Git’s database where snapshots (commits) are stored.

The basic cycle is:

Edit files → Stage them → Commit them

If you keep this 3-step cycle in mind, Git will never feel scary.

3. Getting Started – Your First Project

Step 1: Tell Git who you are (only once)

git config –global user.name “Your Name” git config –global user.email “your@email.com”

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

This info will be attached to your changes.

Step 2: Create a Git repository

A repository = your project folder + Git’s history tracking.

mkdir myproject
cd myproject
git init

You just told Git: “Hey, start tracking this folder.”
[Caution: DO NOT initialize git in your local file system (like home, desktop, etc), always create a new file and then initialize git.]

Step 3: Add a file

echo "Hello Git" > hello.txt

Step 4: Check status

git status

It will say: “Untracked file: hello.txt” → meaning Git sees it but hasn’t saved it yet.

Step 5: Stage the file

git add hello.txt

Now hello.txt is in the staging area.

Step 6: Commit the file

git commit -m "First commit: added hello.txt"

Congratulations You just made your first snapshot!

4. Understanding Key Git Concepts

🔹 Commits = Snapshots

Every commit is like saving a checkpoint in a video game. If something breaks, you can go back.

🔹 Branches = Alternate Timelines

Imagine you want to try a new feature but don’t want to break your main project.
You create a branch:

git branch new-feature
git switch new-feature

Now you’re working in a separate timeline. When ready, you merge it back into main.

🔹 Logs = History Book

See your commits:

git log --oneline

It’s like flipping through a project’s diary.

🔹 Remote Repositories = Cloud Backup

Your local repo is only on your computer. A remote (like GitHub) is a backup + collaboration space.

• Add a remote:

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

• Upload your work:

  git push origin main
  

• Download updates from others:

  git pull
  

5. Correct Workflow to Follow (as a beginner)

Here’s a safe and simple workflow you should practice until it becomes second nature:

1. Start a project:

   git init # or
   git clone <url>
   

2. Make changes → edit files normally

3. Check status:

   git status
   

4. Stage changes:

   git add <file>
   

5. Commit changes:

   git commit -m "message"
   

6. Repeat steps 2–5 often

7. When working with others:

   • Pull updates first:

     git pull
     

   • Make your changes
   • Push them:

     git push
     

Think of it as: Pull → Work → Add → Commit → Push

6. Common Real-Life Examples

• Accidentally deleted a file?

  git checkout -- file.txt
  

• Want to see what you changed before committing?

  git diff
  

• Oops, wrong commit message?

  git commit --amend
  

• Need to undo last commit (but keep files)?

  git reset --soft HEAD~1
  

7. Limitations

• Large files (like videos, datasets) → use Git LFS.

• Merging conflicts can happen → but they’re just Git saying: “I don’t know which version to keep; please decide.”

• Git feels confusing at first → but with practice, it becomes second nature.

8. FAQ

Q: Is Git the same as GitHub?
No. Git is the tool. GitHub is a website to host Git projects.

Q: Do I need to know all commands?
No. Start with init, status, add, commit, log, push, pull. That’s enough for 80% of real-world use.

Q: Can I break my project using Git?
Not really. Since Git keeps history, you can always roll back.

9. Next Steps

Now that you know the basics:

• Practice by creating small projects.

• Use branches for experiments.

• Try pushing to GitHub and collaborating.

Over time, you’ll naturally pick up advanced features like rebasing, stashing, and cherry-picking.

3 - The Three Stages in Git

What Are the Three Stages in Git?

Git tracks your changes in three main stages:
Working Directory, Staging Area (Index), and Repository (Commit History).
Understanding these stages is key to mastering Git’s workflow!

1. Working Directory

• This is your project folder on your computer.
• Any changes you make to files—editing, adding, deleting—happen here first.
• Files in the working directory can be:
  • Untracked: New files Git hasn’t seen before.
  • Modified: Files you’ve changed since the last commit.

Example:
You edit main.py and add a new file README.md.
Both are in your working directory.

2. Staging Area (Index)

• The staging area is a place where you tell Git which changes you want to include in your next commit.
• You move changes from the working directory to the staging area using:

git add <filename>

• Only staged changes will be included in your next commit.

Example:
You want to commit only changes to main.py, not README.md yet:

git add main.py

Now, main.py is staged, but README.md is not.

3. Repository (Commit History)

• The repository is where Git permanently stores your project’s history.
• When you commit, all staged changes are saved as a new snapshot (commit) in the repository.
• Commits are safe, versioned, and can be shared with others.

Example:
You commit your staged changes:

git commit -m "Update main.py with new feature"

Now, your changes to main.py are part of the repository history.

Visual Summary

[Working Directory] --(git add)--> [Staging Area] --(git commit)--> [Repository]

• Working Directory: Where you edit files.
• Staging Area: Where you prepare changes for commit.
• Repository: Where your project’s history lives.

Why Are These Stages Important?

• Control:
  You choose exactly which changes to commit.
• Safety:
  Only committed changes are saved in history; you can undo or redo as needed.
• Collaboration:
  Commits can be shared, reviewed, and merged with others.

Tip:
Use git status often to see which files are untracked, modified, or staged.
Mastering the three stages gives you full control over your project’s

4 - Introduction

Branch in Git is like a parallel universe of your project.
It lets you work on new features without disturbing the main codebase.

Why Branches?

Imagine your project has a main branch.
You want to add a new feature. Instead of risking changes on main, you:

1. Create a new branch.
2. Work on it separately.
3. Merge it back when ready.

Git provides the ability to create branches so developers can work on new features or bug fixes without disturbing the main codebase.
Changes you make to a branch are stored separately from other branches. You can switch between branches at any time. When your changes are ready and working, you can merge the branch back into your main branch.

4.1 - Working with Branches

Listing Branches

To see your local branches, use:

git branch

Expected output:

* main

To list all branches (including remote branches), use:

git branch -a

Expected output:

* main
  remotes/origin/main

To list Remote branches (including remote branches), use:

git branch -r

Expected output:

* remotes/origin/main

• The branch marked with an asterisk (*) is your currently active branch.
• Any changes or commits you make are added to this branch.

Tip:
Use branches to keep your work organized and your main branch stable!

4.2 - Creating Branches

Creating a Branch

Command 1: Create only

git branch <branch-name>

• Creates a new branch.
• Does not switch to it.
• You’re still on the same branch as before.

Command 2: Create + switch

git checkout -b <branch-name>

• Shortcut: creates the branch and switches to it.
• Older syntax.

Command 3: Modern way

git switch -c <branch-name>

• Recommended modern syntax.
• Does the same thing as checkout -b.

4.3 - Understanding HEAD

What is HEAD in Git?

When working with Git, you’ll often hear about something called HEAD.
Think of HEAD as a special pointer that tells Git, “This is where you are right now.”

HEAD: Your Current Position

• HEAD always points to your current branch.
• That branch, in turn, points to a specific commit (a snapshot of your project).

Visualization:

HEAD
 ↓
branch (e.g. main)
 ↓
commit (e.g. a1b2c3d)

• When you make a new commit, the branch moves forward, and so does HEAD.

How HEAD Moves

• If you switch branches, HEAD moves to point to the new branch.
• If you make a commit, HEAD (via the branch) points to the new commit.

Detached HEAD State

Sometimes, HEAD doesn’t point to a branch, but directly to a commit.
This is called a detached HEAD.

When does this happen?

• When you checkout a specific commit, not a branch:

  git checkout <commit-hash>
  

• Now, HEAD points straight to that commit, not to any branch.

Visualization:

HEAD
 ↓
commit (not attached to any branch)

Why is this important?

• If you make new commits in this state, they’re not attached to any branch.
• If you switch branches, those commits can be lost (unless you create a new branch from here).

Recovering from Detached HEAD

If you accidentally end up in a detached HEAD and want to save your work:

1. Create a new branch from here:

   git switch -c my-temporary-branch
   

2. Now your work is safe on a branch!

Summary

• HEAD is your current position in the repo.
• Normally, HEAD points to a branch, which points to a commit.
• Detached HEAD means HEAD points directly to a commit.
• Always create a branch if you want to keep work done in detached HEAD!

Tip:
You can always check where HEAD is pointing by running:

git status

4.4 - Merging Branches

What is Merging?

Merging in Git is the process of taking the changes from one branch and combining them into another branch.
This is how you bring together work from different branches—like adding a new feature you built on a separate branch back into your main project.

Why Merge?

• You might have a main branch that holds your stable code.
• You create a feature branch to work on something new, so your main code isn’t disturbed.
• When your feature is ready, you want to add it back to main—without losing any work from either branch.
• Merging lets you combine the work from both branches, keeping all the commit history and changes.

How Does Merging Work?

When you merge, Git tries to automatically combine the changes from both branches.
If the changes don’t overlap, Git merges them automatically.
If the same lines were changed in both branches, you’ll get a merge conflict (see the Conflicts topic).

Types of Merges in Git

1. Fast-Forward Merge

What is a Fast-Forward Merge?

A fast-forward merge is the simplest type of merge.
It happens when the branch you’re merging into (like main) has not changed since you created your feature branch.
In this case, Git doesn’t need to do any real “combining”—it just moves the branch pointer forward.

Think of it like this:

• Imagine your project is a line of commits.
• You branch off main to make a feature branch.
• You make some commits on feature.
• Nobody else has made any new commits on main since you branched off.
• When you merge feature back into main, Git just moves the main pointer forward to where feature is.

Visual Example

Before merge:

A---B---C   (main)
         \
          D---E   (feature)

Here, main is at commit C, and feature has two extra commits (D and E).

If main hasn’t changed since you branched off, a fast-forward merge just moves main forward:

After merge:

A---B---C---D---E   (main, feature)

Now, both main and feature point to the same commit (E).
No new “merge commit” is created—Git just advances the pointer.

Command

git checkout main
git merge feature

If you see a message like “Fast-forward”, you just did a fast-forward merge!

2. Three-Way Merge

What is a Three-Way Merge?

A three-way merge happens when both branches have new commits since they split.
This means both main and feature have moved forward independently.

Why is it called “three-way”?

Because Git looks at three commits:

• The common ancestor (where the branches split)
• The tip of the current branch (e.g., main)
• The tip of the branch being merged (e.g., feature)

Git compares all three to figure out how to combine the changes.

Visual Example

Before merge:

A---B---C---F   (main)
         \
          D---E   (feature)

• C is where you branched off.
• main has new commits (F).
• feature has new commits (D, E).

When you merge, Git creates a new merge commit that combines the changes from both branches:

After merge:

A---B---C---F---M   (main)
         \     /
          D---E   (feature)

• M is the new merge commit.
• Both main and feature now point to M.

Command

git checkout main
git merge feature

If you see a message about a “merge commit”, you just did a three-way merge!

3. No-Fast-Forward Merge (--no-ff)

What is a No-Fast-Forward Merge?

Sometimes, even if a fast-forward merge is possible, you want to force Git to create a merge commit.
This is called a no-fast-forward merge.

Why would you want this?

• It makes your history clearer.
• You can always see exactly when a feature branch was merged in, even if there were no changes on main.

Visual Example

Before merge (same as fast-forward):

A---B---C   (main)
         \
          D---E   (feature)

After a no-fast-forward merge:

A---B---C-------M   (main)
         \     /
          D---E   (feature)

• M is the merge commit, even though it wasn’t strictly needed.

Command

git checkout main
git merge --no-ff feature

What Happens During a Merge?

1. Switch to the branch you want to merge into (usually main):

   git checkout main
   

2. Run the merge command:

   git merge feature
   

3. Git tries to combine the changes:
   • If there are no conflicting changes, the merge is automatic.
   • If there are conflicts, Git will pause and ask you to resolve them.

Tip:
Always make sure you’re on the branch you want to merge into before running the merge command!

You can use git log --graph --oneline to visualize your branch and merge history.

4.5 - Handling Merge Conflicts

What is a Merge Conflict?

A merge conflict happens when Git cannot automatically combine changes from two branches.
This usually occurs when two branches have changed the same part of a file, or when one branch deletes a file that the other branch has modified.

Why Do Conflicts Happen?

• Two people (or two branches) edit the same line in a file differently.
• One branch deletes a file that the other branch edits.
• Changes are made to the same section of a file in both branches.

Git tries to merge changes automatically, but if it’s unsure which change to keep, it stops and asks you to decide.

How Do You Know There’s a Conflict?

• When you run git merge (or git rebase), Git will pause and show a message like:

  Auto-merging file.txt
  CONFLICT (content): Merge conflict in file.txt
  Automatic merge failed; fix conflicts and then commit the result.
  

• git status will show files with conflicts as “Unmerged paths”.

What Does a Conflict Look Like?

Git marks the conflicting area in your file like this:

<<<<<<< HEAD
This is your change from the current branch.
=======
This is the change from the branch you are merging in.
>>>>>>> feature-branch

• Everything between <<<<<<< HEAD and ======= is your branch’s version.
• Everything between ======= and >>>>>>> branch-name is the other branch’s version.

How to Resolve a Conflict

1. Open the conflicted file(s).
2. Look for the conflict markers (<<<<<<<, =======, >>>>>>>).
3. Decide what the final content should be.
   • Keep your changes, the other branch’s changes, or combine them.
4. Remove the conflict markers and edit the file so it looks exactly how you want.
5. Mark the conflict as resolved by adding the file:

   git add <filename>
   

6. Complete the merge by committing:

   git commit
   

   • If you were in the middle of a merge, Git may auto-generate a commit message.

Example: Resolving a Conflict

Suppose both branches changed the same line in hello.txt:

After merging, hello.txt looks like:

Hello world!
<<<<<<< HEAD
This is my change.
=======
This is their change.
>>>>>>> feature-branch
Goodbye!

To resolve:

• Decide which line (or both) you want to keep.
• Edit the file, for example:

  Hello world!
  This is my change and their change.
  Goodbye!
  

• Save the file.
• Run:

  git add hello.txt
  git commit
  

Tips for Avoiding and Handling Conflicts

• Pull often to keep your branch up to date.
• Communicate with your team about what files you’re working on.
• Keep commits small and focused to make conflicts easier to resolve.
• Use tools like VS Code, GitKraken, or SourceTree for visual conflict resolution.

Tip:
You can always see which files have conflicts with git status.
Use git log --merge to see commits that are causing the

4.6 - Deleting Branches

Why Delete Branches?

Branches are great for working on features, bug fixes, or experiments.
But once a branch has served its purpose (for example, a feature is merged into main), it’s a good idea to delete it.
This keeps your repository clean and avoids confusion.

Deleting Local Branches

A local branch exists only on your computer.

Delete a Local Branch (Safe)

git branch -d <branch-name>

• Deletes the branch only if it has been fully merged into your current branch.
• Prevents you from accidentally deleting work that hasn’t been saved elsewhere.

Example:

git branch -d feature/login

Force Delete a Local Branch

git branch -D <branch-name>

• Force deletes the branch, even if it hasn’t been merged.
• Use with caution! You could lose work.

Example:

git branch -D old-experiment

Deleting Remote Branches

A remote branch is a branch stored on a remote server (like GitHub or GitLab), usually shared with others.

Delete a Remote Branch

git push origin --delete <branch-name>

• Tells the remote server to remove the branch.
• Other collaborators will no longer see this branch after they fetch or pull.

Example:

git push origin --delete feature/login

What Happens After Deletion?

• Local deletion only affects your copy of the repository.
• Remote deletion removes the branch for everyone, but others may still have a local copy until they delete it themselves.
• Deleting a branch does not delete the commits—they remain in the repository history unless they are unreachable from any branch or tag.

Common Scenarios

• After merging a feature branch:
  Delete the feature branch to keep your branch list tidy.
• Abandoned or stale branches:
  Remove branches that are no longer needed to avoid confusion.

Safety Tips

• Always make sure a branch is merged (or you no longer need its changes) before deleting.
• Use git branch to list local branches and git branch -a to see all branches.
• If you accidentally delete a branch, you can often recover it using git reflog (as long as the commits haven’t been garbage collected).

Tip:
Regularly clean up old branches to keep your repository organized and easy to

4.7 - Understanding Remote Branches

What is a Remote Branch?

A remote branch is a branch that exists on a remote repository (like GitHub, GitLab, or Bitbucket), not just on your local computer.
Remote branches let you collaborate with others by sharing your work and keeping your local repository in sync with the remote server.

How Do Remote Branches Work?

• When you clone a repository, Git creates local copies of all the remote branches.
• Remote branches are read-only references to the state of branches on the remote server.
• They are named like origin/main, origin/feature/login, etc.
  • origin is the default name for the remote you cloned from.

Common Remote Branch Commands

1. Listing Remote Branches

• List only remote branches:

  git branch -r
  

  Example output:

  origin/main
  origin/feature/login
  

• List all branches (local and remote):

  git branch -a
  

  Example output:

  main
  feature/login
  remotes/origin/main
  remotes/origin/feature/login
  

2. Fetching Updates from Remote

• Update your local copy of remote branches:

  git fetch
  

  • This downloads new commits and branch updates from the remote, but does not change your local branches.

3. Creating a Local Branch from a Remote Branch

If you see a remote branch (like origin/feature/login) and want to work on it locally:

git checkout -b my-local-branch origin/feature/login

• This creates a new local branch called my-local-branch that starts from the remote branch.

4. Pushing Local Branches to Remote

• Push a new local branch to the remote:

  git push origin <branch-name>
  

  • This creates a new branch on the remote server.

5. Tracking Remote Branches

When you create a local branch from a remote branch, Git can set up tracking so your local branch knows which remote branch it’s connected to.

• Set upstream (tracking) branch:

  git branch -u origin/main
  

  • Now, you can use git pull and git push without specifying the branch name.

How Do Remote Branches Get Updated?

• When you run git fetch, Git updates your local copies of the remote branches.
• When you run git pull, Git fetches and then merges changes from the remote branch into your current branch.

Deleting Remote Branches

• Delete a branch from the remote server:

  git push origin --delete <branch-name>
  

  • This removes the branch from the remote for everyone.

Why Are Remote Branches Important?

• They allow teams to collaborate by sharing code.
• They help keep everyone’s work in sync.
• You can always see what branches exist on the remote and what their latest commits are.

Tip:
Remote branches are read-only. To make changes, create a local branch from the remote branch, work on it, then push your

4.8 - Understanding Upstream Branches

What is an Upstream Branch?

An upstream branch in Git is the remote branch that your local branch is “tracking.”
This means your local branch knows which remote branch it should compare itself to when you run commands like git pull or git push—so you don’t have to specify the remote branch every time.

Why Use Upstream Branches?

• Convenience:
  You can simply run git pull or git push without extra arguments, and Git knows which remote branch to use.
• Collaboration:
  Keeps your local branch in sync with the team’s shared branch on the remote server.
• Safety:
  Helps prevent mistakes, like pushing to the wrong branch.

How Do You Set an Upstream Branch?

When Creating a Local Branch from a Remote Branch

If you create a local branch from a remote branch, Git usually sets the upstream automatically:

git checkout -b my-feature origin/my-feature

• Now, my-feature (local) tracks origin/my-feature (remote).

Setting or Changing Upstream Manually

You can set or change the upstream branch for your current branch with:

git branch -u origin/main

• This tells Git: “My current branch should track origin/main.”

Or, if you want to set it while pushing for the first time:

git push -u origin my-feature

• The -u (or --set-upstream) flag tells Git to set the upstream branch.

How Do You Know What Your Upstream Branch Is?

To see what upstream branch your current branch is tracking:

git status

• You’ll see something like:
  Your branch is up to date with 'origin/main'.

Or, for more detail:

git branch -vv

• This shows all local branches and their upstream branches.

What Happens When You Pull or Push?

• git pull
  Fetches changes from the upstream branch and merges them into your local branch.
• git push
  Sends your local commits to the upstream branch on the remote.

If you don’t have an upstream branch set, Git will ask you to specify where to push or pull.

Changing or Removing Upstream Branch

• Change upstream:

  git branch -u origin/another-branch
  

• Remove upstream:

  git branch --unset-upstream
  

Tip:
Always check your upstream branch before pushing or pulling, especially if you’re working on multiple features or with

4.9 - Renaming Branches

Why Rename a Branch?

Sometimes you create a branch with a quick name, but later want something more descriptive or consistent.
Renaming branches helps keep your repository organized and clear for everyone working on it.

Renaming a Local Branch

Rename the Current Branch

If you are on the branch you want to rename:

git branch -m new-branch-name

• -m stands for “move” (rename).
• This changes the branch name in your local repository.

Example:

git branch -m feature/login feature/authentication

Or, if you’re already on feature/login:

git branch -m feature/authentication

Rename a Different Local Branch

If you want to rename a branch you’re not currently on:

git branch -m old-branch-name new-branch-name

Renaming a Remote Branch

Renaming a branch on the remote (like GitHub) is a two-step process:

1. Push the Renamed Branch to Remote

git push origin new-branch-name

• This creates a new branch on the remote with the new name.

2. Delete the Old Branch from Remote

git push origin --delete old-branch-name

• This removes the old branch name from the remote.

3. Reset Upstream Tracking (Optional but Recommended)

If your local branch was tracking the old remote branch, update it to track the new one:

git branch -u origin/new-branch-name

What About Other Collaborators?

• After you rename and push, others will still have the old branch name locally.
• They should fetch the latest changes and delete the old branch locally:

  git fetch origin --prune
  git branch -d old-branch-name
  

Tip:
Renaming branches helps keep your project tidy and your workflow clear—don’t be afraid to update names as your project evolves!

• Make sure no one else is actively working on the branch you’re renaming, or coordinate with your team.
• Always double-check branch names before deleting anything on the remote.

4.10 - Rebasing Branches

What is Rebasing?

Rebasing is a way to move or combine a sequence of commits to a new base commit.
In simple terms, rebasing lets you “replay” your work from one branch onto another branch, creating a cleaner, linear history.

Why Use Rebase?

• Cleaner History:
  Rebasing creates a straight line of commits, making the project history easier to read.
• Avoids Merge Commits:
  Unlike merging, rebasing doesn’t create extra merge commits unless there are conflicts.
• Keeps Features Up-to-Date:
  You can update your feature branch with the latest changes from main before merging.

How Does Rebasing Work?

Imagine you have this history:

A---B---C main
         \
          D---E feature

If you run git rebase main while on feature, Git will:

1. Temporarily remove commits D and E from feature.
2. Move feature to the tip of main (commit C).
3. Replay D and E on top of C.

Result:

A---B---C---D'---E' feature

• D' and E' are new commits (copies of D and E).

Basic Rebase Command

git checkout feature
git rebase main

• This moves your feature branch to start from the latest commit on main.

Interactive Rebase

Interactive rebase lets you edit, reorder, squash, or drop commits.

git rebase -i HEAD~n

• Replace n with the number of commits you want to edit.
• You’ll see a list of commits in your editor, where you can:
  • pick (keep as is)
  • reword (edit commit message)
  • squash (combine commits)
  • drop (remove a commit)

Rebasing vs. Merging

• Merge preserves the full branch structure.
• Rebase rewrites history for a cleaner look.

Handling Conflicts During Rebase

• If there’s a conflict, Git will pause and let you resolve it.
• After fixing the conflict, run:

  git add <file>
  git rebase --continue
  

• If you want to abort the rebase:

  git rebase --abort
  

When (Not) to Rebase

• Do rebase:
  • On your own feature branches before merging, to clean up history.
• Do NOT rebase:
  • On public branches that others are using. Rebasing rewrites commit history, which can confuse collaborators.

Visualizing Rebase

Use this command to see your commit history as a graph:

git log --oneline --graph --all

Tip:
Rebasing is powerful for keeping your history tidy, but always be

4.10.1 - Interactive Rebase in Git

What is Interactive Rebase?

Interactive rebase is a powerful Git feature that lets you rewrite, edit, reorder, squash, or even delete commits in your branch’s history.
It’s called “interactive” because Git opens an editor and lets you choose exactly what happens to each commit.

Why Use Interactive Rebase?

• Clean up messy commit history before sharing your work.
• Combine (squash) multiple commits into one.
• Edit commit messages for clarity or consistency.
• Reorder commits to make history logical.
• Remove unwanted commits (like mistakes or debug code).
• Split a commit into smaller, more focused commits.

How to Start an Interactive Rebase

Decide how many commits you want to work with (counting backwards from your current commit):

git rebase -i HEAD~n

• Replace n with the number of commits you want to edit.
• Example: To edit the last 4 commits:

  git rebase -i HEAD~4
  

The Rebase Todo List

Git opens your default text editor with a list like:

pick a1b2c3d Add login form
pick b2c3d4e Fix typo
pick c3d4e5f Add logout button
pick d4e5f6g Update styles

• Each line is a commit, from oldest (top) to newest (bottom).
• The word pick means “keep this commit as is.”

What Can You Do in Interactive Rebase?

Replace pick with one of these commands:

• pick: Use the commit as is.
• reword: Edit the commit message.
• edit: Pause to change the commit’s content (amend).
• squash: Combine this commit into the previous one (good for cleanup).
• fixup: Like squash, but discard this commit’s message.
• drop: Remove the commit entirely.
• exec: Run a shell command.

Example: Squash and Reword

pick a1b2c3d Add login form
squash b2c3d4e Fix typo
reword c3d4e5f Add logout button
pick d4e5f6g Update styles

Step-by-Step Example: Squashing and Editing

Suppose you want to:

• Combine “Fix typo” into “Add login form”
• Edit the message for “Add logout button”

1. Start the rebase:

   git rebase -i HEAD~4
   

2. In the editor, change:

   pick a1b2c3d Add login form
   squash b2c3d4e Fix typo
   reword c3d4e5f Add logout button
   pick d4e5f6g Update styles
   

3. Save and close the editor.
4. Git will prompt you to combine commit messages for the squashed commits.
5. Git will prompt you to edit the commit message for the “reword” commit.
6. If there are conflicts, Git will pause and ask you to resolve them:
   • Fix the files.
   • Run git add <file>.
   • Continue with git rebase --continue.

Aborting or Continuing

• Abort the rebase and return to original state:

  git rebase --abort
  

• Continue after resolving conflicts:

  git rebase --continue
  

When to Use Interactive Rebase

• Before merging a feature branch, to tidy up your commits.
• When you want to split, combine, or reorder commits for clarity.
• When you need to edit a commit message or remove a mistake.

Caution

• Interactive rebase rewrites history.
  Only use it on branches that haven’t been pushed/shared with others, or coordinate with your team.
• Never rebase public/shared branches unless everyone agrees.

Tip:
Interactive rebase is one of the most powerful tools in Git for crafting a clean, professional commit history.
Practice on a test branch to get comfortable before using it on important

4.10.2 - Squash Commits with Interactive Rebase

What is Squashing?

Squashing means combining multiple commits into a single commit.
This is useful for cleaning up your commit history before merging a feature branch—so instead of a long list of tiny or “work in progress” commits, you have one clear, meaningful commit.

Why Squash Commits?

• Cleaner History:
  Makes your project history easier to read and understand.
• Atomic Changes:
  Groups related changes together, making it easier to review and revert if needed.
• Professionalism:
  Shows a tidy, intentional history when collaborating or submitting pull requests.

How to Squash Commits Using Interactive Rebase

Suppose your branch has several commits you want to squash into one.

1. Start an Interactive Rebase

Decide how many commits you want to squash.
For example, to squash the last 3 commits:

git rebase -i HEAD~3

2. The Rebase Editor

Git will open your default text editor with a list like:

pick a1b2c3d First commit
pick b2c3d4e Second commit
pick c3d4e5f Third commit

• The commits are listed from oldest (top) to newest (bottom).

3. Mark Commits to Squash

• Leave pick on the first commit.
• Change pick to squash (or just s) on the commits you want to combine into the first.

Example:

pick a1b2c3d First commit
squash b2c3d4e Second commit
squash c3d4e5f Third commit

• This will squash the second and third commits into the first.

4. Write the Commit Message

• After saving and closing the editor, Git will open another editor window to combine the commit messages.
• Edit the message to describe the combined changes clearly.
• Save and close the editor.

5. Finish the Rebase

• If there are no conflicts, you’re done!
• If there are conflicts, Git will pause and ask you to resolve them. After fixing, run:

  git add <file>
  git rebase --continue
  

Example: Before and After Squash

Before:

* c3d4e5f - Third commit
* b2c3d4e - Second commit
* a1b2c3d - First commit

After squashing:

* z9y8x7w - Combined commit (contains all changes)

Squash While Merging (Alternative)

You can also squash all commits from a feature branch into one when merging to main:

git checkout main
git merge --squash feature-branch
git commit

• This prepares a single combined commit from the feature branch.

When to Squash

• Before merging a feature branch into main or develop.
• When you want to clean up “work in progress” commits.
• When submitting a pull request and the project prefers a tidy history.

Tip:
Squashing is a great way to make your project history clean and professional.
But remember: **never squash commits on a branch that others are working

4.10.3 - Reordering Commits with Interactive Rebase

Why Reorder Commits?

Sometimes, you make commits in an order that doesn’t make sense for the project’s history.
Maybe you fixed a typo before adding the main feature, or you want related changes grouped together.
Reordering commits helps you organize your history so it’s logical, readable, and easy to review.

How to Reorder Commits in Git

You use interactive rebase to reorder commits.
This lets you pick up any commit and move it before or after others.

Step-by-Step: Reordering Commits

Suppose your history looks like this (from newest to oldest):

* d4e5f6g - Update styles
* c3d4e5f - Add logout button
* b2c3d4e - Fix typo
* a1b2c3d - Add login form

But you want “Fix typo” to come after “Add login form” and before “Add logout button”.

1. Start an Interactive Rebase

Decide how many commits you want to reorder (counting backwards from HEAD):

git rebase -i HEAD~4

2. The Rebase Todo List

Git opens your editor with:

pick a1b2c3d Add login form
pick b2c3d4e Fix typo
pick c3d4e5f Add logout button
pick d4e5f6g Update styles

• Commits are listed from oldest (top) to newest (bottom).
• The order here is the order they will appear in history after the rebase.

3. Change the Order

To reorder, simply move the lines up or down.

Example:
To put “Fix typo” after “Add logout button”:

pick a1b2c3d Add login form
pick c3d4e5f Add logout button
pick b2c3d4e Fix typo
pick d4e5f6g Update styles

• Save and close the editor.

4. Finish the Rebase

• Git will replay the commits in the new order.
• If there are conflicts, Git will pause and let you resolve them:
  • Fix the files.
  • Run git add <file>.
  • Continue with git rebase --continue.

Tips for Reordering Commits

• Test after reordering:
  Changing commit order can sometimes cause conflicts or break your code if commits depend on each other.
• Keep related changes together:
  Grouping related commits makes your history easier to understand.
• Use meaningful commit messages:
  After reordering, you can also use reword to update messages for clarity.

When to Reorder Commits

• Before merging a feature branch, to make history logical.
• When you want to group bug fixes or features together.
• When preparing a pull request for review.

Caution

• Reordering rewrites history.
  Only reorder commits on branches that haven’t been pushed/shared, or coordinate with your team.
• Never reorder commits on public/shared branches unless everyone agrees.

Tip:
Reordering commits is a great way to make your project history logical and professional.
Practice on a test branch to get comfortable before using it on important

4.11 - Reordering Commits

Why Reorder Commits?

Sometimes, you make commits in an order that doesn’t make sense for the project’s history.
Maybe you fixed a typo before adding the main feature, or you want related changes grouped together.
Reordering commits helps you organize your history so it’s logical, readable, and easy to review.

How to Reorder Commits in Git

You use interactive rebase to reorder commits.
This lets you pick up any commit and move it before or after others.

Step-by-Step: Reordering Commits

Suppose your history looks like this (from newest to oldest):

* d4e5f6g - Update styles
* c3d4e5f - Add logout button
* b2c3d4e - Fix typo
* a1b2c3d - Add login form

But you want “Fix typo” to come after “Add login form” and before “Add logout button”.

1. Start an Interactive Rebase

Decide how many commits you want to reorder (counting backwards from HEAD):

git rebase -i HEAD~4

2. The Rebase Todo List

Git opens your editor with:

pick a1b2c3d Add login form
pick b2c3d4e Fix typo
pick c3d4e5f Add logout button
pick d4e5f6g Update styles

• Commits are listed from oldest (top) to newest (bottom).
• The order here is the order they will appear in history after the rebase.

3. Change the Order

To reorder, simply move the lines up or down.

Example:
To put “Fix typo” after “Add logout button”:

pick a1b2c3d Add login form
pick c3d4e5f Add logout button
pick b2c3d4e Fix typo
pick d4e5f6g Update styles

• Save and close the editor.

4. Finish the Rebase

• Git will replay the commits in the new order.
• If there are conflicts, Git will pause and let you resolve them:
  • Fix the files.
  • Run git add <file>.
  • Continue with git rebase --continue.

Tips for Reordering Commits

• Test after reordering:
  Changing commit order can sometimes cause conflicts or break your code if commits depend on each other.
• Keep related changes together:
  Grouping related commits makes your history easier to understand.
• Use meaningful commit messages:
  After reordering, you can also use reword to update messages for clarity.

When to Reorder Commits

• Before merging a feature branch, to make history logical.
• When you want to group bug fixes or features together.
• When preparing a pull request for review.

Caution

• Reordering rewrites history.
  Only reorder commits on branches that haven’t been pushed/shared, or coordinate with your team.
• Never reorder commits on public/shared branches unless everyone agrees.

Tip:
Reordering commits is a great way to make your project history logical and professional.
Practice on a test branch to get comfortable before using it on important work!

4.12 - Branching Workflows

What is a Branching Workflow?

A branching workflow is a strategy for how you and your team use branches to organize work in a Git repository.
It defines how features, fixes, releases, and collaboration happen—making teamwork smoother and your project history clearer.

Why Use a Workflow?

• Organization:
  Keeps features, fixes, and releases separate.
• Collaboration:
  Allows multiple people to work independently.
• Safety:
  Protects stable code from unfinished or experimental changes.
• Traceability:
  Makes it easy to see what was done, when, and by whom.

Common Branching Workflows

1. Feature Branch Workflow

• Each new feature or fix gets its own branch.
• Branches are created from the main branch (often called main or master).
• When finished, the feature branch is merged back into main.

Example:

git checkout -b feature/login

• Work on your feature, then merge:

git checkout main
git merge feature/login

Benefits:
Keeps features isolated, makes code review easier.

2. Gitflow Workflow

A popular workflow for larger projects.

• Main branches:
  • main (or master): Always stable, production-ready code.
  • develop: Integration branch for new features.
• Supporting branches:
  • feature/*: For new features.
  • release/*: For preparing releases.
  • hotfix/*: For urgent fixes to production.

Example:

git checkout -b feature/payment develop

• Merge features into develop, then create a release branch when ready.

Benefits:
Organized, clear process for releases and hotfixes.

3. Trunk-Based Development

• Everyone works on a single branch (usually main).
• Feature branches are short-lived—merged quickly.
• Encourages frequent integration and small changes.

Example:

git checkout -b quick-fix
# Make changes
git checkout main
git merge quick-fix

Benefits:
Fast-paced, reduces merge conflicts, ideal for continuous integration.

4. Fork + Pull Request Workflow

Common on platforms like GitHub and GitLab.

• Each contributor forks the repository (creates their own copy).
• Work happens in branches on the fork.
• Changes are proposed back to the original repo via a pull request (PR).

Example:

• Fork the repo.
• Create a branch on your fork:

  git checkout -b feature/docs
  

• Push and open a PR to the main repo.

Benefits:
Safe for open source, allows code review before merging.

Choosing a Workflow

• Small teams/projects:
  Feature branch or trunk-based is often enough.
• Large teams/multiple releases:
  Gitflow or fork + PR workflows add structure.
• Open source:
  Fork + PR is standard.

Workflow Tips

• Name branches clearly:
  Use descriptive names like feature/login, bugfix/header, or hotfix/payment-crash.
• Keep branches focused:
  One feature or fix per branch.
• Merge often:
  Avoid long-lived branches to reduce conflicts.
• Protect important branches:
  Use branch protection rules on main or develop to prevent accidental changes.

Tip:
Pick a workflow that matches your team size, release process, and collaboration style.
Document your workflow so everyone knows how to

4.13 - Branch Protection

What is Branch Protection?

Branch protection is a set of rules that prevent unwanted changes to important branches in your repository—like main, master, or develop.
It’s a safety feature, usually managed on platforms like GitHub, GitLab, or Bitbucket, to keep your codebase stable and secure.

Why Use Branch Protection?

• Prevent mistakes:
  Stops accidental force-pushes, deletions, or direct commits to critical branches.
• Enforce code review:
  Require pull requests and approvals before merging changes.
• Maintain stability:
  Ensure only tested, reviewed code reaches production branches.
• Automate checks:
  Require passing tests, successful builds, or other checks before merging.

Common Branch Protection Rules

1. Require Pull Requests

• Disallow direct pushes to protected branches.
• All changes must go through a pull request (PR) for review.

2. Require Reviews and Approvals

• Specify that one or more team members must approve a PR before it can be merged.

3. Require Status Checks

• Only allow merging if automated tests, builds, or other checks pass.

4. Restrict Who Can Push

• Limit who can push, merge, or delete the branch (e.g., only admins or maintainers).

5. Prevent Force-Pushes and Deletion

• Block force-pushes (git push --force) to avoid rewriting history.
• Prevent accidental or malicious branch deletion.

How to Set Up Branch Protection

On GitHub

1. Go to your repository on GitHub.
2. Click Settings > Branches.
3. Add a branch protection rule for your chosen branch (e.g., main).
4. Select the rules you want (require PRs, reviews, status checks, etc.).
5. Save the rule.

On GitLab

1. Go to your repository.
2. Click Settings > Repository > Protected Branches.
3. Choose the branch and set permissions for who can push, merge, or delete.

On Bitbucket

1. Go to your repository.
2. Click Repository Settings > Branch permissions.
3. Add rules for your branches.

Example: GitHub Branch Protection

• Require pull request before merging.
• Require at least one approval.
• Require status checks to pass.
• Restrict who can push.
• Block force-pushes and deletion.

When to Protect a Branch

• Production branches:
  Always protect main, master, or any branch deployed to users.
• Release branches:
  Protect branches used for releases or hotfixes.
• Develop/integration branches:
  Protect if multiple people merge features into them.

Tips for Branch Protection

• Document your rules:
  Make sure everyone on your team knows which branches are protected and why.
• Review regularly:
  Update protection rules as your team or workflow changes.
• Combine with workflows:
  Use protection rules alongside branching workflows for maximum safety.

Tip:
Set it up early—don’t wait for a mistake to happen!

4.14 - Bonus Concepts

This section covers advanced and useful Git concepts related to branching, history, and project management.
Even if you’re new to Git, these tools and ideas will help you understand and recover your project in tricky situations!

Tags vs Branches

What is a Tag?

• A tag is a fixed pointer to a specific commit.
• Used to mark important points in history, like releases (v1.0.0, v2.1.3).
• Tags do not move—they always point to the same commit.

Create a tag:

git tag v1.0.0

List tags:

git tag

Push tags to remote:

git push origin v1.0.0

How is a Tag Different from a Branch?

Detached HEAD & Temporary Branches

What is Detached HEAD?

• HEAD is Git’s pointer to your current branch.
• Detached HEAD means HEAD points directly to a commit, not a branch.
• Happens when you checkout a specific commit:

  git checkout a1b2c3d
  

• You’re “not on a branch”—any new commits are not attached to a branch.

Why Use Detached HEAD?

• Experiment with changes without affecting any branch.
• Review or test old versions of your code.

How to Save Work from Detached HEAD

If you want to keep your work:

git switch -c temp-branch

• This creates a new branch from your current state, saving your changes.

Orphan Branches

What is an Orphan Branch?

• An orphan branch starts with no history—it’s a completely fresh branch.
• Useful for creating documentation, gh-pages, or starting a new project in the same repo.

Create an orphan branch:

git checkout --orphan docs

• Your working directory stays the same, but the branch has no commits.
• Add and commit files as usual.

Reflog: Recover Lost Commits and Branches

What is Reflog?

• Reflog records every change to HEAD (branch checkouts, commits, resets, etc.).
• Lets you recover lost commits, branches, or undo mistakes—even after deletion.

View reflog:

git reflog

• Shows a list of recent HEAD positions.

Recover a deleted branch:

1. Find the commit hash in git reflog.
2. Create a branch from it:

   git branch recovered-branch <commit-hash>
   

Bisecting: Find the Buggy Commit

What is Bisecting?

• git bisect helps you find which commit introduced a bug by binary search.
• You mark a “good” commit and a “bad” commit, and Git checks commits in between.

Start bisect:

git bisect start
git bisect bad                # Mark current commit as bad
git bisect good a1b2c3d       # Mark known good commit

• Git checks out a commit in the middle. Test it, then mark as good or bad.
• Repeat until you find the exact commit that introduced the bug.

Finish bisect:

git bisect reset

Visualization Tools

Command-Line Visualization

• Show commit history as a graph:

  git log --oneline --graph --all
  

• Show branches and merges visually.

GUI Tools

• Gitk:
  Run gitk for a graphical history viewer.
• SourceTree, GitKraken:
  Free tools for visualizing branches, merges, and history.
• VS Code GitLens:
  Powerful extension for viewing history and branch structure inside VS Code.

Tip:
These advanced tools and concepts help you manage, recover, and understand your project’s history.
Practice using them—they can save your

5 - Stashing Changes in Git

What is Stashing?

Stashing in Git lets you temporarily save changes in your working directory that you’re not ready to commit.
It’s like putting your unfinished work in a “drawer” so you can switch branches, pull updates, or do other tasks—then come back and finish later.

Why Use Stash?

• Switch branches safely:
  If you have uncommitted changes but need to switch to another branch, stash lets you save your work without committing.
• Keep your work-in-progress separate:
  Avoid cluttering your commit history with incomplete or experimental changes.
• Handle emergencies:
  If you need to quickly fix something elsewhere, stash your current work and come back to it later.

How Does Stash Work?

When you run git stash, Git saves your changes (tracked files, and optionally untracked files) in a special stack.
Your working directory is then clean, as if you just checked out the branch.

Basic Stash Commands

1. Stash Your Changes

git stash

• Saves your changes and resets your working directory to match the last commit.

2. List All Stashes

git stash list

• Shows all stashed changes, each with an identifier like stash@{0}.

3. Apply the Most Recent Stash

git stash apply

• Restores the latest stashed changes, but keeps them in the stash list.

4. Apply and Remove the Most Recent Stash

git stash pop

• Restores the latest stashed changes and removes them from the stash list.

5. Stash Untracked Files Too

git stash -u

• Includes untracked files (files not yet added with git add).

6. Drop (Delete) a Stash

git stash drop stash@{0}

• Removes a specific stash from the list.

7. Clear All Stashes

git stash clear

• Deletes all stashed changes.

Example Workflow

1. You’re working on a feature but need to switch branches:

   git stash
   git checkout main
   

2. Do your work on main, then return to your feature branch:

   git checkout feature
   git stash pop
   

3. Your changes are restored, and you can continue working.

What Gets Stashed?

• Tracked files:
  Changes to files already being tracked by Git.
• Untracked files:
  Only if you use git stash -u.
• Ignored files:
  Only if you use git stash -a.

When to Use Stash

• Before switching branches with uncommitted changes.
• When you want to pull or merge updates but aren’t ready to commit your work.
• To save experimental changes without committing them.

Caution

• Stashes are stored locally and are not shared with others.
• If you forget about stashed changes, they can pile up—use git stash list to check.
• Always apply or pop your stash on the correct branch to avoid confusion.

Tip:
Stashing is perfect for saving your work-in-progress without cluttering your commit history.
Use it whenever you need to quickly switch

6 - Working with Remotes

Up until now, we have been working on our local system. Git, however, is built to facilitate collaboration among multiple developers. To let other developers work on our code, we need to publish this code to a website.

Why Not Just Share Files?

You can upload your code anywhere—zip it up and put it on cloud storage like Google Drive or Dropbox, or send the files as an attachment to your friend.
But these methods won’t preserve your commit history, branches, or collaboration features (unless you include the hidden .git folder, which is risky and not recommended).

Why use a remote?

• Keeps your commit history safe and accessible.
• Lets you collaborate with others easily.
• Makes it simple to go back to older versions or branches.
• Saves your work on a server, not just your computer.

What is a Remote?

A remote in Git is a link (URL) to a repository hosted somewhere else—like GitHub, GitLab, Bitbucket, or your own server.
It lets your local repository sync (push and pull) with a remote repository, so you can share code and work with others.

Think of it as:
Your local project is your workspace. The remote is a shared folder on the internet where everyone can contribute.

Using a Git Hosting Service

It is much better to use a hosting service that is specially made for Git repositories.
Popular options include:

• GitHub (most popular, especially for open source)
• GitLab
• Bitbucket
• Self-hosted servers

These platforms offer tools for collaboration, code review, issue tracking, and more.

Connecting a Remote Repository

Step 1: Create a Remote Repository

Go to GitHub’s new repo page and create a repository.

• Give it a name.
• Description is optional.
• Leave all checkboxes under initialization unchecked (you’ll add files from your computer).

Step 2: Add the Remote to Your Local Project

In your terminal, inside your project folder, run:

git remote add origin https://github.com/yourusername/yourrepo.git

• origin is the short name for the remote. It’s a convention for the main remote, but you can use any name.
• Replace the URL with your actual repository link.

What does this do?

• Tells Git where to send your code when you push.
• Lets you pull updates from the remote.

Default Remote: origin

When you clone a repository, Git automatically sets up a remote called origin pointing to the original URL.

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

• This creates a local copy and sets origin as the default remote.

You can rename it if needed:

git remote rename origin upstream

Managing Remotes

• List all remotes and their URLs:

  git remote -v
  

• Add a new remote:

  git remote add <name> <url>
  

• Remove a remote:

  git remote remove <name>
  

• Change a remote’s URL:

  git remote set-url <name> <new-url>
  

• You can have multiple remotes (e.g., origin, upstream).

Remote Branches

Remote-tracking branches show the state of branches on the remote server.

• Examples:
  • origin/main → main branch on origin remote.
  • upstream/dev → dev branch on upstream remote.

Remote branches are read-only pointers. You can’t commit directly to them.

To work on a remote branch:

git checkout -b feature origin/feature

This creates a local branch called feature based on the remote branch.

Push & Pull Basics

• Push (upload changes):

  git push origin main
  

  Sends your local commits to the remote branch.

  git push -u origin feature
  

  Pushes and sets up tracking for the feature branch.

• Pull (download + merge):

  git pull origin main
  

  Fetches and merges changes from the remote.

  Equivalent to:

  git fetch origin main
  git merge origin/main
  

• Fetch (download only):

  git fetch origin
  

  Updates info about the remote without merging.

Tracking & Upstream Branches

When you push a branch for the first time:

git push -u origin feature

This sets up a tracking relationship.
Now you can just use:

git push
git pull

without specifying the branch.

Check tracking:

git branch -vv

Cloning vs Forking

• Clone:
  Copies a repository to your machine.
• Fork:
  (GitHub/GitLab feature) Copies a repository under your own account, then you clone it locally.

Typical open-source flow:

1. Fork the repo.
2. Clone your fork.
3. Add upstream:

   git remote add upstream https://github.com/original/repo.git
   

4. Sync with upstream:

   git fetch upstream
   git merge upstream/main
   

Deleting Remote Branches

Delete a branch from the remote:

git push origin --delete feature

The branch still exists locally unless you delete it:

git branch -d feature

Pull vs Fetch vs Rebase

• git pull:
  Fetch + merge remote changes into your branch.
• git fetch:
  Only download changes, don’t merge.
• git pull –rebase:
  Fetch remote changes, then reapply your local commits on top (creates a cleaner history).

Upstream & Multiple Remotes

Common in open-source:

• origin → your fork (where you push).
• upstream → original repo (where you fetch new changes).

Example commands:

git fetch upstream
git merge upstream/main

Remote Tracking Best Practices

• Always pull before push to avoid conflicts.
• Keep branches in sync with upstream:

  git fetch --all
  

• Delete remote branches after merging to keep things clean.
• Don’t force-push unless absolutely necessary:

  git push -f
  

Advanced Remote Operations

• Mirroring:

  git clone --mirror <url>
  

  Creates a bare clone for full backup.

• Shallow clone:

  git clone --depth=1 <url>
  

  Only downloads the latest commits (faster, less history).

• Multiple push URLs:

  git remote set-url --add origin <url2>
  

  Push to multiple remotes at once.

• Tracking remote renames:

  git remote rename origin backup
  

Authentication & Security

• HTTPS vs SSH remotes:

  • HTTPS: Needs username/password or a Personal Access Token (PAT).
  • SSH: Uses SSH keys (git@github.com:user/repo.git).

• PATs (Personal Access Tokens):

  • Required by GitHub/GitLab instead of passwords for HTTPS.
  • More secure and can be revoked anytime.

Summary Table

Tip:
Remotes are the backbone of collaboration in Git.
Master remote management to work smoothly with teams and

7 - Best Practices for Using Git

Following best practices helps you avoid mistakes, keep your project history clean, and collaborate smoothly with others.
Here are essential tips for working with Git, whether you’re solo or on a team!

1. Commit Often, But Meaningfully

• Make small, focused commits:
  Each commit should represent a single logical change.
• Avoid huge commits:
  Large commits are hard to review and revert.
• Commit early and often:
  This makes it easier to track changes and fix mistakes.

2. Write Clear Commit Messages

• Describe what and why:
  Explain what changed and why, not just “fix” or “update”.
• Use the imperative mood:
  Example: “Add login feature” instead of “Added login feature”.
• Reference issues or tickets:
  If using issue tracking, include references (e.g., Fixes #42).

3. Use Branches for Features and Fixes

• Create a new branch for each feature or bugfix:
  Keeps work isolated and makes merging easier.
• Name branches descriptively:
  Examples: feature/login, bugfix/header, hotfix/payment-crash.

4. Pull and Merge Regularly

• Sync with the remote often:
  Use git pull to get the latest changes before starting new work.
• Resolve conflicts early:
  The longer you wait, the harder conflicts become to fix.

5. Review Before You Commit

• Check your changes:
  Use git status and git diff to review what you’re about to commit.
• Don’t commit secrets or sensitive data:
  Double-check for passwords, API keys, or private info.

6. Clean Up Branches

• Delete branches after merging:
  Keeps your repository tidy and avoids confusion.
• Remove stale or unused branches regularly.

7. Use .gitignore

• Ignore files that shouldn’t be tracked:
  Add build artifacts, logs, and environment files to .gitignore.
• Keep .gitignore up to date as your project grows.

8. Protect Important Branches

• Enable branch protection rules:
  Prevent force-pushes, require pull requests, and enforce code reviews on critical branches like main or master.

9. Test Before You Push

• Run tests and build your code before pushing:
  Avoid breaking the shared codebase.

10. Document Your Workflow

• Write down your team’s Git workflow:
  Make sure everyone knows how to branch, merge, and review code.
• Update documentation as your process evolves.

Summary Table

Tip:
Good Git habits save time, prevent headaches, and make you a better collaborator.
Practice these tips and share them with your team!

8 -