SauravBhattacharya
SauravBhattacharya

Reputation: 643

How to make one remote branch identical to another

On origin, I have 2 branches: master and development.

master is ahead of development by a few commits and behind by a few commits.

I want the tree of master branch to be identical to the one of development branch (talking about the tree object of the revisions, not the history, actually). It is fine if I lose anything on the master branch, but the development branch should be intact.

Reasons for doing this is, we have a workflow where we work on development and merge to master when we are ready to do a release. Over time there have been some commits made directly to master. We want to bring master back in sync with development.

Can you please share how this can be achieved? One way which I think might work is merge master to development, then revert the commit from the merge in development, and merge development to master.

Edit: I cannot force push. I need to create a pull request to make any changes.

Upvotes: 1

Views: 825

Answers (2)

Antebios
Antebios

Reputation: 1781

What you have encountered is a standard Git development problem that we all run into, and because of that a branching methodology has been created. Some branching strategies are more popular than others. The 3 most popular are:

  1. GitFlow (what it seems like you need): https://nvie.com/posts/a-successful-git-branching-model/

  2. GitHub Flow: https://guides.github.com/introduction/flow/index.html

I'm going to quickly describe how to solve your issue:

  1. In 'develop' branch, do a pull from 'master'. Resolve any merge conflicts in the 'develop' branch and then commit and push into the 'develop' branch.'
  2. Do a build from the 'develop' branch and make sure everything builds and pasts any unit tests if you have any.
  3. Complete a Pull Request to get your code into the 'master' branch, and now your 'master' branch and 'develop' branch are now in sync.

This is how to solve your issue going forward:

  1. Do your development work in 'develop' branch
  2. Do your features in 'feature' branches. Create Pull Requests to get code from 'feature' branches to 'develop' branch.
  3. Merge from 'develop' into 'release' branch, and build package from 'release' branch and deploy to Test environment.
  4. Do your testing builds in 'release' branch and testing fixes in the same 'release' branch.
  5. After you deploy to production, then merge your code into the 'master' branch and DO NOT TOUCH IT. This is our golden Production code.
  6. If there is a Production issue, branch FROM the 'master' branch into a new branch called 'hotfix' and do commits and builds from here, and deploy into Production for emergency fixes.
  7. When done, merge fixes backwards into 'master' branch, then 'release', and 'develop' branch. Individual developers will absorb the fixes into their 'feature' branches when they are ready.
  8. There is a lot I am skipping, but I am hitting the top points on the branching methodology called "GitFlow" mentioned above. This is a slow process that slows you down on purpose. You do not have to follow this process, or you can modify this process to suit your needs. This is a much larger topic that you can spend hours upon hours reading. Good luck.

Upvotes: 0

eftshift0
eftshift0

Reputation: 30212

just push development into remote master (even if by using -f to force it):

git push -f origin develop:master

Adjust name of remote.

Another hackish suggestion

If you want to have master look exactly like develop with a PR with the least amount of work possible, this is what you would want to do:

git cat-file -p origin/develop # find the ID of the _tree_ of this revision
git commit-tree -p origin/master -m "Tree of master is now just like develop" id-of-tree-of-last-command # create a new revision with the same tree of develop... this will generate one ID
git checkout -b some-development use-id-printed-by-commit-tree
git push some-remote some-development

Now you can create your PR from some-development.... if you also want develop to be a parent of this revision, add it as another -p parameter to commit-tree.

Upvotes: 4

Related Questions