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.
至于裸存储库，这是一种让所有人保持同步的标准方法，并且没有任何技术原因需要额外拥有该存储库。除了大多数人使用 github 或具有良好 Web UI 的等效远程备份服务来进行通信和协调之外，它实际上成为了中央裸存储库。
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:
Install Gitorious. Not necessary but helps to keep track of things,
Create your production repository in Gitorious.
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).
Create a development repository in Gitorious.
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.").
发布评论
评论（3）
这是一个有趣的 git 工作流程： http://nvie.com/posts/a -successful-git-branching-model/
如果你的开发人员和设计人员不熟悉命令行界面，请使用 GUI git 包装器，有几种：
gitx、gitbox、git tower，只需用谷歌搜索即可获取他们的网站。找到您的团队熟悉的一个或多个工具。最好的工作流程是满足您团队需求的工作流程，并且它可能会随着时间的推移而改变。
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.
非常如此。
我过去的做法是，让设计人员在
design分支或类似名称的分支上工作，并且始终只有一个命令可以推送。开发人员每当更新服务器时都会合并来自设计分支的内容。事实上，合并将是自动部署脚本中的一个命令。
要仅暂存设计更改而不暂存开发更改，您始终可以将暂存中的分支切换到设计分支。为此，您可以为设计人员提供一个部署脚本，用于推送最新更改，切换到设计分支。
话虽这么说，鼓励设计师慢慢地、逐步地使用 git。首先将它们挂钩到 stash 命令。并拉。然后，要求他们创建不同的分支。
至于裸存储库，这是一种让所有人保持同步的标准方法，并且没有任何技术原因需要额外拥有该存储库。除了大多数人使用 github 或具有良好 Web UI 的等效远程备份服务来进行通信和协调之外，它实际上成为了中央裸存储库。
Very much so.
The way I used to do it, Let the designers work on the
designbranch 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
stashcommand. 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.
我也不明白使用裸存储库的原因。我写了一篇关于简单开发流程的简短文章：
使用 Git 的简单开发流程
这不是正是你的情况，但更通用的解决方案。使用功能分支的想法是允许人们将他们的更改推送到主存储库，而不会弄乱其他人的工作，并且更容易合并其他人的更改。
如果我这样做，我会这样做：
这种设置有很多优点：
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:
This setup has many advantages: