DEV Community 👩‍💻👨‍💻

Cover image for 10+ things I always setup in git when I prepare a new environment
Shinji Nakamatsu
Shinji Nakamatsu

Posted on • Updated on

10+ things I always setup in git when I prepare a new environment

When you buy a car or a bicycle, you first adjust the seat position and saddle height to suit your body size. It is the same with git configuration.

In this article, I will share the git setup I use all the time.

User name & Mail address

git config --global user.name "<name>" && \
git config --global user.email "<email>"
Enter fullscreen mode Exit fullscreen mode
  • Replace <name> with my name and <email> with my mail address.

Alias for existing command

git config --global alias.co checkout
git config --global alias.st status
git config --global alias.br branch
Enter fullscreen mode Exit fullscreen mode

Global ignore setting

git config --global core.excludesfile ~/.gitignore_global
Enter fullscreen mode Exit fullscreen mode
  • This allows you to put your own specific ignore settings in ~/.gitignore_global in addition to the .gitignore for each project, which will be applied to all git operations across all projects.

Push only the branch you are now working on

git config --global push.default simple
Enter fullscreen mode Exit fullscreen mode

Make --rebase the default behavior during git pull

git config --global pull.rebase true
Enter fullscreen mode Exit fullscreen mode
  • This prevents unintentional creation of a merge commit if the branch being pulled has been modified locally.

Make --prune the default behavior during git fetch

git config --global fetch.prune true
Enter fullscreen mode Exit fullscreen mode
  • This will remove local branches that were deleted remotely when git fetch or git pull was performed.

Set the width of indentation for tab characters

git config --global core.pager 'less -x4'
Enter fullscreen mode Exit fullscreen mode
  • In this example, the pager (less command) option specifies tab indent width as 4

Use nvim as the editor to be used when committing

git config --global core.editor 'nvim'
Enter fullscreen mode Exit fullscreen mode
  • I use several different text editors for different purposes, but I prefer to use nvim with git commit.

Do not fast-forward when merging

git config --global --add merge.ff false
git config --global --add pull.ff only
Enter fullscreen mode Exit fullscreen mode
  • Fast-forward merging makes it difficult to follow the history of work on a branch. Therefore, avoid unintentional fast-forwards when merging.
  • However, fast-forwarding is not a problem for git pull cases in most cases 1, so we enforce fast-forwarding in the case of pulls.
  • See also: gitのmerge --no-ff のススメ - Qiita

Output line numbers in the result of git grep

git config --global grep.lineNumber true
Enter fullscreen mode Exit fullscreen mode

Visualize differences in whitespace (including newline codes)

git config diff.wsErrorHighlight all
Enter fullscreen mode Exit fullscreen mode

EDIT: 2022-07-31

dotfile

As mentioned in the comments, these are stored in .gitconfig. And I have added these settings to the dotfiles repository.

https://github.com/snaka/my-dotfiles/blob/master/.gitconfig

Thanks to all who commented.


See also


  1. In my experience, this happens when you are temporarily changing code while reviewing a PullRequest created by someone else in your local environment. In that case, fast-forward is better because local changes are gathered at the top of the history, making it easier to work with when you finally undo the changes. 

Top comments (31)

Collapse
tdwright profile image
Tom Wright

Great tips. Feels like this could be the start of a script. In fact, I can imagine an open source CLI tool for setting up Git just right on new environments, perhaps using a user-specific config file stored online...

Collapse
citizen428 profile image
Michael Kohl

You can put all of that (and much more) in your ~/.gitconfig. Here’s mine from my dotfiles repository:

github.com/citizen428/dotfiles/blo...

I also have a .gitattributes and global .gitignore I manage there.

Collapse
snaka profile image
Shinji Nakamatsu Author

Your dotfile is also helpful. Thanks for sharing ✨

Collapse
anasrin profile image
anasrin

The essential thing for me was add gpg sign and signing key

Collapse
francoislp profile image
François

Hey :) Great post, thanks for sharing!

How would you deal with 2 git emails on the same laptop?
one for github (perso) and one for work (pro)

The best would be to default to the email perso (and the associated GPG key), and when working from ~/Projects, always use the work email
Not sure if it is feasible ^^

Collapse
snaka profile image
Shinji Nakamatsu Author

Perhaps you can.
I wrote an article about it, please check it out.

dev.to/snaka/use-a-different-git-c...

Collapse
tallesl profile image
Talles L

Nice tips!

However I was surprised to see "Do not fast-forward when merging" with the reason of making it "difficult to follow the history".

My personal experience is the exact opposite, having multiple automatic "Merge branch..." commits makes the commit history incredibly polluted.

Collapse
snaka profile image
Shinji Nakamatsu Author

I understand your surprise, as I have seen several different organizations managing branches with different policies.

There isn't enough in this comment section to discuss that, so I will post a separate entry after I get more thoughts on it.

Collapse
joolsmcfly profile image
Julien Dephix

Do you always use cli commands or do you sometimes commit/push/pull/delete branches from your IDE?

Collapse
snaka profile image
Shinji Nakamatsu Author • Edited on

I use tig and git CLI depends on the situation.

github.com/jonas/tig

I often use tig to see logs and diffs, or commands with a specific commit ID, such as git cherry-pick <commit-id> or git rebase -i <commit-id>.

On the other hand, I use the git CLI for risky commands such as git reset, and for tasks that are faster with shell completion such as git checkout <branch-name>.

Collapse
joolsmcfly profile image
Julien Dephix

I see. I’ll check tig later out of curiosity!

I prefer using my IDE for most commands (I make sure to know what’s going on behind the scenes though) as I find faster (Ctrl+K to open commit window, type message, Ctrl+Shift+K to commit and push).

Collapse
suckup_de profile image
Lars Moelleken

To setup my environment for Linux or Windows I usually use my dotfiles : github.com/voku/dotfiles/blob/mast...

Collapse
snaka profile image
Shinji Nakamatsu Author • Edited on

Thanks for the link to your dotfiles! It is very helpful. 👍

Collapse
suckup_de profile image
Lars Moelleken

Good if you find something useful there. 😊

Collapse
buddhadebchhetri profile image
Buddhadeb Chhetri

Thanks for the tips this is really helpful.

Collapse
dominik90 profile image
Dominik Bartsch

Great tips, thank you!

Collapse
ravavyr profile image
Ravavyr

Neat...I install github desktop and click buttons.

Good article, it has its uses if you must use command line :)

Collapse
wjplatformer profile image
Wj • Edited on

git --checkout -b 'this post' 🔖✅

Collapse
proismailshah profile image
ismail shah

Great tips will gonna use in my next project.....

Collapse
peterwitham profile image
Peter Witham

Some great suggestions in this list that I never thought about before, especially the global ignore outside of a project.
Thanks for sharing.

Collapse
devsimc profile image
simc dev CSM®

You also need to take care about this mistakes.
cmsinstallation.blogspot.com/2021/...

Collapse
snaka profile image
Shinji Nakamatsu Author

Thanks for the link to a helpful article 👍

Collapse
piyushnags profile image
Piyush

I read that git push isn't supported fromthe CLI due to security reasons. Is there a nice way to get around that (other than using Github Desktop)?

Collapse
nstvnsn profile image
Nathan Stevenson • Edited on

I use git push from the CLI all the time. I think you may have read that where it talks about setting up ssh keys.

If you are using your IDE or the Desktop UI for git, you are likely signed in to your github account through them. No issues.

With CLI, you need to set up SSH for authenticating your pushes from the CLI:

docs.github.com/en/authentication/...

Collapse
piyushnags profile image
Piyush

Thank you, after switching to SSH it works just fine

Thread Thread
nstvnsn profile image
Nathan Stevenson

No problem! Glad you got it working.

Collapse
snaka profile image
Shinji Nakamatsu Author • Edited on

Sorry, I didn't catch what you meant by "git push isn't supported formthe CLI due to security reasons".
Could you please add what you mean by that?

Collapse
piyushnags profile image
Piyush • Edited on

Yep my bad, I wasn't clear enough and I also realized I didn't read the documentation properly :(. I was trying to push some changes to my repo through the terminal. However, I was trying to push via HTTPS. According to GitHub, it no longer supports authenticating through HTTPS for the CLI (I had mistakenly assumed that pushing from CLI in all cases was no longer supported, which is pretty silly in hindsight). After I switched to SSH as suggested by Nathan (from the below response), it works just fine. Side note: great tips now that I can use CLI again!

Edit: If you're curious, you get a 'fatal authentication' error if you try to push via HTTPS. Apparently, they stopped this since August 2021.

Thread Thread
snaka profile image
Shinji Nakamatsu Author

Ah, it was clear to me what you said.
I'm pleased that your problem was resolved as a result.

Thread Thread
jasperhorn profile image
JasperHorn • Edited on

git push, from the command line, to GitHub, over https does work. It's just that you don't use your password to login. Instead, you use a token, which you first need to generate in your settings somewhere.

Thread Thread
snaka profile image
Shinji Nakamatsu Author • Edited on

Thank you for the additional information.
As you mentioned, it is possible to push via HTTPS with the git command by using a Personal access token (PAT).

Here is a link to the GitHub documentation for reference.

docs.github.com/en/authentication/...

🌚 Browsing with dark mode makes you a better developer.

It's a scientific fact.