Modern Git workflows optimize for features, but best practices optimize for integration, review quality, and history.<\/p>\n
The Git Patch Stack Methodology replaces feature-centric pull requests with small, architectural patches stacked directly on top of mainline. Each patch is:<\/p>\n
Development happens outside-in, while review and integration happen inside-out\u2014one patch at a time. The result is better reviews, fewer conflicts, cleaner history, and faster integration without abandoning pull requests.<\/p>\n
This article describes a methodology, not a tool requirement.<\/p>\n
That said, some of the workflows described here\u2014tracking patch identity across rebases, managing patch stacks, and opening pull requests per patch\u2014introduce friction if done manually.<\/p>\n
To address that, the Git Patch Stack CLI exists.<\/p>\n
\ud83d\udc49 https:\/\/git-ps.sh<\/a><\/p>\n The CLI is designed to support this methodology directly on top of Git and existing platforms like GitHub and Bitbucket. It automates the mechanical work (branching, cherry-picking, tracking patch identity, updating pull requests) so developers can focus on creating high-quality patches and integrating continuously.<\/p>\n The rest of this article explains why the methodology works. Tooling simply makes it practical at scale.<\/p>\n To truly understand the Git Patch Stack Methodology<\/strong>, it helps to start with how software changes are typically made.<\/p>\n At a high level, most changes fall into one of two categories:<\/p>\n On the surface, this works fine if you don\u2019t care much about peer review quality, conflict reduction, architectural clarity, or the long\u2011term historical value of your code. In that world, all you need is a feature branch<\/em>, following the workflow popularized by platforms like GitHub and Bitbucket.<\/p>\n At best, a pull request created this way corresponds to a single, coherent change from the diagram above. At worst, it looks like a feature branch full of loosely related commits\u2014snapshots of half\u2011finished thoughts\u2014with little structure or narrative. The commits don\u2019t clearly explain what<\/em> changed, why<\/em> it changed, or how the changes relate to one another. Unfortunately, this pattern is extremely common.<\/p>\n So what should we actually be aiming for?<\/p>\n One widely accepted best practice is to keep pull requests small. The primary reason is to enable high\u2011quality peer review<\/em>.<\/p>\n When a pull request is large and overwhelming, reviewers tend to skim it and respond with a quick LGTM<\/strong>. We\u2019ve all done it. The result is a review that adds little value\u2014often no more than what an automated linter could have caught.<\/p>\n Small pull requests, on the other hand, make it realistic for reviewers to:<\/p>\n Another best practice is continuous integration<\/em>\u2014not the tooling (GitHub Actions, CircleCI, etc.), but the behavior.<\/p>\n Continuous integration means integrating changes into the mainline as quickly and as frequently as possible. Doing so:<\/p>\n Small, frequent integrations keep the system stable and make failures easier to reason about.<\/p>\n A third set of best practices concerns the long\u2011term readability and usefulness of your Git history. Ideally, each change should:<\/p>\n When these conditions are met, your Git history becomes a form of documentation. You can understand why<\/em> the system evolved the way it did, not just what<\/em> the final state looks like. Each commit becomes a small, logical step toward a larger goal\u2014similar to showing your work in a math problem. This is often described as proof of work<\/em>.<\/p>\n When you try to apply these best practices while relying primarily on feature branches, tensions quickly emerge.<\/p>\n Branches exist to isolate work. Continuous integration exists to avoid<\/em> isolation. By definition, the two concepts are in conflict.<\/p>\n Teams often try to work around this by rebasing feature branches or repeatedly merging mainline back into them. Rebasing adds cognitive and operational overhead. Merging mainline repeatedly results in tangled Git histories that are difficult to understand or reason about.<\/p>\n Feature branches typically bundle an entire feature into a single pull request. The result is often a massive PR that discourages careful review and encourages superficial approval.<\/p>\n Finally, feature branches encourage developers to think in terms of features<\/em>, not architectural changes<\/em>. As a result, commit messages often lack clarity and historical usefulness. A feature is not an architectural unit; it is composed of many smaller architectural steps.<\/p>\n To better align with these best practices, we need a different mental model\u2014one that emphasizes small, architectural changes and frequent integration.<\/p>\n Our goals are straightforward:<\/p>\n Let\u2019s introduce a new unit of work: the patch<\/strong>.<\/p>\n A patch<\/em> is a single, logical, architecturally meaningful change that provides historical value. This terminology is intentional\u2014it echoes the original patch\u2011based workflows used in early open\u2011source development, and still used today by projects like Git and the Linux kernel.<\/p>\n Conceptually, a patch maps directly to a well\u2011formed Git commit.<\/p>\n Instead of developing long\u2011lived feature branches, we develop directly on top of mainline.<\/p>\n Local commits represent patches. As mainline advances, we continuously rebase our local patch stack on top of it. Git makes this easy:<\/p>\n With this configuration, Rarely do we create just one patch. More often, we create a stack of patches<\/strong>, each building on the one below it.<\/p>\n This stack lives locally on top of Work\u2011in\u2011progress commits can be marked with a Pull requests still matter\u2014they\u2019re how we request review. But instead of representing features<\/em>, they represent patches<\/em>.<\/p>\n A simple workflow looks like this:<\/p>\n This introduces some overhead, but it\u2019s manageable\u2014and automatable.<\/p>\n Independent patches can be reviewed and merged on their own.<\/p>\n Dependent patches require more care. If Patch B depends on Patch A, then Patch A must be reviewed and merged first. This encourages an inside\u2011out review order<\/strong>, even if development happens outside\u2011in.<\/p>\n In some cases, a patch series<\/em>\u2014a pull request containing multiple dependent patches\u2014may be appropriate. This trades faster integration for convenience and should be used selectively.<\/p>\n When a reviewer requests changes, we don\u2019t add new commits\u2014we update the patch.<\/p>\n Using interactive rebase, we modify the original commit and force\u2011push the updated branch. The pull request stays focused on a single logical change, even as it evolves.<\/p>\n Because rebasing changes commit hashes, we need a stable identifier. Each patch includes a UUID in its commit message:<\/p>\n This allows tooling to track patches across rebases, branches, and pull requests\u2014and to detect when a patch has diverged from its reviewed version.<\/p>\n Patch stacks naturally reflect dependency structure: foundational changes sit at the bottom, higher\u2011level behavior at the top.<\/p>\n This pairs well with outside\u2011in development<\/strong>\u2014starting from the system boundary and letting requirements drive lower\u2011level interfaces. Early patches may be incomplete or marked as WIP.<\/p>\n As inner layers solidify, outer patches are revisited and finalized. Review, however, happens inside\u2011out<\/strong>: dependencies first, consumers later.<\/p>\n This rhythm\u2014develop outside\u2011in, review inside\u2011out<\/em>\u2014is the heart of the Git Patch Stack Methodology.<\/p>\n"},{"title":"Hosting my Git Repositories","published":"2026-01-06T00:00:00+00:00","updated":"2026-01-06T00:00:00+00:00","author":{"name":"\n \n Unknown\n \n "},"link":{"@attributes":{"rel":"alternate","type":"text\/html","href":"https:\/\/drewdeponte.com\/blog\/hosting-my-git-repositories\/"}},"id":"https:\/\/drewdeponte.com\/blog\/hosting-my-git-repositories\/","content":" For a long while now it has become more and more evident that you just can't\ntrust companies to host your data. This is true even if you are paying for said\nservices. This has become even more obvious with the introduction of large\nlanguage models, etc.<\/p>\n Additionally, the products that exist in the space of Git hosting are less than\nideal in my opinion. Instead of them focusing on making Git hosting as good as\nit possibly could be. They are focused on building AI platforms that integrate\nwith all your Git repositories. Which I have zero interest in when I am paying\nfor Git hosting. Beyond that these companies are built on a software\ndevelopment model that is clearly less than ideal but they have no interest in\nrethinking that model.<\/p>\n For these reasons and more I have decided it probably makes the most sense to\nsimply host all my Git repositories myself.<\/p>\n The following are my notes around how I accomplished this so that if anyone\nelse wants to do the same they would hopefully be able to figure out.<\/p>\n Basically, we need a server to host the repositories and run the software. You\ncan of course pay some VPS provider like Digital Ocean or you can run your own\nserver at your house or wherever you want. Note: If you run it at your house\nyou will likely need to figure out some sort of Dynamic DNS. I believe\nCloudflare provides this as a service. But I am sure there are others.<\/p>\n Then you need to have an operating system. I personally prefer Arch Linux so I\nhave a server running Arch Linux.<\/p>\n We are going to be hosting our Git repositories over the SSH protocol with the\nhelp of a tool called Gitolite<\/a>. Gitolite<\/a> facilitates authenticating\nusers and managing access to the Git repositories over SSH public\/private key\npairs.<\/p>\n This portion assumes you already have an Arch Linux system setup for your server.<\/p>\n First thing we need to do on that server is installed the Next we want to start the ssh daemon.<\/p>\n Then we want to enable it so that it starts up at boot.<\/p>\n We can then verify it is running with the following.<\/p>\n Then I configured sshd by editing Then I restarted the sshd to have the changes take place.<\/p>\n After this I simply scp'd my public ssh key over to the server and added it to\nthe Then I simply made sure that the file had the correct permissions.<\/p>\n First I installed the dependencies as follows.<\/p>\n Then I installed Gitolite<\/a> as follows.<\/p>\n The above created the Then simply needed to initialize Gitolite. In order to do this I ran the\nfollowing.<\/p>\n This setup the Which supports what you need for private repositories as well as anonymous\n(unauthenticated) repositories which are useful for opensource.<\/p>\n One side benefits I was getting from the services I was leaving was off-site\nbackups. So, I figured I might as well address that in my setup as well.<\/p>\n Turns out there is a pretty great backup tool called Restic<\/a> that integrates\nwith Backblaze B2 that allows you to configure backups to be done and stored in\na Backblaze B2 bucket pretty easily.<\/p>\n First I had to decide what I wanted to backup. In my case I simply wanted the following.<\/p>\n
\nGit Patch Stack Methodology<\/h2>\n
\n
\nBest Practices<\/h2>\n
Small Pull Requests<\/h3>\n
\n
Continuous Integration<\/h3>\n
\n
Architecture & Historical Value<\/h3>\n
\n
\nThe Conflict<\/h2>\n
Feature Branches vs. Continuous Integration<\/h3>\n
Feature Branches vs. Small Pull Requests<\/h3>\n
Feature Branches vs. Historical Value<\/h3>\n
\nResolving the Conflict<\/h2>\n
\n
The Patch<\/h3>\n
Continuous Integration Without Feature Branches<\/h3>\n
[pull]<\/span><\/span>\n rebase = true<\/span><\/span><\/code><\/pre>\ngit pull<\/code> automatically rebases your local patches onto the latest mainline, surfacing conflicts early\u2014when they\u2019re small and easy to fix.<\/p>\nThe Stack<\/h3>\n
origin\/main<\/code>. Later patches can depend on earlier ones, which mirrors how real features are developed. Git\u2019s interactive rebase allows us to:<\/p>\n\n
WIP:<\/code> prefix and refined over time until they\u2019re ready for review.<\/p>\nPull Requests as Patch Reviews<\/h3>\n
\n
origin\/main<\/code> named after the patch<\/li>\nIndependent vs. Dependent Patches<\/h3>\n
Updating Pull Requests<\/h3>\n
Tracking Patch Identity<\/h3>\n
ps-id: <uuid><\/span><\/span><\/code><\/pre>\n
\nDevelopment: Outside\u2011In, Review: Inside\u2011Out<\/h2>\n
What we need<\/h2>\n
The Setup<\/h2>\n
Get SSH Daemeon Setup<\/h3>\n
openssh<\/code> package so\nthat we will have the ssh daemon installed.<\/p>\nsudo pacman -Sy openssh<\/span><\/span><\/code><\/pre>\nsudo systemctl start sshd<\/span><\/span><\/code><\/pre>\nsudo systemctl enable sshd<\/span><\/span><\/code><\/pre>\nsystemctl status sshd<\/span><\/span><\/code><\/pre>\n\/etc\/ssh\/sshd_config<\/code> by updating it so that\nthe following are set. Explanations of what they do are in comments above them\nall below. This is effectively to harden sshd as may be exposed to the internet\ndirectly and it needs to be as secure as possible.<\/p>\n# Enable public key authentication<\/span><\/span>\nPublickeyAuthentication yes<\/span><\/span>\n<\/span>\n# Tell it where to find the file containing authorized keps<\/span><\/span>\nAuthorizedKeysFile .ssh\/authorized_keys<\/span><\/span>\n<\/span>\n# Prevent password authentication<\/span><\/span>\nPasswordAuthentication no<\/span><\/span>\n<\/span>\n# Prevent challenge response auth<\/span><\/span>\nChallengeResponseAuthentication no<\/span><\/span>\n<\/span>\n# Disable PAM authentication<\/span><\/span>\nUsePAM no<\/span><\/span>\n<\/span>\n# Prevent root login<\/span><\/span>\nPermitRootLogin no<\/span><\/span>\n<\/span>\n# Prevent keyboard interactive auth<\/span><\/span>\nKbdInteractiveAuthentication no<\/span><\/span>\n<\/span>\n# Don't allow any empty passwords<\/span><\/span>\nPermitEmptyPasswords no<\/span><\/span>\n<\/span>\n# Restrict allowed users<\/span><\/span>\nAllowUsers youruser gitolite<\/span><\/span>\n<\/span>\n# Disable agent & TCP forwarding unless you need it<\/span><\/span>\nAllowAgentForwarding no<\/span><\/span>\nAllowTcpForwarding no<\/span><\/span>\nX11Forwarding no<\/span><\/span>\n<\/span>\n# Disable tunneling unless needed<\/span><\/span>\nPermitTunnel no<\/span><\/span>\n<\/span>\n# Disable rhosts-style trust<\/span><\/span>\nIgnoreRhosts yes<\/span><\/span>\nHostbasedAuthentication no<\/span><\/span>\n<\/span>\n# Limit auth attempts<\/span><\/span>\nMaxAuthTries 3<\/span><\/span>\n<\/span>\n# Limit concurrent connections<\/span><\/span>\nMaxSessions 2<\/span><\/span>\nMaxStartups 10:30:60<\/span><\/span>\n<\/span>\n# Drop idle connections<\/span><\/span>\nClientAliveInterval 300<\/span><\/span>\nClientAliveCountMax 2<\/span><\/span><\/code><\/pre>\nsudo systemctl restart sshd<\/span><\/span><\/code><\/pre>\nauthorized_keys<\/code> file as follows so that I could easily ssh over to the\nserver and manage things.<\/p>\ncat ~\/.ssh\/id_ed25519.pub >> ~\/.ssh\/authorized_keys<\/span><\/span><\/code><\/pre>\nchmod 600 ~\/.ssh\/authorized_keys<\/span><\/span>\nchown -R user:user ~\/.ssh<\/span><\/span><\/code><\/pre>Install & Setup Gitolite<\/h3>\n
sudo pacman -Sy base-devel git<\/span><\/span><\/code><\/pre>\nsudo pacman -Sy gitolite<\/span><\/span><\/code><\/pre>\ngitolite<\/code> user on the system and setup\n\/var\/lib\/gitolite<\/code> as it's home directory.<\/p>\nsudo -u gitolite gitolite setup -pk path\/to\/my\/public\/ssh\/key<\/span><\/span><\/code><\/pre>\ngitolite-admin<\/code> repository as well as a testing<\/code> repository.\nThe gitolite-admin<\/code> repository is how you configure and manage Gitolite. So\nyou simply clone it and make changes to the configs in there and commit and\npush it up. It then handles creating repositories appropriately for you with\nthe configured access controls.<\/p>\nWhat about Off-site Backups<\/h2>\n
\/var\/lib\/gitolite\/repositories<\/span><\/span>\n\/var\/lib\/gitolite\/.gitolite<\/span><\/span><\/code><\/pre>\n