In some cases, running composer update could mean several dependency updates, as well as even database changes. Unfortunately, you won’t always get the chance to completely test and deploy these updates before having to continue on with other tasks.
On the other hand, saving these updates to a separate branch, or stashing them in a git stash, might cause several errors on your local site.
Here is a procedure I use to keep my short-term changes separate from my local update.
First, checkout a new branch:
git checkout -b upgrades
Then commit all your updates (this commit will not get pushed):
git commit -m 'local updates: do not push'
Next, do your short-term development and changes, then commit those:
git commit -m 'SITE-123: Fixes issue with user save'
git commit -m 'SITE-124: Adds new form for user signup'
At this point, your local history will look something like:
commit 393aba6a826b9155eb1b8b60e6cd03fbcf2bcf7f (HEAD -> upgrades)
Author: Alan <alan@atendesigngroup.com>
Date: Thu Jul 12 13:34:52 2018 -0600
SITE-124: Adds new form for user signup
commit d357a71b17c5a631e83452f671a32d02a05c7485
Author: Alan <alan@atendesigngroup.com>
Date: Thu Jul 12 10:40:04 2018 -0600
SITE-123: Fixes issue with user save
commit d5dca1b09f318113aad3fcbf65e99a460a68ec23
Author: Alan <alan@atendesigngroup.com>
Date: Tue Jun 5 16:39:19 2018 +0200
local updates: do not push
If you're like me and still have other uncommitted changes that are a work in progress, you can safely set those aside as well:
git stash
Now, it's time to deploy to master:
git checkout master
There are a few shortcuts for cherry-picking commits. If you want to just cherry pick the last one from a branch, it’s as simple as:
git cherry-pick upgrades
If you want to cherry-pick the last two:
git cherry-pick upgrades~1..upgrades
Note that using the branch name itself is the equivalent of saying 'the most recent hash of this branch.'
Therefore "upgrades~1" is the equivalent of saying "the second to last hash of this branch."
If you use the exact hashes, and you give a range to cherry-pick, be sure that your first hash includes a ~, meaning “grab from this hash to the next hash, but also include this hash."
Now, do a git pull to grab the latest, and then a get push.
git pull -r origin master
git push origin master
The last step is to make sure that your “upgrades” branch will be as clean and readable as possible. What we do is rebase master to re-order your commits.
git checkout upgrades
git rebase master
Now your upgrades history will look something like:
commit d5dca1b09f318113aad3fcbf65e99a460a68ec23
Author: Alan <alan@atendesigngroup.com>
Date: Tue Jun 5 16:39:19 2018 +0200
local updates: do not push
commit 393aba6a826b9155eb1b8b60e6cd03fbcf2bcf7f (HEAD -> upgrades)
Author: Alan <alan@atendesigngroup.com>
Date: Thu Jul 12 13:34:52 2018 -0600
SITE-124: Adds new form for user signup
commit d357a71b17c5a631e83452f671a32d02a05c7485
Author: Alan <alan@atendesigngroup.com>
Date: Thu Jul 12 10:40:04 2018 -0600
SITE-123: Fixes issue with user save
[other changes that came from master remote]
To bring back those previously uncommitted changes, just run:
git stash pop
And you're done! Repeat this process however many times you may need until you can safely push your composer upgrades.
