Git Workflow: Solo vs Team

I Pushed Directly to Main My First Week

On side projects, I pushed straight to main. Commit messages like "fix", "update", "asdf". Nobody knew, nobody cared.

First week at my first job, I pushed directly to main and got a 30-minute lecture from a senior dev. Why you need branches, why you need PRs. My entire perception of Git changed that day.

Branches Are Worth It Even Solo

Honestly, even when I'm working alone, I use branches. I create feature/ and fix/ branches even in side projects. If an urgent bug pops up mid-feature, I can just switch branches and fix it quick.

But I skip PRs. Nobody to review them. Commit messages are more relaxed too. Stuff like "cart feature halfway done."

Teams Need Rules

Branch naming conventions, commit message formats, PR templates, merge strategies. Don't nail these down and your Git history becomes a jungle within a month.

Our team does it like this: branches are feature/JIRA-123-add-cart, commits follow conventional commits, PRs need at least 1 approval, and we squash merge. Felt tedious at first, but once it's muscle memory, your hands just do it automatically.

Commit Messages Are for Future You

Solo: "implement login", "fix bug", "fix".

On a team: "feat: add social login (Google, Kakao)", "fix: total not updating when cart quantity changes".

(Honestly, even solo, writing just "fix" means you'll have zero idea what you fixed later.)

A good commit message explains the "why" behind the change. Not "change login logic" but "add token refresh logic to fix auto-logout not triggering on session expiry."

Squash Merge Saves Your History

Solo, fast-forward or whatever -- doesn't matter. On a team, your merge strategy determines how readable your history is.

We use squash merge. Even if you made 10 commits building a feature, it goes into main as one clean commit. No more "typo fix" and "lint fix" commits cluttering up the history.

Rebase vs Merge Is a Religious War

Personally, I prefer rebase. Keeps the history clean. But if someone on the team isn't comfortable with Git, merge is safer. Mess up conflict resolution during a rebase and commits can vanish.

Our current setup: git pull --rebase origin main before opening a PR, then squash merge. This combo is clean and safe.

PRs Are for You Too

Solo, you don't need PRs. On a team, merging without a PR is risky. PRs are the minimum safety net for code quality.

I frequently catch stuff when reviewing my own diff before opening a PR -- "oh wait, that code shouldn't be in there." Even if the reviewer approves immediately, the act of opening a PR forces you to review your own code one more time.

What Actually Matters Is Consistency

Solo, Git is a backup tool. On a team, it's a communication tool. What matters isn't the specific rules -- it's that everyone follows the same ones.