Git workflow for a small team of developers and designers

I’m getting lost with Git branching model and the workflow that I want to create for my team (developers + designers).

Suppose that the project is based on a MVC pattern, so we have a structure similar to :

  • Can I have two different versions of cakephp into same Git repo? With different Git branches?
  • Using Git with your CakePHP Project
  • Where is the PHPUnit report schema used by Jenkins?
  • Beta testing new website features with live data and real customers
  • Should I use .gitignore, or auto-detect configurations for different servers in staging?
  • Good way to manage CakePHP, MAMP, and git?
  • Models/
    Controllers/
    Views/

    Developers works on the M & C parts with some basic/generated views (Rails, Django or CakePHP app for example)
    and Designers works on the V part

    How can I manage that developers works on M&C and keep some basic crappy views, and in the same time, designers make sexy views based on controllers actions coded and added by developers progressively ?

    I tried to make it works with 3 branches :

    master (production-ready)
    dev
    ui

    but no idea how a designer working on ui branch can keep the code elsewhere than /views updated an a working app…

    Thanks folks for help !

  • .gitignore and Visual Studio project: Ignore bin/Debug directory but not bin/Release directory
  • Git - corrupted object?
  • Configuring GitLab to store repositories for each user in personal directory
  • Setting colors for prompt in Git Bash on Windows
  • git Permission denied (publickey), on every connect
  • Is there a way to turn off git conflict resolution?
  • 4 Solutions collect form web for “Git workflow for a small team of developers and designers”

    With git, there’s no reason for developers to work on a separate branch or to have mocked up views. Have designers and developers work in the same branch, on the same codebase. When a view is done (or at least improved and not crashing) have the designer commit and push them to a master repository. The same is true for developers: when a local change is ‘done’, have them commit it and push it.

    Before pushing, each side needs to pull (to ensure there are no conflicts). If the two groups are working in mutually-exclusive pieces of code (separate files or even separate parts of the same files), then the pull will simply update the local copy and all will work well.

    With this, both sides are always seeing the most up-to-date codebase, and contributing directly towards the exact end goal, watching it evolve.

    Git is so simple to use, theres no reason everyone should not have their own branch to work out of. Hell, thats one of the main reasons to use a version control system. In Git, commits are cheap.

    Typically, we have a master, and anyone who is working on updates or features will branch from the master and branch a branch if need be, then a release master (someone like me) will take care of merging them all back down, checking for conflicts, testing the release and merging back to master.

    As you work on it, others can receive your changes by doing a fetch/pull against your branch to pull in the changes.

    Git isn’t magic. It doesn’t let your designers use code that the developers are actively writing. The developers still have to write, test and commit their code, and push it some place the developers can pull it from.

    Typically you’ll have a “bare” repository that all parties push their work to when it’s ready to be shared. Everybody else pulls that work down. It might be the designers job to pull the developer’s work and merge the dev branch into the ui branch, for example:

    git checkout ui
    git fetch
    git merge dev
    

    If you really want to enforce things like branch and path rights, I suggest you checkout gitolite

    This will allow you to manage access at all sorts of levels.

    Git Baby is a git and github fan, let's start git clone.