Originally published in adityasridhar.com
I am not able to commit to the remote repository, let me do a force push.
Let me Run Rebase on the remo...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for the great article. I'm still learning all this so why rebase and not simply pull in this case?
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
Nice article!
Another wrong way with Git is changing time on your development environment, trying to simulate with another project and forgot to return it. So, the commit was made 2 weeks ahead...on master. That was a bad day.
Remember kids, check your server time before to make a commit and push if you're playing with it.
Thanks. Yes, changing the time in your dev environment can create issues :D.
I use hard reset as my last resort.
I have mixed feelings about distinguishing by remote or local. As you point out each time the actual issue is shared vs unshared. I can see how this gives a good goto principle for Git beginners, but you learn through mistakes.
Also, if you do get into a rebase for a shared branch, you can reach for cherry-pick or rebase interactive to take just the needed changes.