Question 1

When should I merge vs rebase?

Accepted Answer

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.

Question 2

How do I recover deleted commits or lost work?

Accepted Answer

Git reflog saves every HEAD movement for 90 days. Run `git reflog` to see all commits, find the lost SHA, then `git reset --hard ` or `git checkout ` 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.

Question 3

What's the difference between monorepo and polyrepo?

Accepted Answer

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.

Question 4

How do I handle merge conflicts efficiently?

Accepted Answer

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.

Question 5

Should I use trunk-based development or gitflow?

Accepted Answer

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.

Question 6

How do I manage large files and binary assets?

Accepted Answer

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.

Question 7

Can AI help write commit messages?

Accepted Answer

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.

प्रदेश	ज्युनियर	मध्यम	सीनियर
USA	$80k	$120k	$160k
UK	£50k	£75k	£95k
EU	€55k	€80k	€105k

Git & Version Control

Git & Version Control म्हणजे काय

💰 प्रदेशानुसार पगार

🎓 प्रमाणपत्रे

🎯 Git & Version Control वापरणारी करिअर

⚖ यांच्याशी तुलना करा

❓ FAQ

हे कौशल्य तुमच्यासाठी योग्य आहे का, याची खात्री नाही?

तुमचा आदर्श करिअर मार्ग शोधा