You don't have to create a branch before you write some code. Write the code, and if you think it should go on a different branch, type "git checkout -b 'branchname'". But if you don't want to, you don't have to! work on master for all anyone cares. Branches just help you! IF they are too hard, don't use them.
Branches were so problematic in subversion that nobody did them. In git, if you want to, then do it.
If you accidently check in something, just "git rm" it. You have this extra staging area.
If you are finding there is something problematic with your workflow, take the time to look up how to do it, and you'll find that the fix is a command away. You should never be copying/pasting stuff back into your IDE. If you are, you're doing it wrong.
I agree with you, and would like to add to it. The parent said git gets in the way ... I couldn't disagree more with that. More than any other version control software, git stays out of my way and my workflow until I need it. Rename a file? No big deal, take care of it before I commit, for now rename it and keep working. Need these changes to go on a branch? As you said, "git checkout -b <branchname>" and BAM! I'm on a branch (most unlike SVN branching). Contrast that with something like perforce (and I know the parent was comparing to SVN) where it intrudes into my workflow whether I want it to or not. p4 edit? pshaw! I have been using the "git p4" module for a few years now in my corporate p4 environment. It ain't native git, but it's better than p4 IMO.
EDIT: Come on. If you disagree with me, don't downvote, reply so you can contribute to the conversation. Coward.
I've just started using git recently and have completely fallen in love with its power and flexibility.
But as someone just starting out, I can relate to how demanding git can _seem_ to a beginner. Say I have some refactoring ideas floating around in my head. I could either begin accommodating for these changes in git (namely branching, perhaps also chunking my edits into commits) or start coding and go back and handle commit isolation and branching later.
For me it can seem like git is getting in the way if I select the former method, and that the latter is just messy and cumbersome. But the more and more time I invest into the tool, both my efficiency and the cleanliness of the code base increases. Persevering through the higher learning curve (which exists probably due to a minimal (bad?) interface wrapping a set of concepts that can best be understood visually à la Dwarf Fortress) appears to be a worthwhile investment.
The nice thing about git, is there is a ton of possible workflows depending on how much you care, how knowledgeable you are about git, level of effort willing to put forth, etc.
I've found my workflow in git has changed over the years... just like my coding style does.
You don't have to create a branch before you write some code. Write the code, and if you think it should go on a different branch, type "git checkout -b 'branchname'". But if you don't want to, you don't have to! work on master for all anyone cares. Branches just help you! IF they are too hard, don't use them.
Branches were so problematic in subversion that nobody did them. In git, if you want to, then do it.
If you accidently check in something, just "git rm" it. You have this extra staging area.
If you are finding there is something problematic with your workflow, take the time to look up how to do it, and you'll find that the fix is a command away. You should never be copying/pasting stuff back into your IDE. If you are, you're doing it wrong.
http://gitref.org/ is pretty good if you get stuck.