Configure and manage repositories

Wingtip Toys has a 60 GB monorepo named wingtip-toys/wingtip-mono on GitHub Enterprise Cloud with 15 years of history and more than 200,000 files. Developers on the web team work only in src/web and shared/ui, but they regularly run git log and git blame across the full commit history. Clone and checkout times must drop significantly without losing access to the full history.

Which two actions should the web team perform? Each correct answer presents part of the solution.

1. AClone with git clone --filter=blob:none to create a blobless partial cloneA blobless partial clone downloads all commits and trees but fetches file contents on demand, so the full history stays available for git log while the initial download shrinks.
2. BClone with git clone --depth 1A shallow clone truncates history to the latest commit, which breaks the requirement to run git log and git blame across the full history.
3. CRun git sparse-checkout set --cone src/web shared/uiCone-mode sparse checkout limits the working tree to the listed directories, so checkout and status operate on a fraction of the 200,000 files.
4. DRun git lfs migrate import --everything --include="*.js"LFS migration rewrites history for large binary files; moving source code into LFS does not reduce the working tree and makes diffs and blame on those files impractical.
5. ESplit src/web into a separate repository and add it back to wingtip-mono as a submoduleSplitting the repository is a disruptive restructuring that changes the workflow for every team and does not by itself shorten clone time for the web team.

Coho Winery has a GitHub organization with a repository named cellar-app. A project coordinator needs to label, assign, close, and reopen issues and pull requests and mark duplicates, but must not be able to push code to any branch. Least privilege is required.

Which repository role should you assign to the project coordinator?

1. AReadRead allows viewing and commenting but not applying labels, assigning, or closing other people's issues and pull requests.
2. BTriageTriage lets a user manage issues and pull requests, including labels, assignees, and closing or reopening, without any write access to code.
3. CWriteWrite includes pushing to branches, which exceeds what the coordinator needs and violates least privilege.
4. DMaintainMaintain adds code push rights and some repository settings management, which is far beyond the requirement.

Fourth Coffee maintains a .NET library named FourthCoffee.Telemetry in its own Azure Repos repository. Six application repositories consume the library, and each application team must be able to choose when to upgrade to a new library version, roll back to a previous version, and see which version they are on from their project file. Builds of the applications must not need access to the library's source code.

How should you share the library across the repositories?

1. AAdd the library repository as a Git submodule in each application repositoryA submodule pins a commit SHA rather than a semantic version, requires every build to fetch the library source, and adds submodule commands to every developer's workflow.
2. BUse git subtree to copy the library source into each application repositorySubtree copies the full library source into each repository, so builds still compile the source and version selection becomes a merge exercise rather than a reference change.
3. CMerge all six application repositories and the library into a single monorepoA monorepo forces every application onto the same library version at all times, which removes each team's ability to upgrade on its own schedule.
4. DBuild the library in a pipeline that publishes semantically versioned NuGet packages to an Azure Artifacts feed, and have each application reference a specific package versionPackage feeds deliver compiled, versioned artifacts, so each team pins, upgrades, or rolls back by changing the PackageReference version, and no source access is needed at build time.

Margie's Travel releases version 3.2.0 of the Azure Repos repository itinerary-svc from commit with the placeholder SHA 5be09a4. Compliance requires every release marker to record who created it, when it was created, and a release message, and the marker must be visible to everyone who fetches from the server. The release pipeline triggers on tags that match v*.

Which commands should you run?

1. Agit tag v3.2.0 5be09a4 followed by git push origin v3.2.0This creates a lightweight tag, which is only a pointer to the commit and stores no tagger, date, or message, so it fails the compliance requirement.
2. Bgit tag -a v3.2.0 5be09a4 -m "Release 3.2.0" followed by git pushThe annotated tag is correct, but a plain git push does not push tags by default, so the tag stays local and the pipeline never sees it.
3. Cgit branch release/v3.2.0 5be09a4 followed by git push origin release/v3.2.0A branch is a movable reference that records no tagger or message and does not match the v* tag trigger.
4. Dgit tag -a v3.2.0 5be09a4 -m "Release 3.2.0" followed by git push origin v3.2.0An annotated tag is a full Git object that stores the tagger name, email, date, and message, and pushing the tag explicitly publishes it to the server where the v* trigger fires.