3 ms·
Your dev tree doesn't have to be always working so you can clean your commits later, you can commit much more often. Instead of using the VCS just for final col
by wnight 15y ago
Your dev tree doesn't have to be always working so you can clean your commits later, you can commit much more often. Instead of using the VCS just for final collaboration you're now much more mobile. In a centralized VCS check-ins and branching are the sorts of things that risk breaking tests and require your team's awareness. With a DVCS you're the only one using it and can check-in every minute if you want, have all the experimental branches you need, etc.
Instead of copying files or some other manual filesystem manipulation to swap between lines of development you're using a tool to help you. Once you're free to branch around as you wish you can get even partial ideas into code - they don't block anything by not being complete.
Then you can clean up this dev rambling into the public commits you want everyone else to see - usually the whole side-project in a couple of larger (and often out of original order) commits. Here is where you make sure the tests are successful at each commit, that you reference bug numbers, write decent commit messages, etc.
And you can do this without anyone needing to know or help with anything until you finally have nice clean commits based off of the current tree and they get imported as nice atomic chunks. You can either ditch your ugly dev commits, or keep them without it getting in the way if you're a history junkie.
tl;dr Instead of a flat directory as your sandbox you've got a full VCS at your disposal.
- georgieporgie 15y agoIn a centralized VCS check-ins and branching are the sorts of things that risk breaking tests and require your team's awareness Huh? Branching code in no way affects the code that has been branched. Instead of a flat directory as your sandbox you've got a full VCS at your disposal I don't get it. I can make as many branches in Subversion as I want. It's pretty common for me to have a couple of active branches off the same parent, as I try a couple of different approaches to a problem. So far, the only advantage I see to Git is the ability to make offline commits (presumably they sync when I have a network connection). But that's only an advantage in my hypothetical future where I'm developing code as I travel around the world.
- wnight 15y ago> Branching code in no way affects the code that has been branched. Usually it requires a repo admin - hence "team awareness". > So far, the only advantage I see to Git is the ability to make offline commits That's more important than you imagine. It also means nothing takes longer than a few seconds - branching, diffing, committing... > I don't get it. I can make as many branches in Subversion as I want. But you can't do it offline. You can't even check-in without the central server, let alone make and use branches, merge them, share them with another dev, etc. When you're offline you aren't using a VCS at all. > presumably they sync when I have a network connection Hah, no. That's half the fun.