ご無沙汰しています！Blogを再開します✍️
こんにちは😄プログラミングの学習中のFuushi−です🙇🏻♂️
久しぶりの投稿になります😄せっかく開設したブログを全く活用していなかったので、再開しようと思います🙇🏻♂️
今年は自分にとってもチャレンジな年にしたい...🐯 『自分の人生は自分の意志で決めて行く』
その為に2年前から初めている『朝活』の継続はもちろんの事，今年は『結果を出す』ことも意識していきたいと思います✍️
ブログは学習のアウトプットを中心に『思い』や『感じた事』を書いていこうと思います。
まずは『毎週1記事を書く』事を1か月やり抜きます✍️
ではでは👋
〜学びは人生を豊かにする✍️〜
行動することの意味...
こんにちは😄プログラミングの学習中のFuushi−です🙇🏻♂️ 1月23日にFJORD BOOT CAMP（フィヨルドブートキャンプ）で開催された、初心者のための発表会「⚡️初めてのLT会 Vol.6」に参加・登壇させて頂きました。 LT会自体は何度か聴講専門で参加した事はありましたが、登壇して発表したことはなかったので、今回は人生で初めてLT会で発表した感想を書いていきたいと思います😄
LT会って？🤔
まずは、LTって何？という方もいらっしゃると思うので、簡単に紹介させて下さい😄 LTとはLightning Talks（ライトニングトーク）の略で、「短いプレゼンテーション」のことです。 基本的にルールはなく、決められた時間内だったら何を発表してもOK！どんな風に発表してもOKというスタイルのようです😄
LT会に参加しようとした理由💪
きっかけはフィヨルド内での「初めてのLT会 Vol.6」のお知らせがあり、最初は聴講で参加をしようと考えていました。ただ、以前参加したある企業様の会社説明会で 「アウトプットする」事の大切さの話を聞きました。それまで、あまりアウトプットする事をしていなかったので、まずはやってみようかなと思い、登壇を決意しました💪
学び✍️
発表してみて直感的な感想は「楽しかった」😁です。確かにスライド作成や発表練習と時間を割かなければいけませんが、 「人前で発表する」 「アウトプットする」事にはメリットが３つあると感じました。
①より深く理解できるようになる
➡️人前で話をするので、間違えた事を発表するのは…という気持ちで色々調べて理解を深める事ができました✍️
②スライド作成スキル、話し方スキルの学習ができる
➡️見やすいスライドや聞きやすい話し方を意識するようになりました🎤
③自分という存在を認知してもらえる
➡️このご時世、リアルでのコミュニケーションが制限される中、オンライン上でのコミュニケーションをとる事が多くなってきているように感じています。 今回は参加しているコミュニティ内での発表ではありましたが、皆さんと顔を合わせて話をする機会にあまり参加できていなかったのでこのような場で 「顔出し」「声出し」して発表する事で、皆さんに認知してもらえやすくなると思いました😄
感想😁
今回はTL会に登壇した感想を書いていきました。「人前で登壇する」という事は、普段人前で話をしたり、やった事がない人からすると、かなりのハードルだったりプレッシャーに感じると思います🤔今回はオンライン上でしたが、これがリアルの場で顔の見れる場での発表であれば、緊張で倒れていたかもしれません🥺笑
でも久しく感じていなかった「大きな達成感」を感じる事ができました😄 少しの勇気ときっかけ、仲間の後押しで「登壇して発表する」という行動をとる事ができました😄 この行動により、多くの気づきや学びを得る事ができ、また一つ、成長できたと感じています💪
感謝🙏
今回の登壇において、多くの方々から応援のお言葉やアドバイスを頂きました❗️感謝しております🙇🏻♂️改めて、コミュニティーに所属する大切さや仲間の存在に 気づく事ができました😁発表以上に得るものの多かったと感じています😄今後も積極的にイベントに参加していきたいと思います😄
バージョン管理ツール「Git」について
おはようございます😄プログラミングの学習中のFuushi−です。
今回はフィヨルドブートキャンプ内で実施しているアドベントカレンダー2020用に書いた記事になります😄
Part 2もあります✍️
フィヨルドブートキャンプ Part 2 Advent Calendar 2020 - Adventar
「フィヨルドブートキャンプ Part 1 Advent Calendar 2020」の5日目の記事です。
昨日記事はima1zumiさんの 初学者が Ruby on Rails の広大さに途方にくれたけどなんとかやっていけるようになった話 でした😃
ima1zumiさん記事を拝見して共感した点は下記部分です🤔
結局は自分で手を動かして、悩んだり苦しんだりしないと、本やサイトを読んだだけでは、あまり理解できないのかな、と思いました
エンジニアに必要な自走力を高める上で必要が考え方だと思いました✍️
それでは，本題に入ります🙇🏻 本日はエンジニアとして仕事する上で，必須の必要知識である『Git』についてまとてみたいと思います。実務経験はないですが…😅 エンジニアの仕事は一人で行う事は少なく、チームでの共同開発が前提となるのでGitは欠かせない知識となっています。
（いくつかの「エンジニアコミュニティ」に参加していますが、どのコミュニティでもGitの知識の必要性を聞きます）
今回の記事では３点に絞って書きたいと思います。
・Gitとは？
・Gitの使うメリット
・Gitのコマンド・基礎操作
主に初学者である僕のアプトプット用、復習用で書いていきます。
それでは、スタートです✍️
【目次】
1.Gitとは
Gitの歴史
Linuxの開発者の一人であるリーナス・トーバルズ氏が開発したバージョン管理システムです。アプリケーションが動作するための基本環境であるLinuxカーネルを開発する際に、コンピュータのソースコードのバージョン管理システムであるBitKeeperを使用して管理していたが、BitKeeperを開発していた企業との間の協力関係が悪化を機に、Linux開発コミュニティとLinuxの開発者の一人であるリーナス・トーバルズ氏が独自のバージョン管理ツールの開発してできたのが「Git」である。
GitとGitHub
GitとGitHubは関連性のあるサービスであるが、別々のサービスです。それぞれの特徴を紹介します。
【Git】
ファイルのバージョン管理を行うツールの１つ。バージョン管理とは変更履歴を管理する事です。 Gitで管理することで、自動で「編集者」 「編集日時」 が保存される為、ファイルが「いつ」 「誰によって」 「どこに修正があったのか」 がすぐに把握できる事が出来る。
Gitを使用することによって、変更履歴をさかのぼってコードを元の状態に戻す事もでき、GitHubとの連携で複数人での共同開発が可能。
【GitHub】
「Gitを利用した開発者を支援するWebサービス」。クラウド上でGitを用いたバージョン管理をすることができ、 チーム開発を行うための機能などを提供する。
Gitの基本的な用語
Gitを使用する上で、必要な用語をいくつか紹介します。
| リポジトリ(repository) |
|---|
| Gitで管理する対象になるディレクトリやファイルを管理する場所 |
| イニット(init) |
|---|
| リポジトリの新規作成 |
| ローカルリポジトリ(local repository) |
|---|
| 自身のPC内にあるリポジトリ |
| リモートリポジトリ(remote repository) |
|---|
| リモートのサーバー内にて、管理や共有する為のリポジトリ(GitHubなどにあるリポジトリ) |
| ワークツリー(work tree) |
|---|
| 自分が作業している場所。リポジトリ配下のファイルを編集して自動的に保存される場所(コミット対象ではない) |
| インデックス(index) |
|---|
| 編集したファイルをコミットする前の仮確定して置いておく場所(コミット対象) |
| コミット(commit) |
|---|
| リポジトリに編集内容を記録する事 |
2.Gitの使うメリット
僕が学習する中でGitを使うメリットは主に３つあると感じました。 他にもありますが、とりあえず３つについて紹介します。
①変更履歴を追跡(前バージョン(保存データ)に戻れる
変更履歴の追跡...バージョンに管理...バージョンを戻す...??? 初学者の僕は始めの頃は？？？でした。調べれていて、しっくりくる説明は多くの記事で出てくる「セーブポイント」です。ドラクエやFF、ポケモンなど、RPGゲームをやった事のある方なら、イメージしやすいと思います！ ただゲームのセーブポイントの概念と違うところは「過去のセーブポイント」へ戻れる点です。
例えば、初代ポケモンではサワムラー」or「エビワラー」「オムナイト」or「カブト」など選択する場面があったと思います。1度は選択前にセーブして、どちらを選択するか考えに考えた方も多いと思います。一度選択してストーリーを進め、ジムリーダーとの戦い前にセーブしてしまうと前のセーブ(「サワムラー」or「エビワラー」「オムナイト」or「カブト」など選択する場面)へ戻る事はできません… バージョン管理ツールであるGitはそれができてしまうイメージです！ゲーム内のセーブがGitであればですが...
ソースコードはGitで管理する事でcommitした保存データに遡って戻す事ができます。こうする事で作業を進めていく上で、「やっぱり昨日の実装の方が良さようだ」となった場合に、コードを消して一から書き直すのではなく、戻したいコードの保存履歴に戻れば瞬時に変更が可能になり、作業効率もUPできます。
②変更履歴を記録(いつ・誰によって・どこに修正があったのかがすぐに把握できる事が出来る)
「この変更いじったの誰や〜」 「どこを変更したんや〜」 と１つのファイルを共有して管理していると何度も思ったことでしょう！
例えば、ExcelやWordなどを共同で管理していた場合など…
Gitではcommitした段階で、「どこを変更したのか」 「編集者」 「編集日時」 が自動で記録されます。
git log コマンドでコミットした内容が確認できます！
③共同開発が可能
GitHub上のリモートリポジトリを個人PC上のローカルリポジトリを連携する事で複数人で開発が可能となります。後ほど詳しく流れを紹介します。
3.Gitの基礎操作
【Gitコマンド】
| git init |
|---|
| ローカルリポジトリを作成するコマンド |
| git add(git add ./ファイル全て)(git add ファイル名/指定ファイルのみ) |
|---|
| ワークツリーにあるファイルをインデックスに移動させるコマンド |
| git reset |
|---|
| インデックスに追加したファイルをワークツリーに戻すコマンド |
| git commit(git commit -m”メッセージ”) |
|---|
| ローカルリポジトリの変更内容を保存。コミットメッセージを入力 |
| git log |
|---|
| コミットログを確認するコマンド |
| git status |
|---|
| ワークツリーとインデックスにあるファイルの状態を確認するコマンド |
| git branch |
|---|
| ローカルリポジトリにあるブランチの一覧と現在選択中のブランチを確認 |
| ◆ブランチのリスト表示(git branch) |
| ◆ブランチの新規作成(git branch ブランチ名) |
| ◆ブランチの削除(git branch -d ブランチ名) |
| git checkout ブランチ名 |
|---|
| ブランチの切り替えコマンド |
| git checkout -b ブランチ名 |
|---|
| ブランチの作成とチェックアウトを同時に行うコマンド |
| git clone URL |
|---|
| リモートリポジトリをローカルリポジトリにクローンする |
| git push |
|---|
| コミット済みファイル(ブランチ)をリモートリポジトリ(Github)内のリポジトリ(origin)へ反映させる |
| git pull |
|---|
| リモートリポジトリから変更内容(履歴)を自分のローカルリポジトリに反映させること |
Gitの基本操作①【〜ローカルリポジトリ作成からコミットまで〜】
①対象ファイルのローカルリポジトリを作成
git init
⬇️
②ファイルをコミットする為に作業中のワークツリーからインデックスへ移動
git add
※git reset→ インデックス→ツリーワークへ戻す
⬇️
③変更内容を保存。コミットメッセージ記述。
git commit -m”コメント”
※コミットの確認 git log / qコマンドで終了
Gitの基本操作②【 〜コミットからリモートリポジトリへpushまで】
⬇️
②コミット済みのフォルダのあるローカルリポジトリと作成したリモートリポジトリの紐付けを行う
git remote add origin URL
※URLはリモートリポジトリを作成時にできたURL
※「origin」→設定したリモートリポジトリの１つ
⬇️
③紐付けが完了したら、ローカルリポジトリ内の編集済みブランチをリモートリポジトリへ反映させる
Git push <リモート名> <ブランチ名> / git push origin master)
Gitの基本操作③【〜共同開発編(クローン、ブランチ、プルリク、マージ)】
共同開発には、リモートリポジトリ【共同開発を行うディレクトリ(ファイル)】からローカルリポジトリ【自分のPC内】へ
コピーをしてから各自が作業を行う。その際に必要になるのが、クローン(git clone)コマンド
※cloneを間違えたら、[cd ..]で戻り、rm -rf ファイル名で削除
[クローン]
①リモートリポジトリをクローンする
git clone URL
※URLは共同開発するリモートリポジトリのURL
⬇️
②cdコマンドにてクローンして作成されてディレクトリへ移動する
cd <対象ディレクトリ>
※lsコマンドで作成されたディレクトリ内のファイルを確認する(ちゃんとクローンできているか確認)
[ブランチ作成〜編集・push]
①ファイルを編集する為、コピーしたファイル(masterブランチ)から編集用ブランチを作成する
git checkout -b new_branch名
⬇️
作成した編集用ブランチ(new_branch名)を編集していく。
⬇️
②編集が終了したら、ファイルをコミットする為にインデックスへ移動
git add .
⬇️
③変更内容を保存。コミットメッセージ記述。
git commit -m”コメント”
⬇️
④コミット済みファイル(ブランチ)をリモートリポジトリ(Github)内のorigin(リポジトリ)へ反映させる
git push origin <編集済みブランチ名>
※リモートリポジトリを確認するにはgit remoteで確認する
⬇️
⑤pushするとローカルリポジトリ(github)にコミット済みファイル(ブランチ)が作成される
[プルリク]
プルリクとはローカルリポジトリでの変更した内容をGithub上で他の開発者に通知し、コードレビューなどを行なってもらう。
①Github上の「コミット済みファイル(ブランチ)」のCompare & pull requestをクリックして、レビューのお願いを通知する。
⬇️
②コメント記載後、Create pull request をクリック
※どのブランチに対してpull requestをするのかを確認すること。
[マージ]
マージとは変更内容をmasterブランチへ統合する。 変更内容を一つのブランチにまとめる。
コードレビューが終わったらmasterブランチ(ローカルにコピーした大元のブランチ)に対してマージを行う。
①Merge pull request → Confirm merge の順でクリック
⬇️
②Delete branchをクリックで削除
※マージが終わったら、コミット済みファイル(ブランチ)は必要ないので削除する
[プル]
プルとは、リモートリポジトリから変更内容(履歴)を自分のローカルリポジトリに反映させること
①ローカルリポジトリのブランチをmasterブランチへ切り替え
git checkout master
⬇️
②リモートリポジトリのmasterをローカルリポジトリのmasterへpull(反映)させる
git pull origin master
※以前のローカルのブランチは削除する
git branch --delete [ブランチ名] git branch -d [ブランチ名]
※マージ済みのブランチのみ削除ができる。
マージされていないブランチを削除したいときはgit branch -D [ブランチ名]
今回は以上になります。まとめて記事にする事は頭の整理になりますし、間違えのないように調べる為、 良いアウトプットになると感じました。自分なりに調べて図解を作成し、理解を深めたつもりです。 もし、間違えなどございましたら、コメントにてご指摘頂けますと幸いです。
参考資料
自己紹介
皆様、初めまして。 Fusshi-と申します。人生で初めてこのような形で学んだ事をアウトプットをする事を決めました✍️
お恥ずかしながら、特段、勉強ができる訳でもなく、スキルというものもなく、35年間、真面目に平凡な人生を送ってきました。決して今の生活に不満がある訳ではありません。
しかし、今後の人生・生活に不安に感じ、将来の働き方や生活について考えるようになり、学ぶ事を始めました。現在はプログラミングを中心にマネーリテラシーを上げる為に学んでいます✍️
現在は下記のコミュニティに参加させて頂き、学習しています💻
【大名エンジニアカレッジ】
daimyo-college.pepabo.com
【フィヨルドブートキャンプ(研修生)】
bootcamp.fjord.jp
【リベラルアーツシティ(リベシティ)】
不定期ですが、はてなブログでは学びのアウトプットの場として活用していきたいと思います🙇🏻♂️
宜しくお願いいたします🙇🏻♂️
