DEV Community

DevCorner2
DevCorner2

Posted on

🏢 Git Workflow for Corporate Developers: Feature Branching Done Right

👋 Introduction

In corporate environments, collaboration, code quality, and traceability are crucial. That’s why teams adopt structured Git workflows — most commonly the feature branching model.

Whether you're onboarding or refreshing your Git skills, this guide walks you through the entire lifecycle of a feature branch: from creation to merging via pull request (PR).

Image description

🚀 Why Use Feature Branches?

Feature branches let developers:

  • Work on isolated features safely
  • Keep main or develop stable
  • Enable clean code reviews and testing
  • Trace what feature/bug each commit belongs to

🔁 Standard Workflow Overview

Here's a high-level view:

  1. ✅ Start from the latest main (or develop)
  2. 🌿 Create a feature branch
  3. 🛠 Make code changes and commit
  4. ⬆️ Push the feature branch to remote
  5. 📩 Create a Pull Request (PR)
  6. 👀 Collaborate, review, and approve
  7. 🔀 Merge the PR
  8. 🧹 Clean up (delete feature branch)

💻 Step-by-Step Guide with Git Commands

✅ 1. Sync with Main Branch

Always start with the latest base code to avoid conflicts later.

git checkout main
git pull origin main
Enter fullscreen mode Exit fullscreen mode

Use develop instead of main if your company follows Git Flow.

🌿 2. Create a Feature Branch 

git checkout -b feature/your-feature-name
Enter fullscreen mode Exit fullscreen mode

🧠 Tip: Use consistent naming like:

  • feature/add-login-page
  • bugfix/fix-header-glitch
  • hotfix/rollback-v2

🛠 3. Make Changes and Commit

After coding:

git add .                          # or specific files
git commit -m "Add login API integration"
Enter fullscreen mode Exit fullscreen mode

💡 Best Practices:

  • Write meaningful commit messages
  • Commit often and logically
  • Don’t commit secrets or env files

⬆️ 4. Push to Remote 

git push origin feature/your-feature-name
Enter fullscreen mode Exit fullscreen mode

📩 5. Create a Pull Request (PR)

Now open your Git platform (e.g., GitHub, GitLab, Bitbucket):

  • Choose the base branch (main or develop)
  • Select your feature branch
  • Write a descriptive title and summary
  • Assign reviewers

🎯 Include:

  • What was done
  • Screenshots (if UI-related)
  • Test instructions

👀 6. Collaborate on Review

Your teammates may suggest improvements. Make those changes, then:

git add .
git commit -m "Fix: Updated validation based on review"
git push
Enter fullscreen mode Exit fullscreen mode

🛡 PRs may trigger:

  • Code quality checks (Sonar, Lint)
  • Unit tests / integration tests
  • CI/CD pipelines

🔀 7. Merge the PR

Once approved and tests pass, merge it using the UI.

🧠 Depending on policy, use:

  • Merge commit – preserves full history
  • Squash merge – combines all commits into one
  • Rebase & merge – keeps linear history

🧹 8. Clean Up

Post-merge, delete the feature branch:

git branch -d feature/your-feature-name               # Local
git push origin --delete feature/your-feature-name    # Remote
Enter fullscreen mode Exit fullscreen mode

🧠 Additional Tips

🧼 Keeping Feature Branch Updated

If the main branch moves forward, rebase your feature:

git fetch origin
git rebase origin/main     # or origin/develop
Enter fullscreen mode Exit fullscreen mode

If conflicts occur:

# fix conflicts in files
git add .
git rebase --continue
Enter fullscreen mode Exit fullscreen mode

📚 Summary

Step Action Git Command
1 Sync main git pull origin main
2 Create branch git checkout -b feature/xyz
3 Commit code git add . + git commit
4 Push branch git push origin feature/xyz
5 Open PR (Via GitHub/GitLab UI)
6 Review + Fix git commit + git push
7 Merge PR (Via UI)
8 Delete branch git branch -d + git push origin --delete

📌 Final Thoughts

This workflow ensures clean collaboration, quality assurance, and streamlined delivery. Following it helps:

  • Reduce merge conflicts
  • Improve review efficiency
  • Maintain a clean Git history

🧭 Use this blog as a reference during daily development or onboarding. If your team uses Git Flow or trunk-based development, the core ideas still apply with minor variations.

Top comments (0)