0

I'm working on a project in a small team at the moment working on a webapp. We originally had 3 on the team with a lead dev and now we've grown to 7 and a lead dev.

At the moment our workflow is this: we all work off of one central repository and use SVN. Once we get our dev environment to a somewhat stable stage we copy it over to our testing site, then we push it live. At the moment I'm trying to push a single feature live, so I'm copying bits a pieces from our dev environment over to our test environment and it's a bit of a pain which has prompted this post.

(Disclaimer, my knowledge of git is mainly push, pull and commit) In my mind we should be doing the following: maintain one branch of code. Each dev would then create branch when working on a feature then when complete merge it back to the main branch.

My boss, the lead dev, reckons that merging in PHP is a pain in the ass. I can't think of why it would be different to any other language but I don't have the experience to know any better. Is this a workflow that we should be looking into or is there a better way? What way does your workflow go?

Thanks

Peck3277
  • 153
  • 3
  • 3
    There's absolutely no reason why merging in PHP would be any different to merging in any other language. Could you ask your lead dev to elaborate? Is it possible that's not exactly what he meant? Also, your feature branches idea is not only good enough for the task at hand, but is also quite common: https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow. – yannis May 06 '15 at 10:44
  • Oh it's not my idea, I got it from researching but I wasn't really sure if there was something newer/better! Last time I asked he kind of said it's messy in PHP but it wasn't a proper conversation. I think I need to read up fully on the concept and then approach the topic with him again. Thanks for the link I think it will be a good help! – Peck3277 May 06 '15 at 11:07
  • While not strictly part of your question, you _should_ be using a build server that generates repeatable, consistent builds even if using branches. While working piecemeal in a poorly-thought-out branching scheme is a headache, copying bits of code to the test environment just makes that headache worse. –  May 07 '15 at 02:26

1 Answers1

0

Merging in SVN is no different to merging in git - if the computer can figure it out, it does it and all's good, if it needs manual attention it prompts you. (exception: SVN's handling of new/deleted/renamed files is poor, but git can have issues in this area too).

So, that out of the way you can really think of SVN as a clone of a repo that you push to. Once you have a working copy, you modify it and commit the changes - they are effectively committed and pushed in a single stage and the origin repo automatically pulls your changes to it. All very simple.

Branching: not much different here, create a branch off the trunk per dev, do work, then merge it back onto trunk. Very simple, really easy. Works.

Once you have a stable trunk with all the features you want, you should create or update a tag - this is just a branch by a different name. I'd maintain a tag for your test and live environments, just merge the trunk to the test tag when you're ready to deploy and your test environment can then simply update its working copy from that tag. When its passed test, either merge the test tag to the live one, or (better) create a new live tag from the test branch.

I've never found git v svn particularly different, obviously the tooling is but the concepts of branching, merging and updating is roughly the same. What you would do with git is just the same with svn - only with a central repo that you transfer the files to or from instead of pushing and pulling to different repos, the SVN 'working copy' being the equivalent of your local git repo.

So that's a very rough description - basically, your old workflow should still be the one to use with SVN.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172