Once we're inside of the local copy of the intended environment, it will be the right time to make changes to the code. We generally spawn these additional short-lived environments so that simple commands can be used to deploy new code. We have a few files to target, because we think of the control repository as a configuration file for the rest of the environment. The Puppetfile is used to manage dependencies, including any component modules (from the Forge or your own environment). roles and profiles are often kept in the control repository, as well, and code can be edited directly in these environments. The workflow for making changes in the control repository is as follows:

1. Edit the files (in the IDE of your choice).
2. Make a snapshot of the current state of the code (git add and commit).
3. Send the environment back to the remote repository (git push):

# Edit our files

# Change the branch of the component module to new_feature
vim Puppetfile

mod 'module',
  git => [email protected]:puppet/module.git,
  branch => 'new_feature'

# Make a change in the profile that utilizes the component modules
vim site/profiles/manifests/baseline.pp

# Add our new changes, to be staged for a commit
git add .

# Commit our changes
git commit -m 'Supporting new Feature to support <effort>'

# Push our code back to the control repository as a new branch intended to be
# realized as a new environment on the Puppet Master
git push origin new_feature

At this point, we've edited a module and files in the control repository and pushed them back to the origin. We'll now deploy the branch we made in the preceding code, and we will tweak our profile to use the module changes. Unless you have set up Git hooks or a CI/CD solution, you'll also have to trigger an environment deployment on the Puppet Master.