1

At home, I have a server that is running some software (on a LAMP stack, but only accessible internally). I have another machine and a laptop that I both use for developing said software. What is the best workflow for me?

Should I have a repository on my local server, create a live branch, staging branch and development branch, then checkout the development branch from my laptop/development PC to work on, commit that back when I'm done, then merge the development branch with the staging branch for testing, before further merging to the live branch?

Would I simply checkout the production branch to my /www/var/ on my server?

Or am I thinking/going about this all wrong?

Thanks.

Improve this question
3
  • 1
    To the answerers: It would be interesting to hear how to set up Git hooks to automatically manage deployment too!
    – Kos
    Commented Jun 9, 2012 at 10:26
  • 1
    @Kos I think it would be best if you post that as a question. I myself would like to know an answer to that question.
    – Apoorv
    Commented Jun 9, 2012 at 12:53
  • How many people are developing your software? How closely do you need to collaborate? How many different things do you expect to be working on at a time? What other external dependencies are there on your workflow (i.e. expectations from customers, testers, etc.)? Some more details on these will help you get to the minimal workflow that will meet your needs.
    – Owen S.
    Commented Jun 9, 2012 at 20:21

1 Answer 1

Reset to default
5

Never checkout the production branch

Or more specifically, never work off the production branch (it is ok to check it out for testing and/or patching). And here is why. You never know when or if you would be asked to work on a different requirement/fix while you are already developing something else. The production branch should only be used for testing the code that is about to go live or to make quick fixes (fixes that have a development cycle much shorter than the avg. timespan between two check-ins to the production branch).

The first approach you have mentioned is the one I have observed most commonly in enterprise settings. Here are the advantages:

  1. You can create as many different branches as you want for different features.
  2. You do not have to lose your work should you decide to abandon your task temporarily or have to work on a different task for a short while.
  3. Many developers have a habit of committing their changes to the branch so that they have a back-up (and to answer themselves "how the ... did I get here?" You obviously cannot take this approach with the production branch. If you use the Perforce system (I know you mentioned you are not) then you may be tempted to use the shelve feature but that does not get you out of situations I described in #1 and #2.

Some off topic advice on how to maintain dev. branches

I think it is a good practise to regularly merge the production branch to your dev. branch so that you do not have to undertake a massive merge task when you decide to merge your changes to the production branch. Another advantage of this practise is that if someone checks in a conflicting change to your changes to the production branch then you can find about that in your development cycle itself (assuming you test regularly while developing).

Another practise that you can follow to avoid messing up the production branch is to merge the production branch one final time with your dev. branch, test your dev. branch thoroughly to resolve/discover any conflicts (not just those that come up as line differences but even those that can come up as design level conflicts), and then merge your branch back to production.

Yet another good practise is to label the dev. branch with something that identifies the specific goal of that development task rather than just who owns that dev. branch (hence, dev_notificationEnhancement and not dev_monstertruck).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.