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 :

  • Ignore modifications after git add -f
  • How to change postgresql.conf default values on Openshift
  • How to upload changes from development branch to remote branch on GIT?
  • set folder permissions when deploying cakephp app
  • Version Git Repo for Composer Use - Git/Composer
  • How to organize CakePHP project on github that began with git clone CakePHP?
  • 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 !

  • How do you preview merge changes in one git command?
  • Can I push my git submodules to Github without using extra repositories?
  • Shell variable expansion in git config
  • Getting rid of some sensitive data in a git repo
  • how to control ownership of files auto-pushed to a git target repo by commit hooks?
  • Merging changes in intermediate branches with DVCS
  • 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.