Let's Get Started with Git!
So, you're ready to dive into the world of Git? Excellent choice! Git is like your trusty assistant, keeping your project organized while you and your team work together seamlessly.
We'll be covering the following topics:
Let's dig in!
Installing Git
First things first, let's get Git installed on your machine. Head over to the official Git website and grab the latest version.
MacOS:
If you're on a Mac, you probably already have Git installed, but just in case, here's how you can do it with brew.
brew update # Ensure everything's up to date
brew install git # Install Git
Linux (Debian/Ubuntu/WSL on Windows)
For Linux users, installing Git is straightforward. Just run:
apt-get install git
For other Linux distributions, refer to the documentation.
Verifying the Installation
Once Git is installed, let's double-check to make sure it's working. Open your terminal and type:
git version # Check Git's version
If you see something like this, you're good to go!
Configuring Git
Now that Git is on your machine, let's configure it to suit your preferences.
Configure your identity
Let's start by telling Git who you are:
git config --global user.name "Your Name"
git config --global user.email "your-email@example.com"
git config --global user.username "yourusername"
Choosing your text editor
Next, let's set your preferred text editor for Git to use:
git config --global core.editor "your-editor"
I like to use zed for this given its speed, to use zed you can run:
git config --global core.editor "zed"
For VSCode you can run:
git config --global core.editor "code -w"
Signing your commits
As you've become adept at navigating Git, you may now be considering enhancing your workflow by signing your commits for added security and authenticity. Traditionally, Git has relied on GPG (GNU Privacy Guard) for commit signing. However, configuring and understanding GPG can present challenges, especially for those new to the tool.
Thankfully, there's a new solution. OpenSSH has introduced a feature allowing the signing of data using existing SSH keys and Git has seamlessly integrated this capability as an alternative to GPG.
You can take a look at the official Github documentation here
Signing Git Commits with SSH
(Make sure to remove the --global parameter if you only want to do this for a specific repository)
First we need to switch the signature format to SSH:
git config --global gpg.format ssh
You also need to tell Git which SSH key to use for signing. You can just use your public key for user.signingKey.
git config --global user.signingKey ~/.ssh/id_rsa.pub
You can now create signed commits:
git commit -S -m 'Create a signed commit'
If you want to force all future commits to be signed you need to add:
git config --global commit.gpgsign true
If you're using Github make sure you have added your Public Key to both "Authentication Keys" and "Signing Keys" in the settings page.
Verifying the signatures
To show and validate the signatures, you can run git log with the --show-signature parameter.
git log --show-signature --oneline
Sometimes, as you embark on signing your commits, you may encounter an error message within the commit information. As is the case on this scenario with the error:
error: gpg.ssh.allowedSignersFile needs to be configured and exist for ssh signature verification
This error stems from Git's lack of knowledge regarding which SSH keys to trust for signature verification. Git relies on a predefined list of trusted keys known as the "allowed signers file," which operates similarly to the "authorized keys file" utilized by SSH.
Creating the Allowed Signers File
To address this issue, begin by creating a file on your system (e.g., ~/.config/git/allowed_signers) to manage trusted signing keys. Each entry in this file corresponds to an email address used in committing, followed by the associated public key. For instance, you can do so running:
# Create allowed_signers file
echo "$(git config user.email) $(cat ~/.ssh/id_rsa.pub)" > ~/.config/git/allowed_signers
# Add allowedSignersFile configuration
git config --global gpg.ssh.allowedSignersFile "$HOME/.config/git/allowed_signers"
And now the signature can be verified!
Checking your configuration
To confirm that everything is set up correctly, run:
git config --list
Expecting an output like this:
Conclusion
Congratulations! You've successfully configured Git and you're ready to start coding and collaborating like a pro.
Remember, Git is a powerful tool with many more features to explore. Happy coding!
Quick Commands Cheat Sheet:
MacOs:
# Ensure everything's up to date
brew update
# Install Git
brew install git
# Basic Configuration
git config --global user.name "Your Name"
git config --global user.email "your-email@example.com"
git config --global user.username "yourusername"
# Signing configuration
git config --global gpg.format ssh
git config --global user.signingKey ~/.ssh/id_rsa.pub
git log --show-signature --oneline
# Check your Git configuration
git config --list
Linux:
# Make sure package list is updated
apt-get update
# Install Git
apt-get install git
# Basic configuration
git config --global user.name "Your Name"
git config --global user.email "your-email@example.com"
git config --global user.username "yourusername"
# Signing configuration
git config --global gpg.format ssh
git config --global user.signingKey ~/.ssh/id_rsa.pub
git log --show-signature --oneline
# Check your Git configuration
git config --list
Allowed Signers File
# Create allowed_signers file
echo "$(git config user.email) $(cat ~/.ssh/id_rsa.pub)" > ~/.config/git/allowed_signers
# Add allowedSignersFile configuration
git config --global gpg.ssh.allowedSignersFile "$HOME/.config/git/allowed_signers"
Top comments (9)
Amazing
This looks like an error:
You can't redirect stdout to directory.
You're right! I missed this while testing it 😅 Thank you for catching it!
It should look like this:
I just updated the post to reflect this change!
What's the difference that use the git config to handle different signingKey to handle in the .ssh directory with a config file?
Hey! Thanks for reading!
The use of the
allowed_signersfile is necessary only if you're signing commits using the SSH approach, as described in this post. If you're using GPG, for example, you can skip this step, but there's a whole different process that you need to follow.I prefer this approach because if you're using GitHub, there's a good chance you already have SSH key pairs, eliminating the need to create more keys. This ultimately reduces potential security vulnerabilities in the future.
I got it.
I didn't know about this approach until I read your post (so useful) nevertheless currently I handle 2 GitHub accounts one for the job and the other for personal projects in a personal account. To handle these 2 accounts with 2 SHH keys I have a config file in the
~/.sshdirectory where I map what account will handle.So I was wondering What's the difference?
....Actually, I realized the response until I was writing this comment LOL, your approach is better because you can use git remotes without any extra step, in my approach I need to add the domain that I mapped in the config file.
Good advice thanks!!!
Glad it helped! 🙌
Thank you! As someone who is new to coding, this is very helpful.
Thank you! I'm glad you enjoyed it and found it helpful 🤓 I'll be sure to upload more of this soon!