Git workflow for development in a shared environment

0
votes

I am trying to figure out the best git branch model and workflow for our case. We have a pretty special setting: developers don't have a local environment, all use the same shared environment.

Since our environment difficult to replicate, we use a shared environment for development. Modifications are uploaded to this shared environment to be executed and evaluated.

However, sometimes developers step on other's toes by updating the same file separately and causing other people's work being overwritten.

We have also an staging and production environment used for our testing and release process.

Does anybody know a git branching model that could fit our setting?

1
gitworkflow

1 Answers

0
votes

I have been in your shoes. I assume you mean that you use a shared working directory where your code (scripts?) lives and is in use by your webserver or whatever, and everyone is accessing that (i.e., the running code is your single shared working space at the same time)

One model would be:

  • Every dev gets his own clone of the repository, and is only allowed to git add ; git commit in that directory.
  • If a developer wants to modify the "live" working directory, he can only do so by doing a git pull ; git checkout xyz-branch in that directory. It is for purposes of this relatively inconsequential which branching regime you use. You can use the standard "gitflow" http://nvie.com/posts/a-successful-git-branching-model/ , or my personal favourite http://dymitruk.com/blog/2012/02/05/branch-per-feature/ . Or even just "one branch per developer + master".
  • This transfers the problem from your un-history-fied local working directory to the git commit tree. You now just have to find a way (with one of the workflows) to get out of the habbit of just manually modifying files all over the place directly in the live working directory.

But it would really be wise to take the effort to get rid of the shared working directory on your development environment, and try hard to give each developer his own.