

Tutorial: How to use Git in a team development environment - zackattack
http://nvie.com/posts/a-successful-git-branching-model/?

======
nixme
The author also developed git-flow, a set of extensions to help manage this
workflow: <http://github.com/nvie/gitflow>

Related discussions:

\- Why aren't you using git-flow?
<http://news.ycombinator.com/item?id=1617425>

\- Ask HN: What's your dev teams git multi-environment setup workflow like?
<http://news.ycombinator.com/item?id=1738934>

\- Our Git Workflow: Private Development, Public Releases (at Braintree):
<http://news.ycombinator.com/item?id=1611667>

\- My Git Workflow (Michael Ivey):
<http://news.ycombinator.com/item?id=441670>

\- My Common Git Workflow (Yehuda Katz):
<http://news.ycombinator.com/item?id=1343753>

\- Git Workflow for Agile Teams: <http://news.ycombinator.com/item?id=624319>

------
RiderOfGiraffes
An old favorite:

<http://news.ycombinator.com/item?id=1730788>

<http://news.ycombinator.com/item?id=1460895>

<http://news.ycombinator.com/item?id=1222755>

<http://news.ycombinator.com/item?id=1199117>

<http://news.ycombinator.com/item?id=1063198> <\- This one has comments

------
mullr
I use and highly recommend Gerrit. <http://code.google.com/p/gerrit/> Having a
code review-based workflow has shifted my team from never talking with each
other and writing silos of bad code to talking with each other every day and
actively working to improve things. It's probably the best thing we've ever
done.

------
jasonkester
Is there a graphical tool (along the lines of TortoiseSVN) that you can use to
do all this?

The added hassle of memorizing shell commands (and opening a command prompt
every time you want to commit) are just not worth any incremental benefit that
Git might provide. I'm happy using SVN because it's got good tools. Surely
there's an equivalent for Git?

~~~
biotech
This kind of thing is key to selling git to other members of my team.

I haven't used it, but there is a tortoisegit project:
<http://code.google.com/p/tortoisegit/>

Anyone know the status of EGit? I can't download source or binaries; it looks
like the server has been down for a couple weeks.
<http://www.eclipse.org/egit/>

~~~
jasonkester
Nice. Assuming they've kept it nice and tortoisy, it should be an easy sell to
move across. I'll check it out.

------
jaddison
This is really handy - many thanks!

Assuming that a release-1.2.1 branch existed and a hotfix was needed, what
would the the hotfix be versioned as? 1.2a? 1.2.1a? 1.2.1 and then bump the
release to 1.2.2?

~~~
chairface
I'm pretty sure you can tag the new release with whatever you want, and these
kinds of decisions are left to the developers.

------
akent
The tip about using "--no-ff" for feature branch merges is really useful. Why
ISN'T that the default.

~~~
antirez
I'm not sure I understand --no-ff very well, but if with it you lose the
feature branch sub-commits this is why it is not the default I guess.

~~~
kyleslattery
\--no-ff doesn't get rid of the individual commits, it just guarantees that a
merge commit gets created as well, so it's easy to see what branch was merged
in. If you don't use it and the commits you're merging in can be applied via
fast forward, it skips creating the merge commit.

~~~
antirez
oh I see, thank you. But then the graphics on the article is misleading I
guess...

------
silentbicycle
Tangential, but any suggestions for educating a dev team used to another VCS?
(In my case, Perforce, but I'm sure e.g. svn->git advice will be useful for
someone.)

I've used both git & p4 for a while and know their ins & outs, but would love
to know if anybody has any suggestions for the crossover. My X-importing-to-Y
experience has been limited to svn-to-git, svn-to-hg, and hg-to-git.

~~~
utoku
I made some success by showing off git-svn in the environments/places where
they were still using svn. I would show off by using many local branches, by
doing things like fixing bugs in another branch right away, test other
developers' commits in other branches to see if they really work, or basically
things that are hard to do with svn. They still get to use their svn repos as
the "origin" but they meet the flexibility of git.

~~~
silentbicycle
I'm asking about explaining git to people used to p4, importing tools, etc.
They're already convinced, they're just _really_ used to the way p4 does
things, p4v, etc. (TortoiseGit will help.)

------
joystickers
As someone who is learning Rails and is looking to collaborate with a partner,
thank you!

------
abraham
January 05, 2010

~~~
brown9-2
Has working with Git on a team changed much in nine months?

~~~
abraham
Significantly? Probably not. Ten months is a long time in technology and best
practice/process will have changed. The age is yet another factor to consider
while reading the article.

~~~
sanswork
Best practices change a lot more slowly than the emergence of new
technologies. For the good reason that to determine something is a best
practice takes time and finding something even better takes even more time.
When considering core/base technologies it's usually safe to give it a lot
more than ten months before dismissing it and even in that case only in the
presence of something known that could improve on it.

Replacing your best practices/processes every couple months to keep up with
the latest trends is a recipe for disaster in any multi-person development
environment and change breeds confusion.

That said this setup won't work for everyone nor does the author claim it
should do. It's another possible tool for your belt to consider depending on
your work and the team you're working with.

I guess the to short version is don't be so quick to dismiss things based off
age(or lack thereof in this case) unless you can dismiss it with a proven
replacement.

~~~
abraham
personally how I do things is constantly changing. Usually in small increments
but I am always looking for new and better methods. Many will just just be
used for a short period.

You should not however be so quick in concluding that I said to dismiss the
article. I am nearly bringing attention to the fact that it is nearly a year
old and to consider it while making your own evaluation of the article.

~~~
sanswork
Some things I've found are best to keep fairly stable for longer periods of
time. Branching policy with git is one of these. I'm not sure of your
experiences with managing development teams using git but from mine I've found
setting a branching policy(this one actually) and making sure people stick to
it is the best way to minimize confusion and keep people on track.

Side note: I think the reason your previous comments were down voted wasn't
your concern about the age of the article so much as your lack of a better
alternative. If you could say "This was from Jan and this has been shown to be
better" people would probably be posting stories about your new technique. To
just say it is 10 months old though adds nothing to the conversation.

------
burgerbrain
Well gee, this looks familiar:
<http://whygitisbetterthanx.com/images/branches.png>

