Learn Git good practices!

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 use it in your project, what you should do, and what you should not do.

In this post, I prepared eight things that you should know. These are not all of the best practices that you should know, but these are the ones that will make you a better developer instantly.

The eight GIT best practices that you should know are:

1. Make clean commits

Don't do too much on one commit. If you fixed one bug related to one thing, and then another bug related to another thing pops out, don't include it in your commit.

Fix one bug, commit, fix the second bug, commit, and so on (only if the bugs are not related to each other).

2. Good commit messages

Capitalized, meaningful commits in the present tense is the best commit message practice. It's good both for others, such as visitors, developers, recruiters, clients, and also for you.

You could stand out from other developers only by improving your commit messages game.

Let's say that you added responsiveness to your project, which is a website.

Bad:

added responsive mobile version

Good:

Add responsiveness to the website.

3. Commit often

Rather than making the first commit your project's last commit, create small commits every meaningful update you make.

That doesn't mean your every new line of code needs to be committed singly. Here's an example:

Bad:

body {};

Good:

body { margin: 0; width: 100vw; font-size: 1rem; };

4. Don't commit keys

If you need to commit secret API keys or anything that people shouldn't be able to see on your GitHub project's repository, you can use environment variables.

Within a React project, install a dotenv package and create a ".env" file in the root directory. Then, you can place there a key and its value, like:

REACT_APP_YOUTUBE_API=xxxxxxxxxxxxxxxx;

Then in your project, you can use process.env.REACT_APP_YOUTUBE_API to get that from your local file and no one will be able to see that key when you commit the file.

5. Use branches

Branches can allow you to have multiple versions of your code in a single repository.

A simple example in which I used branches on my portfolio website's project:

In the repository, I have three branches: master, md-blog, and no-blog, which have different codes depending on their name. The Master branch is the version with a Contentful blog, md-blog stands for Markdown blog, and no-blog is nothing else than a no blog version of the portfolio.

By having them, when I want to change something minor on all of them, I simply head on one of them, and after doing the commit I merge changes with the rest of the branches.

6. Check security alerts

If you want to make sure your app has no vulnerabilities, you can use the GitHub's Data services to receive alerts when one or more of your project's dependencies will need to be fixed automatically.

In that case, I would suggest you visiting regularly GitHub and checking the notifications. If there will be something like: "Bump x from 1.0.0 to 1.0.1, you need to click on that and merge the automatic changes.

7. Create aliases

Improve your productivity by using Git aliases. The most common ones are:

$ git config --global alias.co checkout

$ git config --global alias.br branch

$ git config --global alias.ci commit

$ git config --global alias.st status

You can always create aliases on your own to make your git flow more efficient. A lot of people share their settings online, so if you will find something interesting, you can use that in your terminal as well!

8. Small cheat sheet

1. Adds a file to your previous commit

$ git commit --amend

2. Rather than staging everything, you can stage only parts of a changed file

$ git add .

$ git add -p

3. Check file changes

$ git diff --cached

That's it!

Thank you so much, and have a productive day!

Comments

[Stephen Whitmore]

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.

[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 :)

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

[Catriel Lopez]

For #2 I like to refer to this post:

How to write a good commit message

Chrissie ・ Jul 30 ・ 2 min read

#git #codenewbie #beginners #github

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

Nice post!

[Derek Crosson]

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

[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

[Cliff]

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.

[Cliff]

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.

[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'! ;)

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

[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

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

[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