Task 2.2: Configure and manage repositories

• AUse shallow fetch on developer clones and keep the textures in Git

  Incorrect

  Shallow history helps clones, but every texture version still sits in the repository and grows it.

• BStore the textures in a pipeline artifact that developers download

  Incorrect

  Developers would leave Git workflows for every texture change.

• CTurn on the Maximum file size repository policy at 1 MB

  Incorrect

  That blocks the textures without giving them anywhere to live.

• DTrack the texture file types with Git LFS, and set lfs to true on the pipeline's checkout step

  Correct

  LFS keeps large files on the server and downloads only the versions checked out; checkout needs lfs true to fetch them.

Git LFS stores large files on the server and replaces them in the repository with pointers, so clones download only the versions they need while Git commands work as usual. A pipeline's checkout step downloads LFS files only when lfs is set to true.

• ARevoke the storage account key and generate a new one for the applications that use it

  Correct

  Anyone who pulled has the key, so it must be invalidated and replaced.

• BRevert the commit with git revert so the key disappears from the latest version

  Incorrect

  A revert adds a new commit and leaves the key in history.

• CRewrite history with git filter-repo or BFG to remove the key, and force push the rewritten branches

  Correct

  These tools remove sensitive text from history, which then has to be force-pushed.

• DDelete the repository and import a copy of it into a new project

  Incorrect

  An imported copy keeps the same history, and clones still hold the key.

• EAdd the file that held the key to .gitignore

  Incorrect

  Ignoring a file affects future commits only; history keeps the key.

To remediate an exposed secret, invalidate the credential and create a new one. Tools such as git filter-repo and BFG Repo-Cleaner rewrite history to remove sensitive files or text, which requires a force push; a revert only adds a new commit.

• AGit submodules for every top-level folder of the repository

  Incorrect

  Splitting into submodules changes the repository structure the team wants to keep.

• BGit LFS for every source file

  Incorrect

  LFS is for large binary files, not ordinary source code.

• CScalar to clone and maintain the repository

  Correct

  Scalar sets up partial clone, sparse-checkout and background prefetch and maintenance.

• DA larger agent VM for developers' builds

  Incorrect

  Bigger build agents don't change clone and fetch on developer machines.

Scalar is a tool from Microsoft that helps very large repositories work faster by turning on Git features such as partial clone, background prefetch and sparse-checkout, plus background maintenance.

• AA pre-commit hook in each developer's clone that checks file sizes

  Incorrect

  Client-side hooks can be skipped and aren't enforced on the server.

• BA build validation policy that fails when the build output is large

  Incorrect

  That checks pull requests, not direct pushes, and after the fact.

• CThe Case enforcement repository policy

  Incorrect

  That policy isn't about file size.

• DThe Maximum file size repository policy set to 50 MB

  Correct

  The policy blocks pushes that add or update files larger than the limit, on the server.

The Maximum file size repository policy blocks pushes that contain new or updated files over the limit, enforced on the server for every client. Large files belong in Git LFS.

• Agit stash pop

  Incorrect

  The stash holds uncommitted local work.

• Bgit blame <file>

  Incorrect

  Blame shows line authorship, not a restore.

• Cgit fetch --all

  Incorrect

  Fetching gets remote updates; it doesn't restore the file.

• Dgit checkout <commit>^ -- <file>, then commit it

  Correct

  Checking out the file from the parent of the deleting commit restores it.

git checkout <commit> <file> restores a specific file from a previous commit; use the parent of the commit that deleted it, then commit the restored file.

• AReserved names

  Incorrect

  That blocks platform-reserved names and characters.

• BMaximum path length

  Incorrect

  That limits path length.

• CCommit author email validation

  Incorrect

  It doesn't look at file or folder names.

• DCase enforcement

  Correct

  It switches the server to case-insensitive behavior for paths and blocks case-only conflicts.

The Case enforcement policy switches the server from case-sensitive mode, where File.txt and file.txt are distinct, to a Windows-friendly mode that blocks case-only conflicts; it's recommended when most contributors use Windows or macOS.

• AYes, by searching for the deleted branch in the web portal and restoring it

  Correct

  You can restore a deleted branch from the Branches page at any time.

• BNo, deleted branches are purged after 30 days

  Incorrect

  Deleted branches have no retention limit.

• COnly if someone still has a local clone with the branch in it

  Incorrect

  The server keeps deleted branches restorable without a local copy.

• DOnly with a support request to Microsoft

  Incorrect

  Users can restore branches themselves.

There's no retention policy on deleted branches in Azure Repos: you can find a deleted branch from the Branches view in the web portal and restore it at any time, regardless of when it was deleted.

• AThe original's branch policies

  Incorrect

  Forking doesn't transfer policies.

• BThe original's build pipelines

  Incorrect

  Pipelines aren't transferred.

• CThe original's permissions

  Incorrect

  Permissions aren't transferred.

• DThe source code

  Correct

  A fork shares the original repository's source code.

A fork is a new repository that shares the source code of the original. The forking process doesn't transfer permissions, policies or build pipelines.