Commit changes from staging
Change a staging or multidev site's code over SFTP, SSH, or wp-admin, then commit the changes to its branch with you as the author.
New staging and multidev environments start in Git mode, where code is a read-only release and changes only through Git. Switch an environment to SFTP mode (the SFTP | Git switch on the Code card) and it runs a writable working tree: you can change its code over SFTP, over SSH, with WP-CLI, or in wp-admin (plugin and theme installs and updates). The changes are not in Git until you commit them. A commit saves them to the environment's branch: main for staging, env/{name} for a multidev.
Live code is a read-only release, so live has nothing to commit. Change code on staging instead.
Commit your changes
- Pick the environment in the top bar and open Info.
- On the Avaloi Git card, click Commit changes and read the files added, changed, and deleted since the last commit.
- Write a short message that says what changed. The message is required.
- Click Commit changes. Avaloi commits the changes to the branch with you as the author.
To commit only some files, list their paths, one per line. The next commit only sees changes made after the last one. A commit with nothing to commit finishes with no new commit, and the job says so.
What is never committed
Uploads, caches, wp-config.php, the Avaloi plugin, and the paths in the ignore: list of avaloi.yml stay out of Git. Files that look like secrets (.env, wp-config-local.php, private keys, database dumps) are left out too, and the card names them. Keep secrets in environment variables.
When the branch moved on
If someone pushed to the branch or merged into it since staging last pulled, Avaloi combines your commit with the new commits and staging ends on the result. If the same file changed in both places, nothing changes and Avaloi lists the files: resolve the conflict in Git, push, and pull.
Running a read-only release instead
Switch the environment to Git mode to make it read-only again. Commit first: Avaloi says how many changes are uncommitted and offers Commit and switch (with a message) or Discard and switch, so nothing is lost by accident. The environment then runs a release of its last commit.
A promote, a merge, and a new multidev all build from a commit. When an environment in SFTP mode has uncommitted changes, commit them first, or promote with a commit message. A merge needs both sides clean, or it answers 409 working_tree_dirty.
Getting the code to live
A commit moves code on the branch. It does not change live. Promote staging to live from the Staging to live panel; from a multidev, merge into staging first. See Staging, live, and multidev environments.
Not yet
- A line by line diff of each file before a commit is not shown yet. The card lists the files.
- Commits to a connected GitHub repository are not built. Those need the provider connection first.
Related
Still stuck?
Email [email protected] with your site name and what you tried, or send us a message.