1

I have some orphan commits inside my Github repo. They are not present inside of any branch or my local repo, and I can only see them if I select a specific issue with the list of related commits.

Is there any way I can merge these commits into another branch of my choice?

enter image description here

Felipe Peña
  • 2,324
  • 4
  • 18
  • 35
  • 1
    Orphaned commits don't belong to _any_ branch. That's precisely what makes them orphans. – Chris Jan 13 '16 at 04:08
  • @Chris Thanks for the comment. Is there a way to merge these commits into a particular branch? – Felipe Peña Jan 13 '16 at 12:16
  • 1
    @FelipePeña You're looking at it the wrong way. [Commits should not be thought of as *belonging* to a branch](http://stackoverflow.com/questions/29257491/which-branch-do-commits-from-a-deleted-branch-belong-to/29258814#29258814). – jub0bs Jan 13 '16 at 12:19
  • @Jucobs ok, thanks for the link. Assuming one commit is not present in my local repo, and also it's not merged in master, how can I bring it into master ? – Felipe Peña Jan 13 '16 at 12:23

1 Answers1

0

What branch orphan commits belong to? (Git, Github)

Well, by definition orphaned commits do not belong to any branch (btw, it's a bit wrong to say this, better wording is 'which branch-tip commits have the specific commit in their hierarchy chain?'), so I suppose the real question is...

Is there any way I can merge these commits into another branch of my choice?

Surely it is. You can use git cherry-pick command to, quoting the docs, "apply the changes introduced by some existing commits". Here goes a simple example of how it can be used:

First, the repository is initialized:

> git init
> echo 1 > first.txt
> git add . && git commit -m "First commit"
[master (root-commit) a8871cd] First commit
 1 file changed, 1 insertion(+)
 create mode 100644 first.txt

Then, the orphan commits are created (the easiest way is to create a branch, advance it a bit, then remove it):

> git checkout -b branch-to-remove
Switched to a new branch 'branch-to-remove'

> echo 1 > cherry.txt
> git add . && git commit -m "Cherry commit 1"
[branch-to-remove 7cd90f8] Cherry commit 1
1 file changed, 1 insertion(+)
create mode 100644 cherry.txt

> echo 2 >> first.txt
> git add . && git commit -m "Cherry commit 2"
[branch-to-remove 8289dee] Cherry commit 2
1 file changed, 1 insertion(+)

> git checkout master
> git branch -D branch-to-remove
Deleted branch branch-to-remove (was 8289dee).

So branch is gone, but two commits - 7cd90f8 and 8289dee - are still there. Now the master branch is worked upon:

> echo 3 >> first.txt
> git add . && git commit -m "Second commit"
[master e0c199e] Second commit
1 file changed, 1 insertion(+)

Now we have a kind of situation you have in your hands: there are some changes applied somewhere, we need these changes to be applied onto the current branch. It's trivial to do with simple non-conflicting changes, like the one introduced in Cherry commit 1:

 > git cherry-pick 7cd90f8
[master 864dcbe] Cherry commit 1
 1 file changed, 1 insertion(+)
 create mode 100644 cherry.txt

The picked commit is replayed, changes are applied, another commit is created, tip of master branch is advanced, life is good. But what happens with the next one?

> git cherry-pick 8289
error: could not apply 8289dee... Cherry commit 2
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

In fact, nothing really bad: as both commits - HEAD and the picked one - affected the same file, there's a classical conflict going there. Easy to check, easy to fix; just don't forget to git add all the resulting files and git commit them later.

Note that the commits that are result of cherry-pick have single parent only (they're similar to rebased commits in this case).

raina77ow
  • 91,589
  • 12
  • 180
  • 210