4 ms·

This is what I used to think. Until I started using it. And mind you I'm not a power user - I'm barely a developer at all. I think the reason that git has this

This is what I used to think. Until I started using it. And mind you I'm not a power user - I'm barely a developer at all. I think the reason that git has this proliferation of tutorials, cheat sheets, etc. is not that it's not easy to use, because (as I've discovered) it is easy to use. No, I think the reason is that people have a pre-conceived intuition of what version control should be, and that intuition is actually wrong. So when they encounter something that does it right (git) it doesn't feel right. The tutorials and cheat sheets help the committed user get over the hump and start to "think git", but if we didn't bring our biases to the party there wouldn't need to be so many of them. As for front-end interfaces, some of that is an attempt to shoe-horn git into something it isn't, which is dumb. But some of it is just adding visual features that are sometimes nice to have and not easily replicated in a terminal.

dispose13432 10y ago
For example, how often do you use "staging" (as in not git add .) and how efficient is it's use? In my workflow, you need a feature - you develop, you build, it works, you commit. Because think about it like this, you need a feature. You build, it works, then before committing you notice a bug. You fix it. Now you need to commit in two batches, the new feature and the bug. This is the commonly given reason for the add/commit/push workflow. But at some point it's probably faster to either revert, fix bug, then merge with main than to make your staging precise (especially you don't play with staging in your IDE where you can test code as you type)
- peterbonney 10y ago
  I'm not sure I follow your example exactly... What works for me (and I am just one person, and - again - not really a professional developer) is that I think in terms of branches. If I want to add a new feature, step one is to create a new branch. I do whatever I want in there, make 1 commit or 50 commits, push to the repo 1 time or 50 times (note that sometimes I might want to push incomplete work so I can load the branch on multiple machines), test in a realistic but isolated environment, fix whatever bugs come up, and generally work however I want to work. Then I merge (or submit a merge request as the case may be) when I'm satisfied. And then I delete the branch, purge it from the repo, may it never be heard from again. If I got something wrong or want to change the work I just submitted, I start over with a new branch. This is certainly not the only workflow, undoubtedly not the best workflow, and maybe not even a good workflow. And it probably breaks down if your changes are sufficiently complicated (though I avoid this by always working in bite-sized chunks, which I've learned to do the hard way). But it works for me and - as far as anyone on my team has ever told me - my colleagues and collaborators. I can't comment on git's other features or alternative workflows - I rarely or never use them! But what I described is functional, simple, and covers 100% of the cases I've encountered in my (brief) career in software. And I think for 99% of users just getting started with git, if they just pick a simple workflow and don't fight the way git wants them to do it, they'd also find that git is surprisingly easy to learn and to use.
- ciaranm 10y ago
  What? I'd stash the changes I'm working on for the new feature, cut a fresh branch from whatever trunk/master/develop we're using, fix bug, checkout my other branch again, stash pop/apply, and we're back to where we were 10 minutes ago (or 5 days, if that's how long the bug-fix took). Branches are cheap. Stash is cheap. Use them.
- yarrel 10y ago
  I use it frequently. Even if I'm only using add ., I check the staging area before I commit. Reverting wouldn't be faster and wouldn't separate out files that are meant to be committed from those that aren't. It's also harder once you've pushed. So staging is more efficient as well. I used both cvs and subversion for many years. They have their own complexities, but lack git's ability to manage them.

dispose13432 10y ago

For example, how often do you use "staging" (as in not git add .) and how efficient is it's use? In my workflow, you need a feature - you develop, you build, it works, you commit. Because think about it like this, you need a feature. You build, it works, then before committing you notice a bug. You fix it. Now you need to commit in two batches, the new feature and the bug. This is the commonly given reason for the add/commit/push workflow. But at some point it's probably faster to either revert, fix bug, then merge with main than to make your staging precise (especially you don't play with staging in your IDE where you can test code as you type)

peterbonney 10y ago
I'm not sure I follow your example exactly... What works for me (and I am just one person, and - again - not really a professional developer) is that I think in terms of branches. If I want to add a new feature, step one is to create a new branch. I do whatever I want in there, make 1 commit or 50 commits, push to the repo 1 time or 50 times (note that sometimes I might want to push incomplete work so I can load the branch on multiple machines), test in a realistic but isolated environment, fix whatever bugs come up, and generally work however I want to work. Then I merge (or submit a merge request as the case may be) when I'm satisfied. And then I delete the branch, purge it from the repo, may it never be heard from again. If I got something wrong or want to change the work I just submitted, I start over with a new branch. This is certainly not the only workflow, undoubtedly not the best workflow, and maybe not even a good workflow. And it probably breaks down if your changes are sufficiently complicated (though I avoid this by always working in bite-sized chunks, which I've learned to do the hard way). But it works for me and - as far as anyone on my team has ever told me - my colleagues and collaborators. I can't comment on git's other features or alternative workflows - I rarely or never use them! But what I described is functional, simple, and covers 100% of the cases I've encountered in my (brief) career in software. And I think for 99% of users just getting started with git, if they just pick a simple workflow and don't fight the way git wants them to do it, they'd also find that git is surprisingly easy to learn and to use.
ciaranm 10y ago
What? I'd stash the changes I'm working on for the new feature, cut a fresh branch from whatever trunk/master/develop we're using, fix bug, checkout my other branch again, stash pop/apply, and we're back to where we were 10 minutes ago (or 5 days, if that's how long the bug-fix took). Branches are cheap. Stash is cheap. Use them.
yarrel 10y ago
I use it frequently. Even if I'm only using add ., I check the staging area before I commit. Reverting wouldn't be faster and wouldn't separate out files that are meant to be committed from those that aren't. It's also harder once you've pushed. So staging is more efficient as well. I used both cvs and subversion for many years. They have their own complexities, but lack git's ability to manage them.