- Git 12©2ch.net
696 ：デフォルトの名無しさん[sage]：2015/06/13(土) 01:44:19.98 ID:2XvJk2DZ - >>689
えとさぁ、見苦しいよ。
人のコメントを引用して、
そのことについて、何が間違ってるかを
何一つ書かないで、言い返した気になるのは。
|
- Git 12©2ch.net
697 ：デフォルトの名無しさん[sage]：2015/06/13(土) 01:47:39.52 ID:2XvJk2DZ - >>691
> 俺「俺がその管理者なんだよ〜。どうやってルール決めればいいかわかんねーよ」
社内に詳しい人がいないなら、社外の知識を利用すればいいのでは？
最近はオープンソースでgitでどういうコミットをしているのか
見ればすぐにわかるし、資料も多いし、２ちゃんねるでもこっちのスレで詳しくやってるよ。
Gitをより良くするための運用ガイドライン作成スレ [転載禁止](c)2ch.net
http://peace.2ch.net/test/read.cgi/tech/1433650988/
|
- Git 12©2ch.net
698 ：デフォルトの名無しさん[sage]：2015/06/13(土) 01:50:44.54 ID:2XvJk2DZ - >>693
> 外部の刻々と変わる環境に対して、
それはわかる。単にコマンドを覚えるだけじゃなく
gitの外部の環境＝ソースコードに応じて
適切な順番と内容で対応を変更して実行する。
これはコマンドを覚えるだけじゃ出来ないからね。
それは他の人のコードのブランチをレビューしていて
痛いほどよくわかってる。コマンドを使うことは出来る
だけどあるべき姿のものを作れない。
|
- 【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ50【php,py,pl,rb】 [転載禁止]©2ch.net
248 ：デフォルトの名無しさん[sage]：2015/06/13(土) 01:53:18.88 ID:2XvJk2DZ - >>229
> Swiftはとっくの昔から流行ってる印象だし、
2014年6月リリースのSwiftはとっくの昔とは言わない
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
41 ：デフォルトの名無しさん[sage]：2015/06/13(土) 12:33:55.09 ID:2XvJk2DZ - >>39
それがコミットを意味がある単位で細かく分けろって話にもつながるんだよね。
バグをどうリリースするかはバグの内容による。改良のリリースも同じ。
緊急で出さなきゃいけないものは緊急で出す。
そういうのは見つかった段階ですぐに対応しなきゃいけないから
最新のリリース版からブランチを切って作ったブランチをリリース版にマージ。
そしてそれを開発版にもマージって流れになるだろうね。
あとはブランチ（＝バグや新機能）をリリースしたい順にマージ[*]していけばいい。
よくあることだが、新機能がバグの修正に依存しており、新機能の作成中に見つかった。
という話しなら、先にバグを直して（バグ修正ブランチを作ってマージ[*]）、
そこから新機能を作ったことに歴史を書き直せば良い。
[*] の部分だがどこにマージするかは方針と内容次第。
すぐにmasterにマージすることもあるし「次期バージョン」という考え方を
しているのなら次期バージョンブランチを作って、そっちにマージしていって
リリース時にmasterにマージを行う。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
42 ：デフォルトの名無しさん[sage]：2015/06/13(土) 12:40:50.27 ID:2XvJk2DZ - ただし大型新機能の開発が複数並行で進んでおり、両方が同じ部分を修正する
可能性が有る場合、大量のコンフリクトが起きる可能性があるので注意する必要がある。
これを避けるために新機能が完成するまで新機能の内容を"全て"マージしない
という考え方を変える必要がある。
多くの場合、新機能の開発の中には、既存バグの修正やリファクタリング
モデルや汎用ライブラリなどの機能追加（仕様変更ではなく）が含まれる。
これらは先にリリースしても問題ないはず。全てマージしないのではなく一部だけマージする。
だから新機能の開発を行っていたとしても、そのなかで先にリリースできるものはリリースしておく
（次期バージョンブランチがあるのならそっちにマージ。次期バージョンブランチと新機能ブランチは別ね）
こうすることでいち早く大型新機能開発はコンフリクトが起きかねない部分を知ることができるし、
相手の開発した部分を利用することも可能になるから、同じものをそれぞれで作ってしまう無駄も省ける
大型新機能開発を行っていたとしても、小さな開発とリリースという形に変更していくことは可能なんだよ。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
43 ：デフォルトの名無しさん[sage]：2015/06/13(土) 12:44:26.69 ID:2XvJk2DZ - 自己レス
> それがコミットを意味がある単位で細かく分けろって話にもつながるんだよね。
この話につながっていなかったｗ
まあわかるとは思うけど、このように開発の順番とマージやリリースの順番を
自由に入れ替えるってことは、それぞれのコミットが意味のある単位で
細かくまとまってなきゃいけないんだよ。
無関係の修正が一つのコミットに混じっていたり、
関係あるコミットが複数に分かれていたりしたら
それを見つけるのが大変になる。
ちゃんとコミットが分かれていれば、開発した順番ではなく
望む形に入れ替えたりすることがしやすくなる。
|
- 【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ50【php,py,pl,rb】 [転載禁止]©2ch.net
255 ：デフォルトの名無しさん[sage]：2015/06/13(土) 14:56:05.76 ID:2XvJk2DZ - 早いってことは、
そんなに昔ではなく
短いってことじゃんｗ
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
46 ：デフォルトの名無しさん[sage]：2015/06/13(土) 19:15:52.26 ID:2XvJk2DZ - >>44
たしかにね。最初はちょっと難しかった。
コード修正中に関係ないことをついついやってしまうしｗ
そこは慣れだよ。意識してコミットを小さくするようにしていけばいい。
まず覚えるべきなのは、git add -pだね。
これができると一つのファイルの中の一部分だけコミットできる。
あとはコミットの順番は後から並び替えられるし、まとめることもできるので
順番は気にせずにほんとうに小さくコミットを作ること。
そして後からまとめて綺麗にしようと考えずに、常に片付けながら作業（開発）すること。
後からまとめてコミットを綺麗にしようと思って、そこで何したか忘れるんだよｗ
大きな開発を複数人でスムーズに行うには、共通のソースコードへの修正の
反映作業が重要だからね。大きな開発も小さく修正していくことで管理可能になる。
それを実際にやってるのを見れるのがgithubとかなんで（まともなプロジェクトの）
リポジトリを参考にするといいよ。
|
- 【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ50【php,py,pl,rb】 [転載禁止]©2ch.net
258 ：デフォルトの名無しさん[sage]：2015/06/13(土) 19:28:26.23 ID:2XvJk2DZ - じゃあ客観的に長さを比べましょう。
Swift リリースから1年
JavaScript リリースから20年
Ruby リリースから20年
PHP リリースから20年
Perl リリースから28年
Swiftがとっくの昔から流行したというのなら、
何年・・・にも到達してないからｗ、
何ヶ月前から普及していたと思うのか？
○ヶ月も昔から普及していた！と
ドヤ顔で語るが良いｗ
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
48 ：デフォルトの名無しさん[sage]：2015/06/13(土) 19:51:47.81 ID:2XvJk2DZ - >>47
だからgitだってｗ
gitを一番うまく使ってるのは
gitプロジェクトに決まってるでしょｗ
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
51 ：1[sage]：2015/06/13(土) 22:30:36.68 ID:2XvJk2DZ - >>49
残念ながら知らない。日本の本に関しては、最近出た2,3冊は内容を確認してないけど、
それ以前のものに関してはgitの使い方ぐらいだったな。それはそれで最初のうちは
役に立つんだけど。海外の本に関しては、読んでないので知らない。
代わりに日本と海外（アメリカ）の考え方の違いの話をするよ。
よく言われていることだけど、海外はパッケージの導入を積極的に行うけど、
日本は独自で作ったりパッケージをカスタマイズすることを望む。
この考え方の違いというのは、日本は自分のやり方を通そうとするということ。
日本の文化だと、アプリにがあれもこれもなんでも出来るようになってしまう。
それは一見便利なように見えるけど、業務を改善（＝変えていく）ことにはつながらない。
やり方を変えずにツールを変えるだけだから生産性は上がらない。
海外のソフトウェアっていうのは、業務を一番効率的にやれるのはどういうものか？
という考えを形にしたものなんだ。もちろんその考え方はいろいろあって正解とは限らないけど、
少なくともソフトウェアっていうのは、開発者が想定した正しい使い方っていうのがあるんだよ。
つまり俺の考え方というのは、ツールの正しい使い方というのを学習していくことでできたもの。
ツールにはできること、できないことってのがあるけれど、思いつくまま実装されたのではなく、
正しい使い方をするのに、必須だから追加した機能であり、邪魔だから追加しないと考える。
例えばgitには歴史を改ざんできる機能があるでしょ？ これは正しく使うのに必須だから。
ファイルをロックして他人が編集できないようにする機能はないでしょ？
それは正しく使うのに邪魔だからあえて搭載しないことを選んでいる。
この開発者の考えに、自分の考えが適合してくると、「こんな機能があったほうがいいんじゃないか？」って
思ったものが次期バージョンに搭載されたり、議論が行われていたりする。
考え方が合わない最初のうちは、なんでこうなってるんだ？使いにくい！って思うかもしれないけど
そうではなく意味があってやってることだと考え、何故そうなっているかを考えていくといいよ。
|
- Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
52 ：デフォルトの名無しさん[sage]：2015/06/13(土) 22:43:28.86 ID:2XvJk2DZ - >>49
もう一つgitよりの話をすると、gitは誰が何故作ったのかを考えればわかると思うよ。
リーナスがソフトウェアを開発するために作ったよね？
そう、開発者のものなんだ。
開発の進捗を知るためのマネージャーのツールでもないし
ソフトウェアのロストを怖がる管理者のツールでもない。
ソフトウェアの開発、しかもそれを多くの人が関係するってことは
正しい修正であるかどうかを判断するには、ソースコードを読まないといけない。
頭数を揃えてテストしたって、正しい修正であるかなんてわからない。
どっかの金もってる大会社じゃないんだから、頭数自体揃えられないけどｗ
そういう文化にとって「テスト」とは誰でも（一人でも）テストの実行を再現可能な
テストコードであり、そのテストコードが正しいかどうかは、読んで判断するもの。
それ以外できっこないんだから。これは現実。
そこまでわかれば、あとは何が必要かがわかる。必要なのはコードが読みやすい
コミットであり、必要なツールは読みやすいコミットを作ることが出来るもの
そういう考えでgitが必要とされ生み出された。あとはそのgitの正しい使い方を理解していくだけだよ。
ただ一つだけ俺がラッキーだったのは、gitを知る以前から、読みやすいコミットの重要性を理解していたことかな。
完成されたソースコードだけじゃなくて、修正の内容とその過程自体もわかりやすいことが重要であると。
だから俺にとっては、gitは俺が考えた理想を実現するツールだったね。
|
- 【JavaScript】ｽｸﾘﾌﾟﾄ ﾊﾞﾄﾙﾛﾜｲﾔﾙ50【php,py,pl,rb】 [転載禁止]©2ch.net
263 ：デフォルトの名無しさん[sage]：2015/06/13(土) 22:54:37.74 ID:2XvJk2DZ - >>259
いつ抜いたんだよｗ
そんな話題聞いたことすら無いわｗ
|