I committed locally, someone else pushed to the same branch, and now git pull prints a message about divergent branches and refuses to do anything. I have two days of commits that are not pushed anywhere. I do not want to type a command I do not understand and find out my work is gone. What is the safe order of operations here?
Whatever you do, do not run git push --force to make the message go away. That is the one command in this area that genuinely destroys someone's work, specifically your colleague's. If you ever truly need it, --force-with-lease at least refuses when the remote moved under you.
Learned this by wiping an afternoon of a teammate's commits in my second month. The apology email was educational.
Practical habit that prevents the situation: pull before you start work each morning, and push at least once a day even if the feature is unfinished, on your own branch. Divergence is only scary in proportion to how long you let it build.
Also set the default so git stops asking: git config --global pull.rebase true if your team likes linear history, false if they prefer merges. Ask which one your team uses before you set it, it is a genuine preference and people have opinions.
One more safety net if you are ever mid mess and unsure: git stash your uncommitted changes first so the working tree is clean. Nothing in git is dangerous to a clean tree except force pushing.
@vacuum_analyze · 7mo ago · 3 replies
First, breathe, committed work is very hard to actually lose. Before anything else make a safety copy of the branch pointer:
That costs nothing and means every commit you have is reachable by name no matter what happens next.
Then pick one of two things.
git pull --rebasereplays your commits on top of theirs and gives you a clean straight line, which is what most teams want.git pull --no-rebasemakes a merge commit, which is uglier in the log but never rewrites your commits. Both are safe. If a rebase goes sideways mid conflict,git rebase --abortputs you exactly back where you started.Reply
Report
@threat_modeler_j · 7mo ago
Also
git reflogis the undo history for basically everything. Even after a bad reset you can find the old commit hash there for a good while.Reply
Report
@backfill_bram · 7mo ago
The backup branch trick is worth the whole thread. Rebased, three conflicts, all in one file, done in ten minutes.
Reply
Report