【 GitLab 】既存のフォルダをリモートリポジトリで管理

GitLab

はじめに:前回の記事でリモートプロジェクト(リポジトリ)を作成しておいて下さい


主のPC環境一覧

PC:Mac OS[Monterey]
CPU:Intel Core i7
メモリ:32GB
Git:2.35.1
GitLab:14.10.0-pre


先に知っておいた方が話が早い「git」コマンド

種類対象範囲設定ファイルの場所備考
global該当ユーザーの全リポジトリ~/.gitconfighomebrewなどで gitを既にインストールしていることが前提
local該当リポジトリ~/.git/config該当フォルダで $ git init をしており、ローカルリポジトリを作成していることが前提(以下で詳しく解説)
アカウントの切り替えコマンド

既に「GitHub」または「GitLab」で、アカウント作成が済んでいることが前提
※ Gitアカウントが複数ある場合(以下、主の例)
・GitHub:プライベート用
・GitLab:チーム開発用

$ git config user.name <ユーザー名>
$ git config user.email <メールアドレス>

各「global / local」アカウントの確認コマンド
// global
$ git config --global -l

// local
$ git config --local -l

各「global / local」アカウントの設定変更コマンド
global
// ユーザー名の変更
$ git config --global user.name <変更したいアカウントのユーザー名>

// メールアドレスの変更
$ git config --global user.email <変更したいアカウントのメールアドレス>
local
// ユーザー名の変更
$ git config --local user.name <変更したいアカウントのユーザー名>

// メールアドレスの変更
$ git config --local user.email <変更したいアカウントのメールアドレス>

「– local」オプションは省略することができる
globalのアカウント設定を変更したい場合は「– global」オプションを付けること


Git管理外の場所(超絶簡単にうと .gitがない階層で)で、ローカルアカウントの設定を変更しようとするとエラーになる
変更したい場合は、該当のリポジトリ内に移動してから実行すること


🙇🏼‍♀️ さて本題 大変お待たせいたしました 🙇🏼‍♀️

何かしらのプロジェクトなどを用意(主:Flutterプロジェクト)

言語:Dart / フレームワーク:Flutter

プロジェクトの作成(ローカル側):ローカルリポジトリ作成

[1] 該当のプロジェクトやフォルダへ移動(ターミナル またはコマンドプロンプト)

$ cd <移動先までのパス>

< 知らなかった ! ? >
Mac:ターミナル上で「cd」を入力した後に、Finderから該当のフォルダを ドラッグ&ドロップ でも移動することができる。
Windows:該当の場所までエクスプローラー上で移動し、検索窓で「cmd」を入力し Enterを押すとコマンドプロンプトが立ち上がり、その階層に入った状態になる。


[2] git init:リポジトリの新規作成(ローカル側)

<※ 重要 ※>
Gitのデフォルトブランチを「main」に切り替えておきましょう。【理由は後述】

$ git config --global init.defaultBranch main

Gitインストール時に元々「main」になっている方もいるかもしれませんが、何度やっても良いので、万が一の時のことを考えてしておきましょう!(圧)

【理由】
以下でも軽く触れますが「GitHub」や「GitLab」等の、Gitを使用したサービスで生成される『リモートリポジトリ』のデフォルトブランチ名が『master』から『main』に変更された。

しかし、ローカルにインストールしている Gitのバージョン等の違いで、ローカル側で Gitを初期化(上記のコマンド)した場合に生成されるデフォルトブランチが「master」のままでリモート側と整合性が取れなくなり余分な手間が手間が掛かることになる。



※ ちょっと言葉に語弊があるのは否めませんが要は、、
リモートから「fetch」してきたのは『main』やのに、ローカルのブランチは『master』やからそれを「merge」して、リモート側で『master』ブランチを生成して「push」するもしくは、ローカルで『main』ブランチを生成してから『master』の変更を「merge」して削除してからリモートの『main』に「push」するかみたいな、ね、、はい。

ローカルリポジトリの新規作成
$ git init

・ローカルフォルダ内に「.git」フォルダができていることを確認

「.git」は、隠しファイル
Mac:「cmd + shift + . (ピリオド)」で、表示
Windows:エクスプローラーのリボンから [表示] > [表示/非表示] > [隠しファイル] にチェック

ローカルリポジトリのユーザー情報設定を確認
$ git config --local -l

# core.repositoryformatversion = 0
# core.filemode = true
# core.bare = false
# core.logallrefupdates = true
# core.ignorecase = true
# core.precomposeunicode = true

「.git/config」を、コードエディタで開き変更や修正をすることも可能
※ 上記のターミナル上と同じ内容が書かれている

git init後のデフォルト内容

[3] git config:アカウントの切り替え(ローカルアカウントの追加)

↑:『このリポジトリでは、この Gitアカウントを使うよぉ』って教えてあげている感じ

$ git config --local user.name <GitLabで登録しているのユーザー名>
$ git config --local user.email <GitLabで登録しているメールアドレス>
設定が変更されていることを確認
$ git confid --local -l

# core.repositoryformatversion = 0
# core.filemode = true
# core.bare = false
# core.logallrefupdates = true
# core.ignorecase = true
# core.precomposeunicode = true

// 以下が追加されていることを確認
# user.name = <上記で設定したユーザー名>
# user.email = <上記で設定したメールアドレス>

[4] git add:ステージングしていないファイル群を追加

※ 変更内容をインデックスに追加することを「ステージング(管理対象)」と表現する

git status:ステージングされていないファイルを確認
$ git status

// 以下に、ステージングされていないファイルやフォルダが表示される
# On branch main

# No comits yet

# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#         .gitignore
#         .metadata
#         README.md
#         analyzeis_options.yaml
#         android/
#         ios/
#         lib/
#         pubspec.lock
#         pubspec.yaml
#         test/

# nothing added to commit but untracked files present (use 'git add" to track)
git add
// ステージング(Gitの管理対象にする)
//「.(ピリオド)」で、変更履歴のある全てを指定
$ git add .

[5] git commit:ステージングした変更をリポジトリに記録

git commit
// ステージングした変更をリポジトリに記録する
// -m:オプションでコミット内容にコメントを追加することができる
$ git commit -m "コメント"

// 以下にコミット内容がズラッと表示される
# ...
# ..
# .

リモートリポジトリとの紐付けの前に「add → commit」までしておかないと「.gitignore」で追跡対象外に設定しているファイル等が反映されず、意図しないデータまで追跡対象になってしまう。


[6] git remote:リモートリポジトリ と ローカルリポジトリ の紐付け

1. GitLabにログインし、前回の記事で作成したリモートリポジトリに入る
2. 画面中央部にある「クローン」を押下
3. 「SSH」と「HTTPS」があるが、今回は HTTPSを採用し URLをコピー
(※ SSHを利用する場合、その他の手続きに色々準備が必要なため今回は省く)

4. ローカルリポジトリ内で以下のコマンドに続き、先ほどコピーした URLを続ける

$ git remote add origin https://gitlab.com/<ユーザー名>/xxxx-xxxx.git
リモートリポジトリのURLを確認する方法
$ git remote -v

# origin  https://gitlab.com/<ユーザー名>/xxxx-xxxx.git (fetch)
# origin  https://gitlab.com/<ユーザー名>/xxxx-xxxx.git (pull)

よく勘違いをしてしまうこと

origin:デフォルトのリモートリポジトリの場所(URL)の別名
master:デフォルトのローカルブランチの名前([2]で解決済み)
※ [2] で、デフォルトを「main」に、変更しました。やってない方は大至急


[7] git fetch:リモートで更新された最新情報をローカルに持ってくる

fetch ってなに? pullとの違いは?

・リポジトリは「リモート」と「ローカル」と 2つ存在する。
・「git fetch」をすることで、リモート側で更新された最新情報をローカル側に持ってくるコマンドのこと。(注意:持ってくるだけ
・「git pull」のように、ファイルが更新されることはなく「origin/main」が更新される

<持ってくるだけってどういうこと?>
・ローカルリポジトリに「origin/main」というブランチが新たに生成される
・名前のないブランチとして生成され「git checkout FETCH_HEAD」で、そのブランチに入りこともできる

「$ git pull 」=「$ git fetch 」+「$ git merge 」


次、origin/main ってなんよ、、

・ローカル側の作業ディレクトリと結びついているのが「main」ブランチ
・リモート側と結びついているのが「origin/main」ブランチ

// リモート側の最新情報を取得(origin/main へ一時的に保存)
$ git fetch

// ローカル側(main)と、先ほど fetchしたリモート側を merge(rebase)
$ git merge origin/main

// ここまでして、やっとローカル側のファイル等がリモート側と同じように最新版になる。
// ※「merge」と「rebase」の、違いは以下で説明

=====================================================================
// 上記の工程をまとめてやってくれるのが pull
$ git pull


origin/master」と「origin/main」の 違い

デフォルトブランチ名が「master」から「main」に 変更された。
GitHub:2020/10 ~
GitLab:2021/03 ~

[背景]
米国ミネソタ州ミネアポリスで発生した警官による人種差別で黒人が窒息死に至らしめた事件が関与しているとかなんとか…

git fetch
$ git fetch

// - 以上省略 -
# .
# ..
# ...
#  * [new branch]    main      -> origin/main

[8] git rebase:2つ以上のコミットが存在するブランチを統合

今回の例では、作業ディレクトリに存在するローカルリポジトリ「main
と、リモートリポジトリから最新情報を取得し記録している「origin/main

$ git rebase origin/main

// 想定済みのエラーが以下にズラッと
# Auto-merging README.md
# CONFLICT (add/add): Merge conhlict in README.md
# error: cloud not apply <コミットID> <コミットコメント>
# Cloud not apply <コミットID> <コミットコメント>
コンフリクトの解消

[原因]
・リモート側で、新規リポジトリを作成した際に「README.md」ファイルがデフォルトで生成されている。(※ オプション設定次第で、生成しないこともできる)
・表題にもある通り、主がしようとしていることは既存プロジェクトを、リモート側で管理しようとしている(※ Flutterフレームワークで新規プロジェクトを立ち上げた場合、デフォルトで「README.md」ファイルが生成される)

以上 2つの「README.md」ファイルが衝突し、Gitに怒られている。
翻訳:両方、変更履歴あるんやけどどっちを rebaseしたらえぇのん?(怒)

主のようにプロジェクトまで生成しておらず、ローカルでの作業履歴をリモートで管理だけやってんけど。って方は、[9] まですっ飛ばして下さい。

皆様、愛用の Visual Studio Code のお世話になりましょう

Visual Studio Code で、README.md ファイルを開くと、以下のようになっている。

・上半分(緑):リモート側の「README.md」
・下半分(青):ローカル側の「README.md」

【再喝】
同じファイルが「リモート」でも「ローカル」でも変更が加えられていたので、どっちを適応するんや!? それとも両方とも適応すんのか!? って 激怒なう。

画像上部に赤枠で囲んである以下の項目がある
Accept Current Change:上半分の「リモート側」を適応
Accept Incoming Change:下半分の「ローカル側」を適当
Accept Both Change:両方の内容を 1つに結合
Compare Change:下半分に上下を比較した変更点を表すウィンドウ表示

今回はどちらを適応しても構わないのだが、ローカル側を採用するので「Accept Incoming Change」を選択し、保存して閉じる。

コンフリクト解消後は、変更内容をステージングする
// 変更ファイルを確認( "README.md" が表示される)
$ git status

// -- 省略 --
$ git add .
$ git commit -m "merge: コンフリクトの解消"
git rebase –continue
$ git rebase --continue

# ...
# ..
# Successfully rebased and updated refs/heads/main

[9] git push:ローカルリポジトリの変更内容を、リモートリポジトリへ送信する

$ git push

// エラーがまたもや(これまた想定済み 以下で解説)
# fatal: The current branch master has no upstream branch.
# To push the current branch and set the remote as upstream, use
#    git push --set-upstream origin master

親切なことに、懇切丁寧「こうしなさい」って書いてくれている。

【説明】
・明示的に push先を指定してあげなければならない
・現在のローカルブランチに、リモートリポジトリのブランチがないことが原因
※ [7] で生成された「origin/main」は、一時的なブランチでリモートブランチって訳ではない

$ git push --set-upstream origin main

ってことで、上記コマンドで push先を指定してあげれば問題なく通る。


最後に:以下の画像のように反映されていたら終了です

お疲れ様でした。

<次は各Gitコマンドについて詳しく書こうかな?>

主がまだ右も左も斜めも分からなかった時のこと、、
どの記事を参考にしても、ある程度の前提知識を踏まえての解説が多く、その記事内だけでは現状ぶつかっている問題が解決できないことが多かった。

「こうしなさい!」または「こうした方が良い!」ってのが多く、理解をして進めたい主としては納得できるわけもなく、、
希望的には「これそれあれ があるけど、これはこう言う時に使って それはこんな時に便利で あれは主流じゃないけどこんな利点もある」的な的な感じの記事で出会いたかったなと思って主自身が作ることにした。

何か、こんな記事が欲しいとかありましたらコメントください。ご指摘とか、、

参考

・$ git fetch
https://qiita.com/takakuda/items/2123e37733445f69f0ff

・$ git push
https://pointsandlines.jp/env-tool/git-push-upstream

comment 📝

タイトルとURLをコピーしました