Git Workflow for Backdrop CMS

Here is my workflow.  For my Backdrop CMS sites, I keep pretty much all of my code in a single git repo. I know that some Drupal 8/9 sites using composer do not include Drupal core in GIT. However, the standard practice for managing Backdrop does not include composer. I have heard of some folks trying to set up Backdrop with composer, but I am not sure how that works or how easy it is. I exclude the files directory from the git repo and the active config directory. I usually also exclude settings.php from repo, unless I am using a settings.local.php file for my database credentials. I do keep a versioned copy of config in the repo and occasionally export the active config from production into this directory and commit it (see later comments).   I believe that the best practice would be to include core in your git repo. When it comes time for updates, this is my rough process: 1) Backup my database 2) Clone my site locally (usually I already have a local copy) 3) Update core locally, commit to repo, push to github 4) You should be careful about updating settings.php and .htaccess if you have any custom changes to these files on your production server. 5) SSH into server and pull updated code to server 6) Run update.php (if necessary) 7) I usually update modules locally one at a time, with a single commit for each module. Depending upon how many modules need updates, I may push them in batches to production server and run update.php as necessary. 

Personally, I don't like to update the code directly on my production server - it just seems easier to resolve any unexpected issues if everything is in git before it touches my production server. However, I suspect that many Backdrop users are updating code with UI or drush on the server and then committing the code afterwards (if they keep a repo).  NOTE: My current workflow includes renaming the staging directory to "versioned" and committing to repo (something like this). So, if I wish to push any changes to production through config files, I include those in the versioned config directory.  Other ideas for managing config are outline here. I don't usually do this, because I'm not usually updating the live site with config. But, I think it would be good practice to export your active config into your versioned directory anytime you are doing updates, to keep these in sync. I aspire to being more disciplined about this in my workflow in the future. 

Is it fair to say that versioning Backdrop in your project repo is a standard or even recommended way to organize a project site codebase?

Yes, think it is fair to say that most Backdrop sites version Backdrop core in their repo. Personally, it would be my recommendation. 

Do you version the other contributed modules your site might use?

Yes, I keep core, contrib, and custom code all in the same repo. I try (and am pretty good) about creating separate commits for each to help track the history and make it possible to revert any single item easily if necessary.   

Yes, I keep core, contrib, and custom code all in the same repo. I try (and am pretty good) about creating separate commits for each to help track the history and make it possible to revert any single item easily if necessary. 

I do the same thing. I always include Backdrop core in the repo, just like I did with Drupal core. I find it easier to handle core updates for Backdrop than for Drupal because usually, all I need to do is replace the `core` directory with each update. 

I do keep a versioned copy of config in the repo and occasionally export the active config from production into this directory and commit it 

I also keep my staging directory in version control, but I usually leave it named "staging" just so I know that will be the staging directory on all copies of my site (sometimes as many as 4 copies: local, dev, test, and live).

On servers where I have ssh access, I keep the live directory in version control, but on Pantheon and other environments where I don't, I also use the UI, as Tim mentioned, to export the active config from production.

On Pantheon, I keep my active configuration in the "files" directory, but on all other servers I move it outside my web root, so my git repo looks like this:

gitroot:

/config
/config/staging
/config/dev-active
/config/live-active
/docroot
/docroot/core
/docroot/files
/docroot/modules
/docroot/...

I hope this is helpful :)

It's now possible to put your staging config in the repo too and deploy it along with the rest. And then sync it via the UI or drush. One thing to do though is to add a setting to settings.php to prevent the staging config from being removed with each sync.

Some more info on what I mean. If someone adds this to settings.php then it will skip clearing the staging directory with each sync:

$config['system.core']['config_sync_clear_staging'] = 0;

The reason this is useful is that it then won't mess with any files that are in a repo by deleting them when synced. It means we need to be careful with removing all config files locally before putting in updated ones so it will ensure that deleted config is actually removed.

The nice side effect is that it'll show if live config has been changed compared to the repo, so I can ensure that those changes don't get blown away if they need to be kept.