Magento和Git的版本控制

This article is part of a series created in partnership with SiteGround. Thank you for supporting the partners who make SitePoint possible.

本文是与SiteGround合作创建的系列文章的一部分。 感谢您支持使SitePoint成为可能的合作伙伴。

Many developers may wish to use version control with their Magento site as they develop it, and perhaps continue doing so as they maintain and add to the live website. Here, we’ll focus on Git as the version control system of choice. This article is meant not as a step by step instruction, but rather a set of tips and things to consider when you’re working with Magento and Git.

许多开发人员可能希望在他们的Magento网站上使用版本控制，并且在维护和添加到实时网站时可能会继续这样做。 在这里，我们将重点介绍Git作为选择的版本控制系统。 本文的目的不是作为分步说明，而是在使用Magento和Git时应考虑的一系列技巧和注意事项。

为什么要完全使用Magento和Git？ (Why use Magento and Git at All?)

Magento is one of the world’s most popular and innovative ecommerce platforms. With a huge customer base and countless developers building applications in it, extending and theming it, Magento is an excellent choice for ecommerce websites.

Magento是世界上最受欢迎和创新的电子商务平台之一。 Magento拥有庞大的客户群，无数开发人员在其中构建应用程序，对其进行扩展和主题化，是电子商务网站的绝佳选择。

Git is similarly the leading version control system of the day. There are many places to go for Git hosting, such as GitHub or BitBucket, (What are the Differences Between Git and BitBucket?) and Git is the easiest VCS to use if you want the most developers to be familiar with it, as it’s used everywhere, and for all manner of projects, ranging from single page private sites to massive production applications.

同样，Git是当今领先的版本控制系统。 Git托管有很多地方，例如GitHub或BitBucket (( Git和BitBucket之间的区别是什么？ )，如果您希望大多数开发人员熟悉它，Git是最容易使用的VCS。从单页私有站点到大规模生产应用，无处不在，适用于各种项目。

Why would you want to version control your Magento site with Git? That’s an easy question to answer as well. When creating or altering things like themes or other custom coding, you’ll want to make sure those changes are not only saved, but also that your retain the ability to easily roll back changes. You’ll want the ability, perhaps, for other developers to clone your working setup and add features or fixes as well, or to easily deploy your site code to another testing or staging server. Git can help with all of that.

您为什么要使用Git对Magento网站进行版本控制？ 这也是一个容易回答的问题。 在创建或更改主题或其他自定义编码等内容时，您将要确保不仅保存了这些更改，而且还保留了轻松回滚更改的功能。 您可能想要让其他开发人员能够克隆您的工作设置并添加功能或修复程序，或者轻松地将站点代码部署到其他测试或登台服务器的功能。 Git可以为您提供所有帮助。

确定要包含在存储库中的内容 (Deciding What to Include in the Repository)

One of the first decisions is what exactly to include in the repository. This is going to depend heavily on your use case.

首要决定之一是在存储库中确切包含什么。 这将在很大程度上取决于您的用例。

首先，决定您的方法 (First, Decide on Your Approach)

First, you’re going to have to decide on your approach. What is Git repository for? Do you wish to store your entire site? If so, you’re going to have to make note of items that you do not want to store in the repository. This might be useful if you have a small team and find it easier to just pull down a large Git repository containing your (almost) entire site, rather than setting up Magento in a new environment, and then pulling in only a few assets from a Git repository.

首先，您将必须决定自己的方法。 Git存储库是做什么用的？ 您要存储整个网站吗？ 如果是的话，你将不得不作出记项，你不想在仓库中存储。 如果您的团队很小，并且发现只需要删除一个包含(几乎)整个站点的大型Git存储库，而不是在新的环境中设置Magento，然后仅从一个环境中获取一些资产，这可能会很有用。 Git存储库。

On the other hand, perhaps your team is already set up with substantial build tooling, and able to deploy the same version of Magento and other software to any environment without trouble, and you really only want to version control the specific files that are under development.

另一方面，也许您的团队已经建立了强大的构建工具，并能够将Magento和其他软件的相同版本毫无问题地部署到任何环境中，并且您实际上只想对正在开发的特定文件进行版本控制。 。

Knowing your approach will dictate the rest of your Git decisions with Magento.

了解您的方法将决定您与Magento一起进行的其他Git决策。

考虑数据库和配置文件 (Consider Databases and Configuration Files)

Some Git teams do database dumps to files that are inside the Git repository, so that when creating a new environment, as soon as the repository is pulled down, you have a relatively recent copy of the production database for use in setting up the new dev or test environment.

一些Git团队将数据库转储到Git存储库中的文件，以便在创建新环境时，一旦存储库被拉下，您就会拥有生产数据库的相对较新的副本，用于建立新的开发环境。或测试环境。

Other teams might balk at this. It may depend on your situation, and perhaps more importantly, on your team and project’s security. If the project is open source, or is open to a large section of your own company, even, you may not want to be including copies of your database files, as this would be grossly insecure. Shared amongst three developers on a private repository, for a startup app that is still under development and not in production, it might be exactly what you want. However, if you don’t put database dumps in your repository, you will need to create a process for sharing database files in order to create cloned environments as needed for development and testing.

其他团队可能对此表示怀疑。 这可能取决于您的情况，也许更重要的是取决于您的团队和项目的安全性。 如果该项目是开源的，或者是对自己公司的很大一部分开放的，那么即使您不希望包含数据库文件的副本，因为这绝对是不安全的。 在私有存储库中的三个开发人员之间共享，对于仍在开发而不是在生产中的启动应用程序，这可能正是您想要的。 但是，如果您不将数据库转储放在存储库中， 则需要创建一个共享数据库文件的过程，以便根据开发和测试的需要创建克隆的环境。

Configuration files are treated much the same way. Typically, you are going to want to keep magento/app/etc/local.xml out of your repository if you have any security concerns at all, because of the credentials stored within it.

配置文件的处理方式几乎相同。 通常，由于存储在其中的凭据，如果您完全有任何安全方面的考虑，则将magento/app/etc/local.xml排除在存储库之外。

如何处理图片 (How to Handle Images)

The /media folder can become quite massive for large Magento installations. When it’s below a certain amount of content, perhaps during development or early stages, it may make sense to include it to have image content for testing in other environments. When it starts getting too large though, it may just make more sense to ignore the entire thing, and then perhaps use a fake image set for test environments.

对于大型的Magento安装， /media文件夹可能会变得很大。 当其含量低于一定数量时，可能在开发或早期阶段，将其包含为可在其他环境中进行测试的图像内容可能是有意义的。 但是，当它开始变得太大时，可能更有意义的是忽略整个事物，然后为测试环境使用伪造的图像集。

设置您的.gitignore (Setting up Your .gitignore)

Once you’ve made your decisions about what you want in your Git repository, the next step before beginning to use Git is going to be to come up with your .gitignore file contents (the items that will be ignored by Git when pushing to or pulling from your project repository). This .gitignore file goes at the root of your repository, and instructs Git on files to ignore. It may be a relativelty small list, like the below, or it might cover the majority of your application – that’s up to your strategy for version control.

在决定要在Git存储库中的内容之后，开始使用Git的下一步就是提出.gitignore文件内容(当推送到或时，Git将忽略的项目)。从您的项目存储库中提取)。 该.gitignore文件位于存储库的根目录，并指示文件上的Git忽略。 它可能是一个相对较小的列表，如下所示，或者它可能涵盖了您的大多数应用程序-这取决于您的版本控制策略。

magento/app/etc/local.xml
magento/cron.php
magento/cron.sh
magento/errors/
magento/install.php
magento/LICENSE*
magento/media 
magento/RELEASE_NOTES.txt
magento/robots.txt

Note that this isn’t a complete .gitignore to copy and paste, but just a set of ideas – you’ll want to decide on additonal items to remove or add to this list, depending on your own project’s needs.

请注意，这不是复制和粘贴的完整.gitignore，而只是一组想法–您需要根据自己项目的需要，决定要删除的其他项目或将其添加到此列表中。

You also might want to take a look at the contents of your .htaccess – if they are specific to your environment, that may need ignored. You may also want to ignore some or all of var – caching, errors, etc. may be unnecessary to commit to source control.

您可能还需要查看.htaccess的内容-如果它们特定于您的环境，则可能需要忽略它们。 您可能还想忽略部分或全部var缓存，错误等对于提交源代码管理可能是不必要的。

Git安全 (Git Security)

You’ll want to make sure and consider your Git repository’s security. Who has access to the repository, and do they have read or write access? Do you alter or revoke permissions when a user changes roles or leaves your project? Is the project open source or private? Could it ever become open source? These are all considerations when you first set up your repository.

您需要确保并考虑Git存储库的安全性。 谁有权访问存储库，并且他们具有读或写访问权限？ 当用户更改角色或离开您的项目时，您是否更改或撤消权限？ 该项目是开源的还是私有的？ 它将成为开源吗？ 这些是您首次设置存储库时的所有注意事项。

分支机构与环境 (Branching Structure and Environments)

Another thing to consider right at the beginning is your branching structure. Many projects have something similar to the following:

一开始要考虑的另一件事是您的分支结构。 许多项目具有类似于以下内容：

- Development
- Staging
- Production

But of course you can tailor the branches to your needs. You could have temporary branches, for say theme development or custom features, then merge them into the development pipeline when complete. The strategy is up to you, but the important part is to plan it out and execute it, and not fall into the trap of commiting everything to the master branch in your repository. Branching is part of the reason you use Git!

但是当然，您可以根据需要定制分支机构。 您可以有临时分支，例如主题开发或自定义功能，然后在完成时将它们合并到开发管道中。 该策略取决于您，但是重要的部分是计划和执行它，而不是陷入将所有内容提交到存储库中的master分支的陷阱。 分支是您使用Git的部分原因！

部署策略 (Deployment Strategy)

Finally, you may want to consider your deployment strategy as well. Are you going to deploy using Git on the production server? Will you use an outside service, such as DeployHQ to deploy via FTP when your Git repository is updated? Or will you do deployments manually? SiteGround offers a Git integration that is quite handy for developers who are using their hosting.

最后，您可能还需要考虑您的部署策略。 您要在生产服务器上使用Git进行部署吗？ 当您的Git存储库更新时，您是否将使用外部服务(如DeployHQ)通过FTP进行部署？ 还是您将手动进行部署？ SiteGround提供了一个Git集成，对于使用托管的开发人员来说非常方便。

结论 (Conclusion)

With careful planning and setup, Magento and Git can work hand in hand to provide you with a better, more secure site and a much more efficient development strategy. Get out there and build awesome ecommerce platforms with Magento and Git, and keep them safe and productive!

通过精心的计划和设置，Magento和Git可以携手合作，为您提供更好，更安全的站点和更高效的开发策略。 赶紧去那里，用Magento和Git构建很棒的电子商务平台，并确保它们安全高效！

翻译自: https://www.sitepoint.com/version-control-magento-git/