CODEWITHSUNDEEP
gitgithubrebase
Sundeep
Sundeep

Reputation: 1606

Git Remove commits from a project fork

So, I forked a project on Github, and made 2 commits. I also pushed these commits to my fork.

At the same time, the upstream project also had 2 commits.

Let's say at the time of forking, both the branches are at head A

A

and I made my two commits B and C and pushed them into my fork

A - B - C

and upstream made commits D and E

A - D - E

In my clone repo of the fork, I fetched from upstream, so the state is

A - D - E
  \ 
    B - C

Then I did a rebase, which brought the state to

A - D - E
  \ 
    B - C - D' - E'

Now, I want to make it in my fork so that D and E never existed and the head is at E'. I am the only one using my fork.

I checked several other answers here and I don't see any questions that have this problem of multiple heads(E and E').

Upvotes: 4

Views: 5405

Answers (2)

javaHolic
javaHolic

Reputation: 45

As you have mentioned you have - your forked branch - Lets call it as 'Origin' at A-B-C- status (Assuming its push to your Origin),

Now Main Branch (Call it as 'upstream') has few changes A-D-E, So you have to do is ,pull code from upstream and if you are using Eclipse/or Local, you will have your code ( A-B-C ++ D-E) if you don't have any conflict, push it to your Origin branch, so your repo will be in Sync & then you can also make pull request for your Changes which are B-C ,

Now your Upstream which is main branch and your Origin which is Forked branch are even.

Upvotes: 1

Mark Adelsberger
Mark Adelsberger

Reputation: 45819

What you've left out of your picture are the refs - branches and tags (and remote branch refs, and potentially a few other things).

When you rebase, if you have a branch checked out (or specify to check a branch out at the start of the rebase), the default behavior is to move the checked-out branch ref to the rewritten commits. The original commits always still exist; but if no refs still point to them, default log output won't show them.

However, one ref surely still points to them: the remote branch ref for the branch you rewrite. This will be corrected when you push your updates to the origin. This will have to be a "forced" push (git push -f), but since you are the only user of the repo that shouldn't matter.

If other branches still point at the original commits, you can use git reset to move them to the new commits.

git checkout branch
git reset <new-commit-id>

If branches point to other commits from which the original commits are reachable, then those commits would have to also be rewritten. That's a bigger topic so let us know if it applies.

Similarly with tags, if they point to the original commits you could move them (git tag -f ...).

Upvotes: 4

Related Questions