With git, it’s possible to do things that must be considered pure magic for anyone using older version control systems. Learn 7 simple tricks that will help you take the leap beyond commit, push and pull and let you leverage the powers of git. With these 7 tricks, you will be the git Wizard of the office.
This is a summary of my talk at Tech Days Sweden 2015. The explanations here are very brief, if you would like me to explain anything of this in more detail in a separate post, please leave a comment.
So you created an awesome pull request with a couple of features, but the evil(?) maintainer (could be me) just denied it and said you shouldn’t make pull requests from master? Then you’ve come to the right place to learn what went wrong and how to fix it.
Current (Incorrect) State
Looking at the history of your repository, it probably looks something like the image to the right. There’s a base commit and then you’ve added one commit for each of the features to it. And everything is done on the branch master.
The image was created with Git Extensions. Although I prefer using the command line when working with git, having a tool that can display the branches and commits graphically is indispensible to understand what’s happening.
Doing everytying on master as shown in the image is wrong for a couple of reasons that might not be obvious when first starting working with git.
Every single feature should be created in its own branch. Branches are so lightweight in git that it’s okay to branch all the time.
Submitting a pull request from your own master branch is a recipe for disaster, as it effectively prevents you from getting the latest code from the upstream repository (more on that later).
Unfortunately it’s easy to end up in this situation with git. Fortunately, it’s also quite easy to fix.
I like to receive pull requests, but I like some more than others. Here are a few hints on how to make me love your totally awesome pull request and merge it instantly.
With a bit more than a year as an open source maintainer I’ve received a few pull requests. Some have been good, some have had room for improvements and some have required extensive work by myself to clean up before merging.
An Awesome Pull Request
To write an awesome pull request is not that hard, but requires a bit of planning and reading up on tools.
Add an issue describing the feature before coding. It’s an opportunity to get feedback both on the suggested feature and on how to make it fit with the existing design/architecture.
Learn git. As a minimum you need to know how to fork the main repository, create feature branches and how to rebase them on a refreshed master pulled from the main repository. Check out the contribution guidelines from Nancy for details.
Limit each pull request to a single issue/feature. It’s much easier to review and discuss multiple small focused PRs than one large complex.
So you have Resharper and found a bunch of unused usings and other things that should be cleaned up? You’re welcome to submit those non-functional changes in a separate pull request.
Run any existing tests and make sure you didn’t break anything.
Make sure your code meets the test coverage expected and coding standard in the project.
Respect the architecture of the existing code. For example in AuthServices that supports both IIS and Owin hosting, it’s not acceptable to reference System.Web from most parts of the code.
A Gift to Who?
Finally I’d like to mention the view of pull requests as gifts. I totally agree with viewing pull requests as gifts. But not only a gift from the contributor (sending the PR) to the maintainer (receiving the PR), but also from the maintainer to the contributor.
I give you this code that I have written to improve your project.
I will take care of your code by reviewing it, maintaining it and take responsibility for any bugs in it.
This post was inspired by a similar post by Mark Seemann. It’s very good (although more lenghty than this), so I recommend reading it.
Every once in a while I’m working on a feature, only to discover that I need to extend another part of the code first. If I was disciplined, I would create another branch at that point. But I’m not. I end up with both the extended utility class and the actual feature as pending changes. With git it is simple to make two separate commits while ensuring that every commit compiles.
I’m working on my new big thing; the command line calculator. I’ve already done addition and am quite happy with that and I’m now implementing subtraction. Half way through the subtraction implementation I discover that I need to make some changes to the console output formatter class. It has the + sign hard coded and now needs to take that as a parameter. I do that and end up with a working solution.
Doing a git status however shows a mess.
C:\git\spikes\gitpartial [master +1 ~2 -0 !]> git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)(use "git checkout -- <file>..." to discard changes in working directory)
modified: ConsoleFormatter.cs
modified: Program.cs
Untracked files:
(use "git add <file>..." to include in what will be committed)
Subtraction.cs
no changes added to commit (use "git add" and/or "git commit -a")
C:\git\spikes\gitpartial [master +1 ~2 -0 !]>
C:\git\spikes\gitpartial [master +1 ~2 -0 !]> git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: ConsoleFormatter.cs
modified: Program.cs
Untracked files:
(use "git add <file>..." to include in what will be committed)
Subtraction.cs
no changes added to commit (use "git add" and/or "git commit -a")
C:\git\spikes\gitpartial [master +1 ~2 -0 !]>
I’ve got both the updated ConsoleFormatter.cs, the updated Program.cs and the new Subtraction.cs. The first one contains the updated console formatting features that are independent of the added functionality. I want to commit the ConsoleFormmatter.cs separately. And not only commit it. I want to compile and test the exact code I’m going to commit, by hiding the other files from view. With git this can be done with just a few commands. With subversion, I’ve never quite figured out how to do it in a simple enough way. I usually end up with one big commit on svn. If anyone knows how to do this as simple in svn, please leave a comment.
Git is magic, but sometimes it drives my crazy with all that power causing strange situations and clean-up work. The magic of git is that it is (nearly?) always possible to clean up the mess and get back to a good state. The problem is that there are A LOT of commands to master. This post is a story about cleaning up a pull request to prepare it for merging into master.
The pull request contains functionality that I do want to merge, but also workarounds for cultural sensitive unit tests that are obsolete and should not be merged. There’s also a rebase that has been done in the wrong way and a merge from master of the forked repo – which is no longer in sync with the main repo’s master branch.
Looking at the history of your repository, it probably looks something like the image to the right. There’s a base commit and then you’ve added one commit for each of the features to it. And everything is done on the branch 
The pull request contains functionality that I do want to merge, but also workarounds for cultural sensitive unit tests 
