Git, GitHub and an open source .NET project – Part 4

I have used the open source enterprise search platform Solr for a number of years now and on a recent project have been using the open source SolrNet .NET client library. The SolrNet library lacked a feature I required when used with the bundled Service Locator implementation. A number of people had been asking for the same feature so I decided to jump in and implement it.

This is part 4 of my journey into learning Git, using GitHub and contributing to an open source project.

The feature

The feature in SolrNet that I was interested in updating revolved around using the built in Service Locator to support multi-tenancy.

No one had volunteered their time to implement this feature as can be seen by a thread in the SolrNet Google Group, so I decided to jump in and implement the feature.

Committing the implemented feature

After implementing the feature I was ready to commit my code to my local repository which was located in my C:\Projects\GitHub\SolrNet folder. I ran the git status command via the Git Bash shell. This will show any new files that I have created or any changes to existing files that I have made.

git status

The Changed but not updated list refers to files that have been modified in the working directory but have not yet been staged. The Untracked files list refers to new files in the working directory that Git does not have in a previous snapshot (commit). All these files need to be added to the staging area in preparation for the commit.

The staging area is where changes can be grouped before being committed. This gives you a lot of flexibility in what actually goes into a commit. There is a nice explanation on the git ready site.

I ran the git add command via the Git Bash shell for each of the files that I needed to add to the staging area.

git add

I then ran the git status command via the Git Bash shell again to confirm that the files were now all in the staging area of my local repository.

I ran the git commit command via the Git Bash shell to commit the changes from the staging area. The -m switch allows you to specify the commit message. I used the issue details Issue 83: Support for multi core using ServiceLocator as my commit message.

git commit -m

I ran the git status command again via the Git Bash shell again to confirm that all staged changes had been committed in my local repository.

Pushing commits to public repository

You may have noticed the following message in the last screenshot: Your branch is ahead of ‘origin/master’ by 1 commit. This is showing that my local repository now has a commit that is not in my public paulbouwer/SolrNet repository. To confirm that the name origin references my public paulbouwer/SolrNet repository I ran the git remote command via the Git Bash shell. The -v switch switches on verbose messages and the show -n action and switch specifies the name of the remote.

git remote -v show -n

I next ran the git push command via the Git Bash shell to push my commit to my public paulbouwer/SolrNet repository on GitHub. I am pushing my local changes to the master branch on my origin remote. Note that the password here is not your passphrase but your GitHub account password.

git push

A final git status command via the Git Bash shell confirms that my local branch is no longer out of sync with my public paulbouwer/SolrNet repository on GitHub.

Confirmation

The commit pushed up to my public paulbouwer/SolrNet repository on GitHub is clearly visible under the Commits tab. Clicking on the commit hyperlink for the commit will take you to the details of the commit.

Next is submitting a pull request and getting the code accepted into the master repository …