Posted: 2/18/2015 12:27:32 AM EDT
|
we just switched from a mix of svn and clearquest/clearcase to git. thus far i HATE it but i am trying to keep an open mind.
Dear Leader decided git flow fit our dev model. but it's not "by the book" git flow from what I can tell. we have master, release, develop, then feature branches. the idea is we branch feature for feature changes, makes sense. when a feature is ready we submit a pull request, the change mgr reviews code (that's laughable but a different gripe) then merges into develop. when a release plan is met, develop is merged into release which is then built and deployed for QA. once QA verifies, the build eventually gets deployed to prod and release merged to master. (is the release stream even necessary? seems like extra work) sooo... that works fine for one group but not so much for my group. we're still very waterfall and release maybe a few times a year. we have very long running feature branches, it's just how things are right now and there's absolutely no changing it. we're having trouble keeping our long-running feature branch in synch with changes going into develop. this is where I need help. should i fetch from develop bi-weekly? literally how do i do that? I can't find any examples online. everything shows only cutting feature branch, do some work, fold it back to develop. how do i stay in synch? when we goof up, how the hell do we revert? as of right now we end up stashing changes, re-basing feature branch, then re-applying changes/fixing merge issues in feature. it's killing productivity. not to mention the guys brand new to a distributed system ... on man they just cruise facebook all day. the only reason we can rebase with any success is that i have a cookie-cutter script i got from a frind at a different company :( can anyone recommend a good tutorial that doesn't assume you already know everything there is to know about git and doesn't assume you are using github? a middle-of-the-road source of info, we're not brand new to development but we're not git experts either and have no in-house knowledge. |
|
Have you checked out (SCM puns!) the tutorials at https://www.atlassian.com/git/tutorials/ ?
They compare the workflows, concisely cover resolving, reverting, resetting, moving from svn to git, etc. Not sure what IDE environment you're operating in but there is a git flow plugin for most of them that tries to abstract some of the repetitive janitorial git stuff. I dislike the release branch thing in favor of tags on develop but it sounds like that would be up to your QA team/process. Long running features and staying in sync is covered in the above tutorial, it's just a matter of either resolving the merge conflicts or stashing like you said. I like SourceTree but still try to avoid stashing since it isn't tracked and it's too easy to name them quickly and then lose them or delete them if you don't pop them back on right away. |
|
Yeah i've scoured those tutorials, i need something a bit more in depth than that. how to configure fetch would be nice, and whether or not git automatically prefers merges from develop over feature, that sort of thing.
eta sourcetree, i can't grasp how to use it until i get more comfortable with git. same with the eclipse plugin, which is what i'd prefer to use. i guess it's just growing pains. i cant help but think git wasn't meant for enterprise use. |
|
Git works more than fine for Enterprise, we (in the mobile group) at our software shop use it all day.
It's the greatest thing to ever happen to software developers that I can recall in the last 15 years. Your questions are so broad and numerous we'd have to go through them 1 at a time. PM me if you need help, I can conference with you on Skype screen share or if you have a mac, ScreenHero app. |
i almost took you up on this, and i still might. we finally got someone in here with git experience to help us out. basically, we were doing a lot wrong in order to force git into our company-mandated development process. funny though, using git with stash the right way better fits our model, we just needed a voice of experience to get us on track. yesterday we got a forking/branching strategy agreed upon by almost all the teams and got a few teams on the new strategy and actively developing new code. this morning i got many teams with working CI, after staying up damn near all night fixing people's poms (nothing to do with git). the offshore teams are going to be tough, there are language barriers obviously but they had an extremely hard time with SVN, i'm afraid this is going to be too much for them to handle. one "near shore" team actually just mails me patch files... 
but yeah, frustration is dissolving, we're productive again, and i still want to string up the guy that pushed us onto git with no warning, no training or knowledge transfer, no reasoning.. i bet he wanted to put a git migration on his resume while ignoring the fact that 10+ teams across the globe have to work in the same already messy codebase. |