100DaysOfCodeを始めよう！
友人から紹介された100DaysOfCodeというものをやってみようと思います。
本日はその準備編の記事になります。
実際の学習とかでなんかあったら多分Qiitaの方に投稿すると思います。
(この辺の棲み分けは正直気分です)
今回始めるにあたってこちらの記事を参考にしました。
進捗記録にGitHubを使うということで、Gitの実践も兼ねてやっていきます。
まずは、公式リポジトリのフォークを作ります。
https://github.com/Kallaway/100-days-of-code
上記のページにアクセスしたら、ログインした状態で画面右上の方にあるForkボタンを押します。
しばらく待つと自分のアカウントにフォークを作ってくれるので、Forkボタンよりもう少し右上にあるアイコンをクリックし、メニューから"Your repositories"をクリック。
すると自分のリポジトリ一覧が出てくるので、100-days-of-codeをクリック。
リポジトリを開いたら、そのページのURLをコピーしておきます。
(後でクローンを作る時に使います)
リポジトリのURLの準備ができたら、エクスプローラでクローンを作りたいフォルダを開いて、そこで右クリックメニューから"Git Bash Here"をクリックしてGitBashを起動します。
(これはGitBash内でcdを使って移動してきてもいいです。)
対象のフォルダで"git clone [リポジトリURL]"を実行します。
※リポジトリURLには先程GitHubで開いたURLを入力します。
あとはリポジトリにある"log.md"を任意のテキストエディタで編集してコミットしてプッシュするだけです。
※言語によってディレクトリが分かれていることに注意。日本語は"intl/ja/"配下。
ログを更新するだけなので、コミットは"git commit -a -m "[任意のコメント]"でいいです。
(クローン作製したディレクトリにいる場合はcdで移動することも忘れずに)
また、コメントには○日目のログってことが分かるようにしておくとよりわかりやすくてよくなると思います。
コミットしたら"git push"でプッシュして、GitHub上のリポジトリに内容が反映されていることを確認します。
進捗記録用のログファイルが更新できていることが確認できたら準備完了です。
あとはこれと同じ要領で同ファイルをプッシュしていけばいいです。
さて、紹介だけして終わらないように気を付けないと...。
ちなみに私は100DaysOfCodeで紹介されているfreeCodeCampを使用してJS→Reactとやっていこうかなと思っています。
2020/9/26追記
自分のやりたいことと合っていない気がしたので書籍を使ってKotlinを学習することにしました。
GitHubの方もKotlinの内容でプッシュしていく予定です。
覚えた内容についてはまとまったら何かしらの形でアウトプットを予定しています。
Dockerを入れてみる話
今回はDockerについてのお話です。
以前からDockerという単語自体を聞くことは多かったのですが、あまり自分にとって馴染みがなかったのであんまり詳しく調べたことはありませんでした。
ただ、最近開発環境とかを手軽に作るために入れておいた方がいいということという助言を頂いたので、調べて自宅環境に導入してみることにしました。
今回作業をするにあたり、こちらの記事を参考にさせて頂きました。
作業時の環境は以下の通りです。
OS:Windows10 Pro (ビルド1903)
RAM:4GB
※マザボが古いのでわりと必要最低限
インストール作業時に再起動が必要になるため、他の作業は並行してやらない方がいいと思います。
まず、インストールのためのPCの準備として
(コンパネの出し方がWin10のビルドverでかなり変わることあるので一応出し方も画像つけておきます)
上図の通りに追いかけていくと出てくる"Hyper-V"のチェックが入っていればOKです。
変更の際にはここで1回再起動が必要になります。
次に、いよいよDockerをインストールします。
まずは配布されているHPへ。
https://docs.docker.com/docker-for-windows/install/
"Download from Docker Hub"をクリック。
"Get Stable"のリンクをクリックしてインストーラーをダウンロードして実行。
チェックボックスは両方とも入れたままの状態で"Ok"をクリック。
インストールが開始されます。
ウインドウのタイトルに出ていますが、この作業時点でのバージョンは2.3.0.5のようですね。
インストールが終わるとインストーラが下図のような状態になり、ここで再起動が必要になります。
再起動から復帰すると"Docker Desktop"というショートカットがデスクトップに作成され、これを起動するとWindowsの通知とともにクライアントが立ち上がる...はずなのですが、ここで問題が発生。
メモリが足りないと怒られていますね。
そりゃ物理メモリが4GBしかないので致し方ないです。
"or change your settings"とあるので設定で対応できるんでしょうか。
(使うOSイメージにもよる気がしますが)
とりあえず設定を見てみましょう。
右下のインジケータの中を探してみるといかにもダメそうな赤いアイコンがあり、マウスオーバーすると"out of memory"と出てきます。
右クリックメニューの"Settings"を選択して設定ウインドウを開き、"Resources"を選択。
とりあえず"Memory"を1.50GBぐらいにしてみます。
バーを操作して調整した後、Apply&Restartをクリックすると、Dockerがリスタートされます。
それでも足りないと同じウインドウがまた出てきます。
最終的には1.00GB(限界)まで落としたら出なくなりました。
(逆にこれでOSイメージ動くんだろうか...。)
とりあえずインストールについてはこれで終了です。
メモリについてはサブ機のSurface君の方が多く積んでるのでそちらでもインストール確認してみます。
2020/9/26追記
SurfaceLaptop2(RAM8GB)ではインストール時の設定(割当2GB)で警告ありませんでした！
さすがにデスクトップのメモリが足りなすぎますね...。
Gitのお勉強 第n+1幕
今回も引き続きGitの話です。
とはいえ前回まで(個人的に)細かく書きすぎたので今回はさっくりまとめたいと思います。
内容的にはシンプルだけど大事なお話であるGitのワークフローについてです。
いきなり初心の話ですが、Gitはバージョン管理ツールであり、その目的は共同作業をサポートするための役割を大きく担っています。
共同作業をするということは多かれ少なかれ複数の人間が携わることになるため、運用に当たって一定のルールというものがあります。
ただ、Gitというものは性質上とてもオープンなものなので、あくまでGit自体に制約があるわけではなく、Gitを採用しているプロジェクトで固有にルールを定めています。
ただそのルールもある程度のベースがあり、それをプロジェクトに合わせてアレンジして使っていたりするらしいです。
(この辺は自分で参画してみないとわからないですね)
で、そのベースというのが有名なところで"git_flow"と"GitHubフロー"というもので、検索するとそれなりに出てきます。
この2つは色々と違いがあるらしいですが、『核となるブランチがいくつあるか』が大きな違いといえます。
具体的には、git_flowでは常に完成リリースのみをマージする"master"ブランチと、そのリリースに向けて実装作業を行う"develop"ブランチの2つがあります。
※名称はプロジェクトによって異なるかもしれません。要は役割が異なる2本のブランチがあるということが重要です。
git_flowでは下記のように開発～リリースの流れを組むことになります。
※途中参画の場合は1からになりますが、一応そこができるまでの流れも記載しています。
0. そもそもリポジトリ自体新しく作る場合
まず"master"と"develop"のブランチを作る必要があります。
リポジトリのルートディレクトリで"--allow-empty"スイッチを付けてコミットします。
これで何もない空コミットが作成できるため、ここをスタート地点として新たに"develop"ブランチを作ることができます。
1. 作業用のブランチを作る
"develop"ブランチを作成できたら、今度はそこから自分の作業用のブランチを作成します。
あくまで"develop"はリリースに向けての共同作業用ブランチなので、そこからさらに個々のブランチを作成する必要があります。
ブランチの名前はプロジェクトによって規約があると思いますが、慣例としては"feature/[対応名称]"という命名になることが多いようです(要調査)
2. 個別ブランチを"develop"ブランチにマージする
さて、実装作業が一通り終わったらリリースの準備です。
前の手順でブランチを分けていたということは、リリース用に再度マージする必要があります。
ここで重要なのが、マージの際に早送りマージを許可しないということです。
早送りマージをしてしまうとコミットの時間をすっ飛ばしてしまうことがあるため、それを避けるために意図的に抑制してあげる必要があります。
早送りマージの抑制には"--no-ff"スイッチを使用します。
後は普通のマージ作業です。
3. "develop"ブランチから"release"ブランチを作る
"develop"に全てマージが終わっても、いきなり"master"にマージするわけでありません。
まずは"release"ブランチを作成します。
この際、ブランチの名前にはリリースするバージョンを明示します。("release-1.0"など)
4. 対象のファイルのバージョンを更新する
ブランチを作成したら、リリース対象のファイル内で記載管理しているバージョンをリリースバージョンに合わせて更新し、それをコミットします。
またテストやバグ修正もここで行いますが、"develop"にはこの段階では戻しません。
5. "master"にマージする
ここまで準備ができたら、ようやく"master"にマージができます。
色々と段階を踏んできているので、ここですることは本当にマージだけです。
6. バージョンを示すタグをつける
マージが終わったら、ブランチ内をログで追いかけやすいように、バージョン名を示すタグを付けます。
また、この時のコミットコメントにもバージョンリリースの旨を記載します。
7. "develop"にマージする
リリースが終わったら、それを"develop"にもマージしましょう。
これで"develop"側も最新の状態に同期できます。
8. "release"を削除する
全て最新でリリースしたら、"release"ブランチは不要となったので削除します。
使わなくなったブランチは削除してクリーンにする、というのがgit_flowの大事な部分です。
ここまでがgit_flowの流れです。
少し面倒な部分もありますが、これにより作業ログは必要なものだけでクリーンになるという大きな効果があります。
GitHubフローの場合
GitHubフローは、核になるブランチは"master"1本しか持ちません。
また、各ブランチを作る際には"master"から直接派生させ、完了後はそのままマージします。
ブランチの削除も行いません。
GitHubフローによる大きなメリットは、迅速性に特化しているということです。
"master"に対して直接マージを行っているため、変更はすぐに反映されます。
それこそ実運用をしているものを直接更新しているわけですから。
git_flowに比べてかなり説明は短くなりますが、それぐらい手順がスキップされているということになります。
それぞれ一長一短なところもありますし、あくまで今回出した2つのフローはほんの一例とのことなので、調べればもっとたくさん出てくると思います。
(今回はできるだけ早い習得のためなので私は割愛してますが...)
Gitはまだまだ奥が深いということを痛感させられる次第です。
あ、結局長くなっちゃいました。
短くまとめるのって難しいですね...。
Gitのお勉強 第n幕
さて、今回もGitについてです。
タイトルが第n幕となっているのは、記事を書く際にベースにしようと思っていたメモが未保存の状態で焼失してしまったからです。
一時的なメモでもちゃんと保存はしようね！
というわけで参考テキストの順番でいうと少し間が飛びますが、
今回はリモートリポジトリとプッシュ/プルの話です。
☆はじめに
ここで扱う操作は、性質上、大元(以下リモート)リポジトリを用意してがっつり操作します。
複数の個別(以下ローカル)リポジトリから順々に操作を実行するため、順番や操作元のローカルを間違えると、意図しない結果が返ってくることがあります。
そうなると当然リモートの状態から作り直しになるため、以下のようなリストアの準備をしておくことを強くおすすめします。
(私はこれに気づかず状況を理解するまで苦労しました)
①作業直前のリモートリポジトリの物理完全コピーを確保する
②同じ状態を作れるスクリプトを用意する
③git bashに打鍵するコマンドをテキストに貼り付けて羅列する(コマンドリスト)
①については、リモートにするリポジトリのフォルダをそっくり丸ごとコピーしておけばいいです。
失敗したらコピーを再度複製してリモートに割り当てましょう。
②については独習Gitでは著者のページに生成用のスクリプトが配布されています。
③については、失敗してリストアした後に原状復帰する用です。
↓こんな感じに並べておけば、後は貼り付けるだけでロールフォワードできます。
画像では要所要所で現状を確認するためのコマンドを入れてます。
また、まとめて流す際には失敗した時と同じ轍を踏まないように注意。
前置きが長くなりましたが、どんどんやっていきましょう。
まずはリモート(神様)を参照先(崇拝)とするクローンを作ります。
ここで先に作るのはベアリポジトリというもので、ベアリポジトリはリモートリポジトリ内で管理しているファイルを直接持ちません。
では何を持つかというと、このクローンはリモートに対する参照情報だけを持ちます。
リモートを神様とするのであれば、ベアリポジトリは神様の使者のような立ち位置です。
神様が信仰者一人一人のお願いを聞いていると内容同士が喧嘩してしまうこともあるため、そこの整理は専属の使者に整理をしてもらい、整理が済んだものだけを受け取っているわけです。
※ベアリポジトリについては独自の解釈をしています。存在と役割についてはこちらを参考にしました。
クローンのベアリポジトリを作るには"git clone"を使用します。
git clone --bare {クローン元URL} {作成リポジトリ名}
作成するクローンをベアリポジトリにする場合は"--bare"スイッチを使用します。
クローン元URLはPC内のローカルであればフルパスorカレントからの相対パスを指定します。
GitHub等の外部ネットワークがソースとなる場合は、そのURLを指定します。
作成リポジトリ名はベアリポジトリの場合は末尾に".git"をつけるのが慣例のようです。
(システム上エラーとなるわけではない)
クローンのローカルリポジトリ(※)を作るのにも同じく"git clone"を使用します。
git clone {クローン元URL} {作成リポジトリ名}
先程のコマンドから"--bare"が消えただけです。
ただ、ベアリポジトリを使用する場合はベアリポジトリがクローン元となるため、実際にはクローン元URLはベアリポジトリのリポジトリ名となることが多いです。
(実行時のカレントパスによります)
"git clone"はクローン元のURLが存在しなかったり、作成しようとしているクローンの名前が既に存在したりするとエラーになります。
※厳密にはベアリポジトリも大元のリポジトリのローカルリポジトリですが、区別のためにあえてこう表現しています。
クローンを作成したらクローンのリポジトリ内で"git remote"を使用すれば指定されているソースを確認できます。
git remote -v show [{リモート名}]
リモート名は省略可能ですが、指定すれば紐付くリモートのブランチ情報が確認できます。
また、逆に省略時はリポジトリに紐付くリモート名が全て表示されます。
クローン名はデフォルトで"origin"が使用されていますが、これも"git remote"で変更ができます。
git remote rename {変更前の名前} {変更後の名前}
また、対象のリモートを追加する場合にも"git remote"を使用します。
git remote add [追加するリモート名] [リモートのソースURL]
リポジトリが参照するリモートのリファレンス一覧を見たい場合は"git ls-remote"を使用します。
git ls-remote ([対象のリモート名])
一通り確認することが終わったら、リポジトリ内でファイルを編集したり作業をしてみましょう。
コミットまでは各リポジトリ内だけで完結できるので、作業が終わったらリポジトリ内にコミットをします。
コミットが終わったら、いよいよリモートにプッシュをします。
最初の例でいえば、神様に奉納をするわけです。
プッシュは下記のコマンドで実行します。
git push ([リモートのブランチ名] [ローカルのブランチ名])
ここで、カレントのブランチ名とリモートのブランチ名が同じ場合は引数を省略して"git push"だけで実行できます。
カレントと違うブランチ名にプッシュする時は指定してあげないといけません。
また、プッシュしようとしているブランチに自分が持つコミットよりも新しいコミットが存在する場合、ローカルブランチに更新がなくても(プッシュする内容がなくても)"git push"はエラーになります。
この場合、ローカルブランチとリモートブランチで一度同期をとる必要があります。
リモートと同期をとるには"git fetch"と"git merge FETCH HEAD"を使用します。
"git fetch"を使用すると、リモートの最新コミットを"リモート追跡ブランチ"としてカレントブランチの最新コミット"に取得します。
これは、ローカル側から見れば1つの新たな分岐を持つブランチということになります。
またこのブランチのHEADは、マージするまで"FETCH HEAD"という名称で管理されます。
("git merge"の引数に出てくるのはこのためです)
もしローカルブランチに更新そのものがなかった場合、リモートに合わせて"早送りマージ"が実行されます。
これは"git merge"の挙動の1つで、更新がないのでそこは飛ばして最新コミットの整合だけを合わせる、最新のコミット時間を先に進めるだけの処理をしているので早送りと呼ばれているようです。(公式用語)
ローカルブランチに更新がなければ無事にローカルへ早送りマージされますが、もし更新に競合があった場合はそうもいきません。
その場合は自動または手動でマージを実行する必要があります。
Gitのアルゴリズムで変更箇所がないと判断された場合、"git merge"は自動で内容のマージを行い、マージしたことをローカルブランチにコミットします。
(もちろん、コミット後にはリモートへのプッシュが必要です)
同一行に別の内容で更新があった時など、Gitが自動でマージできなかった場合には手動によるマージが必要です。
手動でマージした後、自動でマージした時と同様にコミットとプッシュを行いましょう。
もちろん、プッシュの内容によっては別のリポジトリでは同様にマージ時に修正が必要になることもあります。
リモートに余分なブランチをプッシュしてしまった場合は、削除したことをプッシュすることでリモートブランチを削除できます。
そのためにはローカル上で削除したという情報を作らないといけないため、まずは先にローカルでブランチを削除します。
git branch -d {ブランチ名}
ローカルからブランチを削除したら、次にリモートにもその情報をプッシュしましょう。
git push {リモート名} :{ブランチ名}
ここでブランチ名の前に付いているコロンが重要で、"git push"の最後の引数の入力形式となっています。
入力形式のフォーマットとしては"{ソース(src)}:{反映先(dest)}"となっており、ここではdestのみ指定することで、ブランチの削除(ソースなし)という情報をリモートにプッシュしています。
タグの場合もブランチの時とフォーマットはほぼ一緒ですが、操作の順番が異なります。
リモートにタグを作成する場合はまずローカル側でタグを作成し、それをプッシュします。(タグ名を決めないとプッシュできない)
git tag -a {タグ名} -m {コメント} {タグ作成位置}
git push {リモート名} {タグ名}
リモートからタグを削除する場合は、コマンドはブランチと同じフォーマットですが、リモート⇒ローカルの順番で削除を実行します。
git push {リモート名} :{タグ名}
git tag -d {タグ名}
長くなりましたが、最後がプル(フェッチ)です。
プルは英語そのままプッシュと逆の操作で、リモートの情報をローカルに取り込みます。
ただし、プッシュの数倍は面倒臭いです。
というよりも、実際の操作的にもプッシュでこける原因がプルだったりするので、プッシュの面倒臭い原因のほとんどがプルが持ってるようなものだと思います。
何が面倒かという話に入る前に、まずプル自体について。
プルは先程出てきたフェッチとマージをセットにしたようなコマンドです。
フェッチは最新コミットに勝手にブランチを作ってくれるだけなので、問題はマージです。
マージは早送りだったりGitが自動でやってくれたりすると楽ですが、手動だといちいち確認して編集してあげないといけません。
Git自体が共同作業用の支援ツールなので仕方がないことですが、やっぱり競合のマージは神経も使って面倒なものです。
だから結構苦労するんですよね。
そしてプルがプッシュの原因となる理由ですが、プッシュしようとしたときに(コミット履歴に競合が起きていて)プッシュができないということが多いからです。
履歴の整合性を保つために一度ローカルを同期してからということになりますが、結局競合が発生する可能性はそれなりに高いと思います。
なのでプルには頭を悩ませることが度々あるようです。
ちなみにプルは"git pull"で実行できますが、これの実行はあまりおすすめされていないようです。
というのも、そもそも"git pull"自体が"git fetch"⇒"git merge FETCH HEAD"のセットコマンドで、"git merge"で想定しないマージを行ってしまうことがあるからということです。
この問題を解決するために、"git fetch"の後に"git diff HEAD..FETCH HEAD"を実行して差分を確認するという方法が推奨されており、特に初心者ほど不用意に"git pull"を使用しない方が良いらしいです。
まあ確かに実際に差分を取り込むなら中身は確認した方がいいですよね。
というわけでかなり長くなってしまいましたが、ローカルからリモートへ操作をするGit処理のお話でした。
☆余談☆
今回はリモートリポジトリを使用するということで複数の物理ディレクトリに対して(間接的に)変更をかけているわけですが、これらのリポジトリを1つの親フォルダで管理しておくと、git bashを実行した時にブラウザでフォルダを開いておけば更新時間からフォルダを操作しているのが見れて、ちゃんとリポジトリがリンクされてるってことが確認できます。
努力の美徳と錯覚
今回は自己啓発用のメモになります。
また、今回のメモをはじめ当ブログは自分の振り返り用のメモや備忘録であり、
自分と同じような境遇に陥っている人が動き出すきっかけや動く際の行動心理に繋げられたらいいなと思って記載しています。
まだ自分自身が動きながらのためここに書いてあることが正しいというわけではないですが、同じ心境の人に届けばいいなという思いです。
前置きはここまでにするとして、今回は努力に対する美徳感覚に対しての話です。
これまで自分が生きてきた状況を細かく説明するとそれだけで記事になってしまうので今回は端折りますが、ざっくりと概要を説明すると、
1.学生時代は全然勉強してこなかった(自主的に勉強する習慣がなかった)
2.部活とかも特に打ち込んでいない
3.そもそも大学行ってない(ただし、完全に後悔しているわけではない)
4.卒業してからも現状維持でダラダラと過ごしている
5.やりたいことは特にない
重要なポイントを搔い摘むとこんなところです。
まあよくいる底辺人間ですね。
イメージとしては、Fラン大学の学歴を借金して買っていない、ニートではなくて自分で生計は立てているぐらいの立ち位置です。
こんな経歴を辿ってきている自分なわけですが、このままだと将来がないということと、最近は年齢的に何かをできる期限が迫ってきていることから、今の状況を打開すべく、怠惰という底なし沼を抜け出すために行動を起こしています。
(Gitの話もその一環です。)
とはいえそこは今まで何もしてこなかった人間。
勉強とか効率とかもとんでもなく悪く、なかなか進捗が上がらないのが現実です。
色々と更生のためにサポートを受けている友人からも厳しい一喝を受ける始末。
まあ自分が悪いのは分かっているのでしょうがないんですけど。
これぐらいやらないと変われないのも分かっています。
ただまあ、こういうことを周りに相談すると、大体の人が決まって口を揃えるのが
「やること自体に意味がある」
「やってるだけ十分」
「やらないよりよっぽど良い」
という、ポジティブな表現です。
自分も逆の立場だったら言ってると思います。
しかしこの言葉、ポジティブで好意的な印象ですが、実はその裏には無責任な暴力も含まれています。
環境や内容にもよりますが実際には結果主義であることが多く、そこに至るまでのプロセスは考慮されないということです。
例えば試験なんかは、合格基準に満たなければそこにいくまでにいくら努力していても決して合格にはならないです。
本来仕事での評価も一貫してそうあるべきで、やろうとしていること、やるべきことができたかどうか、それが評価の基準となるわけです。
しかし周囲の人というのは「そこまでやったのなら十分だ」とか「やろうとしているだけ立派だ」とか、当人からしてみればあまりにも無責任な言葉を投げつけます。
本来建設的に考えるのであれば「何が足りなかったのか」や「現実的に本当にできることなのか」とか、そういったアプローチをかけるほうがよほど効果的です。
もちろん本人の行動内容や心理についてどれほど知っているかによっても変わってきますが、全体的に努力すること自体への美徳意識が強すぎると思います。
また、これによってまだ成果もあげていないのに「自分は頑張っているんだ」と錯覚してしまうことがあるのも事実です。
(少なくとも自分はそのタイプです。偏見だったら指摘してください)
もちろんそこを錯覚してしまうのは自身の弱みでもあるのですが、あまり無責任に「君は頑張っているよ」というのも良くないのではないかと思います。
とはいえ自分自身も同じ感覚を持ってしまっているため、少しずつでも意識を変えていけるよう努めていきたいと思います。
Gitのお勉強 第2幕
さて、今回も前回に引き続きGitのお話です。
独習Gitでいう第7章に相当。
前回と同じく自分の中での情報整理用です。
まず今回初めて知って驚いたのが、Gitではコミットする内容部分を選択することができるということ。
これまたSubversion(以下svn)との比較になってしまうのですが、svnだとファイルをドカッと丸ごと同期させる形でリポジトリにコミットするんですよね。
だからsvnを使用した管理だと開発中に仮にデバッグ用のコードとかを入れた場合はコミットする時には消さないといけないわけです。
ところが、Gitではコミット時に必要な部分だけを選択してコミットすることができる。
これでデバッグコード等を(自分の作業環境にある)ソース本体から物理的に削除する必要がなくなるわけですね。
なんだかんだそういうデバッグコードってその修正をコミットした後も再利用したくなる時って結構あるんですよね。
コミットする度に(コミット用に)デバッグコード消して、作業環境でもう1回復活させて、なんてやってたらはっきり言って手間でしょうがないです。
こういうところがスピード感が大事になるアジャイル開発では必要になる要素なんだと思います。
(実際にやったことないのでわからないですが)
ただし、この部分コミットはあくまで手動で選択するわけなので、コミット漏れはないように気を付ける必要があります。
前述のように自分の環境でだけ残したいものを意図的にコミット対象から外せるため、必要な処理をコミット対象から外してしまい、自分の環境では問題なく動く(ソースが完全)が、リポジトリをチェックアウトした他のユーザーからは動かない(ソースが不完全)といったことも起こりえるわけです。
少し極端な例えですが、以下のような場合が挙げられます。
●自分の作業環境にあるソース(正しく動く)
int a = 1;
int b = a * 2;
System.out.println(b);
int b = a * 2;
System.out.println(b);
1行目の変数aの宣言をコミットしなかったため、2行目のaが正しく代入できずにコンパイルエラーとなってしまいます。
このため、選択コミット時にはよりコミットチェックが難しくなりますが、全体的にはとても便利な機能です。
また、慣れればコマンドラインでやった方が早いと思いますが、慣れないうちはgit guiを使用してGUI環境でやる方が安全で直感的に作業できます。
行をクリックして選択していく感覚はWinMargeを使用してソースを差分単位でマージする時の感覚に近いです。
GUIではなくコマンドラインから作業する場合は"git add -p"を使用します。
すると差分情報やらが出力された後に選択を要求されますが、テキストエディタを使用する場合は"e"を使用します。
(ちなみに、ここで出る差分情報は"git diff"を使用した時と同じ内容です)
この操作をする場合はGitに紐付けているテキストエディタで編集することができるので、自分の使いやすいエディタを設定しておくのもいいと思います。
(自分はインストール時に知らずにVS Codeを設定していてそのまま使用しています。デフォルトだとこれまたLinuxで頻繁に使われるviになるようです)
エディタで編集する場合は直接のテキスト操作になるので、ソースから不要部分をまるっと削ぎ落とす形の作業になります。
他の選択オプションについては別の機会でまたまとめようと思います。
(ここまでで少し長くなってしまったので)
Gitのお勉強
最近、周りからの助言でGitの勉強をやっていまして。
助言と併せて参考になるテキストも提示してもらったので、今はこれを使って学習を進めています。
※宣伝ではない。
先述の通り参考テキストを使って少しずつ学習している最中なわけですが、ここまでで気付いたことと言いますか、知らなかったことやイメージと違っていたことをまとめてみます。
日頃からGitを活用している方々にとっては至極当たり前のことだと思いますが、初めての自分にとってはかなり衝撃な部分だったので、どうか初心者を見守る生暖かい目で眺めて頂けると幸いです。
オフライン環境でも作業ができる
本書の入門部分の解説でも強調されていましたが、ネットワークに繋がっていなくてもリポジトリ内の作業ができるんですね。
この辺はどうしても自分の中ではSubversionのイメージが強いといいますか、集中管理型のシステムだとその管理している中枢(リポジトリ)と通信をしていないといけないわけなので、そもそもオフラインでリポジトリの情報を管理できるのは何度聞いても不思議な感覚です。
コマンドラインの操作が多い
これも意外なことでした。
仕事でSubversionを扱う時にはTortoiseを使うことがほとんどだったので(というかだいたい何処もそんなもんじゃないだろうか)、同じようにGUIで作業することになるものだと思っていました。
しかし自分の思っていたものとは裏腹に、実際にGitを使う場合はかなりのケースでCUIでの作業になるようです。
(これは本書内でも度々強調されているし、周りに聞く限りでも同じ意見でした)
シェルコマンドが度々出てくる
これはコマンドラインの話と重なる部分もありますが、Linuxで使うシェルコマンドが度々使用されます。(cd, lsなど)
そもそもWindowsで使用する場合はGitBashっていう如何にもな名前のアプリで操作しますし、UNIX/Linuxではターミナルから直接コマンド叩いて実行してます。
(自分の手持ち環境ではWinしかないので実際にUNIX/Linuxで操作はできていませんが)
なので、普段からUNIX/Linuxを使用しているかどうかでかなり操作への馴染みは変わってきます。
逆にあまりLinuxを触る機会がない場合(自分のようなケース)でも、Gitを扱うだけで簡単な操作ならいい練習になると思います。
それと、Git用のコマンド(git ●●)もシェルコマンドに準じたコマンド名があります。
(git mv, git rmなど)
今の段階でまだわからないこと
少しずつ学習を進めているわけですが、どうしても今の段階でまだ分かっていない、というより挙動は分かったけど納得できていないこととして、分散型でどのようにマスターを管理しているのか、というところがあります。
確かにそれぞれのローカルにリポジトリを用意してローカル内で作業記録を管理していることは分かったのですが、グループワークとしてどのように管理しているのか、という部分は依然として謎のままです。
1つのファイルに対して複数人で作業をすれば、当然基準となるマスターが必要になると思うわけですが、それをどのようにして実現しているのか...。
まあこの辺はまだ学習自体が途中なので核の部分に自分が触れられていないだけなのかもしれません。
そのうちGitHubの話も出てくるはずですし、今後の楽しみとしておきましょう。
それにしてもどうなってるか全然想像もつかないので、最初にGitの考案をした人は本当にすごいと思いますね。
以上、現段階でのGitで知ったことについてでした。
