2015 was a pivotal year for my life as a developer, due in no small measure to the impact of open source software both on how I go about writing code, as well as on how I interact with other developers.  If I had to select one word to describe the reason for this, it would be: collaboration.  It’s not just that open source development demands a greater degree of collaboration, but the acceleration of open source as a movement during the past couple of years has actually redefined software development as a highly collaborative process.

In plain English, this means that software quality depends on how well I can work with others.  However, in the past it hasn’t been very easy to make collaboration a seamless part of software development.  You could do real-time collaboration (also known as pair programming), but few employers were willing to support it, and it was difficult to pull off when team members were scattered across different time zones.

To add insult to injury, centralized version control systems, such as Team Foundation Version Control or Subversion, made common tasks, such as branching and merging, much more arduous.  All of this changed with the widespread adoption of Git, a distributed version control system which makes first-class citizens out of branching and merging.

This has actually changed the way I write code.

To start with, it’s helped to organize my development.  For example, when I want to work on a bug fix or new feature, the first thing I’m going to do is create a branch. This keeps me from working on more than one thing at the same time. But if I do want to multitask, I can stash changes, switch to another branch to do something else, then come back and pick up where I left off.  When I’m working on a branch, the process of committing my changes also forces me to try to better organize my work, by logically grouping my changes into commits.  I can also compare what I’m currently doing to the prior commit to see how refactoring has helped eliminate code smells.

While Git has had an impact on how I personally write code, what has transformed software development into a truly collaborative process has been the rise of code hosting services such as GitHub, Bitbucket or Visual Studio Team Services, which provide tools for implementing a collaboration workflow based on Git, with work isolated into branches, organized into commits and documented with commit messages.

If I am working on my own public Git repository, then the workflow might take place as follows:

1. Open an issue describing a defect or desired feature.  Here I can add comments, insert code snippets, refer to other issues or lines of code, as well as reference other issues.
    
2. Create a branch for working on the issue. Here I can write code or change existing code, then commit changes with descriptive messages.
    
3. Publish the branch, at which time GitHub will show a “Compare & Pull Request” button, which I can click to create a pull request.  This will allow other developers who have cloned my repository to create a local branch based on the pull request, so they can look at the code I’ve written. Other developers can then comment on the pull request, and we can have a discussion about the the issue, even referencing specific lines of code.  If I am trying to reproduce a particular bug, I can simply write a failing test, commit changes, then push those changes to the public branch, which allows others to retrieve and run the failing test.  When I fix the defect so that the failing test now passes, I can commit the fix and push the commit so that other developers can pull the commit to see how the fix was performed.
    
4. Once I’m satisfied with the code, I can merge the feature branch into the main branch (probably develop or master), then push those commits to the public repository.  At that point, the pull request can be closed (GitHub will automatically close it), both the public and private feature branches can then be deleted, and the original issue can be closed (GitHub will automatically close issues based on commit messages).

If I am working on someone else’s public Git repository, then the workflow will start off differently:

1. The first thing I’ll want to do is fork their repository, effectively copying it over to my own GitHub account.
    
2. I can then clone the forked repo, create a local branch, work on it (for example, write a feature or create a failing test to reproduce an exception), then publish my local branch to my public repo.
    
3. Once I’ve published a branch I can create a new pull request, which others can then pull to see what I’ve done, without affecting any other work they may be doing.

What Git and GitHub essentially provide is the ability to share code with others and facilitate discussions in a structured workflow. That’s powerful stuff.

But the ability to leverage these tools depends on how widely they’ve been appropriated by members of the developer community.  And that means developers are going to need to get out of their comfort zone to learn how to use Git and GitHub (or another hosting service).  The good news is that most popular IDE’s and code editors have decent Git integration, which allows you to perform most Git tasks using a GUI interface right from within the IDE.  Other Git clients, such as TortoiseGit and SourceTree, ease many tasks, but there are some Git commands, such as interactive rebase, where you’ll need to pull up a terminal window or command prompt.  Interactive rebase can be tricky at first, but it lets you squash certain commits and consolidate messages for a cleaner version history.

One of things which can trip up Git noobies is not providing a proper .gitignore file with their repo.  GitHub provides .gitignore file templates for various IDE’s.  Not using the correct file will make it difficult for others to build your solution without getting spurious errors.  For example, if you’re using Visual Studio without the correct .gitignore, you may check in package, bin and obj folders, which is can interfere with restoring NuGet packages when someone else tries to build the solution.

To help you get up to speed on this new collaborative approach to software development, you should check out some of the many free Git tutorials available online.  Then you should bite the bullet and contribute to an open-source project.  Feel intimidated?  Scott Hanselman has created a First Timers Only web site specifically targeted to people who are dipping their toes into the open source waters.

I’ve been privileged to author a couple of popular open source frameworks: Simple MVVM Toolkit and Trackable Entities.  I created the first project prior to embracing Git, but I moved the second project to GitHub early on and have had other developers contribute to the project, which has encouraged me to fully adopt the Git way.  I also had the opportunity to submit some pull requests to Microsoft’s ASP.NET 5 repo on GitHub, where I learned how to rebase my feature branch and resolve conflicts to stay in sync with upstream changes.

One of the things that propelled me further into open source has been the way in which Microsoft has jumped on the bandwagon.  Not only have they opened up their code for developers to look at, they have invited others to take part in the process by allowing them to open issues and submit pull requests.  That’s huge.  And it’s a model for how companies large and small stand to benefit from this new way to build software by sharing code and allowing collaboration with the help of tools from Git and GitHub.

I hope your journey into open source is as enriching for you as it has been for me.

May the Source be with you!