Topic 1 Question 260
You are a developer at a large organization. Your team uses Git for source code management (SCM). You want to ensure that your team follows Google-recommended best practices to manage code to drive higher rates of software delivery. Which SCM process should your team use?
Each developer commits their code to the main branch before each product release, conducts testing, and rolls back if integration issues are detected.
Each group of developers copies the repository, commits their changes to their repository, and merges their code into the main repository before each product release.
Each developer creates a branch for their own work, commits their changes to their branch, and merges their code into the main branch daily.
Each group of developers creates a feature branch from the main branch for their work, commits their changes to their branch, and merges their code into the main branch after the change advisory board approves it.
ユーザの投票
コメント(3)
- 正解だと思う選択肢: D
You are a developer at a large organization
👍 1closer892023/04/25 - 正解だと思う選択肢: D
Use a centralized repository. A centralized repository is a single location where all of your team's code is stored. This makes it easy for everyone to access the latest code, and it also helps to prevent conflicts. Use branches. Branches are a way to create a separate version of the code for development purposes. This allows developers to work on new features or bug fixes without affecting the main branch of the code.
👍 1Writer2023/04/26 - 正解だと思う選択肢: B
B. Put all commits inside a single repo would place lots of burden on branching and commit history. This not only makes checkout slower but also hard to manage - think about a small-mid size team (10 developers) creating 200 commits per day, roughly equals to 156,000 for 3 months. The maintainers of a repo would have a hard time to chase down and merge 156,000 commits. Not to mention the repo permission management would be a nightmare if the repo extends to enterprise level (200 - 500 developers / SRE / qa / SA) .Forking repo as opt B would be a better choice. Each developer deals with his fork. PR merge and squash once ready. In fact, all famous OSS software, such as Kubernetes, Grafana, Prometheus, etc., use this approach.
👍 1zanhsieh2023/06/08
シャッフルモード