Search code examples
gitgithubgit-merge

How to fix a remote branch on Git ahead of my local repository without doing a pull

I am working on a project with a number of people using git. I am remote from the team, and the way we have worked is like so:

1) they create branches off 'develop', then merge them into 'develop' after testing and push that to the origin repo. This happens a lot.

2) I, every so often, create my own develop branch off the origin: a branch called 'my_develop'. I then create branches off that, test them and merge them into 'my_develop'.

3) as they update 'develop', I frequently merger 'develop' INTO my branch (i.e., into my_develop). This minimizes divergence without needing to integrate my work into develop on a daily basis.

4) about once a month, I push 'my_develop' to origin, issue a pull request, and it gets merged into develop - and then I start with a new 'my_develop2', etc.

Here is the problem. In a nutshell, at one point, code got into develop that had some serious problems that went undetected for a short while. I had, however, merged this bad 'develop' branch into 'my_develop', and pushed it to origin. It became a functionality problem that froze my progress, so I at one point, on my local repository, done a 'git reset' to a commit on 'my_develop' three commits prior to what is on origin.

The problem now is that I can't push 'my_develop' to origin. It objects on the grounds that the 'tip' on origin is a few commits ahead of what I have locally, and asks me to do a pull to integrate the changes from origin on branch 'my_develop'.

The point, of course, is that I have been doing incremental development from that point a few commits back from what is on origin. At this point, the HEAD of 'my_develop' on origin is outdated and a pull would undo all the changes I have made on the 'live' branch locally.

I have seen people make 3 suggestions how to fix this:

1) do a 'git push origin my_develop --force'. Logically this is what I want to do, but there are many warnings about the dangers of doing this.

2) some suggestions say to handle this with a rebase, though I don't quite see how to do that.

3) option #3 involves using 'ours' as a means of merging but giving git guidance to decide which line of code 'wins' in a merge conflict.

Any advice on the best way to do this?

NOTE: I am the only person who does work on 'my_develop', if that helps.

NOTE since I first posted: I suppose I could simply go onto my branch ('git checkout my_branch'), then create a new branch off that ('git checkout -b my_latest_branch'), and then simply work from that one - and then push that to origin and issue a pull request. This would orphan the tip of 'my_branch', but do I care?

Solution

  • Because you're the only one on my_develop

    NOTE: I'm the only one working on my_develop

    I recommend using git push --force

    1. As you're the sole developer on my_develop, you can safely use git push origin my_develop --force. This won't impact other team members.

    2. rebase is a good practice for updating your feature branch my_develop with code from the main branch. However, your feature branch must not have any previous merges

    3. If the code on develop is unstable, avoid merging it into your feature branch.

    P.S. You can create a new branch from the last commit before the develop merge and continue working there.