Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

Ive just started working with Git (Github) in anticipation for an up coming project I'm project managing and designing and developing the front end of.

One thing I couldn't work out is, is it preferable to publish each individual change as you make them, ie. updated sidebar js, designed new FAQ page (each as individual commits) and the back end developers would be doing the same ie. added this class, refactored this..

Or is it better to do a daily / half daily commit of all the work you've done?

My thoughts were that if you do lots of small commits its easier to roll back, but also at the same time every commit you make the rest of the team has to get locally before they can commit their code.

You obviously don't have this problem so much if you do daily or half daily commits, but its a little more complicated to roll back if you need to?

Is there a best practice for this or is it down to team preference?

Background: I'm using Github via the mac desktop app not the CL.

share|improve this question

marked as duplicate by Jarrod Roberson, MichaelT, Corbin March, Aaronaught, Yusubov Sep 6 '13 at 19:34

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

add comment

1 Answer

You're thinking of git like it's SVN. It's not.

SVN looks at versions: Version 1000 contains sidebar, version 1001 contains sidebar and FAQ.

Git looks at changesets: Changeset 100 contains all the code to put in the sidebar, codeset 101 contains the FAQ. You can then merge those two together if you want, or add another feature and leave out the FAQ if it doesn't work like you want.

For more info see this Mega Thread on stackoverflow!

I find git to be much more forgiving than SVN as well, where branching and merging has a much lower cost, so feel free to do that as much as you want.

share|improve this answer
1  
Actually, Git doesn't store changesets, it stores snapshots and produces changesets on demand. It does this intentionally so that as the tools improve, the diffs become more accurate in terms of detecting things like renamed/moved files and blocks of code moved from one file to another. That is why you should commit whenever you're finished with a logical unit of work, whether that's a feature, a refactoring, etc. The smaller your commits, the more accurate the diffs will be. –  Aaronaught Sep 6 '13 at 18:51
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.