So you end up committing untested code? (since you did test the whole change, not just part of it). Sounds like a bad idea to me.
https://github.com/garybernhardt/dotfiles/blob/master/bin/ru...
41–50 of 108 posts
So you end up committing untested code? (since you did test the whole change, not just part of it). Sounds like a bad idea to me.
https://github.com/garybernhardt/dotfiles/blob/master/bin/ru...
Site wont load for me. I'm a big fan of "git gui". You can commit individual lines.
Here's another article discussing git add -p: http://blog.tplus1.com/index.php/2008/10/31/break-up-changes... Nice. Too bad I'm on svn. Though I suppose you'd want to be really careful about not creating a commit that's broken, e.g. by overlooking a declaration. Can you easily check whether currently staged changes still compile and/or pass a test?
Earlier quoted context omitted.
All you need to do is type "apt-get install git-core" or "brew install git" and you can try 95% of git out locally. Get a free bitbucket or github account and you can do most of the rest. :) OK, perhaps you are on Windows, then i am not sure if it's that simple.
Step 2: write some code that exercises all git features
"Oh, you're friend was 20 commits behind and did [some stupid] shit that wiped out all commits and GUI tools aren't helping? Here's how to attack it..." which is where my Git knowledge falls apart very quickly.
Regular commiting/pushing/remotes etc are all okay to me, except the bad habits of using "sync" as a commit message when I move from my desktop to my laptop and I don't have wip branch.
OT: I'd love an interactive "Learn Git" webpage where you could learn to use Git with demo scenarios. Something like "Try Ruby" but for git.
All you need to do is type "apt-get install git-core" or "brew install git" and you can try 95% of git out locally. Get a free bitbucket or github account and you can do most of the rest. :) OK, perhaps you are on Windows, then i am not sure if it's that simple.
I'd been using git for a couple months on a project on my own with no problems. I felt comfortable with it. Then I got hired at a company using it.
I wasn't even remotely prepared for the difference (and for how little I actually knew about git: addressing commits, modifying commits to make them more clear to review, moving branches around, etc). I flailed for several weeks (coworkers were always happy to help, but I prefer to try to swim on my own) before the light bulb really went off (and I'm not new to VCS or DVCS, eitherm by any stretch of the imagination).
I don't think you can really learn git until you are working with a group of people, because its not until that point that its strengths and peculiarities really show up. Especially since the UI is so cryptic.
Fwiw, I was a big mercurial fan pre-hiring. I'm now very happy that BitBucket has a git interface (I prefer BB to Github for closed-source, personal projects) as, unless there is a requirement that history not be changed in the repo, I'll be using git moving forward.
Site wont load for me. I'm a big fan of "git gui". You can commit individual lines.
Here's another article discussing git add -p: http://blog.tplus1.com/index.php/2008/10/31/break-up-changes... Nice. Too bad I'm on svn. Though I suppose you'd want to be really careful about not creating a commit that's broken, e.g. by overlooking a declaration. Can you easily check whether currently staged changes still compile and/or pass a test?
It's an absolutely fantastic (though dangerous) command. It's also a good illustration of how git doesn't commit anything you don't want to see committed (eg, "git commit" doesn't do anything if you haven't done "git add" before, letting you prepare your commits more carefully than with other VCSs).
It's an absolutely fantastic (though dangerous) command. It's also a good illustration of how git doesn't commit anything you don't want to see committed (eg, "git commit" doesn't do anything if you haven't done "git add" before, letting you prepare your commits more carefully than with other VCSs).
You really need to test the version of the code you are going to commit. See the comment about using "git stash" elsewhere in this thread.
That's what this is for. And it works pretty well. Any other helper for this task would look pretty much the same -- the goal after all is to translate your local hacks into a clean commit.