14/06/22 17:40:25.81 mgZTcG6H
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
URLﾘﾝｸ(git-scm.com)
◆関連サイト
Pro Git - Table of Contents
URLﾘﾝｸ(git-scm.com)
Git入門
URLﾘﾝｸ(www8.atwiki.jp)
◆前スレ
Git 9
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
14/06/22 18:02:10.08 b06vElF6
ｲﾁｵﾂ
3:デフォルトの名無しさん
14/06/22 18:33:54.01 2+Nzucu/
Gitを使うと早漏になるの？だったら嫌だなあ、使うの控えるべきかしら？
4:デフォルトの名無しさん
14/06/22 18:45:39.07 Zf5ltYR1
ｱｰｲｷｿ
5:デフォルトの名無しさん
14/06/22 18:55:46.49 3ROl0TsY
∧＿∧ SVN？ ぎっとぎとにしてやんよ
( ･ω･)＝つ≡つ
(っ ≡つ＝つ
/ ) ﾊﾞﾊﾞﾊﾞﾊﾞ
( /￣∪
6:デフォルトの名無しさん
14/06/22 19:03:02.96 kD+jIMJ8
ノ ﾟ.ﾉヽ , /} ...
,,ｲ`" ､-' `;_' ' ..::::::::::::::...
,-､ _.._ ( (,(~ヽ'~ ..:::::::::::::::::::::::
）'~ ﾚｰ' 〉 ヽ i`'} .:::::::::::::::::::::::
~つ '-ｰ､ i | i' ...:::::::::::::::::::::::
／ < / 。/ ! ......::::::::::::::::::::::::: これは>>1乙じゃなくて
/ ~^´ /},-'' ,●::::::::::::::::::::::::::::::::::::
i､ ,i' _,,...,-‐-､/ i :::::::: .:::::::::::::
..ゝ <,,-＝=､ ,,-,/ .::::::::::: 放射能がうんたら
) {~''~>`v-''`ｰﾞ`'~ ..::::::::: ........::.
{ ﾚ_ﾉ ..::::::::. ......:::::::::
ノ '' ..::::::: ...::.:...:::::::::
.::::::::: ...:......:::::::::::: .
.:::::::::::. ..... .. ..:::::::::::::::::::::::: :::.
::::::::::::::::.::::::....:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::.. :: ::..
.:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ::: ::.
::::::::::::::::: :::::::::::::::::::::::::::::: :::::
.:: ::. :::
7:デフォルトの名無しさん
14/06/23 10:11:42.41 sjU94AhZ
◆関連スレ
バージョン管理システムについて語るスレ10
ｽﾚﾘﾝｸ(tech板)
CVS導入スレ～ Rev.3
ｽﾚﾘﾝｸ(tech板)
Subversion r14
ｽﾚﾘﾝｸ(tech板)
【分散型バージョン管理】 Mercurial 2【hg】
ｽﾚﾘﾝｸ(tech板)
【bzr】Bazaarでバージョン管理 Rev 4
ｽﾚﾘﾝｸ(tech板)
OSSホスティング総合【SourceForge,GitHub,etc..】
ｽﾚﾘﾝｸ(tech板)
◆関連スレ 別板
CVS 1.3 [UNIX板]
ｽﾚﾘﾝｸ(unix板)
8:デフォルトの名無しさん
14/06/23 10:12:16.78 sjU94AhZ
◆関連書籍
Pro Git 日本語版電子書籍公開サイト
URLﾘﾝｸ(progit-ja.github.io)
開発効率をUPする Git逆引き入門 2014/04 著:松下雅和 船ヶ山慶 平木聡 土橋林太郎 三上丈晴
URLﾘﾝｸ(www.c-r.com)
Git ポケットリファレンス 2012/07 著:岡本隆史 武田健太郎 相良幸範
URLﾘﾝｸ(gihyo.jp)
Gitによるバージョン管理 2011/10 著:岩松信洋 上川純一 まえだこうへい 小川伸一郎
URLﾘﾝｸ(ssl.ohmsha.co.jp)
実用Git 2010/02 著:Jon Loeliger オライリー本
URLﾘﾝｸ(ssl.ohmsha.co.jp)
入門Git 2009/9 著:濱野純
URLﾘﾝｸ(www.shuwasystem.co.jp)
入門git 2009/08 著:Travis Swicegood 監訳:でびあんぐる
URLﾘﾝｸ(ssl.ohmsha.co.jp)
9:デフォルトの名無しさん
14/06/24 10:55:31.19 BxyDqmCe
スレ立てて書き込み少な目で放置しとくと落ちるのは自動なのか？このスレは大丈夫なのかね？
10:デフォルトの名無しさん
14/06/24 12:46:36.12 /C23Uhbr
入門Git以外は手に取ってみる価値もない
でFA?
11:デフォルトの名無しさん
14/06/24 14:19:17.66 oDNeDxJ6
GoogleAppsScriptで書いたソースをgitでリポジトリ管理するにはどうすればいい？
12:デフォルトの名無しさん
14/06/24 16:36:15.78 Q+GgUeFG
>>11
import/exportができるみたいだからそれ使えばいいんじゃないの？
URLﾘﾝｸ(qiita.com)
単に特殊なデプロイが必要になるってだけ。
13:デフォルトの名無しさん
14/06/25 10:27:08.76 51nve3hM
import/export を自動化するスクリプトを GoogleAppsScript で書けないかな
14:デフォルトの名無しさん
14/06/26 08:42:26.78 rb3EhG0/
>>10
どっちの？
15:デフォルトの名無しさん
14/06/26 10:06:12.43 BCJ2ygce
念のためにこっちにも
Git 2.0.1 リリース
URLﾘﾝｸ(github.com)
16:デフォルトの名無しさん
14/06/26 11:59:36.41 lzGhXXy2
>>14 君には入門Gitが入門gitに見えるのかね
17:デフォルトの名無しさん
14/06/26 15:13:00.47 I1GlggqH
スレ番も数字じゃなくハッシュ値で
18:デフォルトの名無しさん
14/06/26 20:19:34.54 uNXRCBxV
さ あ 、 も り あ が っ
て
ま
い
り
ま
し
た
19:デフォルトの名無しさん
14/06/27 12:01:47.48 wewJM3ti
兆戦の皿が白ばっかりなのは
土器みたいに茶色いままだと
うんこが付いてても気付かないから
20:デフォルトの名無しさん
14/06/27 22:32:20.88 VuPlBIMA
日本の器に黒っぽいのが有るのはうんこが付いてても気にせず食べるから？
21:デフォルトの名無しさん
14/06/28 01:35:08.69 sQNJ1q5c
皿にうんこが付く状況ってどんなんだよ
22:デフォルトの名無しさん
14/06/28 04:37:58.98 w+QI/fAg
器にうんこが付くという発想がないから
23:デフォルトの名無しさん
14/06/28 04:57:32.01 sKWOMnpi
トンスルランドでは台所に便所紙捨てるところがあるんだっけ
24:デフォルトの名無しさん
14/06/28 06:10:14.26 WBXNiQjo
日本に観光に来てる連中は
ホテルのトイレでも紙をゴミ箱に入れるので
従業員を困らせている
25:デフォルトの名無しさん
14/06/28 06:50:34.22 6GT+Y+O2
日本も戦前は同じだったそうだよ
26:デフォルトの名無しさん
14/06/28 07:49:42.50 88+ODrtr
ここまで Git の話なし
27:デフォルトの名無しさん
14/06/28 10:47:37.20 pkB82Erl
今日のうんこスレはここですか
28:デフォルトの名無しさん
14/06/28 23:12:42.12 c56+A2pI
一、清潔な食事運搬用バケツと雑巾バケツの区別をよく教えること。
こんな注意書きが必要な連中なので
29:デフォルトの名無しさん
14/06/29 00:18:04.03 /NI7q9pJ
敗戦直前の日本の雑誌に、汚れたバケツに貯まった雨水を飲み水に使うことの美徳が書かれていたって話を思い出すな
それはともかく、Gitのブランチ管理はややこしいよなー
未だに解説読みながらやってる
30:デフォルトの名無しさん
14/06/29 00:54:31.86 f0WIPed4
gitのブランチ管理じゃなく
git flowもしくはgithub flowのブランチ管理がややこしいのでは
31:デフォルトの名無しさん
14/06/30 22:40:23.98 5h8Y0Ud2
$ git clone URLﾘﾝｸ(github.com) ← 自分のリポジトリ(SSHキーは登録済み)
色々作業してローカルでコミットした
$ git push
fatal: could not read Username for 'URLﾘﾝｸ(github.com)': No such file or directory
↑
なんでなん…
その後こうしたらpush出来た
↓
$ git remote rm origin
$ git remote add origin 'git@github.com:username/repo.git'
originを変更しないと駄目な理由を分かりやすく教えてください
32:デフォルトの名無しさん
14/06/30 22:46:39.87 v5UqmfMQ
>>31
URLﾘﾝｸ(git-scm.com)
> HTTP 越しの Git のプッシュを行うことも可能ですが、あまり使われていません。
> また、これには複雑な WebDAV の設定が必要です。めったに使われることがないので、本書では取り扱いません。
> HTTP でのプッシュに興味があるかたのために、それ用のリポジトリを準備する方法が
> URLﾘﾝｸ(www.kernel.org) で公開されています。
33:31
14/06/30 23:03:26.98 5h8Y0Ud2
>>32
おお！素早いご指摘どうもです
よく理解できました
これからはそのドキュメントを良く読むようにします
34:デフォルトの名無しさん
14/06/30 23:10:54.18 v5UqmfMQ
っていうかGitHubってhttpsでのpushに対応してたっけ？
35:デフォルトの名無しさん
14/06/30 23:24:02.07 ocNeWDMt
httpsのアドレス宛にいつもpushしてるが
36:デフォルトの名無しさん
14/07/01 02:04:03.39 uudBEfHR
>>31
単にpushする先を指定してないだけだろ。
URL指定でcloneしているから、
originと紐付いてないだろうし。
37:デフォルトの名無しさん
14/07/01 20:07:37.99 dBLK7YMD
ローカルリポジトリのブランチhogeにコミットしました
ここでリモートリポジトリのhogeにコミットするはずが、リモートのmasterにコミットしてしまいました。
取り消すにはどうすればいいのでしょうか？
38:デフォルトの名無しさん
14/07/01 20:22:39.16 M2q2ii4G
パルプンテを唱える。
39:デフォルトの名無しさん
14/07/01 20:23:17.83 M2q2ii4G
もしくはメガンテ
40:37
14/07/01 20:24:46.81 dBLK7YMD
git remote -v
origin URLﾘﾝｸ(hoge.com) (fetch)
origin URLﾘﾝｸ(hoge.com) (push)
git add . --all
git commit -m "hoge"
git push origin master
to URLﾘﾝｸ(hoge.com)
master -> master
git branch -a したら
remotes/origin/HEAD -> origin/master
と出てきたんですが、これはURLﾘﾝｸ(hoge.com)のmasterにコミットされたということですよね？
41:デフォルトの名無しさん
14/07/01 20:25:26.30 rJGfEq1K
用語が変なのはgit使いでなくsvn使いとかか
42:デフォルトの名無しさん
14/07/01 20:28:16.54 sZ99gDnh
>>37
リモートリポジトリの管理者にごめんなさいして、どう処理するか相談する
43:37
14/07/01 20:39:43.94 dBLK7YMD
リモートリポジトリをcloneしてmasterブランチのlog見たらコミット履歴にありませんでしたが・・・
どこにコミットされたのでしょうか・・・
>>41
その通りです
44:デフォルトの名無しさん
14/07/01 20:44:17.29 rJGfEq1K
用語がめちゃくちゃで何を言ってるのか何をやりたいのかさっぱり分からん
45:デフォルトの名無しさん
14/07/01 20:54:30.74 sZ99gDnh
>>40
その一番最初の git remote -vの結果が正しければ、
そのリポジトリで普通にpushすると URLﾘﾝｸ(hoge.com) に反映されるはず
それなのに URLﾘﾝｸ(hoge.com) にpushされたというログになってるのはオカシイ
＞git push origin master
＞to URLﾘﾝｸ(hoge.com)
＞master -> master
写し間違えた？
>>43でcloneして確認したリポジトリは URLﾘﾝｸ(hoge.com) か URLﾘﾝｸ(hoge.com) のどっち？
46:37
14/07/01 22:06:47.31 dBLK7YMD
質問が不明瞭、かつ書き間違いなどがあり申し訳ありませんでした。
もう一度できるだけ詳しく正確に書くように致します。
47:デフォルトの名無しさん
14/07/01 22:21:48.75 dBLK7YMD
git remote -v
origin URLﾘﾝｸ(hoge.com) (fetch)
origin URLﾘﾝｸ(hoge.com) (push)
upstream URLﾘﾝｸ(foo.com) (fetch)
upstream URLﾘﾝｸ(foo.com) (push)
※「URLﾘﾝｸ(hoge.com)」は「URLﾘﾝｸ(foo.com)」をcloneしたもの
↓
git branch -a
branchA
* branchB
master
remotes/origin/HEAD -> origin/master
↓
cd c:\users\nullpo\desktop\repo\test\
git add x.cpp
git commit -m "save!"
1 file changed, 2 insertions(+), 2 deletions(-)
↓
git push origin master
To URLﾘﾝｸ(hoge.com)
dvcx245..9frr0bf master -> master
※ここで「git push origin branchB」とするはずが間違えて「master」にコミットしてしまいました。
ログから判別すると、現状は、URLﾘﾝｸ(hoge.com)のmasterブランチにコミットしてしまってると見るべきですよね？
ところがURLﾘﾝｸ(hoge.com)のmasterをcloneしてログを確認してもさっきのコミットが残っておらず、実際変更したはずのファイル(x.cpp)を見ても変わってないんです…。
48:デフォルトの名無しさん
14/07/01 23:38:48.46 sZ99gDnh
>>47
それは、ローカルのmasterブランチをURLﾘﾝｸ(hoge.com)のmasterブランチにpushしただけだね
URLﾘﾝｸ(hoge.com)のmasterブランチの最新が9frr0bfに更新されてるはずだよ
49:デフォルトの名無しさん
14/07/02 00:34:49.55 KQlLn9XQ
>>48
ありがとうございました。
しかし、幾ら試してもURLﾘﾝｸ(hoge.com)のmasterのコミットログにないんです・・・。
恐らくこのまま放置することにします。
長々と書き込んでしまいすいませんでした。
50:デフォルトの名無しさん
14/07/02 01:06:49.78 OroZGiqB
>>49
いやだから、書き込みを良く見てくれ
「ローカルのbranchBじゃなくて、ローカルのmasterを、リモートのmasterへpusuしてる」
したがって、ローカルのbranchBにコミットしたx.cppファイルがURLﾘﾝｸ(hoge.com)のmasterに無いのは当然
それて、pushが成功したかどうかはファイルの有無じゃなくてハッシュで確認しろ
git branch -av で各ブランチと対応するハッシュを確認できる
51:デフォルトの名無しさん
14/07/02 01:17:52.28 En/r/TGL
pusu
52:デフォルトの名無しさん
14/07/02 01:26:05.54 OroZGiqB
>>50-51
おう、pusuはpushのタイポな
53:デフォルトの名無しさん
14/07/02 01:29:18.74 En/r/TGL
example.なんとか使えつって教わらなかったのか
54:デフォルトの名無しさん
14/07/02 22:13:56.81 mhKrJc1t
VisualStudioのExpressでバージョン管理したいからGit入れたいんだけど
GUIで楽にローカルリポジトリ作る方法ってある？
55:デフォルトの名無しさん
14/07/02 23:02:29.91 87h9OT3W
はい、tortoisegitさんお呼びですよ
56:デフォルトの名無しさん
14/07/02 23:06:30.92 mhKrJc1t
亀ってリポジトリ作れるの？
57:デフォルトの名無しさん
14/07/02 23:40:22.67 j/Db3LoH
もちろん
58:デフォルトの名無しさん
14/07/02 23:50:54.99 mhKrJc1t
単独で作れるのか
ありがとう
59:デフォルトの名無しさん
14/07/02 23:55:08.90 87h9OT3W
Visual Studioに組み込めるプラグインもあるかも知れんけど
わかんね。msdnでも覗いてみれ。
60:デフォルトの名無しさん
14/07/03 03:35:02.68 LFvCfQY8
VSに組み込めるプラグインがあるとしても、Expressは拡張機能サポートしてないからどのみちダメじゃないか？
61:デフォルトの名無しさん
14/07/03 03:39:50.30 j0zMe+Fe
VS2013ならMSが公式でGitのプラグインを出してなかったか
62:デフォルトの名無しさん
14/07/03 05:54:32.69 DIfIjFzr
Azure専用
63:デフォルトの名無しさん
14/07/03 06:02:01.97 fWjka1bK
Windowsが7以降ならSourceTreeもあるな
64:デフォルトの名無しさん
14/07/03 09:57:25.05 T6nbxnRY
2013はExpressでもIDEからgit使えるけど、どうもわかりにくい
ankhsvnくらいに手軽だといいのだが、、、よって亀とコマンドライン併用
Xcodeの内蔵はかなり使いやすいと思った。
65:デフォルトの名無しさん
14/07/03 19:41:43.68 dti37cU6
msysgitダウンロード出来ねぇ…
500ってなんだ…
66:デフォルトの名無しさん
14/07/03 21:06:15.26 tTUYGcci
サーバの内部エラー
67:デフォルトの名無しさん
14/07/03 21:06:41.59 tTUYGcci
URLﾘﾝｸ(github.com)
行けた
68:デフォルトの名無しさん
14/07/03 21:16:47.31 dti37cU6
ありがと！いけた
69:デフォルトの名無しさん
14/07/03 21:22:28.52 dti37cU6
gitは正常に終了しませんでした (終了コード 128)
とか言われた…
なんだこれ…
70:デフォルトの名無しさん
14/07/03 21:29:51.18 ljTzUKRX
あ～、俺もそれなった。64bit Windows7
余計な物が入るのがいやなんだろうけど
msysgit諦めて
URLﾘﾝｸ(git-scm.com)
から丸々落としたら問題なくインストールできた
71:デフォルトの名無しさん
14/07/03 21:31:59.03 VhhMtL7W
…え？
git-scmからmsysgitじゃないWindows用gitが入手できたの？
72:デフォルトの名無しさん
14/07/03 21:39:27.88 dti37cU6
>>70
おｋ入れてみる
…の前にアンインスコしとこっと
73:デフォルトの名無しさん
14/07/04 01:20:38.78 ZQHJOpH+
msysgitのアンインスコがそもそも出来なくねえか？
ネットにはコントロールパネルからアンインスコしろと書いてあったが
インスコの途中でエラッたからかどうか分からんが、そんなものはなかった
とりあえず、面倒くさいのでインスコされたフォルダごと削除してやったけど
とりあえず、今のところ、その後、上記をインスコして問題ない
ところで、
インストールの時に聞かれる設定で
Checkout as-is, commit as-is
について、改行コードの勝手な変換は百害あって一利なしって言い切ってるサイトもあれば
なんか、それだとソフトウェア的に不具合が出る場合があるんで他の設定にした方がいいってサイトもあるんだが
実際にはどうなの？
個人的には、改行コードを勝手に変換されるなんて害以外の何物でもないと思うので
問題ないなら、何も変換させたくないのだが
74:デフォルトの名無しさん
14/07/04 08:40:05.93 xvFt74Dw
>>73
いろいろな環境でやるならlfだけにしておいて、各環境でチェックアウト時にcr,crlf,lfで使うのが楽じゃない？
ソースじゃなくてなんか特殊なファイルとか管理するならきめうちのほうがいいかもだし、
自分ひとり開発とかチームで環境が変わる要素がないならそのままでもよい
75:デフォルトの名無しさん
14/07/04 20:58:59.90 G9V8ZPtC
企業でgit使う場合ってリポジトリは暗号化して使うものですか？そのへん詳しい人教えてください
76:デフォルトの名無しさん
14/07/04 21:41:37.64 KGk1oj/Q
>>75
基本的に、暗号化してからadd,commitするよ
77:デフォルトの名無しさん
14/07/04 22:46:19.47 VHgyx1X4
>>75
詳しくはないけど。
鍵やデータはバージョン管理しないんじゃない。暗号化するようなファイルシステムなら、されちゃうかもだけど。
78:デフォルトの名無しさん
14/07/04 23:32:09.16 7y8V145d
ん？Git-scmってのはmsysgitの代わりに使うって認識で良いの？
79:デフォルトの名無しさん
14/07/05 00:32:02.32 7oOEkOAN
msysGitというプロジェクトでWindows用のGitが開発されていて
その成果は(Linux版やMac版も含めた)Gitの総合サイトであるgit-scmでも
やはりWindows用Gitとして配布されている…？
>>70 はつまり落とすサイトの話をしていて
開発版でなく安定版落としました、みたいな話なのかな
…俺もWindows版はよく知らんので、誰かツッコミ頼む
80:デフォルトの名無しさん
14/07/05 01:34:47.12 oA33QTWa
git-scm.comのDownload for Windowsで落ちてくるのは
URLﾘﾝｸ(github.com) のGit-1.9.4-preview20140611.exeじゃない？
>>70がうまく行かなかったのは同じ場所
URLﾘﾝｸ(github.com) のmsysGit-netinstall-1.9.4-preview20140611.exe
の方じゃないかな？
前者はバイナリだけの配布で、
後者はネットワーク経由インストールでコンパイル環境なんかも含めたすべてを落とせる？
81:デフォルトの名無しさん
14/07/05 05:17:04.89 SaA3Dhwi
そこで、cygwin で git ですよ。
オレオレビルドで、新しいリリースがすぐ使える
82:デフォルトの名無しさん
14/07/05 14:14:39.37 oc6wEiev
URLﾘﾝｸ(tracpath.com)
これ見ながらやろうと思っても、Git Bash起動するとすぐ画面閉じるんだけど
Git bashってどうやって使うの
83:デフォルトの名無しさん
14/07/05 14:29:48.66 oA33QTWa
>>82
msysgit のインストールに失敗してるんだろ
84:デフォルトの名無しさん
14/07/05 14:45:31.43 oc6wEiev
あれ？もしかしてmsysgitインストールしたらmsysgitってフォルダ作られる？
C:\Program Files (x86)\Git
とは別に？
85:デフォルトの名無しさん
14/07/05 14:57:24.31 Q/k3+41v
win7にmsysgitをインストールしたら↓のディレクトリにインスト―ルされたけど、Git Bashもこの中だし
C:\Users\Hiroshi\AppData\Local\Programs\Git
86:デフォルトの名無しさん
14/07/05 15:03:51.27 oc6wEiev
そうか…やっぱ失敗してんのかな
500から403に変わってGoogle Codeからは相変わらずダウソ出来ないし
もう少し探してみるか…
ありがとなヒロシ
87:デフォルトの名無しさん
14/07/05 15:16:53.89 oA33QTWa
>>86
しばらく前から動かないって言ってるひとか？
インストールに失敗してるんじゃなくて、アンインストールに失敗してるんじゃないか？
ゴミが残ってて新しくインストールしたmsysgitがうまく動かないみたいな感じ
88:デフォルトの名無しさん
14/07/05 15:51:10.99 oc6wEiev
うーん
つってもとりあえず『アンインストールとまたは変更』から削除したんだけど
それじゃ足りないのかな？
ゴミがどこに残り得るのかすらわからんのだけど
89:デフォルトの名無しさん
14/07/05 15:59:32.61 oA33QTWa
そういうのは地味に調べるか、できなきゃOS再インスコかね
自分もWindowsはよくわからんから、Winでこの手のツールをインストールしまくるのは嫌だね
なので、構成を自分でだいたい把握できてるcygwin版を使ってる
90:デフォルトの名無しさん
14/07/05 20:52:23.99 oc6wEiev
なんなのこれ…
Stack trace:
Frame Function Args
688100 [main] sh.exe" 8060 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
724705 [main] sh.exe" 8060 handle_exceptions: Error while dumping state (probably corrupted stack)
91:デフォルトの名無しさん
14/07/05 21:02:46.99 Q/k3+41v
お前のwindowsが単にぶっこわれてるだけなんじゃね
92:デフォルトの名無しさん
14/07/05 21:03:11.07 oA33QTWa
>>90
それは STATUS_ACCESS_VIOLATION でググルと対策らしいのが出てくるぞ
TEMPフォルダ絡みらしい
93:デフォルトの名無しさん
14/07/05 21:08:28.81 oA33QTWa
中途半端にGitのコードにユニコード対応とか入れた影響なんだろうなあ
日本語Win環境なんかじゃ試して無いだろうし
オリジナルのGitがほぼそのまま動くCygwinがやっぱええわ
94:デフォルトの名無しさん
14/07/05 21:20:01.50 oc6wEiev
>>92
おぉ、ほんとだありがとう
キャッシュ自体1.5Gもあったしちょうどよかった…
95:デフォルトの名無しさん
14/07/05 21:35:39.83 DUJJhZn/
>>93
なんかユニコードがらみで問題でもあったの？
96:デフォルトの名無しさん
14/07/05 21:58:23.52 oA33QTWa
>>95
TEMPフォルダにゴミがあると>>90みたいに落ちるらしい
特に日本語ファイル名のファイルとかあるとダメ
Unicode対応前のバージョンなら問題無いとか
97:デフォルトの名無しさん
14/07/06 01:52:41.07 2At6bBxp
やっと使えるようになったよ
ありがとう
コミットの概念が、SVNとちょっと違うのかなぁ
また混乱したら聞きにくるよ
繰り返しになるけどありがとね
98:デフォルトの名無しさん
14/07/06 02:22:08.53 hcqFkKqd
なんで頑なにPro Gitとかを読もうってしないんだ連中は
99:デフォルトの名無しさん
14/07/06 12:57:28.08 IqnhNmsn
ここの先輩って一つのフォルダにどのくらいプロジェクトを詰め込んでるのか教えてください
100:デフォルトの名無しさん
14/07/06 15:24:57.69 f2dQpJou
自分も興味ある＞どのくらい詰め込んでるのか
今はSubversionで10くらいのシステムを1システム1リポジトリで管理。
1システム(1リポジトリ)の中で document/client/server/moduleA/moduleB/... と複数ディレクトリを作って管理してる
Gitの場合、systemA-server/systemA-client という単位でリポジトリ作った方がいい？
101:デフォルトの名無しさん
14/07/06 16:16:31.85 aXyTuyHi
>>100
ケースバイケースとしか言いようがないけど、Subversionに比べてGitではリポジトリを分けることが多くなった。
っていうか、「フォルダ」と「プロジェクト」って、「リポジトリ」とどういう関係があるのか説明してくれないと上手いこと答えられないかも。
systemA-serverとsystemA-clientが割と個別に開発できるなら(つまり、サーバーは新しいけどクライアントは古いみたいなのがOKかどうか)
リポジトリは分けるし、サーバーとクライアントで同調して開発しなくちゃいけないならリポジトリは分けないほうがいいように感じる。
言語が別で共有コードがほとんどないような場合も分けることがあるかもしれない。
Subversionと違って、独立したものをなんでもかんでもリポジトリに突っ込むと別々に開発したときにマージが発生しまくってめんどくさいし、
Subversionでいうところのupdateをかけるフォルダの単位でリポジトリを分けたほうが面倒がないよ。Gitはリポジトリの一部だけを最新にするってことができないから。
102:デフォルトの名無しさん
14/07/06 18:40:54.69 8H24GUT0
systemA-serverとsystemA-clientにリポジトリを分けた時なんだけど、
両方で使えるライブラリがあったとする。
そういう場合は、汎用的なライブラリとして別リポジトリを作り
submoduleで登録すればいいんだよね。
この汎用ライブラリにバージョン1.0というのがあったとして、
systemA-serverからバージョン1.0のライブラリをsubmoduleで登録する
systemA-clientからも、通常は同じバージョンを使うだろうけど、
一時的に1.1を使う。なんてこともできる。
つまりsystemA-server、systemA-clientからは両方同じ外部リポジトリを
参照していながら、都合のいいバージョンを使うことが出来るんだよ。
まったくgitはよく考えて作られてるよ。
103:デフォルトの名無しさん
14/07/06 18:45:43.21 8H24GUT0
それからorphanブランチっていうのも忘れちゃいけないね。
systemA-serverとsystemA-clientで別のリポジトリに分ける。
これもありだけど、別の案として
同じリポジトリ内に、独立したブランチを複数作ることが出来る。
リポジトリは最初のコミットから、ずっと歴史を成長させていくものだと思っているかもしれないが、
実は、一つのリポジトリに、「最初のコミット」を複数作れる。
一リポジトリ＝一歴史 じゃないんだよね。
systemA-serverとsystemA-clientに別のリポジトリに分けなくても、
別のリポジトリにわかれているかのように使うことだって出来る。
104:デフォルトの名無しさん
14/07/06 18:50:04.07 J6LM3Iar
MavenとかRubyGemみたいな仕組みが利用できる言語なら、
ライブラリをsubmoduleで取り込む必要は無いね
まあでもそういうのが常に使えるわけじゃないからsubmoduleの仕組みを作ったんだと思うけど
105:デフォルトの名無しさん
14/07/06 23:12:18.37 5OIsyZ4O
コードを修正するたびにコミットログにupdateって書いてすぐにpushするんですけど
pushってどのタイミングでやってますか？
106:デフォルトの名無しさん
14/07/06 23:23:33.10 HJxqGFZE
>>105
テスト合格したらプッシュ
107:100
14/07/06 23:58:38.68 Jh/5AOzt
>>101-104
ありがとうございます。
知らないこと・未経験なことばかりで勉強になりますm(_ _)m
108:デフォルトの名無しさん
14/07/07 06:17:17.82 JBDMezlo
updateなんて意味のないメッセージのコミットは、pushする前に分かりやすくメッセージを書き換えたりsquashしたりした方がいいよ
109:デフォルトの名無しさん
14/07/07 08:35:06.30 dSawaSg/
commit はこまめに
完全に動かない時は動かない理由も書いて commit
push は動作確認出来たものを push
どうしても動作テスト通っていないものを push したいときは branch で
110:デフォルトの名無しさん
14/07/07 08:36:37.14 iqLntt6B
何回か前の commit のメッセージにスペルミスがあったのに気付きました
恥ずかしいので治しておきたいのですが過去の commit のコメントを治せますか？
111:デフォルトの名無しさん
14/07/07 09:33:06.41 sxx7xYnm
俺もそれ知りたいです
そういうときはいつもgit initからやり直してたので
112:デフォルトの名無しさん
14/07/07 09:49:15.90 TkAvh2GT
git rebase rewordでググれ
113:デフォルトの名無しさん
14/07/07 11:22:17.68 qZJT4lFx
git rebase -i commit~1
って感じ
114:デフォルトの名無しさん
14/07/07 16:51:47.32 KZfau/wE
スペルミスにより別の存在する単語になって文全体の意味が違うくなるってなら直す必要もあるかもだが
そうでなく本来のスペルを予測可能な範囲なら大抵はいちいち直さんやろ
115:デフォルトの名無しさん
14/07/07 21:00:46.13 rOGGoQLa
subversionもそうだけど、なんでコメントって
気軽に直せないんだろう？
git rebaseでもコメント修正したら
コミットID変わっちゃうし。
116:デフォルトの名無しさん
14/07/07 21:09:20.24 eRMueaNX
バージョン管理に関しては気軽に修正できるっていうのは必ずしも良いことではない
Gitは気軽に修正できる代わりにハッシュが必ず変わって修正が明白になるようにした
117:デフォルトの名無しさん
14/07/07 22:03:17.69 rOGGoQLa
いや、今の話はソースコードじゃなくて
コミットログの話だから。
さすがにソースコードを気軽に編集できればなんて話はしてない。
気軽に編集できる git notes をなぜ作ったのか？
コミットログを修正できればよかったのではないかって話。
118:デフォルトの名無しさん
14/07/07 22:16:10.15 eRMueaNX
コメントの修正も基本的には問題あるよ？
同じバージョンやハッシュでコメントの違うコミットがOKなVCSがあるとして
それらのコミットを先祖に持つ二つのブランチをマージするときどっちのコメントが引き継がれるべきだと思う？
notesはこういうときどんな扱いしてるんだろ
119:デフォルトの名無しさん
14/07/07 22:39:39.79 GtUCyZaI
タイポを修正したコミットのメッセージがタイポしてたら死んでも直したくなるだろ
120:デフォルトの名無しさん
14/07/07 22:53:15.16 4tIz5IJL
subversionは、コミットログを編集できるよ
121:デフォルトの名無しさん
14/07/07 23:00:28.64 eRMueaNX
それはまあ、非分散型だから問題にならないのかな？
分散型の場合にはコメントの編集がコミットを特定するIDとかに反映されないようだと困る
122:デフォルトの名無しさん
14/07/07 23:03:08.44 rnTCx4k1
コミットの私物化
123:デフォルトの名無しさん
14/07/07 23:23:04.44 YLk007Ty
>>115
> subversionもそうだけど、なんでコメントって気軽に直せないんだろう？
Subversion はフックを設定すれば修正できるようになるよ。
svn ログ 編集 辺りでググればやり方書いてある。
git は難しいと思うよ。
A さんと B さんで違う内容に編集したらどうするかとかから決めないとダメだろうし。
124:デフォルトの名無しさん
14/07/07 23:40:30.30 aVaaFMZ2
gitはコマンドや引数が複雑化しすぎている
今後登場するバージョン管理システムでこれを克服しなければならない
例えばlogとreflogならgit logとgit log -ref
125:デフォルトの名無しさん
14/07/07 23:41:56.88 aVaaFMZ2
統一できるコマンドは統一するのが大事
reflogはlogに吸収させてしまえばいい
そしてコマンドに対する引数もなるべく少なくすること
126:デフォルトの名無しさん
14/07/07 23:42:42.69 aVaaFMZ2
gitはphpみたいに汚い
127:デフォルトの名無しさん
14/07/07 23:58:44.89 KZfau/wE
BazaarやMercurialとかの他の分散型はgitほと汚くないの？
128:デフォルトの名無しさん
14/07/08 00:04:03.61 TkAvh2GT
reword >>126
squash >>125
squash >>124
# The first commit's message is:
汚いレスを圧縮
129:デフォルトの名無しさん
14/07/08 00:18:25.88 u9V+tSfl
よくも悪くも Linux なんだなぁと思う。
個人的には FreeBSD + Subversion の方が肌に合う。
130:デフォルトの名無しさん
14/07/08 01:36:57.96 hxSm+BQN
コミットログなんて、探すときのヒントなだけで、結局はChangeLogやdiffで確認するだろ。あとはtagとか。
131:デフォルトの名無しさん
14/07/08 01:52:11.38 iPzcgb4Q
リポジトリに対するログと、
作業スペースの履歴のログで意味が違うだろ
132:デフォルトの名無しさん
14/07/08 02:06:34.79 aM3L01D8
まさに意味が違うという話をしてたんじゃないの？
133:デフォルトの名無しさん
14/07/09 10:21:12.64 7mAKqlSH
>>114
fileId を fieId と書いてしまって
field って言う別の存在する単語と見間違えます
どうしたら治せますか？
>>121
コミットのコメントのログをバージョン管理に入れてしまえば良い
134:デフォルトの名無しさん
14/07/11 00:22:31.17 sjma/frv
git push -uの-uってなんですか？
毎回-u付けないといけないんですか？
135:デフォルトの名無しさん
14/07/11 00:41:29.05 YU+Bm/Jy
>>134
ヘルプくらい嫁
URLﾘﾝｸ(git-scm.com)
136:デフォルトの名無しさん
14/07/11 06:25:33.53 jWWrmOK/
必要なときは付けろとgitに言われる
137:デフォルトの名無しさん
14/07/16 01:04:59.81 1BA7HWeq
PJはSVN使ってるんだけど、諸事情あって今俺が書いてるソースはリリース直前までコミットできない
さすがに不安なんで、git-svnでローカルにだけでもgitとしてコミットしようとしてるんだけど、
git-svnって、TortoiseGitでもできるん？
git自体触ったこともないので、GUIなくてコマンド覚えるのに時間かかるようだったら諦める
138:デフォルトの名無しさん
14/07/16 09:01:10.65 7fshRLGV
>>137
TortoiseGitでも出来るが、gitを使ったことがないとちょっと解りにくいかも。
139:デフォルトの名無しさん
14/07/16 09:51:25.74 YAHvhD3g
最初TortoiseGitだとできるように見えなかったのが、コマンドでgit-svn使い始めたら
あちこちちゃんと対応してることにきがついたｗ
140:デフォルトの名無しさん
14/07/16 11:03:35.86 nVCK3WYF
initial commitってどのタイミングでコミットしたらいいのか教えてください
作るものは掲示板でお考えください
まずファイル構成を決めて空のファイルを作ってコミットするのか
何もファイルが存在しない状態でコミットするのか
ある程度動くものができたらコミットするのか
本当にわかりません
141:デフォルトの名無しさん
14/07/16 11:48:22.12 qYDy3YV9
特にセオリーは決まってなかったと思う
わからないなら空commitでおｋかと
142:デフォルトの名無しさん
14/07/16 13:12:44.48 dtGU31iT
initial なら 空っぽの RADME.md だけ作って commit てる
とりあえず何か commmit しとかないと diff がエラーになる
143:デフォルトの名無しさん
14/07/16 13:30:32.92 Sd4M1rY0
リリースバージョンで1.0と2.3とかつける時のコミットログはなんて書きますか？
git commit -m "Release: 1.0"みたいな感じ？
144:デフォルトの名無しさん
14/07/16 13:45:29.77 G80bT3bq
最近はREADMEをマークダウンで書いたりするのか。
145:デフォルトの名無しさん
14/07/16 13:46:33.57 G80bT3bq
>>143
tagつけるので、コミットメッセージは気にしない。
146:デフォルトの名無しさん
14/07/16 13:47:41.27 YAHvhD3g
GitHub使うとそれがデフォだったりするからな
147:デフォルトの名無しさん
14/07/16 14:05:10.01 Hxrp0ywP
GitHubだとリポジトリのリンク開いたときにトップディレクトリのREADME.mdをHTMLに変換して表示してくれるからね
トップディレクトリの一覧の下にそれを表示するんで、トップディレクトリ自体にはあまりファイルとかたくさん置かないようにしとくと更に見やすくて良い
148:デフォルトの名無しさん
14/07/16 14:15:16.78 Hxrp0ywP
>>142
一番最初に--allow-emptyで完全空っぽのコミット作ったりすると問題ある？
149:デフォルトの名無しさん
14/07/16 14:19:26.07 G80bT3bq
>>146
>>147
なるほろ。githubか。
150:デフォルトの名無しさん
14/07/17 18:11:47.91 FWioQIqe
プッシュし終わった跡に間違いに気づいてコミットしなおした
git commit -m "update"
git push
git add -A
git commit --amend -m "update"
ここからプッシュした内容をけして新しいコミットのをプッシュする場合はどうしたらよいか？
151:デフォルトの名無しさん
14/07/17 18:23:12.64 FWioQIqe
なんかgit pushしたら
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'git@*********:*********/*******.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
って出たのでgit pullしたら
Auto-merging server.php
CONFLICT (content): Merge conflict in server.php
Automatic merge failed; fix conflicts and then commit the result.
ってなったのでコンフリクトを直してaddしてcommitしてpushしました
>>150の跡にどうするのが一番良かったのか教えて下さい
152:デフォルトの名無しさん
14/07/17 18:37:46.64 5+M8kOpG
>>150-151
そもそも>>150をやってはいけない
pushしたコミットを--amendで直してはいけない
ただし場合によってはどうしてもやりたいときもあるので、そのときは git push -f を使う
push先のリポジトリの設定でこの操作が禁止されている場合もある
push -fをしてもいいのは、push先のリポジトリを自分しか見てないような場合とか、
自分以外の人が見てる場合にはその自分以外の人全員にpush -fする旨の許可を貰えるような場合
153:デフォルトの名無しさん
14/07/17 18:40:00.40 FWioQIqe
なるほどそうでしたか
これからはやらないことにします
こういうときって２回目のコミットログはfixとかって書いとけばいいですかね？
154:デフォルトの名無しさん
14/07/17 19:54:07.75 5+M8kOpG
>>153
コミットメッセージは何をfixしたとかupdateしたとかまで書いておいたほうがいいと思うけどね
155:デフォルトの名無しさん
14/07/17 21:16:30.65 0NORU4KM
チケット駆動とGitの組み合わせで開発するときに
何かするたびにチケット切って、それにあわせたブランチをGitで切って作業する運用って
プロジェクト中盤以降なら修正とか改善の粒度も小さいからしっくりくるんだけど
プロジェクトの何もない最初のほうは、１つの大きな機能の実装に2週間とかかかって、
それのせいでブランチ閉じられずにマージコミットやコンフリクトがあふれてなんかしっくりこない。
チケット駆動してる人は最初からチケット駆動してる？
それとも落ち着くまではmasterに直接コミット突っ込んだりしてる？
156:デフォルトの名無しさん
14/07/17 21:21:35.53 iWQxEqkT
>>153-154
--autosquash用のフォーマットの"fixup! 修正先のコミットID"、でいいよ
元々何をしたかったかは直前のコミットメッセージにあるわけだし
157:デフォルトの名無しさん
14/07/17 21:36:45.43 OTputfOO
コミットごとにpushするのはやめたほうがいい？
158:デフォルトの名無しさん
14/07/17 21:48:15.42 f9EwQ7K8
fixed #1223とかrefs #4643とかだな。
コメントだけではそれが安定か不安定かくらいしか見てない。
ローカルだとadhocとかno testとかもある。
159:デフォルトの名無しさん
14/07/18 00:19:24.35 9lilrWED
個人的なリポジトリなら自分が見やすいよう好きにすればいいし
共同のリポジトリなら仲間同士でルール決めてやるほうがよい
git flowやgithub flowあたりのメジャーなやりかたを採用するのもよい
コミットごとのpushがリポジトリを見づらくしてるよう思うのなら仲間と相談してしないようにルールを決めればよい
160:デフォルトの名無しさん
14/07/18 01:07:16.29 97CjBc8L
内容書くと、どこまで書くかという程度がそれぞれなので、文句が出る。
161:デフォルトの名無しさん
14/07/18 01:23:55.70 fn9HMHhn
>>150
> プッシュし終わった跡に間違いに気づいてコミットしなおした
> git commit -m "update"
> git push
> git add -A
> git commit --amend -m "update"
> ここからプッシュした内容をけして新しいコミットのをプッシュする場合はどうしたらよいか？
単純にpushしたらだめという意見が多いが別にそんなことはない。
運用の仕方による。
gitlabを使った場合のやり方。
メインのリポジトリからforkした個人のリモートリポジトリを作る。
これはgitlabにforkって機能があるんでそれを使うだけ。
メインのリポジトリには直接pushしない。個人のリモートリポジトリにpushする。
個人のリモートリポジトリは個人のものだから--amendして直してpushしていい。
そしてこの状態で思う存分レビューしてもらってNGなら直して--amendして
pushしてOKになったらメインのリポジトリにマージする。
162:デフォルトの名無しさん
14/07/18 06:26:27.67 P4uOsCCD
>>151
>>150 をやってしまったのなら pull してコンフリクトを治して add して commit して push するのが一番良い
163:デフォルトの名無しさん
14/07/18 07:43:45.67 NmG7h+bv
>>161
>>151 が聞いているのは
>>150 の状況にならないためにはどうすれば良いのか？ではなくて
>>150 の状況になってしまった場合どうすれば良かったのか？だから
その回答は今回の場合は適切じゃない
あ
でも
>>150 へのレスだからいいのかな
164:デフォルトの名無しさん
14/07/18 08:06:52.12 Vkkmxlwy
上書きしないですぐに修正コミット追加するかrevertしてじっくり修正
誰もrevert使ってないのは縛りプレイなの？
165:デフォルトの名無しさん
14/07/18 09:10:39.82 fn9HMHhn
>>164
通常のコミットと、マージコミットと二つあるんだよね。
* A機能のコミット
* B機能のコミット
* A機能の小さなバグ修正
* C機能のコミット
* B機能のrevert
* A機能の小さなバグ修正
* B機能の再コミット
とかいう、通常のコミットだけの履歴を作りたいのかと。
こういうのは、機能毎にマージコミットであるべき。
166:デフォルトの名無しさん
14/07/18 19:58:00.50 kcaMBvas
SGitってアンドロイドアプリ使ってみたことある人いる？便利なのかな
167:デフォルトの名無しさん
14/07/18 20:58:14.38 wFp38Dl6
2.0.2
168:デフォルトの名無しさん
14/07/20 12:13:18.06 6LE+xCsK
コミットてどのタイミングでやるべきか教えてください
例えば設定ファイルで設定を書いたらそこで1コミット
169:デフォルトの名無しさん
14/07/20 18:25:37.05 k6VJN0Us
はい
170:デフォルトの名無しさん
14/07/20 18:45:06.24 OS5ZzYFf
>>168
そんなのローカルルール。
特に分散型は同一プロジェクト内でも、リポジトリごとに違うことも。
171:デフォルトの名無しさん
14/07/20 18:47:28.99 llZw+pKm
>>168
後でいくらでも直せるんだから
ローカルでコミットするタイミングは
バックアップとっておきたいと思ったタイミングだな。
一箇所修正したらコミットとかやるときもある。
コンパイルできなくてもやるときもある。
そのあとpushする前に意味がある単位でコミットを作り直すな。
意味がある単位とは言い換えると、コミット一個だけ取り消したいと思う単位とか
誰かにコードを説明する時に「まず○○に関する修正ですが・・・」の単位とか。
意味が無いことはしない。意味があることをする。と考えれば
コミットに分けておくと、何かあった時に便利だなってことに
コミットすればいいんだよ。
172:デフォルトの名無しさん
14/07/20 20:52:14.88 zKSe34gp
1～3回目のコミットをまとめる方法をおしえて
いま10回目のコミットまでしてある
173:デフォルトの名無しさん
14/07/20 22:04:48.48 zKSe34gp
mkdir a
touch t.txt
git init
git add -A
git commit -m "ic"
mkdir b
git checkout -f←bディレクトリが残ったままとなる。なぜですか？
174:デフォルトの名無しさん
14/07/20 23:31:18.41 667cWtBA
checkout は、リポジトリに登録している物に対して作用する
b は、リポジトリの管理外だから無視する
175:デフォルトの名無しさん
14/07/20 23:36:41.49 tRUHKzxS
ってことはいちいちrm -rf * *.*ってやらないとだめそうですね
めんどくせえ
176:デフォルトの名無しさん
14/07/20 23:37:11.83 PtZju0so
何のために？
177:デフォルトの名無しさん
14/07/20 23:53:43.91 Veyq7Blc
いちからか？
178:デフォルトの名無しさん
14/07/20 23:54:29.30 tRUHKzxS
ファイルとかディレクトリを作った後にやりなおしたいんですよ
179:デフォルトの名無しさん
14/07/21 00:21:33.87 jb5Wh/p0
追跡されてないファイルやディレクトリを消すコマンドがあるかもね！？
180:デフォルトの名無しさん
14/07/21 00:40:34.84 bGaWqmfa
そ、その、、コマンドをどうかおしえてください・・・ガクッ
181:デフォルトの名無しさん
14/07/21 02:42:51.85 Udsw+XFD
git clean
182:デフォルトの名無しさん
14/07/21 04:21:43.81 DpfIQ25M
ファイルが無い空のディレクトリをpushしたいのですが
addしてもcommitしてもpush出来ません＞＜
183:デフォルトの名無しさん
14/07/21 05:28:30.74 75s/cUSB
>>182
.gitkeep
184:デフォルトの名無しさん
14/07/21 09:50:04.00 W2ckSfZN
ダミーファイルを置いておくという古典的方法じゃダメなん
185:デフォルトの名無しさん
14/07/21 12:48:57.77 mYM6Tgvw
.gitkeep って要するにダミーファイルだよな
186:デフォルトの名無しさん
14/07/21 13:39:37.03 jb5Wh/p0
今のところGit公式には.gitkeepを特別扱いするようなコードは無くてただのダミーファイルだよね？
ぶっちゃけ空の.gitignoreの方が悪影響は少ないと思うんだけど
名前が良くないってことなんだろうなあ
187:デフォルトの名無しさん
14/07/21 13:47:36.43 By4oX885
というか.gitignoreには「役割がある」からダメなんだと思う
「空のフォルダだけど必要なんです」と言うニュアンスを伝えるにはちょっと
188:デフォルトの名無しさん
14/07/21 13:54:08.75 Emref6q+
いくら「ローカルルールで違う」って言っても
さすがに「コミットメッセージの2行目は空行」を守ってないところはイメージできない
189:デフォルトの名無しさん
14/07/21 14:16:55.97 VU7LZ8It
ちゃんげログでもおいておけばいいじゃん
190:デフォルトの名無しさん
14/07/21 15:59:18.02 l1b5gSje
gitkeepの悪影響とは
191:デフォルトの名無しさん
14/07/21 16:05:11.66 FbNmBe/D
SCM変わったときに「Gitじゃないんだけどなー」と悶々とする。
CVSの頃は .keepme って名前のファイルがよくあったけど、
Svn文化を経由するときに失伝したらしい
192:デフォルトの名無しさん
14/07/21 16:06:20.21 kkLNQHqq
空のディレクトリが必要って状況が想像できない
193:デフォルトの名無しさん
14/07/21 16:20:40.07 FbNmBe/D
入門書とかにハッキリとは書かれてないので
運用してる人は少ないが、公開リポジトリの統合ブランチであっても
「このブランチはrebaseされることあるから、この上で作業すんなよ」
って予め宣言した使い捨てブランチを用意しとけば
そのブランチはpush -fしても全然問題ない。
新しいtopicはまず使い捨てブランチへマージし、
masterは定期的に使い捨てブランチにマージされて
しばらく生き残っているマージコミットまでffすればOK
こうしとけばmasterより先の使い捨て部分はいつでもやり直せる。
revertでもいいんだがゴミがたまるのが辛いし、
失敗してもやり直せる安心感にはかなわない感じ。
194:デフォルトの名無しさん
14/07/21 16:23:02.25 nldUh4DS
>>192
その理屈だと、ディレクトリの中を空にしたら
自動的にディレクトリが消えたほうがいいってことになるよ。
195:デフォルトの名無しさん
14/07/21 16:25:00.39 nldUh4DS
>>193
rebaseしてはいけないのは、”共有の"ブランチであって、
共有してないものはrebaseしてかまわないんだよね。
gitに限らないけどさ、○○したらだめという意見を見て
意味が分からないがとりあえず禁止だ。一切禁止だ。
みたいに考える人多いよ。
そんなのケースバイケースだろうと。
196:デフォルトの名無しさん
14/07/21 16:32:44.93 VU7LZ8It
いやいや自分のやり方以外は認められず否定しかできないのがお前らgitterという生き物
197:デフォルトの名無しさん
14/07/21 16:54:37.93 PFpi7FDC
>>195-196は同じことを違う側面から見ているのだと思う。
多分、微妙に知識がついて「○○したらダメ」「デフォルトの○○は有害でしかない」というような意見を見て信じこむから否定しかできなくなるんだよね。
で、そういうメリットデメリットを考えられない人がブログとかで同じことを強く喧伝するので広まっていくんじゃないのかな
自分も大抵のことはケースバイケースだと思うわ。
198:デフォルトの名無しさん
14/07/21 16:55:57.76 jb5Wh/p0
公開リポジトリ上のブランチのリベースは、回りに周知できてるならいいんじゃないか？
自分用のブランチだからcloneして参照すんなとか、
cloneして見ててもいいけどpullは失敗するかもしんないからそんときは自分でなんとかしろとか
ただ、周知できてないと、まえにこのスレにも沸いたキチガイみたいに
ただpullしてるだけなのにリポジトリ壊れたーとか言い出す奴がでる
199:デフォルトの名無しさん
14/07/21 17:16:50.55 dhFOCTWb
linuxのiptablesの設定ファイルとかをgithubで公開したいんですけどどんなやり方がありますか？
200:デフォルトの名無しさん
14/07/21 17:22:44.80 FbNmBe/D
みなさん、ブログの記事かじっただけの
「だれかがかんがえたさいきょうのワークフロー」
信者を相手に苦労してそうだなｗ
201:デフォルトの名無しさん
14/07/21 17:28:50.82 jb5Wh/p0
>>193はあんたの考えたサイキョウのワークフローじゃないのかよｗ
202:199
14/07/21 17:37:02.31 mynP+LTE
俺の質問に誰か！
203:デフォルトの名無しさん
14/07/21 17:37:51.41 mYM6Tgvw
>>194
そういうOSが有ってもいいとふとおもった
204:デフォルトの名無しさん
14/07/21 18:02:50.97 W2ckSfZN
その理屈だと初期ファイルをパラメータに渡さないとディレクトリを作れないってことになるよ
ついでにディレクトリと初期ファイルの権限設定も一緒に渡せると素晴らしいね
205:デフォルトの名無しさん
14/07/21 18:18:51.76 kkLNQHqq
gitで空ディレクトリを管理したいって話の流れで
何で一般的なファイルシステムでの話になってんだよ
206:デフォルトの名無しさん
14/07/21 18:29:09.64 nldUh4DS
>>205
ソースコードをチェックアウトすると、
ファイルシステムにディレクトリができるから。
結局のところ、空ディレクトリをgitで管理したい事の本質は
clone・checkoutした時に空ディレクトリを作りたいかって
ことになるんだよ。
207:デフォルトの名無しさん
14/07/21 19:00:28.92 FbNmBe/D
>>199
単一のファイルを公開したいだけならGistに貼るのがお手軽でいいんじゃね？
208:デフォルトの名無しさん
14/07/21 20:46:28.55 By4oX885
>>192
プロジェクトのディレクトリ構造を予め決めたい場合とか無いの？
209:デフォルトの名無しさん
14/07/21 22:18:25.16 75s/cUSB
>>188
何そのルール。コミットメッセージは1行しか書いたことない。
210:デフォルトの名無しさん
14/07/21 22:18:48.89 GJtkXJR5
でも、そのディレクトリ構造すらバージョン管理するケースを考えれば、プロジェクトのディレクトリ構造は生成スクリプトにしておくべきなのかもな
211:デフォルトの名無しさん
14/07/21 22:51:42.93 Udsw+XFD
>>209
URLﾘﾝｸ(keijinsonyaban.blogspot.jp)
これによると段落が続く場合は空行が必須っぽい
212:デフォルトの名無しさん
14/07/21 22:52:10.89 gNmDhqbD
>>210
> そのディレクトリ構造すらバージョン管理するケースを考えれば
subversionでは普通に出来たから、そこから移行してきた所が「同じこと出来ないの？」と思うのは分かる。
(出来たというか、タグやブランチもディレクトリ構造の履歴記録の応用として実現してるぐらいなんで>SVN)
213:デフォルトの名無しさん
14/07/21 23:20:16.59 VU7LZ8It
ただpullしてるだけなのにconflict起こすからなんらかの介入が必要になるのがgitとかいう糞vps
214:デフォルトの名無しさん
14/07/21 23:26:47.51 CUNvmPzK
今までの仕事で見たコミットログ
インターンで毎回こういうコミットログを送る奴がいた
お世話になります。インターンの△△です。
作業開始時刻 ○○：△△
作業終了時刻 ○○：△△
作業時間 ○○時間△分
作業内容
～ここに50行ぐらい～
次に作業する内容
～ここに10行ぐらい～
その他メンバーに報告したい事：
～ここに10行ぐらい～
215:デフォルトの名無しさん
14/07/21 23:30:01.63 75s/cUSB
>>211
メールにするようなローカルの場合じゃないか。
216:デフォルトの名無しさん
14/07/21 23:43:14.00 Udsw+XFD
>>215
> 変更に対する短い（50文字以下の）要約
>
> もし必要なら、より詳しい説明を述べる。
> 約72文字ほどで折り返すようにせよ。
>ある文脈では、最初の行はE-Mailの件名になり、残りのテキストが本文になる。
> 空行で本文と要約を分離するのは絶対に必要だ（本文を省略していない限り）。
> もしも二つを繋げてしまうと、rebaseのようなツールが混乱する可能性がある。
とあるからgitの仕様として空行は必要なんじゃない？
あ、でも要約を抜き出すときは空行があれば便利ってだけのことなのか
217:デフォルトの名無しさん
14/07/21 23:54:33.85 75s/cUSB
>>216
その前提がローカルって言っている。
218:デフォルトの名無しさん
14/07/21 23:55:00.47 NsSxsujv
rewrite aaa.txt (98%)
commitしたときに98%って表示されたんですけどこれ何？
219:デフォルトの名無しさん
14/07/22 00:18:41.70 oEdY4w5f
>>217
gitのコマンドラインの内蔵ツールの一部が前提としている条件なんだから、「ローカルルール」は言い過ぎなんじゃないの？
守らなくても動作しなくなるわけではないという意味では必須ではないだろうけど。
言葉の定義の問題になっちゃうけど、公式推奨ルール的なものはローカルルールとは言わないと思うけどね、普通は。
220:デフォルトの名無しさん
14/07/22 04:14:16.08 VGbmS+Eh
>>219
その内蔵のロジックを使ってる人にしか意味がないルール。
実装だ、というのであれば上記のように使わないという選択肢があるが、ルールは守るべきものでしょう。
単なるツールなのだから、ルールなんて無い気もするし。
単にそうなるというなら実装。
必要な場所では守るべきものなら、ローカルルール。
そういう場合もあるから、こうする癖をつけておいた方がいいというなら、ノウハウ、プラクティス。
221:デフォルトの名無しさん
14/07/22 04:57:47.89 m2X37Pt+
ローカル言いたいだけだろ
反抗期みたいなもんだから、スルーしときなよ
222:デフォルトの名無しさん
14/07/22 09:35:51.95 VGbmS+Eh
了解
223:デフォルトの名無しさん
14/07/22 14:01:00.00 9vLp8hBC
>>218
DNA鑑定の結果
224:デフォルトの名無しさん
14/07/22 18:10:41.04 DgetY8L8
コミットログをどうやって書いてるのか参考にしたいので
誰かおすすめのリポジトリおしえて
225:デフォルトの名無しさん
14/07/22 18:11:31.13 DgetY8L8
コミットが2000ぐらいあるリポジトリをクローンしたいんだけどさ
全部クローンするのは時間かかるので最初の1から50までのコミットだけ取る場合のやり方をおしえて
226:デフォルトの名無しさん
14/07/22 18:34:12.18 9vLp8hBC
>>224
git
227:デフォルトの名無しさん
14/07/22 18:34:36.00 rhcifys/
＞最初の1から50まで
「最新50コミット」って意味なら、きっちり需要を満たしているかはわからないけど
git clone --depth=50 repos
ちなみに今テストしたらreposがローカルにある場合は「file://path/to/repos」としないと全部コピーしちゃうので注意
228:デフォルトの名無しさん
14/07/22 19:09:09.68 W07N6TR2
ちがうよ最初の方の1から50
git init して一番初めの1から50まで
229:デフォルトの名無しさん
14/07/22 21:32:24.88 XzkIJVA+
Gitの場合、最初のコミットが1つじゃない可能性があるから
最初のコミットから50までっていう指定は無理なんじゃないか？
230:デフォルトの名無しさん
14/07/22 21:36:56.63 K/PzrTBo
最初のコミットだけじゃなくて、3つめまではどれかって話だよな。
A
│＼
↓ ↓
o o
↓ ↓
o o
↓ ↓
C B
231:デフォルトの名無しさん
14/07/22 21:41:51.82 IAzhYGe7
おそらくすべてのコミットの時系列的に50個目ってことっしょ
SVN的な
232:デフォルトの名無しさん
14/07/22 22:50:30.79 VGbmS+Eh
おそらく何にも考えてないだけっしょ
233:デフォルトの名無しさん
14/07/22 23:07:48.53 XzkIJVA+
ああたしかに、最初がひとつでも、HEADがひとつに定まらん可能性があるのな
HEADが複数な場合、そのそれぞれに対応したブランチ名が無いし、困ってしまうね
234:デフォルトの名無しさん
14/07/23 08:17:37.76 VxAus1Vh
HEADがひとつだとして、最初から50番目のコミットIDがわかれば、git fetchでいけるかと思ったけどうまくいかないね
hgだとclone -r コミットIDで途中までcloneできるんだけど
235:デフォルトの名無しさん
14/07/23 11:50:34.68 7MX9nHNJ
コミットログのよりよい書き方とかブランチの切り方とかコマンドを実行するタイミングとかいろいろ教えてください
ログは英語で書けないので日本語で書くものでお願いします
php rssdownload.php http://フィードのurl
でフィードを取得して最新1件をファイルに追記していくプログラムでお考えください
まだ何もコードを書いてない状態でgit init;git add .;git commit -m "Initial commit";します
そしてここでgit checkout -b develop
クラスと必要なメソッドを書きます。メソッドの中身はまだ書きません
class Rssdownload{public function getFeed(){//空}などいくつかメソッドを書く}
そしてgit add .;git commit -m "クラスとメソッドのスケルトンを追加"
ここからメソッドの中にコードを書きます。一番最初にgetFeedメソッドにダウンロードする処理を書きます
そして書きましたのでgit add .;git commit -m "フィードをダウンロードするメソッドを書いた"
git checkout master
git merge develop
こんな感じでいいでしょうか？
236:デフォルトの名無しさん
14/07/23 11:59:10.93 rdKtmwhJ
コミットは日本語使わない方が安全
237:デフォルトの名無しさん
14/07/23 12:37:02.01 GD00E4+x
>>235
だめです。
gitはバージョン管理です。
作業履歴を残すツールではありません。
バージョンなので機能に変更があった時がコミットになります。
メソッドの中身が無いものを作った所で機能（バージョン）
は何も変わってないのでコミットとしてとっておく必要がありません。
ただし、自分のローカルリポジトリや、
他人に作業内容をレビューしてもらうのが目的のブランチなら別です。
gitを作業履歴として使っているので、修正を説明したい単位でコミット取るのはありです。
だけどこれはメインブランチにマージされる時に一つ、
または機能の単位毎にまとめられます。
238:235
14/07/23 12:49:27.98 7Q0hA37B
おらがいなかもんだおもってうそこぐな>>237
239:デフォルトの名無しさん
14/07/23 13:19:16.16 iSdQDUGU
>>228
ぶっちゃけそんなもんを必要とする場面が想像できなくて、ただの煽りとしか思えないが、
とりあえず思いつくやり方は
一旦cloneする→cloneしたやつでgit resetする→さらにそこからcloneする
とかかな？
240:デフォルトの名無しさん
14/07/23 13:26:25.75 WJZjj5QG
それじゃだめです巨大リポジトリからダウンロードすると通信料かかるのです
241:デフォルトの名無しさん
14/07/23 13:56:00.92 iSdQDUGU
モバイルで全部事足りるからって固定回線全部捨てたお前が悪い
242:デフォルトの名無しさん
14/07/23 14:03:19.99 xMQ/Q89h
subversion で旧バージョンをもとにフォークしたときは普通にgit svn clone できたけど
元がgit だと全部持ってきたほうがよさそうね
243:デフォルトの名無しさん
14/07/24 14:59:58.63 +FhslZO7
Git 2.0.3 リリース
URLﾘﾝｸ(github.com)
244:デフォルトの名無しさん
14/07/24 15:37:36.88 r6QGED5m
ブランチを切り替えて作業した内容をmasterブランチにマージする場合の定石コマンドを教えて
245:デフォルトの名無しさん
14/07/24 15:46:46.70 2xZpDB05
github で自分のブランチから master->branch の pull request を作る
246:デフォルトの名無しさん
14/07/24 16:59:10.13 EZX0DS/3
自分の作業用ブランチならrebaseしてpushしてもいいの?
247:デフォルトの名無しさん
14/07/24 17:17:53.40 RXCuruZL
その質問には答えられません
248:デフォルトの名無しさん
14/07/24 18:38:47.92 2xZpDB05
自己責任で済まないからな
249:デフォルトの名無しさん
14/07/24 18:43:04.61 4y3AwbX8
>>246
運用上、そのブランチをベースにして誰かがコミットを重ねてなきゃいいよ
250:デフォルトの名無しさん
14/07/24 19:12:11.39 eQap2LAf
>>246
キチガイがpullする可能性があるかどうかも気にしておけ！
251:デフォルトの名無しさん
14/07/24 20:44:52.79 EZX0DS/3
バックアップ的にpushしときたいんだよね
この時点で間違ってるのかな
252:デフォルトの名無しさん
14/07/24 20:58:24.83 HrSZ7LES
そのためのブランチ
253:デフォルトの名無しさん
14/07/24 21:04:30.41 eQap2LAf
まあ、外部にpushしとくと少し安心感が増すよね
rebaseすること前提の個人ブランチ名の運用ルールでも決めときゃいいんじゃない？
254:デフォルトの名無しさん
14/07/24 21:26:52.08 f4kjQ3wJ
>>250
別にpullされても、その人のlogがおかしくなるだけだろ？
エラーが出るわけでもない、ただFFできないからマージコミットになるだけ。
そういうブランチがあったとしても、誰も困らない。
255:デフォルトの名無しさん
14/07/24 21:34:03.12 f4kjQ3wJ
>>253
決める必要あるの？
だって共有じゃないものは、自分を含めた誰かの個人のブランチでしょ？
自分のブランチは自分で管理すればいいし、他人のブランチは無関係。
共有リポジトリに沢山ブランチができて邪魔なぐらいでrebaseするかどうかはどうでもよくない？
共有ブランチをrebaseするなっていうのは、
みんながそのブランチをベースにして開発するからなわけで、
共有じゃないものはどうだっていいと思うけどな。
もっともうちではgitlabつかって、個人リポジトリにforkして
リポジトリ間でMerge Request（githubでいうPull Request）を
送ってるけどね。共有リポジトリは共有ブランチだけになるし、
そのほうがフローが綺麗なんだよ。
256:デフォルトの名無しさん
14/07/24 21:34:07.17 pB/6WHYI
masterにマージしてpushしちゃうかもしれないのがキチガイのキチガイたる所以
257:デフォルトの名無しさん
14/07/24 21:35:16.51 eQap2LAf
>>254
修正前と修正後をマージすることになるから、場合によってはコンフリクトするよね？
258:デフォルトの名無しさん
14/07/24 21:39:07.36 eQap2LAf
コンフリクトするならマシかな？
修正前と後が両方残るような変な感じにマージされちゃわない？
259:デフォルトの名無しさん
14/07/24 21:48:24.81 pB/6WHYI
>>255は統合マネージャー型のワークフロー前提だから話が噛み合わない
中央集権型のワークフローの場合にどうしよう？って話
260:デフォルトの名無しさん
14/07/24 21:52:46.54 f4kjQ3wJ
>>256
> masterにマージしてpushしちゃうかもしれないのがキチガイのキチガイたる所以
そんなにmasterへのpushをロックすればいいだけじゃね？
gitlabでそうしてるけど？
261:デフォルトの名無しさん
14/07/24 21:54:30.75 f4kjQ3wJ
>>259
なんだよ、統合なんたらとか集中とか
自分用語言われてもわからんわｗ
gitなんだからgitらしく使え。
262:デフォルトの名無しさん
14/07/24 21:56:38.90 pB/6WHYI
>>261
URLﾘﾝｸ(git-scm.com)
263:デフォルトの名無しさん
14/07/24 22:02:39.01 pB/6WHYI
あ、>>161でも噛み合ってない。
264:デフォルトの名無しさん
14/07/24 23:04:41.17 eQap2LAf
>>254
$ (mkdir foo1; cd foo1; git init; date > date1.txt; git add date1.txt; git commit -m "foo1 repo 1st")
$ git clone foo1 foo2
$ (cd foo1; git mv date1.txt date2.txt; git commit --amend --no-edit)
$ (cd foo2; git pull --no-edit)
$ (cd foo1; ls)
date2.txt
$ (cd foo2; ls)
date1.txt date2.txt
foo1レポジトリはdate1.txtを作ってそれをdate2.txtにmvしてコミット書き換え
それをcloneしてpullしていたfoo2には、date1.txtとdate2.txtの両方残っちゃった！
265:デフォルトの名無しさん
14/07/24 23:08:12.80 f4kjQ3wJ
>>264
何か問題が？
cloneした自分のブランチは自分で管理しろよ。
最新のブランチに同期したいなら、消してから取り直すだけでいい。
266:デフォルトの名無しさん
14/07/24 23:15:59.98 eQap2LAf
>>265
>>264は自分でcloneしてるけど、当然のことながら他人がcloneしてpullした場合にも同じことがおこるんだよ？
>>254の「別にpullされても、その人のlogがおかしくなるだけだろ？ 」これが間違ってるって言ってるの
おかしくなるのはlogだけじゃなくてリポジトリそのものが整合取れてない状態になる
自分なら消して取り直せばいいが、他人は気がつかない可能性があるのがわからんのか？
267:デフォルトの名無しさん
14/07/24 23:22:28.57 f4kjQ3wJ
え？ リポジトリはその人のローカルリポジトリでしょ？
そんなの知ったことじゃないじゃない。
前提として>>246に書いてあるように自分専用の作業ブランチの話だよ？
それを他人がどうとったからって、その人の問題じゃないか。
オリジナルの自分専用の作業ブランチは、自分で好き勝手していい。
それを他人が勝手に盗んで、その人のローカルリポジトリの
ブランチをどう書き換えようが、その他人さんが自分で責任もつことでしょ。
268:デフォルトの名無しさん
14/07/24 23:27:36.97 eQap2LAf
>>267
ふざけるなよ
おまえ自分の書いた>>254をよく読め
＞別にpullされても、その人のlogがおかしくなるだけだろ？
＞エラーが出るわけでもない、ただFFできないからマージコミットになるだけ。
＞そういうブランチがあったとしても、誰も困らない。
pullされたら、エラーもでるし、logだけじゃなくてレポジトリそのものがおかしくなる場合もある
FFできないマージコミットになるだけなんかでは断じてない
269:デフォルトの名無しさん
14/07/24 23:56:15.78 lcgW/ICS
masterの話は誰もしてない
270:デフォルトの名無しさん
14/07/24 23:59:45.07 RXCuruZL
あいまいな質問する奴と
あいないな質問にエスパーして答える奴
この２種類がいる限り
271:デフォルトの名無しさん
14/07/25 00:00:33.90 J29irW36
あと>>264も別にリポジトリはおかしくなってない
reflog見て適当なとこにresetするだけだ
272:デフォルトの名無しさん
14/07/25 00:03:19.67 oxVV+Dk5
>>271
reflogみて適当なところにresetしなきゃならないってことを、どうやって気がつけばいいいんだ
273:デフォルトの名無しさん
14/07/25 00:03:44.97 J29irW36
>>272
pullしたときforced update云々出るだろ
274:デフォルトの名無しさん
14/07/25 00:09:45.52 oxVV+Dk5
>>273
すべての人がforced updateに気づいて正しく対処できるとおもってんのか？
275:デフォルトの名無しさん
14/07/25 00:10:01.25 J29irW36
ていうか話がずれてて、他人の個人用ブランチをワーキングエリアに(カレントブランチに実際のファイルとして)展開してる馬鹿がいて
そいつが更にpullしたときにワーキングエリアが変になるってだけの話だろ？
masterか、チェックアウトされる可能性がある共有ブランチ書き換えない限りeQap2LAfの言うようなことは起きんよ
どう考えても「そんなこと知ったことではない」が正しい
276:デフォルトの名無しさん
14/07/25 00:12:51.68 oxVV+Dk5
まずは>>254が間違ってましたってゴメンナサイするのが先だろ
そして他人から見えるブランチをrebaseする可能性がある場合には
それが明確になるよう運用しなければいけない理由がわかったか？
277:デフォルトの名無しさん
14/07/25 00:13:38.00 0uQevWYT
>>246
結論
こういう(>>247-276)トラブルを避けるためにもやらないのが無難
やるならトラブルを引き起こすリスクを覚悟した上で自己責任で
278:デフォルトの名無しさん
14/07/25 00:14:51.81 HVzq131/
100行あるコードをコミットしました
そして10行まで削除してコードを書きなおそうと思います
そこで最後にコミットした内容を見ながらコードを書きたいんですけど
最後のコードを表示する方法を教えてください
279:デフォルトの名無しさん
14/07/25 00:15:17.80 J29irW36
いや変なのは明らかにeQap2LAfなんだが・・・
280:デフォルトの名無しさん
14/07/25 00:18:50.16 oxVV+Dk5
>>279
自分がおかしくないと思うなら、>>254が間違ってたことをまずは肯定してくれないかな？
281:デフォルトの名無しさん
14/07/25 00:19:44.83 0uQevWYT
>>278
2ペインの片方に最後のコードを表示できる賢いIDEを使いましょう
282:デフォルトの名無しさん
14/07/25 00:24:31.90 eA/GtSQx
>>281
そんなIDEは無いよ
283:デフォルトの名無しさん
14/07/25 00:25:55.65 0uQevWYT
じゃあ諦めましょう。
284:デフォルトの名無しさん
14/07/25 00:32:09.56 oxVV+Dk5
俺の使ってるIntelliJ IDEAは、前回コミットした内容をウィンドウに表示しながら別のウィンドウでそのファイルを編集できるぞ
さらに、編集中のウィンドウでは前回のコミットからどの行が編集されたかマークが表示されて、
そのマークをクリックすれば編集前の行の内容がポップアップで表示される
285:デフォルトの名無しさん
14/07/25 18:57:19.85 voM5b4Ni
>>266
> >>254の「別にpullされても、その人のlogがおかしくなるだけだろ？ 」これが間違ってるって言ってるの
わからん。解説たのむ。例えばふたつのリポジトリ
* A氏のリポジトリrepo-a、
* A氏のリポジトリからcloneしたB氏のリポジトリrepo-b
があったとする。
1. A氏がrepo-aに作業用ブランチworkをpushした。
2. B氏がrepo-aのworkをrepo-bにpull
3. B氏がrepo-bのwork上に独自にコミットを追加した。
4. A氏がworkをrebaseしてrepo-aにpushした
5. B氏がrepo-aのworkをpull -> repo-bのworkでマージ発生。
6. B氏発狂
7. A氏「しらねーよ。repo-aは正常だよ？」
何が問題なんだぜ？あえて言えば3でB氏がworkにコミット追加するのが間違いだが。
286:デフォルトの名無しさん
14/07/25 19:25:08.83 oxVV+Dk5
>>285
>>264の例をよく見てもらえばわかると思うんだけど、
B氏が単にcloneしてpullしただけで非FFのマージが発生する
そのマージはコンフリクトするか、まちがったマージになる
287:デフォルトの名無しさん
14/07/25 19:43:14.81 oxVV+Dk5
cloneしてその後リベースされたのをpullした場合
リベースされたrepo-aをfetchした段階でこうなる
repo-bのwork -> repo-aのworkのリベース前のコミット
repo-bのremotes/repo-a/work -> repo-aのworkのリベース後のコミット
そして次にmergeが動いてrepo-bのworkにrepo-bのremotes/repo-a/workをマージする
この2つのコミットは非FFな関係だからガチのマージが動くことになる
都合よくリベース前側のコミットの差分を無視なんかしてくれないからマズイ結果になる
288:デフォルトの名無しさん
14/07/25 19:59:14.18 J29irW36
だから>>286が間違いだっての
workブランチをワークスペースに展開してない限り何も起きねーよ
289:デフォルトの名無しさん
14/07/25 20:09:14.32 oxVV+Dk5
>>288
repo-aのworkブランチをcloneしてpullした場合の話をしてます
>>285もそういう前提の話でおｋ？
290:デフォルトの名無しさん
14/07/25 21:06:16.92 voM5b4Ni
>>287
> 都合よくリベース前側のコミットの差分を無視なんかしてくれないからマズイ結果になる
うんうん、
5. B氏がrepo-aのworkをpull -> repo-bのworkでマージ発生。
のことだよね？
それはworkという他人の作業ブランチをチェックアウトしている
B氏が注意して避けるべき問題であって、B氏以外の人が配慮するべき問題ではないよね。
B氏がそれを避けられないほど間抜けだっつう話だとしても、
B氏を哀れだとは思うがB氏以外の人が負担を強いられるべき問題だとは思わない。
291:デフォルトの名無しさん
14/07/25 21:33:38.76 oxVV+Dk5
>>290
5.が起こるのに3.は必要無いってことです
整理します。俺が>>254が間違ってると言ってる話の流れはこうです
246:
自分の作業用ブランチならrebaseしてpushしてもいいの?
250: >>246
キチガイがpullする可能性があるかどうかも気にしておけ！
254: >>250
別にpullされても、その人のlogがおかしくなるだけだろ？
エラーが出るわけでもない、ただFFできないからマージコミットになるだけ。
そういうブランチがあったとしても、誰も困らない。
※その人のlogがおかしくなるだけじゃなくてコミットもおかしくなる
※エラー(コンフリクト)も出る
※マージコミットになるだけじゃないくて、コミットの内容自体がオリジナルとは異なる
※そういうブランチがあったら誰も困らないなんてことは無い。そのpullしてる人は困る
この流れでは>>254は間違ってると言い切っていいよね？
292:249
14/07/25 22:17:26.06 nlpJ8mOy
なんとなく >>291 の主張していることが理解できた気がする。
たとえば他人の作業ブランチを勝手にpullしたキチガイのブランチが先にmasterにマージされたら、
元の作業ブランチをrebaseしたブランチを後でmasterにマージしようとしたときに
コンフリクトしたり意図しない結果になるだろう。
理屈はわからんでもないが、それはrebaseに限った話ではないし、そんなキチガイに自由にさせることがおかしい。
gitなら過去のcommitをすべて破壊することだってできる。
>>254 「別にpullされても、その人のlogがおかしくなるだけだろ？」
に対しては、通常の運用では正しい。そうならない運用があるならその運用は決定的に間違ってるのでルールを作れ。
キチガイがいたら教育するか排除するかしろ。
> この流れでは>>254は間違ってると言い切っていいよね？
よくない。>>254を否定する同じ理屈で「gitは危険だから使うべきでない」とも言える。
前提がバカバカしい。
293:デフォルトの名無しさん
14/07/25 22:26:51.08 oxVV+Dk5
>>292
いや、ちょっとまってくれよ？
「作業用ブランチならrebaseしてpushしてもいいのかどうか」については、してよいとも、してはいけないとも、俺は言ってない
＞ 246:
＞ 自分の作業用ブランチならrebaseしてpushしてもいいの?
＞ 250: >>246
＞ キチガイがpullする可能性があるかどうかも気にしておけ！
＞ 254: >>250
＞ 別にpullされても、その人のlogがおかしくなるだけだろ？
＞ エラーが出るわけでもない、ただFFできないからマージコミットになるだけ。
＞ そういうブランチがあったとしても、誰も困らない。
この250に対する254の書き込みが間違ってるかどうかだぞ？
>>291の※の指摘をよく見てくれ
おれの指摘は上記の書き込み以外の前提は全く無い
勝手に前提を仮定しないでくれ
294:デフォルトの名無しさん
14/07/25 22:31:44.14 oxVV+Dk5
作業用ブランチならrebaseしていいのかを議論する上で、実際にどんな影響があるのかをしっかり認識しておくのが重要だと思うんだ
それなのに、>>254のように間違った認識しかできてない状態で議論を進めるのは危険だろ
だからまず>>254の認識が間違ってることをはっきりさせたいんだ
どんな影響があるかをしっかり認識した上で、
勝手にpullする人の責任だっていう意見ならそれはそれでいいと思う
295:デフォルトの名無しさん
14/07/25 22:32:04.58 9e0PWdlB
gitスレって荒れやすいね
296:デフォルトの名無しさん
14/07/25 23:06:02.09 CnocSSYp
こんなの荒れてるうちに入らない
荒れているっていうのはこういうことを言うのだよ黄猿君
【PHP】下らねぇ質問はID出して書き込みやがれ 135
ｽﾚﾘﾝｸ(php板)
297:デフォルトの名無しさん
14/07/25 23:18:58.22 9e0PWdlB
俺がスレ荒れてると思えばそうなんだろう、俺ん中ではな！
298:デフォルトの名無しさん
14/07/25 23:22:28.88 voM5b4Ni
>>291
> 5.が起こるのに3.は必要無いってことです
たしかに別に3がなくても5で不要なマージコミットできちゃうね。
でもそれってB氏の責任というのが俺の立場だなぁ。
> ※そういうブランチがあったら誰も困らないなんてことは無い。そのpullしてる人は困る
つまり、
>>254「(pullした奴以外)誰も困らねーだろ」
>>250「pullした奴が困ってるじゃねーか」
ということかな。だいぶ君の主張が理解できた気がする。(つづく)
299:デフォルトの名無しさん
14/07/25 23:23:17.38 voM5b4Ni
だが、これを聞いてもやはりpullした奴(例えばB氏)が気をつけるべきだというのが俺の見解だよ。
理由はpullした奴(例えばB氏)も実はそんなに困らないからなんだ。
昔のGitだと当てまらないことも多いかもしれないが、
1. 上流を参照するだけのブランチはpull --rebaseで更新するようにする
2. 勝手に古いブランチを捨てるのが嫌ならpull --ff-onlyで上流のrebaseを検出できるようにする
3. git fetch 時の出力に (forced update) と表示されてないか注意しておく
4. pull/merge前の git status/checkout のときに your branch and'origin/work' have divergedと出力されない (ca be fast-forwardedと出力される)のを確認する
5. merge時のff-onlyとかをconfigに指定しとく
などなど (他にもある) 、いくらでも避ける手段はあるうえ、
万が一pullしてmergeが発生してしまったとしても、
resetやreflog, conflicしていた場合はmerge --abortとかで戻れるわけだし。
merge発生に気づかないほど間抜けなら(ry
300:249
14/07/25 23:28:10.04 nlpJ8mOy
>>293-294
お前さんの言いたいことはよくわかった。
結論: >>250 から先は意味のない議論だ。どうでもいい
キチガイが勝手に俺のブランチをpullしてrebaseしてmasterにマージしたらかなわんね。
すべてを破壊するキチガイの存在を肯定した議論など何の役にも立たない。
301:デフォルトの名無しさん
14/07/25 23:31:00.30 oKdTZN9u
> キチガイが勝手に俺のブランチをpullしてrebaseしてmasterにマージしたらかなわんね。
手元にはあるのだから、pushしなおせば？
キチガイを持ち出すなら、キチガイが会社中のパソコンを
壊しまわることもあるので、それはキチガイをどうにかすればいいという話で
もはやgit関係ない。何を使おうが壊そうと思えば壊せる。
302:デフォルトの名無しさん
14/07/25 23:34:04.18 oxVV+Dk5
>>299
何度も言いますが、誰が気をつけるべきかという問題と、>>254が間違ってるかどうかは、関係ありません
誰が気をつけるべきかどうかという問題を議論する前に、
>>254が間違っているかどうかをはっきりさせておきたいのです
どういう影響があるかをはっきりさせないと、誰が「何を」気をつけるべきかという点が曖昧になってしまいます
そういうわけで、>>254が間違っているかどうかを答えて頂けませんか？
303:249
14/07/25 23:34:35.23 nlpJ8mOy
そう。>>250 から先はgit関係なくてほとんど意味がない。
「gitを使ってどういう嫌がらせができるか」という話にしかならない
304:デフォルトの名無しさん
14/07/25 23:36:29.29 voM5b4Ni
>>300 >>291
pullしてmerge発生したのに気づかず上流のmasterにpushしちゃうってことを危惧してたの？
だとしたらそんなことするアホにpush権限与えてしまった上流リポジトリのオーナーが間抜けって話だね。
305:デフォルトの名無しさん
14/07/25 23:36:32.91 oxVV+Dk5
>>300
実際にpullされたときにどういう現象が起こるかどうかをはっきりさせておくのは重要だと思いませんか？
それをはっきりさせることでどこまで許容できるかという話が可能になります
306:デフォルトの名無しさん
14/07/25 23:40:56.18 oxVV+Dk5
>>304
>>161あたりがこの話題の元になってると思うんですよ
気になるのはここですね
＞そしてこの状態で思う存分レビューしてもらってNGなら直して--amendして
＞pushしてOKになったらメインのリポジトリにマージする。
レビューしてるひとに迷惑かかりますよね？rebaseしてるからレビューするひとは毎回ブランチ作り直しです
307:デフォルトの名無しさん
14/07/25 23:45:53.97 voM5b4Ni
>>302
> そういうわけで、>>254が間違っているかどうかを答えて頂けませんか？
うーん、俺の理解は↓のとおりだよ。
>>254「(pullした奴以外)誰も困らねーだろ」
>>250「pullした奴が困ってるじゃねーか」
254の発言を字面通りに解釈するなら君の言うとおりpullしたやつが困ってる、という意味で「誰も」は正確ではないと主張は可能だね。
だけど、254は(俺もだけど)暗黙的にpullした奴が困ってるのはそいつの責任だからしったこっちゃねーよ
(しかも避ける方法・回復する方法などいくらでもあるから本当には困ってねーだろ)
という意味で「誰も困らない」と言っているのだと思うけど？
だから、単純に字面を額面通りに捉えて >>254 が間違っているという主張には賛同できないな。
どうだろう？
308:249
14/07/25 23:51:17.91 nlpJ8mOy
>>304
「気づかず」ではなくて >>291 が主張しているのは半ば意図的に
他人の「作業」ブランチをベースとしたブランチを作った上でそれを操作してmasterに
マージする(など各種ブランチ操作)が技術的に可能、という話だと思う。
元のブランチがそれを意図していないなら嫌がらせの類だと感じる。
masterにマージするのはそいつでも他の誰かでもいい。
> そんなことするアホにpush権限与えてしまった上流リポジトリのオーナーが間抜けって話だね。
そういう話にしかならないから不毛
309:デフォルトの名無しさん
14/07/25 23:51:38.74 oxVV+Dk5
>>307
なぜあなたは>>254の最後の「誰も困らねーだろ」が「(pullした奴以外)誰も困らねーだろ」であることを知っているのでしょうか？
私は文面どおり「 (pullされた奴もpullした奴も)誰も困らねーだろ」の意味にとりました
なぜなら1行目と2行目でpullした奴に実質的に影響が無いということを述べているからです
あなたは>>254かエスパーなのでしょうか？
310:デフォルトの名無しさん
14/07/25 23:54:12.80 voM5b4Ni
>>306
> レビューしてるひとに迷惑かかりますよね？rebaseしてるからレビューするひとは毎回ブランチ作り直しです
それでいいのでは。
レビューで出される指摘事項に依存すると思うけど、
「あっちのコミットとこっちのコミットは一つのコミットにするべきだから、fixupして」
あるいは
「このコミットは2種類の変更が混じってるから分割して」
とかの指摘だった場合、rebase以外で対応するのは原理的に無理だよ?
311:デフォルトの名無しさん
14/07/25 23:57:06.19 oxVV+Dk5
>>307
とりあえずあなたは、>>254の3行目に関しては文面どおり捕らえれば間違っているが、
「(pullした奴以外)誰も困らねーだろ」と解釈できるから間違っていないという意見ということでいいですか？
>>254の1行目と2行目はどう解釈しようも無く間違っているということでいいですか？
312:249
14/07/25 23:59:51.07 nlpJ8mOy
>>307
> >>254「(pullした奴以外)誰も困らねーだろ」
> >>250「pullした奴が困ってるじゃねーか」
そうではなくて、 >>302 や >>309 が主張しているのは
「pullした奴が、(オリジナルブランチのAuthorなど)他のメンバーを困らせることが可能」ということだと思う。
でもオリジナルのブランチの作者がrebaseするとかしないとかもう全然関係ないのがね。
意図的に人を困らせる操作なんかいくらでもあるので
313:デフォルトの名無しさん
14/07/26 00:00:00.83 p4ua17EP
>>309
まず、おれは >>254 じゃないよ
俺の中では >>299 で書いたようなことが暗黙的な前提になってるから、
>>254 のような発言を見た時に
「(pullした奴以外)誰も困らねーだろ」
と解釈したなぁ。
普段も上流をそのまま追いかけたいブランチをチェックアウトしてる場合、
上流からfetchする際は上流のrebaseが無かったか、mergeする前にfast-forwardになるか
必ずチェックするし。
314:デフォルトの名無しさん
14/07/26 00:01:49.35 JET6jTHt
>>310
常に問題無いというわけでは無いですよね
レビューする人も人間ですからミスしてpullしちゃう可能性があります
なのでレビューのやりとりでrebaseするかどうかをはっきり表明しておく必要があると思います
315:デフォルトの名無しさん
14/07/26 00:08:57.84 JET6jTHt
>>313
なるほど。たぶんあなたは>>254の1～2行目の問題に>>298で初めて気がついたからそういう解釈になってしまったのですね
316:249
14/07/26 00:11:27.38 7f7nHnx7
>>>307
>なぜあなたは>>254の最後の「誰も困らねーだろ」が「(pullした奴以外)誰も困らねーだろ」であることを知っているのでしょうか？
>私は文面どおり「 (pullされた奴もpullした奴も)誰も困らねーだろ」の意味にとりました
ただの日本語が不自由な人じゃないか・・・
一生懸命考えて損した。
この板もID出るようになってるのか。いいことだ。
317:デフォルトの名無しさん
14/07/26 00:12:26.21 JET6jTHt
>>313
本来こういう迷惑をかけないために公開リポジトリはrebaseしないというルールがあるのですけどね
＞普段も上流をそのまま追いかけたいブランチをチェックアウトしてる場合、
＞上流からfetchする際は上流のrebaseが無かったか、mergeする前にfast-forwardになるか
＞必ずチェックするし。
チェックする必要があるというのは修羅の国ですね
318:249
14/07/26 00:17:47.11 7f7nHnx7
>>317
ヒント
> 246 ：デフォルトの名無しさん：2014/07/24(木) 16:59:10.13 ID:EZX0DS/3
> 自分の作業用ブランチならrebaseしてpushしてもいいの
319:デフォルトの名無しさん
14/07/26 00:19:37.53 p4ua17EP
>>314
レビューしてもらう側からrebaseしたよ、と言うのは親切かもしれないけど、
レビューする側(とくにmergeする責任を負う奴)は master..topic にどういうコミットが
表示されるかぐらいはチェックするよ。つーかそれがレビューという作業だと思うけど？
topicを送ってきた相手によっては、
「そいつの仕事を完全に信頼してるので言われたとおりmergeする」
ってのもあるかもしれないよ。
でもそれによって送ってきた奴のミスが伝搬してしまうのはしょうがないよな。
そんなこと言い始めたらいくらでも変な状況は想定できるわけだし。
320:デフォルトの名無しさん
14/07/26 00:19:47.98 JET6jTHt
>>316
1行目と2行目でpullする人には実質的な影響無いよ！ってことを述べているのに、
3行目が突然(pullする人以外)誰も困らないよ！って意味になってるとしたらおかしいですよね？
普通に考えれば(pullする人は)誰も困らないよ！って意味になると思います。
＞別にpullされても、その人のlogがおかしくなるだけだろ？
＞エラーが出るわけでもない、ただFFできないからマージコミットになるだけ。
＞そういうブランチがあったとしても、誰も困らない。
321:デフォルトの名無しさん
14/07/26 00:22:24.95 p4ua17EP
>>315
>>254
> 別にpullされても、その人のlogがおかしくなるだけだろ？
> エラーが出るわけでもない、ただFFできないからマージコミットになるだけ。
ここかい？
間違いがあるとしたら、
「エラーが出るわけでもない」→コンフリクトすることもあるね
くらいかな。
他にどんな間違いが？
322:デフォルトの名無しさん
14/07/26 00:24:55.79 p4ua17EP
>>320
おおぅ、そういう解釈してるの？
> ＞別にpullされても、その人のlogがおかしくなるだけだろ？
ここの「その人」はpullした人だよ。明確にpullした人に(表面上)困ることが示されてる。
323:デフォルトの名無しさん
14/07/26 00:26:11.79 p4ua17EP
>>322
> ここの「その人」はpullした人だよ。明確にpullした人に(表面上)困ることが示されてる。
いかん、俺の日本語が不自由になってきた
(誤) pullした人に(表面上)困ること
(正) pullした人に(表面上)困ったことがおきること
です。
324:デフォルトの名無しさん
14/07/26 00:28:41.04 JET6jTHt
>>321
「logがおかしくなるだけ」では無いですね？コミットの内容もおかしくなります
「ただFFできないからマージコミットになるだけ」では無いですね？
不正なマージコミットになることを「ただFFできないからマージコミットになるだけ」と表現するのは無茶だと思います
325:デフォルトの名無しさん
14/07/26 00:31:07.31 p4ua17EP
>>324
> >>321
> 「logがおかしくなるだけ」では無いですね？コミットの内容もおかしくなります
> 「ただFFできないからマージコミットになるだけ」では無いですね？
> 不正なマージコミットになることを「ただFFできないからマージコミットになるだけ」と表現するのは無茶だと思います
ごもっとも。
だがその状態はpullしたやつの手元のワーキングツリーで起こってるだけでしょ？
326:デフォルトの名無しさん
14/07/26 00:33:37.83 JET6jTHt
>>322-323
>>254の1～2行目からはコミットの内容までがおかしくなると考えてるとは読み取れないのですが？
つまりpullerには実質的な影響は無いと考えていると思われます
327:デフォルトの名無しさん
14/07/26 00:39:35.54 JET6jTHt
>>325
pullしたやつの手元のワーキングツリーで起こってるから、pullした奴が困るのです
328:デフォルトの名無しさん
14/07/26 00:40:04.95 p4ua17EP
>>326
> >>254の1～2行目からはコミットの内容までがおかしくなると考えてるとは読み取れないのですが？
> つまりpullerには実質的な影響は無いと考えていると思われます
いやいやいや、そこから共有できてないのか。
ログが違う(ログに現れるコミットが違う。たとえば余計な空のコミットが存在する)だけであっても、
Gitの性質上、それ以外、例えばブランチ先端のツリーが全く同一、差分などなど諸々が同じであったとしても、
Gitの履歴としては全くの別物になっている、というのがGitのメカニズムだし
Gitユーザの常識だと思うんだが。(よほどの初心者は違うかもしれんが)
329:デフォルトの名無しさん
14/07/26 00:42:58.86 JET6jTHt
>>328
つまり、その状態を「ただFFできないからマージコミットになるだけ」と表現する>>254が馬鹿だったということでいいですか？
330:デフォルトの名無しさん
14/07/26 00:44:08.14 p4ua17EP
>>327
> pullしたやつの手元のワーキングツリーで起こってるから、pullした奴が困るのです
そうだね。pullしたやつが可哀想だね。
でも本当はpullした奴も困らないでしょ？ と俺はずっと言っているわけだ。
>>299 を100回くらい読んではくれまいか。
331:デフォルトの名無しさん
14/07/26 00:52:49.47 p4ua17EP
パトラッシュ、疲れたろう。僕も疲れたんだ。なんだか、とても眠いんだ。
332:デフォルトの名無しさん
14/07/26 00:55:04.24 JET6jTHt
>>330
>>299は良いことが書いてあると思いますよ
pull --ff-onlyするようにとか簡単でいいですね
ただ、なぜそういうことをする必要があるかということを>>254を見て誤解してしまったような人は理解できないと思うんですよ
なので、>>254の「ただFFできないからマージコミットになるだけ」とかを見た人が誤解しないように
真意をはっきりさせておく必要があると思います
333:デフォルトの名無しさん
14/07/26 00:56:18.19 JET6jTHt
>>331
寝たら死にますよ
334:デフォルトの名無しさん
14/07/26 01:05:33.08 3J1xCNng
>>332
ということにしたいのですね。
335:デフォルトの名無しさん
14/07/26 01:17:03.50 7f7nHnx7
>>327
貴方は細かいところによく気づく素晴らしい力を持っていますね。
更に文脈を読み大意を掴む力をつけるとさらに価値あるエンジニアになれると思います。頑張ってくださいね。
>>254 のこの部分
> エラーが出るわけでもない、ただFFできないからマージコミットになるだけ。
は確かに正確ではないですね。間違いといっても差支えないでしょう。
ただ、>>254 は
>>250
> キチガイがpullする可能性があるかどうかも気にしておけ！
を受けてるので、大事なのは
> 別にpullされても、その人のlogがおかしくなるだけだろ？
つまり他人の作業ブランチをpullしたキチガイさんが困るだけ、ってところだと思いますよ。
そのキチガイの他には影響は及ばないからそんなもの考慮する必要はない、という主張です。きっと。
あとは枝葉だから誰も気にしなかった。しかし貴方は気づいた。素晴らしい