Git - 🧵
/1 - The perfect commit
➀ Add the right changes!
· Shouldn't cram everything into one commit.
· Only combine changes from the same topic in a single commit.
➁ Compose a good commit message!
· subject = concise summary of what happened
· body = more detailed explanation
/2 - Branching strategies
❏ A written convention - Agree on a branching workflow in your team
➀ Git allows you to create branches - but it doesn't tell you how to use them
➁ You need a written best practice of how work is ideally structured in your team - to avoid mistakes/collision
➂ It highly depends on your team/team size, on your project, and how you handle releases
➃ It helps to onboard new team members ("This is how we work here")
❏ Integrating changes & Structuring releases
➀ Mainline development ("Always be integrating")
- few branches
- relatively small commits
- high-quality testing & QA standards
➁ State, Release, and Feature branches
- Branches enhance structures & workflows
-- different types of branches...
-- ...fulfill different types of jobs
❏ Long-running & short-lived branches - Two types of branches
Long-running
- exist throughout the complete lifetime of the project
- often, they mirror "stages" in your dev life cycle
- common convention: no direct commits!
Short-lived
- for new features, bug fixes, refactoring, experiments...
- will be deleted after integrating(merge/rebase)
❏ GitHub flow
- very simple, very lean: only one long-running branch ("main") + feature branches
❏ GitFlow
- more structure, more rules
- long-running: "main" + "develop"
- short-lived: features, releases, hotfixes
The "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!
/3 - Pull requests
- Communicating about and reviewing code
- a pull request invites reviewers to provide feedback before merging
- Contributing code to other repositories (fork-> make changes -> open PR -> get merged)
/4 - Merge conflicts
How and when do conflicts occur?
When integrating commits from different sources
Merging changes in Git
- A flawless process, most of the time, git will figure things out on its own.
- When contradictory changes happen, git cannot know what's correct!
How to know when a conflict has occurred?
Don't worry Git will tell you.
How to undo a conflict and start over?
You can always undo it and start fresh!
git merge --abort
git rebase --abort
What do conflicts❌actually look like?
Just characters in the file!
How to solve a conflict?
Simply clean up the file!
/5 Merge vs Rebase
Merge commit is automatically created by git
Rebase - A straight line of commits - it rewrites the commit history
Warning ⚠️
- Do not use Rebase on commits that you've already pushed/shared in a remote repository. Instead, use it for cleaning up your local commit history before merging it into a shared team branch.
This thread is created from Git for Professionals Tutorial by @gittower
youtu.be/Uszj_k0DGsg
