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

31–40 of 52 posts

Re: Version control: best practices

#31

Post by pretzel »

babuskov wrote: post #20
VBprogrammer wrote: post #8

Earlier quoted context omitted.

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.

I prefer to keep such comments in the code, not in the commit message. It is highly unlikely that anyone coming to do some changes to that part of the code would go and read a year-old commit message that he isn't even aware exists.

Try using git blame. It tells you what change caused a line to happen. I often use it to find out exactly what issue caused a seemingly crazy bit of code to happen. As the code goes away, so does the commit message - not necessarily so with a comment.

Re: Version control: best practices

#32

Post by why-el »

babuskov wrote: post #20
VBprogrammer wrote: post #8

Earlier quoted context omitted.

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.

I prefer to keep such comments in the code, not in the commit message. It is highly unlikely that anyone coming to do some changes to that part of the code would go and read a year-old commit message that he isn't even aware exists.

There is a difference tough, a very subtle one. A commit body should describe the rationale of the change, i.e. any decisions that had to be made or trade-offs in light of developer discussions and so on. Basically a description of the issue being solved. These things are rarely needed in the code itself, as the code will most likely feature new things and the old things are history.

Some commits even feature implementation details, and those I agree with you sometimes it makes sense to include them in the code. However most implementation details replace old ones, and this is transition should be explained in a commit since this is the perfect place for it.

Here is an random example from the linux kernel, which is guaranteed to do what I described: http://goo.gl/QdKNnJ

Re: Version control: best practices

#33

Post by Eclyps »

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.

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.

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.

Re: Version control: best practices

#34

Post by tomswartz07 »

pretzel wrote: post #31
babuskov wrote: post #20

Earlier quoted context omitted.

I prefer to keep such comments in the code, not in the commit message. It is highly unlikely that anyone coming to do some changes to that part of the code would go and read a year-old commit message that he isn't even aware exists.

Try using git blame. It tells you what change caused a line to happen. I often use it to find out exactly what issue caused a seemingly crazy bit of code to happen. As the code goes away, so does the commit message - not necessarily so with a comment.

While that's true; `git pickaxe` will also do what you describe. The added bonus is that one could use pickaxe to follow a specific line's changes way farther back than a normal comment.

http://jfire.io/blog/2012/03/07/code-archaeology-with-git/

Re: Version control: best practices

#35

Post by KajMagnus »

smathieu wrote: post #9
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?

Yes, Git itself :-) git://git.kernel.org/pub/scm/git/git.git and https://github.com/git/git

Git's commit log is probably the most detailed and informative log I've ever seen. And it's a bit fun to have a glance at Linus Torvald's old initial commits from 2005 :-)

(You might want to check the 'pu' branch rather than the 'master' branch. And there're lots of 'Merge branch...' commits that aren't super interesting.)

Re: Version control: best practices

#36

Post by VBprogrammer »

babuskov wrote: post #20
VBprogrammer wrote: post #8

Earlier quoted context omitted.

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.

I prefer to keep such comments in the code, not in the commit message. It is highly unlikely that anyone coming to do some changes to that part of the code would go and read a year-old commit message that he isn't even aware exists.

The example I gave (happened to be what I was working on) would be quite pointless as a comment. Since the code could easily have been written using the float datatype.

Re: Version control: best practices

#37

Post by j_s »

reledi wrote: post #5

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…

You can also convert issues (which often are created before writing code, as the reason for the changes) to pull requests:

http://stackoverflow.com/questions/4528869/how-do-you-attach...

Re: Version control: best practices

#38

Post by robryk »

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?

Re: Version control: best practices

#39

Post by jipiboily »

Eclyps wrote: post #33

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. We decided to kill…

Just an FYI, with this model, we still do multiple deploys each and every day :)

There might be a point where this won't work for us anymore, it's always time to change.

Also, this is not because a branching model works for a team that it will for all teams and projects.

Like any in-house, process the branching model will evolve with the team and it's requirements to be efficient.

Re: Version control: best practices

#40

Post by ataylor32 »

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?".
Post reply on HN