A great feature of Git is the ability to create branches. Branches allow for creating your own snapshot of the master branch in order to add a new feature or create a hotfix without affecting the master branch of code. Once your change is completed, you can merge your branch into master so your feature or hotfix is now part of the main code branch. In this post I’m going to show you how to create a branch, make a change in the branch, commit the change, merge the branch into master, then update the remote repository. The change I’m going to make is for my SkypeOnlineFunctions PowerShell module. I need to add a new license to check for in my Get-SkypeOnlineTenantLicenses command.
First, I need to clone the repo onto my local system using the git clone command and the URL of the repo (firstname.lastname@example.org:JeffBrownTech/Skype.git):
Once in our cloned repo, I can check to see what branch I am currently on as well as any other branches that exist using the git branch command. I can create a new branch named “add_license” with the command git branch add_license. After viewing the new branch, I switch to the new branch using git checkout add_license.
If I were to run git branch again, “add_license” would be green and have the asterisk next to it. This is to indicate this is where HEAD currently is. Right now, the master branch and add_license branch currently point to the same commit since I haven’t made one in my new branch.
Now that I have my branch to make any changes I need, I modify the SkypeOnlineFunctions.psm1 file and add a new license check on the Get-SkypeOnlineTenantLicenses function.
Just to verify, I can run git status to show which files have changed and if they are currently added to my staging area for committing. I can also view what changes have been made by running the git diff command, and I can see the new license I added in green.
Next, I add my changed file to my staging area and perform a commit at the same time using git commit -a -m “<message>“. The -a parameter adds all untracked files to the staging area. Running git status now shows that we are up-to-date on the branch and there is nothing else to commit.
When I run git log in the branch to review the list of previous commits, HEAD is currently pointing to our add_license branch and is a commit past the master branch. It’s also showing that our remote repo or origin is currently at the same commit as the master branch, so they are the same.
Switching back to the master branch and running git log shows it does not know about the add_license branch or its commit:
So let’s make the master branch aware! I can take the add_license branch and merge its changes and commits into master by running git merge add_license from the master branch. Running git log after the merge shows that master and new_license branches are both pointing to the same commit and is one commit ahead of our origin or remote repo. Running git status also confirms that our local repo is one commit ahead of the remote repo.
Finally, I can run git push origin master to push the updated local master branch to the remote repo currently hosted on GitHub. This will bring the remote repo up to date with the local repo with its commits. Running git status again after the push will show that the local master branch and remote master branch are now the same.
Going back to GitHub, the commit is now reflected on the SkypeOnlineFunctions.psm1 file with the commit message.
While this was a simple example, using branches and merge in Git is what enables it as a powerful versioning system.
Questions or comments? If so, drop me a note below or find me on Twitter or LinkedIn to discuss further.