> The response is often hesitation or outright fear. I get it. Rebase has a reputation for destroying work, and the warnings you see online don’t help.

The best method for stop being terrified of destructive operations in git when I first learned it, was literally "cp -r $original-repo $new-test-repo && go-to-town". Don't know what will happen when you run `git checkout -- $file` or whatever? Copy the entire directory, run the command, look at what happens, then decide if you want to run that in your "real" repository.

Sound stupid maybe, but if it works, it works. Been using git for something like a decade now, and I'm no longer afraid of destructive git operations :)

▲

psychoslave 4 hours ago | parent | next [-]

One step further which is in-scope-of-the-tool spirit will be git clone locally your repository.

And still one step further, just create a new branch to deal with the rebase/merge.

Yes there are may UX pain points in using git, but it also has the great benefits of extremely cheap and fast branching to experiment.

	▲	afiori 3 hours ago \| parent [-]
		in my experience some of the trickiest situations are around gitignore file updates, crlf conversion, case [in]sentivity, etc. where clones and branches are less useful as a testing ground.

▲

bob1029 3 hours ago | parent | prev | next [-]

The fastest way to eliminate fear is to practice. I had the team go through it one day. They didn't get a choice. I locked us on a screen share until everyone was comfortable with how rebasing works. The call lasted maybe 90 minutes. You just have to decide one day that you (or the team) will master this shit, spend a few hours doing it, and move on.

Rebase is a super power but there are a few ground rules to follow that can make it go a lot better. Doing things across many smaller commits can make rebase less painful downstream. One of the most important things is to learn that sometimes a rebase is not really feasible. This isn't a sign that your tools are lacking. This is a sign that you've perhaps deviated so far that you need to reevaluate your organization of labor.

▲

codesnik 4 hours ago | parent | prev | next [-]

whoa. well, if it really works for you. The thing is, git has practically zero "destructive" commands, you almost always (unless you called garbage collector aggressively) return to the previous state of anything committed to it. `git reflog` is a good starting point.

I think i've seen someone coded user-friendlier `git undo` front for it.

	▲	huflungdung 3 hours ago \| parent [-]
		[dead]

▲

thunderbong 3 hours ago | parent | prev [-]

One of the many things I like about fossil is the 'undo' command [0].

Also, since you can choose to keep the fossil repo in a separate directory, that's an additional space saver.

[0] https://www3.fossil-scm.org/home/help/undo