Git Development Strategy for Small Team [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

We have a small digital team (3 designers, 3 developers) and are looking to integrate Git into our system.

At the moment, for most of our sites we have a staging site (dev.example.com) and a production site (example.com). Our developers usually make code changes to a local version, move those changes to the staging site and then, once approved, those changes are moved live. Our designers, on the other hand, make small edits (when developers are too busy) directly to the staging site and then push live once approved. Also, in some cases, we do not have a staging site and edits are pushed directly to the production site.

I know that the different workflows are not ideal but what would be the best way for us to integrate Git into this current system and keep the workflow fairly simple (for the designers' sake)? Should our current workflow be standardized first before incorporating Git (i.e. staging sites are mandatory and designers must develop locally before pushing to staging) or is Git flexible enough to work as-is?

I'm fairly new to Git but have read that a push should only be made to a bare repository. Is this necessary? If so, could this be the staging site? Or should it be its own entity (i.e. on an in-house server like example.local)?

Would a good workflow be as such:

1. User fetches and merges bare repository into local repository.
2. User develops locally and commits changes to local repository.
3. User pushes changes to bare repository at example.local (or something similar)
4. User pulls changes from bare repository to staging repository dev.example.com
5. When approved, user pulls changes from bare repository to production repository example.com

My only issue with this workflow is that the bare repository seems unnecessary...no? And finally, I und开发者_运维知识库erstand what would be logged on the local repository (the users changes, commits, etc.) but I'm unclear as to what would be logged on the bare repository (after the pushes), the staging (after the pull) and the production (after the pull); could all of the above steps be tracked and logged easily?

Thanks for any and all advice/answers!

---

here is one interestion git workflow: http://nvie.com/posts/a-successful-git-branching-model/

if your developers and designers are not familiar with the command line interphase, use a GUI git wrapper, there are several: gitx, gitbox, git tower, just google them to get their sites. find a tool or tools which your team is comfortable.

the best workflow is the one that fulfills your team needs, and it may change over time.

---

is Git flexible enough to work as-is?

Very much so.

The way I used to do it, Let the designers work on the design branch or something similarly named and always have a single command to push.

Developer merges the content from the design branch whenever he updates the server. In fact, merge will be a command, in the auto deployment script.

To stage the design changes only and not the dev changes, you can always switch the branch in the staging to the design branch. For this you can provide the designer with a deploy script that pushes the latest changes, switches to the design branch.

That being said, encourage the designers to use git, slowly and gradually. First hook them to the stash command. And pull. Then, ask them to create different branches.

As for the bare repository, It is a standard way to keep all people in sync and there is no technical reason to have that one extra really. Except that most people use the github or an equivalent remote backup service that has a good web UI to communicate and co-ordinate, which defacto becomes the central bare repository.

---

I don't see the reason to use a bare repository either. I wrote a short post about a simple developer process: A simple developer process with Git

This is not exactly your case, but a more general solution. The idea of using feature branches is to allow people to push their changes to the main repo without messing up everyone elses work and to make it easier to merge other people's changes.

If I did this, this is what I would do:

1. Install Gitorious. Not necessary but helps to keep track of things,
2. Create your production repository in Gitorious.
3. Add a post-hook to the production repository that, when updates are received, automatically updates the production server (maybe delayed to next night, what ever suits you best).
4. Create a development repository in Gitorious.
5. Add a similar post-hook to the development repository that updates the development server.

This setup has many advantages:

• Developers don't need to worry about updating the site. All they need to do is to push to dev repo.
• Updating the production server after tests pass is very simple, a mere push is enough (production repository is never updated from anywhere else than the development server). You could even add a section to the post-hook which does this if a tag is pushed. So you could mark the releasable version with a version number using a tag and this would automatically update the production server.
• There are far fewer points where someone can mess something up ("Oops! I meant to push to dev but instead pushed to prod.").