Our Git Workflow: Private Development, Public Releases • Hacker News Board

Re: Our Git Workflow: Private Development, Public Releases

#11

Post by lnguyen » Tue, Aug 17, 2010, 10:08 PM UTC

henrikhansen wrote: post #3

This reminds me of The Myth of the Genius Programmer. I.e. the developers who don't want others to see them make mistakes and instead want to look like geniuses. I don't see how they "dig" Open-Source when they really are just releasing their source publicly. No one can see the progress of their projects or participate in their work. It also amazes me that they consider branches to be cluttering.

Ensuring that branches are useful and not "cluttering" requires a bit of discipline. It's easy to get a bit branch-happy in which case you end up with changes scattered across a number of branches that may or may not have a consistent starting point. This will cause issues when you have to merge all the updates for a release.

A general rule of thumb is only to create a branch when you need to work in parallel: code needs to be separated to allow for simultaneous updates or if a feature needs to be isolated until it's release timetable is set. This will vary depending on team size, work patterns and the nature of code changes.

Re: Our Git Workflow: Private Development, Public Releases

#12

Post by Aegean » Tue, Aug 17, 2010, 10:34 PM UTC

Excellent. We do open source development and I was about to write a complex script that moves patches around to be able to keep a few private commits and still stay in sync with the single-commit release repos.

Re: Our Git Workflow: Private Development, Public Releases

#13

Post by Zev » Tue, Aug 17, 2010, 10:36 PM UTC

najafali wrote: post #7

shoover wrote: post #6

I hadn't realized git incorporated the much-maligned svn merge as a feature.

If you're referring to the `git merge` command then the actual things they do are quite different. In svn it applies specified changes to your working copy, while in git it either fast-fowards branch-a to branch-b if applicable, or finds a common ancestor for the commits and creates a 'merge commit' so the commit history won't be linear (it will branch and re-converge). If all the branches are local, you can also use…

Merging is still a pain with git. Especially if you have to deal with xib or xcodeproj files (for iPhone/Mac dev). To the point where the usual process I see amounts to "don't touch this file -- I'm working with it (and don't want to lose any work)." instead of dealing with a merge that is almost guaranteed to make someone lose work.

Re: Our Git Workflow: Private Development, Public Releases

#14

Post by billmcneale » Wed, Aug 18, 2010, 4:46 AM UTC

Squashing can be useful but discarding potentially hundreds of commits and replacing them with one commit called "1.0.0" is very puzzling.

Instead, each developer should handle this on their own: commit often, once they're happy with their progress, theh rebase -i, squash and reorder their commits to make them look nice and push that tidy commit to master or release.

This gives you the best of both worlds: an accurate version of your history that doesn't contain throwaway or half baked commits.

Re: Our Git Workflow: Private Development, Public Releases

#15

Post by chousuke » Wed, Aug 18, 2010, 8:00 AM UTC

billmcneale wrote: post #14

Squashing can be useful but discarding potentially hundreds of commits and replacing them with one commit called "1.0.0" is very puzzling. Instead, each developer should handle this on their own: commit often, once they're happy with their progress, theh rebase -i, squash and reorder their commits to make them look nice and push that tidy commit to master or release. This gives you the best of both worlds: an accurat…

I think this point is overlooked all too often. With git, just mashing out code and committing at regular intervals is not using git to its full potential. You're supposed to spend time crafting proper commits, consisting of logical, well-separated changes. The staging area and rebase feature make it easy, but it still requires effort that most developers are not used to.

Good, logically separate changesets make merging, backporting (cherry-picking), bisecting and reverting much easier. It is worth the trouble.

The version history of the git project itself serves as a magnificent example of what a commit history should look like. It's actually possible to read the logs and understand each committed change. (Most of the time)

Re: Our Git Workflow: Private Development, Public Releases

#16

Post by jwr » Wed, Aug 18, 2010, 8:41 AM UTC

I think it is strange that they found topic branches to be "cluttering", but find their current workflow convenient.

We use topic branches a lot in our startup and we find them convenient, useful and efficient. I would never consider doing what they do.

Then again, to each his workflow, I guess.

Re: Our Git Workflow: Private Development, Public Releases

#17

Post by loewenskind » Wed, Aug 18, 2010, 8:52 AM UTC

chousuke wrote: post #15

billmcneale wrote: post #14

Squashing can be useful but discarding potentially hundreds of commits and replacing them with one commit called "1.0.0" is very puzzling. Instead, each developer should handle this on their own: commit often, once they're happy with their progress, theh rebase -i, squash and reorder their commits to make them look nice and push that tidy commit to master or release. This gives you the best of both worlds: an accurat…

I think this point is overlooked all too often. With git, just mashing out code and committing at regular intervals is not using git to its full potential. You're supposed to spend time crafting proper commits, consisting of logical, well-separated changes. The staging area and rebase feature make it easy, but it still requires effort that most developers are not used to. Good, logically separate changesets make merg…

This is what I always liked about darcs (it's still the DVCS I use at home): separating checkins into logical change sets.