Gitつらい - 恋しい日々
GUIクライアントを使っている人にGitの扱い方を教える機会というのがここ数年たびたびあって，最初のうちはGUIアプリわからんし，，，とかいってぽーいとぶん投げていた．途中から良くないなと思いGUIアプリとかも見ながらやってたんだけど，いろいろつらい． どういうことかというと，Gitってソース管理の複雑性を解決しないまま，そのまま複雑なソフトウェアとして落とし込んでいて，使う側に学習を強いるアーキテクチャだと思っていて，根本的にはこれがつらい．ソフトウェア書いてるとソースコードの管理が簡単じゃ無い問題なのわかってるから，使い方覚えるモチベーションもあると思うけど，ソフトウェア書いてない人たちが使おうとすると，なぜ複雑なのかを覚えたり学んだりするところからになる．これは通常であれば完全に無駄なコストで，ノーメリットであると言える．もちろんそういうのすっ飛ばしてコマンドだけ教えても良いのだけれ
コミットログを綺麗にする努力をする。 - パルカワ2
綺麗なコミットログとは 綺麗なコミットログとは、コミットログを見返す時に知りたい事を知れる。 コミットログを見返す時は、「なにをしたのか」と「なぜその変更を行ったか」を知りたい。つまり、「なにをしたのか」と「なぜその変更を行ったか」を書けば綺麗なコミットログになると言える。 ファイルを変更した場合 一行目：「何」に「どういった」変更を行ったかを簡潔に書く（要約） 二行目：改行がないとおかしいことになるので、二行目は必ず改行する 三行目以降：一行目に書いた変更を「なぜ」行ったかを書く 例 HogeViewはpiyo時にfugaするように変更 fugaしないと〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜が起きて 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜で 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜なので フィードバックの対応などした場合 一行目、二行目は、変更した場合と同じ 三行目以降：フィードバ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
