<p>We at Familiar have decided to leave craft out of git because of this exact issue.  It's extra hassle every time an update comes out.</p>

<p>To better deal with it we've built a couple of grunt functions as part of our craft yeoman generator.  You can see the whole generator on npm: <a href="https://www.npmjs.org/package/generator-familiar-craft" rel="noreferrer">https://www.npmjs.org/package/generator-familiar-craft</a>. Or just an idea of how the grunt tasks are setup: <a href="https://github.com/familiar-studio/generator-familiar-craft/blob/master/app/templates/Gruntfile.js" rel="noreferrer">https://github.com/familiar-studio/generator-familiar-craft/blob/master/app/templates/Gruntfile.js</a></p>

<p>The tasks are pretty simple, the first one will download the latest copy of craft, unzip it and then move just the app folder into place (perfect if your local environment gets way behind)</p>

<p>We also have a database pull grunt task that grabs a copy of the live (or any staging) database and imports into your local database.</p>

<p>This way there's always a quick fix through one or both commands if things get out of sync on any of our developers local environments</p>

<p>So our normal update process is this</p>

<ol>
<li>Update local to make sure everything's fine.</li>
<li>Update live</li>
<li>Celebrate!!
No committing needed.</li>
</ol>

<p>Generally we treat craft just like any other project dependency manager like bower would and only add our own code to our repos </p>

CC BY-SA 3.0
2014-10-29T04:53:25.680Z
I would be keen to see this grunt task if you don't mind providing a link!
jnowland
CC BY-SA 3.0
2014-10-29T04:59:56.027Z
Sure here's the gruntfile https://github.com/familiar-studio/generator-familiar-craft/blob/master/app/templates/Gruntfile.js. It's part of our craft yeoman generator but you don't have to use the generator to use it.  Just make sure you fill in any of the variables.  Still needs work but it's been a huge timesaver for us
Keith Mancuso
CC BY-SA 3.0
2014-10-29T08:40:12.390Z
Interesting approach that makes sense, since Craft is encapsulated in its own folder (Great design!). I certainly hit git conflicts a couple times while upgrading, like that time right before launch deadline. Ouch.
Fred Carlsen
CC BY-SA 3.0
2014-10-29T12:17:44.820Z
Yea, exactly the kind of thing this setup is ment to avoid.  We're consisting adding some way to pull down specific craft versions similar to the way bower lets you specify specific versions or just latest, but we haven't had the need to tie something to a specific version yet
Keith Mancuso
CC BY-SA 3.0
2014-10-29T15:09:15.597Z
Interesting take on the matter. Thanks for sharing.
Jérôme Coupé
CC BY-SA 3.0
2014-10-29T00:45:37.413Z
2014-10-29T05:02:20.200Z
2014-10-29T05:02:20.200Z
Keith Mancuso
<p><a href="http://buildwithcraft.com/updates">Craft updates come fast and frequent</a> which introduces a problem when working with lots of people in a team.
Don't get me wrong, this is a <em>good</em> problem to have!</p>

<p>How are dev shops handling the update process when sites have multiple developers on them with multi feature branches running all at once?</p>

<p>The main issue is the strong dependency each feature branch has with the database. Once you implement a craft update, craft doesn't like jumping around on older versions as you switch feature branches.</p>

<p><strong>What we're currently doing:</strong></p>

<ol>
<li><a href="http://buildwithcraft.com/docs/config-settings#allowAutoUpdates">Disabling the ability for people to be able to update on the live production server</a>.</li>
<li>Creating an "Upgrade" branch on git and doing the updates in that before merging them into the develop branch.</li>
</ol>

<p>We still seem to be occasionally getting the odd issue of an old feature branch that is out of sync with the database/new install because of this we are still looking to improve this workflow.</p>

<p><strong>Ideas we are tossing up:</strong></p>

<ol>
<li>Making a private repo of the <code>/app</code> directory a submodule so the sites repo is rather clean.</li>
<li>Disabling the ability to upgrade by default on all domains and treat updates as a "big thing" similar to how you would on an Expression Engine upgrade.</li>
</ol>

<p>Would love to hear how others are tackling this "convenient" problem.</p>

<workflow><updating><auto-updates><git>
Dealing with Upgrades and Git Workflow
# Dealing with Upgrades and Git Workflow

(Asked by: username_0 on 2014-10-29)

[Craft updates come fast and frequent](http://buildwithcraft.com/updates) which introduces a problem when working with lots of people in a team.
Don't get me wrong, this is a *good* problem to have!

How are dev shops handling the update process when sites have multiple developers on them with multi feature branches running all at once?

The main issue is the strong dependency each feature branch has with the database. Once you implement a craft update, craft doesn't like jumping around on older versions as you switch feature branches.

**What we're currently doing:**

1. [Disabling the ability for people to be able to update on the live production server](http://buildwithcraft.com/docs/config-settings#allowAutoUpdates).
2. Creating an "Upgrade" branch on git and doing the updates in that before merging them into the develop branch.

We still seem to be occasionally getting the odd issue of an old feature branch that is out of sync with the database/new install because of this we are still looking to improve this workflow.

**Ideas we are tossing up:**

1. Making a private repo of the `/app` directory a submodule so the sites repo is rather clean.
2. Disabling the ability to upgrade by default on all domains and treat updates as a "big thing" similar to how you would on an Expression Engine upgrade.

Would love to hear how others are tackling this "convenient" problem.

**Tags:** workflow, updating, auto-updates, git


---

## 1 answers

### Answer by username_1 on 2014-10-29. Score: 7

We at Familiar have decided to leave craft out of git because of this exact issue. It's extra hassle every time an update comes out.

To better deal with it we've built a couple of grunt functions as part of our craft yeoman generator. You can see the whole generator on npm: <https://www.npmjs.org/package/generator-familiar-craft>. Or just an idea of how the grunt tasks are setup: <https://github.com/familiar-studio/generator-familiar-craft/blob/master/app/templates/Gruntfile.js>

The tasks are pretty simple, the first one will download the latest copy of craft, unzip it and then move just the app folder into place (perfect if your local environment gets way behind)

We also have a database pull grunt task that grabs a copy of the live (or any staging) database and imports into your local database.

This way there's always a quick fix through one or both commands if things get out of sync on any of our developers local environments

So our normal update process is this

1. Update local to make sure everything's fine.
2. Update live
3. Celebrate!!
   No committing needed.

Generally we treat craft just like any other project dependency manager like bower would and only add our own code to our repos

> **Comments:**
> **username_0**: I would be keen to see this grunt task if you don't mind providing a link!  
> **username_1**: Sure here's the gruntfile https://github.com/familiar-studio/generator-familiar-craft/blob/master/app/templates/Gruntfile.js. It's part of our craft yeoman generator but you don't have to use the generator to use it.  Just make sure you fill in any of the variables.  Still needs work but it's been a huge timesaver for us  
> **username_2**: Interesting approach that makes sense, since Craft is encapsulated in its own folder (Great design!). I certainly hit git conflicts a couple times while upgrading, like that time right before launch deadline. Ouch.  
> **username_1**: Yea, exactly the kind of thing this setup is ment to avoid.  We're consisting adding some way to pull down specific craft versions similar to the way bower lets you specify specific versions or just latest, but we haven't had the need to tie something to a specific version yet  
> **username_3**: Interesting take on the matter. Thanks for sharing.  

---

