βΆWhen should I merge vs rebase?
Merge creates a merge commit (preserves history, shows collaboration points). Rebase replays commits on top of another branch (linear history, cleaner logs). Rule: rebase for local branches before pushing (interactive rebase cleans up); merge for integrating shared branches. Trunk-based dev uses rebase for feature branches β main, no merge commits. Never rebase after pushing to shared branches β causes conflicts for teammates.
βΆHow do I recover deleted commits or lost work?
Git reflog saves every HEAD movement for 90 days. Run `git reflog` to see all commits, find the lost SHA, then `git reset --hard <sha>` or `git checkout <sha>` to recover. For deleted branches, `git fsck --lost-found` finds dangling commits. Pro tip: always tag releases and important commits so they survive garbage collection.
βΆWhat's the difference between monorepo and polyrepo?
Monorepo = one Git repo for many services (shared history, atomic commits across projects, easier refactoring; tools: Nx, Turborepo, Bazel). Polyrepo = separate repos per service (independent CI/CD, easier access control, slower refactoring across projects). Monorepo wins for startups/cohesive teams; polyrepo for large companies/security boundaries. Git handles monorepos fine; tooling (workspaces, CI filters) is the challenge.
βΆHow do I handle merge conflicts efficiently?
Conflicts arise when both branches modify the same line. Use `git status` to see conflicts (marked <<<<<<< ======= >>>>>>>). Tools help: `git mergetool` (opens UI), VS Code's Merge Editor (built-in, interactive), or `git diff --ours/--theirs` to see both versions. Always understand the conflict, not just pick 'ours'. Use `git merge --abort` to bail out. Prevention: rebase frequently, small PRs, communicate with teammates.
βΆShould I use trunk-based development or gitflow?
Trunk-based (main only, short-lived branches): high velocity, low merge pain, suitable for continuous deployment. Gitflow (main + develop + release/hotfix branches): clear separation, structured release cadence, bureaucratic. Pick trunk for startups/fast teams; gitflow for regulated/large orgs with formal releases. Most successful tech companies (Google, Meta) use trunk-based.
βΆHow do I manage large files and binary assets?
Git is bad at large files (clones are slow, disk bloat). Use Git LFS (Large File Storage) to store pointers instead of actual files. Enable with `git lfs install`, then `git lfs track '*.psd'` etc. For images/videos, consider cloud storage (S3, Cloudinary) + Git-tracked metadata files. Never commit binaries >100MB without LFS; clone times explode.
βΆCan AI help write commit messages?
Yes (2026). Tools like Conventional Commits linters (Husky + commitlint) enforce format automatically. GitHub Copilot can suggest messages; some IDEs (VS Code, JetBrains) integrate AI. Best practice: use `git commit` with a template (`commit.template` in .gitconfig) that prompts for type/scope/subject/body. Conventional format (`feat: add login`, `fix: typo in README`) is machine-readable for changelog generation + semantic versioning.