Source control management and Cloud Source Repositories. Every time you change a file, you risk losing the old version or overwriting a teammate's work. This problem is why every professional team uses a source control system – and for PCDOE, you must know how Google Cloud's version, Cloud Source Repositories, fits into the larger DevOps workflow of continuous integration and deployment.
Jump to a section
A simple way to picture Source Control Management and Cloud Source Repositories
You and 4 friends are writing a 47-page report for a university project. Without a system, one person writes the introduction, another the findings, and a third the conclusion, all on their own laptops. When you try to combine them, you realise your friend used the old version of the budget table, someone else deleted your carefully crafted summary, and the file names are a mess of 'final_v3_actual_final_reallyfinal.docx'. Chaos.
Source control management (SCM) is the digital filing cabinet and rulebook that stops this chaos. It tracks every single change to every file, like a time machine. You create a 'repository' (the project folder). When you want to make changes, you 'commit' them with a message like 'Added budget table version 2'. Everyone pulls down the latest version before editing, so nobody overwrites anyone else's work. If a mistake gets made, you 'roll back' to a previous version as easily as pulling a page out and replacing it with an earlier draft.
Cloud Source Repositories (CSR) is Google Cloud's secure, offsite filing cabinet for this system. You don't need to manage your own server; Google hosts it. You push your local changes up to the cloud, and your teammates pull them down, all while Google handles backups, security, and availability. The 47-page report gets written without tears, every version is recoverable, and everyone knows who changed what and why.
Imagine you are working on a recipe book with a friend. You both have a physical notebook. You write down a new chocolate cake recipe on page 10. Meanwhile, your friend, using the same notebook on their side, decides to improve the pasta sauce on page 15. But you are both holding the same physical book. If you send your changes to your friend, they have to manually copy your chocolate cake recipe into their book, and you have to manually copy their pasta sauce changes. It is slow, error-prone, and if you both edit the same page, one person's work gets destroyed.
Source control management (SCM) is the digital version of that notebook, but with magic powers. It is a system that records every single change made to a set of files, when it was made, who made it, and why. The core concept is a 'repository' (often shortened to 'repo'), which is essentially a folder or database containing all the project files and their entire history.
Here are the core actions in any source control system:
Commit: Like taking a snapshot of your notebook at a specific moment. When you've made a set of changes (e.g., adding the chocolate cake recipe and fixing a typo in the pasta sauce), you 'commit' them. This creates a permanent record in the history with a unique identifier and a message you write describing what you changed, e.g., 'Added chocolate cake recipe and fixed pasta sauce typo'.
Branch: This is the most powerful feature. Think of a branch as a separate copy of the entire notebook where you can experiment without affecting the main book. You might create a branch called 'experimental-tofu-recipe'. You can make wild changes in that branch (adding 10 new tofu recipes), and the main notebook (often called 'main' or 'master') remains perfectly clean. Once your tofu recipes are perfected, you can 'merge' that branch back into the main book, bringing all those changes in.
Merge: The action of combining changes from one branch into another. For example, taking all the tofu recipes from your 'experimental-tofu-recipe' branch and adding them into the 'main' book. If two people changed the same line in the same file, a 'merge conflict' occurs – the system tells you it cannot decide which change to keep. You then manually resolve it by choosing one version or writing a new combination.
Pull / Push: These are the actions of syncing your local copy with the remote copy (the one in the cloud). 'Push' means sending your commits from your computer to the remote repository. 'Pull' means downloading new commits from the remote repository to your computer.
Cloud Source Repositories (CSR) is Google Cloud's fully managed, private Git repository service. Git is the specific piece of software that handles version control (comparing files, managing branches, merging). CSR is the hosting platform that stores your Git repositories in Google Cloud. You do not need to manage any servers or worry about backups. It integrates directly with other Google Cloud services like Cloud Build (for automated testing and building) and Cloud Run (for deploying code).
For authentication, CSR uses Google Cloud IAM (Identity and Access Management). Instead of a username and password, you can use an SSH key or a generated credential file. This means access control is consistent with the rest of your Google Cloud permissions.
This system replaces the old way of working: emailing files back and forth, using confusing file names like 'report_final_v2.doc', and having no way to go back to a previous version if a bug is introduced. It is the foundation of modern software development and a core tool for any DevOps engineer.
Create the Repository
In the Google Cloud Console, navigate to 'Source Repositories' and click 'Add repository'. Choose a name, select the project, and set it as public or private. This creates the centralised storage location for your code. Google automatically creates an empty Git repository ready to receive commits.
Authenticate and Clone Locally
Generate an SSH key pair or use a credential helper. Run `gcloud source repos clone REPO_NAME` in your terminal. This downloads a copy of the (empty) repository to your local machine, setting up the remote connection so future pushes and pulls work automatically.
Add Files and Make Your First Commit
Place your project files into the local folder. Use `git add .` to stage all changes, then `git commit -m 'Initial commit with project skeleton'`. This creates a timestamped snapshot of your files with a message explaining what you did.
Push the Commit to the Cloud
Run `git push origin main` (or `master`). Your local commit travels to Cloud Source Repositories. Now all team members can pull this version. The push also triggers any configured Cloud Build triggers that watch the `main` branch.
Create a Branch and Work Collaboratively
Run `git checkout -b feature/add-payment` to create and switch to a new branch. Make changes, commit them locally, then push using `git push origin feature/add-payment`. Other team members can see this branch in the console and pull it for code review.
Open a Pull Request and Merge
In the Cloud Source Repositories UI, navigate to 'Pull Requests' and click 'Create pull request'. Select the source branch and target branch (e.g., main). Add reviewers and a description. Once approved and all checks pass, click 'Merge'. This integrates the feature branch into the main codebase.
An IT professional, let us call her Priya, works as a platform engineer for a mid-sized online retailer. The company has 12 backend developers, 4 front-end developers, and 2 data engineers. They all need to work on the same e-commerce platform code. Without source control, chaos would reign. Here is what Priya actually does with Cloud Source Repositories.
First, Priya creates the central repository. She goes to the Google Cloud Console, navigates to 'Source Repositories', and clicks 'Add repository'. She chooses to create a new empty repository called 'retail-platform-backend'. She sets it as 'Private'. She then configures access: she creates a Google Group called 'dev-team@company.com' and gives it the 'Source Repository Writer' role. This means anyone in the dev team can push and pull code, but only Priya (with the 'Source Repos Administrator' role) can delete the repository or change its settings.
Next, the development workflow begins. A developer named Sam wants to add a new 'faster checkout' feature. Sam does not touch the 'main' branch directly. Instead, he creates a new branch from the latest code: 'feature/faster-checkout'. He codes for three days, committing his changes with messages like 'Added express payment API call' and 'Fixed validation error on card number'. Each commit is a checkpoint. If Sam introduces a bug, he can easily revert that single commit without losing the other good code.
When Sam finishes, he opens a 'pull request' (PR) against the 'main' branch on Cloud Source Repositories. This is a request to merge his branch into the main codebase. The PR triggers a webhook to Cloud Build, which automatically runs unit tests and a security scan on Sam's code. If the tests pass and another developer approves the code review, Priya (or Sam) clicks 'Merge'. The system automatically records the merge and deletes the feature branch.
Priya also uses triggers. She sets up a Cloud Build trigger that watches the 'main' branch. Every time a merge happens to 'main', the trigger automatically builds a new container image, runs integration tests, and if tests pass, deploys that image to a staging environment. This is the 'continuous integration' part of DevOps.
One day, a critical bug appears in production where a customer's discount coupon is not being applied. Priya can trace the exact commit that introduced the bug by using the 'git bisect' command or, more commonly, by looking at the repository's history and seeing which commit changed the coupon calculation logic. She then creates a new branch from the commit just before the bug, applies the hotfix, merges it to main, and deploys the fix – all within 30 minutes. Without source control, she would have a stressful scramble through dozens of untracked file versions.
Lastly, Priya uses mirroring to keep a secondary copy of the repository in another Google Cloud region for disaster recovery, but the primary use is this daily development loop of branch, commit, review, merge, and deploy.
The Google Professional Cloud DevOps Engineer exam tests your understanding of how source control fits into the broader DevOps pipeline. You will not be asked to write Git commands from memory. Instead, the exam tests concepts and integration points.
Here are the exact concepts they love to test:
Integration with Cloud Build: You must understand that Cloud Source Repositories can trigger Cloud Build builds automatically. A typical question describes a scenario with code in CSR and asks what service to use for automated testing/linting. The answer is Cloud Build, triggered by a push to a specific branch. Traps often involve suggesting Jenkins or a cron job instead of the native Google Cloud service.
IAM permissions for repositories: Questions will present a scenario where a developer cannot push code to a repository. The correct answer involves checking IAM roles (specifically roles/source.writer or roles/source.editor). The trap is focusing on service accounts or network settings when the problem is simply missing IAM permissions.
Mirroring from GitHub/Bitbucket: The exam expects you to know you can mirror an existing Git repository (e.g., from GitHub) into Cloud Source Repositories. A question might ask how to set up a connection to an external Git repository. The correct answer is configuring a mirror, not creating a new repository and manually importing files.
Branch protection rules: You need to know you can protect branches (e.g., 'main') by requiring pull requests, requiring approvals, and preventing direct pushes. The exam might describe a scenario where a critical bug was directly pushed to main. The solution is enabling branch protection rules that disallow direct pushes and require code reviews.
Tags and versions: The exam may ask about how to mark a specific commit for a release (e.g., v1.0, v2.0). The correct answer is using Git tags within Cloud Source Repositories. Tags are lightweight pointers to specific commits.
Differences from other services: They will test why you would use Cloud Source Repositories versus Cloud Storage or a simple zip file. The key distinguishing features: version history, branching, change tracking, and team collaboration.
Common trap patterns:
Trap: Suggesting Cloud Functions or Cloud Run as a trigger for source control events. Truth: Cloud Build is the correct trigger service.
Trap: Confusing the concept of a 'pull request' with a 'merge commit'. The exam may ask you to identify when code review happens – it happens during the pull request phase, not after the merge.
Trap: Forgetting that Cloud Source Repositories is a code host – it does not build or deploy code. It only stores and manages versions. Build and deploy are separate services (Cloud Build, Cloud Deploy).
Trap: Assuming you need to set up a VPN or special network to access CSR. In most simple scenarios, the default internet-facing access with correct IAM is sufficient.
Cloud Source Repositories hosts Git repositories on Google Cloud, giving you full commit history, branching, and rollback capability.
IAM roles, not passwords, control who can read and write to a repository in Cloud Source Repositories.
A Cloud Build trigger can automatically run tests when you push code to a specific branch in CSR.
Branch protection rules prevent direct pushes to critical branches like 'main', enforcing code review and approval workflows.
You can mirror existing GitHub or Bitbucket repositories into Cloud Source Repositories without losing their historical commits.
Source control is the first step in the continuous integration pipeline – it feeds code into automated build and test systems.
These come up on the exam all the time. Here's how to tell them apart.
Cloud Source Repositories
Tracks every commit with full version history and branching
Designed for collaborative code development with pull requests
Integrates natively with Cloud Build for CI/CD triggers
Cloud Storage
Stores objects with no version history by default (object versioning optional)
Designed for media, backups, and static file storage
No built-in trigger mechanism for CI/CD pipelines
Git (the tool)
Software installed locally to manage versions on your machine
Requires manual setup for remote hosts and authentication
Provides commands like commit, branch, merge that are universal
Cloud Source Repositories (the service)
Cloud-hosted Git repository with IAM-based access control
Automated backups, high availability, and no server management
Adds Google Cloud-specific features like Cloud Build integration
Direct Push to Main Branch
Changes go live immediately without review
High risk of introducing bugs or breaking builds
Used for simple projects or emergency hotfixes (discouraged)
Pull Request with Branch Protection
Requires code review and approval before merging
Ensures automated tests pass before integration
Industry best practice for team collaboration
Cloud Source Repositories
Native integration with Google Cloud services (Cloud Build, Cloud IAM)
Hosted within your GCP project with consistent billing
No issue tracking or community features out of the box
GitHub
Broader ecosystem with issues, actions, and marketplace
Independent platform with its own authentication (not IAM)
Third-party CI/CD connectors require custom configuration
Feature Branch Workflow
Creates a single branch per feature directly from main
Simpler for small teams and services with continuous deployment
Minimal branches: main + feature branches only
GitFlow Workflow
Uses develop branch, release branches, and hotfix branches
Better for scheduled releases with multiple versions in support
More complex overhead for branch management
Mistake
Cloud Source Repositories is the same as Cloud Storage – they both store files.
Correct
Cloud Storage stores files as objects in buckets with metadata but no version history or branching. Cloud Source Repositories stores code with full Git history, branching, merging, and team collaboration features.
Both services store data in Google Cloud, and the word 'repository' sounds similar to 'storage bucket'. Beginners conflate storage with version control.
Mistake
If I push code to Cloud Source Repositories, it automatically deploys to production.
Correct
Pushing code only uploads it to the repository. To trigger a build or deployment, you must explicitly configure a Cloud Build trigger or a Cloud Deploy pipeline that watches the repository for new commits.
People assume 'cloud' means everything happens automatically. In reality, source control is just the input; separate services must be configured to read from it.
Mistake
You cannot use Cloud Source Repositories unless you only use Google Cloud services.
Correct
Cloud Source Repositories can mirror repositories from GitHub, Bitbucket, or GitLab. You can use it as a centralised mirror even if your primary code host is elsewhere.
The branding 'Google Cloud' feels proprietary, leading beginners to believe it only works within the Google ecosystem.
Mistake
Git and Cloud Source Repositories are two different version control systems.
Correct
Cloud Source Repositories is a hosting service for Git repositories. Git is the underlying version control engine; CSR provides the cloud hosting, authentication, and integration features on top of Git.
Beginners see the product name and think it is a standalone system, not realising it is based on the standard Git protocol.
Mistake
Cloud Source Repositories does not support binary files like images.
Correct
CSR can host any type of file Git can handle, including binary files (images, PDFs, compiled binaries). However, Git is less efficient with large binary files than plain text, so it is not optimal for large media assets.
People associate source control with code (text files) and forget that Git fundamentally stores any file type.
Mistake
You cannot delete a file from Cloud Source Repositories once it is committed.
Correct
You can delete a file by committing a new version where the file is removed. The old version remains in the history, but the current state no longer contains the file.
The concept of 'immutable history' confuses beginners into thinking content cannot be removed at all. History is immutable, but the working tree can change.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Git is the version control software that runs on your computer. Cloud Source Repositories is Google's cloud hosting service for Git repositories. You use Git commands to interact with your local files, and Cloud Source Repositories stores the central copy of the repository in the cloud.
Yes. You can create a repository in Cloud Source Repositories that is not tied to any workload. It functions as a standalone Git host. You can even mirror a repository from GitHub or Bitbucket.
Do not share your password. Instead, use Google Cloud IAM. Grant the user the 'Source Repository Writer' or 'Source Repository Reader' role. They authenticate using their own Google account or a service account.
The password is now in the Git history permanently unless you rewrite history (which is complicated). The safest approach is to rotate the password immediately and use a secrets manager (like Cloud Secret Manager) for future credentials.
You need Git installed on your local computer. You also need the Google Cloud SDK (`gcloud`) to clone the repository initially if you use the credential helper. Beyond that, standard Git commands work.
Yes, for most use cases. There is no cost for the repository itself. You only pay for storage above a certain limit (currently 50 GB per project is free) and for network egress. Build and deployment services (Cloud Build, Cloud Run) have their own pricing.
You've finished Source Control Management and Cloud Source Repositories. Continue through the PCDOE study guide to build a complete picture of the exam.
Done with this chapter?