The Story of Alice, Bob, and Git

The Software Team

Alice and Bob are developers in a growing software company.

Their project manager (PM) assigns them a mission: ”Build the

best application ever!”
The Software Team

Alice and Bob are developers in a growing software company.

Their project manager (PM) assigns them a mission: ”Build the

best application ever!”

But if they edit the same files directly, chaos happens:

▶ Lost changes
▶ Overwritten work
▶ No history
The Software Team

Alice and Bob are developers in a growing software company.

Their project manager (PM) assigns them a mission: ”Build the

best application ever!”

But if they edit the same files directly, chaos happens:

▶ Lost changes
▶ Overwritten work
▶ No history

They need a Version Control System (VCS). That’s when the tool
Git comes to the rescue!
Setting Up Git

Before working on code, Alice and Bob install and configure Git.
Setting Up Git

Before working on code, Alice and Bob install and configure Git.

Install Git:
▶ [Link]
Setting Up Git

Before working on code, Alice and Bob install and configure Git.

Install Git:
▶ [Link]

First-time setup:
git config --global [Link] "Alice Dev"
git config --global [Link] "alice@[Link]"
Setting Up Git

Before working on code, Alice and Bob install and configure Git.

Install Git:
▶ [Link]

First-time setup:
git config --global [Link] "Alice Dev"
git config --global [Link] "alice@[Link]"

These settings identify the developer in every commit.

git config --list
The Central Repository

In their company, projects live in repositories hosted on platforms

like GitHub, GitLab, or Bitbucket.
The Central Repository

In their company, projects live in repositories hosted on platforms

like GitHub, GitLab, or Bitbucket.
The repo has two parts:
▶ Remote: shared server (e.g., GitHub)
▶ Local: developer’s machine
The Central Repository

In their company, projects live in repositories hosted on platforms

like GitHub, GitLab, or Bitbucket.
The repo has two parts:
▶ Remote: shared server (e.g., GitHub)
▶ Local: developer’s machine
The PM creates a remote repo. Alice and Bob clone it:
git clone [Link]
Branching for Features

To avoid conflicts, each developer works on a separate branch.

Alice:
git checkout -b feature-login
Branching for Features

To avoid conflicts, each developer works on a separate branch.

Alice:
git checkout -b feature-login

Bob:
git checkout -b feature-dashboard
Branching for Features

To avoid conflicts, each developer works on a separate branch.

Alice:
git checkout -b feature-login

Bob:
git checkout -b feature-dashboard

Now they can develop independently while keeping the main

branch stable.
Saving Work with Commits

Alice stages her work:

git add [Link] [Link]

Then records a snapshot:

git commit -m "Add login page"

Bob does the same for his dashboard. Now their progress is safely
stored in Git history.
Inspecting the Project History

Git keeps track of everything.

Check current status:
git status

View commit history:

git log

See what changed:

git diff
Sharing Work with the Team

Alice pushes her branch:

git push origin feature-login

Bob pushes his:

git push origin feature-dashboard

Now their code is available on the remote repo for the team to
review.
Code Review with Pull Requests

After pushing, Alice wants her feature in main. She opens a Pull
Request (PR) on GitHub.
A PR allows:
▶ Review: teammates suggest changes
▶ Automated checks: CI tests run
▶ Protection: no direct changes to main
Merging a Feature Branch

When the PR is approved:

git checkout main
git pull origin main
git merge feature-login
git push origin main

If conflicts occur, Git asks the developer to resolve them manually.

Resolving Merge Conflicts

If Alice’s branch conflicts with updates in main:

git checkout feature-login
git pull origin main
# fix conflicts in files
git add conflicted_file.js
git commit -m "Resolve conflicts"
git push origin feature-login

Now the PR can be merged safely.

Undoing Mistakes

Unstage a file:
git reset HEAD [Link]

Discard changes:
git checkout -- [Link]

Undo a commit:
git revert <commit-hash>
Staying Updated with the Team

Quick sync:
git pull origin main

Or step-by-step:
git fetch origin
git merge origin/main
Working with Remotes

List remotes:
git remote -v

Add a remote:
git remote add origin [Link]

Push with upstream tracking:

git push -u origin feature-login
Keeping a Clean History: Rebase

Alice wants her branch on top of the latest main:

git checkout feature-login
git fetch origin
git rebase origin/main

If conflicts appear:
git add resolved_file.js
git rebase --continue
Marking Releases with Tags

To mark version 1.0:

git tag v1.0
git push origin v1.0
Continuous Integration and Deployment

Every merge into main triggers:

▶ Automated tests
▶ Deployment to staging or production
This ensures a stable and reliable release process.
Best Practices in a Dev Team

▶ Commit often, keep commits focused

▶ Write clear commit messages
▶ Keep main always stable
▶ Pull frequently
▶ Use branches for every task
▶ Never commit secrets!
The Daily Workflow

git pull origin main

git checkout -b feature-newthing
git add .
git commit -m "Implement new thing"
git push origin feature-newthing

Then open a Pull Request, get feedback, and merge!

The Story in a Nutshell

Alice and Bob, developers in a software company, set up Git with

git config. They clone the repo with git clone, create
branches using git checkout -b, make changes, stage them with
git add, and commit snapshots with git commit. They push
work using git push, open Pull Requests for review, and merge
into main with git merge. If conflicts occur, they resolve them.
They keep updated with git pull or git fetch + merge, undo
mistakes with git reset, git checkout, or git revert, rebase
with git rebase, and mark releases with git tag. By following
best practices, their team delivers stable software efficiently.
Example: Handling Push Conflicts
Scenario: You cloned a repository, made local changes, but
another developer modified the same branch and pushed first.
Example: Handling Push Conflicts
Scenario: You cloned a repository, made local changes, but
another developer modified the same branch and pushed first.
Possible Git output when you try to push:
! [rejected] main -> main (fetch first)
error: failed to push some refs to '[Link]
git'
hint: Updates were rejected because the remote contains work that
you do
not have locally. You may want to first integrate the remote
changes
(e.g., 'git pull ...') before pushing again.
Example: Handling Push Conflicts
Scenario: You cloned a repository, made local changes, but
another developer modified the same branch and pushed first.
Possible Git output when you try to push:
! [rejected] main -> main (fetch first)
error: failed to push some refs to '[Link]
git'
hint: Updates were rejected because the remote contains work that
you do
not have locally. You may want to first integrate the remote
changes
(e.g., 'git pull ...') before pushing again.

Solutions:
1. Merge approach (safe):
git pull origin main # fetch + merge remote changes
# resolve conflicts if any
git push origin main
Example: Handling Push Conflicts
Scenario: You cloned a repository, made local changes, but
another developer modified the same branch and pushed first.
Possible Git output when you try to push:
! [rejected] main -> main (fetch first)
error: failed to push some refs to '[Link]
git'
hint: Updates were rejected because the remote contains work that
you do
not have locally. You may want to first integrate the remote
changes
(e.g., 'git pull ...') before pushing again.

Solutions:
1. Merge approach (safe):
git pull origin main # fetch + merge remote changes
# resolve conflicts if any
git push origin main

2. Rebase approach (clean history):

git fetch origin
git rebase origin/main # replay your commits on top of
latest main
# resolve conflicts if any
git push origin main
Example: Handling Push Conflicts
Scenario: You cloned a repository, made local changes, but
another developer modified the same branch and pushed first.
Possible Git output when you try to push:
! [rejected] main -> main (fetch first)
error: failed to push some refs to '[Link]
git'
hint: Updates were rejected because the remote contains work that
you do
not have locally. You may want to first integrate the remote
changes
(e.g., 'git pull ...') before pushing again.

Solutions:
1. Merge approach (safe):
git pull origin main # fetch + merge remote changes
# resolve conflicts if any
git push origin main

2. Rebase approach (clean history):

git fetch origin
git rebase origin/main # replay your commits on top of
latest main
# resolve conflicts if any
git push origin main

3. Force push ( dangerous):

git push origin main --force

Use only if you are sure you want to overwrite remote history.
Git Architecture
▶ Working Directory: Your
local project files that you
edit.
▶ Staging Area (Index):
Prepares selected changes
for commit.
▶ Local Repository: Stores
commit history, branches,
and tags.
▶ Remote Repository: A
shared version of the repo
(e.g., GitHub).
(Architecture diagram of Git) ▶ Data flows through
commands: git add → git
commit → git push, and
updates come back via git
pull.
Inside Git: How It Works
Git is not just a simple file tracker — it’s a powerful system built
on a few core concepts:
▶ Snapshots, not differences Instead of storing line-by-line
changes (like older VCS), Git saves a snapshot of the entire
project state each time you commit.
Inside Git: How It Works
Git is not just a simple file tracker — it’s a powerful system built
on a few core concepts:
▶ Snapshots, not differences Instead of storing line-by-line
changes (like older VCS), Git saves a snapshot of the entire
project state each time you commit.
▶ Three main areas
▶ Working Directory – where you edit files
▶ Staging Area (Index) – a holding zone for changes before
commit
▶ Repository (.git) – permanent history with all commits
Inside Git: How It Works
Git is not just a simple file tracker — it’s a powerful system built
on a few core concepts:
▶ Snapshots, not differences Instead of storing line-by-line
changes (like older VCS), Git saves a snapshot of the entire
project state each time you commit.
▶ Three main areas
▶ Working Directory – where you edit files
▶ Staging Area (Index) – a holding zone for changes before
commit
▶ Repository (.git) – permanent history with all commits
▶ Content-addressable storage Every file, commit, and tree is
identified by a unique SHA-1/SHA-256 hash. This ensures
integrity and makes Git very reliable.
Inside Git: How It Works
Git is not just a simple file tracker — it’s a powerful system built
on a few core concepts:
▶ Snapshots, not differences Instead of storing line-by-line
changes (like older VCS), Git saves a snapshot of the entire
project state each time you commit.
▶ Three main areas
▶ Working Directory – where you edit files
▶ Staging Area (Index) – a holding zone for changes before
commit
▶ Repository (.git) – permanent history with all commits
▶ Content-addressable storage Every file, commit, and tree is
identified by a unique SHA-1/SHA-256 hash. This ensures
integrity and makes Git very reliable.
▶ Branches as pointers A branch is just a lightweight pointer
to a commit. Creating branches is cheap and fast.
Inside Git: How It Works
Git is not just a simple file tracker — it’s a powerful system built
on a few core concepts:
▶ Snapshots, not differences Instead of storing line-by-line
changes (like older VCS), Git saves a snapshot of the entire
project state each time you commit.
▶ Three main areas
▶ Working Directory – where you edit files
▶ Staging Area (Index) – a holding zone for changes before
commit
▶ Repository (.git) – permanent history with all commits
▶ Content-addressable storage Every file, commit, and tree is
identified by a unique SHA-1/SHA-256 hash. This ensures
integrity and makes Git very reliable.
▶ Branches as pointers A branch is just a lightweight pointer
to a commit. Creating branches is cheap and fast.
▶ Commits form a graph (DAG) Git commits are nodes in a
Directed Acyclic Graph, linking project history. This allows
branching and merging efficiently.
Git Command Reference
▶ git config --global [Link] "Your Name" git
config --global [Link] "you@[Link]"
▶ Set your identity in Git (name and email).
▶ The --global flag applies to all repositories on your system.
Git Command Reference
▶ git config --global [Link] "Your Name" git
config --global [Link] "you@[Link]"
▶ Set your identity in Git (name and email).
▶ The --global flag applies to all repositories on your system.
▶ git clone <url>
▶ Makes a full copy of a remote repository onto your local
machine.
▶ Includes the project history, branches, and files.
Git Command Reference
▶ git config --global [Link] "Your Name" git
config --global [Link] "you@[Link]"
▶ Set your identity in Git (name and email).
▶ The --global flag applies to all repositories on your system.
▶ git clone <url>
▶ Makes a full copy of a remote repository onto your local
machine.
▶ Includes the project history, branches, and files.
▶ git status
▶ Shows the current state of your working directory.
▶ Lets you see which files are modified, staged, or untracked.
Git Command Reference
▶ git config --global [Link] "Your Name" git
config --global [Link] "you@[Link]"
▶ Set your identity in Git (name and email).
▶ The --global flag applies to all repositories on your system.
▶ git clone <url>
▶ Makes a full copy of a remote repository onto your local
machine.
▶ Includes the project history, branches, and files.
▶ git status
▶ Shows the current state of your working directory.
▶ Lets you see which files are modified, staged, or untracked.
▶ git add <file>
▶ Moves changes from the working directory to the staging area.
▶ Example: git add . stages all modified files.
Git Command Reference
▶ git config --global [Link] "Your Name" git
config --global [Link] "you@[Link]"
▶ Set your identity in Git (name and email).
▶ The --global flag applies to all repositories on your system.
▶ git clone <url>
▶ Makes a full copy of a remote repository onto your local
machine.
▶ Includes the project history, branches, and files.
▶ git status
▶ Shows the current state of your working directory.
▶ Lets you see which files are modified, staged, or untracked.
▶ git add <file>
▶ Moves changes from the working directory to the staging area.
▶ Example: git add . stages all modified files.
▶ git commit -m "message"
▶ Records a permanent snapshot of staged changes in the
repository history.
▶ Always use a clear message to describe what you changed.
Git Command Reference
▶ git config --global [Link] "Your Name" git
config --global [Link] "you@[Link]"
▶ Set your identity in Git (name and email).
▶ The --global flag applies to all repositories on your system.
▶ git clone <url>
▶ Makes a full copy of a remote repository onto your local
machine.
▶ Includes the project history, branches, and files.
▶ git status
▶ Shows the current state of your working directory.
▶ Lets you see which files are modified, staged, or untracked.
▶ git add <file>
▶ Moves changes from the working directory to the staging area.
▶ Example: git add . stages all modified files.
▶ git commit -m "message"
▶ Records a permanent snapshot of staged changes in the
repository history.
▶ Always use a clear message to describe what you changed.
▶ git log
▶ Displays the list of past commits (history).
▶ Useful for tracking who made changes, when, and why.
Git Command Reference
▶ git checkout -b <branch>
▶ Creates a new branch and switches to it immediately.
▶ Helps isolate work (features/bugfixes) without affecting main.
Git Command Reference
▶ git checkout -b <branch>
▶ Creates a new branch and switches to it immediately.
▶ Helps isolate work (features/bugfixes) without affecting main.
▶ git push origin <branch>
▶ Uploads your local branch and commits to the remote server.
▶ Makes your work visible to collaborators.
Git Command Reference
▶ git checkout -b <branch>
▶ Creates a new branch and switches to it immediately.
▶ Helps isolate work (features/bugfixes) without affecting main.
▶ git push origin <branch>
▶ Uploads your local branch and commits to the remote server.
▶ Makes your work visible to collaborators.
▶ git pull origin main
▶ Fetches the latest changes from the remote main branch and
merges them into your current branch.
▶ Prevents working on outdated code.
Git Command Reference
▶ git checkout -b <branch>
▶ Creates a new branch and switches to it immediately.
▶ Helps isolate work (features/bugfixes) without affecting main.
▶ git push origin <branch>
▶ Uploads your local branch and commits to the remote server.
▶ Makes your work visible to collaborators.
▶ git pull origin main
▶ Fetches the latest changes from the remote main branch and
merges them into your current branch.
▶ Prevents working on outdated code.
▶ git merge <branch>
▶ Combines changes from another branch into your current one.
▶ May cause conflicts if the same lines of code were edited
differently.
Git Command Reference
▶ git checkout -b <branch>
▶ Creates a new branch and switches to it immediately.
▶ Helps isolate work (features/bugfixes) without affecting main.
▶ git push origin <branch>
▶ Uploads your local branch and commits to the remote server.
▶ Makes your work visible to collaborators.
▶ git pull origin main
▶ Fetches the latest changes from the remote main branch and
merges them into your current branch.
▶ Prevents working on outdated code.
▶ git merge <branch>
▶ Combines changes from another branch into your current one.
▶ May cause conflicts if the same lines of code were edited
differently.
▶ git rebase origin/main
▶ Replays your commits on top of the latest main branch,
creating a linear history.
▶ Useful for keeping the commit history clean.
Git Command Reference
▶ git checkout -b <branch>
▶ Creates a new branch and switches to it immediately.
▶ Helps isolate work (features/bugfixes) without affecting main.
▶ git push origin <branch>
▶ Uploads your local branch and commits to the remote server.
▶ Makes your work visible to collaborators.
▶ git pull origin main
▶ Fetches the latest changes from the remote main branch and
merges them into your current branch.
▶ Prevents working on outdated code.
▶ git merge <branch>
▶ Combines changes from another branch into your current one.
▶ May cause conflicts if the same lines of code were edited
differently.
▶ git rebase origin/main
▶ Replays your commits on top of the latest main branch,
creating a linear history.
▶ Useful for keeping the commit history clean.
▶ git tag v1.0
▶ Labels a specific commit with a name (e.g., marking a release
version).
▶ Makes it easy to reference stable milestones.
Git Command Reference
▶ git checkout -b <branch>
▶ Creates a new branch and switches to it immediately.
▶ Helps isolate work (features/bugfixes) without affecting main.
▶ git push origin <branch>
▶ Uploads your local branch and commits to the remote server.
▶ Makes your work visible to collaborators.
▶ git pull origin main
▶ Fetches the latest changes from the remote main branch and
merges them into your current branch.
▶ Prevents working on outdated code.
▶ git merge <branch>
▶ Combines changes from another branch into your current one.
▶ May cause conflicts if the same lines of code were edited
differently.
▶ git rebase origin/main
▶ Replays your commits on top of the latest main branch,
creating a linear history.
▶ Useful for keeping the commit history clean.
▶ git tag v1.0
▶ Labels a specific commit with a name (e.g., marking a release
version).
▶ Makes it easy to reference stable milestones.
▶ git revert <commit-hash>
▶ Creates a new commit that undoes the changes from a
previous commit.
▶ Safer than git reset because history remains intact.
Git Branch Commands Summary
▶ Create a branch:
git branch <branch-name>

▶ Switch to a branch:
git checkout <branch-name>

▶ Create and switch to a new branch:

git checkout -b <branch-name>

▶ List branches:
git branch # local branches
git branch -r # remote branches
git branch -a # all branches

▶ Merge a branch into the current branch:

git merge <branch-name>

▶ Delete a branch:
git branch -d <branch-name> # delete locally
git push origin --delete <branch> # delete remote branch
Using Git in IDEs

Most modern IDEs (e.g., VS Code, IntelliJ, PyCharm, Eclipse)

come with Git integration:
▶ Clone Repositories – Directly from GitHub/GitLab within
the IDE.
▶ Commit & Push – Stage files, write commit messages, and
push without typing commands.
▶ Branch Management – Create, switch, and merge branches
via a sidebar or menu.
▶ Conflict Resolution – Graphical diff/merge editors make
resolving conflicts easier.
▶ History View – Visualize commits, branches, and tags with a
clear timeline.
Using Git in IDEs

Most modern IDEs (e.g., VS Code, IntelliJ, PyCharm, Eclipse)

come with Git integration:
▶ Clone Repositories – Directly from GitHub/GitLab within
the IDE.
▶ Commit & Push – Stage files, write commit messages, and
push without typing commands.
▶ Branch Management – Create, switch, and merge branches
via a sidebar or menu.
▶ Conflict Resolution – Graphical diff/merge editors make
resolving conflicts easier.
▶ History View – Visualize commits, branches, and tags with a
clear timeline.
Advantage: IDEs simplify Git operations for beginners and increase
productivity for experienced developers.
Using Git with UI-Based Tools

If you prefer not to use the command line, dedicated Git GUIs are
available:
▶ GitHub Desktop – Easy sync with GitHub, beginner-friendly.
▶ Sourcetree – Powerful free Git GUI by Atlassian (works with
GitHub, GitLab, Bitbucket).
▶ GitKraken – Visual commit graph, drag-and-drop merges,
cross-platform.
▶ Tower, SmartGit, TortoiseGit – Other popular GUI tools for
different OS.
Using Git with UI-Based Tools

If you prefer not to use the command line, dedicated Git GUIs are
available:
▶ GitHub Desktop – Easy sync with GitHub, beginner-friendly.
▶ Sourcetree – Powerful free Git GUI by Atlassian (works with
GitHub, GitLab, Bitbucket).
▶ GitKraken – Visual commit graph, drag-and-drop merges,
cross-platform.
▶ Tower, SmartGit, TortoiseGit – Other popular GUI tools for
different OS.
Benefits:
▶ Intuitive drag-and-drop for staging and branching.
▶ Visual commit history with graphs.
▶ Easier learning curve for teams new to Git.
Conclusion

Alice and Bob mastered:

▶ Git setup and configuration
▶ Branching and committing
▶ Pushing and Pull Requests
▶ Merging and conflict resolution
▶ Rebasing, tagging, and best practices
Conclusion

Alice and Bob mastered:

▶ Git setup and configuration
▶ Branching and committing
▶ Pushing and Pull Requests
▶ Merging and conflict resolution
▶ Rebasing, tagging, and best practices
You are now ready to Git things done!