Best practices · Stacks and tools
Git Best Practices for Developers
Opens with creditsA practical guide to using Git well on a team, checked against the official Git documentation and the Pro Git book. It covers commits and messages, branches and pull requests, rebase vs merge, safe history rewriting, keeping secrets out, .gitignore, commit signing and how to recover from mistakes.
Written by Tauseef Fayyaz7 chapters, 26 practicesAbout 15 min24 quiz questionsReviewed 12 October 2026What you will learn
7 chapters · about 15 min
1Commits and commit messagesHow big a commit should be and how to write a message that still makes sense a year from now.4 practices · 3 min
2Branches and pull requestsA branching flow that keeps the main branch releasable and pull requests easy to review.4 practices · 2 min
- Rebase vs mergeWhen to rebase, when to merge, and the one rule that keeps rebasing safe.4 practices · 2 minOpens with credits
- Rewriting history safelyHow to force push without losing anyone's work, and how to undo commits that are already shared.3 practices · 2 minOpens with credits
- Secrets and .gitignoreKeep credentials and generated files out of the repository from day one, and know exactly what to do if a secret leaks.4 practices · 2 minOpens with credits
- Signing commits and tagsProve that commits and releases really come from you, using the SSH key you probably already have.3 practices · 2 minOpens with credits
- Recovering from mistakesAlmost nothing you commit is ever really lost. These are the commands that get you out of the usual messes.4 practices · 2 minOpens with credits
About this guide
These Git best practices are for developers who use Git every day and want a history that teammates can read, review and trust. They are checked against the official documentation on git-scm.com for Git 2.56, the Pro Git book, and GitHub's own guides on signing and removing sensitive data.
Good Git habits pay off in small ways all the time. A clear commit message saves a reviewer ten minutes. A small pull request gets merged the same day. Pushing with --force-with-lease instead of --force means you never wipe out a teammate's work. Knowing about the reflog turns a scary mistake into a two-minute fix.
The first two chapters, on commits and on branches and pull requests, cover what reviewers and future maintainers notice most, so start there. Later chapters cover rebase vs merge, rewriting history safely, keeping secrets and junk out of the repository, signing your commits, and recovering lost work.
If you are a student or a fresh graduate, your GitHub history is often the first code a hiring team looks at. Clean commits and readable pull requests are an easy way to show you can work on a real team.
Common questions
What is the difference between git rebase and git merge?
Merge joins two branches with a merge commit and keeps both histories as they were. Rebase replays your commits on top of another branch, creating new commits and a straight history. Rebase your own unshared work to stay current, and never rebase commits others may have based work on.
Is git push --force-with-lease safe?
It is much safer than --force, because it refuses to overwrite the remote branch if someone else pushed since you last fetched. Background fetches by editors can weaken that check, so add --force-if-includes too. Never force push to main or other shared branches.
How do I recover a commit I lost after git reset --hard?
Run git reflog to list where HEAD has been, find the commit from before the reset, and create a branch on it with git branch rescue <hash>. Reflog entries are kept for 90 days by default. Uncommitted changes that were discarded are not in the reflog and usually cannot be recovered.
What should I do if I committed an API key to Git?
Revoke or rotate the key first, since anything pushed should be treated as copied. Then, if needed, remove it from history with git filter-repo --sensitive-data-removal, force push, and ask collaborators to re-clone. Forks and existing clones keep the old commits, which is why rotation matters most.
How long should a git commit message be?
The Git documentation recommends a summary line of no more than 50 characters, then a blank line, then a body explaining the change in more detail. Many teams wrap the body at about 72 characters. Focus the body on why the change was made.
Should I sign my Git commits?
Yes, it is cheap and proves a commit came from you. The easiest way is SSH signing: set gpg.format to ssh, point user.signingkey at your public key, enable commit.gpgsign, and add the key to your Git host as a signing key.
Sources (8)
Checked against these, last on 12 October 2026.
- git-commit Documentation, Gitgit-scm.com/docs/git-commit
- git-push Documentation, Gitgit-scm.com/docs/git-push
- git-reflog Documentation, Gitgit-scm.com/docs/git-reflog
- gitignore Documentation, Gitgit-scm.com/docs/gitignore
- Git Branching: Rebasing, Pro Gitgit-scm.com/book/en/v2/Git-Branching-Rebasing
- git-config Documentation, Gitgit-scm.com/docs/git-config
- Removing sensitive data from a repository, GitHub Docsdocs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository
- Telling Git about your signing key, GitHub Docsdocs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See all- Linux, terminal and Git cheat sheetShell, Git, SSH and your dev setup.
- Git cheat sheetHow Git stores your work, the everyday commands, branching, undoing mistakes, remotes, reviews and team workflows.
- Linux command line cheat sheetThe Linux shell from first commands to safe Bash scripts: files, text tools, permissions, processes, services, SSH and more.
Best practices
See all- Code Review Best PracticesCode review best practices for reviewers and authors: the approval standard, what to look for, review speed, writing kind and useful comments, handling disagreement and small changes.
- Technical Writing Best Practices for EngineersTechnical writing best practices for developers: write for your audience, clear sentences, scannable structure, design docs, READMEs and docs, PR descriptions, async updates and blog posts.
- CI/CD Best PracticesBuild pipelines that are fast, trustworthy and safe to deploy from: trunk-based flow, fast tests, locked-down workflows, signed artifacts, canaries and DORA metrics.
Checklists
See allProject structures
See all- VS Code extension project structureA TypeScript extension for Visual Studio Code, built from the official Yeoman generator with esbuild bundling. The example, TODO Lens, finds TODO comments and shows them in a tree view, with commands, settings and editor decorations. The tree grows from the generator's Hello World into commands, providers and editor-free core logic, then tests on three operating systems, publishing to the Marketplace and Open VSX, and a webview with a strict security policy. For students who use VS Code every day and want to build a tool other developers install.
- Turborepo monorepo project structureOne Git repository holding several apps and the packages they share, wired together by pnpm workspaces and run by Turborepo.
apps/holds things you deploy (two Next.js apps from the starter, later an API),packages/holds shared code and config (UI components, ESLint and TypeScript configs, validation schemas, the database client). Turborepo runs each task in dependency order and caches the results, so you never rebuild what did not change. - Chrome extension project structureA Manifest V3 Chrome extension that saves highlights from any page into a side panel, built with WXT, React and TypeScript. WXT reads your
entrypointsfolder and writes the manifest for you, so the layout is one folder per thing Chrome loads (service worker, content script, popup, side panel, options) with shared code inutils. For students who have loaded an unpacked extension once and want to ship a real one to the Chrome Web Store.
Career questions
See all- How do I learn Git and GitHub properly instead of just copying commands?Learn the model first: commits are snapshots, branches are pointers, and remotes are copies. Then use Git daily on your own projects, practise a team workflow with branches and pull requests, and break things on purpose, such as merge conflicts, so you learn to recover calmly.
- Which AI tools do employers expect junior developers to know in 2026?Employers rarely require a specific brand. They expect you to use an AI coding assistant well (in the editor and in the terminal), to review and test what it produces, to call an LLM API in a small feature, and to explain when you would not use AI. Pick one assistant, learn it properly, and show judgement in your projects.
- How do I build a developer portfolio as a beginner with nothing to show?Start with two or three small but complete projects that solve a real problem, each with a clear README, screenshots and a live link or easy run steps. Put them on a simple one-page site or a tidy GitHub profile. Depth and finish matter far more than the number of projects or a fancy design.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com