Chemaclass - git

Verified Git Commits

2024-11-17T00:00:00+00:00

When it comes to software development, trust and security are very important. One easy way to level up both is by using verified commits.

Whether you’re working on an open-source project or in a private company, verified commits can make sure your contributions are legit. Let’s break down what they are, why they’re important, and how to start using them.

What are verified commits? #

A verified commit is basically a Git commit that is signed by the author using a digital signature. This signature proves that the commit actually came from the person who says they made it. Tools like GPG (GNU Privacy Guard) let you attach this signature to your commits.

If you’re using platforms like GitHub, you’ll notice a little “Verified” badge next to commits that are signed properly. It’s a quick way to show that the commit is authentic.

Why Are They Important? #

Signed commits help keep your contributions authentic and trustworthy. By adding a cryptographic signature to your commits, you prove that the changes came from you. This is especially important in collaborative environments, where maintaining trust and accountability is key.

Without signed commits, anyone could fake a commit using someone else’s email. For example, they could use your email, and platforms like GitHub would link it to your profile, making it look like you made the changes, even if you didn’t… not good!

By signing your commits, you show that the work is genuinely yours. It stops impersonation, builds trust in what you’ve done, and keeps everything transparent and accountable.

Note: For this demo, I used a public email address belonging to Linus Torvalds. After pushing the commit to this repository, GitHub recognized the email and linked it to his profile. This impersonation is purely for demo purposes to highlight potential risks. Always use your own email for commits.

How to get started with verified commits #

Set up a GPG key #

First, you’ll need a GPG key to start signing commits. Here’s how:

Generate a GPG key:

gpg --full-generate-key

Find your key ID:

gpg --list-secret-keys --keyid-format=long

Tell Git to use your key:

git config --global user.signingkey <your-key-id>

Make signing commits the default:

git config --global commit.gpgsign true

Add your key to GitHub/GitLab #

Export your public key:

gpg --armor --export <your-key-id>

Navigate to “Settings > SSH and GPG keys,” and paste your key.

Start signing commits #

From now on, Git will automatically sign your commits.

If you want to sign a commit manually, just use the -S flag:

git commit -S -m "Your commit message"

You can verify the commit signature with:

git log --show-signature

And also when clicking on the “Verified” badge on GitHub directly.

Verified commits might seem like a small step, but they make your code more trustworthy. It’s an easy way to add an extra layer of protection to your work, and it’s worth it. Give it a try!

Extra: Full setup in Spanish 🇪🇸 #

Related links

Learn more: What is PGP encryption? A 3-minute tutorial for beginners

Open-Source Software

2021-05-03T00:00:00+00:00

Every project you ship stands on open-source software. Your framework, your test runner, your compiler, the small library you never think about.

You use it every day. The real question is whether you ever give back.

Giving back is not charity. It is one of the fastest ways to grow as a developer.

What is OSS? #

Open-source is not the same as free software. Free software is one kind of open-source, but open-source does not have to be free to use. Two examples draw the line. PHPUnit is open-source and free. Spryker is open-source and paid. Both publish their code for anyone to read.

OSS is software that is public, open to the world.

Benefits #

Two groups win from open-source: the companies that publish it, and the people who contribute.

For companies #

Open access drives adoption. The easier the code is to get, the faster people build on it. Training and tutorials pull in newcomers and grow the ecosystem. The code tends to sit on the cutting edge, because software that stands still goes obsolete. A public project gathers a community around it, and public channels make that community easy to join.

And because anyone can read the source, anyone can check its quality. That is trust you cannot fake.

For individual contributors #

You pick what you work on. You practice real skills without the pressure of a production outage. You get to play with the newest features of your language, or try a language you have never touched.

You also sharpen the soft skills that carry a career: writing clearly, explaining a change, holding your ground when people disagree.

The code teaches the hard skills. The disagreements teach the rest.

Contributing to OSS #

Getting started with GitHub #

Starting is easy, and you have two doors. Open your own project, or contribute to one that already exists. A pet project fits the first door perfectly.

Pet projects #

A pet project is a playground to build real software and train real skills. Put it on your public GitHub profile and you get every benefit of contributing to OSS, plus one more: you answer to nobody. You set the roadmap. You decide what to build and how. You are your own boss.

The project is there for you. You are responsible to play, explore, and push past your limits.

My pet projects #

Active:

agnostic-ai: write AI agents, skills, rules, and hooks once, use them in every AI CLI.
bashdep: a simple dependency manager for Bash.
phel-snake: the snake game in your terminal, written in Phel.
edifact-parser: a parser for a UN/EDIFACT file format in PHP.
unspent: a PHP library for UTXO-like bookkeeping with unspent entries.

Inactive:

create-pr: a Bash script to open a pull request from your branch and context.

Abandoned:

stock-ticker: get a notification with the news from your favorite Tickers.
jira-status-notifier: Notify when the JIRA tickets don’t move along.
php-best-practices: what I considered best practices for web-dev (archived).
php-scaffolding: a basic PHP scaffolding with Docker (archived).
knob-mvc: a framework to create WordPress templates (2015/2017).

… and many more on github.com/Chemaclass

My OSS organization contributions #

Active:

phel-lang: Phel is a functional programming language that compiles to PHP. It is a dialect of Lisp inspired by Clojure and Janet. I already wrote a post about this: Phel: A Lisp that compiles to PHP
gacela-project: Gacela is a PHP framework that helps you to improve the design of your application by splitting the logic into different modules.

Abandoned:

nm_template: The base template for NuevaMetal (2013-2016).

Code is only half of it. The other half is what you write down and hand to the next person.

Blog posts #

… and many more on https://chemaclass.com/blog/

The beauty of OSS #

Contribute in public long enough and you start to see your own growth. The corrections you keep making. The code you wrote last year, already aged. The mistakes, all of them, in the open. And underneath, the slow proof that you are getting better.

You build a sixth sense for patterns you have hit before, the good ones and the painful ones.

Show your skills. Help the people around you. That is working with the garage door open.

Open-source software offers you one of the best opportunities to start building a career of continuous improvement.

This is a (Spanish) talk that I did remotely on April 2021, for PHPMad Madrid Community. I present all these ideas together with a live demo of how to contribute to a real OSS.

Sharing Your Git Patches

2020-12-01T00:00:00+00:00

Discover another way of sharing suggestions with your development team.

Imagine this situation #

You are reviewing a Pull Request (PR), and you see some minor improvements or suggestions that you would like to share with the author. You might write some comments, and usually, that would be sufficient.

Imagine that in order to transmit your “whole idea” you would need to change some files because just communicating the full picture will end up in a huge comment which might be not as clear as it could be.

What possibilities are there apart from just comments in a PR? #

Well, there are multiple options. The key is to be aware of them and use them wisely depending on the priority of the task and the changes themselves:

As already mentioned, writing a comment as feedback is a good idea by default, but not the only one.
We can always do some pair-thinking, talk at any time. Communication is always good in order to clarify the possible uncertainty.
Sharing your git patches is another good option.

Git diff to the rescue! #

What if you (as a reviewer) could share your idea without any single commit or comment in the PR, but sharing your changes directly with the author?

Well, that’s actually possible and really easy. As you already know, the git diff command gives you the differences between any two branches.

git diff origin develop > ../my-origin-develop.patch

What we are doing here is redirecting the output of the diff command into a file (aka: patch), so we can share that output with any other peer-team.

What now? #

Well, having that patch file, it’s pretty easy to apply those changes in your local machine without doing any commit:

git apply ../my-origin-develop.patch

Applying this patch will simply change your local system in the same way the patch was created.

“How to” by steps #

Let’s divide the responsibilities into two: the creator of the patch and its user:

The patch creator: the person who will create the patch #

# Checkout that branch
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Do your suggestions and changes in the targeted branch
# Generate the patch file using the diff command
$ ~/myProject git:(the-branch) ➜ git diff > ../your-diff.patch
# Share the patch file with the author of the PR

The patch user: the person who will see the patch #

# Ensure you are in that branch
$ ~/myProject git:(the-branch) ➜ git pull origin the-branch
# Apply the patch file
$ ~/myProject git:(the-branch) ➜ git apply ../your-diff.patch

References #

Official documentation for “git apply”