トップページ⇒tech
983コメント406KB

Git 12©5ch.io

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん 転載ダメ©2ch.net2015/03/23(月) 13:35:13.83ID:aBYp+bVs
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - Fast Version Control System
http://git-scm.com/

◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/

◆前スレ
Git 11
http://peace.2ch.net/test/read.cgi/tech/1416195050/
0516デフォルトの名無しさん2015/05/21(木) 22:28:03.52ID:fr6zPWaF
Windowsでウィルススキャンソフトが入ってる状態でgit checkoutは時間がかかり過ぎるから、使いづらく感じるかもな
0517デフォルトの名無しさん2015/05/22(金) 00:01:21.71ID:6DaqA/5u
>>515
リーナスだろうと関係ないよ
リーナスには使いやすいものでも
俺には使いにくいってのは普通にあるよ
0518デフォルトの名無しさん2015/05/22(金) 22:43:05.39ID:SSdLqWaE
>>508 ブランチってほんとにみんな使ってる？
俺は一人開発だけど、master と daily の二つの branch を使っているよ。git 使い始
めの一年ぐらいは master だけだったけど。

master の commit/merge は version 番号より少し細かい粒度で行っている。daily
branch は bug/issue tracking の粒度より少し細かいぐらいで commit している。とい
うより、daily branch の commit message の殆どは bug/issue 番号に紐付けている。
Version 番号の粒度の履歴に bug tracking 粒度の履歴を残したくない。

ちなみに bug/issue tracking はソースとは別ディレクトリのテキスト・ファイルで
git 管理している。


>>508 gitのブランチって使いづらくね？
Time stamp が checkout 時刻に強制変更されてしまうのが使いにくいと感ずる。make
compile 時の便利さは分かるが、ファイルの time stamp 自体は重要な属性だから。俺
が git を作ったならば、time stamp を commit 時の時刻にするオプションを絶対設け
ていた。

実際には commit 時刻に変更する script を書いてあるけれど、殆ど使っていないの実
情だ。その script が必要になるのは master 側だけだから。そして その master 側で
push するときには、time stamp など構っていれらない状態が殆どだという実情なのが
情けない。
0519デフォルトの名無しさん2015/05/23(土) 16:05:57.79ID:4OfmjrZC
プロジェクトがすごく小さい場合には、
途中経過の整合性が合わなくなるのが許されたり、
途中経過の整合性を合わせるためのテストやり直しが許されることがあるんだな

pushした修正がバグってたからって、pushしたもんをリベースで打ち消すのはご法度と思っていたが
プロジェクトの大きさによってはそれもあり得るということか
0520デフォルトの名無しさん2015/05/23(土) 17:21:41.69ID:x743ZDZ3
pushした先がリベースが許されるブランチかそうでないブランチかって違いであってプロジェクトの大きさは関係ないんじゃないの？
0521デフォルトの名無しさん2015/05/23(土) 17:24:16.06ID:x743ZDZ3
いや逆か。
push後のリベースが許されるブランチを運用出来るように、プロジェクトをサブプロジェクトに分割したほうがgitを有用に使えるってことなのかもね。
0522デフォルトの名無しさん2015/05/24(日) 00:38:55.87ID:NuukhrjT
push後のリベースが許されるブランチ＝他の誰も見ていないブランチ？
サブプロジェクトどころか、一人プロジェクトだな
0523デフォルトの名無しさん2015/05/24(日) 10:38:28.38ID:GI5iGoR+
話題がループしてるな。もうすこし世の流れを学んだ方がいいよ。
gitだと特に、ブランチの運用によって前提が大きく変わる。

GitHub flowならチケット1つにつき1つ（1バグにつき1つ）ブランチができるから、
それぞれのブランチの寿命は数分〜長くとも数日程度であって、その間はブランチ上では基本1人でしか変更しない。
だからpushしたブランチをrebaseしてもまったく問題ない。
むしろレビューで指摘されたようなtypoや微修正が残ってると後で見にくい。積極的にrebaseを使ってほしい
0524デフォルトの名無しさん2015/05/24(日) 11:16:37.86ID:VWanxcqX
>>522
ん〜と、前提が大ブランチになってるとそうかもしれないけど

Gitの得意技は作業単位で小さなブランチを山ほど作れる所にあるから
得意技を積極的に使った方がお得な気がするな


うちのチームは去年強制的にsvnからgitに移行してからコミット数もブランチ数も20倍くらいに増えた

その代わり、細かくコミットしろ、作業単位でブランチを分けろ
って、半年くらいは口うるさく言い続ける必要があったけどね

レビューの時にコミットツリー図を見ながら
ここはこういう意図で、こういう風にブランチを分けて欲しかった、とか
ややこしいコンフリクトが生じた時に
どういう手順ならマージが簡単だったかとか
具体的に教えたり、みんなで考えたりした

新しい文化を根付かせるのは大変だよ、いつでもさ
0525デフォルトの名無しさん2015/05/24(日) 14:14:44.04ID:J9ZjzLe3
>>523 だからpushしたブランチをrebaseしてもまったく問題ない。

branch を push する意味が理解できん。数分から数日しか存在しないブランチを何処
に push するの？

レビューアーの git に同じブランチを設けてリモート・ブランチにしているの？
0526デフォルトの名無しさん2015/05/24(日) 15:41:15.45ID:1k2HbjOC
ブランチを公開する際に中央リポジトリにpushする形式が考えられる
0527デフォルトの名無しさん2015/05/24(日) 19:35:16.30ID:LHzJ6dIN
今コミットした後にgit pullしたらリモートの最新のログ（1個だけ）が追加されてしまいまして
今コミットしたログの後にそのリモートのログが来てしまいました
git rebase -iで今コミットしたログを最新にしたいので順番を書き換えたいんですがリモートのログが表示されません。ローカルのログしか表示されません
git rebase -i HEAD^^^^^^みたいに^を増やしても出てきません
これってどうしたらいいんでしょうか？
0528デフォルトの名無しさん2015/05/24(日) 19:41:30.07ID:Ewhf1zLw
>>524
となると、やはり 本体はSVNで、ローカルはgitで
別に管理したほうが全体が幸せになりそうだな
0529デフォルトの名無しさん2015/05/24(日) 19:50:34.06ID:Jl9gFOkM
レビューが終わって共有ブランチにpushしてからバグが見つかった場合に
共有ブランチ上でrebaseするんだったら、ブランチの生存期間を超えて共有ブランチ上で修正を続けているように見えるな
0530デフォルトの名無しさん2015/05/24(日) 20:03:35.12ID:Jl9gFOkM
>>528
この人の場合、バグを修正したというコミットをmastarに残したくないのに、SVNだとコミットを後から修正できないのが不満だ
（それがレビューの邪魔？）というのが、gitを使っている一番の理由だろう
0531デフォルトの名無しさん2015/05/24(日) 21:34:38.73ID:VWanxcqX
>>528
それはいい解の一つだと思う。特に移行期には。
うちも、svnから一気にgitに移行するか、git-svnを使うか結構悩んだ。

でも最後は俺がsvnとgitの両方を使うのが面倒くさいという判断で一気にgitに移行する方を選んだ。
当時の対象プロジェクトがちょうど区切り良く、
過去ログを捨てて一気に乗り換えることができるタイミンングだったのと、
フロアをまたがっているとはいえ、同じビルの中にチームの全員がいるので、なんかあったら顔を合わせて相談できる状態だったから決断できた。

最初はトラブル続出で、「判断間違えたかな？」と内心悩んでいたけど
結局馴染んでくればgitの方が扱いやすくなってきたよ。

しばらくして、VisualStudioがgit標準対応した時は「よっしゃ！」ってなった。
（でも日本語変だよマイクロソフトのgit）
0532デフォルトの名無しさん2015/05/24(日) 22:05:23.23ID:VWanxcqX
>>530
おれ>>524な
「この人の場合」が俺のことなのか、ほかの人なのか読み取れなかったんだけど、

俺がgit使ってる（使わせてる）理由の一番大きい所は
「間違えてリポジトリ壊しても俺が直してやる。安心してどんどんブランチ作れ！細かくコミットしまくれ！」って言える所だな。

俺の場合、バグとか間違ったコミットとかも積極的に残しておくことを推奨している。
レビューもそのままで特に問題は無かったな。
でも、「間違えても大丈夫」という安心感がないとみんなブランチ活用してくれないんだよ。

特に問題だったのは（svn使っていた頃の話ね）
何ヶ月もたってから、コードのここの部分て、修正入っているんだけど、意図がわからない、当時の担当者はもう居ない。何て事がよくあった。
svnだと、ブランチ＆マージとかコミットとかは結構大事（おおごと）で
みんな、自分の手元で完全に書き終わってからしかコミットしてくれなかった。
ブランチ＆マージはリーダーだけがやる仕事みたいな感じだったし。
そうなると、ログ上いっぺんにあっちこっち修正が入っている中で、特定個所の意図を読み取るのがものすごく難しくて困ったんだ。

今は「マージ操作間違えても俺が直してやる。
安心して、”変数名を書き換える”様な小さな修正でも各自でブランチ作って作業してくれ。」って言える。
これだけでも後から意図を読み取るのは随分楽になったよ。
0533デフォルトの名無しさん2015/05/24(日) 22:19:55.92ID:mdHWC0Am
状況によるけどコミット分けたほうが見やすいというのは複数の作業単位(ブランチ)に分けるものを
一つのブランチに押しこんでるからじゃないの
機能まるまる追加とかなら経過をコミットで分けたほうがわかりやすいというのはわからんし

>>529
閉じたブランチ使わないでバグフィクス用のブランチで修正するのが筋だろう

>>527
リセットでヘッド戻して新しくブランチ切ってそっちにコミットして元のブランチに更新取り込んで新しいブランチをマージ
次から最初からブランチ切っとけばこんなことで困らん
0534デフォルトの名無しさん2015/05/25(月) 03:10:39.76ID:WhsXE+Ib
>>532
個人でブランチ作ってコミットしたあと、どうすればいいの？
そのブランチを本家に取り込ませるの？
0535デフォルトの名無しさん2015/05/25(月) 05:59:36.31ID:/VFybrtg
> でも、「間違えても大丈夫」という安心感がないとみんなブランチ活用してくれないんだよ。

これ大事よね
master に
0536デフォルトの名無しさん2015/05/25(月) 06:01:10.35ID:/VFybrtg
途中で書きこんでしまった

> でも、「間違えても大丈夫」という安心感がないとみんなブランチ活用してくれないんだよ。

これ大事よね
master に wip と fix typo が積み重なってた時は流石に萎えたけど
0537デフォルトの名無しさん2015/05/25(月) 08:14:58.07ID:y6DNlXTS
>>536
＞master に wip と fix typo が積み重なってた時は流石に萎えたけど
そういうのを、それがmasterにあろうと自分でリベースして消すのがその人のやり方なんだろう
05385232015/05/25(月) 09:19:23.83ID:E69UDjHE
>>525
> >>523 だからpushしたブランチをrebaseしてもまったく問題ない。
>
> branch を push する意味が理解できん。数分から数日しか存在しないブランチを何処
> に push するの？
>
> レビューアーの git に同じブランチを設けてリモート・ブランチにしているの？

自分が作成・変更したブランチをpushする先はclone元のリポジトリの同名ブランチ。

典型的にはGitHub(GitLab)上には共有リポジトリがひとつしか存在しない。そのリポジトリはForkしない。ひとつのリポジトリのなかでブランチを使ってPull Request(Merge Request)する
0539デフォルトの名無しさん2015/05/25(月) 13:36:42.28ID:XuKAmWn9
中央リポジトリにみんながpushしまくる方式で運用してるのか、Pull Request方式で運用してるのか、
まずその辺から説明してくれないとgitの運用方式に自由度が有り過ぎて話が噛み合わん
0540デフォルトの名無しさん2015/05/25(月) 13:49:29.09ID:XuKAmWn9
>>527
あんたがやりたいことはrebase本来の一番基本的な使い方で、rebase -iで自分で直接順番操作する必要は無い
検索すりゃ方法わかると思うので調べてみてくれ
0541デフォルトの名無しさん2015/05/25(月) 22:51:38.00ID:o/eCAQPj
共有ブランチ上のバグを直すために共有ブランチ上のコミットを書き換えるんだとしたら、
書き換え前のコミットををベースにしている人への配慮が必要そうだな

各作業者に「共有ブランチ上のコミットを書き換えたいから、各自のブランチをリベース
してください」って頼んで回れる環境が必要だ
05422122015/05/25(月) 23:42:12.33ID:fVXVPz7E
gitってなんでMakeFileにuninstallが用意されてないんですか？
アンインストール作業が苦痛なんですよ
makeだけでアンインストールさせてくださいよ
05435382015/05/26(火) 00:30:58.55ID:VHuDuKFu
>>539
> 中央リポジトリにみんながpushしまくる方式で運用してるのか、Pull Request方式で運用してるのか、
> まずその辺から説明してくれないとgitの運用方式に自由度が有り過ぎて話が噛み合わん

中央リポジトリにみんながpushしまくって、中央リポジトリのTopicブランチ(各人がpushしたブランチ)から同じ中央リポジトリのmasterに向けてPull Requestする。
これが GitHub flow な。

元が「 >>522 Pushしたブランチは書き換えてはならん」への反論だから、
そうでない運用もごく一般的、という主張をしたということ。
0544デフォルトの名無しさん2015/05/26(火) 08:35:26.55ID:n+9g7Zgu
「各メンバーが、個人用ブランチをリモートリポジトリ上に持っている」
これじゃ>>522への反論になってないっていうか、>>522が言ってることそのままだな
0545デフォルトの名無しさん2015/05/26(火) 17:27:09.33ID:sKFLbSMM
>>541
そうだよ。だから、それができる範囲なら共有ブランチでもリベースして良いんだよ。
0546デフォルトの名無しさん2015/05/26(火) 17:39:03.82ID:sKFLbSMM
>>544
個人用ブランチは作成者だけが見るわけじゃないから>>522とは違うな。
>>522は、ブランチを公開することと、一部の人間がそのブランチに依存することと、不特定多数の人間が依存することの区別がついてないんじゃないか？
単に極論言って煽ってるだけかもしれないけどね。
0547デフォルトの名無しさん2015/05/26(火) 18:06:24.50ID:2IsijlAj
ところでそれだけ熱心なブランチ管理のpush,rebase制限はどうやってる？
規約任せかツールかスクリプトか
0548デフォルトの名無しさん2015/05/26(火) 18:23:29.30ID:O0gIeBts
うちは原則push -f禁止でやってるんで、みんながpushするサーバーにはreceive.denyNonFastforwardsとreceive.denyDeletesを設定してる
0549デフォルトの名無しさん2015/05/26(火) 20:10:30.68ID:qT5tL8rR
横だがどうやって禁止するのかと思ったらちゃんとそういうコンフィグが用意されてるのか
一回オプション総ざらいしてみよう
0550デフォルトの名無しさん2015/05/26(火) 22:07:42.46ID:1ouiCH4F
>>545
で、>>519が言ってる「プロジェクトの規模が小さい場合には
それができる」って話につながってくるのか…。
0551デフォルトの名無しさん2015/05/26(火) 23:55:53.54ID:2IsijlAj
>>549
それブランチごとじゃなくて一律だからアクセス制限にはならないぞ
0552デフォルトの名無しさん2015/05/27(水) 12:17:18.05ID:98FdFg1V
Git 2.4.2
https://github.com/git/git/releases/tag/v2.4.2
0553デフォルトの名無しさん2015/05/31(日) 20:55:03.14ID:2hiQrePQ
特定のファイルを特定の履歴に戻すのはどうやるんでしょうか？
a.txtをHEAD@{12}のa.txtの内容にしたいんです
git reset HEAD@{12} a.txtじゃ戻りませんでした
0554デフォルトの名無しさん2015/05/31(日) 21:23:55.63ID:q0XD6tk+
checkoutせよ
0555デフォルトの名無しさん2015/06/01(月) 22:34:02.79ID:6w2KJtLO
git init
git add -A
このaddを取り消したいんですがgit reset HEADをやると
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
ってでます
git add -Aで変更をインデックスに追加されているわけだからHEADを指定したらリセットできると思ったんですが何で出来ないんですか？
0556デフォルトの名無しさん2015/06/01(月) 22:37:39.31ID:wXX1PCBE
まだHEADに相当するコミットが存在しないから
0557デフォルトの名無しさん2015/06/01(月) 22:37:41.39ID:60FC1uF1
1回もコミットしてないとか？
0558デフォルトの名無しさん2015/06/01(月) 22:43:38.24ID:wXX1PCBE
おれはそんなとき.gitをざっくり消したりしてたが、
ぐぐると git rm --cached が使えるみたいだな
0559デフォルトの名無しさん2015/06/02(火) 10:41:16.23ID:2Bq+WaXR
git rebaseでどこまでまとめるべきなのかわかりません
例えばデータベースの文字コードの設定の修正と、スタイルシートを変更した2点の場合
一緒にまとめたほうがいいんでしょうか？
0560デフォルトの名無しさん2015/06/02(火) 22:36:32.71ID:ENh0ws/u
Windows版のバージョンは上がらんのかえ
0561デフォルトの名無しさん2015/06/02(火) 22:37:29.49ID:dwjHRJAm
自分でコンパイルしろよ
0562デフォルトの名無しさん2015/06/02(火) 22:37:35.29ID:H1H2VilB
>>559
その二つならまとめない。

もし、データベースの文字コードを変更したことによりスタイルシートの変更が必要になったのであればぎりぎりまとめてもいい。
0563デフォルトの名無しさん2015/06/03(水) 01:22:55.03ID:knJmPdD6
>>559
そういうgit運用の話は、「管理者の意見に従うべき」

個人用or自分が管理者なら、好きなようにやっていい。
0564デフォルトの名無しさん2015/06/03(水) 01:42:10.75ID:3kJPkUc2
>>563
少しは助言してやれよ
0565デフォルトの名無しさん2015/06/03(水) 03:55:40.59ID:cOL0IOxC
どのやり方が良いかなんて決まっているわけじゃない
色々試して自分が一番しっくりする形を探すか
最も採用されていると思えるやり方というのを見出してそれを選択するか
有名どころのオープンソースプロジェクトの方針を色々と見てくるといい
0566デフォルトの名無しさん2015/06/03(水) 05:32:16.44ID:5OGKD7dq
俺がまとめる基準はそのまとめたコミットに判り易いひとつのタイトルをつけられるかどうかあたり
でも優先されるべきはそのリポジトリの管理方針なのは間違いない
0567デフォルトの名無しさん2015/06/03(水) 10:17:17.28ID:qaWpPbOF
ところでpost commit mail送るのに何使ってる？

うちはmultimail使ってるがなんかしっくり来ない
0568デフォルトの名無しさん2015/06/04(木) 01:27:40.14ID:FZpfA7xp
>>565
お前はどうやってるんだよ
0569デフォルトの名無しさん2015/06/04(木) 10:38:54.51ID:ixdJmRIH
俺は初心者の頃にここでコミットをまとめるなって言ってこのスレを炎上させた初心者＋だけどさ
その時はコミットをまとめろって言われたからソースコードのバージョン毎にコミットを全部まとめたよ
一体まとめろ！まとめるな！のこのスレの意見を統一してもらわないと俺みたいな初心者が無駄な道を通ることになる

1. initial commit
---- ここから -----
2. save
3. type
4.　○○実装
5.save
6.○○実装
7.typo
8.ファイル追加
----- ここまでまとめる -------
tagで1.0って付ける
0570デフォルトの名無しさん2015/06/04(木) 10:43:29.77ID:lUVfOohh
バージョン毎にまとめろとか誰も言ってないだろ
具体的にそのやりとは何スレ目だよ
0571デフォルトの名無しさん2015/06/04(木) 10:47:48.34ID:w41Ky1ux
>>569
「まとめろ」「まとめるな」で意見を統一するのは難しいと思うけど(そもそも状況によってどっちが良いかかわるだろうから)、
どういうときはまとめたほうがよい
どういうときはまとめないほうがよい
というガイドラインのようなものならある程度意見はまとまってきそうだね
0572デフォルトの名無しさん2015/06/04(木) 13:46:30.21ID:7Y8AXPNC
後から分離したくならないものはまとめる
要するに、二つのコミットがあった時に、これが二つに分かれてる必要はあるだろうか？と考えればいい
0573デフォルトの名無しさん2015/06/04(木) 13:49:14.71ID:5FZxl5co
そうして全てのコミットはひとつになった
0574デフォルトの名無しさん2015/06/04(木) 16:11:36.89ID:a/IZmogk
コミットを入れ替えるときにコンフリクトって起きないんですか？
git init
touch README.md
git add README.md
git commit -m "Initial commit"
echo 1 > a.txt
git add a.txt
git commit -m "add a.txt"
echo b1 > b.txt
git add b.txt
git commit -m "add b.txt"
echo a1 > a.txt
git add a.txt
git commit -m "modified a.txt"
git rebase -i HEAD^^^
以下のように並べ替え
pick 06da9a6 add a
pick 2c80b8f modified a
pick 7a6a277 add b
git checkout HEAD^
lsするとbファイルがありません
"modified a"のコミットにはbはないことになるんですか？gitが自動的に面倒見てくれてるんですか？
0575デフォルトの名無しさん2015/06/04(木) 20:10:10.65ID:lUVfOohh
Gitでは各コミットがその時点での全ファイルの状態を持ってるけど、
rebaseで並び替えるのはコミットの変更差分(自分の前のコミットとの差分)ってことかな

>>574のrebaseによって、"modified a"コミットのa.txtを変更したという差分だけが"add b.txt"コミットより前の歴史へ移動するので、
"modified a"コミットにbは存在しなくなる

rebase -iでコンフリクトは起こる
例えば>>574の"add a"と"modified a"コミットの順番を逆にしたりすれば
0576デフォルトの名無しさん2015/06/04(木) 20:23:21.52ID:69dFu2L0
>>569
正直「そこの管理者の意見に従ってまとめろ」「同僚たちと同じようにまとめろ」って回答しかないな
0577デフォルトの名無しさん2015/06/04(木) 20:46:29.00ID:b+4KVUcq
少なくともどの時点でもコンパイル通るようにコミットまとめる
大きくても機能ごとにはコミット分ける
でその間はプロジェクトごとに方針あれば何でも
0578デフォルトの名無しさん2015/06/06(土) 22:34:59.14ID:4eOWDqlW
問題は俺自身に経験がないのに
俺がルールを決めなきゃいけない時だな
0579デフォルトの名無しさん2015/06/06(土) 22:35:56.50ID:yk/a5xMg
>>569
お前、マージ使ってないだろ？

まず前提として「一つのプロジェクトを複数の人が平行で開発している」という
個人プロジェクト以外のごく普通のプロジェクトの話なんだよ。

よくある間違いが、小さい規模の例だけで考えて、
それがそのまま大きな開発にも適用できちゃうって考えること。
君はその間違いはまってる。

（俺が知ってる）小さい規模ではこれでうまくいくんだ。ではなくて
大きな規模になった時それでうまくいくのか？を考えた方がいい。

適切なやり方というのは、規模によって変わるんだから。
0580デフォルトの名無しさん2015/06/06(土) 22:41:32.51ID:yk/a5xMg
>>577
問題は1コミットを後から見直すかどうかだよな。

後から見なおさないのであれば、どんなに意味不明な修正でも
同じ所を試行錯誤したコミットでも、何百行あるコミットでも
何十個もあるコミットでも、そのコミットを見ないのであればどうでもいい

でもあとからそのコミットを見るのであれば
修正内容が明確にわかるコミットが必要最低限あった方がいい。

あとからそのコミットを見るかどうかだよ。
もちろん俺はよく見る。
仕事でもその修正が適切であるかを見たり、
オープンソースとかでもある修正内容を見たり
だからコミットは分かりやすくなっていたほうがいいと考える。
0581デフォルトの名無しさん2015/06/06(土) 22:46:03.75ID:yk/a5xMg
>>571
> というガイドラインのようなものならある程度意見はまとまってきそうだね

コミットをまとめる or まとめないのが目的じゃないからね。
コミットを綺麗にするのが目的。

当然の話だけどガイドラインには理由が必要だろうね。
まとめる理由が。（もしまとめないのであれば、まとめない理由も）

コミットをまとめたりまとめなかったりして、綺麗にする理由は
簡単にいえば、後からコミットを見た時にわかりやすいように
するためなんだが、もっと細かい理由って必要だろうか？
0582デフォルトの名無しさん2015/06/06(土) 22:54:18.21ID:yk/a5xMg
少しだけガイドライン考えてみた


・一つのコミットで複数の修正を行わない
理由 後からそのコミットを見た時何を修正したのかがわからなくなるから

・一つの修正を複数のコミットにわけない（分かれていればまとめる）
理由 後からそのコミットを見た時何を修正したのかがわからなくなるから
例外 リリースしてしまったコミットはまとめることは出来ない。


いま気づいたが、この「リリース」っていう概念が重要だな。
どの時点でリリースになるのかはそれぞれだろうが
master、もしくは共有ブランチににマージされた時点がリリースだと考える。


と考えると、やはり>>569の例ははマージ機能を使ってない時点で
一人で開発している場合にのみ通じる例だから、例としてふさわしくないんだよ。
0583デフォルトの名無しさん2015/06/06(土) 23:00:59.08ID:OBriYrAJ
3行で
0584デフォルトの名無しさん2015/06/07(日) 00:12:36.70ID:5CuOmznL
あとから見てわかるようにコミットを綺麗にしておけ
まとめる とか まとめない とかどちらか一方じゃない
どちらもやって、綺麗にしておけ。
0585デフォルトの名無しさん2015/06/07(日) 02:04:34.40ID:VSY66R2E
一つのコミットに入れる一つor複数の修正って、何単位で一つと呼ぶのかって話もあるし、

>>541と>>545のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」
って運用ルールでgitを使っている人がいたりするので、抽象的なガイドラインは決めるだけ
無駄ではないか

それを議論したって、自分がブチ上げたガイドラインを弁護し、他人がブチ上げたガイド
ラインの言葉尻を捕まえてロンパするだけの、言葉遊びの世界に入っていってしまう
0586デフォルトの名無しさん2015/06/07(日) 02:08:39.07ID:VSY66R2E
>>578
そういう時は、「なんでgitなんか使わなきゃならないのか」に立ち戻るべきだと思う
0587デフォルトの名無しさん2015/06/07(日) 02:48:23.33ID:5CuOmznL
>>585
> >>541と>>545のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」

いないだろｗ

あぁ、なんで共有ブランチにpushしたコミットは
編集したらだめなのかを書いていなかったね。

物事は単純で、他人の役に立つことをしましょう、
他人の迷惑になることはうやめましょう。これだけだよ。

コミットは他人が見ることを考えれば、そして他人は何故見るのかを考えれば
コミットを綺麗にしておけば可読性が高くなって読む人の負担が減る。
これは他人の役に立つこと。

そして共有ブランチを修正したらだめというのは、他の人も
その共有ブランチから派生して修正しているので、その派生元が変わると
今まで参照していたものが履歴を残さずに変わるわけで何が起こったのかわからなくなるから。
これは他人の迷惑になること。

このように俺のガイドラインにはちゃんと理由がある。
反対のガイドラインを作りたいなら、その理由をいうことだけ。
でないと俺の意見に対抗できない
0588デフォルトの名無しさん2015/06/07(日) 02:52:10.94ID:5CuOmznL
念の為に俺が言ってる「共有ブランチ」の定義を書いておくわ。

俺が言ってる共有ブランチっていうのは、
他の人がそのブランチから作業をする、
または他の人がそのブランチにマージすると
という目的で作られたブランチのこと。

つまり他の人が参照しているだけならば
共有ブランチとは言わない。
参照しているだけならば、そのブランチが変わっても
他の人の作業のじゃまにはならないからね
0589デフォルトの名無しさん2015/06/07(日) 02:54:19.37ID:5CuOmznL
ということで、何故そうするのか、どんなメリットがあるのかを
しっかりと書いたガイドラインを、俺以外に出すのまってま〜すｗ
0590デフォルトの名無しさん2015/06/07(日) 10:11:47.35ID:V49LqTdE
>>587
＞いないだろｗ

いや、>>541が「共有ブランチ上のコミットを書き換えるんだとしたら」と言ったのに対して
>>545が「そうだよ」と返しているので、いること自体は確かなようだ

545に対して、あなたがどうロンパするかは別に知らないが
0591デフォルトの名無しさん2015/06/07(日) 10:31:51.05ID:V49LqTdE
>>579-580
全部のコミットをひとつにまとめて周りから怒られなかったなら、
それは正しいまとめ方だったと思うんだけどね
0592デフォルトの名無しさん2015/06/07(日) 12:19:13.74ID:5CuOmznL
>>590

> 545に対して、あなたがどうロンパするかは別に知らないが

論破？ 何故そうするかの理由がないのだから、
まずその理由を言うのが先だろうｗ
0593デフォルトの名無しさん2015/06/07(日) 12:20:45.23ID:5CuOmznL
>>591
> 全部のコミットをひとつにまとめて周りから怒られなかったなら、

周りの人間がコードを見るということを知らないだけかもしれない。
スキルが低くてソースコード管理ツールすら知らない人もいるのだから。

だからそれは全く参考にならないな。


理由だよ理由。

俺は何故そうするかの理由を書いた。
この俺を論破する理由をかける奴はいないのか？ｗ
0594デフォルトの名無しさん2015/06/07(日) 12:21:31.63ID:yxti539q
誰か運用スレ立ててくれない
0595デフォルトの名無しさん2015/06/07(日) 12:52:14.95ID:V49LqTdE
結局は>>585の言ったとおりになるという、悲しい現実

>>594
運用スレを建てても、荒らしがそこに移動するかどうかは別問題だと思う
0596デフォルトの名無しさん2015/06/07(日) 13:04:07.08ID:yxti539q
運用スレ行けと言えるようになるだけ幾分マシかと
0597デフォルトの名無しさん2015/06/07(日) 13:08:53.36ID:V49LqTdE
>>596
なるほどそうかもしれないね
そういう意味だと、既存だとここあたりが適切なのかな

バージョン管理システムについて語るスレ10
http://peace.2ch.net/test/read.cgi/tech/1393147031/
0598デフォルトの名無しさん2015/06/07(日) 13:12:32.75ID:5CuOmznL
>>595
> 結局は>>585の言ったとおりになるという、悲しい現実

大丈夫。

俺が言った「ガイドラインを言う時は理由も明確書くこと」
のおかげで、今のところガイドラインは俺が言った一つしかでてない。
0599デフォルトの名無しさん2015/06/07(日) 13:17:04.64ID:yxti539q
>>597
ここでされてるの横断的でない個別的な内容だからスレチ
0600デフォルトの名無しさん2015/06/07(日) 13:18:47.22ID:V49LqTdE
>>599
そっか、じゃあ新スレがいるか・・・
0601デフォルトの名無しさん2015/06/07(日) 13:23:17.32ID:V49LqTdE
>>598
＞今のところガイドラインは俺が言った一つしかでてない。

そりゃ出ないでしょ
誰も関わりたくないんだから
0602デフォルトの名無しさん2015/06/07(日) 13:26:15.60ID:5CuOmznL
>>600
スレ立てておいたよ。

Gitをより良くするための運用ガイドライン作成スレ [転載禁止](c)2ch.net
http://peace.2ch.net/test/read.cgi/tech/1433650988/


>>601
> 誰も関わりたくないんだから
関わりたくないのが理由っていうのはおかしな話だな（笑）

言い返せない時に汎用的に使えそうな言い訳だ。
0603デフォルトの名無しさん2015/06/07(日) 13:31:19.54ID:V49LqTdE
>>602
ありがとう
じゃあここから先は、ここで運用系の話をするのはスレ違いってことで、
あとはそっちでやってもらおう
0604デフォルトの名無しさん2015/06/07(日) 13:42:31.68ID:yxti539q
>>602
タイトルを単にGit運用スレにできないあたり自己顕示欲あふれるスレタイですね
0605デフォルトの名無しさん2015/06/07(日) 15:41:57.12ID:D5MO+jlJ
立てたら立てたで文句言う奴 w
0606デフォルトの名無しさん2015/06/07(日) 18:26:22.23ID:5CuOmznL
いるいるw
0607デフォルトの名無しさん2015/06/07(日) 18:53:47.38ID:V49LqTdE
>>604
荒らしが自分で建てたスレなんだから、そうなるのはしょうがない
運用の話はそっちでやってもらいましょう
0608デフォルトの名無しさん2015/06/07(日) 19:53:48.87ID:yxti539q
自分で立てたスレなんだからもちろん自分は引っ越して誘導もするんですよね
期待してますよ
0609デフォルトの名無しさん2015/06/07(日) 20:06:44.60ID:5CuOmznL
>>608
はい当然です。 Gitの運用方法に関するレスは全部向こうに移動します。
みなさんも協力してくださいね。

逆に運用以外の雑多な内容はこっちに移動しますよ。
0610デフォルトの名無しさん2015/06/07(日) 21:10:56.78ID:V49LqTdE
>>608
おみごと
0611連続書込しすぎなのでID変えます2015/06/07(日) 21:22:11.43ID:rs3gN1uE
このスレから運用に関することをなくしたら
どれだけのレスが残るか期待ですｗ

ぜーんぶかっさらっていきますよーｗ
0612デフォルトの名無しさん2015/06/07(日) 21:49:02.86ID:HSoSL4U1
git とうまく組み合わせられるような
バグトラッキングツールでおすすめのはある？
mantisってもう人気無い？
0613デフォルトの名無しさん2015/06/07(日) 21:52:12.28ID:V49LqTdE
これでツールの質問ができるようになるのか、
または、ツールの質問に答えられる人なんて初めからいなかったのかがハッキリするな

どっちにしても平和になってよかった
0614デフォルトの名無しさん2015/06/07(日) 21:57:36.23ID:/P0faz6I
Egitで、amendじゃなくてもっと過去のコミットを編集するには
画面上でどういう操作をすればいいんでしょうか？
0615デフォルトの名無しさん2015/06/07(日) 22:03:03.72ID:rs3gN1uE
githubの使い方を教えて下さい。
■ このスレッドは過去ログ倉庫に格納されています