Comment by dkns
7 years ago
> Oh shit, I accidentally committed to the wrong branch!
I find cherry-picking to be easier in this case. Just checkout the branch and cherry pick commits from 'wrong' branch.
7 years ago
> Oh shit, I accidentally committed to the wrong branch!
I find cherry-picking to be easier in this case. Just checkout the branch and cherry pick commits from 'wrong' branch.
But then those commits are still in the wrong branch. If I accidentally commit something to master instead of a development branch, I can't deploy master until my development branch is merged in, as the one commit isn't ready for live.
If you haven't pushed, it's as easy as resetting the branch to the last good commit. If you have pushed, well, it's the same, then push -f, and then making sure that all your teammates pull the fixed branch. If that's a situation you regularly find yourself in, protecting master from direct pushes and only doing PRs is a good solution (GitHub, BitBucket and GitLab all have tooling for this).
Maybe it's just me but I feel like if you work with multiple developers you should never, ever force push master. I'm wary of force pushing branches in general, unless that's a branch that only I work on.
3 replies →
That's where tools like github and gitlab come in (or a pre-receive hook on the server), which can deny all commits to master. If that's something you want to prevent of course - and tbf, as soon as there's more than one or two people working on a project, I'd lock master down.
I don't see how that's easier. There's `git checkout -b my-new-branch` which is even easier than the originally proposed solution. Followed by `git checkout master && git reset --hard @{u}` or, if you don't want to switch between branches, `git branch -f master master@{u}`.
I agree that the proposed solution is not the best. If you can fix your problem without dirtying the working tree (i.e. by simply moving changesets around), that's almost always a nicer way to do it.