I’ve been using source control and git flow for a long time. Indeed I delievered a session with Declan Lynch at Lotusphere 2014 on source control. (If you want all 337 slides at over 17Mb, here is the download. If you prefer videos, I did a NotesIn9 covering the SourceTree part.) A blog post would be too long to cover all the ways it’s helped me, even though most of the time I’ve been the only developer on many projects, or multiple developers have been working on separate, self-contained, non-conflicting areas. OpenNTF Domino API is a big exception to that and we’ve used various approaches over the years, but not really using git flow.
When the XPages Extension Library was open sourced a number of years ago, I submitted various changes – fixes and enhancements – as pull requests. I did it badly. I submitted a pull request from my develop branch that had the key changes, from multiple bugs / features, but also changes caused by compilers changing line lengths and changes to files that probably should have been excluded by a .gitignore. One of the biggest impacts is that the pull request is not a snapshot in time. It’s a living link. So subsequent changes you make to the branch your requesting a pull from get added to the pull request as soon as you push them to your remote repo.
Admittedly that was the only project I submitted a pull request on, and probably most Domino developers are inexperienced on doing pull requests. Indeed I suspect there are a large number who still don’t use source control or branching.
But recently a few things coincided, with me doing significant work on a fork of one open source project and considering managing pull requests into a project I was working on. Git flow and separate feature branches made a lot of sense. And SourceTree has a “Git-flow” button to make things easier for you. It sets up git flow, sets up a master branch, switches to the develop and handles creating feature, hotfix and release branches. I had a number of fixes and features to submit, all made in my local repo and not yet committed or pushed to my remote fork. So I created a feature branch, committed the hunk changes for that bug or feature, created a pull request, and repeated the process for each. At the end I pulled everything back into my develop branch ready to start again.
But then comes the next feature or fix. I need a feature branch. But I don’t want it from my develop branch, because then it will have everything from every other pull request. I want it from my master branch – in my case that’s the same as the master branch of the forked repo, but if it were not, it’s the forker repo’s master branch I want to create a new feature branch from. The “Git-flow” button in SourceTree looks promising. It has radio buttons for “Specified commit” (letting me choose a commit) and “Working copy parent” (presumably the current branch).
But neither worked.
A quick search showed I was not the first to hit this problem. The answer pointed to raising an issue on the source GitHub repo for git flow. The date of last commit – September 2012 – left me unimpressed. The other link on the answer didn’t seem to help. More searching pointed to a fork project that promised a fix. The good news is this fork project, gitflow-avh, seems to be the closest to an official git flow solution. The better news (for Windows users) is that if you’ve installed “Git for Windows” recently, since version 2.6.4 the AVH edition of GitFlow is included, as the wiki installation details for Windows says. For MacOS, it can easily be installed though. Going to Tools > Options in SourceTree, and on the Git tab scrolling down to the Git Version section, I was able to see by system git version is well above 2.6.4, so no further action required.
The bad news is that SourceTree’s button doesn’t integrate with that. And as far as I can tell you can’t create a feature from a specific commit, just a local branch. But that covers my needs. Just clicking on the “Terminal” button in SourceTree gives a terminal command window using MINGW64, the Windows Git. Then it’s just a case of the relevant git command:
git flow feature start MY_FEATURE BASE_BRANCH_NAME
Press enter, close the terminal window, refresh the list of branches in SourceTree, and my new feature branch is created from master and I’ve been switched to it. Now I can make my changes, test, commit and push up, create the pull request and merge back into my develop branch.
This is clearly also my preferred approach for receiving pull requests. It means less review for me – and if you want me to spend my personal time accepting your change, I would hope you don’t want me to have to spend longer than I need. And it also means that if I’m submitting a pull request on to whatever repo it’s forked from, it will be cleaner for that third party. Which means greater likelihood of it being accepted by them as well.