5 ms·

Tutorial: How to use Git in a team development environment

137 points by zackattack 16y ago

jaddison 16y 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 16y 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 16y ago
The author also developed git-flow, a set of extensions to help manage this workflow: http://github.com/nvie/gitflow http://github.com/nvie/gitflow Related discussions: - Why aren't you using git-flow? http://news.ycombinator.com/item?id=1617425 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 http://news.ycombinator.com/item?id=1738934 - Our Git Workflow: Private Development, Public Releases (at Braintree): http://news.ycombinator.com/item?id=1611667 http://news.ycombinator.com/item?id=1611667 - My Git Workflow (Michael Ivey): http://news.ycombinator.com/item?id=441670 http://news.ycombinator.com/item?id=441670 - My Common Git Workflow (Yehuda Katz): http://news.ycombinator.com/item?id=1343753 http://news.ycombinator.com/item?id=1343753 - Git Workflow for Agile Teams: http://news.ycombinator.com/item?id=624319 http://news.ycombinator.com/item?id=624319
burgerbrain 16y ago
Well gee, this looks familiar: http://whygitisbetterthanx.com/images/branches.png http://whygitisbetterthanx.com/images/branches.png
abraham 16y ago
January 05, 2010
- brown9-2 16y ago
  Has working with Git on a team changed much in nine months?
  - abraham 16y 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.
    - sanswork 16y ago
      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 16y ago
        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.
akent 16y ago
The tip about using "--no-ff" for feature branch merges is really useful. Why ISN'T that the default.
- antirez 16y 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 16y 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.
    - antirez 16y ago
      oh I see, thank you. But then the graphics on the article is misleading I guess...
RiderOfGiraffes 16y ago
An old favorite: http://news.ycombinator.com/item?id=1730788 http://news.ycombinator.com/item?id=1730788 http://news.ycombinator.com/item?id=1460895 http://news.ycombinator.com/item?id=1460895 http://news.ycombinator.com/item?id=1222755 http://news.ycombinator.com/item?id=1222755 http://news.ycombinator.com/item?id=1199117 http://news.ycombinator.com/item?id=1199117 http://news.ycombinator.com/item?id=1063198 http://news.ycombinator.com/item?id=1063198 <- This one has comments
joystickers 16y ago
As someone who is learning Rails and is looking to collaborate with a partner, thank you!
mullr 16y ago
I use and highly recommend Gerrit. http://code.google.com/p/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.
silentbicycle 16y 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 16y 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.
  - silentbicycle 16y 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.)
jasonkester 16y 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 16y 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/ 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/ http://www.eclipse.org/egit/
  - jasonkester 16y 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 16y ago
  There's TortoiseGit: http://code.google.com/p/tortoisegit/ http://code.google.com/p/tortoisegit/
- brunomlopes 16y ago
  I've been using Git Extensions and it works great:http://code.google.com/p/gitextensions/ 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.

137 points by zackattack 16y 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 16y 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 16y ago

The author also developed git-flow, a set of extensions to help manage this workflow: http://github.com/nvie/gitflow http://github.com/nvie/gitflow Related discussions: - Why aren't you using git-flow? http://news.ycombinator.com/item?id=1617425 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 http://news.ycombinator.com/item?id=1738934 - Our Git Workflow: Private Development, Public Releases (at Braintree): http://news.ycombinator.com/item?id=1611667 http://news.ycombinator.com/item?id=1611667 - My Git Workflow (Michael Ivey): http://news.ycombinator.com/item?id=441670 http://news.ycombinator.com/item?id=441670 - My Common Git Workflow (Yehuda Katz): http://news.ycombinator.com/item?id=1343753 http://news.ycombinator.com/item?id=1343753 - Git Workflow for Agile Teams: http://news.ycombinator.com/item?id=624319 http://news.ycombinator.com/item?id=624319

burgerbrain 16y ago

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

abraham 16y ago

January 05, 2010

brown9-2 16y ago
Has working with Git on a team changed much in nine months?
- abraham 16y 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.
  - sanswork 16y ago
    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 16y ago
      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.

akent 16y ago

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

antirez 16y 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 16y 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.
  - antirez 16y ago
    oh I see, thank you. But then the graphics on the article is misleading I guess...

RiderOfGiraffes 16y ago

An old favorite: http://news.ycombinator.com/item?id=1730788 http://news.ycombinator.com/item?id=1730788 http://news.ycombinator.com/item?id=1460895 http://news.ycombinator.com/item?id=1460895 http://news.ycombinator.com/item?id=1222755 http://news.ycombinator.com/item?id=1222755 http://news.ycombinator.com/item?id=1199117 http://news.ycombinator.com/item?id=1199117 http://news.ycombinator.com/item?id=1063198 http://news.ycombinator.com/item?id=1063198 <- This one has comments

joystickers 16y ago

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

mullr 16y ago

I use and highly recommend Gerrit. http://code.google.com/p/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.

silentbicycle 16y 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 16y 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.
- silentbicycle 16y 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.)

jasonkester 16y 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 16y 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/ 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/ http://www.eclipse.org/egit/
- jasonkester 16y 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 16y ago
There's TortoiseGit: http://code.google.com/p/tortoisegit/ http://code.google.com/p/tortoisegit/
brunomlopes 16y ago
I've been using Git Extensions and it works great:http://code.google.com/p/gitextensions/ 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.