GitHub💍⑩～スカッシュ～

GitHubの続きをします😤

今回はスカッシュです！！

コミットIDを使って、エディタでスカッシュしていきます😊

ースカッシュー

コミットを一つにまとめる

【準備】

1.練習用のリポジトリを作成

GitHubで新しいリモートリポジトリを作成します（今回はsample0218）

2.ローカルリポジトリを作成します

3.新規ブランチを作成（masterブランチ）

4.リポジトリを関連付ける

このコマンドは、ローカルリポジトリとリモートリポジトリを関連付けるために使用されます

• リモートリポジトリの名前: origin
• リモートリポジトリのURL: https://github.com/gunkoa/sample0218

※私が練習をしやすいように、リモートリポジトリの名前「gunkoa」を「origin」に変更しました

5.追跡ブランチを設定する

このコマンドは、ローカルリポジトリの master ブランチを、リモートリポジトリの origin ブランチにプッシュし、同時にリモートリポジトリの master ブランチの追跡ブランチをローカルリポジトリの master ブランチに設定します

◎追跡ブランチとは

ローカルリポジトリのブランチとリモートリポジトリのブランチを関連付けるものです

追跡ブランチを設定すると、以下のメリットがあります

• git pull コマンドを実行するだけで、リモートリポジトリの変更をローカルリポジトリに取り込むことができます。
• git status コマンドを実行すると、リモートリポジトリの最新情報をローカルリポジトリで確認することができます。

6.ファイルを作成

以下の内容で README.txt ファイルを作成。ステージ→コミットをする

ここまでの作業で、2時間もかかってしまいました💦笑

ここからは、スカッシュを実行していきます！

スカッシュの実践

1.ファイルを作成

以下の内容で feature.md ファイルを新規作成。ステージ→コミットをする

2.ファイルを作成

以下の内容で bugfix.md ファイルを作成。ステージ→コミットをする

3.以下の内容でfinishファイルを作成。ステージ→コミットをする

これからfeatureブランチの3つのコミットを1つにまとめて（スカッシュして）、master ブランチの README.txtを追加 というコミットの後に配置するため、以下の手順を実行します

4.スカッシュ操作

featureブランチにいる状態で、コマンドで git rebase -i HEAD~<コミット数>を打ちます

今回は、feature ブランチの最新の3つのコミットをインタラクティブリベースでスカッシュします

エディタが開くので、スカッシュしたいコミットの前にある pick を squash または s に変更します

ただし、最初のコミットは pick のままにしておきます

エディタで変更を保存し閉じるとスカッシュ操作が開始し、自動的に再度エディタが開きます

そこに、スカッシュされるコミットのメッセージを編集するプロンプトが表示されます

しかし、私は間違えてコミットのメッセージを編集せずにエディタを閉じてしまいました😅

そのため、再度エディタを開くためにこちらのコマンドを打ちます

エディタが再度開き、スカッシュされるコミットのメッセージを編集するプロンプトが表示されました

通常、すべてスカッシュされるコミットのメッセージが表示されるので、ここで必要な情報を含む1つのメッセージにまとめることができます

新しいコミットメッセージを編集し、変更を保存するとエディタが閉じます

(今回は「新機能を追加できました」にします)

スカッシュ操作が完了し、新しいコミットメッセージが設定されました

これで feature ブランチの最新の3つのコミットが1つにスカッシュされました！

ここからは、feature ブランチの変更を master ブランチにスカッシュ（1つのコミットにまとめ）をします

5.master ブランチにチェックアウトし、feature ブランチの変更を master ブランチに統合します

スカッシュされた変更をコミットします

ここでエラーが出てしまいました😱😱

原因をChatGPTに聞き、抜粋⇓

’’メッセージの最後の部分 nothing to commit, working tree clean は、現在の作業ツリーにコミットするための新しい変更がないことを示しています。

つまり、あなたが feature ブランチで何らかの変更（ファイルの追加、変更、削除など）を行い、それをステージングエリアに追加した後でなければ、新しいコミットを作成することはできません。

したがって、このメッセージは、新しいコミットを作成しようとしましたが、現在の作業ツリーには新しい変更がないため、コミットは作成されなかったことを示しています。新しいコミットを作成するには、まず何らかの変更を行い、それをステージングエリアに追加する必要があります。’’

ということなので、

feature ブランチにチェックアウトします

新しいファイルを作成。ステージ→コミット

master ブランチにチェックアウトします

featureブランチの新しい変更を、 master ブランチにマージします

スカッシュされた変更を新しいコミットとして master ブランチに追加します

先程featureブランチで新しく作成したファイルを、masterブランチにもマージします！

Git Graphで確認すると.......

スカッシュとマージができました！！！😭✨

ちなみに、コミットIDを使ってエディタでスカッシュをする他にも下記のやり方があるそうですが、安全面を考えてこちらのやり方は操作しないほうがいいのかなとかんじました！

git merge --squashで実行するスカッシュ

「git merge --squash」まとめ

• 「git merge --squash」**は、ページをまとめる。
  • メリット: 見た目が綺麗になる。
  • デメリット: 綺麗にまとまるが、後から「やっぱりあれが良かった！」と思っても、元に戻すのが難しい。

• 「viを使ってコミットIDを指定」**は、コミットを写し書きするようなイメージ
  • メリット: 元々の状態は残るので、いつでも元に戻せる。
  • デメリット: 手間がかかる。

ロードマップを武器に、差別化戦略！！🐻‍❄️

ChatGPTが出たことでIT業界がさらに急成長と技術の変化をしたことで、私もその1人ですが、一層エンジニアへ転職したいと夢を膨らませる人たちがいます😊

情報が多すぎてどれを選べばいいのか分からず、不安と焦りでいっぱいでしたが、フロントエンドエンジニアに転職をするとゴールを決めて、今まで勉強をしてきました✨

市場価値が高いプログラミングは数年前からブームで、プログラマーになりたいと思う人達の人数と比例して、プログラミングスクールも増えてきました

プログラミングスクールやオンラインコースは、基礎から学べる良い場所ですが、時には個々のニーズに合わないこともあります

だからといって、これらの学習方法が悪いわけではありません

むしろ、多くの人にとっては非常に有効です

ですが、私の場合すぐ指導して頂ける環境の中にいると、それに甘えて継続的な学習を進められません笑

そのため独学で学習することを選びます💡

（金銭面が厳しいという理由もありますが）

自分で計画を立て、実行し、問題を解決していくような、多少プレッシャーを感じる環境のほうが私に合っているかもしれないと思っていました😼

しかし、最近は未経験でも高い技術を求められているため、今のままでは私が求めている企業に就職ができないかもしれないと焦りを感じていました💦

たくさんのエンジニアの方達の情報をキャッチして、転職を成功するために必要なことは周りとの差別化だと気付きます💡

そこでもう一度計画を練り直し作ったのが、『フロントエンドの学習ロードマップ』です！

まず、企業が求めるフロントエンド技術を徹底的にChatGPTを活用し、最新のトレンドや（フレームワーク、データベース、バックエンドなど）各企業の採用情報から、必須スキルと有利なスキルを洗い出しました😤

IT未経験という壁は高いですが、差別化戦略と継続的な学習で、目標達成に向けて突き進んでいきます！！

GitHub💍⑨～リバート、リベース～コンフリクト大量発生😅

今日も学習したことをまとめていきます！！

今回は、リバートとリベースについてです！！

ーリバートー

間違った変更を元に戻すためのコマンド

過去のコミットを修正し、その履歴を残せるため、安心してコードを以前の状態に戻せる

間違った変更をしたとき、リバートを使うとそのコミットを消すことはできますが、

ただ削除するだけでなく、その間違いと、それを直したことは、記録として残ります

 

 

わかりやすく書きましたが、私はこれを理解するのにとても時間がかかりました😅

 

 

しかし、現場で実際にどのようにリバートを使われているのかを調べたことで少しずつイメージが掴めてきました

 

 

例えばですが、

新しくリリースしたソフトウェアにバグが見つかったとき、そのバグが存在していない過去の安定した状態に戻してから、バグ修正を行うことがあるそうで、ここでリバートを使うとバグのない状態から安全に作業を進めることができます

 

 

また、新しく追加した機能が何か問題を引き起こした場合や、あとからその機能が不要になる場合もリバートを使います

その機能を追加したコミットをリバートすることで、機能を安全に削除し、コードを元の状態に戻すことができます

 

 

このような状況でリバートを使うことで、問題のある変更を取り消しつつ、何が起きたかを履歴に残すことができるので、あとから問題の原因を追跡したり、同じ間違いを繰り返さないようにすることができるということなんですね！！

ここからは、sample0211フォルダのokonomi.txtを使って実際にリバートします😊

ー手順ー

1. 適当な変更をする
2. 変更をコミットする
3. コミットハッシュ値を確認する
4. リバートを実行する
5. エディターを編集
6. コミット履歴を確認する

1. 適当な変更をする

何かファイルに変更を加えます

例えば、テキストファイルに「こんにちは」という一行を追加して保存します

2. 変更をコミットする

変更をステージしてコミットします

3.コミットハッシュ値を確認する

コミットした後、git logを使ってそのコミットのハッシュを確認します

ここで表示される最新のコミットのハッシュ値をメモします

4.リバートを実行する

メモしたコミットハッシュを使い、git revertコマンドでリバートを実行します

 

 

5.エディターを編集

エディターが開くので、もしコミットメッセージを編集したい場合は、メッセージを打ち込み編集してキーボードで保存します

【保存の仕方】

Control key＋O[書き込み]　⇒　Enter key  ⇒　Control key＋X[終了]

 

 

6.コミット履歴を確認する

リバートが完了すると、新しいコミットがリポジトリの履歴に追加され、git logで確認することができます

リバートが成功していれば、最新のコミットとして「Revert "元のコミットメッセージ"」というメッセージのコミットが表示されます

このコマンドを実行すると、d6e88f06b04eae9b0f103c1dfbe865041d1a87d7（あいさつのIDコマンド）という過去の変更を消すための新しい変更が記録されました

これで、コードは間違いをした前の状態に戻りますが、何があったのかは履歴に残るので、後で確認することができます

ーリベースー

あるブランチの変更を別のブランチに移すための機能

これは、ブランチの変更履歴を整理したり、変更が衝突したときにその衝突を解消するために使う

 

 

例えば、新しい機能を作っているbuttonブランチで作業をしていて、その間にmainブランチに新しい変更が加えられたとします

この新しい変更をbuttonブランチにも反映させたいとき、リベースを使います

 

 

リベースを使うと、buttonブランチはmainブランチの最新の状態から新しく始まり、その上にbuttonブランチで行った変更が適用され、buttonブランチはmainブランチの最新の変更を取り込んだ状態になります

ただし、リベースは過去の変更履歴を書き換える操作なので、他の人と共有しているブランチに対しては慎重に使う必要がありそうです

他の人と共有しているブランチに対してリベースを行うと、他の人の作業を混乱させる可能性があるので、慣れないうちはマージを使ったほうがいいとのことです

 

では、ここでも引き続きokonomi.txtファイルを使って実践します！

ー手順ー

1. 新しいブランチを作成する
2. ファイルを変更する
3. 変更をコミットする
4. メインブランチに切り替える
5. メインブランチのファイルを変更する
6. 変更をコミットする
7. add-ingredientブランチに切り替える
8. リベースを実行する

1.新しいブランチを作成する

まず、新しい機能を追加するためのブランチ（ここではadd-buttonとします）を作成して移動します

2.ファイルを変更する

次に、okonomi.txtに新しい材料を追加します

3.変更をコミットする

 変更をステージ⇒コミットします

4.メインブランチに切り替える

mainブランチに切り替えます

5.メインブランチのファイルを変更する

mainブランチでokonomi.txtを変更します

6.変更をコミットする

 変更をステージ⇒コミットします

 

 

7.add-buttonブランチに切り替える

再びadd-buttonブランチに切り替えます

 

8.リベースを実行する

mainブランチの変更を、add-buttonブランチに適用します

 

すると、コンフリクト発生！！

 

 

mainブランチと、add-buttonブランチのokonomi.txtファイルで、同じ行、同時に別々の修正をしたため、コンフリクトが発生です

（いろいろと変更しすぎました😅）

 

 

これから、コンフリクトを解消します

⇓

 

変更をステージ

 

コンフリクトを解消したら、リベースを続行します

 

 

リバートの時と同様、エディターが開いたので、メッセージを書いて終了します

 

これで、リベースが続行されてコンフリクトが解消されました

 

ということで、1．新しいブランチを作成するはスキップして、

ファイルを変更する

変更をコミットする

メインブランチに切り替える

メインブランチを変更する

変更をコミットする

add-ingredientブランチに切り替える

リベースを実行する

を実行します！

すると、またコンフリクト発生！！😱

Chat GPTに原因を聞いたところ、

「一つのコミットでコンフリクトが解消されても、次のコミットで再びコンフリクトが発生することがあります」

だそうです😭

もう一度コンフリクト解消します！

コンフリクト解消したあとの、add-buttonブランチのokonomi.txt

メインブランチに切り替える

メインブランチのファイルを変更する

変更をコミットする

add-ingredientブランチに切り替える

リベースを実行する

をもう一度繰り返し！

 

 

 

 

 

 

 

 

 

 

…するとまさかの、コンフリクト発生してしまいました😢😢😢😢

 

 

原因が分からず2時間以上頭をかかえました…

 

 

先が進まないのでパスタさんに助けを求めます💦

 

 

 

そこでアドバイスして頂いたのは、

 

 

VScodeの左サイドバーの、①と②をクリック

「変更のマージ」をクリックする

画面に”現在のマシンを適用”と、”受信中”が表示されるため、今回は”現在のマシンを適用”を選択する

画面の真ん中あたりにある「マージの完了」のボタンをクリック！

コンフリクト解消されました✨

最後に、リベースを続行して完了させることができました😭😭

流れがぐちゃぐちゃですみません😱

リベースはエラーばかりでかなりの時間がかかってしまいましたが、たくさん失敗してどんどん成長していきたいです！！

 

 

GitHub💍⑧～過去に戻って、新しく作業をやり直す～

今日のGitHubの学習をまとめます！！

今回は、

Gitで特定のコミットを指定して、新規ブランチを生やして作業をやり直す方法を覚えました！！

ー手順ー

1. ターミナルでgit logコマンドを実行して、コミット履歴を確認します。
2. 戻りたいコミットのハッシュ値を確認します。
3. git branchコマンドでブランチを新規作成、git checkoutコマンドで移動します。
4. 新しいブランチで作業を行います。
5. 作業が終わったら、git addコマンドで変更点をステージし、git commitコマンドでコミットします。

昨日作ったsample.0211フォルダのokonomi.txtを使っていきます💡

まずはVScodeのターミナルを開いて

Gitリポジトリがあるディレクトリ（sample0211）に移動して以下のコマンドを実行します

コミットのリストが表示され、各コミットの先頭にハッシュ値が表示されます

今回はokonomi.txtファイルの「コーラを入れます」の前に戻りたいので、

（「具材を追加」はコミットの内容を表すメッセージ）

コミットIDを指定して、新規ブランチ「butatama」を生やします

butatamaブランチへチェックアウトします 

 okonomi.txtに「豚肉を追加」を追加

 okonomi.txtをステージし、コミットメッセージを入れてコミットします

※「豚肉を追加」ではなく、「具材を追加」でした

ブランチを分岐させることができました！！ 

ーまとめー

この方法は、過去のある時点のコードに戻って新しい機能を追加したり、バグ修正をしたりしたいときに便利だと気付きました💡

例えば、リリース後にバグが見つかっても、そのバグが存在しない古いコミットがある場合、そのコミットから新しいブランチを作成してバグ修正をし、修正した後のコードを現在のコードに統合することができます

これにより、バグのない状態から安全に作業を進めることが可能になります！

簡単に例えるなら、

学校から絵を描く宿題が出される。好きな絵を描く😚

⇓

絵が完成した後に飲み物をこぼして汚してしまった😱

⇓

絵を、飲み物をこぼす前の状態に戻したい....😥

明日提出なのに最初から描く時間がない😢

⇓

近くにきれいな絵があった！

しかも、飲み物をこぼす直前まで描いてある！！😭✨

⇓

途中から描いてあるきれいな絵があるなら、そこから描ける！！

⇓

完成！！提出日に間に合った～😆

過去に戻って新しい作業をする方法ということですね！！

この記事を書いている途中で下書きをせずにパソコンを再起動させてしまったので、データが消えてしまいました笑

基本的なことですが、前に下書きをしないとですね😅

転職をしたらこのようなことが起こらないように絶対に気を付けます😤

GitHub💍⑦～VScodeでリポジトリ作成～

GitHubの勉強を始めたばかりは参考書通りにしようとSourceTreeで操作していましたが、これからはVScodeで開発をしていくので、途中でSourceTreeからVScodeへ切り替えました😊

VScodeでリポジトリを作ったことがないので、復習をしながら進めていきたいと思います！！

まずは、バージョン管理を行いたいディレクトリ「sample0211」をローカル（VScode）で作成します💡

その後にGitHubでリポジトリ「sample0211」を作成⇓

sample0211のURLをコピー⇓

VScodeのターミナルで、GitHubからVScodeへクローンする⇓

「ファイル」→「フォルダを開く」→「sample0211」のファルダを開く

ファルダの中身は空っぽのため場面は真っ黒⇓

（「.git」フォルダは隠れているため表示されない）

「新しいテキストファイル」より新規ファイル作成

名前(okonomi.txt)をつけて、保存⇓

内容を入力して、保存⇓

ステージ→コミットをする⇓

コミットが記録されました！！

このままさらにファイルに変更を加えます💡

テキストファイルを追加⇓

ステージ→コミット⇓

さらにさらに変更を加えます！😤

テキストファイルを追加⇓

ステージ→コミット⇓

3回連続コミットができました！！😆✨

SourceTreeとやり方が違うのでかなり苦戦しました😭

ですが、

GitHubでリポジトリの作成の仕方を習得です！！✨

GitHub💍⑥～プルリクエスト、.gitignore 、Sync fork編～

 GitHubの続きです！！

ープルリクエストをする！！ー

プルリクエスト

自分がした変更を取り込んでもらうように提案すること

まずはプルリクエストの練習用リポジトリをフォーク→クローンをします

Ubuntuでクローンをする⇓

Git Graphでコミットログが表示されたのでクローン成功！！⇓

ここからは以下の流れで進めます！

• 作業用のブランチを作成して自分用のテキストファイルを追加
• ファイルを保存→ステージ→コミット
• プッシュする
• GitHub上でプルリクエストを作成する

GitHubでプルリクエストを作成した時に、「Compare & pull request」というボタンが見当たりませんでした💦

しかし、プルリクエストができる別の方法がリンクが貼ってあったので、そこからとんで手順通りに進めたらプルリクエストができました😊

レビューされたコード⇓

ーバージョン管理しなくてもいいファイルを無視する！！ー

バージョン管理したくないファイルやディレクトリがある場合、「.gitignore」というテキストファイルを使うと、Gitで管理しないファイルを指定することができる

「.gitignore」ファイルを新規作成→編集→ステージ→コミットをする

ファイルをコマンドで書き込んで編集⇓

コミットした結果！！⇓

「.gitignore」に無視したいファイルを追記できました！！

ー親リポジトリ上のコミットを簡単に取り込む！！ー

親リポジトリ（フォークされたリポジトリの元となるリポジトリのこと）のコミットが進んでしまい、自分のリポジトリのコミットは古いまま…

でも、GitHubの機能で親リポジトリのコミットに追いつける！

GitHubの左サイドバーのRepositoriesのリポジトリを選択

下のボタンをクリック⇓

※参考書では「Fetch upstream」と記載

GeminiでFetch upstreamとSync forkの違いを聞いてみました💡

（今日始めて知ったんですけど、BardはGemimiという名前に変わったんですね✨）

ということなので早速Sync forkをクリックすると、私のリポジトリの場合、最新であるため親リポジトリのコミットを取り込んだ実感はありませんでした😅笑

機会があれば、この機能を活用したいと思います！！

今日はここまで！！

GitHub💍⑤〜コンフリクト編〜

GitHubの続きです！！

ーコンフリクトを解決する！！ー

わざとコンフリクトをさせるために、新しくupdete---newsブランチを作成します

index.htmlを開き、「開催日未定」を「5月5日」に修正

修正が終わったらファイルを保存→ステージ→コミットをします

masterブランチにチェックアウトし、「開催日未定」を「5月7日」に修正

ファイル保存→ステージ→コミット！

Git Graphで確認すると、ブランチが分裂して分かれている状態になりました！

masterブランチにupdete---newsブランチをマージします

すると、コンフリクト発生！！

index.htmlのエディタを開くと<<,==,>>の記号があるのでそれを消して、正しいソースコードだけ残します

修正前⇓

修正後⇓

ファイルを修正したら、ステージ→コミットをします！

そしてGit Graphで確認すると、マージコミットが作られてあります！！⇓

無事、コンフリクトを解決です！！！😆

正直言いますと、１回目でまた色々と操作を間違えてしまいどのように対処をしたらいいのか分からなくなってしまったので、ブランチを作り直し、2回目再チャレンジしたらうまくできました笑

次はあまり時間をかけずにどんどん進められるように頑張ります‼︎