Git push to origin/feature errors possibly due to rebase-reassigned commit SHAs

Question

I am trying to integrate git-rebase into my workflow. I have a feature branch my-feature that was branched from develop. In order to have the most recent changes from develop my plan is that I every morning I should (while on my-feature) git rebase develop. This works pretty well, however when I try to push my feature branch

$ git push origin my-feature

I get this error:

 ! [rejected]        my-feature -> my-feature (non-fast-forward)
error: failed to push some refs to 'git@some-domain:some-directory/my-repo.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

I am thinking that git has given shared commits new local SHAs as the logs for origin/my-feature and local my-feature show different ones for the same commit messages. In fact, doing a git pull like it suggests gives me conflicts to reconcile. But I am the only one using this feature branch, so the conflicts are ..with myself?

I was aware that interactive rebase will assign new SHAs when commits are squashed or removed. However I thought what I was doing was a pretty standard workflow for integrating a remote develop branch for longer-running features.

How can I use the rebase functionality to integrate a remote dev branch on a long running feature without introducing conflicts when I go to push my feature?

For clarity my process was basically:

1. On develop
2. Checkout new branch my-feature
3. Do work on my-feature
4. Push code to origin/my-feature (success)
5. Do more work on my-feature
6. While on myfeature, $ git rebase develop (success)
7. git push origin my-feature <-- ERROR (above)

Switching to develop and git rebase my-feature gives me a few expected conflicts I need to fix, but no errors.

Edit:

Also, I am aware I can use --force, however I can foresee sharing a feature branch so don’t think introducing that flag as part of the workflow is a great solution.

Answer 1

There's a lot of great git rebase knowledge here: Git workflow and rebase vs merge questions

But if that doesn't help, often the only way you can push after rebasing is to git push --force, but as the --force flag should indicate, this can be dangerous when there are other people working on the project.

You're correct that rebasing changes the commits and SHA's, since rebase takes the commits you're rebasing and re-plays them on the target branch. But since each commit depends on the commits before it (and that's how the SHA is generated) they will always be new. This causes the problem when you push, since the remote has one set of commits, and the content you're pushing has different commits. The --force flag tells the remote to replace its commits and replace them.

My personal workflow when working on a feature is:

git checkout -b branch_name
# do work
git add .; git commit -m 'my commit message'; git push -u origin branch_name
# do work
git add .; git commit -m 'my commit message'
# there's been an update to dev/master/etc since my last push
git rebase master # (success)
git push --force

But again you have to be careful when using --force

Note that this only happens when you've first pushed the branch to the remote, and then rebased after. You can rebase and push without the error you posted above as long as you haven't pushed before.