5 ms·

> 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

by dkns 9y 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. https://git-scm.com/docs/git-cherry-pick https://git-scm.com/docs/git-cherry-pick

deleted 9y ago
[deleted]
mtrpcic 9y ago
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.
- Cthulhu_ 9y ago
  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.
- mseebach 9y ago
  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).
  - dkns 9y ago
    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.
    - mseebach 9y ago
      It's not ideal, at all -- and if someone else has pushed in the meantime, they risk losing the commit. But if you're in a situation where doing this would be a significant problem, you should probably not be pushing directly to master in the first place, instead relying on a PR workflow.
      - sigjuice 9y ago
        Why not simply push a second commit that reverts the broken commit? This will avoid rewriting history and messing up the rest of your team.
        mseebach 9y ago
        Because that will pollute the history and diminish its value as a record of what happened in the code base. For instance, blame will no longer tell you when a line was changed, but rather point to the revert commit. Bisect breaks if it divides through the reverted commits. Of course, rewriting history is only feasible immediately after the mistaken commits, before anyone builds on top of them. If they've lingered, reverting is the right way. And again, if this is a repeating problem, fix it upstream (no pushing to master, only PRs).
nemetroid 9y ago
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.
yes_or_gnome 9y ago
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}`.

by dkns 9y ago

deleted 9y ago

[deleted]

mtrpcic 9y ago

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.

Cthulhu_ 9y ago
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.
mseebach 9y ago
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).
- dkns 9y ago
  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.
  - mseebach 9y ago
    It's not ideal, at all -- and if someone else has pushed in the meantime, they risk losing the commit. But if you're in a situation where doing this would be a significant problem, you should probably not be pushing directly to master in the first place, instead relying on a PR workflow.
    - sigjuice 9y ago
      Why not simply push a second commit that reverts the broken commit? This will avoid rewriting history and messing up the rest of your team.
      - mseebach 9y ago
        Because that will pollute the history and diminish its value as a record of what happened in the code base. For instance, blame will no longer tell you when a line was changed, but rather point to the revert commit. Bisect breaks if it divides through the reverted commits. Of course, rewriting history is only feasible immediately after the mistaken commits, before anyone builds on top of them. If they've lingered, reverting is the right way. And again, if this is a repeating problem, fix it upstream (no pushing to master, only PRs).

nemetroid 9y ago

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.

yes_or_gnome 9y ago

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}`.