You know the Git commands. Now let's talk about how teams actually use them. Without a workflow, you get chaos: people pushing to main, conflicts every day, the test suite breaking because someone committed half-written code.
The Feature Branch Workflow is what 90% of QA automation teams follow. It's simple, it works, and it's what interviewers expect you to know.
| Prefix | Purpose | Example |
|---|---|---|
| feature/ | New test cases or test features | feature/login-tests |
| bugfix/ | Fix a broken or flaky test | bugfix/fix-cart-locator |
| refactor/ | Restructure code without changing behavior | refactor/page-object-cleanup |
| chore/ | Config changes, dependency updates | chore/update-selenium-4.18 |
| Bad Commit Messages | Good Commit Messages |
|---|---|
| "fixed stuff" | "Add login test for valid and invalid credentials" |
| "WIP" | "Fix flaky cart test by adding explicit wait" |
| "test changes" | "Refactor LoginPage to use CSS selectors" |
| "asdfgh" | "Update Selenium to 4.18.0 for Chrome 122 support" |
| "updated file" | "Add .gitignore for test-output and screenshots" |
# === Morning: Start your day ===
git checkout main
git pull origin main # Get latest code from team
# === Create a branch for today's task ===
git checkout -b feature/search-tests
# === Write tests, commit frequently ===
git add src/test/java/tests/SearchTest.java
git commit -m "Add search test for product name filter"
git add src/test/java/pages/SearchPage.java
git commit -m "Add SearchPage page object"
# === Before pushing: get latest main and rebase ===
git checkout main
git pull origin main
git checkout feature/search-tests
git rebase main
# This puts your commits ON TOP of the latest main — clean history
# === Push and create PR ===
git push origin feature/search-tests
# Then go to GitHub → Create Pull RequestCommit small, commit often. A commit with "Add login test method" is easy to review. A commit with "Add 15 test classes and 8 page objects" is a nightmare for reviewers. Small commits = faster reviews = faster merges.
Q: What is the difference between git merge and git rebase?
A: Both integrate changes from one branch into another, but differently. git merge creates a new merge commit that joins both branches — the history shows a fork and rejoin. git rebase replays your commits on top of the target branch — the history is a straight line. I use rebase to keep my feature branch up to date with main before creating a PR (so the history is clean). I use merge when actually combining a PR into main. The golden rule: rebase your own branches, merge shared branches.
Key Point: Pull latest main → create branch → commit often → push → create PR → get review → merge. This is the daily routine.