Collaboration
Update branches, resolve conflicts, and prepare work for review without rewriting shared history.
Treat a published branch as shared. Fetch before making integration decisions, and avoid rewriting commits that another person may already use.
Update your view of the remote
git fetch downloads remote branches without changing your files or current branch.
--prune removes local references to remote branches that no longer exist. It does not delete your local branches.
Rebase a private feature branch
Rebasing replays your commits on a new base and gives them new commit IDs. Use it for your own feature branch; do not rebase a shared branch unless the team has agreed to it.
When Git stops on a conflict:
Use git rebase --abort to return the branch to its state before the rebase. After rewriting a branch you previously pushed, use git push --force-with-lease; the lease refuses to overwrite remote work you have not fetched.
Merge when history is shared
Merging preserves the existing commits and adds a merge commit when a fast-forward is not possible.
Most teams merge through a reviewed pull request instead of merging into main locally. Follow the repository’s branch protection and review rules.
Resolve a merge conflict
First identify the operation Git is waiting for and the files that need attention.
Edit each file so it contains the intended final result, run the relevant tests, then stage it. Finish with git merge --continue or git rebase --continue, depending on the operation shown by git status.
Tag a release
An annotated tag records a named release point with author and message metadata.
Create the tag from the exact reviewed commit that was deployed. A tag is a reference, not proof that an artifact reached production.