Download to read offline
![リポジトリ操作実行例
$ touch README.md
$ git add README.md
$ git commit
[main (root-commit) 77eb748] add README.md
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 README.md
$ git push -u origin main
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 218 bytes | 218.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To http://gitlab.example.com/tmiyahar/test.git
* [new branch] main -> main
Branch 'main' set up to track remote branch 'main' from 'origin'.
26](https://image.slidesharecdn.com/211015gitlab-211015085045/75/GitLab-Ubuntu-26-2048.jpg)
![3. git push 失敗
$ git push
To http://gitlab.example.com/tmiyahar/test.git
! [rejected] main -> main (fetch first)
error: failed to push some refs to 'http://gitlab.example.com/tmiyahar/test.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
35](https://image.slidesharecdn.com/211015gitlab-211015085045/75/GitLab-Ubuntu-35-2048.jpg)
![5. 6. コンフリクト修正と再push
$ vi README.md
$ git commit -a
[main 2705f27] Merge branch 'main' of
http://gitlab.example.com/tmiyahar/test
$ git push
Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Delta compression using up to 16 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (6/6), 537 bytes | 537.00 KiB/s, done.
Total 6 (delta 0), reused 0 (delta 0), pack-reused 0
To http://gitlab.example.com/tmiyahar/test.git
9cb63b7..2705f27 main -> main
37](https://image.slidesharecdn.com/211015gitlab-211015085045/75/GitLab-Ubuntu-37-2048.jpg)
Uploaded byVirtualTech Japan Inc./Begi.net Inc.
今さら聞けない人のためのGitLabの始め方 Ubuntu編
GitLab Meetup Online #1 の講演資料です。 今さら聞けない人のためのGitLabの始め方 Ubuntu編 GitLab 14対応版
More Related Content
Similar to 今さら聞けない人のためのGitLabの始め方 Ubuntu編
今さら聞けない人のためのGitLabの始め方 Ubuntu編
- 1. 今さら聞けない人のための GitLabの始め方 Ubuntu編 GitLab 14対応版 みやはらとおる（@tmiyahar）
- 2. GitLabと私 • インフラエンジニア上がりの経営者 – 年に1案件ぐらいはガッツリやる程度 •Gitの使い方を覚えるためにGitLabを導入 – 根がインフラ屋なので自分でサーバーを立て ないと気が済まない • お客さんから社内リポジトリとしてGitLab入 れて、と言われて導入したことはある • 社内でも使ってるけどノータッチ • それとなくGitLabを勧める活動を継続中 2
- 3. 今回作る環境について • Ubuntu 20.04LTSにGitLab14.1 Enterprise Editionをインストール – Enterprise Editionでもライセンスを有効にしな ければCommunity Edition相当（GitLab Core） – Omnibusインストールで必要なものがまとまっ て入ります 3
- 4. GitLabをインストールする • GitLabのWebページ 「OfficialLinux package (recommended installation)」を参考に環境を構築 – https://about.gitlab.com/install/#ubuntu – Kubernetesやクラウド上へのインストールも可能 1. GitLabのWebページ（https://about.gitlab.com/）の Productメニューから「Install GitLab」を選択 2. インストールしたいOS・環境を選択 3. 手順に従ってインストール 4
- 5. GitLab 14インストールの注意点 • Let‘sEncryptによるTLS化がデフォルト手順 – ドキュメントでのインストール時の EXTERNAL_URLの指定が"https://○○"に →ローカルIPアドレスだとLet's EncryptのTLS証明 書生成がコケてインストール失敗 – EXTERNAL_URLの指定を"http://○○"に • DNSの逆引き名前解決の設定が必要 – /etc/hostsではダメ – インストールスクリプト（Chef利用）がコケるので、 gitlab-ctl reconfigureの実行が必要 5
- 6. Ubuntuのインストール • 18.04LTSか20.04LTSを適当にインストール – 適当≒インストール時に設定できることはほと んどありません •仮想マシンで運用までする場合にはメモリ は気持ち多め、ディスクも多めにしておくと よい – 後で増やせるように心構えをしておく • インストール終わりが分かりにくいので注意 6
- 7.
- 8.
- 9. Ubuntu 20.04LTSへのインストール 1. sudoapt-get update 2. sudo apt-get install -y curl openssh-server ca-certificates tzdata perl 3. sudo apt-get install -y postfix – 用途が求められるので適当に 4. curl https://packages.gitlab.com/install/repositories/gitlab/git lab-ee/script.deb.sh | sudo bash 5. sudo EXTERNAL_URL="http://gitlab.example.com" apt-get install gitlab-ee – 注）逆引き名前解決でコケるとconfigに失敗します 6. sudo gitlab-ctl reconfigure 9 ←必ず実行
- 10.
- 11.
- 12. 最後に手動でコンフィグする • パッケージのインストールの最後でコンフィ グがこける • 忘れずにsudogitlab-ctl reconfigureする事 12 Thank you for installing GitLab! GitLab was unable to detect a valid hostname for your instance. Please configure a URL for your GitLab instance by setting `external_url` configuration in /etc/gitlab/gitlab.rb file. Then, you can start your GitLab instance by running the following command: sudo gitlab-ctl reconfigure
- 13. 管理者パスワードについて • 一時ファイルに書き込まれるようになった – /etc/gitlab/initial_root_password –以前は初期ログイン時に設定していた • コンフィグの最後に以下の様に表示される 13 Notes: Default admin account has been configured with following details: Username: root Password: You didn't opt-in to print initial root password to STDOUT. Password stored to /etc/gitlab/initial_root_password. This file will be cleaned up in first reconfigure run after 24 hours.
- 14.
- 15. GitLabの管理単位 ファイルサーバーと大体同じと思えばOK • ユーザー – 各開発者のアカウント •グループ – ユーザーをまとめた管理単位 • プロジェクト – ソースコードのリポジトリを含めた開発プロ ジェクトに必要なもの一式 – ユーザー、あるいはグループに紐付けられる 15
- 16. GitLabで初期設定作業 1. rootパスワードを確認 – /etc/gitlab/initial_root_passwordに記載 2.http://gitlab.example.comにアクセス 3. ユーザーrootでログイン 4. ユーザーrootのパスワードを変更 – 右上のアイコン→Edit Profile→Password 5. 新しいユーザーを作成 – Menu→Admin→Users→New User 6. 新規ユーザーのパスワード設定 – ユーザー情報ページ→Edit 7. 新規ユーザーでログイン 16
- 17.
- 18.
- 19. プロジェクト作成とクローン ユーザーtmiyaharを作成しています 1. 新規プロジェクトtestを作成 2. クライアントにリポジトリをクローン –git clone http://gitlab.example.com/tmiyahar/test.git • ユーザー認証が必要 19 $ git clone http://gitlab.example.com/tmiyahar/test.git Cloning into 'test'... Username for 'http://gitlab.example.com': tmiyahar Password for 'http://[email protected]': ※パスワード warning: You appear to have cloned an empty repository.
- 20.
- 21. Gitのリポジトリ種別 • ローカルリポジトリ – 開発作業用クライアントに作成される –リモートリポジトリをクローンすると作成される • クローンが一番分かりやすい – 作業は他の開発者には影響しない • リモートリポジトリ – GitLab上に作成される – 各開発者で共有される 21
- 22. ローカルリポジトリの確認 • クローンしたリポジトリを確認 – $cd ~/test – $ git switch -c main – $ ls -a – 現時点では空っぽです – .gitディレクトリが作られており、リポジトリの各 種情報が格納されている 22
- 23. ステージングとコミットの関係 23 作業用 ディレクトリ ステージング 領域 ローカル リポジトリ $ git switch $git add $ git commit リポジトリは ブランチ毎の ファイルセットを 保持している main develop
- 24.
- 25. リポジトリにファイルを追加 1. 作業ディレクトリにファイルを追加 – $touch README.md 2. ファイルをステージング – $ git add README.md 3. ステージングしたファイルをコミット – $ git commit 4. コミットしたファイルをリモートにプッシュ – 同時にローカルリポジトリのアップストリーム設定 – $ git push -u origin main • mainブランチのアップストリームをリモートリポジトリの main（remotes/origin/main）に設定 25
- 26. リポジトリ操作実行例 $ touch README.md $git add README.md $ git commit [main (root-commit) 77eb748] add README.md 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 README.md $ git push -u origin main Enumerating objects: 3, done. Counting objects: 100% (3/3), done. Writing objects: 100% (3/3), 218 bytes | 218.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 To http://gitlab.example.com/tmiyahar/test.git * [new branch] main -> main Branch 'main' set up to track remote branch 'main' from 'origin'. 26
- 27. ブランチの流れ 27 main develop ① $ gitswitch -c develop ③ $ git merge develop ②コミットを繰り返す
- 28. ブランチを作成する 1. ブランチの確認 – $git branch – 現時点ではローカルのmainだけ 2. ブランチの新規作成と切り替え – $ git switch -c develop – 従来のgit checkout -b相当 3. ブランチの確認 – $ git branch – 作業しているブランチがdevelopに変更されている 28
- 29. ブランチ作成実行例 $ git branch *main $ git switch -c develop Switched to a new branch 'develop’ $ git branch * develop main 29
- 30. developブランチで作業 1. developブランチのREADME.mdを修正 – エディタで何か書きます 2.修正をステージングとコミット – $ git add README.md – $ git commit – $ git commit -a でまとめて実行も可能 3. mainブランチのREADME.mdを確認 – $ git switch main – $ cat README.md – developブランチでの修正が影響していない事を 確認 30
- 31. developブランチをマージする 1. developブランチにコミットされた修正差分 をmainブランチにマージする – $git merge develop 2. README.mdを確認 – developブランチで行った修正が反映される • マージは取り込む側のブランチで行う – だから、取り込んで欲しいときは「マージ（プ ル）リクエスト」を作成する 31
- 32.
- 33. 修正の重複（コンフリクト）の解消 • git push時に既にリモートが更新されているとプッ シュに失敗する •git pullするとコンフリクト発生が通知され、対象と なるファイルが以下のようになる • 適切に修正し、再度コミット＆プッシュ 33 developブランチで修正 <<<<<<< HEAD ローカルのmainブランチで修正 ======= Webブラウザで修正 >>>>>>> fcfafd335fd5d6a4bb8938c1c2dcbe17788debf5
- 34. コンフリクト解消手順 1. WebブラウザでREADME.mdを確認 – この時点では空っぽです 2.Editボタンを押して何か書く – 他のユーザーがpushしたのと同義 3. $ git push – Webブラウザ側での変更が取り込まれておらず失敗 4. $ git pull – コンフリクトが発生し、自動マージに失敗 5. README.mdを編集してコンフリクトを解消 6. 再度、コミット＆プッシュします – 今度は成功します 34
- 35. 3. git push失敗 $ git push To http://gitlab.example.com/tmiyahar/test.git ! [rejected] main -> main (fetch first) error: failed to push some refs to 'http://gitlab.example.com/tmiyahar/test.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. 35
- 36. 4. git pullするとコンフリクト発生 $git pull （rebase関係の設定をしろとhintが出るがとりあえず今回は無視） remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (3/3), 232 bytes | 232.00 KiB/s, done. From http://gitlab.example.com/tmiyahar/test 77eb748..9cb63b7 main -> origin/main Auto-merging README.md CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result. 36
- 37. 5. 6. コンフリクト修正と再push $vi README.md $ git commit -a [main 2705f27] Merge branch 'main' of http://gitlab.example.com/tmiyahar/test $ git push Enumerating objects: 10, done. Counting objects: 100% (10/10), done. Delta compression using up to 16 threads Compressing objects: 100% (2/2), done. Writing objects: 100% (6/6), 537 bytes | 537.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0), pack-reused 0 To http://gitlab.example.com/tmiyahar/test.git 9cb63b7..2705f27 main -> main 37
- 38. ブランチ戦略を考える よくある質問 • Q. 「どのブランチ戦略がいいんですか？」 •A. 「ケースバイケース」 • 考慮すべき事（順不同） – 開発者の人数や規模 – コミットやマージの頻度や粒度 – テストの頻度や方法 – リリースの頻度や方法 38
- 39. この先に考えたい事 • テスト駆動やチケット駆動との連携 • テストの自動化 –コードコミット→テスト→マージリクエストのサ イクルの自動化 – 粒度が小さいとマージ処理する人が大変 • チケットの自動化 – テスト失敗時に自動的にチケット発行 – テスト成功時に自動的にチケットクローズ 39
- 40.