Git&GitHub

読み飛ばしてOKのまえがき 現在、私はFlutterでアプリ開発にチャレンジしています📱 その開発内容もgit＆githubで管理していきたいなと思いました。アプリ開発をしているのは、iPhoneの実験もしたいことから、Mac機を使用しています。環境構築済みのWindows機ではないので、新たに環境構築が必要となります。 一度、Git＆Githubの本で一通り実施したので、それ程詰まらずに進めることができるだろうと思っていたのですが、思ったより時間を要してしまいました。 今後も新たなPCでGit＆Githubの環境構築をすることがあると思いますので、その方法をまとめておきたいと思います。 注意事項？ 全てCLI前提（Mac標準搭載のターミナル）で書いていきます。M1💻と記載しましたが、Apple silicon系であれば内容は同じと思われます。また、Windowsでも、パッケージマネージャー入れたり（必須ではない）、コマンド実行したり、流れや内容は概ね一緒かと思います。 実行手順 Homebrew🍺をHPにアクセスしてインストールする。PATHが追加されていない場合（インストール時にwarningが出る）、Users/ユーザー名/に.zshrcを作成する。.zshrcにexport PATH=/opt/homebrew/bin:$PATHを追記する。下記を実行して、追記内容を反映させる。 ※インストールしただけではPATHが登録されないのはM1の仕様みたい。 ※Homebrewインストールの参考ページ →Homebrewのインストール source .zshrc 下記を実行してバージョン情報が確認できれば問題なし。 brew -v 下記でパスの設定状況を確認するのも良い。 echo $PATH gitをインストールし、ユーザー名とパスワードを登録する（Githubと合わせる必要は特段無い）。下記を実行。 brew install git git confg -- global user.name ユーザー名 git confg -- global user.email メールアドレス 下記を実行すると、設定した内容を確認できる。特に問題なければOK。 git config --list Githubをリモートリポジトリに設定する為に、SSH Keyを設定する。任意のフォルダ（ユーザー名/など）で下記を実行して秘密鍵/公開鍵を作成する。-c "内容"を追記して実行すると、鍵にコメントが追記できる。コメントとしてメールアドレスを追記する作法があったようだが、特段必要は無いと思われる。-f "内容"を追記して実行すると鍵のファイル名を設定できるが、これも必須では無い。ファイル名を設定した場合は.sshフォルダ configファイルを作成してファイル名等を記載する必要がある。 ※ed25519は暗号化の種類。 ssh-keygen -t ed25519 鍵の置き場所を聞いてくるので、カレントディレクトリで問題無ければそのままENTERを押す。設定するパスフレーズを2回入力する。 ※パスフレーズはパスワードの対応文字数が多いバージョン。また、文字にスペースを設定可能。尚、フレーズ=単語を入力しろということではない。 ディレクトリ内にid_ed25519（秘密鍵）とid_ed25519.pub（公開鍵）が作成されていればOK。公開鍵の内容をコピーするために下記を実行する。Finderで直接開いて、内容をコピーしても同じ。 pbcopy < id_ed25519.pub GitHubにアクセスして、Settings→SSH and GPG keys→New SSH keyをクリック。TitleにはPCの種類等を記載して、Keyには公開鍵の内容をペーストする。Add SSH keyをクリックして、Github上の鍵の設定は完了。下記を実行する。 ssh -T git@github.com 実行の可否を聞いてくるので、yesと入力。Hi~と出てくればSSH keyの設定はOK。 Github上でリモートリポジトリを作成する。作成したリポジトリのSSH用URL（NOT https）をコピーしておく。 リモートリポジトリとローカルリポジトリを接続する。下記を実行。 git remote add origin SSH用URL ローカルリポジトリを作成したいディレクトリを移動する。下記を実行しローカルリポジトリを作成する。 git init Gitでadd→commit→pushを実行し、ローカルリポジトリの内容をリモートリポジトリに反映させる。下記を実行して、Gitのインデックスに登録（Git管理の対象になる）。 git add ....

はじめに 本サイトはGitHubPages📄にて運用しております。 一般的なブログサービスは便利なものもたくさんあります。アカウントを登録すればすぐに開始できるし、機能も豊富で、至れり尽くせりです。 では、構築に手間がかかる（少なくともブログサービスよりは）GitHubPagesをなぜ選択したのかを、メリットを挙げながら振り返っていきたいと思います。 広告を載せる必要がない ブログサービスによっては、広告の表示が必須、もしくは広告の非表示が有料なところがあります。GitHubPagesに載る広告は自分でコントロールすることが出来るのが良いですね。 無料🆓 上記の広告の件が絡んできますが、ブログサービスによっては💰有料のプランが用意されている場合があります。逆に言うと、無料プランでは様々な規制が設定されています。アップロードできるデータサイズや、独自ドメインの利用の規制等が主だったところですね。GitHubにも有料プランが存在しますが、特定の機能に限られているので、無料プランでも十分な運用が可能です。 設計自由度が高い ブログサービスによっては、デザイン🎨が固定、もしくはほとんど固定されているところがあります。GitHubPagesは非常に設計自由度が高いです。これは反面、自分で何もかも用意する必要があるということでもあります。当然、本サイトのデザインテーマしかり、Hugoやjekyllという静的サイトジェネレーターしかり、様々な技術を利用させていただけます。しかし、英語の情報も多く、Git/GitHubの利用も必須なので、構築・運用ハードルが低いとは言えないと思います。 サービスの信頼性が高い GitHubはマイクロソフトが運営しており、倒産等によるサービスの停止リスクは低いと評価できます。また、GitHub、GitHubPagesの利用者は世界中におり、運営元にも信用がおけるので、利用者を無視するような形でのサービスに対する規制が行われるリスクも低いと考えています。運営側の考えが強く反映された結果、利用者目線とは異なるポリシーが敷かれてしまったブログサービスもあったります。 好きなことを書ける💖 ブログサービスによっては、ブログの内容を特定のジャンル（例えばIT技術）に制限するルールを敷いているところもあります。そこでは、個人的な日記やエッセイ的な内容を書くことはできなくなっています。そういった規制も、GitHubPagesならありません！ 使ってみようかなと考えたブログサービス一覧 Qiita はてなブログ Zenn おわりに 上記の内容より、私はGitHubPagesを選択しました。 当然ですが、GitHubPagesにデメリットが無いとは言いません。特に自由度の件はメリットとデメリットが表裏一体になっています。 また、特定のブログサービスにしか無いメリットもあったりします（つまりそれはGitHubPagesのデメリットとも言える）。SEOの強力さや、ネットブック📚の形式でコンテンツの販売ができるところもあります。ただ、このサイトは、少なくとも今のところマネタイズや発信力の高さみたいなところをあまり求めていなかったので、そのメリットとは合致しなかった感じですね。 ということで、今後も技術的な内容を中心にその他色々な内容を書いていけたらと思っています😁

なぜGitHubPagesを選んだのか 無料であり、広告がないのが魅力的でした。はてなブログやZennも検討しましたが、GitHubを使用した経験が乏しいので、練習も兼ねることが出来るのではと考えました。またGitHubを使い慣れておくとは、スキル💪として有用だとも考えていました。 ※記事をMarkdownで書くことは必須事項でしたが、どのサイトもその要件は満たしていました。 静的サイトジェネレーターになぜHugoを選んだのか GitHubPagesを使用していく上で候補に挙がったのが、jekyllとHugoでした。jekyllはビルドに時間が遅い等の問題が見受けられました。調べるとjekyllからHugoに切り替えたというサイトもちらほらあり、かつ開発の継続性も見受けられましたので、Hugo（＋PaperMod）を選択しました。 ※ただ、jekyllはGitHub推奨の静的サイトジェネレーターの様ですし、最初はそこから入っても良かったかもしれません。 参考にしたところ GitHub Pagesで作るウェブサイト開発入門 - 自分だけのホームページを無料で公開 Hugo+Github Pagesでプロフィールページを作ってみた 受難の日々（Error一覧）😥 configが従来生成されたconfig.tomlではなく、config.ymlを作る必要があった。これは選んだテーマにより違う部分の様なので、テーマの公式ドキュメントに書いてある内容だと思います。config.ymlの書き方もなかなか掴めず苦労しました。最終的には下記の公式ページにたどり着き、何とか事なきを得ました。 hugo-PaperMod installation sample config.yml hugo serverで生成したサイトがうまく表示できませんでした。http://localhost:1313/ にアクセスしても、Chromeが「このサイトにアクセスできません」と無情に表示するだけでした。しばらく生成された文章を眺めていると、hugo serverが実行されている間しかlocalのWebサーバーは有効にならない、と気付きました。生成が終わったから実行を止めないといけないと勘違いしており、生成する度にctrl+cで止めてからアクセスしちゃってました。そりゃ表示されないですよね。 Serving pages from memory Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender Web Server is available at http://localhost:1313/ (bind address 127.0.0.1) Press Ctrl+C to stop Press Ctrl+C to stop!! git cloneで取得したPaperModがhttp://localhost:1313/ の段階で動きませんでした。いくつか同様の事例を調べていると、git submoduleで導入している人が多かったので、実行してみたらうまくいきました（cloneしてきたフォルダは削除）。これは今のところ何が悪かったのか分かっていません。 上記の件と関連してURLやパスが異なるといったErrorが出ました（なぜかcloneで持ってきたフォルダは「PaperMod」、submoduleで持ってきたフォルダは「hugo-PaperMod」でした）。GitHub ActionsにこのURLやパスは存在しませんというErrorが出ており、気づきました。自分が誤った修正をしている場面もあり、なかなかErrorが治まりませんでした。 git initの実行したパスが自分の想定と異なっており、GitHub上に上がるのが上位階層のフォルダ１つのみという状況が続きました。GitHub ActionsからDocsフォルダが見つかりませんというError内容が出ており気づきました。結局は、正しい位置でGit initを実行し直した上でadd → commit → pushの一連の流れを行うとうまくいきました。まだGit、GitHubの操作に慣れておらず、随分と右往左往しました。 Repositoryの名前が不適切になっており、想定外のURLでGitHubPagesが公開されていました。それに伴い、baseurlが異なるのでサイト自体が全く表示されませんでした。Repositoryの名前を「github....

TL;DR 総じて良い書籍📘だと感じました。書籍内の演習は全て実践させていただきました。 自分の状況。 GitはInstallしていたが、使用実績はなかった。 GitHubのaccountは持っていたが使用できていなかった。 Visual Studio Codeはinstallしてあり、使用実績もあった。 拡張子やDirectory構造📁をある程度理解していた。 CLIには慣れていた。 htmlを編集したことがあった。 以上のような状況なので、PCの扱いを含めて何も分かっていないわけではありませんでした。ただ、上記のような経験が無くとも実践していけるように作ってあると思います。尚、IT関連の実務経験はありません。 良かったところ。 Git＆GitHubを学ぶ上で、良い書籍だと感じました。Teamを想定した開発の演習があるのですが、その内容も分かりやすく興味を持って取り組み続けることができました。 command lineで実施するところと、その結果がしっかりと表示してあり、勘違いをしにくい（自分がCommand Lineを打ち込む場面なのか実行結果を待つ場面なのかといった）のも進めやすかったです。 事前説明の項目と演習の項目がしっかりと分けられており、分かりやすかったです。反面、少し上長にも感じました（事前説明の段階で先んじて実行してしまったり等）。「いちばんやさしい」をタイトルにしている以上は仕方ないのかなぁとも思います。 ところどころにある「ワンポイント」で納得感を得ました。編纂事情の説明や、こんなこともできるよといった演習では扱いきれない、視座に富んだ内容が記載されていました。master/slaveがmainに変わりつつある話しとか、面白かったです。下記画像はP140。 公開鍵による認証手続き（今回はSSH）についても、丁寧に解説してあったと思います。こういった書籍を用いずに実践する場合は、躓きポイントになりそうですね。 自分が詰まったところ。 Pull Request先を誤ってfork元にしてしまいました（yasagit-2/ichiyasaGitSample Repository）。同じことをしてしまっている人も多くいるようで、私が訪問した時点で同様のRepositoryには41件（forkは300件超）のPull Requestが行われていました。書籍の読者の皆様、同じ間違いをするようで少し安心しましたｗ （Pull Requestは取り消すこともできるので、間違った方はそうすると良いかもしれません） ホームディレクトリの環境変数を変更するのに手間取りました。/c/Users/(Home Directory)にはすでにいくつかのFolderやFileが存在したので、そこに新たにFolderを作成し、その直下で作業を進めたいと考えました。しかし、SSH Keyを生成する際に自動的に指定されるのがHome Directoryだったので、その変更を余儀なくされました。結果、Git Bash上でSETXCommandを実行して、変更することができました。下記を参考にしました。操作自体は簡単だったのですが、Git Bashの再起動を実施していなかったので、結果が反映されていないことに気づくのに時間がかかりました。GUIで実施すれば問題なく、かつ早くできたと思いますが、CLIで操作したかったんです。。。 [Git] Git Bashのホームディレクトリを変更する SETXで環境変数の変更を間違えた場合に面倒なことがあるようですが、最終的にはPowerShellを用いて解決できるようでした。 Windows環境変数の設定に「SETX」コマンドを使ってはいけない理由 Repositoryの連携に手間取りました。上記の件でGit Bashを再起動したせいか、Remote Repository（GitHub）との連携が解消されており、Commitしたところ、下記の通知が流れました。ここでemailだけでも判別できるかなぁ、とか色々やって時間を食いました。 誤植らしきところ。 下記の画像のところです。行数の順番がおかしくなっており（114から始まり途中で90になっている）、記載に誤りがあると思われます。この内容はインプレス社のお詫びと訂正に載っていませんでした（2022年8月7日訪問時）。P215です。 いちやさGit インプレス社 まだ慣れないところ。 git init → git add → git commit git clone → git branch → git add → git commit → git push → Create Pull Request → Review → Merge → git pull git status, git diff, git checkout, git reset, git rm, git log, git remote...