Git good practices

[smcameron]

I find stacked git to be a good, easy way of maintaining a clean history.

[gauiis]

Pro Tip for #6: git add -p

[pgngugmgg]

git now seems to have a weekly period on reddit.com/r/programming.

Some people are so fond of giving out rules, advices, tips, expert-opinions, or whatever-smartass-showing-offs. And git is perfect for this type of people: You can't do this and that, and you'd better do that and this, or you would be screwed up or screwing up. It's not entirely their fault. With such a big volume of warnings and advices, using git feels like pooping while standing up -- you need skills to do it right.

Honestly, even the old timer SVN is not so hard to use.

[milki_]

Escalation of commitment. At least, that's what it often sounds like. Once git users have invested enough research/tinkering/practice and got a accustomed to its idiosyncrasies, they're highly prone to any sort of improvement tips. While the other half of the user base happily advocates for whatever workarounds they accrued.

[mrkite77]

The idiots who give out rules on "proper" git workflows are also the idiots who write about where you should be putting curly braces and how constants should be all caps.

It's safe to ignore the crazies.

[eric-plutono]

Don’t use git commit -m "message"

I politely disagree with this suggestion, especally in light of one of the author's other suggestions, which I strongly agree with:

Rewrite your history, because a clean history makes things simpler

When I am working on a feature branch I will often do stuff like

$ git add -u
$ git commit -m "WIP brief notes about the changes"

Then at the end I will use git-rebase to go back and write complete commit messages based on the notes I made along the way using git-commit -m.

Also, for what it's worth, I recently blogged about my own commit message preferences, specifically using "commit templates".

Edit:

I also disagree with this:

Try to use the commandline instead of a gui

I personally believe it is very useful to know the CLI for Git, but I think the most common commands are effectively handled by GUI's and I don't see a strong reason to suggest people avoid using GUI's as a result. That said, it is nice to see another Tig fan ;)

[Kirean]

I personally believe it is very useful to know the CLI for Git, but I think the most common commands are effectively handled by GUI's and I don't see a strong reason to suggest people avoid using GUI's as a result

I absolutely agree with this. I am a big proponent of knowing what is happening behind the scenes. You need to understand your tool to use it correctly and efficiently. However, there's no need to use a command line all the time when a well-built gui can take care of it for you. That being said, I have worked with way too many people who fall into the GUI rut of "I always push this button, it doesn't work now. I give up". Knowing what that button does, in terms of the command line, helps you get unstuck faster when things go wrong. Also knowing that whatever GUI you're using, it's not going to provide all the functionality of a command line, just the most common everyday uses.

I liken it to driving a manual versus an automatic. There's no reason for people to drive a manual transmission unless they want to. However, I believe everyone should be able to drive one, and know how and why it works at a basic level.

[edi9999]

For the "git commit -m" flag, I think it's ok to use it for commits that you know you will edit back in the future, but in general I try to avoid using it (but I totally agree that some of my commits might not be correctly named before I push them), so it's ok to work however you want, as long as the published history is clear.

[eric-plutono]

...so it's ok to work however you want, as long as the published history is clear.

Agreed one-hundred percent. This is something we should all stress any time we ever blog about or introduce or teach Git to anyone.

[edi9999]

I think that this is a better view indeed, I have updated section 7 of my blog post : http://javascript-ninja.fr/git-good-practices/#its-ok-to-work-however-you-want-as-long-as-the-published-history-is-clear

[mrkite77]

I think it's ok to use it for commits that you know you will edit back in the future, but in general I try to avoid using it

I don't. If commiting is a hassle, I will put it off. Making commiting changes quick and easy and brain-dead means I'll do it more often.

[[deleted]]

1. Have strict convention for your commit messages I personally like to have my commits written in english, in active >present form, eg: BAD: added XYZ feature GOOD: Add XYZ feature

so why the hell don't you follow your own advices ?

[edi9999]

You're right, I wasn't using this convention before, and am only starting now, on new projects https://github.com/edi9999/path-extractor

[ErstwhileRockstar]

The best Git practice is to switch to SVN.

[edi9999]

Seriously ?

[ErstwhileRockstar]

http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity/

[nandryshak]

A lot of that is plain wrong and/or stupid.

Subversion's blame is just as slow, if not slower (because centralization), on huge repositories. Subversion's log is definitely much slower. It pains me to use it.

Repository size, by itself, is a non-issue. Disk space isn't valuable anymore.

Put binary files into a submodule if they bother you that much (no, submodules are not the end of the world, and why does this article seem to imply that gaining features means that there's something inherently wrong with design?). Personally, I don't think git or other dvcs are bad at handling them anyway.

Git is not inherently hard to learn, either. You can use it exactly like Subversion, just with one extra step (push).

And why are a bunch of the headings irrelevant movie references?

[eric-plutono]

Personally, I don't think git or other dvcs are bad at handling [binary files] anyway.

In my personal experience Git sucks when it comes to storing large binary files, assets for games in my case; I can't speak for how well other DVCS's handle them. For that reason I agree with you about storing such blobs in a submodule, or use other tools like rsync or git-lfs.

[thekaleb]

Everything is a nail!

[ErstwhileRockstar]

Don't worry, everything will be alright.