Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Version control: best practices

blog.rainforestqa.com

Post reply on HN
Print view View original

1–10 of 52 posts

Re: Version control: best practices

#3

Post by smathieu »

Although many of these tips might seem trivial and obvious, I've often seem developer who self-identified as 'senior' not follow these practices.

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.

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.

Re: Version control: best practices

#4

Post by VBprogrammer »

> Good, descriptive commit messages

All of the examples given in the image going that heading I'd say are mediocre at best.

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.

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.

Re: Version control: best practices

#5

Post by reledi »

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.

Plan out the tasks in your PR to communicate what still needs to be done -- I like to use GitHub Flavored Markdown task lists.

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.

    # 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

Re: Version control: best practices

#7

Post by dmmalam »

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].

Is anyone making squashing part of their workflow? We seem to prefer just plain merges with rebase.

[1] http://zachholman.com/talk/how-github-uses-github-to-build-g...

Re: Version control: best practices

#8

Post by VBprogrammer »

VBprogrammer wrote: post #4

> Good, descriptive commit messages All of the examples given in the image going that heading I'd say are mediocre at best. 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. A ticket number is often the single most useful thing, ideally followed why a very brief what you've changed and as much informat…

As an example of what I'd like to read:

  #2313 Change expected value to a float field.

  django-haystack stores decimal fields as strings internally.
  This means that when we order by expected value small
  values (e.g '9e-08') are sorted before larger values.

Re: Version control: best practices

#9

Post by smathieu »

VBprogrammer wrote: post #4

> Good, descriptive commit messages All of the examples given in the image going that heading I'd say are mediocre at best. 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. A ticket number is often the single most useful thing, ideally followed why a very brief what you've changed and as much informat…

I think the point was mostly that 'lol' or 'meh' is a completely useless comment. It's true that there's a lot of room for improvements in the given example. Still, they do provide some context to people who actually understand the application they are working on.

Does anyone know of good open source project that uses Git messages extremely well that we could use as an example?

Re: Version control: best practices

#10

Post by ukd1 »

VBprogrammer wrote: post #8
VBprogrammer wrote: post #4

> Good, descriptive commit messages All of the examples given in the image going that heading I'd say are mediocre at best. 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. A ticket number is often the single most useful thing, ideally followed why a very brief what you've changed and as much informat…

As an example of what I'd like to read: #2313 Change expected value to a float field. django-haystack stores decimal fields as strings internally. This means that when we order by expected value small values (e.g '9e-08') are sorted before larger values.

This is a great example - it's details, explains the issue and also has the bug id (presumably) in it.
Post reply on HN