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.

GitHub Contributor Tips and Tricks (Gitiquette) My thoughts of being a better GitHub citizen

I made by first GitHub pull request back in November 2015. After a code review I needed to make some changes to the code and the learning curve of Git/GitHub bit me. I had to close my PR and open a fresh one in order to get my code accepted since I couldn’t figure out rebasing. Now a year on, I have had over 100 pull requests accepted on GitHub and have even started helping with code reviews on the allReady project. The journey over the last year started with a steep curve as I got to grips with GitHub and to some extent Git itself.

Back in February in my post about contributing to allReady I briefly covered some rebasing steps useful when contributing on GitHub. In this blog post I wanted to share some further tips and tricks, plus offer my personal views and conventions I follow while attempting to be a good GitHub citizen. I can’t claim to be an expert in GitHub etiquette and I’m still learning as I go but hopefully my experiences can help others new to GitHub to work productively and reduce the pitch of the learning curve a little.

Contributing on GitHub

There is a great post from another allReady contributor and ASP.NET monster Dave Paquette at http://www.davepaquette.com/archive/2016/01/24/Submitting-Your-First-Pull-request.aspx. Dave has covered the main steps and commands needed to work with GitHub and Git in general when contributing to opensource projects. I suggest you read his post for a detailed primer of the commands and GitHub UI.

Git / GitHub Etiquette (Gitiquette)

Rather than repeat advice and steps that Dave has given, in this post I intend to try and share small tips and tricks that I hope allow you to get the best out of opensource and GitHub. These are by no means formal rules and will differ from project to project, so be aware of that when applying them. As an aside; I was quite proud of inventing the term gitiquette before I Googled it and found other people have already used the term!

Raising GitHub Issues

If you find a bug or have an enhancement suggestion for a project, the place to start is to raise an issue. Before doing so it’s good practice to search for any issue (open or closed) that might address a similar point. Managing issues is a large part of running a project on GitHub and it’s good etiquette not to overload the project owners by repeating something that has already been asked and answered. This frees up the owners to respond on new issues.

If you can’t find a similar issue then go ahead and raise one. Try to give it a short descriptive title, summarising the issue or area of the application you are referring to. Try to choose something easy and likely to be searched so that anyone who is checking for related issues can easily find it and avoid repeating a question/bug.

If your issue is more of a question than a bug it can be useful to mark it as such by putting “(question)” or “(discussion)” in the title. Each project may have their own convention around this, so check through some prior issues first and see if there is a preferred pattern in use.

In the content of the issue, try to be as detailed (but also specific) as possible to allow others to understand the bug. Include steps to reproduce the problem if it is a bug. Also try to include screenshots where applicable to share what you’re seeing. If your issue is more of a general question, give enough detail to allow others to understand the reason behind your question. For suggestions, try to back them up with examples of why you believe what you’re suggesting is a good idea to help others make informed arguments for or against.

Keep your language polite and constructive. Remember that a lot of opensource projects are driven by very small teams or individuals around their paid jobs and families. In my opinion, issues are not the right place to complain about things but a place to register problems with a view to getting them solved. “Speak” how you would like to be spoken to.

Once you’ve raised an issue remember that the project leaders may take a while to respond to it, especially if they are a small or one person team. Give them a reasonable period of time to respond and after that time has passed, consider adding a comment as a gentle reminder. Sometimes new issue alerts can be missed so it’s usually reasonable to prompt if the issue goes quiet or has no response.

Each project may have their own process to respond to and to triage issues so try to familiarise yourself with how other issues have been handled to get an idea of what to expect. In some cases issues may be tagged initially and then someone may respond with comments later on.

Once someone responds to your issue, try to answer any follow up questions they have as soon as possible.

If the project owner disagrees with your suggestion or that a bug is actually “by design” then respect their position. If you feel strongly, then politely present your point of view and discuss it openly but once a final decision is made you should respect it. On all of the issues I’ve seen I can’t think of any occasion where things have turned nasty. It’s a great community out there and respect plays a big part in why things function smoothly.

When you start to work on an issue it’s a good idea and helpful to leave a comment on the issue so that others can quickly see that it’s being worked. This avoids the risk of duplicated efforts and wasted time. In some cases the project owners may assign you to the issue as a way of formally tracking assignments.

If you want to work on an issue but are not sure about your potential solution, consider first summarising your thoughts within the issue’s comments and get input from the project owners and other contributors before starting. This can avoid you spending time going down a route not originally intended by the project owners.

If you feel an issue is quite large and might be better broken out into smaller units of work then this can be a reasonable approach. Check with the project how they prefer to handle this but often it’s reasonable to make a sub issue(s) for the work, referencing back to the master original issue so that GitHub provides links between them. Smaller PR’s are often easier to review and merge so it’s often reasonable to break work down like this and quite often preferred.

If someone has said that they are working on an issue but they haven’t updated it or submitted a PR in some time, first check their GitHub fork and see if you can find the work in progress. If it’s being updated and progressing then they are probably still working on the issue. If not, leave a comment and politely check if they are still working on it. It’s not unusual for people to start something with the best intentions and then life comes along and they don’t have time to continue.

If you stop working on an issue part of the way through and may not be able to pick it up for a while, update the issue so others know the status. If you think you will be able to get back to it, then try to give a time frame so that the project owners can determine if someone else might need to pick it up from you. If this is the case you might want to share a link to your fork and branch so others can see what you’ve done so far. Also remember that the project may accept a partial PR as a starting point to resolving the issue. If your code could be committed without breaking the main code base, offer that option.

Git Commits

Next I want to share a few thoughts on best practices to follow when making local commits while working on an issue:

Remember to make a branch from master before starting work on a new issue. Give it a useful name so you can find it again. I personally have ended up using the issue number for most of my branches. It’s a personal choice though, so use what works for you.

It’s not unreasonable to make many work in progress commits locally whilst working on an issue as you progress through it. It can though, be helpful to squash them down before submitting your final PR (see below for a couple of techniques I use to squash my commits).

Your final commit messages that will be included in your PR should be clear and appropriately worded. Try to summarise the commit in the first line and then provide additional detail after a line break and empty line.

GitHub Pull Requests

After you’ve finished working on an issue you’re ready for a pull request. Again I’m sharing my personal thoughts on PRs here and each person and project will differ in style and preference. The main thing is to respect the convention preferred by the project so that they can easily review and accept your work.

It’s a good practice to limit a PR to a single issue. Don’t try to solve too much in one request as it makes reviewing and testing it harder for the project owners. If you spot other bugs along the way then open new issues for them as you go. You can then include the fixes in separate PR(s).

Before submitting your PR I feel it’s good practice to squash or tidy your working commits into logical final commits. This makes reviewing your steps and the content of the PR a bit easier for reviewers. Lots of work in progress or very granular commits can make a PR harder to interpret during code review. Including too many commits will also make the commit history for the project harder to follow once the PR is merged. I aim for 2-3 commits per PR as a general rule (sometimes even a single commit makes sense). Certainly there are exceptions to this rule where it may not make sense to group the commits. See below for advice on how to squash a commit.

I try to separate my work on the actual application code and the unit tests into two separate commits. Personally I feel that it’s then easier for a reviewer to first review the commit with your application code, then to review any tests that you wrote. Instead of viewing the whole set of files changed and wading through it, a reviewer can view each commit independently.

Ensure the commits you do include in your PR are clearly described. This makes understanding what each commit is doing easier during review and once they are merged into the project.

If your PR is a work in progress, mention this on the comment and in the title so that the team know it’s not ready for final merge. Submitting a partial PR can be good if you want to check what you’ve started is in the right direction and to get technical guidance. For example you might use “Fixing Bug in Controller – WIP” as your title. Each project may have a style they would like you to apply so check past PRs and see if any pattern already exists. Once you’re ready for it to be formally reviewed and merged you can update the title and leave a new comment for the project owners.

When submitting a PR, try to describe clearly what you’ve added or changed so that before even reviewing the code the reviewer has an idea of what you’re addressing and how. The PR description should contain enough detail for a reviewer to understand what areas to test and if your work includes UI elements, consider including screenshot(s) to illustrate the changes.

Include a line in your comment stating Fixes #101 (where 101 is the issue number). This will link the PR to the issue to ensure the issue is closed when the PR is accepted. If your PR is a partial fix and should not close the issue, use something like Relates to #101 instead so that the master issue is not automatically closed.

Depending on the PR and project it may be good practice or even required to include unit tests to prove your changes are working.

Before submitting your PR it’s a good idea to ensure your code is rebased from a current version of the master branch. This ensures that your code will merge easily and allows you to test it against the latest master codebase. In my earlier post I included steps explaining how to rebase. This is only necessary if the master branch has had commits added since you branched from it.

Once you receive feedback on your PR don’t take any suggestions or critique personally. It can be hard receiving negative feedback, especially in an open forum such as GitHub but remember that the reviewer is trying to protect the quality and standards of their project. By all means share your point of view if you have reason to disagree with comments, but do so with the above in mind. In my experience feedback has always been valuable and valid.

Once you have received feedback, try to apply any changes in a timely fashion while the review is fresh. You can simply make relevant changes in your local branch, make a new commit and push it to your origin. The PR will update to include the pushed changes. It’s better not to rebase and merge the commit with the original commits so that a reviewer can quickly see the changes. They may ask you to rebase/squash it down after review and before final acceptance to keep the project history clean.

Reviewing GitHub Pull Requests

I’ve started helping to review some of the allReady pull requests in recent months. Here are a few things I try to keep in mind:

Try to include specific feedback using GitHub’s line comment feature. You can click the small plus sign new the line of code you are commenting on so the review is easy to follow. The recent review changes that GitHub have added make reviewing code even more clear.

Leave a general summary explaining any main points you have or questions about the code.

Think of the contributors feelings and remember to keep the comments constructive. Give explanations for why you are proposing any changes and be ready to accept that your opinion may not always be the most valid.

Try to review pull requests as soon as possible while the code is still fresh in the contributor’s mind. It’s harder to come back to an old PR and remember what you did and why. It’s also nice to give feedback promptly when someone has taken the time to contribute.

Remember to thank people for their contributions. People are generously giving their time to contribute code and this shouldn’t be forgotten.

Git Command Reference

That’s the end of my long list of advice. I hope some of it was valuable and useful. Before I close I wanted to share some steps to handle a couple of the specific Git related tasks that I mention in some of the point above.

How to Squash Commits

I wrote earlier about squashing your commits – reducing a large number of small commits into a single or set of combined commits. There are two main techniques I use when doing this which I’ll now cover. I normally do some of these operations in a visual tool such as SourceTree but for the sake of this post I’ll cover the actual Git commands.

Squashing to a single commit

In cases where you have two or more commits in your branch that you want to squash into a single final commit I find the quickest and safest approach is to do a soft reset back to the commit you branched from on master.

Here’s an example set of three commits on a new branch where I’m fixing an issue…

C:\Projects\HTBox-AllReady>git log --pretty=format:"%h - %an, %ar : %s" -3

be7fdfe - stevejgordon, 2 minutes ago : Final cleanup
2e36425 - stevejgordon, 2 minutes ago : Ooops, fixing typo!
85148d7 - stevejgordon, 2 minutes ago : Adding a new feature

All three commits combined result in a fix, but two of these are really just fixing up and tidying my work. As I’m working locally I want to squash these into a single commit before I submit a PR.

First I perform a soft reset using…

C:\Projects\HTBox-AllReady>git reset --soft HEAD~3

This removes the last three commits, the number after the ~ symbol controlling how many commits to reset. The –soft switch tells git to leave all of the changed files intact (we don’t want to lose the work we did!) It also leave the files marked as changes to be committed. I can then perform a new commit which incorporates all of the changes.

C:\Projects\Other\HTBox-AllReady>git commit -a -m "Adding a new feature"
[#123 2159822] Adding a new feature
1 file changed, 1 insertion(+), 1 deletion(-)

C:\Projects\Other\HTBox-AllReady>git status
On branch #123
nothing to commit, working directory clean

C:\Projects\Other\HTBox-AllReady>git log --pretty=format:"%h - %an, %ar : %s" -1

2159822 - stevejgordon, 20 seconds ago : Adding a new feature

We now have a single commit which includes all of our work. Viewing it visually in source tree we can see this single commit more clearly.

Example of branch after a Git squash

We can now push this and create a clean PR.

Interactive Rebasing

In cases where you have commits you want to combine but you want also to control which commits are squashed together we have to do something a bit more advanced. In this case we can use interactive rebasing as a very powerful tool to rewrite our commit history. Here’s an example of 4 commits in a new branch making up a fix for an issue. In this case I’d like to end up with two final commits, one for the main code and one for the unit tests.

C:\Projects\Other\HTBox-AllReady>git log --pretty=format:"%h - %an, %ar : %s" -4

fb33aaf - stevejgordon, 6 seconds ago : Adding a missed unit test
8704b06 - stevejgordon, 14 seconds ago : Adding unit tests
01f0876 - stevejgordon, 42 seconds ago : Oops, fixing a typo
2159822 - stevejgordon, 7 minutes ago : Adding a new feature

Use the following command to start an interactive rebase

git rebase -i HEAD~4

In this case I’m using ~4 to say that I want to include the last 4 commits in my rebasing. The result of this command opens the following in an editor (whatever you have git configured to use)

pick 2159822 Adding a new feature
pick 01f0876 Oops, fixing a typo
pick 8704b06 Adding unit tests
pick fb33aaf Adding a missed unit test

# Rebase 6af351a..fb33aaf onto 6af351a (4 command(s))
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
# These lines can be re-ordered; they are executed from top to bottom.
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
# Note that empty commits are commented out

In our case we want to squash the 2nd commit into the first and the 4th into the 3rd so we update the commit lines at the of the file to…

pick 2159822 Adding a new feature
squash 01f0876 Oops, fixing a typo
pick 8704b06 Adding unit tests
squash fb33aaf Adding a missed unit test

Saving and closing the file results in the next step

# This is a combination of 2 commits.
# The first commit's message is:

Adding a new feature

# This is the 2nd commit message:

Oops, fixing a typo

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# Date: Fri Sep 30 08:10:19 2016 +0100
# interactive rebase in progress; onto 6af351a
# Last commands done (2 commands done):
# pick 2159822 Adding a new feature
# squash 01f0876 Oops, fixing a typo
# Next commands to do (2 remaining commands):
# pick 8704b06 Adding unit tests
# squash fb33aaf Adding a missed unit test
# You are currently editing a commit while rebasing branch '#123' on '6af351a'.
# Changes to be committed:
# modified: AllReadyApp/Web-App/AllReady/Controllers/AccountController.cs

This gives us the chance to reword the final commit message of the combined 1st and 2nd commits. I will use the # to comment out the typo message since I just want this commit to read as “Adding a new feature”. If you wanted to include both messages then you don’t need to make any changes. They will both be included on separate lines in your commit message.

# This is a combination of 2 commits.
# The first commit's message is:

Adding a new feature

# This is the 2nd commit message:

#Oops, fixing a typo

I then can do the same for the other squashed commit

# This is a combination of 2 commits.
# The first commit's message is:

Adding unit tests

# This is the 2nd commit message:

#Adding a missed unit test

Saving and closing this final file I see the following output in my command prompt.

C:\Projects\Other\HTBox-AllReady>git rebase -i HEAD~4
[detached HEAD a2e69d6] Adding a new feature
Date: Fri Sep 30 08:10:19 2016 +0100
1 file changed, 2 insertions(+), 2 deletions(-)
[detached HEAD a9a849c] Adding unit tests
Date: Fri Sep 30 08:16:45 2016 +0100
1 file changed, 2 insertions(+), 2 deletions(-)
Successfully rebased and updated refs/heads/#123.

When we view the visual git history in SourceTree we can now see we have only two final commits. This looks much better and is ready to push up.

Git branch after interactive rebase

When interactive rebasing you can even reorder the commits so you have full control to craft a final set of commits that represent the public commit history you want to include.

How to pull a PR locally for review

When starting to help review PRs I needed to learn how to pull down code from a pull request in roder to run it locally and test the changes. In the end it wasn’t too complicated. The basic structure of the command we can use looks like…

git fetch origin pull/ID/head:BRANCHNAME

Where origin is the name of the remote where the PR has been made. ID is the pull request id and branchname is the name of the new branch that you want to create locally. On allReady for example I’d use something like…

git fetch htbox pull/123/head:PR123

This pulls PR #123 from the htbox remote (this is how I’ve named the remote on my system which points to the main htbox/allready repo) into a local branch called PR123. I can then checkout the branch using git checkout PR123 to test and review the code.

In Summary

Hopefully some of these tips are useful. In a lot of cases I’m sure they are pretty much common sense. A lot of it is also personal preference and may differ from project to project. Hopefully if you’re just starting out as a GitHub contributor you can put some of them to use. GitHub for the most part is a great community and is a great place to learn and develop your skills.

I’d love to be able to acknowledge the numerous fantastic blog posts, and Stack Overflow threads that helped me along my way; unfortunately I didn’t keep notes of the sources as I learned things on my 1 year journey. A big thanks none-the-less to anyone who has contributed guidance on Git and GitHub. Every little bit of shared knowledge is a big help to developers who are learning the ropes. It truly is a journey as your contribute more and more on GitHub it gets easier! Happy GitHub-ing!

Introducing My Blog

I’ve been thinking about creating a blog on and off for a year or so. I like the idea of sharing what I learn and if nothing else it gives me somewhere to write stuff down that I might later need. I’ve had a blog before and finding the time and discipline to keep it going was tough. I hope I do better this time around.

It’s mostly going to be about ASP.NET and C# since those are what I work with day to day. It’s an exciting time with the nearing release of ASP.NET Core 1.0 and I’ll be mostly investigating the code and concepts for that product as I use it for new projects. I enjoy learning new things and I want to get as good a grip as possible on how things work and best ways to use this technology. I’ll cover the things I learn as I go.

As far as intro’s go, I think that’ll do. We’ll see how well I keep this up and if I find the time to post.