Tutorial: How to use Git in a team development environment

http://nvie.com/posts/a-successful-git-branching-model/?

by zackattack • 16 years ago

137 26 16 years ago

jaddison• 16 years ago

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• 16 years ago

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

nixme• 16 years ago

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

burgerbrain• 16 years ago

Well gee, this looks familiar: http://whygitisbetterthanx.com/images/branches.png

abraham3• 16 years ago

January 05, 2010

brown9-2• 16 years ago

Has working with Git on a team changed much in nine months?

abraham3• 16 years ago

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.

silentbicycle3• 16 years ago

Which basically makes it ancient history, right?

I dare you to implement a compiler with only stuff invented since January 6, 2010. Or do basically anything (including eat). Eventually, we'll pity you and bring you antibiotics and parsing algorithms.

akent• 16 years ago

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

antirez2• 16 years ago

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• 16 years ago

--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.

RiderOfGiraffes• 16 years ago

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

joystickers• 16 years ago

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

mullr• 16 years ago

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.

silentbicycle3• 16 years ago

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• 16 years ago

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.

silentbicycle3• 16 years ago

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.)

jasonkester2• 16 years ago

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• 16 years ago

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/

jasonkester2• 16 years ago

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

bostonvaulter2• 16 years ago

There's TortoiseGit: http://code.google.com/p/tortoisegit/

brunomlopes• 16 years ago

I've been using Git Extensions and it works great:http://code.google.com/p/gitextensions/

I find that the workflow using this tool fits me better than with tortoise, mostly because it is repo-centric, instead of working on the explorer.

Tutorial: How to use Git in a team development environment

Related Stories