cvs is for old guys with beards, git is for glorious young handsome geniuses
GENTLEMEN GENTLEMEN. Let's not get carried away into gifdom here.
There's a place and a time for that and it's called
My question is: can you force push and eff yourself so hard you cry (see Emmett) in CVS too?
With great power comes great responsibility... And I like having that power.
@Emmett once you see firsthand a beautiful rebase -i origin/master; git push origin new_pretty_branch -f, you'll understand.
It is scary sometimes though. Once Tal git push -f'd ALL THE BRANCHES AT BRANCH
*queue 15 minutes of everyone freaking out and figuring out who had local copies of everything*
I hear tales, legends really, whispered among the devs, that one who knows the true power of git reflog can salvage such disasters with a few deft strokes.... legends... surely.
On rebasing: Ideally, all work is done on a feature banch, with frequent commits (git-add -i is terrific, though it's not appropriate for all projects). These commits are rebased interactively (git-rebase -i HEAD~<N> | number of divergent commits) so that each chunk represents a sensible unit (cleanup commits are removed, but separate milestones are kept as separate commits).
Then, when rebasing, you get the benefit of a meaningful git log, with no clutter, and no uninformative 'merge FOO' commit messages.
There are a few caveats (eg git bisect), but they can be addressed if you're smart about interactive rebasing. And if you want to 'backup' the branch, use git-tag for that (that's essentially what the default. soft tag does, really).
Interactive rebase is nice since you can reorganize your commits into some form that makes sense; being able to do so removes the need to worry about it while you're busy writing code.
I keep wanting to say that there are some cases in which a branch isn't necessary, but the more I think about it the less I'm able to form a convincing argument for it. I usually only use branches for biggish features that have the potential to alter a lot of existing code, but come to think of it, there seems to be no good reason to avoid them.
How about git-submodule?
Thinking about playing with it for binaries (Maya files, audio assets, scene files etc.). Keep these in a separate repo and you can separate code vs asset pushes. Continually being bit in the ass by Unity's metadata.
Idea from SO: stackoverflow.com
The tales you've heard are true my enlightened friend. git-bisect allows you to fix all kinds of errors made by you or your brothers in arms. It is best used to find how long you've had a bug and where it was first introduced.
True sorcery though comes from mastery of git reflog. BEWARE initiates, reflog is not for the faint of keystroke. reflog is a darker magic that can overtake you should you not be strong in your commits. This darkness has it's rewards. Have you never sent a change to the depths of despair -- never to be recovered -- with a git reset --hard? Then rejoice my brothers and sisters because git reflog will give your changes new life!
Thanks for your feedback! Team Branch