Deal with the merges and conflicts when you want to. Also, it's lot faster to commit. You shouldn't be pushing out every commit -- just commit a lot and when you want others to see it, push it.
Deal with the merges and conflicts when you want to. Also, it's lot faster to commit. You shouldn't be pushing out every commit -- just commit a lot and when you want others to see it, push it.
More generally, I never liked how to cvs and subversion a branch is basically just a copy at the file level. That mixes version control metadata among the file paths that are themselves being version controlled.
Pretty freely is not freely. That's like having 'decent' freedom of speech, y'see. Git allows you to commit any time, so fast you won't even notice the pause.
> As for the faster Git commits, is that just because you are only commiting locally? You still have the overhead of pushing to your central repo.
Yes, it's faster because it only commits locally. You should not push every commit to the central repo, and you should be committing more or less every time you change a file. Git allows you to be far more granular than SVN or perforce did.
It also allows you to throw things away and try things out without worrying about hurting someone else. Branching in SVN/Perforce is simply not worth the effort, but on Git, it's trivial.
Having your own private repo other than what is on the server allows you to experiment and make a lot more mistake without affecting others.