ipconfWell well well.
I’ve had juniors who didn’t believe this, so just to say it: If you know what you’re doing, practically any Git problem is recoverable.
The one major exception is if you delete your local changes before committing them.
Yeah.But many of them are extremely annoying. Specifically screwing up rebase. It is recoverable, but very annoying.
That said I have seen juniors make two other common mistakes.
I’m fed up with these two. Yesterday I had to cherry-pick to solve a combination of these two.
Is it ok to continue on a branch if you also merge back main into it? Like, branch gets merged into main on remote, local main pull, local merge main into local branch, push branch?
Is it ok to continue on a branch if you also merge back main into it?
On some repositories, sure.
But better maintained repositories don’t allow merge commits (because merge commits suck), and so will have squashed on merge.
The squash will have changed commit IDs, so a long running branch rebased won’t benefit from a clean shared commit history.
So it can work, but “you’re gonna have a bad time.”
In general, git works best if branches are thrown away as often as possible.
You don’t have to squash to avoid merge commits. Instead, you can git rebase main to update your branch. Effectively, this will rewrite the history of your branch, as if you had just branched from the main-branch and then instantly coded all your changes on top of that. (Well, the commit timestamps won’t change, but they will sit on top of the changes of the main-branch.)
Afterwards, you should be able to merge into main by switching to it and then running git merge --ff-only your_branch.
Because all the changes sit on top of the main-branch commits, it should be able to fast-forward. No actual merging needs to take place then. You’ve already resolved any conflicts while rebasing.
This also allows you to keep branches for longer, so long as you frequently rebase and merge back.