In the previous 2 installments we've setup source control in DDE, ensured we can push/pull to/from the repository and went over importing code from a repository into a new nsf. Today we will be covering creating a new branch, making a change in that branch and then merging the change back into the main code stream. This is a very powerful feature of git and is an excellent way to keep "active development" separate from your production code.
To set the stage for this, we're assuming that a bug fix is needed for an nsf. We want to make a new branch from the existing production code, make our change, test it and then merge our change into the production code.
To start off, do a "Fetch from Upstream" to ensure you're working with the most up-to-date code. Next, create a new branch by right clicking on the repository and selecting "Switch To\New Branch".
In the resulting dialog enter a name for the branch that's meaningful and click the finish button. You will notice that the branch shown in the Git Repositories tab now lists your new branch. This branch is an exact duplicate of the production code stream, so it should function just as the production code stream functions.
Now that you have a new branch in your repository, right click the repository and select Pull, then right click your nsf and select "Team Development\Syncronize with On-Disk Project". This should get your existing nsf to the newest version of the code. You may have to do a build to see that new code reflected in the XPage app.
You're now ready to make your changes, test and commit new code without affecting the production code stream. This is what makes branching so powerful, you can pursue an idea that you're not sure will work without affecting the production code. Everyone else can continue to work without being affected by anything you may break with the changes you make.
Once you're done with your changes and you're satisfied that everything is working as it should you can now right click the nsf, select "Team Development\Syncronize with On-Disk Project". Then right click the on-disk project and select "Team\Commit" and finally right click the repository (or the on-disk project, either one doesn't matter) and select "Team\Push to Upstream" if you want to be able to share your branch with someone else. If you don't want to share your branch, the "Push to Upstream" is optional.
To merge your code back into the production code stream, in the "Git Repositories" tab, right click the repository and select "Switch To\master" (or whatever branch you and your team are working out of). This sets your repository back to using the production code. Right click the repository and select "Merge".
In the resulting dialog select the branch we created and click the merge button.
In the resulting status dialog click OK and the merge is now completed. The only thing left to do is push your changes to upstream by right clicking the repository and selecting "Push to Upstream" and that's it, we're done.
The branching and merging portion of git is very powerful and allows you to experiment on your own, with production code without the risk of breaking the production code. I do admit that there is a bit of a learning curve involved with git and there are many best practices listed in various locations by just doing a google search. Also, if you encounter any errors, a quick google search of the error should get you what you need in order to fix the problem. I hope you enjoyed this series.