Versatile software engineer with a background in .NET consulting and CMS development. Working on regaining my embedded development skills to get more involved with IoT opportunities.
Came here to say this. If you rebase a public (shared) branch, the other devs working on it are going to be very upset with you. You can rebase all you want while the branch is local, but the second you push it you have to go back to merging.
So if I fetch origin/master to my local origin/tired branch then I could rebase it. Work on the branch and when I'm done later in the day I can push to GitHub to origin/tired and make a PR to origin/master?
You forgot to mention the golden rule! If the working branch is public (someone besides you has a copy of it), please don't rebase!
Came here to say this. If you rebase a public (shared) branch, the other devs working on it are going to be very upset with you. You can rebase all you want while the branch is local, but the second you push it you have to go back to merging.
So if I fetch origin/master to my local origin/tired branch then I could rebase it. Work on the branch and when I'm done later in the day I can push to GitHub to origin/tired and make a PR to origin/master?
That’s correct!
I think the phrasing of this question could use some clarification.
A good general rule is not to rewrite history (any history) after it has been pushed to the shared repo.
Which means that when you are rebasing in your local repo, you’d only want to rebase your newer commits that haven’t been pushed yet.