Looking at the history tree with all the branches and remote branches is a great way really understand Git.

More powerful history browsers to "lola": * gitk (graphical, developed in git's own repo) https://lostechies.com/joshuaflanagan/2010/09/03/use-gitk-to... * tig (console) http://jonas.nitro.dk/tig/manual.html

For me Git has also worked very well for small projects. I actually learned it initially by using it for my masters thesis.

One correction: Git does not store changes at all. It stores all the versions of files as separate "blobs". What keeps .git small, is that Git compresses the object database to pack-files. "git gc" does this for you.

Pro Git has a great chapter about how Gits internals work: https://git-scm.herokuapp.com/book/en/v2/Git-Internals-Plumb...

This picture sums the model nicely: https://git-scm.herokuapp.com/book/en/v2/book/10-git-interna...

For me studying Git internals has been a good lesson in software design. Git's core is very simple, yet somehow that makes it a really versatile tool.

Gerrit, a Git server with code review, lets users write custom submit-rules with Prolog: https://gerrit-review.googlesource.com/Documentation/prolog-...

Shawn Pearce, the author of Gerrit, explains why he thinks Prolog is well suited for this: https://groups.google.com/forum/#!msg/repo-discuss/wJxTGhlHZ...

Extending code review to commit messages is a big help.

If I can't understand from the commit message, what the change is trying to achieve, I won't even look at the code. Instead I'll ask to clarify the commit message first.

FlasForth is another fun Forth for AVR and PIC microcontrollers. You can even try it out over telnet... :-)

http://flashforth.sourceforge.net/

I've worked in a couple of big projects (250+ developers) where we have introduced Gerrit Code Review [1] that has mandatory code reviews.

In all cases, there has been a lot of initial scepticism and worries.

Some things that I feel have contributed to people accepting code review, are: 1) Gerrit enforces code review, you have to get it done somehow, in order to get your changes in. It's integrated in the workflow. 2) You choose your own reviewers. 3) We have had a clear message, that code review is about communication, knowledge sharing and bug hunting is just an added bonus. And communication is always our biggest problem in big projects. Just by letting someone do code review of your changes, the knowledge inside the organization about the change has almost doubled. 4) We ask people to treat code review request as number one priority, as the changes can not get in before it.

Before Gerrit we tried to encourage the culture by using Reviewboard [2], but in our case it just wasn't used that much. People did not treat review request as a high priority. Maybe because it was not enforced and sometimes you'd do a review for a change that the developer already merged in.

It's interesting to see how small tricks can change peoples behaviour...

[1] http://code.google.com/p/gerrit/ [2] http://www.reviewboard.org/

One thing the article unfortunately fails to mention is the motivation for this model. A branching model, as any other policy or technical solution, should be an answer to an existing problem. So decoupling the branching model from projects details makes no sense to me, although the article does a fair job describing the technical aspects.

I've been asked many times by units (big corporation) if this would be a good branching model for them when they are migrating to Git. I always tell them it's probably too complicated for their situation. Most of the units are trying to implement some form of Continuous Integration. Obfuscating that with complex branching models would only confuse them. Only when they encounter a real problem, that could be solved with this branching model, I suggest they try this out. I haven't still seen it happen.

However I must say, that the situation might be different in different types of projects. I've seen only these kind of CI-projects with a couple of hundreds developers with long lead times.

Github found git-flow wasn't suitable given that they do CI and developed their own method of using git, Github Flow: http://scottchacon.com/2011/08/31/github-flow.html

A different article on a CI-based approach, with comparison to git-flow: http://nxvl.blogspot.com/2012/07/a-continous-delivery-git-br...

Very nice concept!

I hope this catches fire like Airbnb! At least here in Finland "Restaurant Day" [1] has already become somewhat of an institution, so I bet there's potential for Cookening too!

A minor detail: I'd appreciate the _full_ price to be displayed with a side note like "including Cookening service free 3€".

Or is the service fee per group? In that case it could be something like: "15€ per guest + 3€ Cookening service fee per group"

With the current layout the service fee feels almost hidden.

Best of luck with this!

[1] http://www.visitfinland.com/article/restaurant-day/

Thank you ! I'll forward the feedback to our UI/UX guy !

Why yes! I've used it (or Gerrit code review [1], to be precise) even in two-man projects!

As important as QA is to keep others in the project aware of the latest changes.

[1] http://code.google.com/p/gerrit/

I like the practicalness of the advice. It might actually lead to some good in this world.

It's times like this when people stop to think about other human beings and might actually act on something. Unfortunately during normal times we are really bad at that.

I also like the practicalness of the advice, but it feels rather crass coming from someone deeply involved in Watsi. Good intentions or not, using a horrible event to promote something else altogether while the event is still happening is in terribly bad taste.

Well, one is more likely to mention an organization they know something about than one they don't, right?

...the obvious conclusion being that it would be appropriate for me to tell people to stop talking about the boston marathon so we could discuss the Mariners game that happened on Sunday.