Or, equivalently, start with the branch delete, then rename new_A to A. Assuming it all works and is good, here's the last few steps: $ git branch -m A old_AĪnd then, if old_A can be abandoned entirely: $ git branch -D old_A So "what to do" depends on "what you want the result to be".Įdit to add: I like the format-patch method better as it leaves my old A branch name around while I make sure everything is good.
If you want to preserve the original A1 and A2, this is a good thing if you want to get rid of them, it's a bad thing. Of course it's also possible to just git merge (as in the answer by Gary Fixler), but that will create a merge commit ("M" with no number, below) and keep revs A1 and A2 visible, giving: M1 - M2 - M3 (If my A3 needs modification to become A3', both the interactive rebase and the "git am" method will require work by me, of course.) If I use the first approach and it succeeds, I end up with the same thing, it's just that my existing branch name A will now point to A3' (and I have no name for the old branch with A1-A2-A3, even though it's still in my repo finding it requires going through reflogs or similar). Where my branch name new_A points to A3' (my existing A branch still points to the old A3). If the second approach is successful I end up with: M1 - M2 - M3 These do require figuring out what I have that Mr Blond didn't before he did his rebase, i.e., identifying A1, A2, A3, etc.
Git rebase origin manual#
(the git am -3 -k method is described in the git-format-patch manual page). $ git format-patch -k -stdout A3.A | git am -3 -k Or: $ git checkout -b new_A remotes/origin/A One obvious direct way: $ git branch -aĪnd then drop revs A1 and A2 entirely, since the modified ones are in new_A as A1' and A2'. (with my local label pointing to A3 rather than A2 or A4 or A5, etc, depending on how many changes I have applied.) Now all I have to do is rebase my A3 (and A4 if needed, etc) onto A2'. If I've been working on my copy of the branch named "A" I'll have this instead: M1 - M2 - M3 The one important difference is, I'll have my local label A pointing to rev A2, and the remote label remotes/origin/A pointing to A2' (Mr Blond had it the other way around, local label A pointing to A2' and remotes/origin/A pointing to A2). Now I'll have this in my repo, which is what Mr Blond had after his rebase and just before he ran "git push -f". My recommendation (or, "what I would do if I were Mr Orange") is, start with git fetch.
Will pull -f force the changes from the remote locally? I know that deleting the local version of A and bringing it again from the remote repository will do the trick but that doesn't seem to be a good way to achieve that. Orange need to do in order to be synchronized with A branch in the remote repository?Ī normal pull won't work. His local repository still looks like this: M1 - M2 - M3 Now the remote repository looks like this: M1 - M2 - M3īut Mr. Mr Blond pushes his commits, using -f to force his changes and "rewrite" history. Now A1` and A2` are the rebased commits that exist locally at Mr blond's, and A1 and A2 exist remotely. Mr Blond pulls from the remote, and after a while decides to rebase onto the master branch: M1 - M2 - M3 Meanwhile, Mr Orange committed and pushed 2 more commits on the master branch, M2 and M3. Mr Blond and Mr Orange are working on branch A that branches out of the master branch on commit M1.
0 kommentar(er)
