Advice on web application workflow and GIT

After years of being a mediocre PHP developer, I’m trying to learn a little more about modern workflows and best practice for developing web apps. I’ve studied up on task runners, dependency managers, git, and cloud servers. I’m working on a PC predominantly and I’ve decided to settle with

  • PHP and Bootstrap 3 for front end work
  • MYSQL (NoSQL seemed like overkill for what I need)
  • AppFog for cloud hosting with git for repository control
  • gulp.js for task automation - it seemed far simpler than grunt for PHP projects
  • either bower or composer for dependency management (still can’t decide)

Best practice generally seems to be that you have two folders - a ‘src’ and a ‘build’ folder. I understand that build is where all your compiled and minified scripts end up along with a copy of your application code, in order to be deployed to your development server.

I’m struggling to understand how I would work this into a git workflow. Specifically

  1. Should I create two repos - one in src and one in build or is possible to have build build as some form of branch that can never be merged, only deployed?
  2. Alternatively, should I only have a repo for build

Every developer works differently, but I’m just trying to get a sense for what’s common.

Creating 2 repos and maintaining both separately would be a major pain in the butt. You want to have your development branch then merge that into your production branch.

For larger projects with multiple developers, you should even create Feature branches which are subsets of the Development branch. For the most part this usually overkill if you’re the sole developer, unless you got something you’re working on alongside of things that may break other things. this is a good read. Kinda old, but it’s not really technology specific (besides being git) and more about the idea.

Also, since you’re on PC look into Source Tree if you haven’t already. It’s pretty great. They need to hurry up and get a linux version.

Thanks mawburn. I figured that having two repos wouldn’t be a good idea. What I’m still struggling with is how do I get this working with two different folders - a src folder with all my uncompiled source and a build folder with every script file concatenated, minified and production ready?

I could just have the repo in the build folder, but then I wouldn’t get the advantage of using git whilst developing. Alternatively, I could put it in the root and have everything in the repo (build and src) but then how would I go about only pushing the src to my live server?

Any advice on what others tend to do would be appreciated.

The key question is “how is /build generated?”

If it is a completely automated artifact of the /src folder using some scripts I would keep the scripts and /src in my repo and let it create /build on demand. As for deployment a lot depends on what you have in place but a simple enough solution would be to have some automated process check out the repo to a non-web accessible folder (ie – it’s home folder) and run the build script to drop the artifacts in the right place. Another model would be to have a repo that was part of the build process which gets updated via script when you generate final output. Then you could check that out directly on the server.

The build is generated through gulp.js (or grunt even).

When you say “updated via script when you generate the final output”, do you mean manually updating a .git repo when the gulp.js task is run?

Presuming said build is scripted you can just install gulp or grunt on the server and deploy locally then – that is your make for all intents and purposes.