Whether you're maintaining an older client website or you have a side project that you just can't afford to buy fancier services for, there will be times where you have to manually deploy an update. For those cases, git's built-in patch functionality might offer a fantastic benefit over manually replacing individual files. Let's take a look.
Git offers a really easy way to generate a patch file that contains any and all differences found between two branches. So when you need to make some changes to a site, simply create a branch and make the changes as usual. Then when the time comes to deploy, before you merge and delete this new branch, run the following command to generate a patch file:
❯ git diff main maintenance-branch-name > maintenance-branch.patch
main is the name of your main branch and
maintenance-branch-name is, you guessed it, the name of the branch you made your changes in.
In certain cases the project repository might also include other files that you don't need to deploy, like
package.json or build artifacts or so. You can exclude any number of files or directories when creating a patch file. Here's an example of this:
❯ git diff main maintenance-branch-name -- . ':!*package.json' ':!*.vscode/*' ':!*.devcontainer/*' > maintenance-branch.patch
In this example I'm excluding
package.json, anything inside the
.vscode directory, as-well as anything inside the
.devcontainer directory. You can repeat this as many times as needed for each file or directory you wish to exclude.
Now that you have a patch file created, you can upload this to where the project is hosted and apply it. You can use your favorite method of uploading this file, whether that's
scp or even plain old
ftp, just be sure to place it in the same directory as where the project itself is, too.
On the server we don't actually need git to apply the patch. We'll instead use the
patch command, which comes preinstalled on many Linux distros. If your server lacks this tool, check your specific flavor's repository for the relevant package. In many cases this package is simply called
patch, but there might be some flavor specific variations here.
Once you have the file on the server and
patch ready to go, go to the directory where the project is located using ssh. You can run the following command to do a test run, meaning it'll not actually make any changes to the files but might report back if something is wrong:
❯ patch -p1 --dry-run < maintenance-branch.patch
When you're confident everything looks OK, simply remove the
--dry-run part of the above command to apply the changes for real:
❯ patch -p1 < maintenance-branch.patch
Do you have to revert these changes for whatever reason? That's super easy now too using the following command:
❯ patch -p1 -R < maintenance-branch.patch
Pretty neat, right?
It would of course be nice if there was an automated deployment system in place, but that isn't always feasible for all projects. Real life and all its limitations, and all that.
If you have to deal with this kind of situation sometimes, maybe give this method a try next time you have to update a project or website.
I hope it'll help.