技術覚書

自分のために技術的なことを色々と書こうと思います。

トップ > 読んでみた > 【読んでみた】いちばんやさしいGit&GitHubの教本

【読んでみた】いちばんやさしいGit&GitHubの教本

読んでみた いちばんやさしいGit&GitHubの教本 Git GitHub

こんにちは。

GitとGitHubを勉強したくてこの本を読みました。

 

目次

読んだ本

いちばんやさしいGit&GitHubの教本 人気講師が教えるバージョン管理&共有入門 (「いちばんやさしい教本」シリーズ)

いちばんやさしいGit&GitHubの教本 人気講師が教えるバージョン管理&共有入門 (「いちばんやさしい教本」シリーズ)

 

本の目次

Chapter1 Gitの基本を学ぼう 

Chapter2 Gitを使う準備をしよう

Chapter3 ファイルをバージョン管理してみよう

Chapter4 GitHubのリポジトリをパソコンに取得してみよう

Chapter5 ブランチを使ってファイルを更新しよう

Chapter6 複数ブランチを同時に使ってファイルを更新しよう

Chapter7 コンフリクトに対処しよう

Chapter8 GitHubをさらに使いこなそう 

なんでこの本を読もうと思ったの？

Git操作の復習とGitHubの理解をしたかった。

以前担当したプロジェクトのバージョン管理にGitを使ったんだけど

これがまぁ全然使いこなせなかったのでちゃんと理解したかったのと

GitHubが流行ってるからちゃんとおさえておこうと思って。

要約・ポイント

Chapter1 Gitの基本を学ぼう 

 文字通り基本的な事柄なので個人的にとくにポイントとしてはなし。

Chapter2 Gitを使う準備をしよう

２種類のGitクライアント(P.31)

Gitクライアントには、CUIクライアントとGUIクライアントという２つの種類があります。…（中略）…GUIクライアントのほうが視覚的にわかりやすいですが、種類が多く、それぞれ画面や操作方法が異なります。…（中略）…CUIクライアントを使うことで「ツールの操作」ではなく「Gitの操作」を覚えることに集中できますし、Gitでの操作をすべて利用できます。

改行について(P.36)

Windowsでは「CRLF」が利用され、macOSなどでは「LF」が利用されるので、共同開発をするときにWindowsを利用している人とmacOSを利用している人がいると、改行コードの種類が混在してしまいます。手順13*1で選択しているのはその問題を防ぐための設定です。初期設定の「Checkout Windows-style, commit Unix-style line encodings」は、Windowsのパソコンで操作しているテキストファイルは「CRLF」、Gitで管理しているテキストファイルは「LF」になるように変換します。

コマンドを実行するツールを知ろう(P.41)

…(中略)…WindowsではWindows版Gitに付属するGit Bashをオススメします。コマンドプロンプトとターミナルでは実行できるコマンドが異なるのですが、Git Bashを使えばWindowsでもmacOSのターミナルでもほとんど同じコマンドを実行できます。  

git configの結果が途中までしか表示されないとき(P.63)

ウインドウに結果が表示しきれないときはウインドウのしたに「:」が表示された状態になります。キーボード上下キーを押すことでウインドウの表示をスクロールできます。表示をやめるときは「Q」キーを押すとコマンドラインに戻ります 

Chapter3 ファイルをバージョン管理してみよう

Markdownで構造をもつ文章を書こう(P.77)

Markdownは「見出し」や「段落」「箇条書き」などの構造を持つ文章を書くためのファイル形式です。オープンソースのソフトウェアの多くは、説明のためにREADME.mdなどのMarkdownファイルをを添付しています。HTMLよりもシンプルな記述ルールになっており、手軽に構造を持つ文章を書けます。 （中略）VisualStudioCodeにもMarkdownビューワ機能がついており、Ctrl+K+Vキー*2で表示できます。

.gitignoreファイルのテンプレート(P.107)

さまざまなプログラミング言語やツールのための.gitignoreファイルのテンプレートをGitHub社がオープンソースで公開しています。.gitignoreファイルの書き方に迷ったら、こちらを参考にしてみましょう(https://github.com/github/gitignore) 

Chapter4 GitHubのリポジトリをパソコンに取得してみよう

GitHubと認証を行う方法は2つある(P.118)
  1. HTTPSプロトコル
  2. SSHプロトコル+公開鍵を用いたサーバ認証

SSHを使うには最初に設定が必要ですが、それ以降、コマンドライン上では認証のためにユーザ名とパスワードを入力する必要がなくなり、GitHubに接続する際の手順が軽減できます。また、HTTPと比較するとデータ転送を効率的に、速く行えるというメリットもあります。

フォーク機能でGitHub上のリポジトリを複製する(P.124)

GitHubはリポジトリを複製する「フォーク」という機能を提供しています。フォークを活用することで複製元となるオリジナルのリポジトリに影響を与えることなく、ファイルに変更を加えることができます。一般的なのは、共同開発をしたいリポジトリをフォークし、フォークした先で変更を加えたあと、最終的にフォーク元のオリジナルへその変更を反映させるという使い方です。 

originはリモートリポジトリを表している(P.130)

git remoteコマンドの実行結果を見ると、「origin」という文字が表示されています。これはクローン元のリモートリポジトリを表す名前です。実はGitでは、１つのローカルリポジトリに対してリモートリポジトリを複数設定できるので、それぞれを識別するために名前が必要です。クローンすると、クローン元のリポジトリにはGItが初期値としてoriginという名前を付けます。 

Chapter5 ブランチを使ってファイルを更新しよう

 プルリクエストは専用画面から作成することもできる(P.151)

先ほどのプルリクエストは、ブランチをプッシュしたら画面に表示される[Compare & Pullrequest]から作成しました(P.146参照)。実は、このボタンはプッシュから一定時間が経つと表示されなくなります*3。それ以降にプルリクエストを作りたい際は、[Pull requests]タブの[New pull request]ボタンをクリックしましょう。

今回実践したのはGitHubフロー(P.176)

Gitでは、masterに直接コミットするのではなく、別のブランチを用意して作業を進めることが一般的です。その際重要になるのが、「どんなトピックブランチを作るのか」「いつ何をきっかけにマージするのか」を定めたフローです。…(中略)…GutHubフローは、作業ごとにトピックブランチを１つだけ作り、細かい単位でサイクルを回すフローで、各作業をシンプルに管理できることが特徴です。原則として頻繁なデプロイ（アプリケーションやWebサイトを稼働・公開すること)を前提としています。  

なぜ作業ごとにブランチを使い分けるのか(P.177)
  • メリットは「作業の影響範囲を限定できる」こと。
  • 1つのブランチで複数の作業を行うと、リリースしたい機能の分の変更だけを抽出するのに苦労する。
  • 複数のブランチのうち、１つが不具合があった場合、バグのあったブランチだけ元に戻すということもできるようになる。

Chapter6 複数ブランチを同時に使ってファイルを更新しよう

チェックアウトと同時にブランチを作成するコマンド

git checkout -b branch-name

変更したファイルをまとめてステージングエリアに追加するコマンド

git add -A

マージ済みのブランチを削除する(ローカルリポジトリ)

git branch --delete branch-name または

git branch -d branch-name 

マージ状況に関わらずブランチを削除する(ローカルリポジトリ)

git branch -D branch-name

ブランチを削除する(リモートリポジトリ)

git push --delete origin branch-name または

git push origin :branch-name 

不要なブランチをGitHub上で削除しよう(P.200)

プルリクエストでブランチをマージしたときに、[Delete branch]というボタン..(中略)..をクリックすると、プルリクエストでブランチを削除できます。それ以外のブランチを削除したい場合は、[Code]タブの[●●branches]をクリックしてブランチの一覧を表示して削除します(Openなプルリクエストでマージを検討中のブランチは削除できません。)

Chapter7 コンフリクトに対処しよう

コンフリクトの発生条件を知ろう(p.202)

（中略） 

マージする２つのブランチがそれぞれ同じファイルの同じ箇所に異なる変更を加えていた場合、Gitはマージの仕方を判断することができません。

（中略）

人間がマージ後の正しい姿を判断し、手動でマージを行う必要があります。

コンフリクトを解消するために(P.218)

ファイルの種類や状況によって、コンフリクトが解消できたといえる状況は異なります。

(中略)

しかし、ゴールは１つ、「ファイルが正しい状態となる」よう編集を行うことです。(中略)…１人で判断できないときは、コンフリクトの原因となった変更を加えたメンバーに意図を確認したり、チームで相談したり、コミュニケーションを取りながら作業することが大事なので覚えておきましょう！

 Chapter8 GitHubをさらに使いこなそう 

  • 「release」：これまでのリリースバージョンを確認できる
  • 「contributors」：貢献者。masterブランチにコミットが取り込まれた人数。そのリポジトリでどれだけの開発者が関わっているかがわかる
  • 「Watch」ボタン：リポジトリの更新情報がアクティビティとして通知される
  • 「Star」の数：リポジトリの注目度の高さを表す
Issueを利用してOSSに貢献しよう(P.224)

OSSのリポジトリを見つけたら、次はそのリポジトリに対して貢献していきましょう。OSSの貢献というと、(中略)...ソースコードの追加や修正も大切ですが、ハードルが高い場合はドキュメントの追加や修正をしたり、問題を報告したりすることもOSSへの貢献になります。問題を報告するときはIssue(イシュー)というGitHubの機能を利用しましょう

感想・気づき

わかりやすい！！ストーリーに沿って作業することで流れが把握できる。

自社でhtmlやcssのワークショップをやろうと思ってるんですが、この教本を使おうかと思っています。チームでWeb画面を作って、バージョン管理もするというストーリーを考えていたのでちょうどいい！

ブランチを扱うことに対する抵抗感が少し和らいだかも

今までブランチはなるべく使わない開発の文化にいたこともあってか

ブランチを作るという言葉を聞いただけでうひぃ！！と思ってたんですが

この本を通じてブランチを切って作業することに対する抵抗感が和らいだような気がします。

それはブランチでの作業量が大きすぎた故だったんだな。小さい作業量の単位でやれば管理もシンプルになってやりやすいかも、と思ったりしました。まぁ実際の開発はもうちょっと複雑ですが、この考え方は今後も活用したいな思いました。

Chapter5でドツボにはまる

やられた。。。

Chapter5のindex.htmlを変更して保存したときにフォーマットが急に

変わって本当は修正箇所1か所しかないのに

コミットしたら大量にでてきてなんぞこれ！！！？という事象が発生。

 

直接的な原因はVSCodeで保存時のファイルを自動整形する機能が動いていたから。

メニューバーから[ファイル] - [基本設定] - [設定]で

「editor.formatOnSave」で検索すると設定がONになってた。。。おまえかー！！

設定OFFにして事なきを得ました。無駄な時間を費やした。。。

 

参考

https://book.impress.co.jp/books/1118101036

本書のサポートページ

 

Markdown記法 チートシート

Markdownの書き方がわかるやつ

 

https://github.com/ManabuHashimoto

自分のGItHubです。今回の勉強で使ったリポジトリが置いてたりします。

これからいろいろリポジトリ増やしていきたい。

*1:Gitのインストール手順で改行コードの設定を確認するところがある

*2:自分の環境ではCtrl+Shift+Vキーだった

*3:一定時間経ったからなのかどうかはまったくわからないのですが、出てこなくてなんでだろうとすごく悩んでドツボにはまりました