GitとCI/CDに関する知識ゼロのSEが、GitLabでhttpsでクローンとプッシュを試すだけの記事 (2023/07/05 更新)

2022/05/06　少しでも見やすく…と思い、ブログのスタイルを一部更新致しました。
2022/05/20　GitLabのデモ動画を作りました！このブログの末尾にリンクを張ったのでよろしければご視聴ください。
2023/07/05　GitLab.com Enterprise Edition 16.2.0-pre の画面に差し替えました。

皆様こんにちは。普段はセキュリティ商材を担当しているSEの小池と申します。

私の普段の業務はGitやCI/CDに無縁なのですが、会社から頂戴した「GitLabの技術ブログ書いておいて」というミッションを達成すべく、今回も頑張ってGitLabの技術をちまちま習得してまいります。

今回はシンプルに GitLabでhttpsを用いてクローンとプッシュを試すだけの話 です。
(SSHを用いる場合については前回のブログをご参照ください。)

本記事の対象の方
今回のブログのゴール
このブログをお読みいただくにあたっての事前ご連絡事項
最初に確認
パスワードの設定
アクセストークンの作成
Windowsユーザー且つGit知らない方向け～Gitのインストール～
httpsでクローンを試行する
httpsでmainブランチにpushを試行する
httpsで別名ブランチでpushを試行する
余談～SSL証明書に関連するメッセージ～
最後に

本記事の対象の方

こちらのブログでGitLabに空のプロジェクトを作成し、次のアクションを求めている方。
GitLabでリポジトリに対してhttpsでクローンorプッシュしようとしたけれど、できなくて困っている方。

今回のブログのゴール

このブログのゴールはこちらです！

今回のゴール

GitLabの任意のリポジトリに対して、httpsを用いてgit clone と git push ができるようになる。
mainブランチに対してpushを試行することで、Protected branchesの効果を確かめる。

このブログをお読みいただくにあたっての事前ご連絡事項

本記事はGitLabがどういった製品なのかの説明はしておりません。製品説明につきましては弊社の製品ページ (こちら) をご参照ください。
本記事はGitやCI/CDに関する知識ゼロのSEによるなんちゃって記事です。GitLabのディープな使用法についてはGitLabの公式オンラインドキュメント (こちら) をご参照ください。
本記事の操作説明と画面ショットはGitLabのローカライズを日本語にした状態で説明しております。それ以外の言語をご利用の方は適宜読み替えてください。
本記事は GitLab.com の Enterprise Edition 16.2.0-pre (Ultimate) における仕様をベースに記載しております。それ以外のエディションやバージョンではこの記事に記載の通りではない可能性がございます。

最初に確認

httpsによるクローンやプッシュを試行するには、パスワードかアクセストークンのどちらかが必要になります。

ですので、最初はパスワードが設定済かもしくはアクセストークンが既にあるかを確認します。

まずはクローンやプッシュを試行する予定のユーザーでにGitLabのGUIにサインインします。
そして、対象のプロジェクトのページに移動します。
画面上部に以下のメッセージが表示されているか否かを確認してください。

Your account is authenticated with SSO or SAML. To push and pull over HTTPS with Git using this account, you must set a password or set up a Personal Access Token to use instead of a password. For more information, see Clone with HTTPS.

上の画面のメッセージが表示されている場合、パスワードが未設定且つアクセストークンが未作成の可能性があります。
(SAML連携等を設定し、ユーザー作成を自動化している環境などでみられるメッセージです。)

httpsでクローンなどを実行する場合、少なくともどちらかが必要になります。
後続の手順パスワードの設定またはアクセストークンの作成をご参照いただき、設定をしてください。

上の画面のメッセージが表示されていない場合、既にパスワードが設定済、もしくはアクセストークンが作成済です。
このままクローンをお試しできるので httpsでクローンを試行するをご参照ください。

パスワードの設定

現状パスワードが未設定且つ httpsによるクローン等の認証でパスワードを使いたい場合は、パスワードを設定します。

クローンなどを試行したいユーザーでGitLabのGUIにサインインします。
画面右上のアイコンから [設定] をクリックします。

左のメニューで [パスワード] を開きます。
新しいパスワードを設定し、[パスワードを保存] をクリックします。

パスワードの設定は以上です。
続けてクローンを試行なさりたい場合は、 httpsでクローンを試行するをご参照ください。

アクセストークンの作成

アクセストークンを未作成、且つhttpsによるクローン等の認証でアクセストークンを使いたい場合は、アクセストークンを作成します。

クローンなどを試行したいユーザーでGitLabのGUIにサインインします。
画面右上のアイコンから [設定] をクリックします。

左のメニューで [アクセストークン] をクリックします。

トークン名に任意の文字列を設定します。
有効期限は任意に設定してください。設定なしの場合は無期限になります。

スコープを選択します。
今回のhttpsを使ったクローンやプッシュだけなら write_repository だけでOKですが、もしほかのスコープが必要あればチェックを入れてください。
完了したら [Create 個人のアクセストークン] をクリックします。

アクセストークンが作成されたら必ずをコピーしておいてください。
画面に「これは必ず保存してください。二度とアクセスできません。」とあるとおり、ここでコピーしないで画面遷移すると、再度アクセストークンを作る必要があります…。

アクセストークンの作成は以上です。
続けてクローンを試行なさりたい場合は、 httpsでクローンを試行するをご参照ください。

Windowsユーザー且つGit知らない方向け～Gitのインストール～

クローンとかを試す前に…、もしWindowsユーザーでクライアントPCにGitのツールをインストールしていない方は、Gitをインストールしておいてください。
インストールについてはこちらのブログで言及しておりますので、よろしければご参照ください。
blogs.networld.co.jp

httpsでクローンを試行する

既存プロジェクトのリポジトリをローカルにクローンしてみます。

git cloneを実行したいユーザーでGitLabにサインインします。
サインイン後、対象のプロジェクトに移動し、[クローン]>[HTTPSでクローン] のURLをコピーします。

普段の業務でお使いのツール類を使って、クローンが成功するかご確認ください。
git cloneコマンドについてよくわからない方は、後続のコマンド例をご参照いただき、クローンをご試行ください。

カレントディレクトリを任意の場所にしたあと、以下のコマンドを実行します。

$ git clone <先ほどコピーしたURL>

GUIがあるOSの場合、上のコマンドを実行すると下図の画面が表示されるケースがあります。
この場合は、ブラウザ経由でのサインイン、アクセストークンを使ったサインイン、ユーザー名とパスワードを使ったサインインから選択できます。
任意のサインイン方法を選択して、画面指示に従ってサインインを進めてください。

上の図のような画面が表示されなかった場合はユーザー名を求められるので、GitLabのGUIにサインインする時のユーザー名をそのまま入力してください。
(サインイン時にメールアドレスを使っている場合は、メールアドレスになります。)

$ git clone <先ほどコピーしたURL>
Cloning into '<クローンしたいプロジェクト名>'...
Username for 'https://<GitLabインスタンスのURL>': <GitLabのユーザー名 もしくは E-mailアドレス>

続けてパスワードを求められます。
ここで、前の手順で設定した パスワード もしくは アクセストークン をポチポチ入力します。

$ git clone <先ほどコピーしたURL>
Cloning into '<クローンしたいプロジェクト名>'...
Username for 'https://<GitLabインスタンスのURL>': <GitLabのユーザー名 もしくは E-mailアドレス>
Password for 'https://<GitLabのユーザー名 もしくは E-mailアドレス>@<GitLabインスタンスのURL>':<パスワード もしくは アクセストークン>

正常にクローンが成功すると以下のような出力になります。

$ git clone <先ほどコピーしたURL>
Cloning into '<クローンしたいプロジェクト名>'...
Username for 'https://<GitLabインスタンスのURL>': <GitLabのユーザー名 もしくは E-mailアドレス>
Password for 'https://<GitLabのユーザー名 もしくは E-mailアドレス>@<GitLabインスタンスのURL>':<パスワード もしくは アクセストークン>
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.

カレントディレクトリにリポジトリがクローンされていることを確認してください。

httpsを用いたクローンの試行は以上です。

httpsでmainブランチにpushを試行する

ここでは、mainブランチに対してプッシュを試みます。

なお、ロールとプッシュ先ブランチの組み合わせによっては、プッシュができないケースがあります。
これは、GitLab14.0以降は "main"、それより前では "master" がデフォルトブランチ且つ Protected branchesであり、保護されているからです。

具体的には、対象プロジェクトに対して "Maintainer" か "Owner" の権限を持っているユーザー以外は通常 main ブランチにはプッシュできません。

Protected branchesとデフォルトブランチについては、こちらのブログで概要を述べておりますので、よろしければご参照ください。
blogs.networld.co.jp

したがってこの章は、"Maintainer" か "Owner" でmainブランチ (Protected branches) にプッシュできることを確認する、もしくは、他の権限のユーザーでmainブランチ (Protected branches) にプッシュできないことを確認する、といった内容になります。

Gitの基本的な操作が分かっていらっしゃる方は、ご自身の手順やツールでお試しください。
プッシュの仕方がよくわからない方のみ、後続のコマンド例をご参照いただき、mainブランチへのpushをご試行いただければと存じます。

先ほどクローンしたリポジトリに移動し、ブランチはmainのまま適当なファイルを追加します。
ここでは例として sample.md を追加します。

$ cd <先ほどcloneしたリポジトリ名>
$ touch sample.md

コミットします。

$ git add .
$ git commit -m "<コメントを任意に入力>"

mainブランチへのpushを試行します。

$ git push origin main

ユーザー情報を求められた場合は入力してください。
"Maintainer" もしくは "Owner" 権限のユーザーで実行した場合は、以下のような出力とともにpushが正常終了します。

Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 294 bytes | 294.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To https://<Push先リポジトリのURL>
   xxxxxxxxxxx  main -> main

pushが成功した場合、GitLabのGUIからもmainブランチのリポジトリにファイルが増えていることを確認できます。

それ以外の権限のユーザーで実行した場合は、以下のようなメッセージでpushが失敗します。

Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 294 bytes | 294.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote: GitLab: You are not allowed to push code to protected branches on this project.
To https://<Push先リポジトリのURL>
 ! [remote rejected] main -> main (pre-receive hook declined)
error: failed to push some refs to 'https://<Push先リポジトリのURL>'

こちらのブログで記載したProtected branchesがどんなものかを確認しながら、mainブランチへのpushを試行していただければと存じます。

httpsを用いたmainブランチへのpush試行は以上です。

httpsで別名ブランチでpushを試行する

前の章で "Maintainer" と "Owner" 以外はProtected branchesで保護されているmainブランチにはプッシュできないことを確認できた (と思います) ので、今度はローカルで別名ブランチを作成し、そのブランチのpushを試行します。

別名の新しいブランチ作成には、ロール"Developer"、"Maintainer"、"Owner"のいずれかが必要です。
デフォルトのロールの権限内容を変更している場合は、この限りではありません。

Gitの基本的な操作が分かっていらっしゃる方は、ご自身の手順やツールでお試しください。
試行方法がよくわからない方のみ、後続のコマンド例をご参照いただければと存じます。

先ほどクローンしたリポジトリに移動し、別名のブランチを作成します。
ここでは例としてブランチ branch-test で進めます。

$ cd <先ほどcloneしたリポジトリ名>
$ git checkout -b branch-test

新しく作成したブランチで適当なファイルを追加します。
ここでは例としてファイル sample02.md で進めます

$ touch sample02.md

新しく作成したブランチへの変更をコミットします。

$ git add .
$ git commit -m "<コメントを任意に入力>""

新しく作成したブランチでpushを試行します。

$ git push origin <先ほど作成した任意のブランチ名と同じ文字列>

ユーザー情報を求められた場合は入力してください。
別名ブランチでのpushが成功すると、以下のような表示になります。

Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 312 bytes | 312.00 KiB/s, done.
Total 2 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
remote: To create a merge request for branch-test, visit:
remote:   https://<Push先リポジトリに作成したブランチのURL>
remote:
To https://<Push先リポジトリのURL>
 * [new branch]      branch-test -> branch-test

GUIからも、先ほど作成したブランチとファイルが反映されていることが確認できます。

別名ブランチのpush試行は以上です。

余談～SSL証明書に関連するメッセージ～

GitLabに限った話ではないのですが、Gitのリポジトリサーバーで自己証明書を使っていると、私のような初心者は色々と困るケースに遭遇しがちです。 httpsでgitコマンドを使う際に、以下はよくあるメッセージかと存じます。

TLS certificate verification has been disabled!

上記のwarningメッセージを消すためには、クライアント側で http.sslverify を true にすればいいです。
ただ、自己証明書のリポジトリサーバーを用いている場合に限っては、今度は以下のfatalメッセージが出て、git cloneすら実行できなくなる…というジレンマに陥ります。

fatal: unable to access '<リポジトリのURL>': SSL certificate problem: self signed certificate

この場合、いくつか回避方法があります。

毎回コマンドで "-c http.sslVerify=false" を指定する。 (セキュリティリスクを伴う方法なので個人的に非推奨。)
クライアント側のgitのグローバル設定で、http.sslVerify を false にする。 (セキュリティリスクを伴う方法なので個人的に非推奨。)
あきらめてsshを使ってgitコマンドを実行する。
Gitサーバー管理者に頼んで、自己証明書ではないサーバー証明書を実装してもらう。

4つ目については以下のブログでLet's Encryptの無料SSL証明書を実装する方法を紹介しております。よろしければご参照ください。
blogs.networld.co.jp

最後に

この度はGitもCI/CDもよくわかっていないど素人SEによるGitLab検証ブログをお読みいただき、誠にありがとうございます。
このブログの目標は以下のとおりでしたが、皆さまはいかがでしたでしょうか。

今回のゴール

GitLabの任意のリポジトリに対して、httpsを用いてgit clone と git push ができるようになる。
mainブランチに対してpushを試行することで、Protected branchesの効果を確かめる。

今回はシンプルに、GitLabの任意のリポジトリに対してhttpsを用いてgit cloneとgit pushをするだけでした。
この記事が「なんかよくわからんけどGitLabをとりあえず触りたい！」という方のお力になれば幸甚にございます。

GitLabに関するお問い合わせは、以下のフォームからお願い致します。
GitLab製品お問い合わせ

今までのGitLabの検証ブログはこちらです。

GitLab操作デモ動画 (基本編) を作ってみました。(音声の録音は自宅でiPhoneのボイスメモ使うという超低クオリティですが…。)
つたない内容ではありますが、ご興味がおありでしたら是非ご視聴いただければと存じます。