リポジトリ

リポジトリはコードを保存し、変更を加える場所です。変更はバージョン管理で追跡されます。

各プロジェクトにはリポジトリが含まれています。

リポジトリの作成

リポジトリを作成するには、以下の方法があります：

リポジトリにファイルを追加

リポジトリにファイルを追加できます：

  • プロジェクトを作成するとき。
  • プロジェクト作成後：

リポジトリへの変更のコミット

リポジトリ内のブランチに変更をコミットできます。コマンドラインを使うと、プッシュする前に何度もコミットできます。

  • コミットメッセージコミットメッセージは、何がなぜ変更されたのかを示します。GitLabでは、コミットメッセージにキーワードを追加することで、以下のいずれかのアクションを実行できます：
    • GitLab CI/CDパイプラインをトリガーします：プロジェクトがGitLab CI/CD で設定されている場合、コミットごとではなくプッシュごとにパイプラインをトリガーします。
    • パイプラインをスキップします：GitLab CI/CDにパイプラインをスキップさせるには、コミットメッセージにci skip キーワードを追加します。
    • イシューとマージリクエストをクロスリンクします：ワークフローの関連部分を追跡するためにクロスリンクを使いましょう。コミットメッセージでイシューやマージリクエストに言及すると、それぞれのスレッドに表示されます。
  • コミットのチェリーピック：GitLabでは、UIからコミットをcherry-pickすることができます。
  • コミットの差し戻し：UIから選択したブランチにコミットを戻すことができます。
  • コミットに署名GPG を使ってコミットに署名します。

リポジトリのクローン

コマンドラインを使ってリポジトリをクローンできます。

あるいは、コードエディターに直接クローンすることもできます。

クローンを作成し、Apple Xcodeで開きます。

.xcodeproj または.xcworkspace ディレクトリを含むプロジェクトは、MacOS の Xcode にクローンできます。

  1. GitLab UIから、プロジェクトの概要ページに移動します。
  2. クローンを選択します。
  3. Xcodeを選択します。

プロジェクトがコンピュータにクローンされ、XCodeを開くように促されます。

クローンを作成し、Visual Studio Codeで開きます。

GitLab 13.10で導入されました。

全てのプロジェクトはGitLabユーザーインターフェースからVisual Studio Codeにクローンできますが、GitLab Workflow VS CodeエクステンションをインストールしてVisual Studio Codeからクローンすることもできます：

  • GitLab インターフェースから：
    1. プロジェクトの概要ページにアクセスします。
    2. クローンを選択します。
    3. IDE で開く] で、[Visual Studio Code(SSH)] または [Visual Studio Code(HTTPS)] を選択します。

    4. プロジェクトをクローンするフォルダを選択します。

      Visual Studio Codeがプロジェクトをクローンすると、そのフォルダが開きます。

  • 拡張機能をインストールした Visual Studio Code から、拡張機能のGit: Clone コマンド を使用します。

クローンを作成し、IntelliJ IDEAで開きます。

全てのプロジェクトはGitLabユーザーインターフェースからIntelliJ IDEAにクローンすることができます。

前提条件：

そのためには

  1. プロジェクトの概要ページにアクセスします。
  2. クローンを選択します。
  3. Open in your IDE] で、[IntelliJ IDEA(SSH)] または [IntelliJ IDEA(HTTPS)] を選択します。

リポジトリにあるコードをダウンロードします。

Git LFS blobを含めるサポートがGitLab 13.5で導入されました。

リポジトリに保存されているソースコードをダウンロードできます。

  1. ファイルリストの上にあるダウンロードアイコン（{download}）を選択してください。

  2. オプションからダウンロードしたいファイルを選択します。

    • ソースコード：現在表示しているブランチのソースコードをダウンロードします。利用可能な拡張子：zip tar,tar.gz, andtar.bz2.
    • ディレクトリ：特定のディレクトリをダウンロードします。サブディレクトリを表示するときにのみ表示されます。利用可能な拡張子：zip tar,tar.gz, およびtar.bz2。
    • アーティファクト：最新の CI ジョブからアーティファクトをダウンロードします。

リポジトリ自体に変更がなくても、生成されたアーカイブのチェックサムが変わってしまうことがあります。例えば、GitやGitLabが使っているサードパーティのライブラリが変更された場合などに起こります。

リポジトリ言語

各リポジトリのデフォルトブランチでは、GitLab はどのプログラミング言語を使用するかを決定します。この情報はプロジェクトの概要ページに表示されます。

Repository Languages bar

新しいファイルが追加されると、この情報が更新されるのに5分かかることがあります。

リポジトリの言語を追加

すべてのファイルが検出され、プロジェクト概要ページに表示されるわけではありません。ドキュメント、ベンダーコード、ほとんどのマークアップ言語は除外されます。

デフォルト設定を上書きすることで、この動作を変更できます。

  1. リポジトリのルートディレクトリに、.gitattributes.

  2. GitLab にこのタイプのファイルをインクルードするように指示する行を追加します。たとえば、.proto ファイルを有効にするには、次のコードを追加します：

    *.proto linguist-detectable=true

サポートされているデータ型の一覧を見る

この機能はCPUを過剰に使用する可能性があります。詳細については、トラブルシューティングのセクションを参照してください。

サポートされるマークアップ言語

ファイルの拡張子が以下のいずれかである場合、GitLabはそのファイルのマークアップ言語の内容をUIでレンダリングします。

マークアップ言語拡張機能
プレーンテキストtxt
マークダウン mdown mkd,mkdn,md 、markdown
reStructuredTextrst
アスキードック adoc,ad 、asciidoc
テキスタイルtextile
Rdocrdoc
オルグモードorg
クレオールcreole
メディアウィキ wiki,mediawiki

READMEとインデックスファイル

リポジトリにREADME やindex ファイルがあると、GitLab はその内容をレンダリングします。これらのファイルはプレーンテキストか、サポートされているマークアップ言語の拡張子を持っています。

  • README とindex の両方のファイルが存在する場合は、常にREADME が優先されます。
  • 複数のファイルが同じ名前で異なる拡張子を持つ場合、ファイルはアルファベット順に並べられます。拡張子のないファイルは最後に並びます。たとえば、README.adoc はREADME.md よりも優先され、README.rst はREADME よりも優先されます。

OpenAPI ビューア

GitLab 12.6 で導入されました。

GitLabはOpenAPI仕様ファイルをレンダリングすることができます。ファイル名にはopenapi またはswagger を含める必要があり、拡張子にはyaml,yml, またはjsonを指定する必要があります。 以下の例はすべて正しいです：

  • openapi.yml
  • openapi.yaml
  • openapi.json
  • swagger.yml
  • swagger.yaml
  • swagger.json
  • gitlab_swagger.yml
  • openapi_gitlab.yml
  • OpenAPI.YML
  • openapi.Yaml
  • openapi.JSON
  • openapi.gitlab.yml
  • gitlab.openapi.yml

OpenAPIファイルをレンダリングするには

  1. リポジトリの OpenAPI ファイルに移動します。
  2. Display sourceとEditボタンの間で、Display OpenAPI を選択します。OpenAPI ファイルが見つかると、Display rendered fileボタンに置き換わります。
  3. オペレーションリストにoperationId を表示するには、クエリ文字列にdisplayOperationId=true を追加します。
note
クエリ文字列内にdisplayOperationId が存在し、_任意の_値を持つ場合、true と評価されます。この動作はSwaggerのデフォルトの動作と一致します。

リポジトリのサイズ

GitLab 15.3で導入された機能フラグgitaly_revlist_for_repo_size とgitaly_catfile_repo_size は、リポジトリのサイズ計算の代替となります。

フラグ: セルフマネジメントのGitLabでは、デフォルトでGitLabはリポジトリのサイズを決定するためにdu -sk コマンドを使用します。GitLab はgit-rev-list (機能フラグgitaly_revlist_for_repo_size で有効) またはgit-cat-file (機能フラグgitaly_catfile_repo_sizeで有効) を代わりに使うことができます。異なる計算方法を切り替えるには、管理者がこれらの機能フラグを有効または無効にします。

プロジェクト概要ページには、リポジトリ内のすべてのファイルのサイズが表示されます。サイズは最大で 15 分ごとに更新されます。ファイルサイズには、リポジトリファイル、アーティファクト、LFS が含まれます。

圧縮、ハウスキーピング、その他の要因により、サイズはインスタンスごとに若干異なることがあります。

管理者はリポジトリサイズの上限を設定できます。GitLabはGitLab.comのサイズ制限を設定します。

リポジトリ投稿者の統計

コントリビューター統計では、プロジェクトメンバーによるコミットの一覧とグラフを見ることができます。

リポジトリ履歴グラフ

リポジトリグラフは、ブランチやマージなどのリポジトリネットワークの履歴を視覚的に表示します。このグラフは、リポジトリで使われている Git のフロー戦略を視覚化するのに役立ちます。

プロジェクトのCode > Repository グラフに移動します。

repository Git flow

リポジトリパスが変更されるとどうなりますか？

リポジトリのパスが変更されると、GitLab は古い場所から新しい場所への移行をリダイレクトで処理します。

ユーザーの名前を変更したり、グループのパスを変更したり、リポジトリの名前を変更したりしたとき：

  • 名前空間とその下にあるすべてのもの（プロジェクトなど）の URL は新しい URL にリダイレクトされます。
  • 名前空間配下のプロジェクトの Git リモート URL は、新しいリモート URL にリダイレクトされます。場所が変わったリポジトリにプッシュしたりプルしたりすると、リモートを更新するよう警告メッセージが表示されます。自動化スクリプトや Git クライアントは、名前の変更後も引き続き動作します。
  • リダイレクトは、元のパスが他のグループ、ユーザー、プロジェクトによって主張されていない限り利用できます。
caution
CI/CDincludes キーワードはプロジェクトのリダイレクトに従うことはできません。includes を使用してリネームまたは移動されたプロジェクトから設定を取得するように設定すると、パイプラインが構文エラーで失敗します。

トラブルシューティング

リポジトリ言語：CPUの過剰使用

リポジトリのファイルにどの言語が含まれているかを判断するために、GitLabはRuby gemを使っています。gem がファイルを解析してどのタイプかを判断するとき、その処理は過剰な CPU を使うことがあります。このgemには、どのファイル拡張子を解析しなければならないかを定義するヒューリスティック設定ファイルがコンテナとして含まれています。

拡張子が.txt のファイルや、gemで定義されていない拡張子のXMLファイルは、過剰なCPUを消費する可能性があります。

回避策は、特定のファイル拡張子に割り当てる言語を指定することです。同じ方法で、誤認識されたファイルタイプも修正できるはずです。

  1. 指定する言語を特定します。gemには、既知のデータ型用の設定ファイルが含まれています。例えばテキストファイル用のエントリを追加するには

    Text:
  type: prose
  wrap: true
  aliases:
  - fundamental
  - plain text
  extensions:
  - ".txt"

  2. リポジトリのルートに.gitattributes を追加または変更します：

    *.txt linguist-language=Text

*.txt ファイルはヒューリスティックス・ファイルにエントリがあります。この例では、これらのファイルの解析を防ぎます。

リポジトリへのプッシュの検索シーケンス

コミットが「行方不明」になったような場合は、リポジトリへの一連のプッシュを検索してみましょう。この StackOverflow の記事では、強制プッシュを行わずにこの状態になる方法を説明しています。別の原因としては、git reset のオペレーションで HEAD ref を変更するサーバーフックの設定ミスが考えられます。

以下のサンプルコードのターゲットブランチの出力を見ると、ステップを踏んでいくにつれて from/to のコミットが不連続になっているのがわかります。新しいプッシュのcommit_from は、前のプッシュのcommit_to と等しくなっているはずです。この順序が途切れているということは、リポジトリの履歴からひとつ以上のコミットが「失われた」ことを示しています。

Rails コンソールを使って、次の例では直近の 100 プッシュをチェックし、commit_from とcommit_to のエントリを表示します：

p = Project.find_by_full_path('project/path')
p.events.pushed_action.last(100).each do |e|
  puts "%-20.20s %8s...%8s (%s)", e.push_event_payload[:ref], e.push_event_payload[:commit_from], e.push_event_payload[:commit_to], e.author.try(:username)
end ; nil

4行目でシーケンスの中断を示す出力例：

master f21b07713251e04575908149bdc8ac1f105aabc3...6bc56c1f46244792222f6c85b11606933af171de root
master 6bc56c1f46244792222f6c85b11606933af171de...132da6064f5d3453d445fd7cb452b148705bdc1b root
master 132da6064f5d3453d445fd7cb452b148705bdc1b...a62e1e693150a2e46ace0ce696cd4a52856dfa65 root
master 58b07b719a4b0039fec810efa52f479ba1b84756...f05321a5b5728bd8a89b7bf530aa44043c951dce root
master f05321a5b5728bd8a89b7bf530aa44043c951dce...7d02e575fd790e76a3284ee435368279a5eb3773 root