哪种Git工作流程适合我们的情况? [英] What kind of Git workflow suits our case?
问题描述
我们目前只有master个分支.我们当前的工作流程包括在本地实施功能，提交到存储库并更新测试服务器，让客户知道它，并且如果他批准更改，我们还将更新产品.
We have currently just master branch. Our current workflow involves implementing the features locally, committing to the repository and updating the test server, letting the client know about it and if he approves the changes we also update the production.
问题在于，现在我们使用SVN，并手动更新了已更改的特定文件夹和文件，因为否则我们可能会在生产中进行不必要的更改.将Git作为我们即将用于一个项目的近期仓库，什么样的Git工作流/分支将适合我们的需求? Git工作流程需要在这种情况下工作良好:
The thing is that now we use SVN and we update manually the specific folders and files that we have changed because otherwise we might get unwanted changes to production. With Git as our near-future repo that we use for one project already, what kind of Git workflow/branching would suit our need? The Git workflow needs to work well for this scenario:
- 在本地工作.
- 更新测试服务器并让客户端知道.
- 如果客户批准了更改，则也要更新产品.
理想情况下，我们希望可以一次将所有文件和文件夹的产品更新为特定标签.测试和生产可能会与许多开发人员发生一些不同的变化，其中有些需要转移到生产中，而有些则不需要.
Ideally we would want it to be possible to update the production to a specific tag all files and folders at once. It's possible that test and production have several different changes from many developers and some of them need to be moved to production some not.
最初，我想到了3个分支master用于生产稳定的发行版，test用于测试服务器(要从dev合并到)和dev进行编码.我不确定这是否合适.
Initially I thought of having 3 branches master for production stable releases, test for the test server (to be merged to from dev) and dev where we code. I'm not sure if this fits well.
推荐答案
在我看来，您不必为每个服务器都需要分支-级联更改时，这可能会产生(取决于您的忽略和其他因素)一些问题上和下.相反，您的各种服务器可以只签出一个分支并将更改拉到该分支.拥有存储库完整副本的服务器非常非常有用.
In my opinion, you wouldn't necessarily need branches for each server - this can create (depending on your ignores and some other factors) some issues when cascading changes up and down. Instead, your various servers can just have a branch checked out and changes pulled to it. The server having a complete copy of the repository is very, very useful.
我们的生态系统最初包括每个服务器，生产，暂存和开发的分支机构-分支机构之间的同步更改有时会导致合并问题，这非常令人沮丧.目前，我们已将所有服务器的生产分支都检出，并且为自己省了很多麻烦.在实际在生产服务器上pull之前，我们会检查所有内容-如果需要，您还可以切换分支以测试更剧烈的编码更改.那里有很多灵活性.
Our ecosystem initially included branches for every server, production, staging, and development - syncing changes between the branches sometimes created merge issues that were very frustrating. We currently have all of the servers with the production branch checked out, and we've saved ourselves quite a few headaches. We check everything there before actually pulling on the production server - you can also switch branches if needed to test more drastic coding changes. There's a lot of flexibility there.
我的建议是评估您的工作流程，看看是否可以利用钩子来自动执行更新测试/登台服务器的过程.我们对甘醇钙石做到了这一点.否则，您的工作流程就很容易实现，您可以对该概念进行一些改进以使其进一步自动化.
My suggestion would be to evaluate your workflow and see if you can leverage hooks to automate the process of updating your test/staging servers. We do this wonderfully with gitolite. Otherwise, your workflow is easily achieved, and you can put some polish on the concept to automate it further.
这篇关于哪种Git工作流程适合我们的情况?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
