そもそもリポジトリ？

"Repos"は、ソースコードを中心とした生産物を履歴などを意識しながら保管できるサービスです。
このような仕組みを一般的に"リポジトリ"と呼びます。
過去、様々なリポジトリが存在していました（もちろん今も存在しています）。
たとえば、

VSS
CVS
Subversion

など、聞いたことや使ったことがあるのではないかと思います。
もしリポジトリを使っていない場合、開発を進めるたびに新たなフォルダを作ってコピーして改修するというような作業に明け暮れることとなります。
これ自体も問題なのですが、複数名で複数の課題に立ち向かっていく際、誰がいつどこをどのように修正したのか、それをどうレビューし承認し結合するのかということを制御するのが非常に困難になります。
このような課題を解決すべく、リポジトリはあります。

リポジトリは、みんなが実施した作業を無駄なくバリューに変換するためのものです。

"Repos"は２種類のリポジトリを提供している

"Repos"では、TFVCベースとGitベースという２種類のリポジトリを提供しており、プロジェクトごとにどちらを採用するかを選択することができます。
端的に書くと、

TFVC：中央集権的なリポジトリ、中央に１つリポジトリを配置して、全員がそこに対して生産物を登録していく。
Git：地方分権的なリポジトリ、ある程度自由に中央のリポジトリをコピーしてきて、そこに対して生産物を登録、その後任意のタイミングで中央に申請して取り込んでもらう。

というような差がありますが、世の流れもありますし差を追求するのはやめましょう。

これからやるならGitベース１択

もちろん個人の主観ではありますが、これからAzure DevOpsを使うのであればGitを採用してください。
この先の説明も、Gitのみを対象としています。

"Repos"のメニュー

かなりザックリした説明になります。
そもそものGitに関する簡単な説明は、このあと書きたいと思います。

Files : ブランチに登録されているファイル一覧を表示します。
Commits : ブランチへのコミットの変遷を表示します。
Pushes : ブランチに対してプッシュされた情報を表示します。
Branches : ブランチの一覧を表示します。
Tags : タグ付け機能がありますので、それを利用します。
Pull requests : "ブランチで作ったものを承認して取り込んでほしい"という要求を出したり承認したりします。

Gitの簡単な説明

冒頭で"Gitは地方分権的なリポジトリ"と書きました。ここでは、Gitと、中央集権的なリポジトリに触れて、メニューの理解を進めたいと思います。
簡単に書きすぎているが故の説明不足など、ご容赦ねがいます。

中央集権的なリポジトリはファイルをコピペする

まずはGitとは異なるポリシーを持ったリポジトリをおさらいします。
たとえばVSSのようなリポジトリを使った開発を行う場合、リポジトリからフォルダやファイル構成を自分のPCにダウンロードしてきます。

取得するのは、主に最新のフォルダやファイルの構成です。
ファイルを更新したのち、リポジトリにアップロードを行います。

アップロードするのは、フォルダ構成やファイルそのものです。
どんなつもりでアップロードしたのかをコメントとして記述しますが、このコメントや履歴は中央にある１つのリポジトリで一括生成、管理します。
とてもシンプルでわかりやすいのですが、いくつかの問題も発生します。（実際には各ソフトウェアで解決が行われており問題に直面することは少ないと思いますが、理論上は以下のとおりです。）

複数名で同じファイルを改修したい場合、ファイルの取り合いが発生する
複数の案件に対する改修を実施している場合、コミットタイミングがわからなくなる
上記２点を踏まえると、状況次第では改修の"待ち"が発生する

Gitはリポジトリそのものをコピペする

Gitでは、リポジトリそのものを自分のPCにクローン（ダウンロード）します。

作業は個人のPCの中にクローンされたリポジトリに対して実施します。
基本的には１案件に対する複数ファイルの改修を行い、ローカルのリポジトリに対してコミット（改修後のファイルの登録）を行います。
全ての改修が終わり、テストも完了した時点で、このローカルのリポジトリを元あった場所（たとえばAzure DevOpsのRepos）にプッシュ（アップロード）します。
リポジトリとしてクローンしてくることのメリットは、コミット時に顕著になります。

リポジトリには、最終的なファイルだけではなく、ローカルリポジトリを更新した履歴が入っています。ファイルと履歴を一式送り込むことができますので、受け入れる側は、改修の意図を理解しながら受け入れるか否かを判断できます。

実際にはどう扱うのか

先ほどの絵ではリポジトリは１つの大きな枠として表現しましたが、実際には１つではありません。
実際にはこのように扱います。

時間の流れを意識しながら、図の左側から右側へ向けて説明します。
はじめ、リポジトリは"master"という場所から始まります。
基本的な作業は

"master"から"branch"（改修用のコピー品）を作る
"branch"をローカルに"clone"（ダウンロード）する
改修しテスト、適宜"clone"したリポジトリに"commit"（登録）する
"clone"したリポジトリを"push"（アップロード）する
"Pull request"を発行しレビューと"merge"（ファイルと改修履歴の統合）を依頼する
"branch"を"master"にマージする

という工程で行われます。
案件Aは、この基本的な作業です。緑色がmaster branch、青色のブランチを作成してオレンジ色のcloneを実施、改修内容をpush(オレンジ)して、ブランチ（青）をmaster（緑）にマージしています。
案件Cは案件Bのマージ前に作業を開始しています。案件Cのマージ時には案件Bに伴う改修が入ったmasterと比較して、案件Cの変更をマージするか否か選択します。同じファイルを改修している際は"conflict(衝突)"をGit側で検知してくれますので、状態を確認し、案件Cの取り込み方を検討します。
案件Dと案件Eも同じ構図です。こちらは後から始まる案件Eを先にマージしていますが、すべての状態を履歴として管理していますので、問題があっても確認は容易です。
これらの状態の確認や承認を実施するために"Pull request"が存在します。
他にも多くの機能がありますが、主題ではありませんので割愛します。

まとめ

"Repos"についてメニューを確認しました。
"Repos"はリポジトリのことです。リポジトリを使えば、ファイルとその改修履歴を扱うことができます。
Gitは分散型のリポジトリです。最初から分散することを意識していますので、ファイルの取り合いやまわりの作業者との協調から解放されます。
その変わり、マージするときは内容の差異を正しく評価しなければなりません。Gitはそのことも容易に扱える仕組みになっています。
動画のようなもので無い限り、できるだけ開発中の資産はリポジトリに登録するようにしましょう。
設計書のようなドキュメントであってもリポジトリの利用をおすすめします。（設計書は無い方が良いですが、全部はなくせないと思いますので。）
また、リポジトリに入れたものは差分を確認できますので、差分を確認できるテキストベースの情報を生産するようにしましょう。

Azure DevOps Repos(リポ)の超概要＆Gitについて簡単に説明