I admit this is probably not an ideal setup, but I’m running apps, that I checkout and update via GIT. If the publisher issues an update, all I have to do is run git pull (or switch to tag or branch).
Another upside is that I can track any changes I made to the code – a technique called monkey-patching. The changes are usually needed to adapt the software (PHP, Ruby, Java) to my particular needs. I therefore makes little sense to contribute those changes back to the (open source) project.
If you want to apply those changes to a different installation or re-apply after an (software-internal) update, you need a way to replicate the changes. A good way for this are patches – one or more files containing only the changes made to particular files.
Here’s the short version for creating a patch, found at https://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/:
- first create a new branch (yes, this is really necessary)
- git checkout -b my_patch_branch_name
- make your changes (or copy the changed files over)
- commit your changes
- create the patch (save the changes in the new branch compared to the master branch)
- git format-patch master –stdout > fix_empty_poster.patch
To apply the patch, run the following:
- git am –signoff < fix_empty_poster.patch
This actually applies the patch and signs off on it, which means the changes are commited to the branch (most likely main) your current copy is on. Check “git log” and you’ll find the applied patch in the comments.
That’s it – just a short procedure.
PS: To switch your current working copy back to the master branch, run “git checkout master”