DEV Community

Cover image for Learn Git good practices!

Learn Git good practices!

Bart Zalewski on September 17, 2020

How well do you know GIT? Learning git is one of the most important things that programmers have to know. You need to know how what it is, how to ...
Collapse
 
stephenwhitmore profile image
Stephen Whitmore • Edited

For point #2 good commit messages I started writing why I made the change rather than what the change is at the recommendation of a coworker. I've found it naturally provides a more meaningful commit history and kinda tells a story.

"Updated model to include license number" becomes "License number is tied to registration".

You already know I added a property by looking at the code change so comments like the former are redundant.

Collapse
 
primozkerin profile image
Primož Kerin

I would have no idea what you did based on your "License number is tied to registration".
You can do something like: "Update model to include license number" and then write your "why" in the description part of commit message. Just my 5 cents :)

Collapse
 
stephenwhitmore profile image
Stephen Whitmore

You make a good point - that wasn't the best example. Maybe something like "Added license number to model because it's tied to registration" would be better. I've found that generally putting reasoning behind the change helps a lot for the code review process and for going through old commits. I see lots of commit messages that are like "Added x" or "Removed y". It drives me nuts because I have to investigate further if I'm looking back through old commits when investigating something for example. Messages that give the reasoning behind the change saves time for things like that because you can hone in on the thing you're actually looking for or if you're doing a review it gives a clearer picture if you're not as familiar with the issue as the one who worked on it.

Collapse
 
bloodgain profile image
Cliff • Edited

Let me give #2 for good commit messages a million upvotes. It's worthy of its own post. In fact, I recommend everybody read a good "how to write good commit messages" post, such as this one:

chris.beams.io/posts/git-commit/

I will note, ironically, that your "good" example ends in a period. It's generally considered good form to not end your commit subject line with punctuation. But you should use proper punctuation in the body of the commit message. Yeah, we're a weird bunch. As such, I'm usually pretty forgiving about whether the first letter is capitalized, too, and just recommend that everyone follow the style of the project, which is good programming advice in general.

Collapse
 
pierrelegall profile image
Pierre Le Gall

I don't think creating aliases is a good practice. Creating yours makes your Git commands obscur to others (or worst, to you). Do not forget, your shell interface can autocomplete things.

Nice recap tho'! ;)

Collapse
 
zanothis profile image
zanothis

On the rare occasions that I've had someone looking at my screen and curious about how I just did something with git, I've been able to explain that I have an alias for it. I can then pull up my aliases to explain the alias they just saw.

Aliases are powerful tools that can give you the power to do more with fewer keystrokes. If there's an alias that I can't remember, I have an alias that lists my aliases (this is still generally faster than looking at the documentation). When I switch branches, it automatically fetches.

They also save valuable space in my head so I don't have to memorize the formatting options for git log --pretty. The flag name there may even be wrong, I don't know and I'll only care the next time I need to format the output of git log.

TL;DR

Aliases are there to increase my productivity and be as memorable as possible, not to be clear.

Collapse
 
pierrelegall profile image
Pierre Le Gall

I understand your point of view, but it's not mine as explained in my previous post.

I prefer to have a gitconfig without alias and to use a « more graphical » Git interface. I use the Git CLI and magit (which is full of default keybindings and integrated into my code editor of choice). This allows me to avoid black magic Git aliases.

If you want to have a pretty git log, the best way is to config your log output like this:

[log]
    abbrevCommit = true
    decorate = true
    date = relative

You can found my gitconfig here, certified alias-free ;p

Thread Thread
 
zanothis profile image
zanothis

I'll give it a look, I'm sure I'll see some settings that I like. I'm probably not going to give up using aliases since I've yet to find a more graphical interface that I like better than the CLI. But if I can find some defaults that allow me to remove an alias or two, it's one less alias to have to worry about.

Collapse
 
bloodgain profile image
Cliff • Edited

No, and in shared repositories I own, I disable the ability to force push. I call it the "No Jedi Rule".

The reason not to allow force push in the general case is that it allows someone to rewrite history. That should be discouraged. It is occasionally necessary to do, such as when something is added to a repo that could cause a security concern, but it should be fixed with the assistance of the repository owner or a designated administrator. Changing history will often invalidate downstream repositories, and allowing force push in general would allow these downstream repos to push the "bad" history back to the shared repo.

Collapse
 
catriel profile image
Catriel Lopez • Edited

For #2 I like to refer to this post:

As for #4, its important to know about .gitignore, not just for web development.

Nice post!

Collapse
 
pierrelegall profile image
Pierre Le Gall

git add -p, best advice, few of us really use it.

However, the Git CLI is not the best interface to seriously use it :p

Collapse
 
derekcrosson profile image
Derek Crosson • Edited

For point two I prefer a non-capitalised subject and scope if possible. An example of my commit would be:

refactor(login view): add mobile responsiveness

Collapse
 
pierrelegall profile image
Pierre Le Gall
  1. Sadly, it's very hard to have the same opinion/habit on this point.
  2. It's more a project guideline than a Git good practice :o