
Git tips to stop you getting fired - philjackson
http://blog.apiaxle.com/post/handy-git-tips-to-stop-you-getting-fired/
======
Bobby_Tables
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.

~~~
malkia
There is a bigger chance of getting fired for ordering 10x the amount of food
for the team, while they are crunching...

------
temp453463343
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?

~~~
Cyranix
Not alone, certainly, but almost certainly in the minority. I don't think I've
met anyone in person (in five professional years, granted) who uses a GUI for
anything Git-related except complex merges or history visualization, both on
rare occasion.

Not sure why your perfectly reasonable question is getting downvoted...

~~~
zem
i mostly use the cli, but i use a gui (git-cola) for interactively committing
only part of the current diff. it's _way_ better than git add --interactive.
also gitk is nicer than tig, though tig is easier to use when sshed into
another server.

~~~
adimitrov
Incremental (interactive) commits are probably best done from within your
editor. I use fugitive [1] for Vim, there's magit [2] for Emacs, and probably
a plugin for your favorite IDE, or ST2.

[1] <https://github.com/tpope/vim-fugitive/tpope/vim-fugitive>

[2] <http://www.emacswiki.org/emacs/Magit>

~~~
zem
what does fugitive do for interactive commits that beats git-cola? i love vim
for single-file things, but once it comes to a global project view i usually
prefer to use another tool.

~~~
adimitrov
I have never use git-cola, so I can't compare, but for an overview of
fugitive's features, you should probably look into the Vimcasts on that
subject. There's overall five videos, this one is the first:

[http://vimcasts.org/episodes/fugitive-vim---a-complement-
to-...](http://vimcasts.org/episodes/fugitive-vim---a-complement-to-command-
line-git/)

------
Aga
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....](https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html)

------
c-oreills
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. =)

~~~
gte910h
You should be using file backup on any system with code on it. It is so cheap
to do this today, it is a no brainer. Apple Time Capsule, Crashplan Pro, etc.

~~~
nathan_long
The only non-replacable thing on my development machine is the code. It makes
more sense to me to always push my feature branches up to the server, which is
backed up, than for each dev machine to be backed up separately.

~~~
Davertron
If you rebase a lot, then you want to avoid pushing code constantly until you
get it where you want it.

~~~
jimktrains2
One of the many reasons not to rebase code that's been pushed already.

~~~
Davertron
As far as I know there's only one reason not to rebase code that's been
pushed.

My point was that pushing constantly as a backup mechanism isn't an option if
you intend to rebase frequently (unless you're the only developer on the
project).

------
darrickwiebe
This command has a mistake in it:

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

it should be

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

~~~
philjackson
Thanks, I've used an alias for checkout, "co", which I wrongly expanded when I
wrote up the article. I've corrected it. Proofreading is another way not to
get fired.

~~~
joe8756438
Has anyone ever gotten fired for making a git or other version control
"mistake?"

<https://news.ycombinator.com/item?id=5513353>

~~~
joelhooks
Most certainly. I've witnessed it. It was a really bad mistake though.

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

needless jab, imo.

~~~
nthj
yes. This is the first thing I fix on most Rails projects I inherit. Hardly
exclusive to PHP.

~~~
mostlystatic
Oh dear, you aren't supposed to commit configuration files? Is this a security
thing? What's the proper way to distribute config files to to the server and
other developers?

"sometimes php developers commit configuration files and things that are used
in production where they shouldn’t be."

Not sure if I'm parsing this correctly. Should the files not be in production
or should they not be committed? Is this just about overwriting the
development configuration in the config file?

~~~
philjackson
An example scenario might play out thusly: Fred checks in the production
configuration credentials (lets say mysql configuration for this example) in a
file called passwords.php. Senior developer Bob Van Gogh checks out the
project but needs to connect to his local mysql instance to develop. He edits
the configuration file and hacks away on his feature. Somewhere along the way
he accidentally commits passwords.php with his changes. Eventually his code is
deployed and suddenly the app servers can't connect to the database. Bob's no
good at football but he's a good developer and now thanks to that accident his
reputation is tarnished beyond the football pitch too.

Configuration like that should be managed by something that isn't susceptible
to these accidental changes.

As you mention it, security is an issue too. The fewer people who know the
passwords to anything the better and the more you can keep the passwords from
going over the wire the better.

~~~
mostlystatic
Cool, thanks for the explanation. I usually have the development config in the
repo and the deployment script overwrites it on the server.

~~~
prodigal_erik
That's better than the converse (default is prod, yikes!) but there's a risk
of a prod server using the dev config, which might appear to work unless your
dev environment is firewalled off. I prefer having an invalid or unusable
config checked in, so the system doesn't even come up until I deploy the
config I intend to use over it.

------
rav
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.

------
guard-of-terra
Git power usage looks dangerously like accounting.

~~~
jeltz
Not all that complicated and follows a simple set of rules?

------
susi22
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)

------
ultimoo
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.

~~~
charlieflowers
What post about Git Koans? I did a google search, but nothing came up.

------
yxhuvud
Snapshot stack? Huh.

git checkout -b

seems a lot simpler.

~~~
bumeye
Simpler indeed. That's actually what stash does internally.

I usually don't make a separate branch, but just commit it in the current
branch. Then you can rebase or amend later. You never need 'snapshot' if you
know rebase -i.

~~~
just2n
You can also just `git reset HEAD~1` if you want to have your index reflect
the changes rather than just working on top of an empty index in a new commit.
My workflow is a --no-verify commit on the branch, then when I come back, just
reset to the previous commit and continue.

This is pretty much identical to stashing, though I prefer it since it means
the part of git I use is smaller.

------
gingerlime
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>

------
pbiggar
> 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!

~~~
philjackson
That's a nice, solid feeling product. I'm going to check it out properly soon.

~~~
pbiggar
Awesome! Feel free to ask any questions.

------
tterrace
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_.

~~~
philjackson
Ah, I've just tried this locally. I was sure an edited, already checked in
file would remain 'hidden' if in gitignore. My mistake, will update the
article.

~~~
tterrace
Gotcha, I love those "them and us" commands, thanks!

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

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

~~~
Aga
KDiff3 has worked nice for me and it seems to be availabe for OS X too:
<http://kdiff3.sourceforge.net/>

(however I have not tested it on an OS X)

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

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

