概要

前回に引き続きプロジェクトの基本機能について触れていきます。
今回はプロジェクトのマージ実行時の競合について学習していきます。

競合(コンフリクト)

GitLab上のプロジェクトにあるファイルについて、例えば2人のプロジェクトメンバーがプロジェクトのクローンを行い、全く同じファイルを編集したとします。
メンバーAが編集を完了し、GitLab上のマスターブランチへマージを行います。
当然マスターブランチにはメンバーAが編集したファイルとして更新されている状態になります。
この状態で異なる編集を行ったメンバーBがマスターブランチへマージを実施しようとすると、メンバーBのクローンしたファイルにはメンバーAが編集した内容が反映されていませんので、その差分が発生してしまいます。
この状態を競合(コンフリクト)と呼びます。
実際に競合を発生してみたいと思います。

競合の発生

まずは以前作成したプロジェクトのクローンを行います。
今回もGitBashを使用します。

GitBash上で上記の通りクローンを行いました。
プロジェクトのディレクトリ内にあるテキストファイルを編集します。
今回は以下画像の青い線が引かれた箇所を追記しました。

その後、以下の要領でコミットからプッシュまで実施しています。

現時点でGitLab上には原本であるmasterブランチと原本を修正したdevelopブランチが存在している状態です。
この状態で一旦別のディレクトリへ移動し、再度クローンを実行します。

現在のブランチはmasterが選択されている状態ですので、再びブランチの切り替えを実施します。
今度はdevelopとは異なる名称で新たにブランチを切ります。
以下の通り新たにdebugというブランチを作成し、切り替えしました。(ブランチ名は適当に付けました…)

新しいブランチにてテキストファイルを以下の通り修正しました。
修正箇所は青線部分です。

先程と同じ要領でGitLabへプッシュまで実施しました。
この時点では特にエラーらしきメッセージは表示されていません。(それぞれ別のブランチで修正しているので当然ですが…)

GitLabへ戻り、まずはdevelopブランチをmasterブランチへマージします。
GitLabのマージリクエストの画面へ移動します。
以下のマージリクエスト画面にある緑の枠で囲った「New merge request」をクリックします。
※「マージリクエストを作成」からだと最後にプッシュしたブランチが指定されます。最後にプッシュしたブランチは「debug」ですが、その前にプッシュした「develop」ブランチのマージがまだ未実施なので、「develop」ブランチを指定する必要があります。

「Source branch」欄内の青枠内に選択されているブランチをdevelopに変更します。
「Target branch」はデフォルトでmasterが選択されていますので、ここは切り替え不要です。
この状態で、「Compare branches and continue」をクリックします。

New Merge Requestの画面に移動します。
下記画像の赤線部に「From develop」と記載されている事を確認し、「Submit マージリクエスト」をクリックします。

以下の画面に移動しますので、「マージ」をクリックします。
※前回マージ実行時に、以下の赤線部「ソースブランチを削除」にチェックが入ったままマージしてしまったので、前回のdevelopブランチが消失してしまっていました…
今回はチェックを外しています

特にエラーなく完了しました。

masterブランチのファイルとdevelopブランチのファイルの内容が一致している事がわかります。

この状態で今度はdebugブランチとmasterブランチをマージしてみます。
再びマージリクエストの画面へ移動し、「New merge request」をクリックします。

デフォルトでソースブランチが選択されていない状態となりますので、「ソースブランチを選択」をクリックし、プルダウン内から「debug」を選択します。
Target branchはmasterのまま、「Compare branches and continue」をクリックします。

以下画面の赤線部が「From debug」となっている事を確認し、「Submit マージリクエスト」をクリックします。

すると以下の画面に移動します。
赤枠で囲っている箇所に「マージ」ボタンが表示されていますが、クリックする事が出来ません。
また、赤線部に競合を示すメッセージが表示されています。
これでマージの再現が出来ました。

競合の解決

競合を発生させたところで、次は競合を解消していきます。
競合を解決させるには、GitLab上で操作する方法と、ローカル上で修正する方法の2パターン存在しているようです。
今回はお手軽なGitLab上での解消方法を試してみます。
まずは以下の画面から「競合を解決する」を選択します。

すると以下の画面に移動します。
ここで表示されている「HEAD //自分の変更」がマージを行えなかったdebugブランチの変更内容で、「origin //相手の変更」はマージ先の変更対象となっています。
以下画面の緑枠の「自分の変更を使用」をクリックするとorigin変更分が削除され、逆に「相手の変更を使用」をクリックするとdebugの変更がキャンセルされる様です。
また、オレンジ枠の「Edit inline」をクリックするとテキストエディタモードになり、編集が出来るようになります。
両方の変更を保持したい場合は、Edit inlineで手動で修正するとよいでしょう。

今回は「Edit inline」を使用し、両方の変更を反映させました。(少し見えづらいですが…)
編集が完了しましたら、「ソースブランチへのコミット」をクリックします。

先程のマージリクエストの画面に戻ります。青線部に競合が解消されたというメッセージが表示されています。
しかしこの状態ではまだ「マージ」ボタンをクリック出来ません。
緑枠内の「承認」をクリックすると、「マージ」がクリック出来るようになります。
※競合の解消内容を他のメンバーにレビューしてもらう事を想定しているのではないかと思います

「マージ」が押せるようになった状態で、「マージ」をクリックしましたところ、以下の画面に切り替わりました。
無事にマージが完了したようです。

マスターブランチ内のファイルを開くと、先程競合の解消を行った際に編集した内容が反映されています。

以上で競合の解消は完了となります。

今回でGitLabのプロジェクトの基本的な使い方は一旦終了となります。
次回はLFSについて学習しようと思います。

commitメッセージを確認するときに

$ git log

を使うと思いますが

コミットメッセージ だけ確認したい時は

$ git log --oneline

を使うとかなり見やすくなるのでおすすめです！

実際にやると

これが

こう

です。

"git log"のオプションは他にも便利なものがあるみたいなので気になる方はこちらのページがおすすめです。
https://techacademy.jp/magazine/10200

是非！

はじめに

この記事はJ自分用のメモです。
※内容について、誤った知識やもっとわかりやすい表現等ございましたら、ご指摘いただけますと幸いです。

用語	意味
ディレクトリ	フォルダのこと
リポジトリ	開発の履歴管理を行う場所
ローカルリポジトリ	自分のPCにあるリポジトリ、各人がそれぞれのPC上で使うリポジトリ
リモートリポジトリ	GitHubにあるリポジトリ、サーバに配置して複数人で共有するリポジトリ
ブランチ(branch)	履歴を枝分かれさせること >他のブランチの影響を受けないため複数の作業を同時に進められる >作業単位で履歴を残すことで後で見た時にわかりやすい ・git branch [branch-name]：ブランチの作成 ・git branch：ブランチの一覧表示 ・git branch –d [branch-name]：指定したブランチを削除
マージ(merge)	ブランチで枝分かれした履歴を１つにまとめること
コミット(commit)	ファイルの追加や変更の履歴をリポジトリに保存するコマンド
インデックス(index)	コミットしたいファイルを登録する場所
ステージング(staging)	ファイルをインデックスにあげるコマンド
プッシュ(push)	ローカルリポジトリの変更をリモートリポジトリに反映させるコマンド
プル(pull)	リモートリポジトリの変更をローカルリポジトリに反映させるコマンド
クローン(clone)	既存のリモートリポジトリをローカルに落とすために使うコマンド 例）GitHubに公開されているリポジトリを自分のコンピュータへ落とすときに使う
アド(add)	ファイルやディレクトリをインデックスに追加するために使うコマンド
checkout	ローカルリポジトリのブランチを切り替えるときに使うコマンド
remote	リモートリポジトリを操作するために使うコマンド ・git remote：リモートリポジトリの名称一覧を表示 ・git remote -v：リモートリポジトリの詳細一覧を表示 ・git remote add [name] [url]：リモートリポジトリを追加 ・git remote rm [name]：リモートリポジトリを削除
ステータス(status)	リポジトリの状態を確認するために使うコマンド
init	リポジトリを新規作成する、または既存のリポジトリを初期化するコマンド
mkdir	ディレクトリ（フォルダ）作成用のコマンド
cd	ディレクトリ(フォルダ)を移動するときに使う 例）cd (移動先のパス)

たまにしかgitを使わないひとのための、最小限の備忘録

git init
git add *
git commit -m "initial commit"
git remote add origin http://xxxxxx.xxx/xxxx.git
git push origin main

この記事はMac OS big surのユーザが対象です

git kraken速度完全方法

公式のtwitterアカウントが一時的な回避方法を載せいていました。

このコードは一部の署名を消すコマンドだそうです。

codesign --remove-signature /Applications/GitKraken.app/Contents/Frameworks/GitKraken\ Helper\ \(Renderer\).app

git krakenをアップデートした際にはもう一度このコマンドを打つ必要があると書いていました。

翻訳ソフトを書けただけなので詳しく知りたい方は、下の文を読んでください。

tweet原文

This is currently a known issue with the new Mac Big Sur OS. 

As a workaround, consider running the following command in your terminal:

codesign --remove-signature /Applications/GitKraken.app/Contents/Frameworks/GitKraken\ Helper\ \(Renderer\).app

This temporary workaround removes the GitKraken Signature (making it a partially-signed app) which means if you update GitKraken you will need to do this again. However, this should help with the performance for now while we wait for Apple to address this issue.

参考

https://twitter.com/gitkraken/status/1329443370385743877?s=21

この記事はMac OS big surのユーザが対象です

git kraken速度完全方法

公式のtwitterアカウントが一時的な回避方法を載せいていました。

このコードは一部の署名を消すコマンドだそうです。

codesign --remove-signature /Applications/GitKraken.app/Contents/Frameworks/GitKraken\ Helper\ \(Renderer\).app

git krakenをアップデートした際にはもう一度このコマンドを打つ必要があると書いていました。

翻訳ソフトをかけただけなので詳しく知りたい方は、下の文を読んでください。

tweet原文

This is currently a known issue with the new Mac Big Sur OS. 

As a workaround, consider running the following command in your terminal:

codesign --remove-signature /Applications/GitKraken.app/Contents/Frameworks/GitKraken\ Helper\ \(Renderer\).app

This temporary workaround removes the GitKraken Signature (making it a partially-signed app) which means if you update GitKraken you will need to do this again. However, this should help with the performance for now while we wait for Apple to address this issue.

参考

https://twitter.com/gitkraken/status/1329443370385743877?s=21

リモートブランチを作ろう

とりあえずフォルダとファイルを作る

GitHubのページに行き、右上の New repositoryをクリックする

ローカルのフォルダと同じ名前をいれる、Create repositoryをおす

gitを使えるようにする(空のgitリポジトリを作りましたよん?)って書いてある

% git init
Initialized empty Git repository in /Users/numataseiji/Documents/practice/GitPractice/.git/

まずローカルにcommitして、リモートにpushする

% git add neko.html

% git commit -m"first commmit"
[master (root-commit) b026deb] first commmit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 neko.html
% git remote add origin https://github.com/SeijiNumata/GitPractice.git

% git push -u origin master
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 198 bytes | 198.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/SeijiNumata/GitPractice.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

いい感じ

---

次、remoteのbranch作ってみっか
ローカルにブランチを作ってチェックアウト
する

% git branch
* master
% git checkout -b develop  #git branch develop してからgit checkout developするのと同じ効果
Switched to a new branch 'develop'
% git branch
* develop
  master

いっけえ(remoteに登録)

% git push -u origin develop 
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: 
remote: Create a pull request for 'develop' on GitHub by visiting:
remote:      https://github.com/SeijiNumata/GitPractice/pull/new/develop
remote: 
To https://github.com/SeijiNumata/GitPractice.git
 * [new branch]      develop -> develop
Branch 'develop' set up to track remote branch 'develop' from 'origin'.

できたあ

---

マージをしてみよう

とりあえずmergeできるように準備しよう。
この状態を目指す
git pull と git pull –rebase の違いって？図を交えて説明します！より

一回マスターブランチに戻ろう

% git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.

ファイルを編集する

<body>
  <p>Hello World</p>
  <p>猫の形にした</p>
  <p>目をつけた</p>  
  <p>にゃああ</p>
</body>

commit しておく

% git add neko.html
% git commit -m"make cat and eyes"
[master 91fec54] make cat and eyes
 1 file changed, 3 insertions(+)

branchきる（ひげブランチ）

% git checkout -b makeHige 
Switched to a new branch 'makeHige'
 % git branch
  develop
* makeHige
  master

htmlを編集する

<body>
  <p>Hello World</p>
  <p>猫の形にした</p>
  <p>目をつけた</p>  
  <p>ひげつけます</p>
  <p>6本いいですか？</p>
  <p>にゃああ</p>
</body>

コミットしておく

% git add neko.html
% git commit -m"make beard"
[makeHige ae44f75] make beard
 1 file changed, 5 insertions(+)

またマスターにチェックアウトする。

% git checkout master
Switched to branch 'master'

ファイルを編集

<body>
  <p>Hello World</p>
  <p>猫の形にした</p>
  <p>目をつけた</p>  
  <p>にゃああ</p>
  <p>口を作った</p>
</body>

% git add neko.html
% git commit -m"make mouth"
[master 91f2876] make mouth
 1 file changed, 1 insertion(+)

ここまででやっと準備が完了した。
差分を確認してみると、口はあるけどひげがないマスターブランチと、ひげはあるけど口がないひげブランチがある。これを合体させて口もあるしひげもあるファイルを作る。

% git diff makehige
diff --git a/neko.html b/neko.html
index 06e3ee2..7d94e24 100644
--- a/neko.html
+++ b/neko.html
@@ -28,9 +28,8 @@
   <p>Hello World</p>
   <p>猫の形にした</p>
   <p>目をつけた</p>  
-  <p>ひげつけます</p>
-  <p>6本いいですか？</p>
   <p>にゃああ</p>
+  <p>口を作った</p>

今回はマスターブランチにひげブランチをマージする。

% git merge makehige
Auto-merging neko.html
CONFLICT (content): Merge conflict in neko.html
Automatic merge failed; fix conflicts and then commit the result.

コンフリクトした。手動で直してあげる。

<body>
  <p>Hello World</p>
  <p>猫の形にした</p>
  <p>目をつけた</p>  
<<<<<<< HEAD
  <p>にゃああ</p>
  <p>口を作った</p>
=======
  <p>ひげつけます</p>
  <p>6本いいですか？</p>
  <p>にゃああ</p>
>>>>>>> makehige
</body>

↓

<body>
  <p>Hello World</p>
  <p>猫の形にした</p>
  <p>目をつけた</p>  
  <p>口を作った</p>
  <p>ひげつけます</p>
  <p>6本いいですか？</p>
  <p>にゃああ</p>
</body>

いいかんじにしてあげたら、またアドしてコミットする

% git add .                                 
% git commit -m"merge hige and fix conflict"
[master c60d1b9] merge hige and fix conflict
 1 file changed, 1 deletion(-)

一応マージできたので、リモートにプッシュする。
ひげブランチはもう不要なので削除する。

% git branch
  develop
  makeHige
* master
% git branch -d makehige
Deleted branch makehige (was ae44f75).
% git branch
  develop
* master

% git push origin master

できました。

CI（継続的インテグレーション）の基本

共有しているリポジトリに統合するだけで、「ビルド」と「テスト」が自動的に実行される手法のことを言います。
Gitのリポジトリにコミットする

https://tracpath.com/bootcamp/ci/continuous-integration.html

有名なソフトウェア
サークルCI、ジェンキンス

【Java版】CI（継続的インテグレーション）ツール導入ガイド

https://tracpath.com/bootcamp/ci/

Git

コンクリフトがおきた時の対処方法
git reset --merge

チーム開発を行う際には
全員にGITのIDを作成してもらう、
レポジトリを作成するA　各チームにAのクローンを作成してもらう
各自ローカルレポジトリを作成してもらい、クローンを入れる。

変更を行ったら、ステージ、コミットでローカルでコミットを行い
レポジトリにプッシュする、まちがえてしまったりしたら本体のプルすること

プルした際にコンクリフトが発生したら、適時判断してどちらを優先させるか
判断する事。

プッシュした際にコンクリが発生したら、１度プルしてから
プッシュした方が良い。

別々で作成する場合には、ブランチを作成する。
マスターにマージしたいときには、ブランチのマージを作成して
プルリクエストを投げて、管理者にマージの依頼をする。

新規の場合には、新規フォルダを作成してから
クローンを作成する、そこからGITHUBと連携を取る

1〜2週目で基礎カリキュラムを終え、3週目からは応用カリキュラムへと入りました。
新型コロナの影響で自粛ムードが続きますが、コロナの不安も忘れるぐらい集中して勉強できているのは受験生以来だなとつくづく思いました。

社会人になってからも勉強は大切なことを身にしみました。プログラミングを短期集中で学ぶことで理解度を高められると思うので、この良い学習習慣を継続させていきたいと思います。

応用カリキュラム

・質問フォーマットの活用
・検索力、読みやすいコード
・JavaScript、jQuery基礎
・Git、GitHub
・SQL

質問フォーマットの活用
まず応用カリキュラムに入るにあたって、メンターへの質問方法が変わりました。
これまではわからないことがあればエラー内容をそのまま教えてもらったり、ミスしている部分を修正してもらえたのですが、これからは検索して調べ、そこから仮説を立てて実践、それでもわからなければメンターへその内容を踏まえ質問をする、という形式です。

個人的には、これまでもそのように質問していましたが３週目に入りメンターへの質問の質が高まってきたと実感しています。

検索力、読みやすいコード
エンジニアに必要な検索力を身につけよう、ということで検索の際のキーワード選びや目的の情報が載っているサイトの選び方、あとは期間指定で新しい記事を探す方法を学びました。この能力はどれだけ数をこなしていくかが大事だと思います。今の時代は知識力も大切ですが検索力も必須だなと思います。

あとは読みやすいコード・良いコードを書く、という意識をつけることを学びました。
命名規則、レイアウト、コメント、リファクタリング。やはりアプリケーションは自分だけで作るわけでなく共同開発をするもので、さらに後で見返してもすぐに理解が出来るように、という観点からも大事な部分だと思いました。このあたりは、リーダブルコードを読んで理解を深めていこうと思います。

JavaScript、jQuery基礎
Webアプリケーションを作る上で必要不可欠な言語。基礎的な部分のみですが難しく感じました。また、これまでの学習内容よりもさらっと流れていく印象でした。これは実際に実装していく中で覚えていこうと思います。jQueryはグーグルマップで使用されていることを知りました。画面が動くということは裏でこのような技術が使われているんだ！と思うと知的好奇心で学習意欲をより一層、高まりました。

Git、GitHub
共同開発していく上で必要なツールで、これからは課題を作成しながらメンターへ都度GitHubを用いて確認してもらいます。データの動きがイメージ出来るようになるまでは扱いが難しい。こればかりは数をこなしていくうちに頭の中で流れを理解していく必要があるなと思いました。また、初めてLGTMをもらった時の感動は忘れられないぐらい嬉しかったです。

SQL
基礎カリキュラムでもRailsでアプリを作る際はMySQLを使用していました。ではそのSQLとは？データベースとは？からその構造の操作を学習しました。多少Excelに近い印象はあったので、入りやすかったですね。レコードは行、カラムは列、まずは一つずつ覚えていこうと思います。

振り返り・感想

３週目はこれまで以上にインプットする量が多く、一つ覚えたと思ったら一つ忘れてしまうことの連続でした。それは、つまり理解したつもりになっている落とし穴にハマっているとも言えます。解決策は、何でもかんでもメモするのではなく、要点だけを抑え、覚えているうちにアウトプットをすることだと思います。アウトプットをすることで同期の人からフィードバックをもらえますし、理解しきれていないところをお互いに聞きあうこともできます。

はじめの頃は一時間おきに、なぜアウトプットをする必要があるのか不明でしたが、３週目に入り早く誰かにアウトプットしたいと思えるまでになりました。引き続き、良い習慣は取り入れ継続させていければと思います。

1. gitに関する認証情報の保存先を確認する。

   • Windows環境

     $ git config --global credential.helper
     manager
     

2. managerの場合、GCM(Git Credential Manager)に保存される。

3. GCMからgithub.comに関する認証情報を取得する。

   $ git credential-manager get
   protocol=https[Enter]
   host=github.com[Enter]
   [Enter]
   

   protocol=https
   host=github.com
   path=
   username=foobar@example.com
   password=********
   

4. GCMからgithub.comに関する認証情報を削除する。

   $ git credential-manager erase
   protocol=https[Enter]
   host=github.com[Enter]
   [Enter]
   

5. git cloneコマンドを実行する。

6. GCMの認証画面が表示される。

7. 新たに、github.comの認証情報をキャッシュする。

8. パスワードにアクセストークンを指定する。