ﾂｺﾞｳﾆﾖﾘ、ﾊﾞﾝｸﾞﾐｦﾍﾝｺｳｼﾃｵｵｸﾘｼﾃｲﾏｽ

Phoneappli AdventCalenderの1日目です！

去年参加表明をしないでひどい目にあったので今年はちゃんと登録するぞ！って思ってたら初日になりました。どうして。。。？

先日行った社内LT会でスライドほぼなしで喋ったので、折角なので文字で残しておこうと思います。ｼﾞ、ｼﾞｭﾝﾋﾞｶﾞﾏﾆｱﾜﾅｶｯﾀﾜｹｼﾞｬﾅｲﾖ...

なに喋ったの？

git雰囲気で使ってたからちょっと調べてみたよ

こんな動きしてた

HEAD

.git/HEAD
branch の場所を記憶しているポインタ

branch

.git/refs/heads
ある地点のコミットに名前をつけたポインタ

commit履歴はこうなってる

.git/logs

0000000000000000000000000000000000000000 58b859c0d1f62d1504a828e9b5d0a0905a65d1dd commit (initial): 
0000000000000000000000000000000000000000 364b3154df57f1dccfb1b6041eb0538f224878ee commit (initial): 
364b3154df57f1dccfb1b6041eb0538f224878ee 364b3154df57f1dccfb1b6041eb0538f224878ee checkout: moving from develop to feature
364b3154df57f1dccfb1b6041eb0538f224878ee 3faeb6bbbb708d1d4b78dc4d5ee8f01a67cd70ce commit:

main

58b859c0d1f62d1504a828e9b5d0a0905a65d1dd

develop

364b3154df57f1dccfb1b6041eb0538f224878ee
HEADを直接編集した

feature

3faeb6bbbb708d1d4b78dc4d5ee8f01a67cd70ce
364b3154df57f1dccfb1b6041eb0538f224878ee
developからcheckout

普段そんな使い方しないけど

HEADをmainに書き換えてコミットすると

58b859c0d1f62d1504a828e9b5d0a0905a65d1dd f786eb36c03d0fd015b405db82f75dd0a32f8be6 commit: 

になる

おしまい

半分備忘録なので内容がアレで恐縮ですが今回はこの辺で
当初の予定だったものは今週末とかに書こうと思います。。。

2日目は@yiwiさんの「AIで遊ぼう」です！

sparse-checkoutコマンドは Git 1.7 でリリースされているようですが、
「Git 2.26」で使うことをオススメします。
※ sparse-checkout add コマンドは Git 2.26 で追加されています。

初期化

git sparse-checkout init

• sparse-checkoutを有効にする
• 設定ファイルが無い場合、作成する (上書きはしない)

設定ファイルの中身

/*
!/*/

設定内容を確認する

git sparse-checkout list

設定を更新する

git sparse-checkout set AAA BBB CCC

• sparse-checkoutを有効にする
• 設定ファイルが無かったら、コマンド引数の内容で作成する
• 既に設定ファイルがある場合、中身を上書きする

設定ファイルの中身

AAA
BBB
CCC

設定を追加する

git sparse-checkout add AAA BBB CCC

• 設定ファイルの末尾にコマンド引数の内容を足す

.git/info/sparse-checkout を編集すれば良い話なのでわざわざコマンドを使わずともいいような。。

よくあるデプロイコマンド
$ cap staging deploy
でエラー、あまり良く見たこと無いメッセージ、しかもついこの間までデプロイできてたのに…

00:07 git:update
      01 git remote set-url origin git@bitbucket.org:hogehoge/hoge.git
    ✔ 01 hoge@foo.com 0.008s
      02 git remote update --prune
      02 Fetching origin
      02 error: rev-list died of signal 11
      02 error: rev-list died of signal 11
      02 error: bitbucket.org:hogehoge/hoge.git did not send all necessary objects
      02
      02 error: Could not fetch origin

なんじゃこりゃ。エラーメッセージでいろいろググってもあまりこれ！って解決方法は出てこない。

・リモートでgitを再インストール
・gemを全部アップデート

で解決した。アップデートで解決するやつってエラーわかりにくいわ…

過去やったのにまた忘れてたのでメモです。

githubにpub keyを登録した後にすること

事象：
先方のリポジトリに、パブリックキーでアクセス許可していただいたけれど、接続できなかった。
接続してリポジトリをcloneしたい

やったこと

~/.ssh/config というテキストファイルを作成し、以下の設定を行う。

$ cd ~/.ssh
$ touch config

作成された config ファルを編集。

host xxxxxxxxxxxx.xxx
 HostName xxxxxxxxxxxx.com
 IdentityFile ~/.ssh/xxxxx（登録したキーのファイル名）
 User git

無事つなげました?

■はじめに

この投稿は私が所属するプログラミングコミュニティの勉強会のために作成しました。
Qiita読者の皆さんにもお役に立てれば幸いです。
読み物として読む場合は、途中のハンズオンは飛ばしてください。

対象者

• ソースコードのバージョン管理の概念と重要性は理解している
• 実際にローカルリポジトリにcommit、リモートリポジトリにpushはしたことがある
• チーム開発で円滑にソースコードを共有する方法を模索している
• コンソール画面やLinuxコマンドには不慣れ

目的

リモートワークでも円滑なチーム開発ができるようになること。

手段

• Gitのコマンドを知る
• Microsoft Visual Studio Code（VSCode）でGitを使う
• GitHubで小規模なチーム開発の流れをハンズオンでやってみる

前準備

• Gitが端末にインストールされている
• VSCodeが端末にインストールされている
  • 以下の拡張機能が入った状態
    • Japanese Language Pack for Visual Studio Code
    • Git Graph
    • Git Lens
    • Git History
• GitHubのアカウントがある

心構え

• コンソールコマンドが不慣れな人はより慎重に！
• 何かがおかしくても、GitやGitHubが言ってくる英語のエラーコードを頑張って読もう！
• お互いに教えあって進めていこう！

筆者について

GitおよびGitHubは独学となります。

業務ではSVNでバージョン管理を経験しました。

https://subversion.apache.org/

SVNでは個人で好き勝手にリポジトリを持てないため細かい単位でのコミットの運用というのができませんでした。そこで独自にgitでバージョンを管理し、本番のSVNにコミットするときはgit-svnという機能を仲介して履歴は保ったまま、疑似分散開発っぽいことを挑戦したことはあります。ただ何かと苦しみを伴ったため途中でやめた記憶があります。

CUIかGUIか

gitをCUIで使うか、GUIで使うかは、バージョンを管理するという目的を達成できるならばどちらでもいいと考えています。

ただし、他の人と会話する際にコマンド名とそれが何を意味するのか、そしてそれが自分が使用するGUIのどの操作に当てはまるのかを抑えておくとスムーズに会話ができると考えます。CUIを使わないにしても、両者の共通言語としてコマンド名がすぐに思い出せる状態にしておくことは重要と考えています。

よって、この記事では、コマンドとその意味、そしてVSCodeでそれを実現する方法という流れで記載します。

VSCode拡張以外にもGUIで使う方法はたくさんあります。自分の手に馴染むものを探してみるのもいいですね。

• SourceTree https://www.sourcetreeapp.com
• GitKraken https://www.gitkraken.com

■Gitとはなにか

説明を行う上で、どうしても説明が前後してしまう単語がありますが、分からない単語も後から出てくるものとして読み進めてください。

また、ここでは本当に概要しか説明していません。ここでの学習を起点に自分なりに調べるなどして理解を深めてください。

コミットとバージョン

ローカルリポジトリにおける変更を確定し、バージョン管理上に乗せることをコミットといいます。

コミットを行うと一つのコミットに対して数字の羅列のような値（ハッシュ値）が割り振られます。これがGitにおけるバージョンです。

コミットしておけば、後からそのバージョンに戻すことも容易です。機能追加していたらいつの間にか動かなくなってしまい、もとにも戻せなくなった。そんな経験はないでしょうか。開発中は区切りのいい単位でコミットを行う癖をつけましょう。

ローカルリポジトリとリモートリポジトリ

Gitは分散型バージョン管理システムです。

なぜ分散型と呼ばれるかというと、共有リポジトリの他に自分自身しか触らないリポジトリを持つことができるからです。

共有リポジトリをリモートリポジトリ、自分自身しか触らないリポジトリをローカルリポジトリといいます。

前述したコミットはローカルリポジトリに対して変更を確定するものでした。

この状態では自分の端末が壊れた際にローカルリポジトリも一緒になくなってしまいます。

リモートリポジトリ（GitHub）にローカルリポジトリの内容をpushすることでそのような事故にも備えることが可能です。

また自分の端末の外側にリポジトリがあるということは、複数人が同じリポジトリを参照して共同開発する環境が作りやすいことを意味します。これを応用したものがGitHubによるチーム開発です。

ディスカッション（ハンズオン）

具体的な説明に入る前に、現段階の知識で良いので、Gitを使っててよかったという体験談や、Gitを使ってなかったせいでこのようなことが起きた、Gitってまだよく分からないけど、こういう困ったこと解決できますか、などをディスカッションしてみましょう。

次からは具体的なgitコマンドを元に解説を進めます。

■Gitコマンド

Gitで行うこと、簡単な説明、Gitコマンド、VSCodeでのやり方の順番で説明します。

今回の学習は、あくまで知識の足がかりと考えて、詳細は自身で調べることをお願いします。

コミット対象候補にする（ステージング）

なぜステージングという考えが必要なのでしょうか。

例えば10ファイル編集中に、10ファイルすべてを一度にコミットせず、分割してコミットしたほうが、後からログをたどる際に分かりやすいシーンがあると思います。

これを実現しやすくする考えがステージングです。

コマンド

git add

VS Code

プラスボタンを押すことでステージングが可能です

ローカルリポジトリにコミットする

コミットという操作はローカルリポジトリのバージョンを上げる行為です。
あくまで自分の端末内だけの更新であるため、GitHub上には登録されないので注意してください。

コマンド

git commit

VS Code

フォームにコメントを入力後、⌘+Enter（Ctl+Enter）を押すことでコミット可能です。

最新の変更を取り込む

GitHub上の最新の変更を、自分のローカルリポジトリに取り込みます。

コマンド

git pull

VS Code

ソース管理と書かれている場所の右端にあるメニューからプルを選択します。

ローカルリポジトリの作成

説明は割愛します。
最初のうちは、GitHubでリモートリポジトリを作り、それをクローンしてローカルリポジトリを作るというやり方がわかりやすくていいと思います。

コマンド

git init

VS Code

VSCodeからinitができるかはわかりません。

リモートリポジトリのコピーを作成する

GitHub上のリモートリポジトリのコピーをローカルリポジトリとして作成します。

コマンド

git clone

VS Code

cloneもVSCodeから可能なようですが使ったことはありません。

GitHubでリモートリポジトリを作成した後、ローカルリポジトリを構成するために指定されるコマンドがあるので、そこまではコマンドラインでやるほうが楽だと思います。

もちろんVSCodeから単に既存のリモートリポジトリをcloneするだけならお手軽に使えると思いますが、その場合も自分がどのディレクトリにいるかはちゃんと意識する必要があるので注意してください。

ローカルリポジトリの変更状況の確認

コマンド

git status

VS Code

青枠で囲まれた部分がgit statusと同等の情報を出しています。

ローカルリポジトリの変更差分の確認

コマンド

git diff

VS Code

ソース管理タブでファイル名をクリックすると変更差分の確認ができます。
今は新規ファイルなので全部が変更差分として表示されています。

変更履歴の確認

コマンド

git log

VS Code

VSCodeの拡張機能を使います。
左がGitLens、真ん中がGitGraph、右がGitHistoryです。
好みのものを使いましょう。

拡張機能なしでもログを確認可能ですが、拡張機能が何かと便利なのでほぼ出番はないと思います。

ファイルの削除

コマンド

git rm

VS Code

VSCode上から削除すればよしなにやってくれるのか、調査中です。

ファイルの移動

コマンド

git mv

VS Code

VSCode上からリネームや移動すればよしなにやってくれるのか、調査中です。

リモートリポジトリの登録

コマンド

git remote add origin https://github.com/user/repo.git(例)

このコマンドは origin という名前で https://github.com/user/repo.git(例) というリモートリポジトリをローカルリポジトリに設定するという意味です。GitHubからリポジトリを作成している際はすでに実行済みのコマンドだと思います。

VS Code

やり方調査中です。

リモートリポジトリにローカルリポジトリの変更をアップロードする

git commitしただけではGitHubにアップロードされていません。git pushしましょう。

コマンド

git push <リモート名> <ブランチ名>

VS Code

バージョン管理の対象から外す

詳細は割愛しますが.gitignoreファイルを編集することで実現します。
なぜバージョン管理の対象から外すという概念が必要なのでしょうか。
例えばパスワードが書かれたファイルはバージョン管理すべきではありません。
OS独自の隠しファイルなどは別のユーザにとっては不要なファイルです。
そのようなファイルを除外するときに.gitignoreファイルを使います。

変更を元に戻す

コマンド

git checkout -- <ファイル名>

VS Code

プラスアイコンの左の矢印が戻っているアイコンをクリックします。

ステージングしたファイルをもとに戻す

コマンド

git reset HEAD <ファイル名>

VS Code

マイナスアイコンをクリックします。

間違ってコミットしてしまった

コミットそのものを取り消すという手段もあるようですが、最初のうちは、素直に正しいファイルでもう一度コミットするほうががわかりやすいと思います。

リモートリポジトリを表示

コマンド

git remote

VS Code

拡張機能GitLensの機能でリモートリポジトリを確認可能です。

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

コマンド

git branch <ブランチ名>

VS Code

VSCodeの左下の枝分かれしたアイコンの場所をクリックすると、ブランチを選択するフォームが開きます。
ここで新しい分岐の作成をすると新しいブランチが作成できます。

ここで設定するブランチ名は適当なものですが、ブランチ名はそのブランチで何をやるかわかり易い名前にしましょう。

現在のブランチを確認する

コマンド

git branch

VS Code

左下の枝分かれしたアイコンの場所の文字が現在のブランチです。

ブランチを切り替える

コマンド

git checkout <既存ブランチ名>

VS Code

ブランチを作成するとVSCodeの左下の枝分かれしたアイコンの場所の文字が作成したブランチ名になっています。これは新しく作成したブランチに移動したことを意味しています。

もう一度左下をクリックすると、もともといたブランチ(master)と新しく作成したブランチが選べるようになっています。もともといたブランチに切り替えたいときはクリックすることで切り替えることができます。

ブランチを作成して切り替える

コマンド

git checkout -b <新規ブランチ名>

VS Code

VSコードではブランチを作成して切り替える動作がデフォルトの動作のようです。

ブランチを今いるブランチにマージする

2回目のコミットのmasterブランチからdev_branch_1を切り出しました。この状態からmasterブランチに３回目のコミットを行いました。
この状態は、dev_branch_1がmasterブランチよりも古いということです。

どういうときに、このようなことが起きるでしょうか。

これはチーム開発の際に、別のチームメンバが自分よりも先に機能をmergeした際に起きます。このようなときにmasterの最新の機能を自分のbranchに取り込みたいというシーンが出てきます。

また、同一ファイルのバージョンが自分のブランチよりも進んでいた際、masterの最新を取り込むことが必須となる（自分のブランチをmasterにmergeできない）ことがあります。

このように、チーム開発では、現状の最新を取り込むという行動が重要になってきますので慣れていきましょう。

なお、ここではマージを紹介しますが、場合によってはリベース（ブランチの切り出しポイントを先にずらす）やプル（リモートリポジトリをfetchしてmerge）という方法もあります。

おそらく、ブランチ開発の第一関門はここではないかと考えています。コンフリクトやエラーが起きて当たり前と考えて、GitやGitHubのメッセージをよく読み、どのような対処が必要か判断できるようになりましょう。

素直にマージできない理由は大きく２つだと思います。

• あるファイルのバージョンに対して古いバージョンのファイルをマージしようとしている
  • マージ先のブランチの変更をマージ元に取り込んでから再度マージを行います
  • また、このマージ元に取り込む際にコンフリクトが発生することがありますが、あわてずに
• バージョンに問題はないが、マージ元とマージ先で同じファイルの同じ場所を編集している
  • 後述するコンフリクト解消作業を行います

おそらく文章だけでは難しいので後ほど実際に動かしてみて試しましょう。

コマンド

git merge <ブランチ名>

VS Code

dev_branch_1に対してmasterをマージするという選択をしました

今回、dev_branch_1は切り出してから何も変更していなかったため、fast-forwardマージが行われました。

fast-forwardマージとは何でしょうか。マージの種類については以下などを参考にしてください。
https://backlog.com/ja/git-tutorial/stepup/04/

コンフリクトを解消する

ブランチをマージする際、マージ元ファイルとマージ先ファイルの同じ行に変更があった場合、gitはどちらの変更を採用すべきかの判断をユーザに委ねます。だいたい以下のような感じになっています。<<や==や>>はどこからどこまでがどの変更可を表す記号のため、コンフリクト解消作業ではこの記号を消しましょう。また、自分の変更とマージ元の変更の関係性を調査して、どちらを残すのか、両方残すのかを判断しましょう。

<<<<
自分の変更  
==== 
マージ元の変更
>>>> 

編集が終わったら git statusで状態を確認します。
コンフリクトが解決していたら、git add / git commitでコンフリクト解消作業は終了です。

一時的に変更を退避する

一時退避とは何でしょうか。ある機能を開発中にコミットするまでに至っていないがブランチを切り替えたいシーンがあります。このときに一時退避機能を利用します。一時退避を使用せずにブランチを切り変えるとブランチ変更前のファイルに対する変更がブランチ切り替え先に引き継がれることになるようです。

コマンド

git stash

VS Code

ここまで学習した機能を使いまくってみよう（ハンズオン）

プログラミングと同じで、Gitを理解するのは、いかに量をこなすかだと思います。学習した機能を使ってどのようなことが起きるのか何度も試してみてください。慣れてきたら、コマンドの方を試すのもおすすめです。

■ブランチモデル

ブランチをどのように分けて開発していくかは、プロジェクトにより様々な考え方があります。いちばん重要なことは、プロジェクト内でルールを決めて全員がそれに従うことです。どんなに素晴らしいやり方を考案しても、ルール通りに皆が動けなければ意味がありません。ネットでよく見かけるキーワードはGit flow と GitHub flowだと思います。

Git flow

(参照: https://nvie.com/posts/a-successful-git-branching-model/ )

GitHub flow

ものすごく単純に説明すると、Git flowの図のmasterとfeatureだけで運用している感じ。

■ディスカッション（ハンズオン）

世の中にプロダクトの完成版をリリースつつ、顧客に次のバージョンアップ版を評価（試験など）をしてもらいつつ、更に次の開発を続けるというシーンを想像して、どのようにすれば円滑に開発が進むか、ブランチを考えてみましょう。正解は一つではありません。

次の模擬チーム開発でも運用できるか、チームで運用するにはどのような工夫、事前準備が必要か、実際に運用するときはどのようなコミニュケーションが必要かまで考えられるとなおいいです。

■GitHubによるリモートチーム開発（ハンズオン）

ここからはGitHubによるチーム開発の説明をします。

チームのリポジトリの作成とメンバの招待

organizationアカウントの作成

個人アカウントに誰かを招待することでチーム開発は可能です。しかし、チーム開発なのに個人のアカウント配下に人を集めるというのが若干違和感を感じませんか。私は感じました。GitHubにはorganizationアカウントという組織で使うアカウントが用意されているので、それを使ってみましょう。

Create organizationsをクリック

Freeプランを選ぶ

Organization account nameを入力し、My Personal accountを選ぶ

ここでメンバを招待できますが後からできるのでこのままComplet setup

GitHubのパスワードを求められるので入力します

どのような用途で何人で使うかなどを答えていきます

既存のリポジトリを使うか聞いてくるのでNoにしておきます

organizationアカウントが完成しました。
Create a new repositoryでリモートリポジトリが作成できます。

リモートリポジトリを作成します
ここからは個人アカウントのリモートリポジトリと同じです。

指定されたコマンドを打てばローカルリポジトリも完成です

骨組みのコードをアップロード

チーム開発といってもファイルがゼロの状態から全員が一斉にコードを書き始めるのは困難です。まずは骨組みのコードを代表者がpushするのがいいと思います。

Hello World的な突貫で作ったファイルを数個でも構いませんし、既存の自作プログラムでも構いません。ただ、今回は練習なのでシンプルで動作確認しやすいものが適しています（複雑すぎると練習として気軽に手を加えることが難しいため）。

issueの作成

プロジェクトを達成するためにやらなければいけないことをissueに挙げましょう。

今回は練習なので内容は気にせず、issueを発行したらお互いにどのような見え方になるのか、どういう情報が記載できるのか、どういう情報が記載されていると他のメンバにもわかりやすいかなどを考えてみましょう。

issueタブでNew issueボタンを押下します。

issueの内容を記載し Submit new issue を押下します。

projectの作成

今どのようなissueがあり、だれがどのissueに取り組んでいるかを見えるようにしたものが、projectです。同じようなことを実現するツールはasanaやtrelloなどがありますが、今回はGitHubのprojectを使ってみましょう。

Projectsタブから Create a project を押下します。

Templateを選択します。複数のテンプレートがありますが、自分たちのチームのやり方に合うのを選ぶと良いでしょう。

例ではAutomated kanban with reviewsを選んだのでカラムが５つできました。
右端にissueがあることが分かります。

このissueはドラックアンドドロップでカラムに移動することができます。

カラムから直接issueを作ることもできます。

Convert to issueをすると

アイコンが！マークになってissue担ったことが分かります。

拡張機能ZenHubの紹介

ZenHubはGitHubのProjectを更に高機能にしたもので無料で使えます。Crome拡張機能です。
チーム開発を管理する際のサービスはtrelloやasanaなどがあります。ZenHubも選択しに入れてみてはいかがでしょうか。

https://www.zenhub.com

このようにガントチャートっぽい見え方ができたり、その他分析用のグラフなどが豊富にあります。

プルリクエスト

プルリクエストは、自分の変更をリポジトリに取り込んでもらえるよう依頼する行為です。
レビュアーを選択し、レビューを受ける起点にもなります。

ブランチをpushすると自動的に Compare & pull request というボタンが出現するので押下します。

レビュアーを指定し、Create pull request ボタンを押下します。これでプルリクエスト完了です。

レビューとコメント

プルリクエストを受けたレビュアーは対象のファイルをレビューし、適宜GitHubのコメントでやり取りを行いましょう。やり取りが完了したらレビュー完了です。レビュアーの全員がレビュー完了したらマージを行います。

ソースコード中のプラスボタンでコメントを入れることができます。

コメントを入れると以下のようなスレッドが作られます。どのようなやり取りが行われたか分かりやすいですね。

例の画像は本人のためApproveができませんが、レビュアーはレビューが終わって問題なければApproveを選択します。

マージ

もしかしたら、コンフリクトを起こしていてマージできないかもしれません。コンフリクトの解消は、プルリクエストを行った本人が行うのが最もわかりやすいと思います。コンフリクトを起こしていたら、レビュー依頼前に解消して、再度プルリクエストを出すようにしましょう。

コンフリクトが起きていなければ Merge pull requestボタンを押下

マージコメントを入力しconfirm mergeでマージ完了です。

マージが終わればブランチを削除しても良いでしょう。削除しなくても問題はありませんがたくさん溜まってくると消したくなります。

masterのファイルを確認すると、無事マージされていることが確認できました。

デプロイ

ホスティングサービスは色々ありますが、今回はvercelを使ってみます。vercelはReactのフレームワークのNext．jsを作っている会社が運営するホスティングサービスで、Next.jsと一緒に使うと何かと便利です。

https://vercel.com/login

githubのアカウントがあればログイン可能です。

vercelとGitHubを連携すると、自動的にデプロイが可能になるほか、プルリクエスト契機にも暫定的なデプロイをしてくれます。これにより、レビューの際に実際の動作を確認しながらレビューが可能です。

■疑似リモートワークしてみよう（ハンズオン）

チームでルール作り、コミニュケーション手段の確立を行い、疑似リモートワークしてみよう。
相手が常に応答できるとは限らない非同期コミニュケーションと、相手の即レスポンスが可能な同期コミュニケーションをうまく使いこなそう。

■終わりに

資料は読みやすいように今後ブラッシュアップしていきます。
以上です。

はじめに

本記事を作成しようとした経緯等を簡単に記載します！
同じ境遇の方であればきっと役に立つかもしれません！

目的

・Git初学者に向けてイメージしやすいインプットをしてもらうため
・自分の覚えのため

背景

・Git/Github学習中に悩むのが
「今Git上でどんな状態にあるのか」
「コマンド入力後に今のディレクトリやブランチ上のデータがどう扱われているか」
が不明であることでした
・実務を想定してGit/Githubを使用していましたが、よく間違えてmasterブランチにdevelopブランチのデータをmergeしてしまったり、なぜか意図していないプルリクエストが出たりと散々でした。。。
・ちなみに疑似チーム開発を経験したことあるのですが、自分のGit知識のなさからチーム開発PJTを火の海にしてしまったことがあります。。。

そんな背景もあり「課題の可視化」を実践してみようと試みた、というわけです。

前提

では、本題に入る前に前提だけ頭に入れていただきたいです！
・使用頻度高いものから順に
・使用するソースコード管理サービスは"GitHub"
・以下レイアウトを頭に入れていただきたい読み進めてください。

1. "git init"

ローカルリポジトリの箱を作成。(「初期化」とも説明される)

2. "git add ~"

commitするためのステージング作業＝commitするかしないかの選別作業
※参考

3. "git commit"

git addでステージングしたディレクトリ、ブランチ内の内容を記録する
この先進んでミスったとしても、"git commit"した地点に戻ることができる

4. "git push"

"git commit"した内容をリモートリポジトリに記録
⇒GitHubの管理下に置く

5. "git branch (ブランチ名)"

新しいブランチを生成
※ブランチを複数作る理由："git init"時に生成されるmasterブランチは本番用ブランチなので、作業場所を確保するために別ブランチを生成する

最後に

ほんとに初歩の初歩のコマンドしか記載していませんが、イメージを持ちながらGitを進めていけば思いがけないミスを回避できます。
今後もちょこちょこ増やそうと思いますので、よかったらGitの初学者の方々は参考にしてみてください！

最後まで読んでいただきありがとうございました！

※参考リンク
・"git add"
https://kray.jp/blog/expound-git-add/#
・"git commit"
https://backlog.com/ja/git-tutorial/intro/03/

こんにちは。
前回からの進捗状況を報告致します。
同様に現職の仕事もしながらプログラミング学習をしている方やこれから勉強を始める方への参考になれば幸いです。

①M1 MacBookAirを購入

表題の通り、M1 MacBookAirを購入しました。
GPU7コアでメモリだけ16GBにカスタマイズしたものです。

ただやはり言われているようにDockerやVirtualBoxなどの仮想環境ツールは動作せず。
届いたのが22日の日曜日でしたがこの日と次の月曜日はほぼ開発環境を整えるのに時間を費やしました（笑）
色々試行錯誤して、HomeBrewなどダウンロードできたもののRails -s でローカルサーバーが立たず、、、

徹夜でやってもうまくいかず一旦環境作りは諦めましたね、、、

②Progate JavaScriptまで一周終了、ただ、、、

気を取り直してProgateを再開しましたが、RailsコースをVあたりでわけわからなくなったので中断してしまいました、、、

アプリ版でちょこちょこやってたJavaScriptコースを終わらせる方にシフトし、ちょうど終了した形になります。

これから

フロントエンド系（HTML＆CSS、JacaScript）
バックエンド系（Ruby,SQL）
その他必須なもの（Git、GitHub)をざっとですが、学習したので
アウトプットを行っていこうと思います。

まずは作成物を紹介するためのポートフォリオサイトを作っていこうかと思います。

まとめ

Progateがひと段落着いた感じがするので（頭に入っているかは微妙）
本格的に自分で何かを「作る」という作業に時間を割いていければと思っております。

この記事は DeNA 21 新卒 Advent Calendar 2020 の3日目の記事です。

はじめに

この記事はふと、コマンドだけのまとめではなくもっと具体的なシチュエーションが想像できる記事を書いてみたら面白いんじゃないかと思い書くことにしたものです

また自分がRails開発を経験した中で役に立ったと感じた知識にも触れ、メモ欄にはその解説を加えてみました。

ザックリ評価基準( 個人的 )

• 超重要☆☆☆☆☆
• 重要　☆☆☆☆
• 普通　☆☆☆

目次

index	タイトル( ※リンクになってます )
1	$ tail -F devlopment.logs
2	$ git checkout -b <ブランチ名>
3	$ git push --set-upstream origin <ブランチ名>
4	$ rails db:migrate
5	$ bundle install

1.　$ tail -F devlopment.logs　☆☆☆☆☆

わい「すいません、、ここで何で落ちてしまっているのか分からず..orz」
上司「ログの方は確認しましたか？」
わい「(...ん？ログってどうやって見るんだ?)」

使い方

tailコマンドを実行したことでログが監視される様子↓

メモ・注意点

development.log の役割

Ruby on Railsでは開発環境で動作させている場合ログが log 配下の development.log に溜まっていきます(最初これ知った時驚いた)
また詳しいロガーに仕様や設定に関してはRailsガイドを参考にするともっと詳しく知れたりします。
参考: Rails アプリケーションのデバッグ 2.1 ロガーについて

tail コマンド

tail コマンドはLinuxコマンドのうちの1つでオプションに -F もしくは -f を付けることで 指定ファイルの追記を監視する ことができます。
オプションのfの大文字小文字の違いに関してだと以下の記事だとこちらがおすすめだったりします
参考: tailコマンドのオプション「f」と「F」
また注意点として　tail コマンドを用いる際にちゃんとディレクトリが log 配下に位置していることを忘れずに！
ルートディレクトリから誤ってコマンドを実行すると存在しないと怒られてしまいますゆえ
アプリのルートディレクトリから叩くことにして tail -f log/devlopment.logs としても良いかも知れません

2.　$ git checkout -b <ブランチ名> ☆☆☆

上司「現在の状態を知りたいのでWIPでいいので適当なタイミングでPR作ってもらえますか?」
わい「はい！(あれPRってどうやって作るんだっけ?)」

使い方

まずPRを作る前に新しくブランチを作り、切り替えた様子

メモ・注意点

WIP とか PR とかの用語

ここで上司役が言っていた WIP とは Work In Progress の略称で 作業途中である状態 を指す用語として良く聞く単語だったりします。
またGithub の Pull Request をPR(ぴーあーる)と呼ばれたりするのも複数社で観測したのでシチュエーションに載せてみました。
またそのまま 「プルリクエストを作ってください」 とも良く聞きます。

時代はもう git switch -c <ブランチ名> ？

実はGitのブランチの切り替え方法に関しては Git 2.23 から実験的に git checkout -b <ブランチ名> から git switch -c <ブランチ名> にしたらどうか言う提案がされました。
参考： 【Git】あなたが知らない新コマンドswitch/restoreの世界にご招待
確かにブランチを切り替える際に switch するのと checkout するのとでは switch の方が直感的で分かりやすいですよね。( 後そもそも checkout 役割多すぎ問題..
またおまけでswitch ver. も載せておきます

3.　$ git push --set-upstream origin <ブランチ名> ☆☆☆

わい「(おし、とりあえずブランチは切れたっと。あれ、でもaddしてcommitしたのになんでpushできないんだ)」
幻聴「エラーログをちゃんと読みなさい」
わい「( ﾟДﾟ)ﾊｯ!?(今、何か聞こえた!?)」

使い方

メモ・注意点

ブランチを切り替えた後の最初のPush

個人開発ではもしかしたら全て1つのブランチ( masterブランチとか )で作業していることがありますよね？( 特にGit初めたてとかしてました← )
その場合はとりあえず
1. git add <file_name>
2. git commit -m <commit_name>
3. git push
をすることでGitを使いこなしているつもりなっていたりしました。
しかし、ブランチを切り替えた際の挙動はちょっと違ったりします。
実際には $ git push --set-upstream origin <ブランチ名> のコマンドでさっきまではmasterに向けて届けてたかも知れないけど、今度は切り替えた先のブランチに届けますよっと宣言しています。

また、おまけでpushが成功した後ブラウザ上でPRを作成する様子を載せておこうと思います(ほんとに初めここ分からなかったなぁ..)

4. $ rails db:migrate　☆☆☆☆☆

わい「すいません、追加された差分をgit pullして更新したあとエラーが..」
上司「もしかしてmigrateしてないんじゃないんですか?」
わい「あ。。(それだ！)」

使い方

メモ・注意点

差分を追加した際にマイグレーションファイルが追加されているとき

差分を拾ってきてそれでマイグレーションのエラーを引き起こすことは複数人で開発をしていると良く起きたりします。
初め自分はgit pullしてきて平気なときもあれば、なぜかこうやって ActiveRecord::PendingMigrationError になってしまうときがあるなと、同じことをしているのになぜこう言ったことが起こるのか分かっていませんでした。
しかしよく観察してみるとマイグレーションを要求されることはそう言った変更を行ったときのみ要求されるものだと気付き、それから更新した際にマイグレーションファイルが追加や削除、変更されている場合には自分の開発環境も揃えてあげる必要があるんだと知っていきました。

5. $ bundle install　☆☆☆☆☆

わい「すいません、たしかにマイグレーションエラーは消えたのですが、、」
上司「もしかして次はbundile installしてないとか言わないですよね?」
わい「( ﾟДﾟ)ﾊｯ!?。。(やばいそれだ!!)」

使い方

メモ・注意点

ブランチ切り替えにおけるgemのアップデートが必要な場合

複数人でのチーム開発を行っている際には他のエンジニアの方が新しい gem を導入するケースは当然あります。
その場合、手元の自分の環境でも同じ最新状態に揃えるためにGemfileならびにGemfile.lockを更新する必要があります。

おわりに

Railsでの開発と言うのは一言で言うのはあまりにも広く、開発組織によって様々な使われ方がされると思います。モノリシックに作って一旦VueやReactは入れずに作るんだ！ってところもあれば、RailsにはAPIサーバーとしての役割を持ってもらって、フロントはフロントで頑張りますってところも当然あるかと。
また、Webサービスを作る手段として良く知られている気がしますがRailsをゲーム開発に用いることもあります。
そして最近はDockerの利用も主流になってきて、初学者からするとdockerのコマンドとRailsのコマンドを合わせて利用する場面もありすぐに理解が追いつかず詰まりどころが多くなった印象もありました。

今回はそう言ったところで何かRails開発に慣れていく手助けができればと思い書いてみました

宣伝

この記事を読んで「面白かった」「学びがあった」と思っていただけた方、よろしければ Twitter や facebook、はてなブックマークにてコメントをお願いします！
また DeNA 公式 Twitter アカウント @DeNAxTech では、 Blog記事だけでなく色々な勉強会での登壇資料も発信してます。ぜひフォローして下さい！
Follow @DeNAxTech

削除は必要なのか？

私はプログラムを組む時、Gitを使う。
家ではTimeMachineで1時間ごとにバックアップされている。
iCloudを介して、Mac, iPhone, Apple Watchで色々な物を共有している。

どの機器が何時壊れても、データが消える恐れが無い。
とても安心だし、要らない物は心置きなく捨てられて、スッキリする。

ユーザから見えなくする事は必要だが、システムとして「削除」する事は要らないのではないだろうか？

追記型ストレージの紹介

Plan9のファイルサーバは WORM(Write Only Read Many)で、追記型光ディスクが主体だ。
HDDもメモリも単なるキャッシュとして動作する。
「追記型」と言う事は消えない。新しいファイルを古いファイルの手前に置いて、見えなくする方法を取っている。
新しいファイルを退ければ、古いファイルが見える、Docker Imageの様なレイヤ構造になっている。
Plan9は、計算サーバなど現在のクラウドの基本概念を作った分散OSだが、追記型ストレージはまだ一般的になっていない。
余談だが、Unicodeもこのプロジェクトから生まれている。

システムには履歴データが必要ではないだろうか？

フォルダやファイル単位でのバックアップや、追記による履歴データの保存を見てきた。
さて、私たちが開発しているシステムではどうだろう？
相変わらずデータは上書きされている。
過去の経緯は消え去り、今現在が刻々と変更されているのではないだろうか？
一度起こった現象は二度と再現できず、ユーザーが「そんな事やっていない」と言うのをなんとかログから探してはいないだろうか？
ユーザのフルデータバックアップではなく、差分データバックアップが欲しいのではないだろうか？

追記型差分ストレージを作って見ないか？

現在の安価な大容量ストレージと、分散環境のノウハウを使えば、追記型で差分(履歴)を使ったストレージのサービスやフレームワークを作れる環境が整っていると思う。
もちろん、排他や整合性は考えなくてはならないので、簡単ではないと思う。
しかし可能性を追うのは楽しいし、壁にぶち当たらなくては限界もわからない。
一緒に壁にぶち合ったって見てもらえないだろうか？

自己組織化ストレージも欲しくないか？

発展型として、自己組織化ストレージも作ってみたい。
システムが自分で判断して、効率の良いデータの置き場所やサービスの構成を採ってくれる仕組みも可能ではないだろうか？
ここまで来て、やっとコンピュータの本来の力が発揮できるのではないか、と思っている。

少し前にGoの勉強用で不要なブランチを削除するコマンドラインツールを作ったので簡単にまとめてみます。実際に作ったものはこちらです。
https://github.com/yuzoiwasaki/sweep

使い方

こんな感じで不要なブランチを削除できます。

masterブランチ以外を削除

$ git branch
* master
  test1
  test2
$ sweep
$ git branch
* master

test1ブランチ以外を削除

$ git branch
* master
  test1
  test2
$ sweep -v test1
$ git branch
* test1

test1ブランチとmasterブランチ以外を削除

$ git branch
* master
  test1
  test2
$ sweep -v test1 -v master
$ git branch
* master
  test1

なぜ作ろうと思ったか

Goでコマンドラインツールを作ってみようと思った時に、せっかくなら自分がほしいものを作りたかったからです。

ブランチの削除自体はワンライナーでできますし、エイリアスに登録しておけば毎回わざわざ長いコマンドを入力する必要もないのですが、エイリアスも面倒なのでこういうツールがあっても良いのではないかと思いました。

なんにせよ、何かを作ろうと思った時に自分のほしいものを作るというのは良いモチベーションだと思います（自分がほしいということは、もしかしたら他の人もほしいかもしれないですし）

コード全体

コード全体としてはこんな感じのコードになります。コマンドラインから引数を受け取って処理した後、シェルコマンドを呼び出すシンプルな構造です。

sweep.go

package main

import (
    "flag"
    "fmt"
    "os/exec"
)

type strslice []string

func (s *strslice) String() string {
    return fmt.Sprintf("%v", multiflag)
}

func (s *strslice) Set(v string) error {
    *s = append(*s, v)
    return nil
}

var multiflag strslice

func main() {
    flag.Var(&multiflag, "v", "Specify the branch you want to exclude")
    flag.Parse()

    if len(multiflag) == 0 {
        multiflag = append(multiflag, "master")
    }

    var b, e string

    for _, s := range multiflag {
        b = s
        e = e + " | grep -v " + s
    }
    cmdstr := "git checkout " + b + " && git branch" + e + " | xargs git branch -D"

    err := exec.Command("sh", "-c", cmdstr).Run()
    if err != nil {
        fmt.Printf("Error! Failed to sweep branches.\n")
    }
}

Goには flag というコマンドラインオプションをパースできるパッケージがあるので、こちらを使って引数を受け取り処理をしています。
https://golang.org/pkg/flag/

また、最終的にはOS上でシェルコマンドを実行したかったため、合わせて os/exec もインポートしています。

悩んだところ

flag は便利なのですが、そのままでは同じオプションに対して複数の値を受け取ってパースすることができません。これを実現するためには、少し独自に拡張する必要があります。

flag は flag.Var() を使うことで独自型の変数をバインドすることができます。また flag には Value というインターフェースが定義されているため、このインターフェースを満たす形で型を定義してあげることで独自に拡張することができます。便利ですね。

you can create custom flags that satisfy the Value interface (with pointer receivers) and couple them to flag parsing by

flag.Var(&flagVal, "name", "help message for flagname")

・参考
https://qiita.com/hironobu_s/items/96e8397ec453dfb976d4
https://golang.org/pkg/flag/#Value

終わりに

以上、簡単ではありますがGoでコマンドラインツールを作ってみた紹介でした。もしよければ使ってみてください。

拙作ですが、同じように初めてGoでツールを作る人の参考になれば嬉しいです。今のところ仕事でGoを使う予定はないのですが、これからも趣味で触っていきたいと思います。