Managing Development in Git Despite an Unwieldy Composer Update

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: Then commit all your updates (this commit will not get pushed): Next, do your short-term development and changes, then commit those: At this point, your local history will look something like: 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: Now, it's time to deploy to 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: If you want to cherry-pick the last two: 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. 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. Now your upgrades history will look something like: To bring back those previously uncommitted changes, just run: And you're done! Repeat this process however many times you may need until you can safely push your composer upgrades.