> Good, descriptive commit messages<p>All of the examples given in the image going that heading I'd say are mediocre at best.<p>The code changes should tell you what has changed, if I'm looking back through your commit history what I'm usually trying figure out is why you've changed something.<p>A ticket number is often the single most useful thing, ideally followed why a very brief what you've changed and as much information on why you've changed it as you think would be useful.
Adding to GitHub Pull Requests, I recommend opening them early. This allows reviews to happen early and often, instead of reviewing one giant chunk of changes at the end which may get rejected because it has too many problems.<p>Plan out the tasks in your PR to communicate what still needs to be done -- I like to use GitHub Flavored Markdown task lists.<p>Here's a fish script I use when creating a new branch. It opens a PR before I even write a single line of code.<p><pre><code> # Usage: git-new-branch 120-fix-foo-issue
function git-new-branch --description 'Creates a new branch and opens a Pull Request for it'
git checkout -b $argv[1]
git commit --allow-empty -m 'Empty commit to open PR'
git push origin HEAD
git pull-request # Opens your default text editor for PR title. Uses hub.
end</code></pre>
Although many of these tips might seem trivial and obvious, I've often seem developer who self-identified as 'senior' not follow these practices.<p>Git and Github are communication channels and you should think about effectively communicating with your audience when you are using them. Very much in the same way that you are when you are writing emails.<p>The other interesting point about Git is that, very often, you are your own audience when you're revisiting the history of particular months after you've written the original code. You should definitely start thinking about your workflow a little more.
I'd be very hesitant with "commit often". Each commit should represent a finished bit of a bigger feature.. Each commit should compile (...generally. With exceptions). Commits that fix spelling, or change some spacing issues end up cluttering the history and making it hard to see what's being actually done. When someone looks over your code they should see things like:<p>commit1: he/she added some methods<p>commit2: refactored some code<p>commit3: he/she plugged in the methods created into the refactored code<p>etc.<p>The branch as a whole should be a finished feature. Keep the features small-ish. Try not to have a branch that living on it's own for a long time. You can merge the master branch into it, however you'll slowly be out of sync with your team b/c they don't really know what you're up to.<p>The only thing I absolutely detest in Git, is that is no quick method to change history on local changes. Say I add a method and make a commit - then I do a bunch of other work and 10 commits later I realize that the method I had written needed to be const. Instead of be able to edit that commit and add the const labels, I end up having to make another commit that no one cares about and no one really should have to look at. It just makes the history incredibly cluttered and make it a lot harder to find the commits I'm interested in.<p>The workaround is to make a new branch and cherry pick changes - but it's a huge PITA and easy to mess up<p>Aside:<p>Does anyone know what diff tool is best for working in C++? The diffs I commit (using kdiff) can sometimes be mind-boggling hideous b/c the diff program parsed things in some strange way.
I used to use feature branches more heavily but these days <i>Branch By Abstraction</i> tends to be my first choice.<p><a href="http://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/" rel="nofollow">http://continuousdelivery.com/2011/05/make-large-scale-chang...</a>
Looks very sensible. We tend to not have a long running dev branch, and just cut features branches off master, similar to the 'how github uses github to build github' presentation [1].<p>Is anyone making squashing part of their workflow? We seem to prefer just plain merges with rebase.<p>[1] <a href="http://zachholman.com/talk/how-github-uses-github-to-build-github/" rel="nofollow">http://zachholman.com/talk/how-github-uses-github-to-build-g...</a>
The branching model that I use with my team projects used to be like this - master was always production code, development was always code ready for QA, and features would be branched off and development. It worked great for larger projects that had releases that were weeks apart, but a lot of our projects are very small and may have several minor changes go to production in a short amount of time.<p>We decided to kill our development branch and just create feature branches off of master. If multiple devs are working on the same project scheduled for the same release, we will create a release branch and they can branch features off of that.<p>An open pull request into master is how we initiate the QA process, and all remediations are discussed in there. When the pull request is merged and closed, we all get an email so we know to update our local code. It's been working really well so far for both our small and large projects.
Nothing very new here, but it still amazes me the sheer amount of devs that ignore these simple best practises. So it's always nice to have these reminders every now and then.
One thing that bothers me is when a commit has multiple changes that aren't related. A commit message will say "Implemented feature X", and that's true, but it's also making a small change to feature Y, which isn't mentioned in the commit message. It makes reading the diff harder because you have extra noise in there and it also makes it harder to answer the question of "Huh? Where did this small change to feature Y come from?".
Nice article! I've got a question though, why do you guys branch from "Staging" ? Personally, I branch from "Master" or "Production" and the reason is that "Staging" may have "features" that need proper testing and the "development to production cycle" be longer and I don't want that to be included. Does this make sense ?<p>Can you explain me how you prevent that from happening ?
When reviewing a pull request I find it hard to see the changes made since my last set of comments and to find unanswered comments (especially when the comment was on a diff hunk that is now gone). When responding to a review I find it likewise hard to find comments that I haven't responded to yet. Rietveld or gerrit solves all of these issues very easily. Do you have any tips on how to deal with them in github/bitbucket pull request UI?
Good post, though I'd add that you should avoid rebase and force push. I've seen both used an add nothing but confusion / breakage.<p>See: <a href="http://geekblog.oneandoneis2.org/index.php/2013/04/30/please-stay-away-from-rebase" rel="nofollow">http://geekblog.oneandoneis2.org/index.php/2013/04/30/please...</a>