1

I want to know how to get the commits from a branch where I once branched from, apply all commits to my working branch and apply my working branch commits again.

For example: develop is the branch I branched from --> working_branch. I am working on the working_branch and after a while I want to pull all commits from develop to my working branch and want to put my commits afterwards on top of all commits done on develop.

I hope it is understandable. I know it is possible to rebase to develop, but then the question is how to create a proper merge request. After rebasing onto develop I cannot push the develop branch and create a merge request.

So what's are the command to achieve this.

If its complete non sense, I am sorry.

Tim Schwalbe
  • 1,588
  • 4
  • 19
  • 37
  • why don't you do a merge? That'd be the standard response to wanting to bring both branches together. – Liam Jan 12 '18 at 14:40
  • That's what I would like to do, but my colleagues always telling me do rebase onto develop. So I don't get it. Maybe because there are too much conflicts then, because my branch is old and the develop branch has evolved too much. So it might be better to apply the commits from develop first and then apply my working commits. I am really not sure what's the right way. – Tim Schwalbe Jan 12 '18 at 14:44
  • I think you need to read this [When do you use git rebase instead of git merge?](https://stackoverflow.com/questions/804115/when-do-you-use-git-rebase-instead-of-git-merge) a merge and a rebase are very similar things – Liam Jan 12 '18 at 14:46
  • Possible duplicate of [How to rebase local branch with remote master](https://stackoverflow.com/questions/7929369/how-to-rebase-local-branch-with-remote-master) – Liam Jan 12 '18 at 14:47
  • @Liam: `rebase` and `merge` can result in very different histories, and many development workflows expect developers to use `rebase` on feature branches, while `merge` will be used when actually commiting new features to the master branch. – larsks Jan 12 '18 at 14:48
  • [this is also a very good explanation of what's going on here](https://stackoverflow.com/a/42425567/542251) – Liam Jan 12 '18 at 14:49
  • I'm not sure if I completely understood your problem, but maybe what they want is to rebase your branch using development commits and then apply your commits on top of that? https://stackoverflow.com/questions/7297379/how-do-you-rebase-the-current-branchs-changes-on-top-of-changes-being-merged-in – Pablo Grande Jan 12 '18 at 14:49
  • @Iarsks Yes I know, hence the link to the question https://stackoverflow.com/questions/804115/when-do-you-use-git-rebase-instead-of-git-merge – Liam Jan 12 '18 at 14:51
  • Yes that's it @pablo riutortblo. Get develop commits and apply my commits on top of it. So how to get the develop commits to my working_branch and apply mine again on top. – Tim Schwalbe Jan 12 '18 at 14:52
  • the dupe I've flagged states how to do this – Liam Jan 12 '18 at 14:53
  • Maybe I am wrong but as described here it's then rebase to develop. Means working_branch commits applied on top of develop commits :https://stackoverflow.com/questions/7929369/how-to-rebase-local-branch-with-remote-master. But It want develop commits applied on working_branch and afterwards apply working branch commits. – Tim Schwalbe Jan 12 '18 at 15:02
  • Workflows that rely on rebasing feature branches should *also* prohibit pushing feature branches, because a workflow that makes routine use of `push -f` is asking for trouble. While people have varying opinions about what kind of history "looks nice", *objectively* - i.e. in terms of practical effects going forward - frequent rebasing causes more non-aesthetic issues than is solves. – Mark Adelsberger Jan 12 '18 at 15:11

1 Answers1

3

The answer you're initially asking is how to move the commits. The literal answer is that you can't move commits, but you can rebase them (create new commits that apply the same changes over a different commit, and move the branch to the new commits) which you already know how to do. So that's not really your question.

The reason you can't push is that doing so would remove history from the branch. After the rebase you have

                       A' -- B' -- C' <--(feature)
                      /
x -- x -- x -- x -- x <--(develop)
      \
       A -- B -- C <--(origin/feature)

Normally when you push an update to a branch, the corresponding remote branch is "reachable" from your branch In this case it's not so because you moved the branch (in a manner other than "added new commits to the tip of the branch").

By default git rejects this push because if anyone else has fetched feature, moving it in this way will cause them problems. You can coordinate with the other users to work through those problems, and so you can override git's default decision to reject the push. Beware that if you do this without having coordinated with the other devs, it will cause problems for everyone (including your work potentially ending up being undone).

For information about how to coordinate the clean-up, see the git rebase documentation under "recovering from upstream rebase". You can find it here: https://git-scm.com/docs/git-rebase

If you have all that handled (or, in the simple case, if nobody else has a copy of that branch), then you can "force" the push

git push -f

The one caveat is, depending on how git is hosted, the server may or may not be configured to allow you to do force-pushes to that branch. If not, then that's a team-level rule saying "you can't rebase branches you've already pushed". In that case, you'd have to decide if it's worth it to you to just merge develop into feature

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52