Very important subject! Thank you for the article!
Some additional advices from my experience:
use some git methodic teamwide (e.g. git flow) — messy history is often a result of messy dev flow
ensure everyone in the team is comfortable with git (better git-cli)
git pull --ff-only — to pull remote branches. By default pull will use merge strategy if there's difference between remote and local branches
if previous cmd fails — run git pull --rebase to use rebase strategy. You can skip "--ff-only" step, but I prefer run it first to acknowledge there is a difference
GitHub (probably others too) has settings to protect branches from direct pushing (under "Branch protection rules") and limit PRs merging strategies: merge | squash | rebase — I usually prefer keeping only squash option
Github (probably others too) has a setting to enforce linear history in branches (under the same "Branch protection rules") — but that's an ultimate weapon I've not used yet 🙂
Total agree with "ensure everyone in the team is comfortable with git", we all already faced the situation of "fear" to brake something.. when i started to use git i was fear of "rebase" and "conflicts".. and we should give more confidence to each developer of the team. Nice point !
Very important subject! Thank you for the article!
Some additional advices from my experience:
use some git methodic teamwide (e.g. git flow) — messy history is often a result of messy dev flow
ensure everyone in the team is comfortable with git (better git-cli)
git pull --ff-only— to pull remote branches. By defaultpullwill use merge strategy if there's difference between remote and local branchesif previous cmd fails — run
git pull --rebaseto use rebase strategy. You can skip "--ff-only" step, but I prefer run it first to acknowledge there is a differenceGitHub (probably others too) has settings to protect branches from direct pushing (under "Branch protection rules") and limit PRs merging strategies: merge | squash | rebase — I usually prefer keeping only
squashoptionGithub (probably others too) has a setting to enforce linear history in branches (under the same "Branch protection rules") — but that's an ultimate weapon I've not used yet 🙂
Awesome man . Thanks to share this with use.
I have already used the gitflow of your link. I use this one, from Atlassian atlassian.com/fr/git/tutorials/com... checked quickly.
Total agree with "ensure everyone in the team is comfortable with git", we all already faced the situation of "fear" to brake something.. when i started to use git i was fear of "rebase" and "conflicts".. and we should give more confidence to each developer of the team. Nice point !
Your post has inspired me to experiment with git log view:
Pretty Git Log built w/ React & Ink
Kostia Palchyk ・ Aug 10 ・ 1 min read
🙂
Nice package :)