Good question. You can pull as well. But when you run git pull, it automatically does a merge. And whenever git merge happens, a merge commit is created. A merge commit is not a bad thing, but too many merge commits can make your local commit history look confusing. So that's why rebase is preferred for local repository, since rebase does not create an extra merge commit.
You can checkout my article on rebase to understand this further :)
Yes. The basic ground rule is, if your branch has any commit which is there in the remote repository, it is better to avoid rebase since rebase alters commit history. It's fine if one developer is working. But if multiple developers are working then it becomes an issue
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.
Good question. You can pull as well. But when you run git pull, it automatically does a merge. And whenever git merge happens, a merge commit is created. A merge commit is not a bad thing, but too many merge commits can make your local commit history look confusing. So that's why rebase is preferred for local repository, since rebase does not create an extra merge commit.
You can checkout my article on rebase to understand this further :)
adityasridhar.com/posts/how-to-bec...
Thanks. So if I understood correctly you advise to rebase from release->feature branch but not the other way around? Makes sense!
Yes. The basic ground rule is, if your branch has any commit which is there in the remote repository, it is better to avoid rebase since rebase alters commit history. It's fine if one developer is working. But if multiple developers are working then it becomes an issue