Live data from Hacker News

Version control: best practices

blog.rainforestqa.com

51–52 of 52 posts

Re: Version control: best practices

#51
post #48

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 ?

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

Also, once something is on develop/staging, it is about to be shipped. If there is any bug in there, they are they should be fixed ASAP.

As we grow, we might have to do things differently, we'll see, but this works really well for us right now. :)

Re: Version control: best practices

#52

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 l…

Thanks for the pointer. In truth, I use a GUI (gitExtentions). I like it a lot more than the command line. Hopefully this is implemented somewhere. I'll look into it!
Post reply on HN