If you have a module you wish to use and that is only hosted on GitHub (which is an online Git service for sharing code using Git), you can create a local Git repository and make the GitHub module a submodule of your modules. Another use for a local copy is if the public module does not work entirely as you require, you can modify the public module in your local copy.
This workflow has issues; submodules are local to each working copy of a module. When working in an enterprise, the internal servers do not usually have access to public Internet services such as GitHub. To get around this access problem, you can create an internal Git repository that is a clone of the public GitHub repository (the machine which is performing the clone operation will need to have access to GitHub).
We'll start by cloning the public repository as our git user:
[root@stand git]# sudo -u git bash [git@stand ~]$ pwd /var/lib/git [git@stand ~]$ git clone --bare https://github.com/uphillian/masteringpuppet.git Cloning into bare repository 'masteringpuppet.git'... remote: Counting objects: 4, done. remote: Compressing objects: 100% (3/3), done. remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (4/4), done.
We now have a local copy of our public repository. We'll create a checkout of this repository as our remotedev user on the client machine as shown here:
[remotedev@client ~]$ git clone git@stand:masteringpuppet.git Cloning into 'masteringpuppet'... remote: Counting objects: 4, done. remote: Compressing objects: 100% (3/3), done. remote: Total 4 (delta 0), reused 0 (delta 0) Receiving objects: 100% (4/4), 4.14 KiB | 0 bytes/s, done.
Now we'll create a local branch to track our internal changes to the module and name this branch local, as shown here:
[remotedev@client ~]$ cd masteringpuppet/ [remotedev@client masteringpuppet]$ git branch local [remotedev@client masteringpuppet]$ git checkout local Switched to branch 'local'
Now we will make our change to the local branch and add the modified README.md file to the repository. We then push our local branch back to the server (stand):
[remotedev@client masteringpuppet]$ git add README.md [remotedev@client masteringpuppet]$ git commit -m "local changes" [local 148ff2f] local changes 1 file changed, 1 insertion(+), 1 deletion(-) [remotedev@client masteringpuppet]$git push origin local Counting objects: 8, done. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 584 bytes | 0 bytes/s, done. Total 6 (delta 1), reused 0 (delta 0) To git@stand:masteringpuppet.git * [new branch] local -> local
We now have a local branch that we can use internally. There are two issues with this configuration. When the public module is updated, we want to be able to pull those updates into our own module. We also want to be able to use our local branch wherever we want the module installed.
To pull in updates from the public module, you have to use the git pull command. First, add the public repository as a remote repository for our local clone as shown here:
[remotedev@client masteringpuppet]$ git remote add upstream [email protected]:uphillian/masteringpuppet.git [remotedev@client masteringpuppet]$ git fetch upstream
The git fetch command is used to grab the latest data from the remote repository. With the latest version of the data available, we now use the git pull command to pull the latest changes into our current local branch as shown here:
[remotedev@client masteringpuppet]$ git pull upstream master From github.com:uphillian/masteringpuppet * branch master -> FETCH_HEAD Merge made by the 'recursive' strategy. manifests/init.pp | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 manifests/init.pp
This will create an automatic merge of the upstream master branch in the local branch (provided there are no merge conflicts). Using the git tag command can be useful in this workflow. After each merge from the upstream public repository you can create a tag to refer to the current release of the repository. Using this local copy method we can use public modules within our organization without relying on direct connections to the public Internet. We are also able to make local modifications to our copy of the repository and maintain those changes independent of changes in the upstream module. This can become a problem if the upstream module makes changes that are incompatible with your changes. Any changes you make that can be pushed back to the upstream project are encouraged. Submitting a pull request on GitHub is a pain free way to share your improvements and modifications with the original developer.