0

I’m working on a project where we have different branches (dev, feature,production). I was working on my feature branch, and did multiple commits on that branch for my changes. Later at some point I took a pull from dev branch and that got merged with my feature branch (which I shouldn’t have done). But, I didn’t realised that mistake at that time, and kept working on my feature branch, and did some more commits.

Now I want to only revert that pull taken from dev and keep all my commits of feature branch, also the one I did after the pull. Is it possible to save those commits? I know a little about Git Reset/revert command, but that will not save my later commits i guess. It will point HEAD to previous commit, before the pull.

Can anyone help how I can save my commits made after that merge? Or my understanding isn’t correct regarding Reset\Revert command?

Note-: Changes are already committed and pushed on remote.I’m using Source Tree.

Tushar Sharma
  • 2,839
  • 1
  • 16
  • 38
  • 1
    Perhaps a duplicate of [this](https://stackoverflow.com/q/7099833/1256452)... – torek Nov 04 '21 at 07:48
  • @torek 'git revert -m 1 ’ will revert to the tree of the first parent prior to the merge (In my case the feature). Will this command preserve the commits made after merge? – Tushar Sharma Nov 04 '21 at 07:59
  • 2
    `git revert` does not revert *to* a commit. It *undoes* a commit: it's a sort of "reverse apply" the commit. Compare with `git cherry-pick`, which copies the changes found in a commit. When using `git revert` *on* a merge commit—which has two parents—Git has a problem: to copy or undo changes in a commit, Git needs to have *another commit to compare*. For ordinary (single-parent) commits, the other commit is *the* parent. Merge commits have *two* parents though, so there's no single "the" parent; `-m` tells revert and cherry-pick "which parent". – torek Nov 04 '21 at 08:07
  • 2
    The result of a `git revert` is a *new commit*. All the existing commits remain. This is quite different from `git reset`, which allows you to take commits off of a branch. – torek Nov 04 '21 at 08:08
  • 3
    Git's use of the English word *revert* here was a poor choice. Mercurial calls this operation `backout`, which is better. Both verbs are technically justifiable, but the English-language meaning of "revert" is more commonly the "revert to" meaning that is actually implemented with `git reset`. – torek Nov 04 '21 at 08:10
  • 2
    Note, though, that I don't use SourceTree. If they have a button labeled `Reset|Revert`, that's weird labeling, because these are *very* different operations. Find someone who does know SourceTree before doing anything irreversible (or, perhaps simpler, make sure you use a fresh clone for all your experiments, leaving your *useful* clones untouched). – torek Nov 04 '21 at 08:11
  • 1
    @torek Yes, I'm not using git for remotely as long as you are, but I already have had to explain this language trap to countless coworkers, since the confusion is more than commonplace. I sometimes wonder if they should have even created `git revert` as a command, rather than just giving a `--negative` option to `git cherry-pick`. – Romain Valeri Nov 04 '21 at 08:18

2 Answers2

1

  1. In Sourcetree, double click the last commit before the merge. Doing so will make your working copy a 'detached HEAD' etc

  2. Click "New Branch" and give it a name.

  3. Navigate to all the commits you did after the merge, right-click them and choose "Cherry Pick"

Arik Segal
  • 2,963
  • 2
  • 17
  • 29
0

You just have to reset your checked out branch (with git reset --hard) to the point you want it to be. You may have to use git reflog if the point you desire has been lost.

Until people don't realize, a bad usage of git can lead to developers losing their changes. It is convenient to backup changes using local mirrors sometimes.

carnicer
  • 494
  • 3
  • 9