Git & DevOps Questions

Git Pull vs Fetch vs Rebase

git pull origin main : what it does actually your feature branch gets updated by merging the latest changes from main, resulting in a merge commit. git rebase main : what it does actually

• Downloads changes from the remote without applying them to your local branch.
• It updates your remote-tracking branches (like origin/main) but doesn’t touch your local code.
• Shortcut for: git fetch + git merge
• It fetches and automatically merges changes from the remote to your current branch..
• Re-applies your local commits on top of another base branch.
• Often used to maintain a clean linear history.
• Ideal in feature branches before merging to main: git rebase main

git fetch origin main
git merge origin/main

re-applies your feature commits on top of the latest main,
 giving you a linear history with no extra merge commit.

What Are Git Tags?

A Git tag is like a label you attach to a specific commit to mark it as important , typically used for version releases like v1.0.0, v2.3.1, etc.

• Like a bookmark: just points to a commit.
• No extra data (like message, date, author, etc.)
• Full object in Git database
• Includes: Tag message,Tagger name, email, date,

git tag v1.0.0

git tag -a v1.0.0 -m "Release version 1.0.0"

"power features" of Git

pick a specific commit from another branch and apply it to the current branch. Creates a new commit that undoes a previous commit. Clean up local changes or commits before pushing. You’re in the middle of something, but need to quickly switch branches. Temporarily save changes without committing.

git cherry-pick commit-hash-id

git revert commit-hash-id

git reset --soft HEAD~1
git reset --hard origin/main

git stash
git stash list
git stash apply
git stash pop

Branching Strategy

we should follow a branching strategy that helps us manage features, releases, and hotfixes. Typically, we should maintain multiple long-running branches like main and develop, and then use short-lived feature and hotfix branches and we merge them to long running branches. “For example, if I'm working on a new login module, I’ll create a branch like feature/login-ui. Once it’s done, we raise a PR to develop, after QA signoff, it gets merged to develop. At the end of a sprint, we cut a release/1.2.0 branch from develop , do final QA, and merge into main with a Git tag. If there’s a production bug later, we do a hotfix/login-crash, merge it into main and also cherry-pick it back into develop to keep both in sync.”

Long-lived branches:
- main       → Production-ready code
- develop    → Staging/Integration branch

Short-lived branches:
- feature/feature-name   → New features
- bugfix/issue-number    → Bug fixes in develop
- hotfix/issue-number    → Urgent fixes directly on main
- release/version        → Pre-release stabilization