How to Handle Pull Requests and Code Reviews in Git

🚀 Git Workflow Challenge: How Would You Handle This? 🚀 In real-world projects, we never push directly to the master branch — it must always be stable and reviewed. Here’s a scenario I recently worked on: Max created a new story in his feature branch: story/fox-and-grapes He pushed his changes to the remote repo (Gitea). The code needed to go into master, but only after review. He created a Pull Request (PR), assigned Tom as the reviewer, and waited for approval. Tom reviewed, approved, and merged the PR. ✅ This workflow ensures: Code stability in master Traceability of changes Collaboration and review among team members Clean audit trail for compliance Interview Tip: This type of scenario often comes up in DevOps / Git interviews. Expect questions like A. Conceptual / Theory Explain Git branching strategies like feature, develop, and master. What is a Pull Request (PR) and why is it important? Difference between merge and rebase. Why should developers not push directly to master? How do you enforce code reviews in a team? B. Scenario-based / Troubleshooting A developer pushed code directly to master by mistake — how would you fix it? PR cannot be merged due to conflicts — how would you resolve it? The reviewer requested changes in a PR, but the developer already deleted the branch — what do you do? How would you revert a merged PR if a bug is found? C. Real-world workflow questions Describe a typical Git workflow in your last project. How do you ensure the master branch is always stable? How do you handle multiple PRs from different developers merging at the same time? How do CI/CD pipelines integrate with PR approvals? I’m curious — how does your team handle Pull Requests and code reviews? 👇 Drop your thoughts, experiences, or tips in the comments! #DevOps #Git #GitWorkflow #CI_CD #CodeReview #Collaboration #SoftwareEngineering #TechTips

To view or add a comment, sign in

Explore content categories