Managing Development in Git Despite an Unwieldy Composer Update

Alan Sherry

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.


About the Author

From his first website to advertise private saxophone lessons, it wasn't long before he realized his interest in web development was much more than a means to advertise. Alan started with Drupal in 2011, and went onto work with large non-profits like the Center for Budget and Policy Priorities, and Banner Health. Since joining Aten in 2017, Alan has been able to bring his experience with non-...

Read More