git

Git, created by Linus Torvalds 20 years ago, transformed software development with its decentralized design, conceived out of necessity after losing access to proprietary tools. Initially, Torvalds aimed to solve his own frustrations with existing systems like CVS and BitKeeper, leading to efficient patch application and a focus on stability and performance. Git allowed for easy local work and sharing, which simplified its adoption for both professional and personal projects. Despite early challenges, Git gained traction, ultimately becoming integral to software collaboration worldwide, supported by its effective maintenance and community involvement.

https://github.blog/open-source/git/git-turns-20-a-qa-with-linus-torvalds/

Malicious code was added to the tj-actions/changed-files GitHub Action, leaking secrets in public repositories. Using mutable Git tags can lead to unexpected code execution; using commit IDs ensures immutability. The author ran a shell script to check their GitHub Actions for such vulnerabilities and reviewed the trustworthiness of the actions based on their sources. The process involved using Unix text processing tools to extract and tally actions from workflow files, emphasizing security practices in leveraging third-party actions.

https://alexwlchan.net/2025/github-actions-audit/

Git Basics Overview:
– Repository: Collection of commits; defines HEAD for current tree.
– Index: “Staging area” for changes before committing.
– Working Tree: Directory with a repository, includes files.
– Commit: Snapshot of working tree; creates revision history.
– Branch: A name/reference for a commit.
– Tag: Permanent name/description for a commit.
– HEAD: Indicates currently checked-out branch or commit.

Workflow: Create repository → work in working tree → add changes to index → commit changes to repository.

https://jwiegley.github.io/git-from-the-bottom-up/

TLDR: Simon Tatham prefers using bare Git repositories over Git forges (like GitHub or GitLab) for hosting his projects. He outlines his reasons, favoring trust, simplicity, and control over heavy account management and imposed workflows. He provides guidelines on how to best submit patches, ranking methods from most to least preferred: providing a repository URL with branch name, git bundles, patch files, diff files, and avoiding git send-email. While acknowledging the transparency benefits of Git forges, he remains unconvinced that they outweigh his reasons for independence.

https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/

Core Git developers use various git config settings to enhance their workflows. The article outlines crucial configuration options that should likely be defaults, categorizing them into three groups:
1. Clearly Makes Git Better – settings like branch.sort and diff.algorithm improve usability and clarity.
2. Why the Hell Not? – harmless options that may enhance the experience, like help.autocorrect and commit.verbose.
3. A Matter of Taste – preferences, such as managing merge conflicts with merge.conflictstyle.

Key recommendations include setting a default branch name, improving diff outputs, and auto-configuring remote tracking for pushes. The author emphasizes the practicality of these settings, backed by insights from Git core developers.

https://blog.gitbutler.com/how-git-core-devs-configure-git/

Beej's Guide to Git is a comprehensive resource by Brian “Beej Jorgensen” Hall, detailing Git and GitHub usage, workflows, commands, and collaboration techniques. The guide includes setup instructions, file management, branching, merging, and advanced topics like rebasing and stashing. It also covers remote repositories, configuration, and tools for conflict resolution. Versions up to February 2025 are included, emphasizing practical application and collaboration in software development.

https://beej.us/guide/bggit/html/split/