Notes: July 20, 2025
Git & Github: A quick but comprehensive quide.
This entry is part of the 🔒Notebook — an exclusive, subscriber-only section of SoftwareResilience.com, offering a glimpse into my working notes, raw observations, and the formative thinking that underpins my published work. If you find these insights useful, I would be grateful if you considered subscribing or recommending the Notebook to a colleague.
🍬 All content here is crafted by hand — no automation, no AI-generated filler. 🍬
…and now back to our notes.
#1
Git for Pros: Tools & Concepts for Mastering Version Control with Git
Commits
git add filename
git diff filename
git add -p filename (patch level / select chunk of change to commit)
Commit message
simple title then
empty line
then body of the commit
git log
Branches
Written convention
Always be integrating
few branches
relatively small commits
high-quality testing & QA standards
State, release and feature branches
different types of branches...
...fullfill different types of jobs
Long-running branches
exist through the complete lifetime of the project
often, they mirror "stages" in your dev life cycle
Short-lived branches
for new feature, bug fixes, refactorings, experiments...
will be deleted after integration (merge/rebase)
GitHub Flow
very simple, very lean: only one long-running branch ("main") + feature branches
GitFlow
more structure, more rules
long-running: "mail" + "develop"
short-lived: features, releases, hotfixes
How to choose "Best" Branching Model?
consider your project, release cycle, and team
take inspiration from existing models (like "GitFlow" or "GitHub Flow")
... and create your own model!
Pull requests
Communicating About and Reviewing Code
Without a Pull Request, you would jump right to merging your code...
A Pull Request invites reviewers to provide feedback before merging
Contribute code to other repositories (you may not have push access)
creating a "Fork" of the original repository, where you can make changes...
... and sugest those changes to be included via a PR (i.e. in OSS projects).
fork project > git clone > git branch test > git checkout test > open pref editor > make changes > git status > git add ... > git commit -m "" > git push --set-upstream origin test > go to browser github and create a pull request
Merge Conflicts
How and when they occur
git merge, git rebase, git pull, git cherry-pick, git stash apply
Merging changes in Git
most of the time, GIt will figure things out on its own!
when contradictory changes happen, git may not know what's correct! (i.e. file is changed in one change and deleted in another)
we can undo a conflict and start over (not always have to resolve it)
git merge --abort
git rebase --abort
when we want to handle the conflict, we see the conflicting part in the file
in such cases we just clean-up the file communicating with the other team member
after clean-up we do git mergetool and we have to select between modified or deleted file or abort
changed file is added and ready to be committed!
Merge vs Rebase
Merge
most simple scenario: original commit triggered to branches A and B, B has changes, A remained as is so the changes of B are merged to A (fast-forward merge)
merge-commit is created automatically from git to synthesize 2 different branches with changes
Rebase
git rebase branch-B (the one we want to integrate as with merge)
rebase re-writes commit history eliminatiting branching for history
WE NEED TO BE CAREFUL when we rebase branches in public commits as they may eliminate the evidence of the work of another developer
DO NOT rebase on commits that you've already pushed/shared on a remote repository!
You should use them to clean up your local commit history before mergin remotely.
Notes taken from this video 👇
#2
Advanced Git - Interactive Rebase, Cherry-Picking, Reflog, Submodules and more
Interactive rebase
a tool for optimizing and cleaning up your commit history
change a commit's message
delete commits
reorder commits
combine multiple commits into one
edit / split an existing commit into multiple new ones
DO NOT use interactive rebase on commits that you've already pushed/shared on a remote repository!
instead, use it for cleaning up your local commit history before merging it into a shared team branch
git rebase -i HEAD~3
"reword" the line you want to edit the commit message
then a new window opens that allows us to change the commit message
git rebase -i HEAD~4
squash the line that you want to combine with the previous commit
first line creates the commit message for the combined commit
Cherry picking
Moving a commit to a different branch
git checkout feature/newsletter > git cherry-pick commit_number
then git checkout master > git reset
hard HEAD~1 to clean up the master branch
Delete unwanted commits
git reset --hard commit_id_I_want_as_last
Delete branch
The Reflog
Recovering deleted commits
git reflog > git branch happy-ending number of deleted commit from reflog
Restoring branches
git reflog > git branch feature/login commit number of the deleted branch
Submodules
Mixing external code with your own files
Updating the external code is, again, a manual process
mkdir lib > cd lib > git submodule add URL to library > git commit -m ""
git clone project with submodules
git submodule update --init (to add the actual submodules folders / populate)
or git clone --recurse-submodules and project clone URL
Search and Find
Filtering your commit history: git log
by keyword --grep="<keyword>"
by date --before / --after
by message --grep
by author --author
by file -- <filename>
by branch <branch-A>
Notes taken from this video 👇