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

41–50 of 52 posts

Re: Version control: best practices

#41

Post by rdrdss23 »

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:

commit1: he/she added some methods

commit2: refactored some code

commit3: he/she plugged in the methods created into the refactored code

etc.

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.

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.

The workaround is to make a new branch and cherry pick changes - but it's a huge PITA and easy to mess up

Aside:

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.

Re: Version control: best practices

#42

Post by swang »

ukd1 wrote: post #6

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. See: http://geekblog.oneandoneis2.org/index.php/2013/04/30/please...

These kind of vague blanket statements doesn't do anybody good.

rebase and force push are _bad_ _if_ you run those commands over commits that are already committed into remote branches that are shared by others (mainly the master branch).

You definitely can (and probably should) rebase on your own branches and be fine with force pushing into your own branches (even "remotely", like on a PR'd branch). However once you are touching shared branches, you should definitely not run rebase/force push.

The basic rule is if you are on a branch and you need to use rebase to do squashes or amendments, you are okay as long as you do `git rebase -i origin/master` (assuming origin/master is updated and that master is what you branched off of). Running a normal rebase should not affect any committed changes as it takes your parent branch (origin/master) and runs your commits on your local branch over it.

Re: Version control: best practices

#43

Post by u801e »

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.

You can run git blame to get the information pertaining to that particular line of code. That's a really good way to document what a particular piece of code is doing and why at the time it was written.

Re: Version control: best practices

#44

Post by Eclyps »

jipiboily wrote: post #39
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.

We ran into a couple issues (none of them significant)

1. When someone merges their branch into development for QA, it's going to be there (with or without issues) for anyone else who merges for QA after that. If the first merge has bigger issues than expected, it's a bit of a pain to roll it back and re-merge the later branch. Without the development branch as a base for our QA, we just QA things one feature/release branch at a time. This lets us easily send back branches that aren't ready for production and move on to a different branch that is before any merging takes place.

2. We weren't sure how to handle pull requests with the development branch always being there. We used to set development as our "default" branch in github, so any pull requests would be automatically merged into there. That got a bit confusing, though, as most of us were so used to merged pull requests representing a change that has already been reviewed and accepted as production-ready. And as for the merge to master, should we submit another pull request? It just seemed like an unnecessary extra step in a lot of situations.

But you are absolutely right. Different flows work for different teams and projects. I'm sure as our team evolves, so will our workflow.

Re: Version control: best practices

#45

Post by reledi »

j_s wrote: post #37
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...

I think having an issue attached to your PR is much better than converting your issue to a PR. Here's a good discussion about why it's been deprecated: https://github.com/github/hub/commit/4f70dd126f46dec14fc341c...

Re: Version control: best practices

#46

Post by alwillis »

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…

This is probably more on point--"A Note About Git Commit Messages” http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa...

Re: Version control: best practices

#47

Post by icebraining »

rdrdss23 wrote: post #41

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: commit1: he/she added some methods commit2: refa…

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.

I think you can use git rebase --interactive to reorder the new commit and squash it with the older: http://stackoverflow.com/questions/3921708/how-do-i-squash-t...

Of course, that requires manual labor (brrr), but that's nothing that a small script can't automate. I'd do it myself if we used git where I work.

Re: Version control: best practices

#48

Post by punkbit »

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 ?

Can you explain me how you prevent that from happening ?

Re: Version control: best practices

#49

Post by jipiboily »

Eclyps wrote: post #44
jipiboily wrote: post #39

Earlier quoted context omitted.

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.

We ran into a couple issues (none of them significant) 1. When someone merges their branch into development for QA, it's going to be there (with or without issues) for anyone else who merges for QA after that. If the first merge has bigger issues than expected, it's a bit of a pain to roll it back and re-merge the later branch. Without the development branch as a base for our QA, we just QA things one feature/release…

For #1, we use Fourchette (https://github.com/jipiboily/fourchette), which means we have a Heroku fork of our QA env for each GitHub PR.

For merges to master, we submit other pull requests that we call "Release: ...". We can then see if CI and Rainforest tests are passing, if all is green, then we merge! :)

Re: Version control: best practices

#50

Post by jipiboily »

ataylor32 wrote: post #40

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…

Commits with unrelated changes should be multiple commits.
Post reply on HN