小团队的Git发展战略 [英] Git Development Strategy for Small Team

问题描述

我们有一个小型数字团队（3名设计师，3名开发人员），并正在考虑将Git整合到我们的系统中。

目前，我们大多数网站都有一个中转站点（dev.example.com）和一个生产站点（example.com）。我们的开发人员通常会将代码更改为本地版本，将这些更改移至暂存站点，然后一旦批准，这些更改就会实时移动。另一方面，我们的设计人员（当开发人员太忙时）将小编辑直接发送到中转站点，然后在批准后推送直播。此外，在某些情况下，我们没有暂存站点，编辑将直接推送到生产站点。

我知道不同的工作流程并不理想，对我们而言，将Git整合到当前系统中并保持工作流程相当简单（为了设计者的缘故）是最好的方法吗？在合并Git之前，我们当前的工作流程是否应该先标准化（例如，分段站点是强制性的，设计师必须在推动分级之前进行本地开发）还是Git足够灵活以便按原样工作？

我对Git相当陌生，但已经阅读过，只能对裸仓库进行推送。这是必要的吗？如果是这样，这可能是中转站点吗？或者它应该是它自己的实体（即在像example.local这样的内部服务器上）？

良好的工作流程是这样的：

1. 用户获取并合并裸仓库到本地仓库。


2. 用户在本地开发并将更改提交到本地仓库。 >
   
3. 用户通过example.local（或类似的东西）将更改推送到裸存储库。


4. 用户将更改从裸存储库提取到暂存存储库dev.example.com。 li>
   
5. 批准后，用户将更改从裸存储库提取到生产存储库example.com

我唯一的问题有了这个工作流程，裸仓库似乎是不必要的......不是吗？最后，我知道本地存储库上会记录什么（用户更改，提交等），但我不清楚将在裸存储库上记录的内容（推后），分段（在拉）和生产（拉动之后）;上述所有步骤都可以被跟踪和记录吗？

感谢任何和所有的建议/答案！

解决方案

这是一个interestion git工作流程： http://nvie.com/posts/a-successful-git-branching-model/ 如果您的开发人员和设计人员不熟悉该命令，则可以使用

在线Interphase中，使用一个GUI git包装器，有几个： gitx ， gitbox ， git塔，只是谷歌他们得到他们的网站。找到适合您的团队的工具。

最好的工作流程是满足您团队需求的工作流程，并且可能会随着时间而改变。 b $ b

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 understand 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.

这篇关于小团队的Git发展战略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！