Start by always using rebase --interactive (or just -i) to help you get a feel for it's behavior.
Learn how to use `git reflog` to recover if you botch it up.
The golden rule is: rebase your own stuff all day long, as much as you want. Don't rebase once you've published.
Rebase is a tool for reasoning about your changes as a collection of logical transformations. It's to help you prepare a patch to share with the team. Interactive rebasing (and squashing, fixups, etc) are there to let you checkpoint your work as you go and to give you the freedom to come back and reason about your patches later.
Once I got comfortable with rebase, I began using it as a tool to help me write code. By that I don't mean putting characters into a text file. I mean teasing out isolated changes without interrupting the flow of bigger tasks.
The fear of rebase comes from people who are used to centralized version control systems. They view their version control system as a tool for backups and accountability. Git provides sha1 hashes for backups/security/accountability. Everything else git does is to help you write, reason about, communicate about, share, separate, combine, and otherwise fiddle with patches as logical changes.
If you don't want people to rewrite history, don't give them push access to your repository. Everyone has their own, right? If you want to prevent people from accidentally rewriting canonical history, disable --force pushes to your team's shared repository using a pre-commit hook. But in reality, that won't be an issue because as soon as some one accidentally force pushes, everyone else will have their pulls broken and know the perpetrator immediately identified for flogging.
`The golden rule is: rebase your own stuff all day long, as much as you want. Don't rebase once you've published.`
This is a great rule of thumb, which I have had to repeatedly drill into my team-mates. The crux of the problem, I've come to realise, is that people can't differentiate between a "local" commit and a "published" commit.
Git tutorials need to focus a bit more on the nature of git than on simply showing the basic operations.
Learn how to use `git reflog` to recover if you botch it up.
The golden rule is: rebase your own stuff all day long, as much as you want. Don't rebase once you've published.
Rebase is a tool for reasoning about your changes as a collection of logical transformations. It's to help you prepare a patch to share with the team. Interactive rebasing (and squashing, fixups, etc) are there to let you checkpoint your work as you go and to give you the freedom to come back and reason about your patches later.
Once I got comfortable with rebase, I began using it as a tool to help me write code. By that I don't mean putting characters into a text file. I mean teasing out isolated changes without interrupting the flow of bigger tasks.
The fear of rebase comes from people who are used to centralized version control systems. They view their version control system as a tool for backups and accountability. Git provides sha1 hashes for backups/security/accountability. Everything else git does is to help you write, reason about, communicate about, share, separate, combine, and otherwise fiddle with patches as logical changes.
If you don't want people to rewrite history, don't give them push access to your repository. Everyone has their own, right? If you want to prevent people from accidentally rewriting canonical history, disable --force pushes to your team's shared repository using a pre-commit hook. But in reality, that won't be an issue because as soon as some one accidentally force pushes, everyone else will have their pulls broken and know the perpetrator immediately identified for flogging.