I have a scenario where I have a git branch (b), based off of develop.
I then made changes to branch (b) and pushed to remote (b)
Some other developer made a PR and had their code merged into develop.
I then pull the changes from remote/develop and rebased my local branch (b) onto develop
I then make more changes to my local branch (b)
When I commit and push my changes, I get a rejected error: [! [rejected] feature/b-> feature/b (non-fast-forward) error: failed to push some refs to 'gitlab' hint: Updates were rejected because the tip of your current branch is behind]
What I normally tend to do is to do a --force push
But I'm wondering if this is the right approach?
CodePudding user response：
Once you have made b "public" by pushing it to the remote (where anyone else might pull it), you can't effectively rebase your local branch any more.
Instead, you should have merged the updated develop into b, which does not rewrite history. Having done this, you can reliably push additional changes from your local b to the remote b, and others will simply see that you have resolved any differences between b and develop by merging, rather than seeing an unexpected change in where b branched off develop in the first place.
CodePudding user response：
Your push was rejected because your local copy of your branch has a different history than the remote copy, because you rebased. Considering that you rebased intentionally, and that you want the remote version to get those changes, using force is entirely appropriate if you’re confident that nobody else is also working from the remote copy of your branch.
The best way to ensure that you’re not changing a branch that someone else is to make your own fork of the repo and push your changes to a branch in your fork; when you’re ready, you then make a pull request back to the develop branch in the “shared” repo. If each developer on your team has their own fork of each project’s repository, and if you all understand that personal forks of a repo are meant for tracking your own work in progress, there’s no real danger of creating a problem for someone else.
An alternative would be to push your rebased branch to some new remote branch, leaving the un-rebased one alone. There’s little point in that if you know you’re the only person using the branch, though.
CodePudding user response：
When you receive a "non-fast-forward" error while pushing to a Git branch, it means that the remote branch has new commits that are not present in your local branch. This can happen if someone else has pushed new commits to the remote branch while you were working on your local branch.
The "right" way to handle this situation depends on what you want to do with your local changes. If you want to discard your local changes and use the latest version of the branch from the remote, you can use the git reset command to reset your local branch to the latest version on the remote. This will discard any local changes that you have made and leave your branch in the same state as the remote branch.
Alternatively, if you want to keep your local changes and merge them with the latest version of the branch on the remote, you can use the git pull command to pull the latest changes from the remote and merge them with your local branch. This will create a new merge commit that combines your local changes with the latest changes from the remote branch.
In either case, it is not recommended to use the --force flag when pushing to a remote branch. This flag can overwrite other people's changes and cause conflicts, which can be difficult to resolve. Instead, it is best to use the git reset or git pull commands to handle non-fast-forward errors in a more controlled manner.
CodePudding user response：
It is generally not recommended to use the --force option when pushing changes to a remote Git branch. Using --force can overwrite changes on the remote branch, potentially leading to data loss or conflicts with other developers who are working on the same branch.
In your scenario, it sounds like you made changes to your local branch (b), and then someone else made changes to the same branch on the remote repository. When you tried to push your changes, you received a "non-fast-forward" error because your local branch is behind the remote branch.
To resolve this issue, you can try the following steps:
Pull the latest changes from the remote branch (b) using the git pull command. This will merge the remote changes into your local branch.
Resolve any conflicts that may have occurred during the merge. This may involve manually editing the files that have conflicts, and using the git add and git commit commands to stage and commit the resolved changes.
Push your updated local branch (b) to the remote repository using the git push command. This will update the remote branch with your changes, and you should no longer receive a "non-fast-forward" error.
By following these steps, you can avoid using the --force option and safely merge your changes with the latest changes on