Forking and Cloning from GitHub Contributing to open source projects (Part 1)

In this post I’m going to share the initial steps that you will need to take in order to be begin contributing to an open source project. I’ve covered this more generally in the past and wanted to provide a more focused post that covered these steps for a new open source contributor. For this post we’ll use the Humanitarian Toolbox allReady project as our example.

Forking a Repository

When beginning to contribute to a project on GitHub, your first step is to fork the repository. This creates a copy of that repository under your own account enabling you to begin working with the code. The rights to public repositories will be such that you can view the code, but not directly commit into the repository or create branches. This allows the project owners to control changes within their codebase. Changes are made via pull requests; which we’ll cover in a future post.

The forking step creates a copy to which you do have permission to commit and branch on and you can consider this your working copy of the project. You can make changes and commits here, safe in the knowledge that you will not affect the main repository.

The process of forking on GitHub is very simple. Make sure you are logged into your account on GitHub and then open the project you are interested in contributing to. In this example I’ll navigate to Once inside the repository you will see a “Fork” button in the upon right hand corner of the UI. Click on this button to begin the automatic forking process.


GitHub Fork Button



GitHub forking progress

Within a few seconds you’ll have your completed fork.

Cloning your Fork

Now that you have your fork, the next step is to clone the code down to your local development machine. Again, GitHub make this quite simple in their UI. To clone a repository you will need its URL. Clicking on the “Clone or download” button will open a UI showing the Git URL. A button to the right hand side of the URL allows you to copy it into your clipboard.

GitHub Clone or Download button

To perform the clone operation I’m going to demonstrate using the command line. There are various graphical tools you can use to work with Git repositories but for simple procedures, the command line is often fastest.

Open a command window and navigate to the path where you would like to clone the repository.

Use the following command to begin a clone:

git clone

Here we’ve pasted in the URL of the fork that we just copied as the argument to the “git clone” command. You will see the output of the clone command as it clones the contents of your repository onto your local device.

Git clone progress

Once the command completes you will have a new folder containing the cloned repository. We can validate this by running the “dir” command.

Directory after cloning

Next we’ll need to navigate into the newly cloned folder. Will do that with the following command:

cd allReady

Registering an Upstream Remote

The final step is to setup a remote which points to the main repository. Remotes simply represent paths or URLs to other versions of your repository. In our case, as we cloned from our fork on GitHub a default remote will have been setup for us called origin. This origin allows us to push and pull code from our forked repository hosted on GitHub. We can list the currently configured remotes on our machine using the “git remote” command.

Default git remote for origin

Pushing and pulling from your own fork is very useful and this will be how you will work with the project most often. However, when working on that code, you’ll want to be starting from the most recent version of the code from the main allReady repository. That code may have been updated and changed since you first made your fork. In order to get access to that latest code, we’ll setup a second remote which points to the main allReady repository. We will not have commit rights there, so we cannot push changes, however, we will be able to fetch the latest commits that have occurred.

To create a new remote we use the “git remote add” command, passing in a name for the new remote and the URL as arguments. First we need the git clone URL for the remote we want to add. We can get this by heading back to GitHub in our browser. From our fork we can use the convenience link to take us back to the main repository from which we forked it.

Switch to fork parent repository on GitHub

Once back in the allReady main project we can use the same steps as we previously used to access the clone URL via the “Clone or download” button and copy it to our clipboard.

Back in our command window; to add our remote for our allReady example we’ll use:

git remote add upstream

We could name the remote anything we like, but the convention is to use upstream, so we’ll follow that.

If we run the “git remote” command again we can verify that we now have two remotes.

After adding upstream remote


That’s as far as we’ll take it in this post. We have forked a copy of a repository, in this case allReady, and then cloned the code down to our local machine. We’ve down the work needed to setup an extra remote and we are now in a position to begin working on our first issue. We’ll cover that in a future post.

If you are a visual learner, then I have a video which covers the topics in this post available up on my YouTube Channel

Other posts in this series

Part 1 – This post
Part 2 – Working on Your First GitHub Issue

2017 – The Year in Review Looking back at an exciting 2017

2017 was an incredibly fun, exciting and busy year for me. I’m a bit late in pulling it together but I wanted to write this year in review post.

2017 Highlights

For me there are a few distinct highlights that come to mind in a year packed full of goodness…

MVP Award

The biggest highlight by far was being nominated for, and later being presented a Microsoft MVP award. To say it was a dream come true would not be true, as I’d never even considered dreaming it before being nominated! I’m still getting used to the idea of joining such an amazing group of community leaders, experts and enthusiasts. My trophy sits pride of place on my desk at home and I often glance at it to reassure myself it actually happened!

Microsoft MVP Award Pack

Public Speaking

I kicked off my speaking “career”; first with some small internal talks at work, then a 20 minute public talk in April, next a talk at London .NET User Group and then two conferences. One in London for Progressive .NET, one in Germany at ADC Core! In January last year, I would have laughed at anyone that said that within the year I’d be volunteering to talk in front of a room full of people! I’m gaining my confidence, experience and most importantly enthusiasm to present more talks in 2018. I’m applying to conferences and planning new talks that I hope will benefit the community. I found a passion for sharing with the community and giving back, since I have personally learned a lot from other writers and speakers over the years.


I again managed to carve out some time to contribute to the Humanitarian Toolbox, allReady project. During 2017 I submitted 45 pull requests to the project, with 121 commits. Some of the biggest work involved migrating from 1.0 to 2.0 of ASP.NET Core. I’ve gotten more involved with helping plan and manage issues, answer questions and review pull requests. It’s a fantastic team and a project I love working on. I also created a little OSS library for basic correlation IDs on ASP.NET Core APIs. It was something we needed at work that I chucked together one weekend and published to NuGet. It’s had nearly 17,000 downloads!! I guess that number is skewed by CI systems and the like, but still way more than I imagined would ever pull it down! I completed a 2.0 upgrade for that project during the Christmas break which added a context concept that might be useful.

Meeting People

I got to meet some great people within the community, as well as forming friendships both online and off. As a naturally introvert and shy person, this hasn’t come easily but I’m building my own self confidence, the more I put myself out there. I got to meet a few people I never expected to meet in person which was a real bonus. Much of that has come from the two items above, contributing to allReady and starting to speak at conferences. In additional I’ve got to know many people via Twitter and enjoy being engaged with the community directly. I learn a lot from the blog posts and content shared via Twitter and rarely does a day pass without my flagging something to read later.

Twitter Growth

My Twitter follower count has grown dramatically this year. On the 10th of January 2017 I marked the milestone of reaching 100 followers with a tweet. By the close of the year I got close to 700 followers which seems incredible to me. I hope this is because my content is resonating with people and being deemed useful. Thanks to everyone who follows me and engaged with me in some way in 2017. Let’s make it at least 1,000 followers this year! That would be very cool!


My blog has been a big focus for me in 2017. I published 45 posts during the year, which looking back is coming on for 1 per week on average. I really love writing for my blog and sharing what I’m learning. Much of the content is ASP.NET Core related, although Docker is featuring heavily too. I’ve started to try and write more soft-skills type posts as I develop myself personally and professionally. For example I wrote two long posts focused on my progress from hating public speaking, to actually really enjoying it. I enjoyed writing something a bit different and while they are long and probably not to everyone’s taste, I had some nice feedback. I’ll hopefully break down some shorter posts early in 2018. I’ve been honoured that a lot of my posts have been featured on the ASP.NET Community Standup by Jon Galloway. That’s certainly helped with reach. In terms of numbers, I’ve seen some impressive growth…

Headline Numbers:

  • 117k unique visitors (up  242% on 2016)
  • 185k sessions (up 268% on 2016)
  • 233k page views (up 290% on 2016)

I’m not sure how that compares to other blogs, but I’m happy with that reach and the growth factor. I’d love to keep growing it in 2018 and will aim to keep up the flow of quality posts. I have many drafts from 2017 left partially worked on which I will pick up against soon!

I also took a quick look at my top 10 posts:

Blog Post

Unique Pageviews

R.I.P project.json – Out with the new, in with the old


How to Send Emails in ASP.NET Core 1.0


Docker for .NET Developers (Part 1)


Migrating from .NET Framework to .NET Core


Implementing IHostedService in ASP.NET Core 2.0


Docker for .NET Developers (Part 2)


CQRS with Mediatr and ASP.NET Core


Upgrading to ASP.NET Core 2.0


Getting started with ASP.NET Core 2.0 Preview 1


ASP.NET Core Identity Token Providers – Under the Hood


The project.json one got a lot of traffic not long after the announcement of it’s demise! Good to see Docker up there. Interesting that the how to send emails in 1.0 is so popular. Maybe I need to produce and update for 2.0 that covers the options we have now!

.NET Meetup

For a while I’d craved a local user group focused on hosting speakers for .NET related topics. I started attending Brighton ALT.NET early in 2017 which is a long running group hosted by Mike Hadlow. It’s a fun event and I enjoy attending, however it’s format is discussion based and I still wanted an option to see speakers present longer topics. This kept coming back to me during the year and by mid 2017 I started to seriously consider starting a meetup. However I was worried about how to go about it. Where would I even start? In the end I decided to simply bite the bullet and put one together. I created a .NET South East meetup account, agreed with Madgex, my employer, that I could kindly use their office space and got planning. It all came together quite quickly and we had our first event in August. The membership has exceeded my initial imagination and we get a good turnout of regulars. Our busiest night was when we arranged for an evening with Jon Galloway that packed the space we had with nearly 60 people. I’m so glad the community are getting behind the group and the feedback is always positive. Thanks to all of the speakers and attendees who’ve made it a reality. Thanks especially to some of the Madgex staff who have continually supported the logistics of the events. Big shout out to Chris Sargood in particular who’s helped me with every event.


My career has progressed at Madgex and I enjoy every day working for them. I’ve got to work on some exciting greenfield technology, building our new reporting system using the latest tools. I learn a lot from working within such a great team of people. I was very happy to be promoted to senior developer during the year and towards the end of 2017 took on some extra responsibilities as a developer community lead. I’m excited about the goals of that role and look forward to working with everyone more closely in 2018.


I’m continuously learning and my personal view is that you have to proactively work at learning new things, consuming new ideas and experimenting all the time. I’ve learned a lot simply by working with new technology in my day job as well as a significant amount from contributing to Humanitarian Toolbox. I love developing and keeping up with the ASP.NET Core space in particular. I watch a lot of recorded conferences and online video content as primers on topics. I then seek blog posts to dive in a bit deeper. I spend a fair bit of time watching the notifications on the ASP.NET Core repositories and reading some of the code there which I find very useful. One of my best learning tools though has been to teach. I found that I learned so much from each and every blog post I put together. Speaking has taken me even deeper as well. I can’t recommend sharing content enough as a way to develop your skills and truly understand something. It’s a win-win!


Late in 2017 I started thinking about recording some YouTube videos. I’d been approached by a couple of online course providers about creating content, but honestly felt I needed some more experience first. In November I started experimenting and in December I recorded my first video about ASP.NET Core Startup, focusing specially on Program.cs. I was quite happy with the content for a first try, but the quality was not quite at the level I wanted, so I invested in some new equipment, including lighting and a proper microphone to hopefully take me to the next level. I’ve since managed one more video, this time about Dockerfile Basics and it’s an improvement over the first video. They’ve gained quite a lot of views (around 700 between them) in a short space of time which has encouraged me to put more time into this during 2018. It’s a lot of work though! I’d like to consider producing a formal course as well if I can find the time and some content that’s not already been covered!

Looking to 2018

I’ve been setting personal goals and noting down ideas for 2018 for the last month or so. Much of it is really to build on 2017. Keeping up blogging, doing more video content and hopefully speaking at more conferences. Overall it’s about being part of the community, earning my MVP wings and sharing what I can with others. Hopefully some of my crazier ideas will become a reality too. I’ll save those until they happen! A key thing I learned in 2017 is that anything is possible if you put the work in. I achieved far more than I would have written in a list at the beginning of the year!

Here’s some larger things on the list for 2018

  • MVP Summit – This is the big one for me and will be my highlight of 2018 for sure. I’m all set to travel to the US for the first time to visit Microsoft HQ in Redmond. It’s an extremely exciting opportunity to meet fellow MVPs as well as interact with the Microsoft teams directly. I’m told it’s a very tiring and packed experience but so, so valuable.
  • NDC London – In a week and half I’ll be attending NDC London. I’ve always wanted to go to an NDC conference in person. Last year I took part in a two day codeathon for Humanitarian Toolbox before the main conference but this year I get to pack in three days or learning and networking. I’m really looking forward to catching up with some people from the Twitter world as well as hopefully meeting a few “tech celebrities”!
  • Humanitarian Toolbox codeathon – The day after NDC I’m very excited to have been able to organise a codeathon in Brighton. I’ll be joined by Richard Campbell to spend a day coding with developers from Madgex and the Brighton community. It’s going to be an exciting and hectic day. I love introducing new people to the allReady project though.
  • Videos – I plan to spend more time recording in 2018 now that I have learned the basics. Why not subscribe to my channel to be notified of new content?
  • Live Coding – I’d like to try some live coding in 2018. It’s an intimidating idea but I think it’s well worth trying. I’ve been watching Jeff Fritz do regular sessions and it’s very inspiring. I also think it’s extremely valuable to see someone code “for real” and not in an edited video. Don’t get me wrong, there’s lots to learn from video training courses and it’s a big part of my learning pattern. The polished videos are great when you want to learn a topic. However, edited videos do tend to disguise the reality and the challenges of coding, obscuring the picture for junior developers which can lead to people feeling under skilled. I know I’ve left videos feeling like I’m not skilled enough, but those videos are likely shot multiple times and edited together to give that clean, slick impression. Live coding lets people see that we’re all human. We miss things, get stuck at what later seem like obvious blockers, make errors and forget stuff. I’m sure we all write sloppy or poorly crafted code at times! My plan would be to live code as I work on issues for Humanitarian Toolbox. The main problems is scheduling as I’m not sure I can easily commit to specific, regular days/times which does make it harder for people to join in live.
  • Blogging – Lots more blogging in 2018 I hope. I want to continue some of the series I started in 2017 as well as finding new areas to explore and topics to cover.
  • Speaking – I definitely want to do more talks in 2018 now that I’ve got my feet wet. I’m actively submitting to talks and developing ideas for a range of new topics. As well as conferences I hope to get to some of the UK meetup groups as well.
  • Learning – As I said earlier, this is a continuous effort for me. You get out what you put in. I’ll be reading a lot of blogs and books, watching videos and hopefully attending some conferences. My particular focus is on the deeper internals of .NET and focusing on performance and bench marking. As ever I’ll dive off into any tangents the Twitter community provides!


So it”ll be a great 2018 I’m sure. Thanks to everyone I met, talked to or interacted with in 2017.

Producing my First ASP.NET Video How I recorded ASP.NET Core 2.0 - Exploring Application Startup

This weekend I published my first ever technical video on YouTube. It’s a short 8 minute introduction which explains how an ASP.NET Core 2.0 web application starts up. Specifically I chose to explore the contents of the Program class, digging into the IWebHostBuilder. It’s designed primarily for beginners to ASP.NET Core, but hopefully it will also be of interest to developers who have some experience of ASP.NET Core already.

I’ve been wanting to record some video content for a long time but it’s always been something that has slipped down my list of things to do. This past week I managed to grab some time in the evenings to experiment with the recording process and on Saturday I had a whole day free where I could focus on the recording, editing and production of my first video.

The first thing I learned is that it takes a lot longer than you might think to produce a completed video. I expected to be done by midday but in reality I wasn’t able to complete the upload before about 4pm in the end. To be fair, a lot of that was simply learning the process. I was using Camtasia for the first time and so some of the time was spent getting up to speed with that too. In the end, including experimenting with the setup, I think I spent between 6-8 hours to get this single 8 minute video finished. I expect that to reduce as I do more videos and purchase some proper equipment but it’s still a much larger investment than blogging!

The toughest issue that I faced was with the lighting. My home office is not the most well lit room in the house, and with a gloomy sky outside it was fairly dark. For this first video I put together a basic homemade setup using a couple of lamps and a reflector. My wife and I are part time photographers, so having the reflector to hand was useful. It’s not a perfect setup but it was enough to get me somewhat reasonably lit.

Based on this great post from Scott Hanselman I now have ordered a small Neewer CN 160 LED video light from Amazon which I hope will make the setup more repeatable and professional in the future. I’m hoping it arrives in time to test it out before Christmas.

The next challenge is good audio. I had a couple of options initially; using the built in audio from my Trust HD webcam or using my Microsoft headset. Neither felt like a great option so I decided to try recording the audio separately via my phone. I used my Samsung hands free headphone with microphone which I positioned in front of me connected to my Galaxy S7. I then used a Voice Recorder app on my phone to record the audio. I remembered to clap loudly at the start of the video so that I could sync up the sound and video later.

This worked reasonably well and the sound is okay for now. I used a the noise reduction enhancement in Camtasia to clean it up a little and then did some volume leveling as well. I found that getting the video and audio syncing spot on was quite difficult as Camtasia only allows the movement of tracks by frames and after one perfect take I couldn’t get the audio perfectly aligned. It was just enough out that I had to ditch that recording. My next attempt worked a lot better. Once I do more videos I’ll look to invest in a decent USB microphone and stand.

Here is my final setup for this first video:

My video recording setup

And here is the final video:

I’ll try to write a more thorough blog about the video recording process once I’ve developed it further and got it to a point where I think it’s useful for others. I hope to be able to make more time to record new content to share with you soon. Until then, please check out the video and like/share if you enjoy it. I’d welcome your comments and feedback as well.

ASP.NET Core Gotchas – No. 3 Why don't my hyperlinks work on my Razor Pages in ASP.NET Core 2.0?

Recently I decided to take Razor Pages, a new feature in ASP.NET Core 2.0, out for a spin. I’ll be blogging about that experience and how I migrated some basic views of an existing application over to Razor Pages in a future post.

In this blog post I wanted to concentrate on a simple gotcha which left me confused for a little while. You are only likely to hit this issue if you are starting with an existing MVC based web application and migrating some or all of your Views over to Razor Pages or starting with an Empty web application template. New Razor Pages based projects using the “Web Application” template will be setup correctly by default.

The symptoms I experienced were that after moving some of my Views and making them Razor Pages, the hyperlinks were not working. This seemed rather strange. They rendered on the screen as hyperlinks (picking up the styling of other anchor tags) however, they did nothing when clicked.

My links were defined as follows in my Razor Page…

<a asp-page="/Index">Home</a>

When viewing the source in Chrome of the rendered page I saw the following…

<a asp-page="/Index">Home</a>

That’s odd! For some mystifying reason the link was not being rendered as expected. This was the first clue though, missing rendering. ASP.NET Core uses the concept of tag helpers which provide a mechanism to write Razor code that later gets rendered at runtime into the final HTML output. Tag Helpers provide a convenient syntax that keeps code in our cshtml files much cleaner. Pre ASP.NET Core we’d have used the @Html.ActionLink method to render a link onto a Razor view based on the controller name and action name for example.

With Tag Helpers we can write code which is much closer to HTML, using the traditional anchor tag <a>. Tag Helpers provide the magic which look for certain tags and then render out the necessary HTML code. In the case above, asp-page should look up the route for the designated Razor Page and render the appropriate href attribute in its place in the final HTML output.

So, it appeared that the Tag Helpers were not working on my Razor Pages. At first I couldn’t think of a reason why this would be the case until I suddenly realised, with Razor we need to make Tag Helpers available using the @addTagHelper directive. This controls in which Tag Helpers are available. In MVC Views this is generally defined in a _ViewImports.cshtml file at the root of the Views folder. This is then inherited on all Views within that folder and it’s sub directories.

I’d wrongly assumed that Pages would also pick up this existing ViewImports file from the Views folder. However, Razor Pages expect their own _ViewImports.cshtml within the Pages folder. In my case, to solve my problem, I simply copied the _ViewImports.cshtml from the Views folder into the Pages folder and tried running my application again. As expected, my anchor links were now rendering as expected. In mixed environments using traditional MVC Views as well as Razor Pages, you’ll need to include _ViewImports.cshtml in both locations.

You can also run into a related issue with missing layout and styling if you do not include a _ViewStart.cshtml file pointing to your shared layout page within your Pages directory too. Note that you can actually use Layouts from within the Views/Shared folder and you do not need to copy these into the Pages folder. Only the _ViewStart.cshtml and _ViewImports.cshtml need to be replicated.


Other posts in the ASP.NET Core Gotchas Series:

No. 1 – Why aren’t my Environment Variables loaded into ASP.NET Core 2.0 configuration on Linux?

No. 2 – Why are settings from launchSettings.json now picked up when using dotnet run?

ASP.NET Core Gotchas – No. 2 Why are settings from launchSettings.json now picked up when using dotnet run?

Following on from my first gotcha that we hit yesterday, here is another one which caught us out at the same time.

TL:DR; When using dotnet run (.NET Core 2.0), expect it to set some properties (including the port and environment) from launchSettings.json if it’s included in the Properties folder!

The issue we faced was that when running a new API using ASP.NET Core 2.0 inside a container, it was starting on the wrong port; not port 80 as we’d expected. The scenario where this can show itself is unlikely to be a common one, so hopefully only a few people will run into this exact gotcha.

In our case, prototyping the new API needed some front end involvement so we added a quick and dirty dockerfile and docker-compose.yml file to enable it to be spun up inside a container. Normally our production containers are all built on images which are based on the ASP.NET Core runtime image. We then copy in our published dlls and run the application inside the container. However, in this particular case we’d cheated a little and were using the SDK based image to allow us to build and then run the source inside a container.

In our case our dockerfile looked like this (note: do not use this in production!)

FROM microsoft/aspnetcore-build:2.0



COPY . .

RUN dotnet restore --verbosity quiet && dotnet build -c Release --verbosity quiet


WORKDIR /app/src/OurNewApi

ENTRYPOINT dotnet run

The details of what it does are not too important. If you’re interested your can read my Docker for .NET Developers series to learn more. What is important here is that we are copying the entire solution folder contents into the container and later using dotnet run to start it. Seems safe enough – right?

As stated earlier, we noticed that for some reason, instead of using the default ASP.NET Core environment variable (ASPNETCORE_URLS=”https://*:80) which defines the default port of 80 it was using a different port. We also noticed that the environment was showing as “Development” and not “Production”.

We then examined the console output and noticed the following information:

Using launch settings from C:\Projects\OurApi\OurApi\Properties\launchSettings.json…

We checked and indeed, the port being used was the one defined in launchSettings.json. This was a bit of a surprise since in the past that file has only been used by Visual Studio. We scratched our heads as we’d previously done something similar with an ASP.NET Core 1.0 project without hitting any issues. I started investigating and soon found a closed GitHub issue titled “Add support for launchSettings.json to dotnet run”. Reading through it, it seems that since 2.0, dotnet run will load up some settings from launchSettings.json if it finds one. This makes some sense from a developer tooling point of view as I guess there are cases where it could be useful. In our case, the fact we were blindly copying in our entire solution folder (including the launchSettings.json file) as well as starting our API using dotnet run, meant that we experienced this behaviour inside the container. It’s not something we normally face, but in this quick prototype, it showed itself.

The quick solution in our case was to include the Properties folder in our dockerignore file which specifies any folders/files that you do not want included in the build context. This then avoids them being copied into your image using the COPY command.

For the curious among you, this functionality is implemented inside ProjectLaunchSettingsProvider.cs in the .NET CLI repository. If the file is found then the properties from the environmentVariables section are used as well as the value of the applicationUrl property.

Long story short, be aware of the fact that since .NET 2.0 the “dotnet run” CLI command will look for and use a launchSettings.json file if it’s available. If you suspect this may be happening in your case you can check the console output to see if it has loaded from launchSettings.json.


Other posts in the ASP.NET Core Gotchas Series:

No. 1 – Why aren’t my Environment Variables loaded into ASP.NET Core 2.0 configuration on Linux?