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.

In Scott Chacon's workflow (explained eg in this SO answer), with essentially two silos (development, and master), if, say I have a small bug to fix (e.g. can be fixed with a few characters) is the optimal way of doing that:

a) branch off of development a branch called e.g. fix_123. Push this branch to origin as I work on it. When it's done, code-reviewed, whatever, merge into development and push development to origin.

b) Same as above, but without pushing fix_123 to origin.

share|improve this question
add comment

2 Answers

Ideally push it to origin as that means everybody else will see that someone else is working on a fix. Also even though something is a small fix when measured by number of charecters it can make a huge difference in execution so the size of the fix shouldn't make any difference to the way you fix it.

However practically when I used git it took so long to sync that I'd bundle a group of small fixes together and just let other devs know by email that I was working on them.

share|improve this answer
    
Thanks—so if you've got like 2000 small fix branches (or more, over the years), should you eventually delete them? Or just remove them locally, but keep the hundreds/thousands of small fix branches on remote? –  Isaac Hodes Oct 19 '12 at 16:19
    
Git took a long time to sync?? What kind of files were you doing? Huge binary files each time? –  Daenyth Oct 19 '12 at 16:29
    
It was on a home broadband connection which in the UK means terrible upstream. The repo ended up at about 175mb I think and could take 30 mins to an hour to sync. As for the fix branches I think I'ld wipe them when I stopped supporting the version they relate to. –  Inverted Llama Oct 31 '12 at 11:54
add comment

It really depends on this. I commit frantically locally but only commit (presumably working) milestones to the remote repository. Historically, the 1000's of local commits don't add as much value to the greater code base as the feature level stuff does (IMO). It creates clutter (IMO).

If your fix_123 is a complete and functional commit, perhaps a bug fix or some other isolated task, it makes more sense to commit each of these to development. If bug number 10402030 is reported and your commit and push from local only encompasses the complete fix state that isn't such a bad thing.

One way to limit clutter on the remote repository is to squash some commits by rebasing like mentioned HERE. I only use git in personal projects outside of my paid work so if I am flawed in my methods I don't mind corrective comments.

On all this, version control practices can almost be like discussing religion. You will get wildly different opinions and practices but it really depends on what fits the project and organization.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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