Il giorno sab, 22/05/2010 alle 11.52 +0100, Andrew Sayers ha scritto: > Hi Daniele, > > I'm a developer getting towards the end of introducing my company to > Git. Here are some thoughts based on the (mis)steps I took. thanks > I found that advocating specific steps wasn't that effective - I just > came across as being pushy and hard to work with. It was more effective > to politely show off what I could do with git-svn, and let people get > jealous enough to work the "how" out for themselves. Here are some > examples: > > I would quietly bisect a hard-to-fix bug, then .... [big-snip] > > Over the course of a few months, people became convinced that Git was > something that makes you more productive. Our lead developer had a go > with git-svn for a while, before our boss decided we should all make the > switch. I'm already doing this stuff.. but i'm in the *lead developer* position now, so, if I say that they had to start using git (at least my team) they will.. But I don't thing going throw git-svn is a good idea.. it has some limitation over the normal git and you have to be more careful about rebasing (interactive) and you should avoid merge (as much as I understood it). I'd like to make the big move going directly to git. I don't think i'll had the time to do it now, the new project is already going on.. but I'd like to have all prepared and ready for the next one :) > I tried to make git-svn as painless as possible with some svn-like > aliases and a cheatsheet, which I'd be happy to upload if the list could > suggest a good place to put a PDF and some text. I think that may be useful to many. In my specific case it wouldn't help, since everybody is used to click around with the git-svn graphical interface, they don't even know the svn commands to do those stuffs. They are almost all windows-minded :) you know: "writing when you can click? why?" - I use to think the opposite :) What i mean here is: git should be graphical, at least at the beginning, better if inside eclipse itself. > The move worked for a while, but it turned out that one-and-a-half git > experts supporting the rest of the team wasn't enough to stop people > from making rookie mistakes like `git merge`ing into an SVN branch with > unpushed changes. We had to accelerate our move to git on the server, > and I got a lot of exercise and not much work done that month as I > dashed from desk to desk. that's what I fear, because we usually are overladen of work and we can't stand some slow down if it last more then 2-3 days in a row. If that happen I'll be the one who will be blamed for the issue :) > Things gradually calmed down as people got more comfortable with git. > But I expect to be occasionally called over for a long time as people > learn new tricks - "how do I, like, cherry-unpick a single commit?" Well.. that's ok.. the problem is with things I don't know about git like: what's the best way to manage binary files? how do I manage submodules? and so on... if I don't know how to properly reply to those questions I'll obtain the opposite effect :) Thanks for your experience, Daniele -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html