If you're in danger of getting fired over a commit mistake, you have more and bigger problems than this article can fix.

These are good tips, nonetheless.

Out of curiosity, do a lot of people use CLI git?

I personally am much happier losing a little functionality (and all these fancy flags) for a much clearer visual interface - I'm using GitExtensions btw.

Am I alone on this?

A warning about the ours and theirs commands: when you're rebasing, they will do the exact opposite what most people await them to do (thanks to git rebase's implementation).

From the git rebase man-page, --merge: Note that a rebase merge works by replaying each commit from the working branch on top of the <upstream> branch. Because of this, when a merge conflict happens, the side reported as ours is the so-far rebased series, starting with <upstream>, and theirs is the working branch. In other words, the sides are swapped.

https://www.kernel.org/pub/software/scm/git/docs/git-rebase....

Also, any code that isn't pushed to a remote doesn't exist. Or, it won't when your hard drive unexpectedly fails and your feature branch disappears. =)

This command has a mistake in it:

  ours   = "!f() { git commit --ours $@ && git add $@; }; f"

  ours   = "!f() { git checkout --ours $@ && git add $@; }; f"

"...sometimes php developers commit configuration files..."

needless jab, imo.

With regards to merging, I prefer using a merge tool such as Meld. Whenever you're in a merge conflict, just run git mergetool.

Meld is pretty easy to learn as long as you know to use shift-click to delete a chunk and ctrl-click to copy a chunk instead of replacing.

Git power usage looks dangerously like accounting.

I realize that this post is targeted more towards advanced git users but it would be immensely helpful if you could add 1-2 examples to the every section (you only have some for the first section)

These are great tips. And so is the other post about Git Koans posted here today.

I'm a bit of a git fan and while such tips pique my curiosity and delight the git geek in me, is it actually wise to use these on a day to day basis at your job? Doesn't the argument about 'clever code v/s clear code' apply to highly configurable tools like git? While pairing with others or even using a common dev box, I like to use plain vanilla CLI git without intricate aliases, without intelligent git hooks, or other fancy extensions as far as possible.

Snapshot stack? Huh.

git checkout -b

seems a lot simpler.

we're also using a small script[1] that prevents committing debug statements by mistake. We put it as a pre-commit hook and also as a standalone check on our CI. It saved us from embarrassing mistakes in production several times...

[1]http://stackoverflow.com/a/14738093/305019

> Get everything you can into git hooks

This is a great idea, and it's one that my company provides: https://circleci.com. You can run standard tests, but also linters and whatever you want to increase your code quality. Users report higher productivity, and shipping code faster!

I don't understand the part about .gitignore not working for passwords.php: because that’s committed too, so then you risk someone forgetting about their valid edits of the file later.

What's the reasoning behind the hack "!f(){}; f" getting shell arguments to work properly?

Does anyone here know of a good 3-way merge tool for Git that's available on OSX?

What is the difference between minimal and patience for git diff?

Seriously, command line for this sort of stuff? Also being stressed over source control when it is not deleting something permanently? Really?