Mohammed Aamir K
Mohammed Aamir K

Reputation: 341

git reset upstream branch

So the master branch of my upstream repo is in bit of a mess.

Commits on upstream branch looks like below.

A - Latest commit
|
B
|
C - Bad commit
|
D - Commit I want the upstream master branch to be at.

on my forked branch I can do a git reset --hard D. But how can I apply these changes back to the upstream master branch. While creating a PR(Pull Request) from forked branch to upstream branch there are no changes shown.

NOTE: Direct commits on upstream branch is prohibited, it has to be done using a Pull Request from the Fork.

EDIT This is how i have cloned the remote repository.

git clone http://myrepo.git
git remote add upstream http://main-repo.git

Now origin and upstream are like below.

origin - http://myrepo.git
upstream - http://main-repo.git

Forked repository is basically a mirror clone of the remote repository. On the bit bucket UI there is an option to create a fork and enable fork syncing between origin & upstream.

When I say forked branch it means that the branch which is on the forked repository.

Upvotes: 0

Views: 2354

Answers (3)

Joji Angas
Joji Angas

Reputation: 1

I agree with the revert commit. This preserves the actual events that lead to the current state of the code, for historical reference.

Now, with the part where you would want to make the history look 'clean and untainted', this may be possible by squashing a specific range of commits starting from where the 'mistake' was committed, up until the 'revert' commit. But this may need some Admin/Maintainer/Owner access, depending on what these roles are called on your Git repository platform. Ask help from anyone on your team with access to these roles.

Squash commits are mostly allowed on merge request approvals, though. And the action is performed by approvers, which, more or less, is configured to have access to the roles I mentioned above. Not sure if it's available for PRs, though.

Update: Silly me. Merge Requests and Pull Requests are the same. MRs are from GitLab land, whereas PRs are from GitHub land. Idk what these are called on platforms you used (BitBucket, Azure Repos, etc.) Please share your thoughts, as reference. :)

Upvotes: 0

Chuck Lu
Chuck Lu

Reputation: 191

The operation you want is a git push with --force, and since you do not have permission to do this.
Then the alternative operation could a revert operation, and there is an elegant solution for you to revert multi commits.
How to revert multiple git commits?

Upvotes: 2

Jiří Baum
Jiří Baum

Reputation: 6940

If changes need to be done by pull request, you cannot remove commits.

Instead, you will want to revert; this creates a new commit, which reverses the effects of the bad one. Both changes will remain part of history.

Create a new branch as normal, then run the command: git revert hash_of_C (where you substitute the hash of commit C). Review the change, fine-tune the commit message with git commit --amend if needed, then push for review as normal.

If you absolutely need to remove the commit, you'll need to discuss that with the project lead. Editing history that's already part of upstream master is a major disruption to the whole team, most likely you'll be told to revert instead. If the project lead agrees that commit C must not be part of history, they'll probably remove it themselves, most likely by temporarily giving themselves permission to push directly to master. The whole team will need to be alerted as well.

Upvotes: 2

Related Questions