0

I have a use case where we have to maintain multiple versions of code in master branch. However there might be cases wherein i have to clone from older version (older commit), make changes to that and push it back right after that commit. Refer to below example :-

Master branch :- A-B-C-D-E-F

Use case - clone from D, make changes and push it after D (i.e. D'). Also, whatever changes made after cloning shouldn't be reflected in E and F.

After Changes the Master branch should be like - A-B-C-D-D'-E-F

Is there a way to do this in git ?

Karan Gabra
  • 1
  • I think one way is to, first reset E and F, Then Commit D', and then commit E and F again. I believe there is one more way to ammend or rewrite histories https://git-scm.com/book/id/v2/Git-Tools-Rewriting-History – Raman Sharma Nov 09 '17 at 22:51
  • Why do you need to make E a child of D'? You could just leave the history branched. – max630 Nov 10 '17 at 17:48

2 Answers2

0

Not as described, no.

In Git, a commit is completely unchangeable—and the parent hash of a commit is part of the commit, so if the parent of commit E is D, the parent of commit E is always D.

You can make a new commit D' whose parent is D. Once you have done that, you can copy E to a new commit E' that's "like E but better", and then copy F to a new F':

           D'-E'-'F'  <-- master
          /
A--B--C--D--E--F   [abandoned]

This "copy some commits, then move the branch name and abandon the original commits" is what git rebase does:

$ git clone $url repo
$ cd repo
$ git checkout -b new-master master~2  # create new branch at commit D
$ ... work to fix up D and make D' ...
$ git add ...; git commit

This builds D' atop D. Then:

$ git checkout master
$ git rebase new-master

There is one enormous drawback: everyone who has cloned the repository, and has their Git remembering that the old master was commit F, still remembers it. You must get everyone who has a clone of the repository to switch over to using the shiny new F' copy instead of the old broken-down F.

torek
  • 448,244
  • 59
  • 642
  • 775
  • Can't we rewrite the history, I mean reorder the commits https://git-scm.com/book/id/v2/Git-Tools-Rewriting-History – Raman Sharma Nov 09 '17 at 23:01
  • @RamanSharma: You can *copy* commits, and then abandon the originals in favor of the new copies. This is what `git rebase` and other history-editing operations do. The original commits cannot be changed, and if some other Git has them, that other Git still has them until someone takes some specific action with that Git repository. Note that the Git book talks about doing the rewriting *before* sharing the commits with others—but if you *get* them from others, obviously the others must have them already. – torek Nov 09 '17 at 23:03
0

You essentially want to edit history on the remote and there are a few ways of doing that. I will illustrate what would come most naturally to me by doing the D' commit in a feature branch to emphasize the nature of the operation.

suppose you cloned your full repo: A-B-C-D-E-F

git checkout -b feature
git rebase master~2

At this point the history in you feature branch will look like : A-B-C-D

Committing D' you get A-B-C-D-D'. This preserves the history of D-D' (I only mention this as one could equally well do an interactive rebase starting at D through E, where D is replace by D+D').

git cherry-pick E..F

Your history now looks like: A-B-C-D-D'-E-F

You can now push. However, a regular push will result in an error as push only performs fast forward merges (Please see Git push rejected after feature branch rebase ). Thus, you will need to do:

git push --force-with-lease origin feature:master
Svetlomir Hristozkov
  • 151
  • 1
  • 5