株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。
各製品のエキスパートたちが旬なトピックをご紹介します。

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

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

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

私の普段の業務はGitやCI/CDに無縁なのですが、会社から頂戴した「GitLabの技術ブログ書いておいて」というミッションを達成すべく、今回も頑張ってGitLabの技術をちまちま習得してまいります。
今回はシンプルにGitLabでhttpsを用いてクローンとプッシュを試すだけの話です。壮絶に簡単…。
(SSHを用いる場合についてはこちらをご参照ください。)

このブログの内容は以下の通りです。

本記事の対象の方

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

今回のブログのゴール

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

このブログのゴール
  • GitLabの任意のリポジトリに対して、httpsを用いてgit clone と git push ができるようになる。
  • (余裕があれば) mainブランチに対してpushを試行することで、Protected branchesの効果を確かめる。

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

  • 本記事はGitLabがどういった製品なのかの説明はしておりません。製品説明につきましては弊社の製品ページ (こちら) をご参照ください。
  • 本記事はGitやCI/CDに関する知識ゼロのSEによるなんちゃって記事です。GitLabのディープな使用法についてはGitLabの公式オンラインドキュメント (こちら) をご参照ください。
  • 本記事はこちらのGitLabに関するブログの続きを想定しており、既にREADME.mdだけ含むリポジトリが存在していることを想定しております。
  • 本記事は GitLab Community Edition 14.7.3 における仕様をベースに記載しております。それ以外のエディションやバージョンではこの記事に記載の通りではない可能性がございます。

最初に確認

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.

上の画面のメッセージが表示されている場合、パスワードが未設定 且つ アクセストークンが未作成 の可能性があります。(上の図のメッセージが出ていても、絶対にパスワードが未設定 且つ アクセストークンが未登録というわけではないです。)
httpsでクローンなどを実行する場合、少なくともどちらかが必要になります。
後続の手順 パスワードの設定 及び アクセストークンの作成 をご参照いただき、必要に応じて設定をしてください。

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

パスワードの設定

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

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

ここから新しいパスワードを設定し、[パスワードを保存] をクリックします。

パスワードの設定は以上です。

アクセストークンの作成

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

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

画面左側の [アクセストークン] をクリックします。

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

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

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

アクセストークンの作成は以上です。

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

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

httpsでクローンを試行する

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

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

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

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

$ git clone <先ほどコピーした文字列>

ユーザー名を求められるので、GitLabのGUIにログインする時のユーザー名をそのまま入力してください。
(ログイン時にメールアドレスを使っている場合は、メールアドレスになります。)

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

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

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

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

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

ここでは、mainブランチに対してプッシュを試みます
先に言っておくと、対象プロジェクトに対して "Maintainer" か "Owner" の権限を持っているユーザー以外は通常 main ブランチにはプッシュできません
これは、GitLab14.0以降は "main"、それより前では "master" がデフォルトブランチ 且つ Protected branchesであり、保護されているからです。
Protected branchesとデフォルトブランチについては、こちらのブログで概要を述べておりますので、よろしければご参照ください。
blogs.networld.co.jp

したがってこの章は、"Maintainer" か "Owner" でmainブランチ (Protected branches) にプッシュできることを確認する、もしくは、他の権限のユーザーでmainブランチ (Protected branches) にプッシュできないことを確認する、といった内容になります。
なお、Gitの基本的な操作が分かっていらっしゃる方は、ご自身の手順やツールでお試しください。
プッシュの仕方がよくわからない方のみ、後続のコマンド例をご参照いただき、mainブランチへのpushをご試行いただければと存じます。

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

$ cd <先ほどcloneしたリポジトリ名>
$ touch <適当なファイル名>

コミットします。

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

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

$ git push origin main

"Maintainer" もしくは "Owner" 権限のユーザーで実行した場合はpushが正常終了します。

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

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

error: failed to push some refs to 'https://<GitLabのURL>/<リポジトリパス>'

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

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

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

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

先ほどクローンしたリポジトリに移動し、別名のブランチを作成します。

$ cd <先ほどcloneしたリポジトリ名>
$ git checkout -b <任意のブランチ名>

新しく作成したブランチで適当なファイルを追加します。

$ touch <適当なファイル名>

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

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

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

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

別名ブランチでのpushが成功すると、以下のような表示になります。

GUIからも先ほどpushした別名のブランチが作成されていることが確認できます。

別名ブランチの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製品 お問い合わせ

2022/05/20追記
GitLab操作デモ動画 (基本編) を作っちゃいました。
つたない内容ではありますが、ご興味がおありでしたら是非ご視聴いただければと存じます。

www.youtube.com