Collaborative Workflows and PR Best Practices

When working on a shared repository with a team, you will eventually encounter push rejections.

1. Handling Push Rejections

If another developer has pushed changes to the remote repository since your last pull, Git will reject your push:

To github.com:username/repository.git
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to '...'

The Wrong Way: Force Push

Avoid running git push -f or git push --force. This overwrites the remote history, deleting your teammate's commits.

The Right Way: Pull with Rebase

Download the remote changes and apply your local commits on top of them:

# Pull changes and rebase your commits onto the incoming tip
git pull --rebase origin main

If conflicts occur during the rebase, Git will pause. Resolve the conflicts in your editor, stage the files with git add, and continue the rebase:

git rebase --continue

2. Pull Request (PR) Lifecycles

In professional teams, developers do not push code directly to the production branch. Instead, they follow the Pull Request workflow:

1. Push Feature Branch: Push your local branch to the remote: git push -u origin feature-auth.
2. Open a PR: Go to GitHub, open a Pull Request comparing your feature branch to the main branch.
3. Code Review: Team members review the code diffs, leave comments, and suggest changes.
4. Merge: Once approved and tests pass, merge the PR into the main branch.