Fair point! Stems from my bad habit of merging the remote even when it's not the best choice.
Basic explanation to those unaware: rebasing will shift all of your commits to after the last commit of the remote, making your branch look like it's building off of the master / develop you want to merge in. Just merging will not fix up the commit history like this, even though it yields the same resulting code in your editor. This article gives a nice visual.
I forgot to add that some projects have specific rule that states something like "rebase your changes on top of upstream before creating pull request".
Found example.
"Note that it is highly recommended to keep your pull requests up-to-date. If you do not know how to do this, take a look on manpage of git-rebase." github.com/termux/termux-packages#...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"merged the remote branch into yours" - why don't "rebased your branch onto remote one"?
Fair point! Stems from my bad habit of merging the remote even when it's not the best choice.
Basic explanation to those unaware: rebasing will shift all of your commits to after the last commit of the remote, making your branch look like it's building off of the
master/developyou want to merge in. Just merging will not fix up the commit history like this, even though it yields the same resulting code in your editor. This article gives a nice visual.I'll make an edit shortly :)
I forgot to add that some projects have specific rule that states something like "rebase your changes on top of upstream before creating pull request".
Found example.
"Note that it is highly recommended to keep your pull requests up-to-date. If you do not know how to do this, take a look on manpage of git-rebase."
github.com/termux/termux-packages#...