In our earlier steps, we isolated our working code into a feature-branch and a short-lived, non-production environment. While teams and organizations should select some merging safeguards and strategies, such as peer code reviews and automated testing, this section will focus on the steps required to merge branches into master or long-lived branches in Puppet. Enterprise and open source web-based Git solutions usually contain some extra controls to indicate who can merge into a repository, and to which branches. The general best practice is to allow for a peer review of code, and the reviewer can accept the code into the long-lived branch or master branch. Merging our code via the command line is a simple process, as follows:

1. Switch to the branch that you want to merge to (git checkout)
2. Merge another branch into this one (git merge)
3. Push the merged branch into upstream repository (git push):

# Many Enterprise-focused git repositories have built in merge features, that ar
# likely more robust and easier to use than a simple git merge. If you have an in
# house git solution, follow the program documentation on a merge request

# On Module
# We'll change to target branch, in this case master
$ git checkout master

$ git merge feature_branch
Updating 0b3d899..227a02e
Fast-forward
 README.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

# Push the branch to upstream repository so Puppet can find it.
$ git push origin master

Merging in the control repository can sometimes be troublesome, due to the Puppetfile being (intentionally) different between versions. Our production-like branches should use Git tags to declare the intended version of the code to be deployed and promoted up the series of environments. Our non-production-like environments are generally pointed to the master branch of each module, providing the latest accepted stable code to the environment for testing and development. Merging is performed in the same way as with a component module; just ensure that you don't overwrite the Puppetfile on a production-like branch with the less controlled Puppetfile in a non-production-like branch. Production branches should refer to Git tags for deploying code.