[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[[["\u003cp\u003eStore all Terraform infrastructure code in version control to maintain a history of changes and enable easy rollbacks.\u003c/p\u003e\n"],["\u003cp\u003eUtilize a default branching strategy with a protected \u003ccode\u003emain\u003c/code\u003e branch for approved code and feature/bug-fix branches for development, merging changes back into \u003ccode\u003emain\u003c/code\u003e via pull requests.\u003c/p\u003e\n"],["\u003cp\u003eEmploy separate environment branches for root configurations to ensure a safe rollout strategy by merging changes between these branches.\u003c/p\u003e\n"],["\u003cp\u003eOrganize Terraform repositories based on team boundaries, with the option of central, team-specific, or decoupled repositories depending on the organization's structure and management requirements.\u003c/p\u003e\n"],["\u003cp\u003eNever commit secrets directly to source control; instead, use a system like Secret Manager and reference them through data sources, keeping in mind that the values can still end up in the state file.\u003c/p\u003e\n"]]],[],null,["# Best practices for version control\n\nThis document provides version control best practices to consider when using\nTerraform for Google Cloud.\n\nAs with other forms of code, store infrastructure code in version control to\npreserve history and allow easy rollbacks.\n\nThis guide is not an introduction to Terraform. For an introduction to using\nTerraform with Google Cloud, see\n[Get started with Terraform](/docs/terraform/get-started-with-terraform).\n\nUse a default branching strategy\n--------------------------------\n\nFor all repositories that contain Terraform code, use the following strategy by\ndefault:\n\n- The `main` branch is the primary development branch and represents the latest approved code. The `main` branch is [protected](https://docs.gitlab.com/ee/user/project/protected_branches.html).\n- Development happens on feature and bug-fix branches that branch off of the `main` branch.\n - Name feature branches `feature/$feature_name`.\n - Name bug-fix branches `fix/$bugfix_name`.\n- When a feature or bug fix is complete, merge it back into the `main` branch with a pull request.\n- To prevent merge conflicts, rebase branches before merging them.\n\nUse environment branches for root configurations\n------------------------------------------------\n\nFor repositories that include root configurations that are directly deployed to\nGoogle Cloud, a safe rollout strategy is required. We recommend\nhaving a separate *branch* for each environment. Thus, changes to the Terraform\nconfiguration can be promoted by\n[merging changes between the different branches](/docs/terraform/resource-management/managing-infrastructure-as-code).\n\nAllow broad visibility\n----------------------\n\nMake Terraform source code and repositories broadly visible and accessible\nacross engineering organizations, to infrastructure owners (for example, SREs)\nand infrastructure stakeholders (for example, developers). This ensures that\ninfrastructure stakeholders can have a better understanding of the\ninfrastructure that they depend on.\n\nEncourage infrastructure stakeholders to submit merge requests as part of the\nchange request process.\n\nNever commit secrets\n--------------------\n\nNever commit secrets to source control, including in Terraform configuration.\nInstead, upload them to a system like\n[Secret Manager](/secret-manager/docs) and reference them by using data\nsources.\n\nKeep in mind that such sensitive values might still end up in the state file\nand might also be exposed as outputs.\n\nOrganize repositories based on team boundaries\n----------------------------------------------\n\nAlthough you can use separate directories to manage logical boundaries between\nresources, organizational boundaries and logistics determine *repository*\nstructure. In general, use the design principle that configurations with\ndifferent approval and management requirements are separated into different\nsource control repositories. To illustrate this principle, these are some\npossible repository configurations:\n\n- **One central repository**: In this model, all Terraform code is\n centrally managed by a single platform team. This model works best when\n there is a dedicated infrastructure team responsible for all cloud\n management and approves any changes requested by other teams.\n\n- **Team repositories:** In this model, each team is responsible for their\n own Terraform repository where they manage everything related to the\n infrastructure they own. For example, the security team might have a\n repository where all security controls are managed, and application teams\n each have their own Terraform repository to deploy and manage their\n application.\n\n Organizing repositories along team boundaries is the best structure for most\n enterprise scenarios.\n- **Decoupled repositories** : In this model, each *logical* Terraform\n component is split into its own repository. For example, networking might\n have a dedicated repository, and there might be a separate project factory\n repository for project creation and management. This works best in highly\n decentralized environments where responsibilities frequently shift between\n teams.\n\n### Sample repository structure\n\nYou can combine these principles to split Terraform configuration across\ndifferent repository types:\n\n- Foundational\n- Application and team-specific\n\n#### Foundational repository\n\nA *foundational* repository that contains major central\ncomponents, such as folders or org IAM. This repository\ncan be managed by the central cloud team.\n\n- In this repository, include a directory for each major component (for example, folders, networks, and so on).\n- In the component directories, include a separate folder for each environment (reflecting the directory structure guidance mentioned earlier).\n\n#### Application and team-specific repositories\n\nDeploy *application and team-specific* repositories separately for each\nteam to manage their unique application-specific Terraform configuration.\n\nWhat's next\n-----------\n\n- Learn about [best practices for Terraform operations](/docs/terraform/best-practices/operations).\n- Learn about [best practices for using Terraform securely](/docs/terraform/best-practices/security)."]]