Hacker News new | ask | show | jobs
by barend 5309 days ago
I've come to see the key distinction between git and SVN as:

* Old workflow: "commit code" and "share code with team" are jumbled together.

* New workflow: "commit code" and "share code with team" are separate actions.

This looks so obvious, but coming from years of using SVN, it took me a while to understand the implications. With git I could fix (with commit --amend) those embarrassing "whoops, forgot to add an untracked file" kinds of mistakes. Over time, I found that my local commits became smaller and more frequent because I can reorder and squash them before pushing (or git-svn dcommitting, as most of my clients run SVN).

Consider a larger change where you might implement it one way, decide you were on the wrong track, back off a bit and implement it some other. With SVN these false paths are either in the common repository confusing the history, or I'm in a disconnected state for an uncomfortably long time. With git, all these changes are local commits that are ultimately kept out of the main history because I've reordered the change history into something comprehensible.

It took me a few months to grok git. Reading an article on the filesystem structure of the repository helped me a great deal.