トップページ⇒tech
1001コメント321KB

Git 10

レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん2014/06/22(日) 17:40:25.81ID:mgZTcG6H
ソースコード管理を行う分散型バージョン管理システム、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 9
http://peace.2ch.net/test/read.cgi/tech/1397276540/
0002デフォルトの名無しさん2014/06/22(日) 18:02:10.08ID:b06vElF6
ｲﾁｵﾂ
0003デフォルトの名無しさん2014/06/22(日) 18:33:54.01ID:2+Nzucu/
Gitを使うと早漏になるの？だったら嫌だなあ、使うの控えるべきかしら？
0004デフォルトの名無しさん2014/06/22(日) 18:45:39.07ID:Zf5ltYR1
ｱｰｲｷｿ
0005デフォルトの名無しさん2014/06/22(日) 18:55:46.49ID:3ROl0TsY
　∧＿∧　　　　　　 SVN？ ぎっとぎとにしてやんよ
　(　･ω･)＝つ≡つ
　(っ　≡つ＝つ
　/　　　) ﾊﾞﾊﾞﾊﾞﾊﾞ
　( /￣∪
0006デフォルトの名無しさん2014/06/22(日) 19:03:02.96ID:kD+jIMJ8
　　　　 　　　　　　　　　　ノ 　　　　 ﾟ.ﾉヽ　 , /}　　　　　　...
　　　　　　　　　　　　,,ｲ`"　　　　　､-' 　 `;_' '　　　　..::::::::::::::...
　　　,-､　　_.._　　　(　　　　　　　　(,(~ヽ'~　　　　　..:::::::::::::::::::::::
　）'~ 　ﾚｰ'　　〉　　 ヽ　　　　　　　i`'}　　　　　　　.:::::::::::::::::::::::
　~つ　　 　　'-ｰ､　　i　　　　　　　|　i'　　　　　...:::::::::::::::::::::::
　／　　　　　　 <　　/　　　　　。/ 　 !　　......:::::::::::::::::::::::::　　　　これは>>1乙じゃなくて
/　　　　　　　　　~^´　　　　 /},-''　,●::::::::::::::::::::::::::::::::::::
i､　　　　　　　　,i'　_,,...,-‐-､/　　　 i　 ::::::::　　.:::::::::::::
..ゝ　　　　　　　　<,,-＝=､　　　,,-,/　　　　　 .:::::::::::　　　　　　　　　　　　放射能がうんたら
　)　　　　　　　{~''~>`v-''`ｰﾞ`'~　　　　　　　..:::::::::　　　　　　　　　　　　　　　　　　　　　　　　　　........::.
　{　　　　　　　 ﾚ_ﾉ　　　　　　　　　　　　..::::::::.　　　　　　　　　　　　　　　　　　　　　　　　　......:::::::::
ノ　　　　　　　　　''　　　　　　　　　　　..:::::::　　　　　　　　　　　　　　　　　　　　　　　 ...::.:...:::::::::
　　　　　　　　　　　　　　　　　　　　 .:::::::::　　　　　　　　　　　　　　　　　　　　　...:......::::::::::::　.
　　　　　　　　　　　　　　　　　　　　.:::::::::::.　　　　　　　　.....　　　　　 ..　　..::::::::::::::::::::::::　　　:::.
　　　　　　　　　　　　　　　　　　　　::::::::::::::::.::::::....:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::..　::　 ::..
　　　　　　　　　　　　　　　　　　　 .::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::　:::　　　　::.
　　　　　　　　　　　　　　　　　　　　:::::::::::::::::　::::::::::::::::::::::::::::::　:::::
　　　　　　　　　　　　　　　　　　　　　　　　　 .::　　　 ::.　　:::
0007デフォルトの名無しさん2014/06/23(月) 10:11:42.41ID:sjU94AhZ
◆関連スレ
バージョン管理システムについて語るスレ10
http://peace.2ch.net/test/read.cgi/tech/1393147031/
CVS導入スレ〜 Rev.3
http://peace.2ch.net/test/read.cgi/tech/1113141518/
Subversion r14
http://peace.2ch.net/test/read.cgi/tech/1326806859/
【分散型バージョン管理】 Mercurial 2【hg】
http://peace.2ch.net/test/read.cgi/tech/1321109748/
【bzr】Bazaarでバージョン管理 Rev 4
http://peace.2ch.net/test/read.cgi/tech/1356521407/
OSSホスティング総合【SourceForge,GitHub,etc..】
http://peace.2ch.net/test/read.cgi/tech/1384821518/

◆関連スレ 別板
CVS 1.3 [UNIX板]
http://peace.2ch.net/test/read.cgi/unix/1093611448/
0008デフォルトの名無しさん2014/06/23(月) 10:12:16.78ID:sjU94AhZ
◆関連書籍
Pro Git 日本語版電子書籍公開サイト
http://progit-ja.github.io/

開発効率をUPする Git逆引き入門 2014/04 著:松下雅和 船ヶ山慶 平木聡 土橋林太郎 三上丈晴
http://www.c-r.com/book/detail/970

Git ポケットリファレンス 2012/07 著:岡本隆史 武田健太郎 相良幸範　
http://gihyo.jp/book/2012/978-4-7741-5184-7

Gitによるバージョン管理 2011/10 著:岩松信洋 上川純一 まえだこうへい 小川伸一郎
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06864-5

実用Git 2010/02 著:Jon Loeliger オライリー本
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-87311-440-8

入門Git 2009/9 著:濱野純
http://www.shuwasystem.co.jp/products/7980html/2380.html

入門git 2009/08 著:Travis Swicegood 監訳:でびあんぐる
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06767-9
0009デフォルトの名無しさん2014/06/24(火) 10:55:31.19ID:BxyDqmCe
スレ立てて書き込み少な目で放置しとくと落ちるのは自動なのか？このスレは大丈夫なのかね？
0010デフォルトの名無しさん2014/06/24(火) 12:46:36.12ID:/C23Uhbr
入門Git以外は手に取ってみる価値もない
でFA?
0011デフォルトの名無しさん2014/06/24(火) 14:19:17.66ID:oDNeDxJ6
GoogleAppsScriptで書いたソースをgitでリポジトリ管理するにはどうすればいい？
0012デフォルトの名無しさん2014/06/24(火) 16:36:15.78ID:Q+GgUeFG
>>11
import/exportができるみたいだからそれ使えばいいんじゃないの？
http://qiita.com/soundTricker/items/e75ee1f2a7d89fa60a60

単に特殊なデプロイが必要になるってだけ。
0013デフォルトの名無しさん2014/06/25(水) 10:27:08.76ID:51nve3hM
import/export を自動化するスクリプトを GoogleAppsScript で書けないかな
0014デフォルトの名無しさん2014/06/26(木) 08:42:26.78ID:rb3EhG0/
>>10
どっちの？
0015デフォルトの名無しさん2014/06/26(木) 10:06:12.43ID:BCJ2ygce
念のためにこっちにも
Git 2.0.1 リリース
https://github.com/git/git/releases/tag/v2.0.1
0016デフォルトの名無しさん2014/06/26(木) 11:59:36.41ID:lzGhXXy2
>>14 君には入門Gitが入門gitに見えるのかね
0017デフォルトの名無しさん2014/06/26(木) 15:13:00.47ID:I1GlggqH
スレ番も数字じゃなくハッシュ値で
0018デフォルトの名無しさん2014/06/26(木) 20:19:34.54ID:uNXRCBxV
さ　あ　、　も　り　あ　が　っ
　　　　　　　　　　　　　　　　　　て
　　　　　　　　　　　　　　　　　　　　　ま
　　　　　　　　　　　　　　　　　　　　　　　い
　　　　　　　　　　　　　　　　　　　　　　　　 り
　　　　　　　　　　　　　　　　　　　　　　　　　 ま
　　　　　　　　　　　　　　　　　　　　　　　　　　 し
　　　　　　　　　　　　 　　　　　　　　　　　　　　た
0019デフォルトの名無しさん2014/06/27(金) 12:01:47.48ID:wewJM3ti
兆戦の皿が白ばっかりなのは
土器みたいに茶色いままだと
うんこが付いてても気付かないから
0020デフォルトの名無しさん2014/06/27(金) 22:32:20.88ID:VuPlBIMA
日本の器に黒っぽいのが有るのはうんこが付いてても気にせず食べるから？
0021デフォルトの名無しさん2014/06/28(土) 01:35:08.69ID:sQNJ1q5c
皿にうんこが付く状況ってどんなんだよ
0022デフォルトの名無しさん2014/06/28(土) 04:37:58.98ID:w+QI/fAg
器にうんこが付くという発想がないから
0023デフォルトの名無しさん2014/06/28(土) 04:57:32.01ID:sKWOMnpi
トンスルランドでは台所に便所紙捨てるところがあるんだっけ
0024デフォルトの名無しさん2014/06/28(土) 06:10:14.26ID:WBXNiQjo
日本に観光に来てる連中は
ホテルのトイレでも紙をゴミ箱に入れるので
従業員を困らせている
0025デフォルトの名無しさん2014/06/28(土) 06:50:34.22ID:6GT+Y+O2
日本も戦前は同じだったそうだよ
0026デフォルトの名無しさん2014/06/28(土) 07:49:42.50ID:88+ODrtr
ここまで Git の話なし
0027デフォルトの名無しさん2014/06/28(土) 10:47:37.20ID:pkB82Erl
今日のうんこスレはここですか
0028デフォルトの名無しさん2014/06/28(土) 23:12:42.12ID:c56+A2pI
一、清潔な食事運搬用バケツと雑巾バケツの区別をよく教えること。

こんな注意書きが必要な連中なので
0029デフォルトの名無しさん2014/06/29(日) 00:18:04.03ID:/NI7q9pJ
敗戦直前の日本の雑誌に、汚れたバケツに貯まった雨水を飲み水に使うことの美徳が書かれていたって話を思い出すな

それはともかく、Gitのブランチ管理はややこしいよなー
未だに解説読みながらやってる
0030デフォルトの名無しさん2014/06/29(日) 00:54:31.86ID:f0WIPed4
gitのブランチ管理じゃなく
git flowもしくはgithub flowのブランチ管理がややこしいのでは
0031デフォルトの名無しさん2014/06/30(月) 22:40:23.98ID:5h8Y0Ud2
$ git clone https://github.com/username/repo.git ← 自分のリポジトリ(SSHキーは登録済み)

色々作業してローカルでコミットした

$ git push
fatal: could not read Username for 'https://github.com': No such file or directory
↑
なんでなん…
その後こうしたらpush出来た
↓
$ git remote rm origin
$ git remote add origin '[email protected]:username/repo.git'

originを変更しないと駄目な理由を分かりやすく教えてください
0032デフォルトの名無しさん2014/06/30(月) 22:46:39.87ID:v5UqmfMQ
>>31

http://git-scm.com/book/ja/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC-%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB

> HTTP 越しの Git のプッシュを行うことも可能ですが、あまり使われていません。
> また、これには複雑な WebDAV の設定が必要です。めったに使われることがないので、本書では取り扱いません。
> HTTP でのプッシュに興味があるかたのために、それ用のリポジトリを準備する方法が
> http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt で公開されています。
0033312014/06/30(月) 23:03:26.98ID:5h8Y0Ud2
>>32
おお！素早いご指摘どうもです
よく理解できました
これからはそのドキュメントを良く読むようにします
0034デフォルトの名無しさん2014/06/30(月) 23:10:54.18ID:v5UqmfMQ
っていうかGitHubってhttpsでのpushに対応してたっけ？
0035デフォルトの名無しさん2014/06/30(月) 23:24:02.07ID:ocNeWDMt
httpsのアドレス宛にいつもpushしてるが
0036デフォルトの名無しさん2014/07/01(火) 02:04:03.39ID:uudBEfHR
>>31
単にpushする先を指定してないだけだろ。

URL指定でcloneしているから、
originと紐付いてないだろうし。
0037デフォルトの名無しさん2014/07/01(火) 20:07:37.99ID:dBLK7YMD
ローカルリポジトリのブランチhogeにコミットしました

ここでリモートリポジトリのhogeにコミットするはずが、リモートのmasterにコミットしてしまいました。

取り消すにはどうすればいいのでしょうか？
0038デフォルトの名無しさん2014/07/01(火) 20:22:39.16ID:M2q2ii4G
パルプンテを唱える。
0039デフォルトの名無しさん2014/07/01(火) 20:23:17.83ID:M2q2ii4G
もしくはメガンテ
0040372014/07/01(火) 20:24:46.81ID:dBLK7YMD
git remote -v
origin https://hoge.com/fuga.git (fetch)
origin https://hoge.com/piyo.git (push)

git add . --all
git commit -m "hoge"

git push origin master

to https://hoge.com/fuga.git
master -> master

git branch -a したら

remotes/origin/HEAD -> origin/master

と出てきたんですが、これはhttps://hoge.com/fuga.gitのmasterにコミットされたということですよね？
0041デフォルトの名無しさん2014/07/01(火) 20:25:26.30ID:rJGfEq1K
用語が変なのはgit使いでなくsvn使いとかか
0042デフォルトの名無しさん2014/07/01(火) 20:28:16.54ID:sZ99gDnh
>>37
リモートリポジトリの管理者にごめんなさいして、どう処理するか相談する
0043372014/07/01(火) 20:39:43.94ID:dBLK7YMD
リモートリポジトリをcloneしてmasterブランチのlog見たらコミット履歴にありませんでしたが・・・
どこにコミットされたのでしょうか・・・

>>41
その通りです
0044デフォルトの名無しさん2014/07/01(火) 20:44:17.29ID:rJGfEq1K
用語がめちゃくちゃで何を言ってるのか何をやりたいのかさっぱり分からん
0045デフォルトの名無しさん2014/07/01(火) 20:54:30.74ID:sZ99gDnh
>>40
その一番最初の git remote -vの結果が正しければ、
そのリポジトリで普通にpushすると https://hoge.com/piyo.git に反映されるはず

それなのに https://hoge.com/fuga.git にpushされたというログになってるのはオカシイ
＞git push origin master
＞to https://hoge.com/fuga.git
＞master -> master
写し間違えた？

>>43でcloneして確認したリポジトリは https://hoge.com/piyo.git か https://hoge.com/fuga.git のどっち？
0046372014/07/01(火) 22:06:47.31ID:dBLK7YMD
質問が不明瞭、かつ書き間違いなどがあり申し訳ありませんでした。
もう一度できるだけ詳しく正確に書くように致します。
0047デフォルトの名無しさん2014/07/01(火) 22:21:48.75ID:dBLK7YMD
git remote -v
　　origin https://hoge.com/fuga.git (fetch)
　　origin https://hoge.com/fuga.git (push)
　　upstream https://foo.com/fuga.git (fetch)
　　upstream https://foo.com/fuga.git (push)
※「https://hoge.com/fuga.git」は「https://foo.com/fuga.git」を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 https://hoge.com/fuga.git
　　　　dvcx245..9frr0bf master -> master
※ここで「git push origin branchB」とするはずが間違えて「master」にコミットしてしまいました。


ログから判別すると、現状は、https://hoge.com/fuga.gitのmasterブランチにコミットしてしまってると見るべきですよね？
ところがhttps://hoge.com/fuga.gitのmasterをcloneしてログを確認してもさっきのコミットが残っておらず、実際変更したはずのファイル(x.cpp)を見ても変わってないんです…。
0048デフォルトの名無しさん2014/07/01(火) 23:38:48.46ID:sZ99gDnh
>>47
それは、ローカルのmasterブランチをhttps://hoge.com/fuga.gitのmasterブランチにpushしただけだね
https://hoge.com/fuga.gitのmasterブランチの最新が9frr0bfに更新されてるはずだよ
0049デフォルトの名無しさん2014/07/02(水) 00:34:49.55ID:KQlLn9XQ
>>48
ありがとうございました。
しかし、幾ら試してもhttps://hoge.com/fuga.gitのmasterのコミットログにないんです・・・。

恐らくこのまま放置することにします。
長々と書き込んでしまいすいませんでした。
0050デフォルトの名無しさん2014/07/02(水) 01:06:49.78ID:OroZGiqB
>>49
いやだから、書き込みを良く見てくれ
「ローカルのbranchBじゃなくて、ローカルのmasterを、リモートのmasterへpusuしてる」
したがって、ローカルのbranchBにコミットしたx.cppファイルがhttps://hoge.com/fuga.gitのmasterに無いのは当然

それて、pushが成功したかどうかはファイルの有無じゃなくてハッシュで確認しろ
git branch -av で各ブランチと対応するハッシュを確認できる
0051デフォルトの名無しさん2014/07/02(水) 01:17:52.28ID:En/r/TGL
pusu
0052デフォルトの名無しさん2014/07/02(水) 01:26:05.54ID:OroZGiqB
>>50-51
おう、pusuはpushのタイポな
0053デフォルトの名無しさん2014/07/02(水) 01:29:18.74ID:En/r/TGL
example.なんとか使えつって教わらなかったのか
0054デフォルトの名無しさん2014/07/02(水) 22:13:56.81ID:mhKrJc1t
VisualStudioのExpressでバージョン管理したいからGit入れたいんだけど
GUIで楽にローカルリポジトリ作る方法ってある？
0055デフォルトの名無しさん2014/07/02(水) 23:02:29.91ID:87h9OT3W
はい、tortoisegitさんお呼びですよ
0056デフォルトの名無しさん2014/07/02(水) 23:06:30.92ID:mhKrJc1t
亀ってリポジトリ作れるの？
0057デフォルトの名無しさん2014/07/02(水) 23:40:22.67ID:j/Db3LoH
もちろん
0058デフォルトの名無しさん2014/07/02(水) 23:50:54.99ID:mhKrJc1t
単独で作れるのか
ありがとう
0059デフォルトの名無しさん2014/07/02(水) 23:55:08.90ID:87h9OT3W
Visual Studioに組み込めるプラグインもあるかも知れんけど
わかんね。msdnでも覗いてみれ。
0060デフォルトの名無しさん2014/07/03(木) 03:35:02.68ID:LFvCfQY8
VSに組み込めるプラグインがあるとしても、Expressは拡張機能サポートしてないからどのみちダメじゃないか？
0061デフォルトの名無しさん2014/07/03(木) 03:39:50.30ID:j0zMe+Fe
VS2013ならMSが公式でGitのプラグインを出してなかったか
0062デフォルトの名無しさん2014/07/03(木) 05:54:32.69ID:DIfIjFzr
Azure専用
0063デフォルトの名無しさん2014/07/03(木) 06:02:01.97ID:fWjka1bK
Windowsが7以降ならSourceTreeもあるな
0064デフォルトの名無しさん2014/07/03(木) 09:57:25.05ID:T6nbxnRY
2013はExpressでもIDEからgit使えるけど、どうもわかりにくい
ankhsvnくらいに手軽だといいのだが、、、よって亀とコマンドライン併用
Xcodeの内蔵はかなり使いやすいと思った。
0065デフォルトの名無しさん2014/07/03(木) 19:41:43.68ID:dti37cU6
msysgitダウンロード出来ねぇ…
500ってなんだ…
0066デフォルトの名無しさん2014/07/03(木) 21:06:15.26ID:tTUYGcci
サーバの内部エラー
0067デフォルトの名無しさん2014/07/03(木) 21:06:41.59ID:tTUYGcci
https://github.com/msysgit/msysgit/releases/
行けた
0068デフォルトの名無しさん2014/07/03(木) 21:16:47.31ID:dti37cU6
ありがと！いけた
0069デフォルトの名無しさん2014/07/03(木) 21:22:28.52ID:dti37cU6
gitは正常に終了しませんでした (終了コード 128)

とか言われた…
なんだこれ…
0070デフォルトの名無しさん2014/07/03(木) 21:29:51.18ID:ljTzUKRX
あ〜、俺もそれなった。64bit Windows7
余計な物が入るのがいやなんだろうけど
msysgit諦めて
http://git-scm.com/
から丸々落としたら問題なくインストールできた
0071デフォルトの名無しさん2014/07/03(木) 21:31:59.03ID:VhhMtL7W
…え？
git-scmからmsysgitじゃないWindows用gitが入手できたの？
0072デフォルトの名無しさん2014/07/03(木) 21:39:27.88ID:dti37cU6
>>70
おｋ入れてみる

…の前にアンインスコしとこっと
0073デフォルトの名無しさん2014/07/04(金) 01:20:38.78ID:ZQHJOpH+
msysgitのアンインスコがそもそも出来なくねえか？
ネットにはコントロールパネルからアンインスコしろと書いてあったが
インスコの途中でエラッたからかどうか分からんが、そんなものはなかった

とりあえず、面倒くさいのでインスコされたフォルダごと削除してやったけど
とりあえず、今のところ、その後、上記をインスコして問題ない

ところで、
インストールの時に聞かれる設定で
Checkout as-is, commit as-is
について、改行コードの勝手な変換は百害あって一利なしって言い切ってるサイトもあれば
なんか、それだとソフトウェア的に不具合が出る場合があるんで他の設定にした方がいいってサイトもあるんだが
実際にはどうなの？

個人的には、改行コードを勝手に変換されるなんて害以外の何物でもないと思うので
問題ないなら、何も変換させたくないのだが
0074デフォルトの名無しさん2014/07/04(金) 08:40:05.93ID:xvFt74Dw
>>73
いろいろな環境でやるならlfだけにしておいて、各環境でチェックアウト時にcr,crlf,lfで使うのが楽じゃない？
ソースじゃなくてなんか特殊なファイルとか管理するならきめうちのほうがいいかもだし、
自分ひとり開発とかチームで環境が変わる要素がないならそのままでもよい
0075デフォルトの名無しさん2014/07/04(金) 20:58:59.90ID:G9V8ZPtC
企業でgit使う場合ってリポジトリは暗号化して使うものですか？そのへん詳しい人教えてください
0076デフォルトの名無しさん2014/07/04(金) 21:41:37.64ID:KGk1oj/Q
>>75
基本的に、暗号化してからadd,commitするよ
0077デフォルトの名無しさん2014/07/04(金) 22:46:19.47ID:VHgyx1X4
>>75
詳しくはないけど。
鍵やデータはバージョン管理しないんじゃない。暗号化するようなファイルシステムなら、されちゃうかもだけど。
0078デフォルトの名無しさん2014/07/04(金) 23:32:09.16ID:7y8V145d
ん？Git-scmってのはmsysgitの代わりに使うって認識で良いの？
0079デフォルトの名無しさん2014/07/05(土) 00:32:02.32ID:7oOEkOAN
msysGitというプロジェクトでWindows用のGitが開発されていて
その成果は(Linux版やMac版も含めた)Gitの総合サイトであるgit-scmでも
やはりWindows用Gitとして配布されている…？

>>70 はつまり落とすサイトの話をしていて
開発版でなく安定版落としました、みたいな話なのかな

…俺もWindows版はよく知らんので、誰かツッコミ頼む
0080デフォルトの名無しさん2014/07/05(土) 01:34:47.12ID:oA33QTWa
git-scm.comのDownload for Windowsで落ちてくるのは
https://github.com/msysgit/msysgit/releases/ のGit-1.9.4-preview20140611.exeじゃない？

>>70がうまく行かなかったのは同じ場所
https://github.com/msysgit/msysgit/releases/ のmsysGit-netinstall-1.9.4-preview20140611.exe
の方じゃないかな？

前者はバイナリだけの配布で、
後者はネットワーク経由インストールでコンパイル環境なんかも含めたすべてを落とせる？
0081デフォルトの名無しさん2014/07/05(土) 05:17:04.89ID:SaA3Dhwi
そこで、cygwin で git ですよ。
オレオレビルドで、新しいリリースがすぐ使える
0082デフォルトの名無しさん2014/07/05(土) 14:14:39.37ID:oc6wEiev
http://tracpath.com/bootcamp/learning_tortoisegit.html
これ見ながらやろうと思っても、Git Bash起動するとすぐ画面閉じるんだけど
Git bashってどうやって使うの
0083デフォルトの名無しさん2014/07/05(土) 14:29:48.66ID:oA33QTWa
>>82
msysgit のインストールに失敗してるんだろ
0084デフォルトの名無しさん2014/07/05(土) 14:45:31.43ID:oc6wEiev
あれ？もしかしてmsysgitインストールしたらmsysgitってフォルダ作られる？
C:\Program Files (x86)\Git
とは別に？
0085デフォルトの名無しさん2014/07/05(土) 14:57:24.31ID:Q/k3+41v
win7にmsysgitをインストールしたら↓のディレクトリにインスト―ルされたけど、Git Bashもこの中だし

C:\Users\Hiroshi\AppData\Local\Programs\Git
0086デフォルトの名無しさん2014/07/05(土) 15:03:51.27ID:oc6wEiev
そうか…やっぱ失敗してんのかな
500から403に変わってGoogle Codeからは相変わらずダウソ出来ないし
もう少し探してみるか…
ありがとなヒロシ
0087デフォルトの名無しさん2014/07/05(土) 15:16:53.89ID:oA33QTWa
>>86
しばらく前から動かないって言ってるひとか？
インストールに失敗してるんじゃなくて、アンインストールに失敗してるんじゃないか？
ゴミが残ってて新しくインストールしたmsysgitがうまく動かないみたいな感じ
0088デフォルトの名無しさん2014/07/05(土) 15:51:10.99ID:oc6wEiev
うーん
つってもとりあえず『アンインストールとまたは変更』から削除したんだけど
それじゃ足りないのかな？
ゴミがどこに残り得るのかすらわからんのだけど
0089デフォルトの名無しさん2014/07/05(土) 15:59:32.61ID:oA33QTWa
そういうのは地味に調べるか、できなきゃOS再インスコかね
自分もWindowsはよくわからんから、Winでこの手のツールをインストールしまくるのは嫌だね
なので、構成を自分でだいたい把握できてるcygwin版を使ってる
0090デフォルトの名無しさん2014/07/05(土) 20:52:23.99ID: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)
0091デフォルトの名無しさん2014/07/05(土) 21:02:46.99ID:Q/k3+41v
お前のwindowsが単にぶっこわれてるだけなんじゃね
0092デフォルトの名無しさん2014/07/05(土) 21:03:11.07ID:oA33QTWa
>>90
それは STATUS_ACCESS_VIOLATION でググルと対策らしいのが出てくるぞ
TEMPフォルダ絡みらしい
0093デフォルトの名無しさん2014/07/05(土) 21:08:28.81ID:oA33QTWa
中途半端にGitのコードにユニコード対応とか入れた影響なんだろうなあ
日本語Win環境なんかじゃ試して無いだろうし
オリジナルのGitがほぼそのまま動くCygwinがやっぱええわ
0094デフォルトの名無しさん2014/07/05(土) 21:20:01.50ID:oc6wEiev
>>92
おぉ、ほんとだありがとう
キャッシュ自体1.5Gもあったしちょうどよかった…
0095デフォルトの名無しさん2014/07/05(土) 21:35:39.83ID:DUJJhZn/
>>93
なんかユニコードがらみで問題でもあったの？
0096デフォルトの名無しさん2014/07/05(土) 21:58:23.52ID:oA33QTWa
>>95
TEMPフォルダにゴミがあると>>90みたいに落ちるらしい
特に日本語ファイル名のファイルとかあるとダメ
Unicode対応前のバージョンなら問題無いとか
0097デフォルトの名無しさん2014/07/06(日) 01:52:41.07ID:2At6bBxp
やっと使えるようになったよ
ありがとう

コミットの概念が、SVNとちょっと違うのかなぁ
また混乱したら聞きにくるよ
繰り返しになるけどありがとね
0098デフォルトの名無しさん2014/07/06(日) 02:22:08.53ID:hcqFkKqd
なんで頑なにPro Gitとかを読もうってしないんだ連中は
0099デフォルトの名無しさん2014/07/06(日) 12:57:28.08ID:IqnhNmsn
ここの先輩って一つのフォルダにどのくらいプロジェクトを詰め込んでるのか教えてください
0100デフォルトの名無しさん2014/07/06(日) 15:24:57.69ID:f2dQpJou
自分も興味ある＞どのくらい詰め込んでるのか

今はSubversionで10くらいのシステムを1システム1リポジトリで管理。
1システム(1リポジトリ)の中で document/client/server/moduleA/moduleB/... と複数ディレクトリを作って管理してる
Gitの場合、systemA-server/systemA-client という単位でリポジトリ作った方がいい？
0101デフォルトの名無しさん2014/07/06(日) 16:16:31.85ID:aXyTuyHi
>>100
ケースバイケースとしか言いようがないけど、Subversionに比べてGitではリポジトリを分けることが多くなった。
っていうか、「フォルダ」と「プロジェクト」って、「リポジトリ」とどういう関係があるのか説明してくれないと上手いこと答えられないかも。

systemA-serverとsystemA-clientが割と個別に開発できるなら(つまり、サーバーは新しいけどクライアントは古いみたいなのがOKかどうか)
リポジトリは分けるし、サーバーとクライアントで同調して開発しなくちゃいけないならリポジトリは分けないほうがいいように感じる。
言語が別で共有コードがほとんどないような場合も分けることがあるかもしれない。

Subversionと違って、独立したものをなんでもかんでもリポジトリに突っ込むと別々に開発したときにマージが発生しまくってめんどくさいし、
Subversionでいうところのupdateをかけるフォルダの単位でリポジトリを分けたほうが面倒がないよ。Gitはリポジトリの一部だけを最新にするってことができないから。
0102デフォルトの名無しさん2014/07/06(日) 18:40:54.69ID:8H24GUT0
systemA-serverとsystemA-clientにリポジトリを分けた時なんだけど、
両方で使えるライブラリがあったとする。

そういう場合は、汎用的なライブラリとして別リポジトリを作り
submoduleで登録すればいいんだよね。

この汎用ライブラリにバージョン1.0というのがあったとして、
systemA-serverからバージョン1.0のライブラリをsubmoduleで登録する
systemA-clientからも、通常は同じバージョンを使うだろうけど、
一時的に1.1を使う。なんてこともできる。

つまりsystemA-server、systemA-clientからは両方同じ外部リポジトリを
参照していながら、都合のいいバージョンを使うことが出来るんだよ。

まったくgitはよく考えて作られてるよ。
0103デフォルトの名無しさん2014/07/06(日) 18:45:43.21ID:8H24GUT0
それからorphanブランチっていうのも忘れちゃいけないね。

systemA-serverとsystemA-clientで別のリポジトリに分ける。
これもありだけど、別の案として
同じリポジトリ内に、独立したブランチを複数作ることが出来る。

リポジトリは最初のコミットから、ずっと歴史を成長させていくものだと思っているかもしれないが、
実は、一つのリポジトリに、「最初のコミット」を複数作れる。

一リポジトリ＝一歴史 じゃないんだよね。

systemA-serverとsystemA-clientに別のリポジトリに分けなくても、
別のリポジトリにわかれているかのように使うことだって出来る。
0104デフォルトの名無しさん2014/07/06(日) 18:50:04.07ID:J6LM3Iar
MavenとかRubyGemみたいな仕組みが利用できる言語なら、
ライブラリをsubmoduleで取り込む必要は無いね
まあでもそういうのが常に使えるわけじゃないからsubmoduleの仕組みを作ったんだと思うけど
0105デフォルトの名無しさん2014/07/06(日) 23:12:18.37ID:5OIsyZ4O
コードを修正するたびにコミットログにupdateって書いてすぐにpushするんですけど
pushってどのタイミングでやってますか？
0106デフォルトの名無しさん2014/07/06(日) 23:23:33.10ID:HJxqGFZE
>>105
テスト合格したらプッシュ
01071002014/07/06(日) 23:58:38.68ID:Jh/5AOzt
>>101-104
ありがとうございます。
知らないこと・未経験なことばかりで勉強になりますm(_ _)m
0108デフォルトの名無しさん2014/07/07(月) 06:17:17.82ID:JBDMezlo
updateなんて意味のないメッセージのコミットは、pushする前に分かりやすくメッセージを書き換えたりsquashしたりした方がいいよ
0109デフォルトの名無しさん2014/07/07(月) 08:35:06.30ID:dSawaSg/
commit はこまめに
完全に動かない時は動かない理由も書いて commit
push は動作確認出来たものを push
どうしても動作テスト通っていないものを push したいときは branch で
0110デフォルトの名無しさん2014/07/07(月) 08:36:37.14ID:iqLntt6B
何回か前の commit のメッセージにスペルミスがあったのに気付きました
恥ずかしいので治しておきたいのですが過去の commit のコメントを治せますか？
0111デフォルトの名無しさん2014/07/07(月) 09:33:06.41ID:sxx7xYnm
俺もそれ知りたいです
そういうときはいつもgit initからやり直してたので
0112デフォルトの名無しさん2014/07/07(月) 09:49:15.90ID:TkAvh2GT
git rebase rewordでググれ
0113デフォルトの名無しさん2014/07/07(月) 11:22:17.68ID:qZJT4lFx
git rebase -i commit~1
って感じ
0114デフォルトの名無しさん2014/07/07(月) 16:51:47.32ID:KZfau/wE
スペルミスにより別の存在する単語になって文全体の意味が違うくなるってなら直す必要もあるかもだが
そうでなく本来のスペルを予測可能な範囲なら大抵はいちいち直さんやろ
0115デフォルトの名無しさん2014/07/07(月) 21:00:46.13ID:rOGGoQLa
subversionもそうだけど、なんでコメントって
気軽に直せないんだろう？

git rebaseでもコメント修正したら
コミットID変わっちゃうし。
0116デフォルトの名無しさん2014/07/07(月) 21:09:20.24ID:eRMueaNX
バージョン管理に関しては気軽に修正できるっていうのは必ずしも良いことではない
Gitは気軽に修正できる代わりにハッシュが必ず変わって修正が明白になるようにした
0117デフォルトの名無しさん2014/07/07(月) 22:03:17.69ID:rOGGoQLa
いや、今の話はソースコードじゃなくて
コミットログの話だから。
さすがにソースコードを気軽に編集できればなんて話はしてない。

気軽に編集できる git notes をなぜ作ったのか？
コミットログを修正できればよかったのではないかって話。
0118デフォルトの名無しさん2014/07/07(月) 22:16:10.15ID:eRMueaNX
コメントの修正も基本的には問題あるよ？
同じバージョンやハッシュでコメントの違うコミットがOKなVCSがあるとして
それらのコミットを先祖に持つ二つのブランチをマージするときどっちのコメントが引き継がれるべきだと思う？

notesはこういうときどんな扱いしてるんだろ
0119デフォルトの名無しさん2014/07/07(月) 22:39:39.79ID:GtUCyZaI
タイポを修正したコミットのメッセージがタイポしてたら死んでも直したくなるだろ
0120デフォルトの名無しさん2014/07/07(月) 22:53:15.16ID:4tIz5IJL
subversionは、コミットログを編集できるよ
0121デフォルトの名無しさん2014/07/07(月) 23:00:28.64ID:eRMueaNX
それはまあ、非分散型だから問題にならないのかな？
分散型の場合にはコメントの編集がコミットを特定するIDとかに反映されないようだと困る
0122デフォルトの名無しさん2014/07/07(月) 23:03:08.44ID:rnTCx4k1
コミットの私物化
0123デフォルトの名無しさん2014/07/07(月) 23:23:04.44ID:YLk007Ty
>>115
> subversionもそうだけど、なんでコメントって気軽に直せないんだろう？

Subversion はフックを設定すれば修正できるようになるよ。
svn ログ 編集 辺りでググればやり方書いてある。

git は難しいと思うよ。
A さんと B さんで違う内容に編集したらどうするかとかから決めないとダメだろうし。
0124デフォルトの名無しさん2014/07/07(月) 23:40:30.30ID:aVaaFMZ2
gitはコマンドや引数が複雑化しすぎている
今後登場するバージョン管理システムでこれを克服しなければならない
例えばlogとreflogならgit logとgit log -ref
0125デフォルトの名無しさん2014/07/07(月) 23:41:56.88ID:aVaaFMZ2
統一できるコマンドは統一するのが大事
reflogはlogに吸収させてしまえばいい
そしてコマンドに対する引数もなるべく少なくすること
0126デフォルトの名無しさん2014/07/07(月) 23:42:42.69ID:aVaaFMZ2
gitはphpみたいに汚い
0127デフォルトの名無しさん2014/07/07(月) 23:58:44.89ID:KZfau/wE
BazaarやMercurialとかの他の分散型はgitほと汚くないの？
0128デフォルトの名無しさん2014/07/08(火) 00:04:03.61ID:TkAvh2GT
reword >>126
squash >>125
squash >>124

# The first commit's message is:
汚いレスを圧縮
0129デフォルトの名無しさん2014/07/08(火) 00:18:25.88ID:u9V+tSfl
よくも悪くも Linux なんだなぁと思う。
個人的には FreeBSD + Subversion の方が肌に合う。
0130デフォルトの名無しさん2014/07/08(火) 01:36:57.96ID:hxSm+BQN
コミットログなんて、探すときのヒントなだけで、結局はChangeLogやdiffで確認するだろ。あとはtagとか。
0131デフォルトの名無しさん2014/07/08(火) 01:52:11.38ID:iPzcgb4Q
リポジトリに対するログと、
作業スペースの履歴のログで意味が違うだろ
0132デフォルトの名無しさん2014/07/08(火) 02:06:34.79ID:aM3L01D8
まさに意味が違うという話をしてたんじゃないの？
0133デフォルトの名無しさん2014/07/09(水) 10:21:12.64ID:7mAKqlSH
>>114
fileId を fieId と書いてしまって
field って言う別の存在する単語と見間違えます
どうしたら治せますか？

>>121
コミットのコメントのログをバージョン管理に入れてしまえば良い
0134デフォルトの名無しさん2014/07/11(金) 00:22:31.17ID:sjma/frv
git push -uの-uってなんですか？
毎回-u付けないといけないんですか？
0135デフォルトの名無しさん2014/07/11(金) 00:41:29.05ID:YU+Bm/Jy
>>134
ヘルプくらい嫁
http://git-scm.com/docs/git-push
0136デフォルトの名無しさん2014/07/11(金) 06:25:33.53ID:jWWrmOK/
必要なときは付けろとgitに言われる
0137デフォルトの名無しさん2014/07/16(水) 01:04:59.81ID:1BA7HWeq
PJはSVN使ってるんだけど、諸事情あって今俺が書いてるソースはリリース直前までコミットできない
さすがに不安なんで、git-svnでローカルにだけでもgitとしてコミットしようとしてるんだけど、
git-svnって、TortoiseGitでもできるん？
git自体触ったこともないので、GUIなくてコマンド覚えるのに時間かかるようだったら諦める
0138デフォルトの名無しさん2014/07/16(水) 09:01:10.65ID:7fshRLGV
>>137
TortoiseGitでも出来るが、gitを使ったことがないとちょっと解りにくいかも。
0139デフォルトの名無しさん2014/07/16(水) 09:51:25.74ID:YAHvhD3g
最初TortoiseGitだとできるように見えなかったのが、コマンドでgit-svn使い始めたら
あちこちちゃんと対応してることにきがついたｗ
0140デフォルトの名無しさん2014/07/16(水) 11:03:35.86ID:nVCK3WYF
initial commitってどのタイミングでコミットしたらいいのか教えてください
作るものは掲示板でお考えください
まずファイル構成を決めて空のファイルを作ってコミットするのか
何もファイルが存在しない状態でコミットするのか
ある程度動くものができたらコミットするのか
本当にわかりません
0141デフォルトの名無しさん2014/07/16(水) 11:48:22.12ID:qYDy3YV9
特にセオリーは決まってなかったと思う
わからないなら空commitでおｋかと
0142デフォルトの名無しさん2014/07/16(水) 13:12:44.48ID:dtGU31iT
initial なら 空っぽの RADME.md だけ作って commit てる
とりあえず何か commmit しとかないと diff がエラーになる
0143デフォルトの名無しさん2014/07/16(水) 13:30:32.92ID:Sd4M1rY0
リリースバージョンで1.0と2.3とかつける時のコミットログはなんて書きますか？
git commit -m "Release: 1.0"みたいな感じ？
0144デフォルトの名無しさん2014/07/16(水) 13:45:29.77ID:G80bT3bq
最近はREADMEをマークダウンで書いたりするのか。
0145デフォルトの名無しさん2014/07/16(水) 13:46:33.57ID:G80bT3bq
>>143
tagつけるので、コミットメッセージは気にしない。
0146デフォルトの名無しさん2014/07/16(水) 13:47:41.27ID:YAHvhD3g
GitHub使うとそれがデフォだったりするからな
0147デフォルトの名無しさん2014/07/16(水) 14:05:10.01ID:Hxrp0ywP
GitHubだとリポジトリのリンク開いたときにトップディレクトリのREADME.mdをHTMLに変換して表示してくれるからね
トップディレクトリの一覧の下にそれを表示するんで、トップディレクトリ自体にはあまりファイルとかたくさん置かないようにしとくと更に見やすくて良い
0148デフォルトの名無しさん2014/07/16(水) 14:15:16.78ID:Hxrp0ywP
>>142
一番最初に--allow-emptyで完全空っぽのコミット作ったりすると問題ある？
0149デフォルトの名無しさん2014/07/16(水) 14:19:26.07ID:G80bT3bq
>>146
>>147
なるほろ。githubか。
0150デフォルトの名無しさん2014/07/17(木) 18:11:47.91ID:FWioQIqe
プッシュし終わった跡に間違いに気づいてコミットしなおした
git commit -m "update"
git push
git add -A
git commit --amend -m "update"
ここからプッシュした内容をけして新しいコミットのをプッシュする場合はどうしたらよいか？
0151デフォルトの名無しさん2014/07/17(木) 18:23:12.64ID: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の跡にどうするのが一番良かったのか教えて下さい
0152デフォルトの名無しさん2014/07/17(木) 18:37:46.64ID:5+M8kOpG
>>150-151
そもそも>>150をやってはいけない
pushしたコミットを--amendで直してはいけない

ただし場合によってはどうしてもやりたいときもあるので、そのときは git push -f を使う
push先のリポジトリの設定でこの操作が禁止されている場合もある

push -fをしてもいいのは、push先のリポジトリを自分しか見てないような場合とか、
自分以外の人が見てる場合にはその自分以外の人全員にpush -fする旨の許可を貰えるような場合
0153デフォルトの名無しさん2014/07/17(木) 18:40:00.40ID:FWioQIqe
なるほどそうでしたか
これからはやらないことにします
こういうときって２回目のコミットログはfixとかって書いとけばいいですかね？
0154デフォルトの名無しさん2014/07/17(木) 19:54:07.75ID:5+M8kOpG
>>153
コミットメッセージは何をfixしたとかupdateしたとかまで書いておいたほうがいいと思うけどね
0155デフォルトの名無しさん2014/07/17(木) 21:16:30.65ID:0NORU4KM
チケット駆動とGitの組み合わせで開発するときに
何かするたびにチケット切って、それにあわせたブランチをGitで切って作業する運用って
プロジェクト中盤以降なら修正とか改善の粒度も小さいからしっくりくるんだけど
プロジェクトの何もない最初のほうは、１つの大きな機能の実装に2週間とかかかって、
それのせいでブランチ閉じられずにマージコミットやコンフリクトがあふれてなんかしっくりこない。

チケット駆動してる人は最初からチケット駆動してる？
それとも落ち着くまではmasterに直接コミット突っ込んだりしてる？
0156デフォルトの名無しさん2014/07/17(木) 21:21:35.53ID:iWQxEqkT
>>153-154
--autosquash用のフォーマットの"fixup! 修正先のコミットID"、でいいよ
元々何をしたかったかは直前のコミットメッセージにあるわけだし
0157デフォルトの名無しさん2014/07/17(木) 21:36:45.43ID:OTputfOO
コミットごとにpushするのはやめたほうがいい？
0158デフォルトの名無しさん2014/07/17(木) 21:48:15.42ID:f9EwQ7K8
fixed #1223とかrefs #4643とかだな。
コメントだけではそれが安定か不安定かくらいしか見てない。
ローカルだとadhocとかno testとかもある。
0159デフォルトの名無しさん2014/07/18(金) 00:19:24.35ID:9lilrWED
個人的なリポジトリなら自分が見やすいよう好きにすればいいし
共同のリポジトリなら仲間同士でルール決めてやるほうがよい
git flowやgithub flowあたりのメジャーなやりかたを採用するのもよい
コミットごとのpushがリポジトリを見づらくしてるよう思うのなら仲間と相談してしないようにルールを決めればよい
0160デフォルトの名無しさん2014/07/18(金) 01:07:16.29ID:97CjBc8L
内容書くと、どこまで書くかという程度がそれぞれなので、文句が出る。
0161デフォルトの名無しさん2014/07/18(金) 01:23:55.70ID: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になったらメインのリポジトリにマージする。
0162デフォルトの名無しさん2014/07/18(金) 06:26:27.67ID:P4uOsCCD
>>151

>>150 をやってしまったのなら pull してコンフリクトを治して add して commit して push するのが一番良い
0163デフォルトの名無しさん2014/07/18(金) 07:43:45.67ID:NmG7h+bv
>>161
>>151 が聞いているのは
>>150 の状況にならないためにはどうすれば良いのか？ではなくて
>>150 の状況になってしまった場合どうすれば良かったのか？だから
その回答は今回の場合は適切じゃない

あ
でも
>>150 へのレスだからいいのかな
0164デフォルトの名無しさん2014/07/18(金) 08:06:52.12ID:Vkkmxlwy
上書きしないですぐに修正コミット追加するかrevertしてじっくり修正
誰もrevert使ってないのは縛りプレイなの？
0165デフォルトの名無しさん2014/07/18(金) 09:10:39.82ID:fn9HMHhn
>>164
通常のコミットと、マージコミットと二つあるんだよね。

* A機能のコミット
* B機能のコミット
* A機能の小さなバグ修正
* C機能のコミット
* B機能のrevert
* A機能の小さなバグ修正
* B機能の再コミット

とかいう、通常のコミットだけの履歴を作りたいのかと。
こういうのは、機能毎にマージコミットであるべき。
0166デフォルトの名無しさん2014/07/18(金) 19:58:00.50ID:kcaMBvas
SGitってアンドロイドアプリ使ってみたことある人いる？便利なのかな
0167デフォルトの名無しさん2014/07/18(金) 20:58:14.38ID:wFp38Dl6
2.0.2
0168デフォルトの名無しさん2014/07/20(日) 12:13:18.06ID:6LE+xCsK
コミットてどのタイミングでやるべきか教えてください
例えば設定ファイルで設定を書いたらそこで1コミット
0169デフォルトの名無しさん2014/07/20(日) 18:25:37.05ID:k6VJN0Us
はい
0170デフォルトの名無しさん2014/07/20(日) 18:45:06.24ID:OS5ZzYFf
>>168
そんなのローカルルール。
特に分散型は同一プロジェクト内でも、リポジトリごとに違うことも。
0171デフォルトの名無しさん2014/07/20(日) 18:47:28.99ID:llZw+pKm
>>168
後でいくらでも直せるんだから
ローカルでコミットするタイミングは
バックアップとっておきたいと思ったタイミングだな。

一箇所修正したらコミットとかやるときもある。
コンパイルできなくてもやるときもある。

そのあとpushする前に意味がある単位でコミットを作り直すな。
意味がある単位とは言い換えると、コミット一個だけ取り消したいと思う単位とか
誰かにコードを説明する時に「まず○○に関する修正ですが・・・」の単位とか。

意味が無いことはしない。意味があることをする。と考えれば
コミットに分けておくと、何かあった時に便利だなってことに
コミットすればいいんだよ。
0172デフォルトの名無しさん2014/07/20(日) 20:52:14.88ID:zKSe34gp
1〜3回目のコミットをまとめる方法をおしえて
いま10回目のコミットまでしてある
0173デフォルトの名無しさん2014/07/20(日) 22:04:48.48ID:zKSe34gp
mkdir a
touch t.txt
git init
git add -A
git commit -m "ic"
mkdir b
git checkout -f←bディレクトリが残ったままとなる。なぜですか？
0174デフォルトの名無しさん2014/07/20(日) 23:31:18.41ID:667cWtBA
checkout は、リポジトリに登録している物に対して作用する
b は、リポジトリの管理外だから無視する
0175デフォルトの名無しさん2014/07/20(日) 23:36:41.49ID:tRUHKzxS
ってことはいちいちrm -rf * *.*ってやらないとだめそうですね
めんどくせえ
0176デフォルトの名無しさん2014/07/20(日) 23:37:11.83ID:PtZju0so
何のために？
0177デフォルトの名無しさん2014/07/20(日) 23:53:43.91ID:Veyq7Blc
いちからか？
0178デフォルトの名無しさん2014/07/20(日) 23:54:29.30ID:tRUHKzxS
ファイルとかディレクトリを作った後にやりなおしたいんですよ
0179デフォルトの名無しさん2014/07/21(月) 00:21:33.87ID:jb5Wh/p0
追跡されてないファイルやディレクトリを消すコマンドがあるかもね！？
0180デフォルトの名無しさん2014/07/21(月) 00:40:34.84ID:bGaWqmfa
そ、その、、コマンドをどうかおしえてください・・・ガクッ
0181デフォルトの名無しさん2014/07/21(月) 02:42:51.85ID:Udsw+XFD
git clean
0182デフォルトの名無しさん2014/07/21(月) 04:21:43.81ID:DpfIQ25M
ファイルが無い空のディレクトリをpushしたいのですが
addしてもcommitしてもpush出来ません＞＜
0183デフォルトの名無しさん2014/07/21(月) 05:28:30.74ID:75s/cUSB
>>182
.gitkeep
0184デフォルトの名無しさん2014/07/21(月) 09:50:04.00ID:W2ckSfZN
ダミーファイルを置いておくという古典的方法じゃダメなん
0185デフォルトの名無しさん2014/07/21(月) 12:48:57.77ID:mYM6Tgvw
.gitkeep って要するにダミーファイルだよな
0186デフォルトの名無しさん2014/07/21(月) 13:39:37.03ID:jb5Wh/p0
今のところGit公式には.gitkeepを特別扱いするようなコードは無くてただのダミーファイルだよね？
ぶっちゃけ空の.gitignoreの方が悪影響は少ないと思うんだけど
名前が良くないってことなんだろうなあ
0187デフォルトの名無しさん2014/07/21(月) 13:47:36.43ID:By4oX885
というか.gitignoreには「役割がある」からダメなんだと思う
「空のフォルダだけど必要なんです」と言うニュアンスを伝えるにはちょっと
0188デフォルトの名無しさん2014/07/21(月) 13:54:08.75ID:Emref6q+
いくら「ローカルルールで違う」って言っても
さすがに「コミットメッセージの2行目は空行」を守ってないところはイメージできない
0189デフォルトの名無しさん2014/07/21(月) 14:16:55.97ID:VU7LZ8It
ちゃんげログでもおいておけばいいじゃん
0190デフォルトの名無しさん2014/07/21(月) 15:59:18.02ID:l1b5gSje
gitkeepの悪影響とは
0191デフォルトの名無しさん2014/07/21(月) 16:05:11.66ID:FbNmBe/D
SCM変わったときに「Gitじゃないんだけどなー」と悶々とする。
CVSの頃は .keepme って名前のファイルがよくあったけど、
Svn文化を経由するときに失伝したらしい
0192デフォルトの名無しさん2014/07/21(月) 16:06:20.21ID:kkLNQHqq
空のディレクトリが必要って状況が想像できない
0193デフォルトの名無しさん2014/07/21(月) 16:20:40.07ID:FbNmBe/D
入門書とかにハッキリとは書かれてないので
運用してる人は少ないが、公開リポジトリの統合ブランチであっても
「このブランチはrebaseされることあるから、この上で作業すんなよ」
って予め宣言した使い捨てブランチを用意しとけば
そのブランチはpush -fしても全然問題ない。

新しいtopicはまず使い捨てブランチへマージし、
masterは定期的に使い捨てブランチにマージされて
しばらく生き残っているマージコミットまでffすればOK

こうしとけばmasterより先の使い捨て部分はいつでもやり直せる。
revertでもいいんだがゴミがたまるのが辛いし、
失敗してもやり直せる安心感にはかなわない感じ。
0194デフォルトの名無しさん2014/07/21(月) 16:23:02.25ID:nldUh4DS
>>192
その理屈だと、ディレクトリの中を空にしたら
自動的にディレクトリが消えたほうがいいってことになるよ。
0195デフォルトの名無しさん2014/07/21(月) 16:25:00.39ID:nldUh4DS
>>193
rebaseしてはいけないのは、”共有の"ブランチであって、
共有してないものはrebaseしてかまわないんだよね。

gitに限らないけどさ、○○したらだめという意見を見て
意味が分からないがとりあえず禁止だ。一切禁止だ。
みたいに考える人多いよ。

そんなのケースバイケースだろうと。
0196デフォルトの名無しさん2014/07/21(月) 16:32:44.93ID:VU7LZ8It
いやいや自分のやり方以外は認められず否定しかできないのがお前らgitterという生き物
0197デフォルトの名無しさん2014/07/21(月) 16:54:37.93ID:PFpi7FDC
>>195-196は同じことを違う側面から見ているのだと思う。
多分、微妙に知識がついて「○○したらダメ」「デフォルトの○○は有害でしかない」というような意見を見て信じこむから否定しかできなくなるんだよね。
で、そういうメリットデメリットを考えられない人がブログとかで同じことを強く喧伝するので広まっていくんじゃないのかな

自分も大抵のことはケースバイケースだと思うわ。
0198デフォルトの名無しさん2014/07/21(月) 16:55:57.76ID:jb5Wh/p0
公開リポジトリ上のブランチのリベースは、回りに周知できてるならいいんじゃないか？
自分用のブランチだからcloneして参照すんなとか、
cloneして見ててもいいけどpullは失敗するかもしんないからそんときは自分でなんとかしろとか

ただ、周知できてないと、まえにこのスレにも沸いたキチガイみたいに
ただpullしてるだけなのにリポジトリ壊れたーとか言い出す奴がでる
0199デフォルトの名無しさん2014/07/21(月) 17:16:50.55ID:dhFOCTWb
linuxのiptablesの設定ファイルとかをgithubで公開したいんですけどどんなやり方がありますか？
0200デフォルトの名無しさん2014/07/21(月) 17:22:44.80ID:FbNmBe/D
みなさん、ブログの記事かじっただけの
「だれかがかんがえたさいきょうのワークフロー」
信者を相手に苦労してそうだなｗ
0201デフォルトの名無しさん2014/07/21(月) 17:28:50.82ID:jb5Wh/p0
>>193はあんたの考えたサイキョウのワークフローじゃないのかよｗ
02021992014/07/21(月) 17:37:02.31ID:mynP+LTE
俺の質問に誰か！
0203デフォルトの名無しさん2014/07/21(月) 17:37:51.41ID:mYM6Tgvw
>>194
そういうOSが有ってもいいとふとおもった
0204デフォルトの名無しさん2014/07/21(月) 18:02:50.97ID:W2ckSfZN
その理屈だと初期ファイルをパラメータに渡さないとディレクトリを作れないってことになるよ
ついでにディレクトリと初期ファイルの権限設定も一緒に渡せると素晴らしいね
0205デフォルトの名無しさん2014/07/21(月) 18:18:51.76ID:kkLNQHqq
gitで空ディレクトリを管理したいって話の流れで
何で一般的なファイルシステムでの話になってんだよ
0206デフォルトの名無しさん2014/07/21(月) 18:29:09.64ID:nldUh4DS
>>205
ソースコードをチェックアウトすると、
ファイルシステムにディレクトリができるから。

結局のところ、空ディレクトリをgitで管理したい事の本質は
clone・checkoutした時に空ディレクトリを作りたいかって
ことになるんだよ。
0207デフォルトの名無しさん2014/07/21(月) 19:00:28.92ID:FbNmBe/D
>>199
単一のファイルを公開したいだけならGistに貼るのがお手軽でいいんじゃね？
0208デフォルトの名無しさん2014/07/21(月) 20:46:28.55ID:By4oX885
>>192
プロジェクトのディレクトリ構造を予め決めたい場合とか無いの？
0209デフォルトの名無しさん2014/07/21(月) 22:18:25.16ID:75s/cUSB
>>188
何そのルール。コミットメッセージは1行しか書いたことない。
0210デフォルトの名無しさん2014/07/21(月) 22:18:48.89ID:GJtkXJR5
でも、そのディレクトリ構造すらバージョン管理するケースを考えれば、プロジェクトのディレクトリ構造は生成スクリプトにしておくべきなのかもな
0211デフォルトの名無しさん2014/07/21(月) 22:51:42.93ID:Udsw+XFD
>>209
http://keijinsonyaban.blogspot.jp/2011/01/git.html?m=1
これによると段落が続く場合は空行が必須っぽい
0212デフォルトの名無しさん2014/07/21(月) 22:52:10.89ID:gNmDhqbD
>>210
> そのディレクトリ構造すらバージョン管理するケースを考えれば
subversionでは普通に出来たから、そこから移行してきた所が「同じこと出来ないの？」と思うのは分かる。
(出来たというか、タグやブランチもディレクトリ構造の履歴記録の応用として実現してるぐらいなんで>SVN)
0213デフォルトの名無しさん2014/07/21(月) 23:20:16.59ID:VU7LZ8It
ただpullしてるだけなのにconflict起こすからなんらかの介入が必要になるのがgitとかいう糞vps
0214デフォルトの名無しさん2014/07/21(月) 23:26:47.51ID:CUNvmPzK
今までの仕事で見たコミットログ
インターンで毎回こういうコミットログを送る奴がいた

お世話になります。インターンの△△です。
作業開始時刻 ○○：△△
作業終了時刻 ○○：△△
作業時間 ○○時間△分
作業内容
〜ここに50行ぐらい〜

次に作業する内容
〜ここに10行ぐらい〜

その他メンバーに報告したい事：
〜ここに10行ぐらい〜
0215デフォルトの名無しさん2014/07/21(月) 23:30:01.63ID:75s/cUSB
>>211
メールにするようなローカルの場合じゃないか。
0216デフォルトの名無しさん2014/07/21(月) 23:43:14.00ID:Udsw+XFD
>>215
> 変更に対する短い（50文字以下の）要約
>
> もし必要なら、より詳しい説明を述べる。
> 約72文字ほどで折り返すようにせよ。
>ある文脈では、最初の行はE-Mailの件名になり、残りのテキストが本文になる。
> 空行で本文と要約を分離するのは絶対に必要だ（本文を省略していない限り）。
> もしも二つを繋げてしまうと、rebaseのようなツールが混乱する可能性がある。

とあるからgitの仕様として空行は必要なんじゃない？
あ、でも要約を抜き出すときは空行があれば便利ってだけのことなのか
0217デフォルトの名無しさん2014/07/21(月) 23:54:33.85ID:75s/cUSB
>>216
その前提がローカルって言っている。
0218デフォルトの名無しさん2014/07/21(月) 23:55:00.47ID:NsSxsujv
rewrite aaa.txt (98%)

commitしたときに98%って表示されたんですけどこれ何？
0219デフォルトの名無しさん2014/07/22(火) 00:18:41.70ID:oEdY4w5f
>>217
gitのコマンドラインの内蔵ツールの一部が前提としている条件なんだから、「ローカルルール」は言い過ぎなんじゃないの？
守らなくても動作しなくなるわけではないという意味では必須ではないだろうけど。
言葉の定義の問題になっちゃうけど、公式推奨ルール的なものはローカルルールとは言わないと思うけどね、普通は。
0220デフォルトの名無しさん2014/07/22(火) 04:14:16.08ID:VGbmS+Eh
>>219
その内蔵のロジックを使ってる人にしか意味がないルール。
実装だ、というのであれば上記のように使わないという選択肢があるが、ルールは守るべきものでしょう。
単なるツールなのだから、ルールなんて無い気もするし。

単にそうなるというなら実装。
必要な場所では守るべきものなら、ローカルルール。
そういう場合もあるから、こうする癖をつけておいた方がいいというなら、ノウハウ、プラクティス。
0221デフォルトの名無しさん2014/07/22(火) 04:57:47.89ID:m2X37Pt+
ローカル言いたいだけだろ
反抗期みたいなもんだから、スルーしときなよ
0222デフォルトの名無しさん2014/07/22(火) 09:35:51.95ID:VGbmS+Eh
了解
0223デフォルトの名無しさん2014/07/22(火) 14:01:00.00ID:9vLp8hBC
>>218
DNA鑑定の結果
0224デフォルトの名無しさん2014/07/22(火) 18:10:41.04ID:DgetY8L8
コミットログをどうやって書いてるのか参考にしたいので
誰かおすすめのリポジトリおしえて
0225デフォルトの名無しさん2014/07/22(火) 18:11:31.13ID:DgetY8L8
コミットが2000ぐらいあるリポジトリをクローンしたいんだけどさ
全部クローンするのは時間かかるので最初の1から50までのコミットだけ取る場合のやり方をおしえて
0226デフォルトの名無しさん2014/07/22(火) 18:34:12.18ID:9vLp8hBC
>>224
git
0227デフォルトの名無しさん2014/07/22(火) 18:34:36.00ID:rhcifys/
＞最初の1から50まで
「最新50コミット」って意味なら、きっちり需要を満たしているかはわからないけど
git clone --depth=50 repos
ちなみに今テストしたらreposがローカルにある場合は「file://path/to/repos」としないと全部コピーしちゃうので注意
0228デフォルトの名無しさん2014/07/22(火) 19:09:09.68ID:W07N6TR2
ちがうよ最初の方の1から50
git init して一番初めの1から50まで
0229デフォルトの名無しさん2014/07/22(火) 21:32:24.88ID:XzkIJVA+
Gitの場合、最初のコミットが1つじゃない可能性があるから
最初のコミットから50までっていう指定は無理なんじゃないか？
0230デフォルトの名無しさん2014/07/22(火) 21:36:56.63ID:K/PzrTBo
最初のコミットだけじゃなくて、3つめまではどれかって話だよな。

A
│＼
↓　↓
o　　o
↓　↓
o　　o
↓　↓
C　　B
0231デフォルトの名無しさん2014/07/22(火) 21:41:51.82ID:IAzhYGe7
おそらくすべてのコミットの時系列的に50個目ってことっしょ
SVN的な
0232デフォルトの名無しさん2014/07/22(火) 22:50:30.79ID:VGbmS+Eh
おそらく何にも考えてないだけっしょ
0233デフォルトの名無しさん2014/07/22(火) 23:07:48.53ID:XzkIJVA+
ああたしかに、最初がひとつでも、HEADがひとつに定まらん可能性があるのな
HEADが複数な場合、そのそれぞれに対応したブランチ名が無いし、困ってしまうね
0234デフォルトの名無しさん2014/07/23(水) 08:17:37.76ID:VxAus1Vh
HEADがひとつだとして、最初から50番目のコミットIDがわかれば、git fetchでいけるかと思ったけどうまくいかないね
hgだとclone -r コミットIDで途中までcloneできるんだけど
0235デフォルトの名無しさん2014/07/23(水) 11:50:34.68ID: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

こんな感じでいいでしょうか？
0236デフォルトの名無しさん2014/07/23(水) 11:59:10.93ID:rdKtmwhJ
コミットは日本語使わない方が安全
0237デフォルトの名無しさん2014/07/23(水) 12:37:02.01ID:GD00E4+x
>>235
だめです。

gitはバージョン管理です。
作業履歴を残すツールではありません。
バージョンなので機能に変更があった時がコミットになります。

メソッドの中身が無いものを作った所で機能（バージョン）
は何も変わってないのでコミットとしてとっておく必要がありません。

ただし、自分のローカルリポジトリや、
他人に作業内容をレビューしてもらうのが目的のブランチなら別です。
gitを作業履歴として使っているので、修正を説明したい単位でコミット取るのはありです。

だけどこれはメインブランチにマージされる時に一つ、
または機能の単位毎にまとめられます。
02382352014/07/23(水) 12:49:27.98ID:7Q0hA37B
おらがいなかもんだおもってうそこぐな>>237
0239デフォルトの名無しさん2014/07/23(水) 13:19:16.16ID:iSdQDUGU
>>228
ぶっちゃけそんなもんを必要とする場面が想像できなくて、ただの煽りとしか思えないが、
とりあえず思いつくやり方は
一旦cloneする→cloneしたやつでgit resetする→さらにそこからcloneする
とかかな？
0240デフォルトの名無しさん2014/07/23(水) 13:26:25.75ID:WJZjj5QG
それじゃだめです巨大リポジトリからダウンロードすると通信料かかるのです
0241デフォルトの名無しさん2014/07/23(水) 13:56:00.92ID:iSdQDUGU
モバイルで全部事足りるからって固定回線全部捨てたお前が悪い
0242デフォルトの名無しさん2014/07/23(水) 14:03:19.99ID:xMQ/Q89h
subversion で旧バージョンをもとにフォークしたときは普通にgit svn clone できたけど
元がgit だと全部持ってきたほうがよさそうね
0243デフォルトの名無しさん2014/07/24(木) 14:59:58.63ID:+FhslZO7
Git 2.0.3 リリース
https://github.com/git/git/releases/tag/v2.0.3
0244デフォルトの名無しさん2014/07/24(木) 15:37:36.88ID:r6QGED5m
ブランチを切り替えて作業した内容をmasterブランチにマージする場合の定石コマンドを教えて
0245デフォルトの名無しさん2014/07/24(木) 15:46:46.70ID:2xZpDB05
github で自分のブランチから master->branch の pull request を作る
0246デフォルトの名無しさん2014/07/24(木) 16:59:10.13ID:EZX0DS/3
自分の作業用ブランチならrebaseしてpushしてもいいの?
0247デフォルトの名無しさん2014/07/24(木) 17:17:53.40ID:RXCuruZL
その質問には答えられません
0248デフォルトの名無しさん2014/07/24(木) 18:38:47.92ID:2xZpDB05
自己責任で済まないからな
0249デフォルトの名無しさん2014/07/24(木) 18:43:04.61ID:4y3AwbX8
>>246
運用上、そのブランチをベースにして誰かがコミットを重ねてなきゃいいよ
0250デフォルトの名無しさん2014/07/24(木) 19:12:11.39ID:eQap2LAf
>>246
キチガイがpullする可能性があるかどうかも気にしておけ！
0251デフォルトの名無しさん2014/07/24(木) 20:44:52.79ID:EZX0DS/3
バックアップ的にpushしときたいんだよね
この時点で間違ってるのかな
0252デフォルトの名無しさん2014/07/24(木) 20:58:24.83ID:HrSZ7LES
そのためのブランチ
0253デフォルトの名無しさん2014/07/24(木) 21:04:30.41ID:eQap2LAf
まあ、外部にpushしとくと少し安心感が増すよね
rebaseすること前提の個人ブランチ名の運用ルールでも決めときゃいいんじゃない？
0254デフォルトの名無しさん2014/07/24(木) 21:26:52.08ID:f4kjQ3wJ
>>250
別にpullされても、その人のlogがおかしくなるだけだろ？
エラーが出るわけでもない、ただFFできないからマージコミットになるだけ。
そういうブランチがあったとしても、誰も困らない。
0255デフォルトの名無しさん2014/07/24(木) 21:34:03.12ID:f4kjQ3wJ
>>253
決める必要あるの？

だって共有じゃないものは、自分を含めた誰かの個人のブランチでしょ？
自分のブランチは自分で管理すればいいし、他人のブランチは無関係。
共有リポジトリに沢山ブランチができて邪魔なぐらいでrebaseするかどうかはどうでもよくない？

共有ブランチをrebaseするなっていうのは、
みんながそのブランチをベースにして開発するからなわけで、
共有じゃないものはどうだっていいと思うけどな。

もっともうちではgitlabつかって、個人リポジトリにforkして
リポジトリ間でMerge Request（githubでいうPull Request）を
送ってるけどね。共有リポジトリは共有ブランチだけになるし、
そのほうがフローが綺麗なんだよ。
0256デフォルトの名無しさん2014/07/24(木) 21:34:07.17ID:pB/6WHYI
masterにマージしてpushしちゃうかもしれないのがキチガイのキチガイたる所以
0257デフォルトの名無しさん2014/07/24(木) 21:35:16.51ID:eQap2LAf
>>254
修正前と修正後をマージすることになるから、場合によってはコンフリクトするよね？
0258デフォルトの名無しさん2014/07/24(木) 21:39:07.36ID:eQap2LAf
コンフリクトするならマシかな？
修正前と後が両方残るような変な感じにマージされちゃわない？
0259デフォルトの名無しさん2014/07/24(木) 21:48:24.81ID:pB/6WHYI
>>255は統合マネージャー型のワークフロー前提だから話が噛み合わない
中央集権型のワークフローの場合にどうしよう？って話
0260デフォルトの名無しさん2014/07/24(木) 21:52:46.54ID:f4kjQ3wJ
>>256
> masterにマージしてpushしちゃうかもしれないのがキチガイのキチガイたる所以

そんなにmasterへのpushをロックすればいいだけじゃね？

gitlabでそうしてるけど？
0261デフォルトの名無しさん2014/07/24(木) 21:54:30.75ID:f4kjQ3wJ
>>259
なんだよ、統合なんたらとか集中とか
自分用語言われてもわからんわｗ

gitなんだからgitらしく使え。
0262デフォルトの名無しさん2014/07/24(木) 21:56:38.90ID:pB/6WHYI
>>261
http://git-scm.com/book/ja/Git-%E3%81%A7%E3%81%AE%E5%88%86%E6%95%A3%E4%BD%9C%E6%A5%AD-%E5%88%86%E6%95%A3%E4%BD%9C%E6%A5%AD%E3%81%AE%E6%B5%81%E3%82%8C
0263デフォルトの名無しさん2014/07/24(木) 22:02:39.01ID:pB/6WHYI
あ、>>161でも噛み合ってない。
0264デフォルトの名無しさん2014/07/24(木) 23:04:41.17ID: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の両方残っちゃった！
0265デフォルトの名無しさん2014/07/24(木) 23:08:12.80ID:f4kjQ3wJ
>>264
何か問題が？

cloneした自分のブランチは自分で管理しろよ。

最新のブランチに同期したいなら、消してから取り直すだけでいい。
0266デフォルトの名無しさん2014/07/24(木) 23:15:59.98ID:eQap2LAf
>>265
>>264は自分でcloneしてるけど、当然のことながら他人がcloneしてpullした場合にも同じことがおこるんだよ？
>>254の「別にpullされても、その人のlogがおかしくなるだけだろ？ 」これが間違ってるって言ってるの
おかしくなるのはlogだけじゃなくてリポジトリそのものが整合取れてない状態になる
自分なら消して取り直せばいいが、他人は気がつかない可能性があるのがわからんのか？
0267デフォルトの名無しさん2014/07/24(木) 23:22:28.57ID:f4kjQ3wJ
え？ リポジトリはその人のローカルリポジトリでしょ？
そんなの知ったことじゃないじゃない。

前提として>>246に書いてあるように自分専用の作業ブランチの話だよ？
それを他人がどうとったからって、その人の問題じゃないか。

オリジナルの自分専用の作業ブランチは、自分で好き勝手していい。

それを他人が勝手に盗んで、その人のローカルリポジトリの
ブランチをどう書き換えようが、その他人さんが自分で責任もつことでしょ。
0268デフォルトの名無しさん2014/07/24(木) 23:27:36.97ID:eQap2LAf
>>267
ふざけるなよ
おまえ自分の書いた>>254をよく読め

＞別にpullされても、その人のlogがおかしくなるだけだろ？
＞エラーが出るわけでもない、ただFFできないからマージコミットになるだけ。
＞そういうブランチがあったとしても、誰も困らない。

pullされたら、エラーもでるし、logだけじゃなくてレポジトリそのものがおかしくなる場合もある
FFできないマージコミットになるだけなんかでは断じてない
0269デフォルトの名無しさん2014/07/24(木) 23:56:15.78ID:lcgW/ICS
masterの話は誰もしてない
0270デフォルトの名無しさん2014/07/24(木) 23:59:45.07ID:RXCuruZL
あいまいな質問する奴と
あいないな質問にエスパーして答える奴
この２種類がいる限り
0271デフォルトの名無しさん2014/07/25(金) 00:00:33.90ID:J29irW36
あと>>264も別にリポジトリはおかしくなってない
reflog見て適当なとこにresetするだけだ
0272デフォルトの名無しさん2014/07/25(金) 00:03:19.67ID:oxVV+Dk5
>>271
reflogみて適当なところにresetしなきゃならないってことを、どうやって気がつけばいいいんだ
0273デフォルトの名無しさん2014/07/25(金) 00:03:44.97ID:J29irW36
>>272
pullしたときforced update云々出るだろ
0274デフォルトの名無しさん2014/07/25(金) 00:09:45.52ID:oxVV+Dk5
>>273
すべての人がforced updateに気づいて正しく対処できるとおもってんのか？
0275デフォルトの名無しさん2014/07/25(金) 00:10:01.25ID:J29irW36
ていうか話がずれてて、他人の個人用ブランチをワーキングエリアに(カレントブランチに実際のファイルとして)展開してる馬鹿がいて
そいつが更にpullしたときにワーキングエリアが変になるってだけの話だろ？
masterか、チェックアウトされる可能性がある共有ブランチ書き換えない限りeQap2LAfの言うようなことは起きんよ
どう考えても「そんなこと知ったことではない」が正しい
0276デフォルトの名無しさん2014/07/25(金) 00:12:51.68ID:oxVV+Dk5
まずは>>254が間違ってましたってゴメンナサイするのが先だろ
そして他人から見えるブランチをrebaseする可能性がある場合には
それが明確になるよう運用しなければいけない理由がわかったか？
0277デフォルトの名無しさん2014/07/25(金) 00:13:38.00ID:0uQevWYT
>>246
結論
こういう(>>247-276)トラブルを避けるためにもやらないのが無難
やるならトラブルを引き起こすリスクを覚悟した上で自己責任で
0278デフォルトの名無しさん2014/07/25(金) 00:14:51.81ID:HVzq131/
100行あるコードをコミットしました
そして10行まで削除してコードを書きなおそうと思います
そこで最後にコミットした内容を見ながらコードを書きたいんですけど
最後のコードを表示する方法を教えてください
0279デフォルトの名無しさん2014/07/25(金) 00:15:17.80ID:J29irW36
いや変なのは明らかにeQap2LAfなんだが・・・
0280デフォルトの名無しさん2014/07/25(金) 00:18:50.16ID:oxVV+Dk5
>>279
自分がおかしくないと思うなら、>>254が間違ってたことをまずは肯定してくれないかな？
0281デフォルトの名無しさん2014/07/25(金) 00:19:44.83ID:0uQevWYT
>>278
2ペインの片方に最後のコードを表示できる賢いIDEを使いましょう
0282デフォルトの名無しさん2014/07/25(金) 00:24:31.90ID:eA/GtSQx
>>281
そんなIDEは無いよ
0283デフォルトの名無しさん2014/07/25(金) 00:25:55.65ID:0uQevWYT
じゃあ諦めましょう。
0284デフォルトの名無しさん2014/07/25(金) 00:32:09.56ID:oxVV+Dk5
俺の使ってるIntelliJ IDEAは、前回コミットした内容をウィンドウに表示しながら別のウィンドウでそのファイルを編集できるぞ

さらに、編集中のウィンドウでは前回のコミットからどの行が編集されたかマークが表示されて、
そのマークをクリックすれば編集前の行の内容がポップアップで表示される
0285デフォルトの名無しさん2014/07/25(金) 18:57:19.85ID: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にコミット追加するのが間違いだが。
0286デフォルトの名無しさん2014/07/25(金) 19:25:08.83ID:oxVV+Dk5
>>285
>>264の例をよく見てもらえばわかると思うんだけど、
B氏が単にcloneしてpullしただけで非FFのマージが発生する
そのマージはコンフリクトするか、まちがったマージになる
0287デフォルトの名無しさん2014/07/25(金) 19:43:14.81ID: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な関係だからガチのマージが動くことになる
都合よくリベース前側のコミットの差分を無視なんかしてくれないからマズイ結果になる
0288デフォルトの名無しさん2014/07/25(金) 19:59:14.18ID:J29irW36
だから>>286が間違いだっての
workブランチをワークスペースに展開してない限り何も起きねーよ
0289デフォルトの名無しさん2014/07/25(金) 20:09:14.32ID:oxVV+Dk5
>>288
repo-aのworkブランチをcloneしてpullした場合の話をしてます
>>285もそういう前提の話でおｋ？
0290デフォルトの名無しさん2014/07/25(金) 21:06:16.92ID:voM5b4Ni
>>287
> 都合よくリベース前側のコミットの差分を無視なんかしてくれないからマズイ結果になる
うんうん、
5. B氏がrepo-aのworkをpull -> repo-bのworkでマージ発生。
のことだよね？

それはworkという他人の作業ブランチをチェックアウトしている
B氏が注意して避けるべき問題であって、B氏以外の人が配慮するべき問題ではないよね。

B氏がそれを避けられないほど間抜けだっつう話だとしても、
B氏を哀れだとは思うがB氏以外の人が負担を強いられるべき問題だとは思わない。
0291デフォルトの名無しさん2014/07/25(金) 21:33:38.76ID:oxVV+Dk5
>>290
5.が起こるのに3.は必要無いってことです

整理します。俺が>>254が間違ってると言ってる話の流れはこうです

246:
自分の作業用ブランチならrebaseしてpushしてもいいの?
250: >>246
キチガイがpullする可能性があるかどうかも気にしておけ！
254: >>250
別にpullされても、その人のlogがおかしくなるだけだろ？
エラーが出るわけでもない、ただFFできないからマージコミットになるだけ。
そういうブランチがあったとしても、誰も困らない。

※その人のlogがおかしくなるだけじゃなくてコミットもおかしくなる
※エラー(コンフリクト)も出る
※マージコミットになるだけじゃないくて、コミットの内容自体がオリジナルとは異なる
※そういうブランチがあったら誰も困らないなんてことは無い。そのpullしてる人は困る

この流れでは>>254は間違ってると言い切っていいよね？
02922492014/07/25(金) 22:17:26.06ID:nlpJ8mOy
なんとなく >>291 の主張していることが理解できた気がする。

たとえば他人の作業ブランチを勝手にpullしたキチガイのブランチが先にmasterにマージされたら、
元の作業ブランチをrebaseしたブランチを後でmasterにマージしようとしたときに
コンフリクトしたり意図しない結果になるだろう。

理屈はわからんでもないが、それはrebaseに限った話ではないし、そんなキチガイに自由にさせることがおかしい。
gitなら過去のcommitをすべて破壊することだってできる。

>>254 「別にpullされても、その人のlogがおかしくなるだけだろ？」
に対しては、通常の運用では正しい。そうならない運用があるならその運用は決定的に間違ってるのでルールを作れ。
キチガイがいたら教育するか排除するかしろ。

> この流れでは>>254は間違ってると言い切っていいよね？

よくない。>>254を否定する同じ理屈で「gitは危険だから使うべきでない」とも言える。
前提がバカバカしい。
0293デフォルトの名無しさん2014/07/25(金) 22:26:51.08ID:oxVV+Dk5
>>292
いや、ちょっとまってくれよ？

「作業用ブランチならrebaseしてpushしてもいいのかどうか」については、してよいとも、してはいけないとも、俺は言ってない

＞ 246:
＞ 自分の作業用ブランチならrebaseしてpushしてもいいの?
＞ 250: >>246
＞ キチガイがpullする可能性があるかどうかも気にしておけ！
＞ 254: >>250
＞ 別にpullされても、その人のlogがおかしくなるだけだろ？
＞ エラーが出るわけでもない、ただFFできないからマージコミットになるだけ。
＞ そういうブランチがあったとしても、誰も困らない。

この250に対する254の書き込みが間違ってるかどうかだぞ？
>>291の※の指摘をよく見てくれ
おれの指摘は上記の書き込み以外の前提は全く無い
勝手に前提を仮定しないでくれ
0294デフォルトの名無しさん2014/07/25(金) 22:31:44.14ID:oxVV+Dk5
作業用ブランチならrebaseしていいのかを議論する上で、実際にどんな影響があるのかをしっかり認識しておくのが重要だと思うんだ
それなのに、>>254のように間違った認識しかできてない状態で議論を進めるのは危険だろ
だからまず>>254の認識が間違ってることをはっきりさせたいんだ

どんな影響があるかをしっかり認識した上で、
勝手にpullする人の責任だっていう意見ならそれはそれでいいと思う
0295デフォルトの名無しさん2014/07/25(金) 22:32:04.58ID:9e0PWdlB
gitスレって荒れやすいね
0296デフォルトの名無しさん2014/07/25(金) 23:06:02.09ID:CnocSSYp
こんなの荒れてるうちに入らない
荒れているっていうのはこういうことを言うのだよ黄猿君
【PHP】下らねぇ質問はID出して書き込みやがれ 135
http://kanae.2ch.net/test/read.cgi/php/1405860979/
0297デフォルトの名無しさん2014/07/25(金) 23:18:58.22ID:9e0PWdlB
俺がスレ荒れてると思えばそうなんだろう、俺ん中ではな！
0298デフォルトの名無しさん2014/07/25(金) 23:22:28.88ID:voM5b4Ni
>>291
> 5.が起こるのに3.は必要無いってことです
たしかに別に3がなくても5で不要なマージコミットできちゃうね。
でもそれってB氏の責任というのが俺の立場だなぁ。

> ※そういうブランチがあったら誰も困らないなんてことは無い。そのpullしてる人は困る
つまり、
>>254「(pullした奴以外)誰も困らねーだろ」
>>250「pullした奴が困ってるじゃねーか」
ということかな。だいぶ君の主張が理解できた気がする。(つづく)
0299デフォルトの名無しさん2014/07/25(金) 23:23:17.38ID: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
03002492014/07/25(金) 23:28:10.04ID:nlpJ8mOy
>>293-294
お前さんの言いたいことはよくわかった。

結論: >>250 から先は意味のない議論だ。どうでもいい

キチガイが勝手に俺のブランチをpullしてrebaseしてmasterにマージしたらかなわんね。
すべてを破壊するキチガイの存在を肯定した議論など何の役にも立たない。
0301デフォルトの名無しさん2014/07/25(金) 23:31:00.30ID:oKdTZN9u
> キチガイが勝手に俺のブランチをpullしてrebaseしてmasterにマージしたらかなわんね。

手元にはあるのだから、pushしなおせば？

キチガイを持ち出すなら、キチガイが会社中のパソコンを
壊しまわることもあるので、それはキチガイをどうにかすればいいという話で
もはやgit関係ない。何を使おうが壊そうと思えば壊せる。
0302デフォルトの名無しさん2014/07/25(金) 23:34:04.18ID:oxVV+Dk5
>>299
何度も言いますが、誰が気をつけるべきかという問題と、>>254が間違ってるかどうかは、関係ありません

誰が気をつけるべきかどうかという問題を議論する前に、
>>254が間違っているかどうかをはっきりさせておきたいのです

どういう影響があるかをはっきりさせないと、誰が「何を」気をつけるべきかという点が曖昧になってしまいます

そういうわけで、>>254が間違っているかどうかを答えて頂けませんか？
03032492014/07/25(金) 23:34:35.23ID:nlpJ8mOy
そう。>>250 から先はgit関係なくてほとんど意味がない。

「gitを使ってどういう嫌がらせができるか」という話にしかならない
0304デフォルトの名無しさん2014/07/25(金) 23:36:29.29ID:voM5b4Ni
>>300 >>291
pullしてmerge発生したのに気づかず上流のmasterにpushしちゃうってことを危惧してたの？
だとしたらそんなことするアホにpush権限与えてしまった上流リポジトリのオーナーが間抜けって話だね。
0305デフォルトの名無しさん2014/07/25(金) 23:36:32.91ID:oxVV+Dk5
>>300
実際にpullされたときにどういう現象が起こるかどうかをはっきりさせておくのは重要だと思いませんか？
それをはっきりさせることでどこまで許容できるかという話が可能になります
0306デフォルトの名無しさん2014/07/25(金) 23:40:56.18ID:oxVV+Dk5
>>304
>>161あたりがこの話題の元になってると思うんですよ

気になるのはここですね
＞そしてこの状態で思う存分レビューしてもらってNGなら直して--amendして
＞pushしてOKになったらメインのリポジトリにマージする。

レビューしてるひとに迷惑かかりますよね？rebaseしてるからレビューするひとは毎回ブランチ作り直しです
0307デフォルトの名無しさん2014/07/25(金) 23:45:53.97ID:voM5b4Ni
>>302
> そういうわけで、>>254が間違っているかどうかを答えて頂けませんか？

うーん、俺の理解は↓のとおりだよ。
>>254「(pullした奴以外)誰も困らねーだろ」
>>250「pullした奴が困ってるじゃねーか」

254の発言を字面通りに解釈するなら君の言うとおりpullしたやつが困ってる、という意味で「誰も」は正確ではないと主張は可能だね。

だけど、254は(俺もだけど)暗黙的にpullした奴が困ってるのはそいつの責任だからしったこっちゃねーよ
(しかも避ける方法・回復する方法などいくらでもあるから本当には困ってねーだろ)
という意味で「誰も困らない」と言っているのだと思うけど？

だから、単純に字面を額面通りに捉えて >>254 が間違っているという主張には賛同できないな。
どうだろう？
03082492014/07/25(金) 23:51:17.91ID:nlpJ8mOy
>>304
「気づかず」ではなくて >>291 が主張しているのは半ば意図的に
他人の「作業」ブランチをベースとしたブランチを作った上でそれを操作してmasterに
マージする(など各種ブランチ操作)が技術的に可能、という話だと思う。
元のブランチがそれを意図していないなら嫌がらせの類だと感じる。
masterにマージするのはそいつでも他の誰かでもいい。

> そんなことするアホにpush権限与えてしまった上流リポジトリのオーナーが間抜けって話だね。

そういう話にしかならないから不毛
0309デフォルトの名無しさん2014/07/25(金) 23:51:38.74ID:oxVV+Dk5
>>307
なぜあなたは>>254の最後の「誰も困らねーだろ」が「(pullした奴以外)誰も困らねーだろ」であることを知っているのでしょうか？
私は文面どおり「 (pullされた奴もpullした奴も)誰も困らねーだろ」の意味にとりました
なぜなら1行目と2行目でpullした奴に実質的に影響が無いということを述べているからです

あなたは>>254かエスパーなのでしょうか？
0310デフォルトの名無しさん2014/07/25(金) 23:54:12.80ID:voM5b4Ni
>>306
> レビューしてるひとに迷惑かかりますよね？rebaseしてるからレビューするひとは毎回ブランチ作り直しです
それでいいのでは。

レビューで出される指摘事項に依存すると思うけど、
「あっちのコミットとこっちのコミットは一つのコミットにするべきだから、fixupして」
あるいは
「このコミットは2種類の変更が混じってるから分割して」
とかの指摘だった場合、rebase以外で対応するのは原理的に無理だよ?
0311デフォルトの名無しさん2014/07/25(金) 23:57:06.19ID:oxVV+Dk5
>>307
とりあえずあなたは、>>254の3行目に関しては文面どおり捕らえれば間違っているが、
「(pullした奴以外)誰も困らねーだろ」と解釈できるから間違っていないという意見ということでいいですか？

>>254の1行目と2行目はどう解釈しようも無く間違っているということでいいですか？
03122492014/07/25(金) 23:59:51.07ID:nlpJ8mOy
>>307

> >>254「(pullした奴以外)誰も困らねーだろ」
> >>250「pullした奴が困ってるじゃねーか」

そうではなくて、 >>302 や >>309 が主張しているのは
「pullした奴が、(オリジナルブランチのAuthorなど)他のメンバーを困らせることが可能」ということだと思う。

でもオリジナルのブランチの作者がrebaseするとかしないとかもう全然関係ないのがね。
意図的に人を困らせる操作なんかいくらでもあるので
0313デフォルトの名無しさん2014/07/26(土) 00:00:00.83ID:p4ua17EP
>>309
まず、おれは >>254 じゃないよ

俺の中では >>299 で書いたようなことが暗黙的な前提になってるから、
>>254 のような発言を見た時に
「(pullした奴以外)誰も困らねーだろ」
と解釈したなぁ。

普段も上流をそのまま追いかけたいブランチをチェックアウトしてる場合、
上流からfetchする際は上流のrebaseが無かったか、mergeする前にfast-forwardになるか
必ずチェックするし。
0314デフォルトの名無しさん2014/07/26(土) 00:01:49.35ID:JET6jTHt
>>310
常に問題無いというわけでは無いですよね
レビューする人も人間ですからミスしてpullしちゃう可能性があります
なのでレビューのやりとりでrebaseするかどうかをはっきり表明しておく必要があると思います
0315デフォルトの名無しさん2014/07/26(土) 00:08:57.84ID:JET6jTHt
>>313
なるほど。たぶんあなたは>>254の1〜2行目の問題に>>298で初めて気がついたからそういう解釈になってしまったのですね
03162492014/07/26(土) 00:11:27.38ID:7f7nHnx7
>>>307
>なぜあなたは>>254の最後の「誰も困らねーだろ」が「(pullした奴以外)誰も困らねーだろ」であることを知っているのでしょうか？
>私は文面どおり「 (pullされた奴もpullした奴も)誰も困らねーだろ」の意味にとりました

ただの日本語が不自由な人じゃないか・・・
一生懸命考えて損した。


この板もID出るようになってるのか。いいことだ。
0317デフォルトの名無しさん2014/07/26(土) 00:12:26.21ID:JET6jTHt
>>313
本来こういう迷惑をかけないために公開リポジトリはrebaseしないというルールがあるのですけどね
＞普段も上流をそのまま追いかけたいブランチをチェックアウトしてる場合、
＞上流からfetchする際は上流のrebaseが無かったか、mergeする前にfast-forwardになるか
＞必ずチェックするし。
チェックする必要があるというのは修羅の国ですね
03182492014/07/26(土) 00:17:47.11ID:7f7nHnx7
>>317

ヒント
> 246 ：デフォルトの名無しさん：2014/07/24(木) 16:59:10.13 ID:EZX0DS/3
> 自分の作業用ブランチならrebaseしてpushしてもいいの
0319デフォルトの名無しさん2014/07/26(土) 00:19:37.53ID:p4ua17EP
>>314
レビューしてもらう側からrebaseしたよ、と言うのは親切かもしれないけど、
レビューする側(とくにmergeする責任を負う奴)は master..topic にどういうコミットが
表示されるかぐらいはチェックするよ。つーかそれがレビューという作業だと思うけど？

topicを送ってきた相手によっては、
「そいつの仕事を完全に信頼してるので言われたとおりmergeする」
ってのもあるかもしれないよ。
でもそれによって送ってきた奴のミスが伝搬してしまうのはしょうがないよな。
そんなこと言い始めたらいくらでも変な状況は想定できるわけだし。
0320デフォルトの名無しさん2014/07/26(土) 00:19:47.98ID:JET6jTHt
>>316
1行目と2行目でpullする人には実質的な影響無いよ！ってことを述べているのに、
3行目が突然(pullする人以外)誰も困らないよ！って意味になってるとしたらおかしいですよね？
普通に考えれば(pullする人は)誰も困らないよ！って意味になると思います。

＞別にpullされても、その人のlogがおかしくなるだけだろ？
＞エラーが出るわけでもない、ただFFできないからマージコミットになるだけ。
＞そういうブランチがあったとしても、誰も困らない。
0321デフォルトの名無しさん2014/07/26(土) 00:22:24.95ID:p4ua17EP
>>315
>>254
> 別にpullされても、その人のlogがおかしくなるだけだろ？
> エラーが出るわけでもない、ただFFできないからマージコミットになるだけ。
ここかい？
間違いがあるとしたら、
「エラーが出るわけでもない」→コンフリクトすることもあるね
くらいかな。
他にどんな間違いが？
0322デフォルトの名無しさん2014/07/26(土) 00:24:55.79ID:p4ua17EP
>>320
おおぅ、そういう解釈してるの？
> ＞別にpullされても、その人のlogがおかしくなるだけだろ？
ここの「その人」はpullした人だよ。明確にpullした人に(表面上)困ることが示されてる。
0323デフォルトの名無しさん2014/07/26(土) 00:26:11.79ID:p4ua17EP
>>322
> ここの「その人」はpullした人だよ。明確にpullした人に(表面上)困ることが示されてる。
いかん、俺の日本語が不自由になってきた
(誤) pullした人に(表面上)困ること
(正) pullした人に(表面上)困ったことがおきること
です。
0324デフォルトの名無しさん2014/07/26(土) 00:28:41.04ID:JET6jTHt
>>321
「logがおかしくなるだけ」では無いですね？コミットの内容もおかしくなります
「ただFFできないからマージコミットになるだけ」では無いですね？
不正なマージコミットになることを「ただFFできないからマージコミットになるだけ」と表現するのは無茶だと思います
0325デフォルトの名無しさん2014/07/26(土) 00:31:07.31ID:p4ua17EP
>>324
> >>321
> 「logがおかしくなるだけ」では無いですね？コミットの内容もおかしくなります
> 「ただFFできないからマージコミットになるだけ」では無いですね？
> 不正なマージコミットになることを「ただFFできないからマージコミットになるだけ」と表現するのは無茶だと思います
ごもっとも。
だがその状態はpullしたやつの手元のワーキングツリーで起こってるだけでしょ？
0326デフォルトの名無しさん2014/07/26(土) 00:33:37.83ID:JET6jTHt
>>322-323
>>254の1〜2行目からはコミットの内容までがおかしくなると考えてるとは読み取れないのですが？
つまりpullerには実質的な影響は無いと考えていると思われます
0327デフォルトの名無しさん2014/07/26(土) 00:39:35.54ID:JET6jTHt
>>325
pullしたやつの手元のワーキングツリーで起こってるから、pullした奴が困るのです
0328デフォルトの名無しさん2014/07/26(土) 00:40:04.95ID:p4ua17EP
>>326
> >>254の1〜2行目からはコミットの内容までがおかしくなると考えてるとは読み取れないのですが？
> つまりpullerには実質的な影響は無いと考えていると思われます
いやいやいや、そこから共有できてないのか。

ログが違う(ログに現れるコミットが違う。たとえば余計な空のコミットが存在する)だけであっても、
Gitの性質上、それ以外、例えばブランチ先端のツリーが全く同一、差分などなど諸々が同じであったとしても、
Gitの履歴としては全くの別物になっている、というのがGitのメカニズムだし
Gitユーザの常識だと思うんだが。(よほどの初心者は違うかもしれんが)
0329デフォルトの名無しさん2014/07/26(土) 00:42:58.86ID:JET6jTHt
>>328
つまり、その状態を「ただFFできないからマージコミットになるだけ」と表現する>>254が馬鹿だったということでいいですか？
0330デフォルトの名無しさん2014/07/26(土) 00:44:08.14ID:p4ua17EP
>>327
> pullしたやつの手元のワーキングツリーで起こってるから、pullした奴が困るのです
そうだね。pullしたやつが可哀想だね。
でも本当はpullした奴も困らないでしょ？ と俺はずっと言っているわけだ。
>>299 を100回くらい読んではくれまいか。
0331デフォルトの名無しさん2014/07/26(土) 00:52:49.47ID:p4ua17EP
パトラッシュ、疲れたろう。僕も疲れたんだ。なんだか、とても眠いんだ。
0332デフォルトの名無しさん2014/07/26(土) 00:55:04.24ID:JET6jTHt
>>330
>>299は良いことが書いてあると思いますよ
pull --ff-onlyするようにとか簡単でいいですね
ただ、なぜそういうことをする必要があるかということを>>254を見て誤解してしまったような人は理解できないと思うんですよ
なので、>>254の「ただFFできないからマージコミットになるだけ」とかを見た人が誤解しないように
真意をはっきりさせておく必要があると思います
0333デフォルトの名無しさん2014/07/26(土) 00:56:18.19ID:JET6jTHt
>>331
寝たら死にますよ
0334デフォルトの名無しさん2014/07/26(土) 01:05:33.08ID:3J1xCNng
>>332
ということにしたいのですね。
0335デフォルトの名無しさん2014/07/26(土) 01:17:03.50ID:7f7nHnx7
>>327
貴方は細かいところによく気づく素晴らしい力を持っていますね。
更に文脈を読み大意を掴む力をつけるとさらに価値あるエンジニアになれると思います。頑張ってくださいね。

>>254 のこの部分
> エラーが出るわけでもない、ただFFできないからマージコミットになるだけ。

は確かに正確ではないですね。間違いといっても差支えないでしょう。

ただ、>>254 は
>>250
> キチガイがpullする可能性があるかどうかも気にしておけ！

を受けてるので、大事なのは

> 別にpullされても、その人のlogがおかしくなるだけだろ？

つまり他人の作業ブランチをpullしたキチガイさんが困るだけ、ってところだと思いますよ。
そのキチガイの他には影響は及ばないからそんなもの考慮する必要はない、という主張です。きっと。
あとは枝葉だから誰も気にしなかった。しかし貴方は気づいた。素晴らしい
0336デフォルトの名無しさん2014/07/26(土) 01:19:31.48ID:JET6jTHt
>>334
はい
0337デフォルトの名無しさん2014/07/26(土) 01:20:14.56ID:JET6jTHt
>>335
あなたは素晴らしいエスパーですね！
0338デフォルトの名無しさん2014/07/26(土) 05:18:57.35ID:hlVwYF+4
とりあえず、>>320みたいな
「誰も困らないよ」という文の解釈を巡って、
「(世の中全員が)誰も困らないよ」という意味になるのが正しくて「(キチガイ以外)誰も困らないよ」という意味になるのは間違っている、とかいう主張は無意味だと思うけどな。
前者か後者か曖昧なのでどっちの意味で使ったのか説明してくれ、ということだったら意味はあると思うが、
こういう文脈依存性の高いものの場合でのそういう主張は結局「文字で書かれていない部分は俺の解釈が絶対なんだ、そうでないニュアンスで文を書く奴は馬鹿」とオレオレ基準で読解力のなさを示してるだけ。
一見客観的に文意を判断してる風に説明するからたちがわるいけどな。(そして>>320も俺の意見は客観的で絶対正しいと思ってるだろう)

読解力の無いやつほど短文で文意が厳密に決まるような表現が出来ると思ってるし、文意を厳密にするために正確に冗長に表現すると長文で読めないとか言い出すよね。
自分の言語に対する理解が完全で、他人の理解が完全でないとどうして決めつけられるのか。自分の言語が間違っているという意識はないのか。謎である
0339デフォルトの名無しさん2014/07/26(土) 07:41:09.25ID:ZVICdgrk
困る人が居る場合
困る人に原因があることをもって
自己責任ということにしておけば
楽と言えば楽
03402352014/07/26(土) 08:18:47.28ID:mdOIZXZW
それがこれまでもこれからもお前らそのものｼﾞｬﾈｰｶ
0341デフォルトの名無しさん2014/07/26(土) 12:06:27.97ID:JET6jTHt
>>338
まだやるんですか？＾＾

＞別にpullされても、その人のlogがおかしくなるだけだろ？
＞エラーが出るわけでもない、ただFFできないからマージコミットになるだけ。
＞そういうブランチがあったとしても、誰も困らない。

この3行は、最後の行だけじゃなくて全部突っ込みどころ満載なんですよ！その辺理解してください
2行目がほぼ間違ってるだろうということは>>335でも納得してもらえました
2行目が間違っているとなると、1行目のlogが何を指しているのかがよくわからなくなります
3行目の誰？が実際に誰のことなのかよくわからないというのもあなたが指摘しているとおりです
0342デフォルトの名無しさん2014/07/26(土) 12:15:29.67ID:8QVtVKLI
コミットログのuser.mailって後から一括とかで変えられる? またはpushするのだけとか。
変えた場合、同じコミットとして認識される?
0343デフォルトの名無しさん2014/07/26(土) 12:23:24.99ID:2fRRiDMt
1.無理
2.無理
0344デフォルトの名無しさん2014/07/26(土) 12:26:52.71ID:JET6jTHt
>>342
user.mailの設定を変えても、過去のコミットの中のAuthorとかは変わらないです
過去のコミットの中のAuthorとかを変更する場合には、git filter-branchとか使ってまとめてコミットを改変します
改変したコミットは改変前のコミットとは別物になります
0345デフォルトの名無しさん2014/07/26(土) 12:36:29.64ID:hlVwYF+4
>>341
2行目が間違ってたとしても、1行目の文意が示してるのは「pullしたやつが困る」と解釈できる。
なので3行目は「pullするような馬鹿はほっといて、それ以外は誰も困らない」って解釈できる。
>>322 >>335もそう言ってるじゃん。
だから、2行目が間違った内容かどうかというのとは別に、3行目の「誰も」をどう解釈するのかという問題は、1行目の意味を重視するのか2行目の間違った内容との整合性を重視するのかで変わってくる。
それでもあなたは「文全体の整合性を考えたら『誰も』はpullした奴も含む」と主張したくなるかもしれないが、
だとするならば1行目の「logがおかしくなる」という表現と3行目の「困らない」という表現は整合していないという考え方もある。

つまり、文章全体が整合性が取れていない状態。だから何らかの文脈読み取りと整合性の訂正が必要となるんだけど、その読み取りと訂正の幅があるから >>338 みたいな話をした。
文全体がおかしいことを指摘し、自分が思いつく本来の意味の可能性を列挙し、「どれ？」と聞くのが偏りのないものの見方であって、そこで勝手に解釈の幅を狭めて
「普通に考えれば」だのなんだの言って勝手に都合のいい解釈をしてるあたり、客観的でもなんでもなくて論争で勝ちたいだけなのかな？って思っちゃう。

>>276あたりから>>254は間違ってるって言ってるけど、建設的な議論をするならそもそも具体的にどこが間違ってるのかさっさと指摘するべきだし、
あなたの行動は>>294あたりでは「どんな影響があるのか実際の動作について皆理解してないぞ」と2行目についての指摘をしているようでありながら、結局は>>254が完全に間違っているみたいな方向に誘導しているわけで、一貫した整合性はないじゃん。
その辺が「一見客観的に文意を判断してる風だからたちがわるい」所以だ。
0346デフォルトの名無しさん2014/07/26(土) 12:45:46.50ID:8QVtVKLI
>>344
ありがとう。
0347デフォルトの名無しさん2014/07/26(土) 13:15:08.95ID:JET6jTHt
>>345
>>254の3行に整合性がとれていないということにも合意して頂けるのですね
>>254が(特に2行目が)間違ってることは、>>264で超具体的に指摘しています
順番にコピペして実行してもらえれば状況が完全に再現できる親切設計ですよ？
何度も言っていますが、私の目的はリベースによって>>264で示すような状況が発生することを知ってもらうことです
0348デフォルトの名無しさん2014/07/26(土) 13:25:03.01ID:4Rh4oPzG
議論のための議論はよそでどうぞ
0349デフォルトの名無しさん2014/07/26(土) 13:49:51.02ID:hlVwYF+4
>>347
それならば具体的に間違っているgitの挙動についての主張に終始すべきだよね。
「誰も」をどう解釈するのかなんていう目的外のことを「普通はこう解釈する」なんていう根拠の無い理由で主張して、>>254全体について「間違っているからごめんなさいしなきゃいけないね」と思っていると
とれる発言を繰り返したことは事実の追及からは外れた個人攻撃に近いものだと思うし、少なくとも不必要な「やりすぎ」だということについては理解してもらえるのかな？
0350デフォルトの名無しさん2014/07/26(土) 14:02:54.21ID:JET6jTHt
>>349
具体的に指摘した>>264に対する回答が>>265とか>>267ですからね
それを>>268で指摘したら当人は消えてしまうし
特にやりすぎたとは思いません
>>254の人はその発言を訂正して、矛盾してる部分の整合性を正すべきだと思いますよ
0351デフォルトの名無しさん2014/07/26(土) 14:20:28.86ID:hlVwYF+4
>>350
なるほど 整合性を正すべきだというのは理解した
では「普通はこう解釈する」という根拠では、「誰も」の解釈についての主張しても>>254の発言の整合性が一層低いんだということを客観的には納得させられないということについては認められる？
それとも「誰も」についても「文字通り全員」じゃないとダメだと思っている？
0352デフォルトの名無しさん2014/07/26(土) 14:22:54.04ID:2fRRiDMt
進化しないのがダメという人間と安定しないのがダメという人間とで意見が合うはずがない
0353デフォルトの名無しさん2014/07/26(土) 14:29:49.12ID:JET6jTHt
>>351
普通はこう解釈するを、私はこう解釈するに訂正してもいいですよ？
ただし、「誰も困らない。」を「(pullした人以外)誰も困らない。」だと解釈すべきだという意見は受け入れられないですね。
これに関してはどういう意味だったかは本人に説明してもらうしかない。
0354デフォルトの名無しさん2014/07/26(土) 14:54:32.80ID:hlVwYF+4
>>353
もちろん「ただし、『誰も困らない。』を『(pullした人以外)誰も困らない。』だと解釈すべきだ」と主張しているわけではないよ。
曖昧な部分だから立場によって解釈に幅がある、だから>>320みたいな「私はこう解釈した、そしたら全然整合性がとれなくてメチャクチャだ、だからおかしい」という主張は
わざとメチャクチャになるように(自分の立場に有利になるように）解釈しているととれるので客観性のある主張ではないと言える。
だから「そんな発言をわざわざする人は読解力がないことを自ら主張しているようなもの」と>>338で言ったわけだよ。
0355デフォルトの名無しさん2014/07/26(土) 15:11:15.70ID:JET6jTHt
>>354
>>320は曖昧な部分を私なりに解釈してみたってだけなのですが？
解釈したら整合性がとれなくなってメチャクチャだと言っているのは誰なんです？
0356デフォルトの名無しさん2014/07/26(土) 15:31:20.95ID:hlVwYF+4
>>355
「私なりに解釈した結果」「突っ込みどころ満載」なのは「私なりに解釈した結果」メチャクチャだ、と言ってるのと同じじゃない？
0357デフォルトの名無しさん2014/07/26(土) 15:39:23.70ID:JET6jTHt
>>356
解釈したら整合性がとれなくてメチャクチャになるというわけではないですよ？
正常に解釈するのが難しいぐらい曖昧でメチャクチャで突っ込みどころ満載なんです
0358デフォルトの名無しさん2014/07/26(土) 15:47:06.41ID:hlVwYF+4
>>357
「正常に解釈するのが難しい」ってのはやっぱり読解力がないってことだね。
0359デフォルトの名無しさん2014/07/26(土) 15:54:08.89ID:JET6jTHt
>>358
私に読解力が無いのはどうでもいいんですが
>>254が「正常に解釈するのが難しいぐらい曖昧でメチャクチャで突っ込みどころ満載」に関しては否定なのでしょうか？
>>254の3行の整合性が取れてないという意見は肯定してもらえたような気がするのですが？

整合性はとれてないけど、正常に解釈できない程ではないという感じですか？
0360デフォルトの名無しさん2014/07/26(土) 16:05:26.17ID:hlVwYF+4
>>359
そう、「整合性はとれてないけど、正常に解釈できない程ではない」かな。
「(pullされる想定のブランチじゃないけど)pullされたら、その人のログがおかしくなるだけ」→「(想定外のpullする奴以外)誰も困らない」
　　　　└→「(おかしくなると言っても)エラーでないしマージコミットになるだけ」
という構造になっていると解釈していて、どのようにおかしくなるかというのはまた別の話を適当に差し込んでしまったんじゃないかな（間違っている内容ではあるが)。
で、こういう解釈をすると整合性がとれていないのは2行目だけで、そこを除くと意味が通るから「正常に解釈するのが難しいぐらいに〜」というのには同意できないな
0361デフォルトの名無しさん2014/07/26(土) 16:24:38.62ID:JET6jTHt
>>360
2行目を無かったことにすれば正常に解釈できるからメチャクチャじゃないと言うわけですかｗ了解しましたｗ
素晴らしい読解力ですねｗ
0362デフォルトの名無しさん2014/07/26(土) 16:51:35.72ID:02EFznKI
そういうスレたててやれ
0363デフォルトの名無しさん2014/07/26(土) 17:56:19.94ID:hp9e8t10
グダグダうるせえなどこかに内容をまとめろや
0364デフォルトの名無しさん2014/07/26(土) 19:41:06.42ID:tno9AbkY
これが日本人流の議論なんだな
最高戦争指導会議もこんなんだったんだろうな
0365デフォルトの名無しさん2014/07/26(土) 20:00:28.24ID:AxEipSYW
話豚切って悪いがまとめるとこんな感じ

この大田の相談に乗ったのが東大航空研究所の小川太一郎教授だった。
実験に協力した谷一郎東大教授によれば「昭和十九年夏、東大航研で
小川教授から新しい依頼があった。
小川さんは広い見識と温かい包容によって声望が高く、
外部から持ち込まれる相談の窓口の役割を余儀なくされていた。
その僅か前に、大田正一海軍少尉が火薬ロケット推進の特攻機の着想を持参し、
海軍上層部を動かすための基礎資料の作成を依頼していたのである。
私に求められたのは、木村秀政助教授の描いた三面図を基に、
風洞実験の助けを借りて、空気力学的特性を推定することであった。
仕事自体はさほど困難ではないが、特攻機が母機を離れた後は、
生還の可能性の全くないことを知って私はたじろいだ。」という。
http://ja.wikipedia.org/wiki/%E6%A1%9C%E8%8A%B1_%28%E8%88%AA%E7%A9%BA%E6%A9%9F%29
0366デフォルトの名無しさん2014/07/26(土) 20:06:16.38ID:AULF2YtD
もうアホどもはまとめてNGにぶっ込めばいいよ
0367デフォルトの名無しさん2014/07/27(日) 08:43:57.53ID:CtoyiymM
IDが導入されて良かった
0368デフォルトの名無しさん2014/07/27(日) 13:38:06.07ID:y0Xr839x
ID赤い奴は自動で消える仕組み
0369デフォルトの名無しさん2014/07/27(日) 14:06:02.09ID:wYLTHqwt
とっくに透明よ
0370デフォルトの名無しさん2014/07/27(日) 14:58:07.68ID:kK8gelhu
ID変えました（笑）
0371デフォルトの名無しさん2014/07/27(日) 16:36:09.04ID:fFsyojt4
忍法帳で判るんじゃね
0372デフォルトの名無しさん2014/07/27(日) 22:23:32.23ID:IbdTfPHn
パスワードを書いたままbitbucketにpushしたので
git push -f origin HEAD^:masterをやったんですけど一応pushした内容の1つ前には戻ったんですが
pushしたものが最近の活動ってところのログからたどれてしまい、アクセスすると内容が表示されてしまいました！
このやり方で合ってたんでしょうか？どうやって消せますか？
0373デフォルトの名無しさん2014/07/27(日) 22:34:22.42ID:PFdtsvV+
>>372
push -fして取り消したコミットもお主の最近の活動だから表示しておいてやるよ！
0374デフォルトの名無しさん2014/07/27(日) 22:43:56.24ID:IbdTfPHn
つまりそれって僕しか見えないものですか？
他の人には絶対に見えませんかね？
0375デフォルトの名無しさん2014/07/27(日) 22:49:55.98ID:PFdtsvV+
>>374
いや知らん。とりあえずリポジトリの設定を一時的にでも非公開にしとけよ
最悪bitbucket側でリポジトリを消して新しい空のリポジトリつくって、ローカルにある修正済みのブランチをpushすりゃいいんでないの？
0376デフォルトの名無しさん2014/07/27(日) 22:59:07.09ID:IbdTfPHn
いちおうコミットログのページにも表示はされてないんですけど
その取り消したコミットログのurlにアクセスすると表示されちゃうんですよ
複数人で操作してるリポジトリなので消すのはやべぇっすよ
0377デフォルトの名無しさん2014/07/27(日) 23:28:17.58ID:PFdtsvV+
>>376
Gitの仕様としてはブランチのコミットログからは消えても、
鯖のリポジトリ側ではGCされるまでそのコミットは残ってるしreflogとかで調べてそのコミットにアクセスできる

bitbucketは自分の？最近の活動でそのGC前のコミットにアクセスできるんだね？

問題は、bitbucketにおいて、他のユーザがそのコミットにアクセスする手段を提供してるか？
強制的にexpireする機能をユーザーに提供してるか？
あたりかな？bitbucketに詳しい人にでも聞いてください
0378デフォルトの名無しさん2014/07/28(月) 08:09:52.74ID:aDCUknIL
rebaseが重すぎる
もっと早くならんのか
0379デフォルトの名無しさん2014/07/28(月) 09:08:00.51ID:bfSVrt1T
Githubでの同じ事例への対処法が沢山転がってるだろう
0380デフォルトの名無しさん2014/07/28(月) 13:01:40.77ID:JUp78osr
gitホスティングサービスが作りたいんですがヒントください
何で作りたいかというと↓のサービスが有料なのが気に入らないのでこれよりもいい物を作りたいからです
http://jp.techcrunch.com/2014/07/28/jp20140728universions/
0381デフォルトの名無しさん2014/07/28(月) 13:20:52.08ID:h3Aquzzx
OSSホスティング総合【SourceForge,GitHub,etc..】
http://peace.2ch.net/test/read.cgi/tech/1384821518/
0382デフォルトの名無しさん2014/07/28(月) 14:44:42.56ID:+qczOS9S
黒い画面て
0383デフォルトの名無しさん2014/07/28(月) 17:20:29.69ID:b9cEV/Qq
日本人が作るとおままごとツールになりそうでなんとも
0384デフォルトの名無しさん2014/07/28(月) 18:20:02.23ID:FHFsPlLG
開発方法寄りの話になるんだけど、
フレームワークで開発者が作ったもの置くディレクトリと、フレームワーク自体のライブラリのディレクトリが混在してたりする。phpとか。ログの出力先まで含まれていたり。
gitに含めるのはどこまで?
0385デフォルトの名無しさん2014/07/28(月) 18:30:18.38ID:0rL2fBex
設定ファイルのデフォルトが示していればディレクトリも入るんじゃ？
セットアップのスクリプトが生成するようにすれば不要かもね。
0386デフォルトの名無しさん2014/07/28(月) 18:45:28.43ID:WkBzZDWV
あー、今ちょうどそんなプロジェクトやってる。
同じプロジェクトだったりしてw
0387デフォルトの名無しさん2014/07/28(月) 18:56:57.67ID:bfSVrt1T
同僚が2chに質問してたら退職も辞さない
0388デフォルトの名無しさん2014/07/28(月) 19:29:29.32ID:0rL2fBex
同僚がすげーキーボード叩いてる、
お、がんばってるな、とモニター覗き込む、
なんか掲示板に質問を一生懸命書いている…

コードの割に叩く回数が多いと思ったのはコレか！
0389デフォルトの名無しさん2014/07/28(月) 19:57:06.47ID:FHFsPlLG
人のプロジェクト引き継ぐと、開発したものじゃないものも大量に入ってて、どこ見ていいかわかんなかったりするんだよね。
例えばdjangoだとprojectごとでなく、appだけ入れておいた方が使いやすいと思うんだ。
mavenとかは余計なものが含まれなくて見やすい。
0390デフォルトの名無しさん2014/07/28(月) 20:11:31.94ID:Wt0X9vvC
環境再構築したときにそのまま使うファイルはignore
それ以外全部Git
0391デフォルトの名無しさん2014/07/28(月) 20:15:35.59ID:WkBzZDWV
バイナリとかどうしてる
0392デフォルトの名無しさん2014/07/28(月) 20:25:25.88ID:Wt0X9vvC
忘れてた
バイナリとIDEやプロジェクトの設定ファイルも除外
他人が入れて邪魔になるもんは大体入れんやろ
0393デフォルトの名無しさん2014/07/28(月) 21:08:52.61ID:0rL2fBex
最初だけ必要、でも同期されると邪魔、だけど時々大きく変わる場合同期が必要・・・

サンプルファイルをリネームコピーで使ってもらって説明にそう明記かな？
0394デフォルトの名無しさん2014/07/29(火) 23:47:58.65ID:ZWA+OWxm
全部禁止にしてから個別に管理するものを指定するために.gitignoreにこうかきました
*
*.*
.gitignore
!test/*.js
これだとtest/test.jsがgit statusに出て来ません
test/test.jsは作って有ります
どう修正したらいいですか？
0395デフォルトの名無しさん2014/07/30(水) 07:09:44.67ID:SFUuJg+H
*
*.*
.gitignore
!/test
/test/*
!/test/*.js
0396デフォルトの名無しさん2014/07/30(水) 12:27:46.44ID:q1vJpBfq
なぜ馬鹿は笑ってゴマカス
0397デフォルトの名無しさん2014/07/30(水) 15:09:39.87ID:x/403miQ
>>394
http://quartet-communications.com/info/technology/13642
0398デフォルトの名無しさん2014/07/31(木) 03:13:30.62ID:SIeAhRnd
EGitの質問ってこのスレでいいのかな？
0399デフォルトの名無しさん2014/07/31(木) 03:24:03.69ID:ipo4JPES
>>398
Eclipse統合M35【Java/C++/Ruby/Python/Scala】
http://peace.2ch.net/test/read.cgi/tech/1405391739/
0400デフォルトの名無しさん2014/07/31(木) 03:29:48.85ID:SIeAhRnd
他のGitクライアントはこのスレでよくて
プラグイン形式のGitクライアントはアカンのか
わかったよ
0401デフォルトの名無しさん2014/07/31(木) 06:46:03.60ID:gyCr5AMO
こっちでもいいとおもうけど
あっちのほうが答えられる人多いかもね
0402デフォルトの名無しさん2014/07/31(木) 12:08:31.40ID:jdJsZ4Jc
プラグインありにすると
Azure のひとも流れ込んできそう
0403デフォルトの名無しさん2014/07/31(木) 16:50:59.03ID:MnJeD9xE
Git 2.0.4 リリース
https://github.com/git/git/releases/tag/v2.0.4
0404デフォルトの名無しさん2014/07/31(木) 17:09:33.92ID:uBAJx71I
もうgit 2.1.0の開発はじまってんのか
0405デフォルトの名無しさん2014/07/31(木) 21:59:02.03ID:w9LroIYe
そりゃそうだろ。
開発は止まることなく続くんだから
2.0がリリースされたら2.1の開発の開始よ。
0406デフォルトの名無しさん2014/07/31(木) 22:26:16.95ID:WgloAiw2
おれみたいなショボグラマはリリースノートの長さにビビる
ソフトウェアを作るって大変なんだな
0407デフォルトの名無しさん2014/07/31(木) 23:35:44.21ID:uCJCqnN7
プログラミングの技能は関係ないだろ
0408デフォルトの名無しさん2014/07/31(木) 23:55:37.91ID:KWL6BjZO
予定は未定ですから
ここまでやった目安にしてるVerとかリリース番号は
0409デフォルトの名無しさん2014/08/01(金) 01:05:09.48ID:qcYKpf5p
もうちょいメンテナンスしてからでもいいと思うんだよ２．１
0410デフォルトの名無しさん2014/08/01(金) 04:04:44.68ID:7R/51h0c
>>404
並行開発のためのブランチじゃないか。
0411デフォルトの名無しさん2014/08/01(金) 05:30:01.08ID:Mjd2jJg4
GitHub微妙にレイアウト変えんなよ
間違って違う機能のボタン押しちゃったじゃないか
0412デフォルトの名無しさん2014/08/01(金) 10:11:50.93ID:pNAOaQhq
>>409
1.9からバージョン番号スキームが変わったから早く見えるだけ。

昔はw.x.y.zで、どんな変更が入るかによって下記のように分けようとしてた。
<すごくインパクトが大きい変更>.<インパクトが大きい変更>.<新機能等>.<バグフィクス>
でも w と x は一緒でよくね？って話になった。
ということで 1.8 以前には w.x.y.z の x が +1 されるのに数カ月 年単位かかってたのが、
今は約12週間に1回程度で x.y.z の y が +1 される
0413デフォルトの名無しさん2014/08/01(金) 11:29:11.79ID:HYcTfRZh
バージョン番号が細分化されてるソフトは不安定なソフトである象徴ｗ
0414デフォルトの名無しさん2014/08/01(金) 12:14:59.79ID:j/JylWKV
Unix文化圏は x.y.z のバージョン番号がわりと普通
0415デフォルトの名無しさん2014/08/01(金) 12:58:26.33ID:KQKeUN6R
>>413
firefoxをdisるのはもっとやれ
0416デフォルトの名無しさん2014/08/01(金) 13:59:39.14ID:c/SITlPI
>>415
え？今は31だぞ
0417デフォルトの名無しさん2014/08/01(金) 15:21:40.83ID:HYcTfRZh
メインバージョンが頻繁に上がるソフトは主流ではない、主流から外れたソフトｗ
0418デフォルトの名無しさん2014/08/01(金) 15:43:48.75ID:5YlCHfl7
細かく分かれてるのはサポートと製品管理に力を入れてるってことじゃねーの
0419デフォルトの名無しさん2014/08/01(金) 16:06:36.71ID:f/bFolqg
2.6.32-431.23.3.el6
0420デフォルトの名無しさん2014/08/01(金) 16:34:28.73ID:UcA9GDEc
>>418
ちげーよ
0421デフォルトの名無しさん2014/08/02(土) 00:52:36.46ID:SZsUPcoF
>>417
ウェッブ業界人に人気のChrome先生をdisるのはやめろ
0422デフォルトの名無しさん2014/08/05(火) 09:38:21.98ID:wIW++7Ni
Git 2.1.0-rc1 リリース
https://github.com/git/git/releases/tag/v2.1.0-rc1
0423デフォルトの名無しさん2014/08/05(火) 10:34:04.15ID:hWvlZYlP
リリースノートの日本語ぐらい書けや
0424デフォルトの名無しさん2014/08/05(火) 13:26:33.16ID:z3s8hGoL
お、どうしたどうしたｗ
0425デフォルトの名無しさん2014/08/05(火) 23:52:18.73ID:64utEkfv
Git2.0Winインストーラまだかよ
0426デフォルトの名無しさん2014/08/06(水) 00:08:09.00ID:GxwqgVuS
git2.0の使いたい機能があるの？それとも2.0以前のバグに悩まされてるの？
0427デフォルトの名無しさん2014/08/06(水) 00:19:37.21ID:IlVwDJHj
Macが2.0だから
0428デフォルトの名無しさん2014/08/06(水) 00:38:57.57ID:Tye/sJpW
cygwin使っとけ
0429デフォルトの名無しさん2014/08/10(日) 08:23:27.47ID:aTEKyeJh
http://www.buzzword.jp/img/face10.png
0430デフォルトの名無しさん2014/08/10(日) 20:12:45.54ID:dsJn6Bct
guro
0431デフォルトの名無しさん2014/08/10(日) 21:23:21.99ID:46zegaug
kaba
0432デフォルトの名無しさん2014/08/12(火) 09:29:02.31ID:CaL42KsB
ファイル名を変更しつつ、変更前のログを変更後のファイルに反映させるにはどうしたらいいですか？

ファイル名変更前： foo.c
git log foo.c
変更 B
変更 A

ファイル名変更後： bar.c
git log bar.c
変更 D
変更 C

これをgit log bar.cとすると
変更 D
変更 C
変更 B
変更 A
と表示させたいです
0433デフォルトの名無しさん2014/08/12(火) 09:44:11.02ID:lLNyag2q
git log --follow bar.c
0434デフォルトの名無しさん2014/08/12(火) 10:02:09.04ID:CaL42KsB
Thx!!
0435デフォルトの名無しさん2014/08/12(火) 23:58:44.30ID:F2vV/z0S
SourceTree1.6betaでUTF-8の日本語のdiff文字化けが直っていました
https://twitter.com/sourcetree
0436デフォルトの名無しさん2014/08/13(水) 23:46:46.70ID:0VzL4TYP
最初のコミットってどのあたりですればいい？
全然コンパイルどころか形もなってない段階のから？
それとも部分的なコンパイルくらいは可能な段階になったあたり？
はたまたテスティングやアルファ版と呼ばれるくらいの段階？
0437デフォルトの名無しさん2014/08/13(水) 23:56:34.28ID:FF7HYwuu
・空の.gitignore置いたら
・Readme書いたら
・プロジェクトファイルやソリューションファイル、メイクファイルなどを作成したら
・仮のmain()書いたら

個人的には…開発環境が決め打ちなら3番目や環境によっては4番目、リポジトリサービスが決め打ちなら2番目、何も無いなら1番目かなあ
0438デフォルトの名無しさん2014/08/14(木) 00:06:25.41ID:UwSdLV//
作業履歴は1から残しとくべきだよね
0439デフォルトの名無しさん2014/08/14(木) 00:11:59.96ID:mP75ikG7
コンパイルすら通らない段階からコミットしていいのですね
0440デフォルトの名無しさん2014/08/14(木) 00:36:51.50ID:DeyF+ee0
完成直前のデータ消失上等ならコミットしないでもいいんじゃねーの
0441デフォルトの名無しさん2014/08/14(木) 00:37:21.42ID:K2fde6cH
最近だと最初にベースとなるコードをツールで自動生成することが多いんで
まずはその生成前と後の状態をコミットしちゃうな
0442デフォルトの名無しさん2014/08/14(木) 02:09:36.84ID:56cGoOWs
開発時の作業はブランチを切ってやるもの
ならマスターブランチの履歴も汚れない
0443デフォルトの名無しさん2014/08/14(木) 02:21:00.12ID:cpAbF84S
バージョン管理でえらく潔癖症な人多いな
0444デフォルトの名無しさん2014/08/14(木) 02:45:25.37ID:UiK3whtS
>>443
バージョン管理ソフトはバックアップソフトじゃないからね。
直近の1週間分のコードがあればいいとかいうわけじゃない。

コミットはどんな修正をしたか、またはどんな修正をするかを
表しているので、変なコミットを作るのはよくないよ。
0445デフォルトの名無しさん2014/08/14(木) 02:53:22.08ID:9Vu8tjE9
日付フォルダにうんざりした人が使うものだからな

ｇｄｇｄなら日付フォルダと大差ないじゃんって話になってしまう
0446デフォルトの名無しさん2014/08/14(木) 03:05:53.73ID:ytFl/Oa9
適当にコミットして後で潰したり並べ替えたりすればいいんだよ
変数名関数名然り、こういう時の手際でおつむの差が出る
0447デフォルトの名無しさん2014/08/14(木) 03:14:26.01ID:UiK3whtS
>>446
すっかりgitになれてしまって、
色々なファイルを修正しつつ、定期的にコードをコミットする段階で
git add -pとかで一部だけコミットして、いくつかのコミットを
意味のある単位に並び替えたりコミットをまとめたりという作業が
スムーズにできるようになったよ

ほんとgitは開発に便利。
0448デフォルトの名無しさん2014/08/14(木) 11:25:35.52ID:XPpNgzhX
確かにファイルを保存するタイミングでコミットする癖がついた。rebaseしてsquashしてmerge。
流れとか気にせず目の前にあるコードにだけ集中できるのがこんなに快適だとは思わなかったよ。
0449デフォルトの名無しさん2014/08/16(土) 03:15:24.55ID:UcWHe/+M
msysgit
Git-1.9.4-preview20140815
0450デフォルトの名無しさん2014/08/16(土) 05:30:09.74ID:7Fp1jvse
Rebaseをドラッグ＆ドロップでできるとこまでGUI化したツールができたら面白そう
事務職も使いだすだろう
0451デフォルトの名無しさん2014/08/16(土) 05:51:17.63ID:LOtWkDZk
>>450
> Rebaseをドラッグ＆ドロップでできるとこまでGUI化したツールができたら面白そう

それは無理。

正確に言えば、ドラッグ＆ドロップまではできるだろう。

無理なのは、rebaseした時に起きるコンフリクトの解消。
単純に難しいというのもあるし、
バイナリは解消できない（一報を捨てることしか出来ない）
それは「すなわちデータが消えた」という騒ぎになる。
0452デフォルトの名無しさん2014/08/16(土) 21:56:22.07ID:UcWHe/+M
https://github.com/git/git/blob/v2.1.0/Documentation/RelNotes/2.1.0.txt
0453デフォルトの名無しさん2014/08/18(月) 20:43:47.81ID:S1QfPa+c
Git 2.1登場 - Unicode 7.0対応強化など
http://news.mynavi.jp/news/2014/08/18/047/

ワークフローを強化した「Git 2.1」がリリース
http://sourceforge.jp/magazine/14/08/19/085400
0454デフォルトの名無しさん2014/08/18(月) 20:54:26.50ID:IPiH7YvP
msysgitの2.0はよ
0455デフォルトの名無しさん2014/08/20(水) 19:50:34.58ID:b2jSERqi
新しいSourceTree行選択後ハンクに戻れないじゃん
クソアプデ
0456デフォルトの名無しさん2014/08/21(木) 01:34:03.06ID:Nk//m6zY
「アプデ」の三文字を見た瞬間鳥肌が立った
0457デフォルトの名無しさん2014/08/21(木) 01:46:32.19ID:tOl9rabw
花言葉は「進捗が遅れ気味」
0458デフォルトの名無しさん2014/08/21(木) 04:47:49.84ID:e2XVI0jx
git使い始めてみたけどかなり良いね
上の方のレスを参考にして、まずブランチ切って、適当に作業して、
ある程度まとまったらgit merge --squashでそのブランチの内容全てを一度でコミットする
という使い方に落ち着いた
0459デフォルトの名無しさん2014/08/21(木) 06:33:14.84ID:Dozm2kfh
適当に作業してる途中はブランチでコミットしないの？
0460デフォルトの名無しさん2014/08/21(木) 06:39:52.57ID:e2XVI0jx
もちろんするよ
merge --squashをするとブランチに適用されてるコミットをすべてひとまとめにして
一度のマージで本ブランチに適用できる
その際にコミットもしなきゃいけないから一度のコミットという表現を使った
0461デフォルトの名無しさん2014/08/24(日) 21:45:44.50ID:52mNGxWX
15時間でわかるgitってどう？
0462デフォルトの名無しさん2014/08/24(日) 22:47:01.58ID:xfU4T7hj
16時間は必要そうな印象を受けた
0463デフォルトの名無しさん2014/08/24(日) 23:06:32.86ID:0LPRT5si
アマで見たとこよさげ
今度立ち読みしたい
0464デフォルトの名無しさん2014/08/25(月) 00:38:40.81ID:py1PbdDs
>>461
たまたま今日買ってきて3時間目まで読んだところだが
CLIなんて面倒臭くてやってられんぜ
俺はSouceTreeでいくぜって人にはよさそう

俺の場合、猿でも分かるじゃあなんかスッキリせんし
GitHub実践入門でも読んでしっかり勉強するかねって
読み始めたはいいが、若干、端から知ってることを前提気味に専門用語ポンポンでてくるし
アホの初心者には優しくねえ。CLIじゃあやっぱり視覚的にイメージしずらいし
面倒くさいし、楽しくねえってその本に寄り道してるところだが、今のところ楽しく読めてる。

15時間で分かるGitでひと通り触ってから
GitHub実践入門で、背景となるコマンドや上手な実運用を学ぶ
ってほうが挫折はなさげ

んなもの、ネットにいくらでもあるだろって人には
15時間で分かるGitはヌルくて高いだけの本かも。
ざーっと、全体を読んだ限りだと、
”SourceTree　使い方”とかでググって手に入る情報ばっかりだし、
要領の良い人、本が嫌いな人には不要な本
0465デフォルトの名無しさん2014/08/25(月) 02:19:16.20ID:yZn9y/8B
ネットで調べりゃなんでも分かる、ってまあ他でも良く言われるけど、結局
本買う人って時間を金で買ってることでしょ。
わざわざ探している時間の方がもったいない、時間単金の高い人というか。
その辺りは大切というか、ヒマで貧乏な人と優先順位とか価値観が違うからねえ。
あと上の本よりはやっぱり「GitHub実践入門」の方が良書と思う。
0466デフォルトの名無しさん2014/08/25(月) 02:23:05.61ID:OTL7uAT+
情報の量質共にネット以下のくだらない本が増えたのも事実
0467デフォルトの名無しさん2014/08/25(月) 02:33:56.63ID:py1PbdDs
p66〜の競合の解決
って説明の部分だと、いきなりコンフリクト解決の方法の話になる

gitのサイトや同類の本だと、別のディレクトリにもう一つクローンを作成するなどして
擬似的に同時開発している担当者を想定して
まずコンフリクトとなる状況の作成から入ると思うのだが、そこが端折られてる

プルやフェッチについても、それが必要となるような状況の作成は端折られて
じゃあ、プルしてみましょう、フェッチしてみましょうって話になる
何の前知識もなく読み進めてきた人には、そもそもプルもフェッチも必要ない
状態なんだけど・・・ってなるかな

書かれていることそれぞれは丁寧で分かりやすいのだが
前知識無しに、やりながら覚える式の手取り足取りを期待してる人には
話が急に飛ぶ、本で言ってる状況の作り方が分からないと感じるかも

p.70
もちろんすべての変更が破棄されるので、

と変なところで尻切れトンボになってる。
まあ、技術評論社の初版第1刷だし、こんなもん？
0468デフォルトの名無しさん2014/08/25(月) 05:40:22.74ID:qum3FgxP
>>465
時間を節約したい人こそ要点だけつまめるネットのほうが向いてる
ゴミ情報しかない場合もあるがGitは充実してる
本のほうが順序だって読み進めるので時間かかるうえに
入門レベルの本じゃ結局肝心の細部はネットで実例を探したほうが的確な情報を得られる

あとまあ件の本だがいくらCLIを避けたところでRebaseまわりはコマンド使うことになると思う
こないだSTのGUIでコンフリクトのあるリベースしようとしたら強制終了されてcmdで直した
エラーの解消はだいたいGUIじゃ詰まるだろうし強制プッシュもできなかったよな？
GUIだけで使おうと思ってもかえって苦行なので要所要所でCLIを覚えるべき
なおGitHub実践入門はCLIの学習には使えないのでその用途で買ってはいけない
0469デフォルトの名無しさん2014/08/25(月) 09:06:55.86ID:85j5blVH
本は、全体を通して体系的に知識を整理出来るのがいいのよ
記憶の中でおおよそページのあの辺りに書いてあったなって
知識と物理的位置が紐付いて記憶出来るのもいい。
個別の問題解決に対してはネットの方が早いし詳細が得られると感じてる

スレチですな
0470デフォルトの名無しさん2014/08/25(月) 11:34:31.85ID:V08rwKRx
一般的に、本ほどまとまっているサイトは無い。

例外として、gitやPHPやMSDNが本レベルまでまとまっているが
一般的には本のほうがまとまって情報を得られる。

本300ページに相当するサイトはあるのか？
と考えれば自ずと理解できるだろう。
0471デフォルトの名無しさん2014/08/25(月) 11:39:09.96ID:ksmxv1nf
>>470
msdnは本というより図書館な感じ
まず棚を探さないといかんってのがね…
0472デフォルトの名無しさん2014/08/25(月) 11:41:19.15ID:7ENIkGwq
詳しいところは英文だからね
0473デフォルトの名無しさん2014/08/25(月) 12:43:14.79ID:C0s8ILgV
Gitの仕組みさえ理解したら、UIは陸亀さんでいいような希ガス
svnも陸亀さんなので両方入れるとコンテキストメニューでアレだが
0474デフォルトの名無しさん2014/08/25(月) 18:00:46.08ID:ksmxv1nf
Tortoiseってリクガメだったのか、ウミガメとは違うのね
0475デフォルトの名無しさん2014/08/25(月) 18:07:02.98ID:l2Fadlu9
俺の長年の調査によるとウミガメは turtle のようだ
0476デフォルトの名無しさん2014/08/25(月) 19:11:19.20ID:qD2gbKMt
gitを使いこなせない（というかバージョン管理を使いこなせない）

git add .
git commit -m "some update"

の全く無意味な動作の繰り返しだは
0477デフォルトの名無しさん2014/08/25(月) 19:13:33.72ID:qD2gbKMt
どうしても雑多な書き換えが多くてコメントをまとめられない
もっと細かな単位でコミットしていけばいいんだろうけど
どうしても不精だから雑多な変更等が溜まってからコミットするから適当なコメントがつけられない
0478デフォルトの名無しさん2014/08/25(月) 19:48:48.33ID:KUe7O5sS
add -pというものがあるのじゃよ
0479デフォルトの名無しさん2014/08/25(月) 20:00:14.51ID:yjE0cHrF
分類してまとめるのもスキルのうち
0480デフォルトの名無しさん2014/08/25(月) 21:06:21.83ID:ISmNy6hh
適当なタイミングで適当な小さいコミットをしまくってrebase -iできれいにまとめるってのもあるんじゃよ
git-nowってコマンド作ってそうやってる人もいるみたい
0481デフォルトの名無しさん2014/08/25(月) 23:13:30.25ID:C0s8ILgV
>>474
海亀はタートルやからね
0482デフォルトの名無しさん2014/08/25(月) 23:50:37.85ID:QhfqmC/d
あいつら海亀なのに下水道に住んでたのか
0483デフォルトの名無しさん2014/08/26(火) 00:04:19.90ID:mhCqY7ev
useBitmap = true だとなんか調子悪い。。
0484デフォルトの名無しさん2014/08/26(火) 05:13:51.51ID:tGns6ZHL
結局、一度馴れてしまえばコマンドが一番楽なのかな
0485デフォルトの名無しさん2014/08/26(火) 05:52:36.84ID:NQFYEExI
ずっとコマンドラインで使ってたけど
IDE組み込みのGit関連機能も慣れるとなかなか便利だよ
まあコマンドラインでやったほうが早いとかコマンドライン必須なこともあるけど
だいたいはIDE側だけで済む
0486デフォルトの名無しさん2014/08/26(火) 08:30:49.41ID:+r6eU4rX
せんせーemacsのexecute-extended-commandから使うのはIDE側ですかー? コマンドですかー?
0487デフォルトの名無しさん2014/08/26(火) 09:00:21.23ID:7aPILC/T
自分でタイプしないなら前者になるんじゃないの？ってどうでもいい話だったね
0488デフォルトの名無しさん2014/08/26(火) 09:52:19.13ID:oyYbyyhj
元気のGUIはコマンドカタカタ打たなくてもマウスクリックだけでブランチいじれるのでそっちのほうがラク
0489デフォルトの名無しさん2014/08/27(水) 01:04:07.93ID:E5NysQ8U
試してみるか？ 俺だって元コマンドーだ
0490デフォルトの名無しさん2014/08/27(水) 01:20:08.22ID:DkXXItR4
てめぇなんか怖かねえ
0491デフォルトの名無しさん2014/08/27(水) 02:30:33.45ID:eiNaMy6m
こんなの飛行機じゃないわ！羽のついたGNUよ！
0492デフォルトの名無しさん2014/08/27(水) 08:39:15.33ID:E5NysQ8U
どこで使い方を習った？
15時間で分かるGitを読んだのよ！
0493デフォルトの名無しさん2014/08/28(木) 00:41:35.30ID:j/KGK/aT
勝手にフォークしてソースは盗む、スパゲティにする、俺のコードをマージしろなんて突然メチャクチャは言い出す。
かと思ったらバイナリファイル管理論争に巻き込んで大勢死人は出す、挙句Githubでソーシャル開発とか、あんた人間なの！？
お次はrebaseときたわ。2ちゃんねらが、あんたを炎上させようとしたから助けたわ。そうしたら私まで追われる身よ！
0494デフォルトの名無しさん2014/08/28(木) 12:39:43.40ID:pLtajWiU
やっぱダラダラ長いとネタの面白さもガタ落ちだな
0495デフォルトの名無しさん2014/08/28(木) 12:47:49.81ID:Q4RzOOjO
野郎ぶっスカッシュしてやる！
0496デフォルトの名無しさん2014/08/29(金) 00:14:52.86ID:0lr9wl8v
git reset --hard
0497デフォルトの名無しさん2014/08/29(金) 00:45:07.44ID:t+ZmPWDd
rm -rf $(git rev-parse --git-dir)
0498デフォルトの名無しさん2014/08/29(金) 03:42:56.43ID:dVjZbmRE
でかくなったファイルを分割するとき(だいたい真っ二つにすると思ってもらっていいです)
それぞれの断片の履歴を追えるようにするにはどうしたらいいですか?
どちらかが new file になってしまうのですが…
0499デフォルトの名無しさん2014/08/29(金) 06:13:20.06ID:bRof6i8E
追うオプションがあるだろ
0500デフォルトの名無しさん2014/08/29(金) 08:57:31.48ID:dduCj2SP
>>496
ワロタ
0501デフォルトの名無しさん2014/08/29(金) 11:16:27.08ID:9OWc8ATu
>>498
やり方が間違ってるよ。そういう場合はリファクタリングをしよう。

まずテストコードがある。という想定。なくてもやりかたは同じだけど。

AというファイルをB、Cに分ける場合、テストコードがあるわけだから
いきなりファイルを分割できない。

まず空のファイルBを作る。AはBに移動したいコードを
Bに移動して、AからBを呼び出すようにする。
こうすれば、テストコードはそのままにBにコードが移る。
同様にCも同じことをやる。そしたらA、B、Cのファイルが出来る。

次にAのテストコードはそのままに、B、Cのテストコードを追加する。
そののち、Aを使ってるコードを、B、Cを直接使うようにする。

最後に不要になったAのコードとテストを削除する。
0502デフォルトの名無しさん2014/08/29(金) 11:33:27.01ID:TBK0UDGJ
>>498
分割してnew fileのままコミット。
$ git show -C30
0503デフォルトの名無しさん2014/08/29(金) 17:23:54.33ID:dVjZbmRE
>502
blameでもいけますね。ありがとうございます。
0504デフォルトの名無しさん2014/08/30(土) 15:34:04.65ID:4WQaR9Xf
お前らの所って、もう2.xに移行した？
良くなってるならうちも移行しようか考えてる
0505デフォルトの名無しさん2014/08/30(土) 15:37:38.87ID:AoE8b4bU
3.xが出たら2.xに移行しようと思う
メジャーバージョンは常にひとつ下で追いかけるほうがいい
0506デフォルトの名無しさん2014/08/30(土) 15:46:53.99ID:yHmhwtLF
こいつ2.x出る前何使ってたんだ
0507デフォルトの名無しさん2014/08/30(土) 15:59:05.20ID:AoE8b4bU
何だお前は、俺は生まれたときからそういう姿勢で生きてきたとでも思ってんのか
0508デフォルトの名無しさん2014/08/30(土) 16:29:41.63ID:4WQaR9Xf
git ってこないだ1.9 が出て、移行しようと思ってたらあっという間に2.1だからな。
Linux のKernel並に3カ月おきに新しいのを出していくつもりなんかな？
0509デフォルトの名無しさん2014/08/30(土) 16:33:45.21ID:JAT13qNM
常時2を使ってるが、特に問題ないな
0510デフォルトの名無しさん2014/08/30(土) 16:39:38.95ID:QM2vBzSO
msysgit使いなので2.xに移行できませんえん
0511デフォルトの名無しさん2014/08/30(土) 17:31:04.08ID:eMjEoUcz
>>503
非難でいけるんだ
0512デフォルトの名無しさん2014/08/30(土) 22:26:33.50ID:fZGGp6dM
git reset
0513デフォルトの名無しさん2014/08/31(日) 01:06:46.53ID:b8tx/Oby
>>507
違うの？ 尊敬したのに損した
0514デフォルトの名無しさん2014/08/31(日) 01:33:47.19ID:DCfsrrwi
ここでメジャーバージョンが上がったのに大した意味はないよね
マイナーバージョンと同レベルの変更だし、ここで止めても仕方ないよ
0515デフォルトの名無しさん2014/09/01(月) 12:34:03.18ID:448XiQDv
http://www.backlog.jp/git-guide/stepup/stepup1_5.html
これによるとmasterブランチにはリリース内容だけにしろってことなんですが
git initしたときに新しくブランチが作れません
やろうとしたのはこうです
git init
git checkout -b dev
コードを書きまくってコミット
git checkout master
git merge dev
0516デフォルトの名無しさん2014/09/01(月) 12:59:42.75ID:ZKcbbA9k
で、何をしたらどうなったの
0517デフォルトの名無しさん2014/09/01(月) 19:49:14.98ID:09g8ZS7k
>>512
git init
git commit --allow-empty -m "Empty"
0518デフォルトの名無しさん2014/09/02(火) 01:06:47.06ID:6AEFW/2e
allow empty で作ったコミットが
rebase で消されたり
rebase -i の中断要因になったり
あれどうにしてほしいなあ。
なんでrebaseにもallow emptyがないんだろう？
0519デフォルトの名無しさん2014/09/02(火) 01:23:39.86ID:Hip3v4+J
aブランチでファイルを編集してaddもcommitもせずbブランチにいきました
bブランチでstatusをみると
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)

test.php

nothing added to commit but untracked files present (use "git add" to track)

って出ます。これだけだとどこのブランチで編集したのかわからず、どのブランチでadd&commitしたらいいのかわかりません
どのブランチで編集したか調べる方法を教えてください
0520デフォルトの名無しさん2014/09/02(火) 02:21:12.97ID:fFmOi5Cz
シェルの履歴を見ればどのブランチをチェックアウトした状態だったか分かるんじゃね
0521デフォルトの名無しさん2014/09/02(火) 02:48:39.82ID:H6/bQ2I4
>>518
allow-empty の説明を読んで俺は使わなくなったよ
0522デフォルトの名無しさん2014/09/02(火) 02:54:30.64ID:4W2L00Fu
>>518
allow-emptyを何の用途に使ってるの？

この機能って、

コミットするものはまだないけど
とりあえずブランチきって共有リポジトリにpushしておくか。
そうすればみんなに今俺がこの機能を作り始めたってことが伝わるし。

って時に使うものなんじゃないの？

rebaseしたくなった時って言うのは、何かのコミットが存在しているわけで、
その時は自動的に消えて欲しいわけで、よく考えられた機能だなぁって
思ってるんだけど。
0523デフォルトの名無しさん2014/09/02(火) 11:03:20.34ID:AWoqLo6D
git config local user.name "zxy"すると
git config -lでみるとglobalに登録したuser.nameが残ってて2つ表示されるんですけどこれで大丈夫ですか？
0524デフォルトの名無しさん2014/09/02(火) 13:14:58.49ID:YTDTwniL
git stashって新規作成ファイルは保存してくれないんですけど
誤ってmasterで作業してた時、今の作業状態を別ブランチに映す場合はどうやってますか？
0525デフォルトの名無しさん2014/09/02(火) 13:47:47.99ID:ja7HZQJ9
新規ファイル（管理されてないファイル）なら
設定ファイルなどと同様、ブランチ移動に関して
全く関与しないので、普通にstashして移動してstash popできるが？
0526デフォルトの名無しさん2014/09/02(火) 13:49:11.62ID:ja7HZQJ9
まあ、オプションで新規ファイルとかもstashしてくれるけど、
間違ったブランチで作業して移動する時に、オプション使ったこと無い。
0527デフォルトの名無しさん2014/09/03(水) 12:10:14.74ID:YNir0Y9+
gitlab入れたけどメモリ1GB環境だと重くてすぐ消した
0528デフォルトの名無しさん2014/09/03(水) 12:19:42.32ID:Bk50IRfN
>>527
これ見たの？
https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/requirements.md
0529デフォルトの名無しさん2014/09/03(水) 13:57:46.99ID:4uEkndM7
gogs軽いぞ
中華でベータだけど
0530デフォルトの名無しさん2014/09/03(水) 14:10:55.95ID:7PpuCQwz
ベータは動作環境が狭いからなあ、、、ってgolangなのか
0531デフォルトの名無しさん2014/09/04(木) 17:16:52.33ID:so/xiuM/
git init
touch README.md
git add -A
git commit -m "Initial commit"
git checkout -b dev
touch hello.php
git add -A
git commit -m "added: hello.php"
touch hello.rb
git add -A
git commit -m "added: hello.rb"
git rebase -i HEAD~2
ここでエディタが立ち上がるので
修正前------------------------
pick a1f4923 added: hello.php
pick d5859a1 added: hello.rb
修正後------------------------
pick a1f4923 added: hello files
fixed d5859a1 added: hello.rb
------------------------------
修正して保存してエディタを閉じる
git checkout master
git merge dev
git branch -d dev
05325312014/09/04(木) 17:17:30.34ID:so/xiuM/
masterブランチを汚さず別ブランチで作業してコミットをまとめるのってこれで合ってますか？
0533デフォルトの名無しさん2014/09/04(木) 18:18:50.75ID:r3dec82J
いいと思うよ
0534デフォルトの名無しさん2014/09/04(木) 18:30:31.98ID:agrvnvoZ
>>532
merge --squashの方が楽じゃない?
0535デフォルトの名無しさん2014/09/04(木) 19:47:20.06ID:SNsufMBL
最近仕事で触り始めたので勉強中です(SourceTreeと一緒に使っています)
GitFlowでリリースブランチを切るとリリース対象のファイルが表示されますが、
そのリリース対象のファイルをコマンドライン等で反映先のディレクトリに
リリースするような方法はないでしょうか？

現在はSCPでファイルをアップロードしているのですが、時折作業ミスが発生し
どうにかならないかと思案しております。
シェルでリリース対象ファイルのディレクトリパス等を取得して…のようなことが
できれば嬉しいのですが。

宜しくお願いします。
05365312014/09/04(木) 19:51:21.34ID:okNlOH27
merge --squashご飯食べてから試します
ちなみにlogはこんなふうになってるけど本当にこれでいいんですか

* cb11364: 2014-09-04 17:28:50 +0900: Merge branch 'dev'
|\
| * 44b9bbc: 2014-09-04 17:25:42 +0900: added: hello.php
|/
* 538714b: 2014-09-04 17:12:54 +0900: Initial commit
0537デフォルトの名無しさん2014/09/05(金) 00:52:21.25ID:XPb05F9M
>>536
狙ってマージコミットを作ったのならそれでいいんじゃね
もし一本道になって欲しいなら設定を見直したほうがいい
そのログなら通常fast-forwardになるはずだから、常に--no-ffを使う設定がされてそう
0538デフォルトの名無しさん2014/09/05(金) 23:45:43.67ID:SZP3vN/x
gitconfigで
[merge]
ff = false
って設定してありました
確か昔どこかの記事やらスライドを見て設定したかもしれません
0539デフォルトの名無しさん2014/09/06(土) 00:12:55.88ID:LAlkQfIz
masterブランチにはREADME.mdしか置いてありません。
htmlファイルを作るためにhtmlブランチを作りました。
htmlファイルが完成したのでjavascriptでhtml要素を操作するコードを書くのでjavascriptブランチを作ります。
さて、この場合htmlブランチからjavascriptブランチを作ってhtmlブランチとjavascriptブランチをマージして完成したらmasterとマージするのがいいのか、
masterブランチからjavascriptブランチを作って、htmlブランチとjavascriptブランチを1つずつmasterブランチにマージしていくのがいいのか
どれが定番なのか教えてください
0540デフォルトの名無しさん2014/09/06(土) 00:27:36.41ID:mpUeuKJh
めんどくせえ
git-flowCI覚えて出直してこい
0541デフォルトの名無しさん2014/09/06(土) 00:28:04.39ID:mpUeuKJh
flowとCI
0542539＠代行レス2014/09/06(土) 01:13:35.47ID:nVESKkfI
ありがとうございますflow と ci覚えてきます
0543デフォルトの名無しさん2014/09/06(土) 11:23:01.20ID:MWnQ8CWe
git checkout ハッシュ

過去の履歴に戻った後に最新のコミットにハッシュを使わないで戻る方法を伝授してください
0544デフォルトの名無しさん2014/09/06(土) 11:43:50.26ID:kRNHJ6eY
開発では常にmergeをno-fast-forwardに統一するべきである
pull requestを送る場合は常にrebaseでコミットをまとめてから送るべきである
0545デフォルトの名無しさん2014/09/06(土) 11:46:11.69ID:kRNHJ6eY
ブランチは必ずmasterから分岐させるべきである
ごちゃごちゃしたブランチのコミットを整理するためにrebaseを使うべきではない
masterからブランチを派生させることを心得ておけばrebaseを使う必要がなくなる
0546デフォルトの名無しさん2014/09/06(土) 12:31:08.84ID:wsRqGyAq
>>544-545
場合によりけり

「○○の場合は」と書いてないお前の書き込みに
価値はない。
0547デフォルトの名無しさん2014/09/06(土) 12:50:50.05ID:Y581x5zV
まだmergeもrebaseも使ったこと無いから勉強になります
0548デフォルトの名無しさん2014/09/06(土) 13:35:24.57ID:Spv4j8U1
>>545に同意
>>546ルールを決めないから「場合によりけり」って曖昧な事を抜かす。こういう奴が一番リポジトリを壊す
0549デフォルトの名無しさん2014/09/06(土) 13:41:13.86ID:YGfPHROT
だからどんなルールにするかが場合によりけりなんだろ
0550デフォルトの名無しさん2014/09/06(土) 14:06:03.08ID:oq2XdgVR
クソルールでダメなリポジトリを作らないようにしましょうって話じゃないの？
0551デフォルトの名無しさん2014/09/06(土) 14:20:16.91ID:ssgHRQI6
銀の銃弾を探しに行くのは構わんが錫の銃弾を売りに来るのはやめろ
0552デフォルトの名無しさん2014/09/06(土) 16:37:53.08ID:iAGDf1Qx
>>543
git reset --hard ブランチ
0553デフォルトの名無しさん2014/09/06(土) 19:34:47.94ID:nW4UkLOS
>>550
まったくもってその通り。

考えるのが嫌なのか、ルールを作って
それだけしかやらないようにする。

もっと便利なものに、それを殺して
単なる作業にしてしまう。

素人がルール作るなっての。
0554デフォルトの名無しさん2014/09/06(土) 19:39:26.80ID:xP6IFMix
>>546
どんな場合のことを言っているのか分からないのでそのレスから価値が生まれてこない。
0555デフォルトの名無しさん2014/09/06(土) 19:57:34.14ID:SoF/8Pjd
>>554
え？ それで言い返したつもり？ｗ

つまりあんたが言うように、どんな場合のことを言っているのか分からないから
価値が生まれてこない。は正しいよね？

じゃあ言ってることはあってるじゃんｗ
0556デフォルトの名無しさん2014/09/06(土) 21:13:44.84ID:A8IOA0fF
>>545
マスターの先頭ににリリースバージョンでないコミットを置かれると第三者が利用しにくい
二行目も作業内容の一時的な保存を禁止されるのでこれも不便

教えて乞食か煽り目的かな？
0557デフォルトの名無しさん2014/09/06(土) 21:28:01.09ID:WRbx/+ja
それはタグを付けろよ
0558デフォルトの名無しさん2014/09/06(土) 21:31:50.31ID:WRbx/+ja
書き漏れたけどstashもな
0559デフォルトの名無しさん2014/09/06(土) 21:53:32.48ID:A8IOA0fF
論争煽りと書くべきだった
0560デフォルトの名無しさん2014/09/07(日) 22:02:25.60ID:nk2Tw+Xt
同一リポジトリの他のブランチのファイルを今のブランチにコピーする方法ありませんか？
0561デフォルトの名無しさん2014/09/07(日) 23:37:55.06ID:GBwjwKNH
checkoutでできなかったっけ？
0562デフォルトの名無しさん2014/09/08(月) 00:12:41.29ID:WRBqI71e
指定したブランチ全体をチェックアウト
特定のファイルをチェックアウト
指定したブランチの特定のファイルをチェックアウト
0563デフォルトの名無しさん2014/09/08(月) 00:22:41.19ID:qdDflaMT
masterブランチは.gitignoreしか置いてない状態で
開発用ブランチAでファイルを作成・編集しコミットして開発用ブランチBに切り替えました
開発用ブランチBで同じファイルを作成して編集してたんですがコミットしないと開発用ブランチAに戻れません。
一時的にAにもどってまたBで作業したいんですがどうやってコミットせずにAに切り替えられますか？
0564デフォルトの名無しさん2014/09/08(月) 00:23:17.05ID:NAv86kVA
gitのやり方にこだわらなければ普通にできるっしょ
リポジトリ外に一度当該ファイルだけコピーしてチェックアウトしてからそれを持ってくればいいだけなんだし
0565デフォルトの名無しさん2014/09/08(月) 00:23:46.20ID:NAv86kVA
>>564は>>560宛てね
0566デフォルトの名無しさん2014/09/08(月) 00:33:25.80ID:crPwpkXi
>>563
スタッシュ
0567デフォルトの名無しさん2014/09/08(月) 00:48:37.10ID:+kFenLfh
俺ならいっそコミットしちゃうかな
どうせsquashでまとめちゃうし
0568デフォルトの名無しさん2014/09/08(月) 02:03:41.81ID:qdDflaMT
>>566
Bでまだコミットしてない状態だとstashに追加できません
>>567
コミットするしか無いですかね＞＜
0569デフォルトの名無しさん2014/09/08(月) 02:31:07.78ID:NAv86kVA
それはstashの使い方というかgitを理解してない感じだね
0570デフォルトの名無しさん2014/09/08(月) 06:44:26.76ID:VKDX8UYB
とにかくgit stashしてみればええんやで
0571デフォルトの名無しさん2014/09/08(月) 08:20:59.95ID:p1aOvVUP
git squash
とか
git stash
と間違えて
git sqash
と書きそう
0572デフォルトの名無しさん2014/09/08(月) 08:39:16.65ID:0SpwLnTc
>>568
git stash save -u
0573デフォルトの名無しさん2014/09/08(月) 08:52:05.03ID:BIFfl8OH
>>568
>>564 は無視か？
どうせ中身はファイルなんだから、もうコピーして戻してやりたいことやってからコピーしたファイル戻せよ
いったいどういうgitの使い方したらそうなるんだよ
0574デフォルトの名無しさん2014/09/08(月) 11:01:43.42ID:4rWcgI79
>>552
detached from なんちゃらってでました
git checkout ブランチ
これでいけました
0575デフォルトの名無しさん2014/09/08(月) 11:07:08.95ID:C+vypWur
>>574
????
それは単にブランチを移動しただけでは????
0576デフォルトの名無しさん2014/09/08(月) 15:05:57.76ID:U7j04x7O
ブランチ移動といってもそのブランチのHEADになるからいいんでないの
0577デフォルトの名無しさん2014/09/08(月) 16:13:28.41ID:0SpwLnTc
そもそも>>543は単にブランチ移動したかっただけなんじゃないか
0578デフォルトの名無しさん2014/09/08(月) 16:36:32.50ID:dO+Fd23e
HEAD^とHEAD@{0}違う？
0579デフォルトの名無しさん2014/09/08(月) 16:49:04.96ID:dO+Fd23e
コミットを取り消したいからgit reset --hard HEAD@{0}ってやったのに戻らないから
git reset --hard HEAD@{1}ってやって{}の部分を2とか3とかいろいろやったらreflogがごちゃごちゃしてしまいました
一番最新のコミットに戻すにはreflogでHEAD@{番号}を調べる方法しかないですか？
0580デフォルトの名無しさん2014/09/08(月) 17:20:11.18ID:0SpwLnTc
>>579
最新のコミットを取り消すためにHEAD@{〜}とか使う必要無い
reflogを理解できてないのにHEAD@{〜}を使うなよ
その状態から元に戻すにはreflog見るのが簡単だけど
0581デフォルトの名無しさん2014/09/08(月) 17:33:52.09ID:K8Q6FwjA
>>579
HEAD@なんて表記やめてlog見て戻りたいところのハッシュ値で指定してやったら?
0582デフォルトの名無しさん2014/09/08(月) 17:40:52.81ID:dO+Fd23e
>>
0583デフォルトの名無しさん2014/09/08(月) 17:45:44.75ID:0SpwLnTc
自分も慣れてないころresetとかrebaseする前には git log --oneline の結果を数行コピペしておいたな
0584デフォルトの名無しさん2014/09/08(月) 17:48:49.27ID:dO+Fd23e
>>580
git reset --hard HEAD^を使えってことですね承知しました

>>581
git reset --hard HEAD@{3}
と
git reset --hard ハッシュ
で
同じ所には戻れたんですがここから最新のコミットに戻る方法がreflogから番号もしくはハッシュ調べてそれを
git reset --hard 番号orハッシュ
で最新に戻れるんですがHEAD@{番号}よりハッシュのほうがいいのは何か利点があるのでしょうか？
0585デフォルトの名無しさん2014/09/08(月) 17:55:56.63ID:0SpwLnTc
>>584
HEADいじる度にHEAD@{番号}が指すコミットは変わっちまうだろ？
おまえさんも>>579でごちゃごちゃになったと書いてるじゃないか
ハッシュが指すコミットはどんなにHEADをいじくり回しても変わらないから混乱しない
0586デフォルトの名無しさん2014/09/08(月) 18:12:44.41ID:dO+Fd23e
あああなるほど、わかりました
これからはハッシュでやります
0587デフォルトの名無しさん2014/09/08(月) 22:00:31.11ID:WRBqI71e
reflogを変えずにcheckoutがしたい、
0588デフォルトの名無しさん2014/09/08(月) 23:26:45.85ID:ndMr36Oi
HEADを直接弄ればいいんじゃね
0589デフォルトの名無しさん2014/09/08(月) 23:36:58.07ID:1ZckH/5F
やはりローカルにsvnの俺様リポジトリこさえて併用するのがベストだな
0590デフォルトの名無しさん2014/09/09(火) 00:18:50.36ID:u4zCVMc4
>>587
ブランチ名@{番号}の方ならcheckoutじゃ変わらんぞ
0591デフォルトの名無しさん2014/09/09(火) 22:34:56.56ID:qWpgvOTn
Git 2.1リリース
http://www.infoq.com/jp/news/2014/09/git21-release-whats-new
0592デフォルトの名無しさん2014/09/09(火) 22:38:42.96ID:SubzMxGE
2.1リリースから何日たってると思ってんだよノロマ
0593デフォルトの名無しさん2014/09/09(火) 22:53:14.21ID:gKfU6Dxq
msysgitのリリースはよ
0594デフォルトの名無しさん2014/09/09(火) 23:35:10.97ID:Q2wSWXGV
もう Cygwin でいいよ。
0595デフォルトの名無しさん2014/09/09(火) 23:57:07.76ID:6C8BCa3g
>>592
＞作者： Sergio De Simone , 翻訳者 笹井 崇司 投稿日 2014年9月8日
ノロマは笹井に対して言ってるんだよな？
0596デフォルトの名無しさん2014/09/10(水) 00:25:05.56ID:yTyA0sMk
msysgitってそんなに違うのか？
統合して欲しいが、どうなんだろ
0597デフォルトの名無しさん2014/09/10(水) 01:34:09.48ID:LZqJBGfN
Cygwin版はCygwin自体が最大の枷だわな
あれを枷と思わない人には良いのかも知れんが
0598デフォルトの名無しさん2014/09/10(水) 02:16:09.01ID:Kk1nHIci
>>595
自信満々にここに貼りつけた>>591==>>595に対してに決まってんだろ
0599デフォルトの名無しさん2014/09/10(水) 05:03:54.50ID:4LqmTc+v
windowsが枷
0600デフォルトの名無しさん2014/09/10(水) 07:06:01.73ID:SIxieRJp
他人に対する罵倒だと思い込まないと精神が死ぬ
0601デフォルトの名無しさん2014/09/10(水) 07:15:50.74ID:MqMxecSj
>>591==>>595だと思い込まないと精神が死ぬ
0602デフォルトの名無しさん2014/09/10(水) 09:56:29.50ID:av5QsdtA
>>593
同意

>>594
cygwin は捨てて良い

>>596
違う

>>597
同意

>>599
嫌なら使うなよ
0603デフォルトの名無しさん2014/09/10(水) 12:24:04.63ID:4LqmTc+v
>>602
俺はwindows使ってないよ
0604デフォルトの名無しさん2014/09/10(水) 13:39:34.62ID:UVf8c3/I
Cygwinが枷になってる人達はどんな環境でどんなプログラム言語使ってるのか気になる
コマンドプロンプトな環境で使ってたりするの？
0605デフォルトの名無しさん2014/09/10(水) 14:00:31.43ID:D/KQTinb
msysgitだとエクスプローラの右クリックメニューで色々できるからじゃね
0606デフォルトの名無しさん2014/09/10(水) 14:12:57.98ID:D/KQTinb
cygwinにgit入れてみたけど
msysgitのgit bashみたいに現在のブランチ名を表示するのってどうやんの？
0607デフォルトの名無しさん2014/09/10(水) 14:17:09.16ID:D/KQTinb
gitのコマンドやスイッチの補完もmsysgitのgit bashにはあるけど
cygwinでやる場合はこれらは自分でセットせにゃならんのかな
0608デフォルトの名無しさん2014/09/10(水) 14:19:48.68ID:D/KQTinb
msysgitのインストールフォルダにあるgit-prompt.shをそのまま持ってくればいいかな
0609デフォルトの名無しさん2014/09/10(水) 14:24:08.72ID:UVf8c3/I
>>606-607
bash-completionとgit-completionっていうパッケージが入ってれば補完されるかな
プロンプトはPS1を適当に設定すればいい
0610デフォルトの名無しさん2014/09/10(水) 14:59:27.04ID:D/KQTinb
補完はgit-completionで出来た
ありがとね
0611デフォルトの名無しさん2014/09/10(水) 15:11:10.16ID:D/KQTinb
gitkが起動しないし解決法探るの面倒草…
これさcygwinでgitやる場合は導入にかなり手間かかるね
msysgitでいいや
0612デフォルトの名無しさん2014/09/10(水) 15:19:14.08ID:/KH51cxp
cygwinは窓から捨てろ
0613デフォルトの名無しさん2014/09/10(水) 15:21:16.53ID:UVf8c3/I
使いこなせないならしょうがないな
0614デフォルトの名無しさん2014/09/10(水) 15:36:40.99ID:1paU2wgw
cygwinを使うならvirtualboxにlinuxを入れろ
cygwinの知識なんて何にも訳にたたねえよ
0615デフォルトの名無しさん2014/09/10(水) 15:59:36.12ID:D/KQTinb
それは手段が目的になってねえか？
Windows上で開発してるのをgitで管理するって話なんだから仮想環境にlinux構築する意味ねえし
たしかにCygwinはLinux使うより手間や面倒多いし、Cygwinはどうしてもって奴用の手段だな
git使いたいだけならcygwinよりもmsysgitかその他のWindows用gitクライアント使うのが一番いいな
0616デフォルトの名無しさん2014/09/10(水) 16:46:31.97ID:D/KQTinb
やっとCygwinでgitkを起動できたがやっぱmsysgitのほうがいいわ
0617デフォルトの名無しさん2014/09/10(水) 17:04:25.68ID:1paU2wgw
>>614
そうだよcygwin使いはcygwinを使うことが目的になってんだろ
0618デフォルトの名無しさん2014/09/10(水) 17:36:42.05ID:UVf8c3/I
>>614
Windows上で動かすIDEがgitコマンド使ってるんでWindows側で動いてないとダメなんだよ
それだけならmsysgitでもいいんだけど、msysgitには無いUnixコマンドも使いたかったりするんでCygwinになる

>>617
Cygwinにこだわってるわけじゃない
Windows上でなるべく制限の無いUnixコマンドが使いたいんだよ
バーチャルマシン上のLinuxや別のLinuxマシンにログインしたりもするがそれとは用途が違うんだ
0619デフォルトの名無しさん2014/09/10(水) 19:49:05.34ID:CyIX6v51
本日のあぼーん


↓
0620デフォルトの名無しさん2014/09/10(水) 19:59:56.78ID:XdlQkfFb
ここは俺たちの日記帳だ！
0621デフォルトの名無しさん2014/09/10(水) 20:25:18.54ID:OJY5gFsq
毎月このスレッドを作業記録として提出しましょう
0622デフォルトの名無しさん2014/09/11(木) 17:23:25.71ID:/FTCw4HW
msysgitのgit bashとCygwinのbashの違いはパス名で大文字小文字を区別するかしないかの違いがあるね
0623デフォルトの名無しさん2014/09/11(木) 17:27:15.91ID:SNUYrGFx
/cygdrive/c/hoge
と
/c/hoge
の違いもなかったっけ
0624デフォルトの名無しさん2014/09/11(木) 18:13:14.92ID:92Rqckl0
>>622-623
その辺はどちらも設定次第じゃない？
0625デフォルトの名無しさん2014/09/11(木) 18:54:51.03ID:/FTCw4HW
設定で変えられるかというより
大半がデフォルトの設定のまま使える
なるべく手間や面倒が省けるほうがいいっしょ
0626デフォルトの名無しさん2014/09/11(木) 19:12:18.48ID:92Rqckl0
それだったら「デフォルト設定に違いがあるね」って最初から書こう
0627デフォルトの名無しさん2014/09/11(木) 21:40:05.41ID:eOvHxe0S
2.2 ドラフト
0628デフォルトの名無しさん2014/09/13(土) 22:45:09.53ID:QgtGsY/0
デザインが決まらないので5個ぐらい作る場合
ブランチを5つ作るのか
master
design1
design2
design3
design4
design5

masterからサンプル用のブランチを作りそこにスケルトンのファイルを置いて、更にそこからブランチを5つ作って作業するの
master
|-design-sample
　|-design1
　|-design2
　|-design3
　|-design4
　|-design5

こんなふうに思いつきましたがどうやるのが一番いいですか？
0629デフォルトの名無しさん2014/09/13(土) 23:30:29.19ID:OGauqNqE
どっちでも一緒だと分かれば、さらに一歩git使いに近づいてる
0630デフォルトの名無しさん2014/09/14(日) 01:03:24.60ID:pOqGUkHF
ディレクトリを分けなくてよくなるわけではない
0631デフォルトの名無しさん2014/09/14(日) 01:05:48.64ID:hXoVPBM+
後者のやりかたのほうが俺は好きかな
masterを汚さずにやるから
0632デフォルトの名無しさん2014/09/14(日) 01:09:36.99ID:a/rqPd2y
>>631
どうやって前者の方法で
masterを汚すの？
0633デフォルトの名無しさん2014/09/14(日) 19:07:15.19ID:z5w391po
msysgitのgit bashやべえな
ファイル名の大文字小文字を変えるのを認識しやがらねえ
git mv file.txt File.txt
だと失敗
git mv file.txt file.txt.tmp
git mv file.txt.tmp File.txt
と二度やったらやっと登録できた
0634デフォルトの名無しさん2014/09/14(日) 19:09:37.99ID:a/rqPd2y
>>633
認識したら困るだろ。
cp a.txt A.txtってやったら、
A.txt （= a.txt） を削除してから、a.txtを読み取ってコピーすることになるんだぞ。
既に消されてるというのに。
0635デフォルトの名無しさん2014/09/14(日) 19:15:57.12ID:t5hepJjd
>>633
git mv -f file.txt File.txt
0636デフォルトの名無しさん2014/09/14(日) 19:53:01.69ID:/nrQFrnK
git mvって必要あるの？ファイルを移動したら勝手に追跡してくれるじゃん
0637デフォルトの名無しさん2014/09/14(日) 20:26:24.05ID:z5w391po
msysgitのgit bashだと普通に大文字小文字変えるだけではファイル名の変更が認識されないんだよ
File.txtに変えたのに内部ではfile.txtのまんま
>>633のようにgit mv２つを実行するとやっとrename file.txt -> File.txt と認識される、んでコミットすりゃ晴れて内部でもFile.txtになる
0638デフォルトの名無しさん2014/09/14(日) 20:33:58.96ID:t5hepJjd
>>636
git mv a.txt b.txt の代わりに mv a.txt b.txt すると、git add b.txt と git rm a.txt もしないといけないかな
0639デフォルトの名無しさん2014/09/14(日) 20:40:10.82ID:t5hepJjd
>>637
mv file.txt File.txt で変えてしまった後なら、
これでいい
git rm --cache file.txt
git add File.txt
0640デフォルトの名無しさん2014/09/15(月) 01:12:30.44ID:c0zpNvUD
共有(bare)リポジトリをDropboxに置く使い方があちこちで
紹介されていますが、リポジトリが壊れたりする危険性は
ないのでしょうか?
複数のcloneから同時にpushしたりしたら...
でも、ssh経由で共有する場合も同じような状況に
なりそうで、大丈夫だったりします?
0641デフォルトの名無しさん2014/09/15(月) 01:37:45.54ID:+Ldu6wso
dropboxが動いている時にファイルを更新したら最新ファイルがアップロードされなかった事があったから
dropbox起動中はgitの操作をしないほうがいいかもよ
0642デフォルトの名無しさん2014/09/15(月) 01:45:31.18ID:75pLEfoa
Dropboxが怖いなら無料のリポジトリサービスでも使えばいいだろＪＫ
0643デフォルトの名無しさん2014/09/15(月) 05:02:51.46ID:9UWhhSIJ
>>640
複数の場所で共有していると壊れるだろうね。

AとBの両方で作業したら
新しい方のファイルで更新されるし。
0644デフォルトの名無しさん2014/09/15(月) 08:54:23.82ID:fTGIYQla
>>633
ファイルシステムとそのAPIに文句を言うべきかと
0645デフォルトの名無しさん2014/09/16(火) 21:22:17.79ID:gF8SSz86
objectsの下のファイルがそろってさえいれば、headsは衝突してもどうにかなるんでは〜
0646デフォルトの名無しさん2014/09/17(水) 19:31:27.50ID:3n4VSMqM
Dropbox で bare リポジトリ共有って、そもそも開発者1人が前提なんじゃないんかね

Dropbox 上で安全にやるなら、公開個人リポジトリ＆中央リポジトリ管理者方式で
管理者が手動プルリクもどき頑張る、みたいなやり方かね
この場合のプルリクって、「僕のリポジトリクローンして○○ブランチを中央の master ににマージしてください」とかメール出すやつ
0647デフォルトの名無しさん2014/09/17(水) 21:31:10.41ID:nOBr1X2H
一時期複数人でDropbox&bundleやってた
これなら衝突は問題無いはずだけど操作が面倒で結局サーバーたてた
0648デフォルトの名無しさん2014/09/17(水) 21:46:44.89ID:bNvg7Npd
pushするときにロックファイルがあればpush失敗させればいいよ
フック書けばどうとでもできる
0649デフォルトの名無しさん2014/09/19(金) 19:31:27.86ID:PrP397Gb
gitのpost-commitフックを用いてjenkinsのビルドを開始させようとしました。しかし、post-commitに

wget -O nul http://localhost:8080/jenkins/job/<;project name>/build

と書いて(<project name>は実際はプロジェクト名です)、commitをしたところ、

error: cannot spawn .git/hooks/post-commit: No such file or directory

と出て、jenkinsビルドが開始されません。
気になるのは、post-commitのパーミッションをgit bashでls -lで調べると、-rw-r--r--となっていて、
post-commitに実行権限がついていないことです。ただ、git bashで　chmod +x post-commit　としても、
実行権限をつけることができませんでした
(ただ、.git/hooksに移動して ./git-commit　とするとスクリプトが起動したので、git bashから実行権限の変更を確認できないということかもしれません。)
windowsにおけるアクセス許可は、どのユーザに対しても読み取りと実行は許可されています。

ちなみに、post-commitの中身を echo a にしても同様のエラーが出たので、post-commitの中身のスクリプトは関係ないと思います。

環境はwindows8 + 1.9.4.msysgit.1 + GNU Wget 1.11.4です

この現象の原因及び解決方法、またパーミッションの変え方などを教えて下さい。
0650デフォルトの名無しさん2014/09/20(土) 10:44:57.72ID:Xc99Cp2d
git statusをやるとファイルとディレクトリ名がでますが
ディレクトリの中に含まれているファイルとかも確認したい時はどうやるんですか？
0651デフォルトの名無しさん2014/09/20(土) 19:53:38.75ID:I6a2TTeN
ｌｓ -alR

ディレクトリの中に含まれているファイルのとかの何を確認したいの？
0652デフォルトの名無しさん2014/09/20(土) 20:05:43.56ID:W3bmv3cS
>>650
git status -u
0653デフォルトの名無しさん2014/09/21(日) 07:36:29.91ID:vYPwYIwQ
Git 2.1.1 リリース
https://github.com/git/git/releases/tag/v2.1.1
0654デフォルトの名無しさん2014/09/22(月) 12:56:54.30ID:/Ev3c58M
今までコミットしたときのnameとemailを書き換えたいんですがどうやれますか？
それが無理なら１からリポジトリ作るしかないですよね
0655デフォルトの名無しさん2014/09/22(月) 13:32:54.45ID:3YN9TFHL
>>654
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE%E3%81%AA%E3%83%84%E3%83%BC%E3%83%AB-%E6%AD%B4%E5%8F%B2%E3%81%AE%E6%9B%B8%E3%81%8D%E6%8F%9B%E3%81%88
> メールアドレスの一括変更
0656デフォルトの名無しさん2014/09/22(月) 13:35:46.03ID:xorcTHrm
歴史の捏造ニダ
朝日NHKの得意技ニダ
0657デフォルトの名無しさん2014/09/22(月) 13:36:02.21ID:3YN9TFHL
>>654
http://qiita.com/seamountain@github/items/d70216a5bc16a88ed932#1-3
0658デフォルトの名無しさん2014/09/23(火) 22:16:54.41ID:mVrPrFOF
Update draft release notes to 2.2
0659名無しさん2014/09/24(水) 17:04:03.73ID:Qh5bz0XT
Gitならgitlabが一番いいと個人的には思う
0660デフォルトの名無しさん2014/09/24(水) 17:07:19.80ID:27efG/Se
いきなり何の話よ
06616492014/09/24(水) 21:00:45.42ID:hKGm5mT1
>>649ですが自己解決しました。
post-commitのスクリプトの一行目に
#!/bin/sh
を追加したところ動きました(windowsなのでいらないと思っていました)
お騒がせしました。
0662デフォルトの名無しさん2014/09/24(水) 21:57:41.06ID:im18uCU9
>>661
＞error: cannot spawn .git/hooks/post-commit: No such file or directory
このエラーメッセージでググれば一番最初にヒットするのがmsysgitでも #! つけろだからな
0663デフォルトの名無しさん2014/09/28(日) 01:34:48.16ID:S3ctTNeN
git notesにtodoって書いたりする？
0664デフォルトの名無しさん2014/09/28(日) 01:42:50.80ID:RZX9lPG9
は？
0665デフォルトの名無しさん2014/09/28(日) 02:08:11.01ID:S3ctTNeN
msysgit使ってるんだけど
git notes add -m "〜"で書き込むとgit notes showでもちゃんと日本語で出るんだけど
-mを使わずvim起動して書き込むとgit notes showで日本語が出ず文字化け状態になる
git diffでも文字化けはするけど同じ状態
でもgit commitでは-mで書いてもvimで書いてもgit logやgit showでちゃんと日本語が表示される
この違いは何で？
0666デフォルトの名無しさん2014/09/28(日) 02:09:44.62ID:S3ctTNeN
gitkやgit guiでは日本語表示は問題ないんだけど
git bashだとShift_JISは相性悪かったりすんのかね
0667デフォルトの名無しさん2014/09/28(日) 02:13:08.66ID:S3ctTNeN
ちがうな
gitkだとgit notes -mで書いた日本語がnotesのコミット見ると文字化けしてる、git bashの逆だ
でもnotesをくっつけたコミットオブジェクトのコメント欄ではgit bash同様に文字化けしてない
0668デフォルトの名無しさん2014/09/28(日) 02:24:17.67ID:V6A0YAer
msysは知らんけど今時文字コードはutf-8で統一しとくものでは？
gitkの文字コードは、git config gui.encoding utf-8
0669デフォルトの名無しさん2014/09/28(日) 03:15:33.58ID:S3ctTNeN
どうもgit bash上で入力したものは(コードページは932なのに)全部utf-8になるみたいだね
謎なのは
git commitなどで起動するvimでの日本語入力はutf-8になるけど
git notes addで起動するvimでの日本語入力はShift_JISになってしまう

>>668
ソースコードにutf-8を使えないのでどうしようもない
0670デフォルトの名無しさん2014/09/28(日) 03:20:33.14ID:S3ctTNeN
nkfを導入してエディタをvimから別のに変更するしかないか
0671デフォルトの名無しさん2014/09/28(日) 03:26:58.26ID:Z+K69R8V
>>670
$ chcp.com 65001
でどうだろう
0672デフォルトの名無しさん2014/09/28(日) 03:28:15.63ID:L8CmCeM8
>>669
＞ソースコードにutf-8を使えないのでどうしようもない
SJISしか解釈しないソフト？
それとも社是？
0673デフォルトの名無しさん2014/09/28(日) 03:42:36.32ID:S3ctTNeN
>>671
うーん、それあんま関係ないと思う
コードページは932なのにutf-8の日本語文字は正常表示されるから
lessとかがShift_JISの日本語文字を<82>とかutf-8で該当コードがあるのはその文字で表示されるという感じ
gitkやgit guiはutf-8日本語文字のコミットコメントも、shift_jis日本語文字のソースコードもちゃんと日本語表示してくれるよ
問題は>>699で書いたとおり同じvimで編集されてるのに保存される日本語コードが異なるというのがちょっと気になったというかvimの設定を弄ればいいだけなんだろうけど

>>672
IDEおよびコンパイラがutf-8を認識できない
0674デフォルトの名無しさん2014/09/28(日) 03:49:03.75ID:S3ctTNeN
>>670の方策でFAのようだからスレ汚しスマソでおやすみ
0675デフォルトの名無しさん2014/09/28(日) 10:04:21.42ID:V6A0YAer
>>669
ああ、そういうこと
C:\Program Files (x86)\Git\share\vim\vimrcに次のような行があるはず

autocmd BufReadPre COMMIT_EDITMSG,git-rebase-todo setlocal fileencodings=utf-8

これでCOMMIT_EDITMSGとgit-rebase-todoを編集するときはutf-8になる。それ以外のファイルはShift_JIS
ここか自分のvimrcにNOTES_EDITMSGを足しておけばよい
あとはMERGE_MSGも足しておいた方がよさそう
0676デフォルトの名無しさん2014/09/28(日) 12:17:40.34ID:HJquXbDq
windowsはコマンドの引数にUTF-8の文字列を渡すと正しく受け取れない
標準入力で渡せば問題無い
0677デフォルトの名無しさん2014/09/28(日) 12:23:04.07ID:/z7vQ2zP
その手があったか！(bar)
0678デフォルトの名無しさん2014/09/28(日) 12:34:35.51ID:5eGkIoPA
cygwin使えよ
0679デフォルトの名無しさん2014/09/28(日) 14:59:33.29ID:urGSMMdQ
msysgitのgit notesだけiconvが機能してない
0680デフォルトの名無しさん2014/09/28(日) 15:46:18.48ID:urGSMMdQ
$ iconv -f sjis -t utf-8 source.file | cat
0681デフォルトの名無しさん2014/09/28(日) 16:00:23.77ID:urGSMMdQ
もしくは
$ cat source.file | iconv -f sjis -t utf-8 | iconv -f utf-8 -t sjis
0682デフォルトの名無しさん2014/09/28(日) 16:13:34.60ID:urGSMMdQ
コードページ932のmsysgitのgit bash(mingw32)上で
sjisで書かれたsource.fileを
$ cat source.file
とすると文字化け
$ iconv -f sjis -t utf-8 source.file | iconv -f utf-8 -t sjis
とすると正しく表示
>>680-681の方法を取ればcatやlessなどでsjisのファイルを渡しても正しく表示される
0683デフォルトの名無しさん2014/09/28(日) 16:22:01.64ID:urGSMMdQ
コードページ932のmsysgitのgit bash(mingw32)上で
utf-8で書かれたsource.fileを
$ cat source.file
とすると正しく表示
$ iconv -f utf-8 -t sjis source.file
とすると正しく表示
$ iconv -f utf-8 -t sjis source.file | iconv -f sjis -t utf-8
とすると文字化け

catの出力をパイプやリダイレクトで拾っても文字コードが変換されているわけではない(当然のことだが)
catからの標準出力を受け取るmingw32がutf-8をsjisに変換しているのだろうか？しかしそれではiconvの出力と整合性がとれない
0684デフォルトの名無しさん2014/09/28(日) 18:51:05.51ID:O58wbOXV
>>675でFA
0685デフォルトの名無しさん2014/09/29(月) 12:35:23.79ID:AsmfGn0v
一応、git-bashもShellshockアウトだな
0686デフォルトの名無しさん2014/09/29(月) 12:50:04.02ID:PkV280SH
やはりな
0687デフォルトの名無しさん2014/09/29(月) 15:44:57.22ID:yq8evElj
Windows版EmacsのVCでgitを使ってると-mでコミットメッセージを渡すから
utf-8でメッセージを書くとおもいっきりログが化ける

で原因を探っていったら>>676に行き着いた
自前で引数の内容をダンプするexeを作ってutf-8の日本語を渡して確認した
結局どうにも行かずに、VCのコミット部分を改良して標準入力で渡すようにして解決した

もう少し詳細が知りたい人がいたら続き書く
0688デフォルトの名無しさん2014/09/29(月) 19:14:19.81ID:WBYZ6MwM
msysGit 使ってるけど UTF-8 で全然問題ない
0689デフォルトの名無しさん2014/09/29(月) 19:21:36.88ID:yq8evElj
>>688
参考までにどういう手順(使ってるシェルとか)でコミットメッセージを書いてるか教えてくれ
0690デフォルトの名無しさん2014/09/29(月) 19:30:25.36ID:DImY60Do
半角英数記号だけにして日本語を使わなければWindowsだろうとエンコード関係なくて無問題
0691デフォルトの名無しさん2014/09/29(月) 22:14:27.58ID:pB5pThCu
msysgitでShift JIS運用してる奴けっこういるんだなあ

ファイルの中身
コミットメッセージ
ファイルパス

この辺全部Shift JISに統一してるの？すげー危なっかしいんだけどｗ
0692デフォルトの名無しさん2014/09/29(月) 22:44:47.36ID:0qyZ7Y3Q
nihongo
0693デフォルトの名無しさん2014/09/30(火) 13:57:13.53ID:CMcuQWVl
ファイル経由だと問題ない
0694デフォルトの名無しさん2014/09/30(火) 14:38:49.81ID:slTS89tz
Git for Windowsがバージョンアップでやっと2.0かなとおもったらshellshock対策だったでござる
0695デフォルトの名無しさん2014/09/30(火) 15:05:01.92ID:GTUBo0R8
じらしやがる
0696デフォルトの名無しさん2014/10/01(水) 08:57:22.72ID:0Rd3PZj2
Git 2.1.2 リリース
https://github.com/git/git/releases/tag/v2.1.2
0697デフォルトの名無しさん2014/10/01(水) 19:15:25.68ID:DMZSGVKB
今書いてるコードを失敗作だったから特定のコミットまで戻ってコードを書きたい場合は
git checkout ハッシュ
でいいですか？
0698デフォルトの名無しさん2014/10/01(水) 19:27:03.97ID:9jQnFvsv
そんな質問よりも、ここで失敗作という単語を選ぶそのセンスに興味がある
0699デフォルトの名無しさん2014/10/01(水) 20:24:46.22ID:Z2lIlKnF
失敗も含めて記録です
0700デフォルトの名無しさん2014/10/01(水) 20:33:58.26ID:tKVi5+VE
>>697
ブランチをどんな風に使ってるかによる
0701デフォルトの名無しさん2014/10/01(水) 20:47:35.90ID:T6Ti1llJ
checkoutじゃなくてresetじゃね？
0702デフォルトの名無しさん2014/10/01(水) 21:21:20.45ID:tKVi5+VE
適当にブランチ作ってコード書いてるときは俺だったらこうするね
git checkout -b 新しいブランチ名 ハッシュ

git checkout ハッシュ の後に git checkout -b 新しいブランチ名 でもいい
0703デフォルトの名無しさん2014/10/01(水) 22:41:43.10ID:h9BOR5vi
どこにもpushしてない前提なら

git mv バックアップ名
git checkout -b 元のブランチ名 HASH

でとりあえず失敗作も取っておく
0704デフォルトの名無しさん2014/10/01(水) 22:45:53.29ID:2NEK614A
CUIでgit使ってる人に聞きたいんだけど
ハッシュって直接タイプしてる？コピペ？
0705デフォルトの名無しさん2014/10/01(水) 23:17:33.05ID:ZUQc71vZ
>>703
なんでpushしたらの前提なのかおしえてください
0706デフォルトの名無しさん2014/10/01(水) 23:22:06.58ID:FCLAwuTf
pushしてないなら、ね。
pushしてしまったブランチ名を変えてしまうと、後でわかりにくくなるから。
だからpushしてあるなら、今作業中のブランチはそのままにして、新しいブランチ名で作業開始するなあ。
0707デフォルトの名無しさん2014/10/03(金) 00:32:08.85ID:oFcsBg9c
Your branch is ahead of 'origin/test' by 2 commits.
(use "git push" to publish your local commits)
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

modified: test.txt

コミットしたのにgit statusでこういうふうに出ました
test.txtがコミットされてないってことですか？
0708デフォルトの名無しさん2014/10/03(金) 01:07:29.08ID:lJ+fGULR
>>707
addでステージングしてない、
またはステージングしたあとに変更されて、ステージとワークの差分が残った。
commit -aしたら。
0709デフォルトの名無しさん2014/10/03(金) 01:46:23.01ID:tlslc8rS
gui使え捗る
0710デフォルトの名無しさん2014/10/03(金) 06:37:37.72ID:uoUrCJpL
この辺のGitの動きを知らなかったらUI関係なく使い物にならん
0711デフォルトの名無しさん2014/10/03(金) 19:52:57.55ID:0fNFd6Zz
Changes to be committed: ならaddはされてるんじゃ？
0712デフォルトの名無しさん2014/10/03(金) 21:49:40.10ID:AgIiHhZF
>>704
とりあえず先頭5文字ぐらいタイプして一意じゃなかったらコピペかな。
0713デフォルトの名無しさん2014/10/03(金) 22:01:30.75ID:lJ+fGULR
>>711
ファイルをaddするんじゃない、差分をaddするんだ。
0714デフォルトの名無しさん2014/10/03(金) 22:41:09.35ID:bwpHkU5/
そんなあなたにはMercurialがオススメ
0715デフォルトの名無しさん2014/10/04(土) 15:44:59.48ID:SmsUE6ND
add驚く
0716デフォルトの名無しさん2014/10/04(土) 15:55:57.79ID:klU9cMDD
あ？
0717デフォルトの名無しさん2014/10/04(土) 18:48:11.03ID:lz81iwIl
内藤やるやんwwwwwwww
0718デフォルトの名無しさん2014/10/04(土) 19:52:27.34ID:UfGxrzJu
>>707
それまさにコミット直前の状態。
多分コミットしようとしたときに何かエラーが起きて失敗してる。
git log で確認するべし。
0719デフォルトの名無しさん2014/10/06(月) 13:34:47.78ID:+251wIR0
git mv old.txt new.txt
してコミットした後に
一番最初にコミットした時のold.txtの内容をnew.txtに持ってきたい場合はどうやるんでしょうか？
0720デフォルトの名無しさん2014/10/06(月) 16:13:08.43ID:LCKE4ThM
gitのmvは古いファイル消して同じ内容の新しいファイル作るようなものだから
revertみたいな巻き戻し的な操作ではそういうのはできないんじゃないかなあ？
だからその最初のコミットのold.txtの内容でnew.txtを上書きしてコミットするしかないんじゃないの？

上書きするのはこんな感じかな
git cat-file blob 最初のコミットのハッシュ:old.txt > new.txt
0721デフォルトの名無しさん2014/10/06(月) 16:49:30.61ID:f7RfeMbE
コミットがold.txtファイル単体のものだったらrevertでnew.txtの内容がold.txtのものになったよ
戻したい時点のコミットに他のファイルもあると他のも戻されちゃうけど
0722デフォルトの名無しさん2014/10/06(月) 16:50:08.14ID:f7RfeMbE
こんな感じの
$ vim old.txt
$ git add old.txt
$ git commit -m "add old.txt"
$ vim old.txt
$ git commit -am "update old.txt"
$ git mv old.txt new.txt
$ git commit -m "rename old.txt -> new.txt"
$ git log --oneline
4c10412 rename old.txt -> new.txt
2144b77 update old.txt
6174740 add old.txt
$ git revert 2144b77
0723デフォルトの名無しさん2014/10/06(月) 16:59:08.86ID:LCKE4ThM
ためしてみた
たしかにrevertで新しいファイル名のまま中身だけ戻るわ
revertも元に戻すコミットを作るだけだから
mvのつながりさえ検知できるのなら、こんな芸当ができるってわけか
0724デフォルトの名無しさん2014/10/06(月) 21:01:02.75ID:5SQO2Mek
サブモジュールの循環参照ってありうる？
0725デフォルトの名無しさん2014/10/07(火) 11:51:46.80ID:bg20eE9e
gitを使ってnvmをインストールしたんですが
今入っているバージョンが0.16.1で最新版が0.17.2です
.nvmディレクトリでgit pullしたんですけど最新版になりません
こういうのってどうやってアップグレードするんでしょうか？
0726デフォルトの名無しさん2014/10/07(火) 13:48:31.25ID:42Rhg3Aa
>>725
そんなもんnodeのスレ行って聞けよ
やり方なんてリポジトリ次第だ
ちらっとREADME見る限りじゃ最新のタグをcheckoutする必要があるみたいだが
07277252014/10/07(火) 14:04:31.66ID:62qC9bSD
>>726
いやリポジトリの内容を最新にしたいんですよ
0728デフォルトの名無しさん2014/10/07(火) 14:18:40.49ID:42Rhg3Aa
>>727
pullすればリポジトリは最新になってるよ
でもリポジトリを最新にしただけじゃディレクトリに展開されるファイルが最新になるわけじゃないんだよ
デフォルトのmasterブランチが最新とは限らないし
どのブランチやタグが最新の内容を指してるかとか
どうやって最新のブランチを使うべきかとかはリポジトリ依存
0729デフォルトの名無しさん2014/10/07(火) 19:45:20.87ID:Z7Aoevpe
あー初心者垢からしか評価こないんじゃーぬるぽ
0730デフォルトの名無しさん2014/10/11(土) 00:02:08.18ID:Yf2b8D8g
>>552
過去に編集したファイルを確認したいんですがこういう時ってどうやって戻るんでしょうか？
ブランチはmasterしか使用していません
0731デフォルトの名無しさん2014/10/11(土) 00:53:01.04ID:Rdrw9x2+
>>730
SourceTree
0732デフォルトの名無しさん2014/10/11(土) 08:27:23.90ID:cLKjQNHa
今Aというbranchをcheckoutしていて、別のBというbranchをAと同じcommitに持って来たいとき
こんな風にしてるけど、

$ git checkout B
$ git reset --hard A

最終的に作業ツリーの中身は作業前と同じになるけどタイムスタンプだけ変わってしまう。
作業ツリーに触らずに同じことをできないかな？
0733デフォルトの名無しさん2014/10/11(土) 08:42:35.63ID:Rdrw9x2+
>>732
zipで固めておくとか。

マジレスすると、そんな細かいことは気にしないのがgitを快適に使う秘訣だと最近気づいたよ。
0734デフォルトの名無しさん2014/10/11(土) 08:50:58.68ID:1vz5EW/S
>>732
git branch -D B
git checkout -b B
とかじゃダメなの？
0735デフォルトの名無しさん2014/10/11(土) 08:54:32.95ID:OrDwN+4S
タイムスタンプなんてチェックアウトするたびに変わるんだからどうしようもない
0736デフォルトの名無しさん2014/10/11(土) 08:57:40.41ID:8zrlM+r5
gitを改造すればいいじゃん
0737デフォルトの名無しさん2014/10/11(土) 09:00:59.26ID:u8e8Yi+s
ホントになあ
reset --hardだと部分的に元に戻すことができないからcheckout HEAD (ディレクトリ名)を使ったら
変更が無くても指定したディレクトリ以下全部作り直されるし

でも>>732のケースは>>734か、git branch -f B Aでいいと思う
0738デフォルトの名無しさん2014/10/11(土) 09:18:27.51ID:cLKjQNHa
>>737
ありがとう、バッチシです。
本来必要ないリビルドで何分も待たされるのをずっと我慢してた。
0739デフォルトの名無しさん2014/10/11(土) 09:27:25.81ID:1gHC+Rt5
>>731
それ使えません
linuxで定番ありますか？
0740デフォルトの名無しさん2014/10/11(土) 10:23:56.57ID:8zrlM+r5
percol と スクリプトと p4merge で過去差分を見るツール作った
0741デフォルトの名無しさん2014/10/11(土) 14:24:23.48ID:Rdrw9x2+
>>739
Linux用GUIクライアントのおすすめはSmartGit/Hgとgitgってのがあるらしい。
使ったことないけど。日本語がちゃんと使えるといいね…。
http://softwarerecs.stackexchange.com/questions/292/gui-for-git-and-mercurial-on-linux-similar-to-atlassian-sourcetree
0742デフォルトの名無しさん2014/10/11(土) 16:07:33.78ID:+RfzhL5s
>>730
普通に git checkout ハッシュ でいいのでは
戻りたい地点はgit logで知らべる
0743デフォルトの名無しさん2014/10/11(土) 16:12:33.60ID:aOjCrPms
gitbookくらい一通り読んでくればいいのに不精な人が多いんだなあ
0744デフォルトの名無しさん2014/10/11(土) 16:41:25.60ID:9AEIvNa2
>>742
そうするとブランチが
0745デフォルトの名無しさん2014/10/11(土) 17:41:24.23ID:1vz5EW/S
ブランチがなんだよ
とりあえず見るだけならエディタやIDEの機能を使うのがいいと思うんだが何使ってるんだ？
コマンドラインからでいいならとりあえずこれで見れる
git cat-file blob ハッシュ:ファイルのパス | less
じっくり見たいなら自分のリポジトリをcloneしてしまってもいい
0746デフォルトの名無しさん2014/10/11(土) 18:13:32.74ID:6HL2TmPS
>>730
git show $version:$filename
とかいうこと?
0747デフォルトの名無しさん2014/10/11(土) 18:41:13.11ID:N8j8zGao
過去のリビジョンに戻る時にgit checkoutはやるべきではない
git reset を使うべきだ
0748デフォルトの名無しさん2014/10/11(土) 18:50:18.29ID:0tst77Z4
過去のリビジョンをチェックアウトする時がcheckoutで
過去のリビジョンまでコミットを戻すのがresetだろ。

ぜんぜん違うものだって。そんな違いもわからんの？
0749デフォルトの名無しさん2014/10/11(土) 19:08:30.34ID:aOjCrPms
作業ファイル一式を入れ替えるのがcheckout
resetはブランチが参照するコミットを変更するのが主目的
0750デフォルトの名無しさん2014/10/11(土) 19:09:00.88ID:aOjCrPms
ブランチじゃねえHEADだ
0751デフォルトの名無しさん2014/10/12(日) 07:03:10.69ID:oWlxOy9Q
この辺よく分かってないんだけど、--hard リセットはresetとcheckoutを同時にやるって事なのかな？
0752デフォルトの名無しさん2014/10/12(日) 10:38:52.27ID:p0nnbQFv
checkoutは引数次第でいろんなことをするから
「checkoutをする」だけ言われても何を意図してるのかわからん
0753デフォルトの名無しさん2014/10/12(日) 11:52:33.48ID:e6aIROEn
>>752
>>730
0754デフォルトの名無しさん2014/10/12(日) 12:23:19.27ID:p0nnbQFv
>>753
過去に編集したファイルを見るためにcheckoutを使うとしても、
「過去のハッシュ」を指定してcheckout以外にも
「過去のハッシュ:ファイル名」を指定してcheckoutするとかでも見れるのはわかるよな？
前者はカレントブランチが変わってしまうけど、後者はそのままだ
0755デフォルトの名無しさん2014/10/12(日) 12:54:05.07ID:sOwm7/3X
linuxで過去の状態のファイルが見たいんなら，tigもいいと思うんよ
0756デフォルトの名無しさん2014/10/12(日) 14:10:40.60ID:IX57hp7+
featureブランチとかtopicブランチってあるけど
英和辞書のfeatureやtopicだと意味が分からん
gitではどういう意味で使われてるん？
0757デフォルトの名無しさん2014/10/12(日) 14:30:11.95ID:z1NIPMV8
機能と話題じゃねーの
0758デフォルトの名無しさん2014/10/12(日) 21:07:29.18ID:IX57hp7+
機能ブランチって特定の機能を作るってこと？
話題ブランチってちょっと意味が分からない
0759デフォルトの名無しさん2014/10/12(日) 21:27:26.08ID:N2wuPuuE
特定の機能を追加するっていうトピック・話題・テーマ、特定のバグを潰すってトピック
0760デフォルトの名無しさん2014/10/12(日) 21:34:18.14ID:z1NIPMV8
両方トピックじゃねーか！
間違ってはいない
0761デフォルトの名無しさん2014/10/13(月) 10:39:05.48ID:UiUWyauZ
masterブランチでgit merge fixを実行して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 statusを実行すると
On branch master
Your branch and 'origin/master' have diverged,
and have 153 and 1 different commit each, respectively.
(use "git pull" to merge the remote branch into yours)
nothing to commit, working directory clean

助けてくださいどうしたらpushできますか？
0762デフォルトの名無しさん2014/10/13(月) 11:05:19.89ID:Ka1C2n0c
$ git checkout master
$ git branch testtest origin/master
$ git rebase testtest
$ git push origin/master

これでどうよ？
0763デフォルトの名無しさん2014/10/13(月) 11:11:11.28ID:UiUWyauZ
すいません誰もいないと思って先走ってgit pullしたらコンフリクトしました
ありがとうございます
0764デフォルトの名無しさん2014/10/13(月) 13:47:51.26ID:yFRqmPNp
自分のところとコンフリクトしてんじゃね
0765デフォルトの名無しさん2014/10/13(月) 23:03:04.45ID:0GIv1UTW
あとはコンフリクトを解決すればOK
0766デフォルトの名無しさん2014/10/14(火) 10:26:22.58ID:8E9fzGhm
tortoiseGitでローカルにコミットしても
赤！アイコンが消えないでござる
0767デフォルトの名無しさん2014/10/14(火) 14:50:34.16ID:a754JoyQ
git branch feature/aaaみたいにスラッシュ区切りのブランチを見かけますが
これは何の意味があるんですか？
0768デフォルトの名無しさん2014/10/14(火) 22:05:41.58ID:F0kchRkJ
featureって意味があるよ！
0769デフォルトの名無しさん2014/10/15(水) 06:17:23.46ID:t4MHvgx0
ふゅーちゃーってたしか機能って意味もあるからなんか特化した開発してるんじゃない？
0770デフォルトの名無しさん2014/10/15(水) 06:56:43.14ID:ZR9Ve6JZ
ふゅーちゃーはfuture(未来)、feature(機能、特徴)はふぃーちゃー。
0771デフォルトの名無しさん2014/10/15(水) 06:58:06.42ID:t4MHvgx0
おーそーりー。
0772デフォルトの名無しさん2014/10/15(水) 16:42:35.08ID:B8bsm/f7
>>767
利点は知らないけど
.git/refs/heads 内にディレクトリが作られる
SourceTreeみたいなGUIクライアントがフォルダとして扱ってくれるからとか？
0773デフォルトの名無しさん2014/10/20(月) 01:38:24.79ID:6j05cluu
こんな新刊でてた。
読んだ人評価よろ。

Gitで困ったときに読む本 (Programmer’s SELECTION) 大型本 – 2014/10/17
Wodzimierz Gajda (著), 長尾 高弘 (監修, 翻訳)
http://www.amazon.co.jp/dp/4798137138/

そろそろ入門書や解説書が増えてきたし、リスト付くってテンプレに入れたいね。
各書の寸評も入れて。
0774デフォルトの名無しさん2014/10/20(月) 02:46:47.42ID:gc0RlShe
2chにそんなものいらん
0775デフォルトの名無しさん2014/10/20(月) 06:21:53.91ID:8ZypDjIK
高杉
0776デフォルトの名無しさん2014/10/20(月) 08:41:42.03ID:ZbmD4P58
４００ページか・・・
イエローページって呼ぶわｗ
0777デフォルトの名無しさん2014/10/20(月) 09:20:28.20ID:Xd0rYRkq
宣伝成功！！！！
0778デフォルトの名無しさん2014/10/20(月) 10:27:00.91ID:9PaXcFMy
マインスイーパ？
0779デフォルトの名無しさん2014/10/20(月) 10:46:20.24ID:5bAFSmmu
何十円なら買えるんだよ
0780デフォルトの名無しさん2014/10/20(月) 12:12:25.60ID:4QGk34Ml
ジャンプなんか400ページ超えてて
300円しないというのに。
0781デフォルトの名無しさん2014/10/20(月) 12:29:43.87ID:6InD2oEn
イエローページならなんと！
0782デフォルトの名無しさん2014/10/20(月) 12:34:28.67ID:Ze8iUggo
>>780
つまりGitの擬人化漫画を描けば良いと？
0783デフォルトの名無しさん2014/10/20(月) 19:47:31.74ID:kEWHmjOP
ジットちゃん
0784デフォルトの名無しさん2014/10/20(月) 19:51:57.33ID:qTy0O4wa
沈黙待機系少女じっとタン
0785デフォルトの名無しさん2014/10/20(月) 19:52:16.07ID:gc0RlShe
ツイッターで描いたら流行りそう
0786デフォルトの名無しさん2014/10/20(月) 20:56:25.96ID:ZbmD4P58
じっとタン「push・・・来ない・・・」
0787デフォルトの名無しさん2014/10/20(月) 22:31:36.94ID:wK6yDOM4
ジットじゃなくギットだとおもいまーっす
0788デフォルトの名無しさん2014/10/20(月) 22:52:41.69ID:aZfIvSfB
俺的にはジットの方が近いな。
何が正しいかといえばgitだろう。
0789デフォルトの名無しさん2014/10/20(月) 23:02:37.46ID:KfYW9NVG
gif(ジフ)、git(ギット)一貫してない！
でググってみたら、元の発音もそもそも一貫してないんだな

gifは本来はギフだろうが、設計者がjif(ジフ)が正しいと言ったようだ
0790デフォルトの名無しさん2014/10/20(月) 23:02:39.90ID:qTy0O4wa
>>786
イイねb

>>787
ふたご設定とか？
0791デフォルトの名無しさん2014/10/20(月) 23:09:30.25ID:kEWHmjOP
テーマ曲は「ギットギトにしてやんよ」
0792デフォルトの名無しさん2014/10/20(月) 23:10:23.03ID:qTy0O4wa
脂っぽくてヤダー。Orz
0793デフォルトの名無しさん2014/10/20(月) 23:12:25.78ID:gc0RlShe
バイキンマンポジで
0794デフォルトの名無しさん2014/10/21(火) 01:05:27.81ID:MKkuO4Nj
「ギットギトにしてやんよ」だったら、脂性でギットギトのデブオタが丁度いい
0795デフォルトの名無しさん2014/10/21(火) 01:07:53.10ID:dWXgLBxs
WindowsのOSが萌えキャラ化されたから
バージョン管理ソフトも萌えキャラ化される日も近いかもな
GITちゃんSVNちゃんCVNSちゃんHGちゃんBZRちゃん
0796デフォルトの名無しさん2014/10/21(火) 01:12:09.79ID:98IF0d26
VSSちゃん「ぶ・・・ぶっす・・・」
0797デフォルトの名無しさん2014/10/21(火) 01:31:49.82ID:rLdpxu5/
デザイナーもバージョン管理ソフト使ってるんだから誰かやってそうな気もするけど無いのか
0798デフォルトの名無しさん2014/10/21(火) 06:13:36.21ID:ndQNY/8a
作者がぎっとだと明言しとる
0799デフォルトの名無しさん2014/10/21(火) 08:12:10.54ID:8oGIBXRE
>>789
ローマ字読みを｢本来｣とは言えないんじゃ…
でもなんとなく英語風に読もうと思えば
gifはジフ、gitはギットって読めると思うんだけどな
0800デフォルトの名無しさん2014/10/21(火) 10:00:13.51ID:OGY/NnRX
gをジーと読むからだろうけし、略語由来は読み方がいろいろ
giftはギフト
0801デフォルトの名無しさん2014/10/21(火) 12:09:20.75ID:LDDYL1oQ
gingerはジンジャー
0802デフォルトの名無しさん2014/10/21(火) 13:56:45.17ID:3SFXCOz9
magitは?
0803デフォルトの名無しさん2014/10/22(水) 03:30:24.61ID:NoApm9kp
テクニカルタームとしてJITが存在するのに、gitをジットと読むわけないだろ。
0804デフォルトの名無しさん2014/10/22(水) 08:38:44.29ID:sB6ga6u2
magicはマジック
magitはマギット
0805デフォルトの名無しさん2014/10/22(水) 09:49:48.53ID:CQ3LWgmB
gitってフィンランド語だっけ？
0806デフォルトの名無しさん2014/10/22(水) 11:17:33.32ID:yVOzWn6d
両手の指をピストルのように構え前に突き出して叫ぶんだ。「ギット！！」
0807デフォルトの名無しさん2014/10/22(水) 11:35:06.82ID:G2nqW3Ft
intelligence インテリゲンチャ
0808デフォルトの名無しさん2014/10/22(水) 15:36:23.51ID:1vGBv3op
働けど働けど　我が暮らし楽にならず
Git 手を見る
0809デフォルトの名無しさん2014/10/22(水) 15:47:47.36ID:kKncjr9Q
GitGitだった
0810デフォルトの名無しさん2014/10/22(水) 16:18:12.92ID:yVOzWn6d
Git君は来ない 一人きりのクリスマスイブ
0811デフォルトの名無しさん2014/10/22(水) 17:34:15.15ID:09vRtLa/
GitGitにしてゃんょ
0812デフォルトの名無しさん2014/10/22(水) 19:38:47.95ID:mh35NEK4
君たちリポジトリは何個ぐらい持ってますか？
0813デフォルトの名無しさん2014/10/22(水) 19:42:18.40ID:DBSwOXHr
40くらいかな。
0814デフォルトの名無しさん2014/10/22(水) 20:35:24.61ID:rV+YylK+
Gigaはギガ
Giganticはジャイガンティック
だから命名した人がこう読む、というのがなけりゃどっちの読み方が正しいかは英語では決まらないでしょ。
0815デフォルトの名無しさん2014/10/22(水) 21:15:08.52ID:9Jwqj8Ni
オーレーはジャキガーン、歌鬼大Show
0816デフォルトの名無しさん2014/10/23(木) 02:22:04.66ID:QsQhyUlJ
danger
0817デフォルトの名無しさん2014/10/23(木) 03:08:23.65ID:9xQ1BkMO
ダンゲア？
0818デフォルトの名無しさん2014/10/23(木) 06:51:15.76ID:QsQhyUlJ
anger
0819デフォルトの名無しさん2014/10/23(木) 07:47:48.13ID:I5sCFcB1
git 来る
0820デフォルトの名無しさん2014/10/23(木) 11:09:22.09ID:wVXZyphH
ちょっと git してろよ
0821デフォルトの名無しさん2014/10/23(木) 11:34:05.42ID:6plD894T
gitをgit見てました
0822デフォルトの名無しさん2014/10/23(木) 11:48:39.74ID:ISc0F2Qf
>>810
0823デフォルトの名無しさん2014/10/23(木) 11:51:26.14ID:c5DrjxEb
GIMPはギンプでほぼ統一されてるな。

JOJOは第5部だけGIOGIOだ。ザ行で発音するのはイタリア由来かね？
0824デフォルトの名無しさん2014/10/23(木) 12:16:58.01ID:q5HQpAt6
http://ja.wikipedia.org/wiki/GIMP
> GIMP（ギンプ、ジンプ、GNU Image Manipulation Program）は

って書いてあるのに、何を根拠に統一されていると
思ったの？
0825デフォルトの名無しさん2014/10/23(木) 12:51:10.62ID:ISc0F2Qf
GNU って何て読むの
0826デフォルトの名無しさん2014/10/23(木) 12:53:25.44ID:q5HQpAt6
じーぬ
0827デフォルトの名無しさん2014/10/23(木) 12:53:42.10ID:I+m4T/U6
reset,add,commit,remote,log,reflog,checkout,branck,clone,rm,mv
とりあえずこのコマンドだけ覚えれば複数人で開発する時は問題ないと思ってるんですけど他にもあれば教えてください
0828デフォルトの名無しさん2014/10/23(木) 12:57:46.69ID:q5HQpAt6
bisectが入ってないとは開発者とは思えないな。
0829デフォルトの名無しさん2014/10/23(木) 13:25:03.63ID:1sBnQq4K
>>825
グニュー(ニューはねちっこく)
0830デフォルトの名無しさん2014/10/23(木) 14:50:03.96ID:eDVkHXcG
branch の綴りを間違えるとはほんとに使ってるとは思えないな。
0831デフォルトの名無しさん2014/10/23(木) 14:51:39.25ID:d2dt+BtO
>>827
push、pull。
ルールによってはtag。
0832デフォルトの名無しさん2014/10/23(木) 16:49:47.11ID:DGTXOsmr
pullっていりますか
mergeとfetchのほうがいいんじゃないですか
0833デフォルトの名無しさん2014/10/23(木) 16:55:02.78ID:d2dt+BtO
>>832
好きにしろ。
どれも入ってなかったので、最も単純そうなものを入れておいただけだ。
0834デフォルトの名無しさん2014/10/23(木) 17:00:46.99ID:91hl1kT/
>>827
status
diff
0835デフォルトの名無しさん2014/10/23(木) 17:18:28.62ID:AJSC2eer
ぼっち開発で使って見ようと思うのだけどおすすめの運用教えてください
0836デフォルトの名無しさん2014/10/23(木) 19:00:05.17ID:49+zpQPL
git flow
github flow
gitlab flow
好きなのを選べ
0837デフォルトの名無しさん2014/10/23(木) 22:03:02.25ID:q5HQpAt6
>>827
blame、showが入ってない。最初だけだがinitもいるだろ。
複数人開発ならcherry-pickもつかうな。

>832
> pullっていりますか
> mergeとfetchのほうがいいんじゃないですか

mvっていりますか？ cpとrmだけでいいんじゃないですか？って
言ってるようなもの。

git pullだけで済むことをわざわざfetchしてmergeしているみると
毎回そんなことやってんのかな？って思ってしまう。
0838デフォルトの名無しさん2014/10/23(木) 22:09:56.33ID:q5HQpAt6
>>835
バージョン管理する意味をしっかり理解することだな。

単なるバックアップなら、バックアップソフトを使えばいいだけだよ。
バージョン管理のコミットというのは、
過去のコミットをチェックアウトする価値が有るように使わないといけない。

チェックアウトしても使いものにならないコミットは作らない
（一時的な作業用は除く）

コミットは過去の作業履歴じゃなくて、一つ一つが意味のある修正で
その一つを取り出して、このコミットでは何を変えたのかがわかるようにする。
0839デフォルトの名無しさん2014/10/24(金) 01:28:59.20ID:2TlSkpOq
ソースはwikipedia(笑)
0840デフォルトの名無しさん2014/10/24(金) 01:34:15.46ID:2TlSkpOq
GitHubの追跡しにくさてすげーよな
どんだけセンスのない奴ばかり集まればあれほど使いにくくなるのだろうか
0841デフォルトの名無しさん2014/10/24(金) 02:23:08.36ID:En8l5okm
んで使いやすいGitリポジトリサービスはどこよ？GitLab？bitbucket？
0842デフォルトの名無しさん2014/10/24(金) 08:51:59.42ID:agHk22KZ
>>840
twitter よりマシ
0843デフォルトの名無しさん2014/10/24(金) 12:56:07.98ID:UyJ9AldF
>>840
GitHubの追跡ってのがよくわからん。
そもそもあんたgit使って追跡できる？

git使って追跡できるんだから追跡に
GitHubにたよる必要はないはずなんだが。
0844デフォルトの名無しさん2014/10/24(金) 13:11:51.01ID:l44t8Ym7
CodeBreakがクソな理由＆使ってはいけない理由

・ソースコードに連絡先を書いてはいけない。WordPressのテーマファイルのように作者と連絡先を記載すると利用規約第12条違反となる。
0845デフォルトの名無しさん2014/10/24(金) 13:22:44.70ID:UyJ9AldF
http://codebreak.com/ja/contents/rules/

第12条 利用者の禁止事項
利用者は、本システムの利用に関して以下の行為をしてはならないものとします。
かかる行為によりビズリーチに生じた一切の損害について、利用者は賠償する責任を負担し、
ビズリーチは民事および刑事の一切の法的手段をとることができます。

ソースコードや個人情報等の情報およびその投稿に関する禁止事項
1. 悪意のあるプログラムその他のソースコードを配布または公開すること
2. 第三者の権利を侵害しまたは法令ないし公序良俗に反し、またはそのおそれのある情報を投稿すること
3. ソースコードに、自己または第三者の連絡先を記載または暗示すること
4. その他当社が不適切と判断する情報を投稿すること
0846デフォルトの名無しさん2014/10/24(金) 13:23:14.18ID:UyJ9AldF
その他一般的な禁止事項
1. 当社もしくは第三者の著作権、特許権、実用新案権、意匠権、商標権その他知的所有権を侵害し、またはそのおそれがある行為
2. 当社もしくは第三者の財産権、プライバシーもしくは肖像権その他の人格権を侵害し、またはそのおそれのある行為
3. 当社もしくは第三者を不当に差別もしくは誹謗中傷し、第三者への不当な差別を助長し、又はその名誉もしくは信用を毀損し、またはそのおそれのある行為
4. 自分以外の人物や組織（架空の人物や組織を含みます。以下同じ）を名乗ったり、代表権や代理権がないにもかかわらずあるものと装ったり、又は他の人物や組織と提携、協力関係にあると偽って本システムを利用する行為
5. 法令、公序良俗又は本規約に反し、またはそのおそれがあると当社が判断する行為
6. 当社もしくは第三者の権利を侵害し、またはそのおそれがあると当社が判断する行為
7. 面識のない異性または同性との性交、性交類似行為、わいせつな行為、出会い等を主な目的として利用する行為
8. 当社の業務運営を妨げると当社が判断する行為
9. 当社および本システムの信用を損ねるまたは損ねるおそれがあると当社が判断する行為
10. 本システムを通じて入手した情報を、複製、販売、出版、その他私的利用の範囲を超えて使用する行為
11. 正当な権限無く、利用者のシステム認証およびセキュリティの探求、本システムの非公開情報やアカウントにアクセスし、またはアクセスしようとする行為
12. 本システムの運営として当社が使用する当社又は第三者のサーバーに負担をかける行為、もしくは、本システムの運営やネットワーク・システムに支障、損害を与える行為、又はこれらのおそれのある行為
13. その他当社が別途禁止する行為
0847デフォルトの名無しさん2014/10/24(金) 21:06:13.80ID:RHs71UjF
>>841
Gitbucket
0848デフォルトの名無しさん2014/10/25(土) 00:20:51.78ID:jrmrNsb2
例えばあるcveに関する修正調べるだけの用で
プログラム自体に何の興味もねえのにいちいちクローンなんかしてられねえつーの
0849デフォルトの名無しさん2014/10/25(土) 00:22:20.70ID:SRh9eelG
GitHubの追跡にクローンの必要ないだろ、Watchにチェック入れりゃ更新がメールで届くし、スター付けるだけでもトップページで更新確認できるだろ
0850デフォルトの名無しさん2014/10/25(土) 11:25:50.96ID:baN3kQAe
>>848
Changelogみればいいだけじゃないの？

そんな表面で告知された内容じゃなくて
具体的にコードがどう変わったのか知りたいっていうのは、

もはや修正を調べるではなくて、ハードウェアで言えば
分解してチップが変わったかを調べるようなもので、
調べる技術は必要だと思うけどね。

つまりあんたは技術者なのに技術がないっていうこと。
0851デフォルトの名無しさん2014/10/25(土) 11:49:41.62ID:iDGC2gg+
branch前（幹の部分）にコミットを追加したら、
branchにもそのコミットが反映されるかとおもったらそうではなかった。
(rebase -iでmasterの最新のコミットを幹の部分に入れ込んだ)

branchの親を付け替えることができればよさそうですが、
そのようなことはできますか？
08528512014/10/25(土) 12:00:16.99ID:iDGC2gg+
>>851の追加です。
あるいはこういう場合、
全branchに、cherrypickで同じコミットをあてていくべきなんでしょうか？
0853デフォルトの名無しさん2014/10/25(土) 12:12:14.07ID:baN3kQAe
よくわからんけど、ontoかいな。
0854デフォルトの名無しさん2014/10/25(土) 12:37:04.05ID:OsyjfeG2
>>852
分岐前のbranchを分岐後のbranchにマージ
あるいは分岐後のbranchを分岐前のbranchに対してrebase
0855デフォルトの名無しさん2014/10/25(土) 13:17:24.15ID:Nj8R3giM
なんとかフローに従っていればチェリーピックとか使う必要ないよね
0856デフォルトの名無しさん2014/10/25(土) 13:39:02.31ID:iDGC2gg+
もう少しわかりやすく書いてみました。
A-B-C(a)
B-D(b)
(Bが分岐点)

この状態から
A-B-C-E(a)
としたのですが、Eがbにも必要なことがわかりました。

rebase -iで
A-E-B-C(a)
としたら、Bから分岐してるbにもEが適用されてると思ったのですが、
A-E'-B'-C'(a')
となったようで、aを修正したつもりが単にa'を作ってしまったようになり、
bにはEが適用されないままとなってます。

実際にはbのようなとブランチがもっとある状況です。

>>853
ontoで、Dの親をB'にしてしまえばよさそうですが、
これもb'ができてしまいそうで、bが複数分岐していた場合、その枝も付け直すひつようがありそうです。
>>854
不慣れでマージがまだ理解できてません。2番目は>>853と同じでしょうか。

分岐点より前のものにコミット変更やると、どうしても分岐点後の各ブランチとは別歴史となってしまいそうな気がしてきました。
0857デフォルトの名無しさん2014/10/25(土) 14:13:41.92ID:tjXcLkh9
リベースしたら変更したコミット以降全部再作成されるから当然のこと
0858デフォルトの名無しさん2014/10/25(土) 14:23:33.80ID:OsyjfeG2
> 分岐点より前のものにコミット変更やると、どうしても分岐点後の各ブランチとは別歴史となってしまいそうな気がしてきました。

その通り。rebaseはそのブランチの歴史改変。別ブランチには影響しない。

> これもb'ができてしまいそうで、bが複数分岐していた場合、その枝も付け直すひつようがありそうです。

これもそう。
なので普通は別ブランチの変更を取り込むときはmergeする。
0859デフォルトの名無しさん2014/10/25(土) 14:26:53.51ID:baN3kQAe
>>856
コミットIDなどと言ったりするから勘違いされやすいと思うが、
IDというのはそのコミットに対する番号ではなくて、
過去の歴史すべての情報を含んでいるんだよ。

あるIDとあるIDが同じであれば、
過去の歴史も全て一緒になる。
0860デフォルトの名無しさん2014/10/25(土) 20:54:32.21ID:rEnLKs1o
>>859のいうIDって何のことだ？
0861デフォルトの名無しさん2014/10/26(日) 00:39:38.99ID:KYTvr3GZ
848だけどさ
Changelog見たかったんだけどな
存在しなかったんだよね
リリースノートも更新されてないしね

それがぺちぱーというタイプの生き物なんだよ
08628482014/10/26(日) 11:01:41.57ID:MKtCgGPk
>>861
私になりすまして、私のレスをPHP叩くネタにしないでくれませんか？
根性ねじ曲がっていますね。
0863デフォルトの名無しさん2014/10/26(日) 12:54:04.01ID:dbycS4MG
>>837
そこはcpじゃなくてlnだろ
0864デフォルトの名無しさん2014/10/26(日) 13:44:32.29ID:E7QfrGU+
まあそこまで厳密に考えなくてもｗ
0865デフォルトの名無しさん2014/10/26(日) 22:30:45.78ID:KYTvr3GZ
頭の悪いぺちぱーがなりすましかよ(笑)
0866デフォルトの名無しさん2014/10/26(日) 23:34:05.33ID:Uxx8sszV
なぁ
リモートのmasterをローカルにcloneするやん？
自分の作業をするためにローカルにブランチ作ってcheckoutするやん？
したら修正とかやってコミットしよんよ
んでどないすんの？
オレオレブランチをリモートのmasterにあげたいんや
0867デフォルトの名無しさん2014/10/26(日) 23:59:51.36ID:KYTvr3GZ
権限と許可あるなら押せば〜
ないなら差分送りつけるなり
そいつらの流儀に従え
0868デフォルトの名無しさん2014/10/27(月) 01:18:10.93ID:KfSASuUC
他人のリポジトリ好きにしたいとか頭おかC
0869デフォルトの名無しさん2014/10/27(月) 02:25:43.24ID:dBZ7xcRa
元のmasterを自分のアカウントでfork
その修正したbranchを自分のforkしたリポジトリにpullrequest
自分のリポジトリのbranchを元のmasterにpullrequest
0870デフォルトの名無しさん2014/10/27(月) 04:14:33.93ID:XzKSKrvp
リモートという言葉が他人のリポジトリを指すわけではないのに他人のリポジトリと決め付けて話をすすめるエスパーたち
0871デフォルトの名無しさん2014/10/27(月) 04:28:32.43ID:BepvCTPK
>>870
自分のなら>>867の1行目で話終わってるだろ。それ以外の場合は多岐に渡るため、いろいろ補足が出てるんだろ。
0872デフォルトの名無しさん2014/10/27(月) 09:13:57.19ID:3pkGW4w9
なんで？
0873デフォルトの名無しさん2014/10/27(月) 09:42:13.06ID:wK4QYAC1
自分のリモートなら push
0874デフォルトの名無しさん2014/10/28(火) 00:53:31.06ID:mFnj7HRR
commitするまえにgit diffで表示される内容を
commitした後に見る方法をおしえてください
0875デフォルトの名無しさん2014/10/28(火) 01:05:28.82ID:2moDL6+C
>>874
これか?

http://qiita.com/hide/items/17b970c485e803cbce08
>直前の commit による変更を表示
>
>git diff HEAD^ HEAD
>
>HEAD と HEAD^ の差分を表示するコマンド。
>commit 直後によく実行する。
0876デフォルトの名無しさん2014/10/28(火) 01:21:14.87ID:mFnj7HRR
ありがとうございますそれです
0877デフォルトの名無しさん2014/10/28(火) 07:47:04.20ID:3xBkNC1k
>>874
git show
0878デフォルトの名無しさん2014/10/28(火) 23:54:47.08ID:sTktv/Nl
Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール
http://www.amazon.co.jp/dp/4844337009/

なぜかWeb製作に特化した本。普通の入門書はそろそろ飽和気味でこういう
毛色が変わったのがでてくるようになったのか。
そろそろブームも終焉かな。
0879デフォルトの名無しさん2014/10/28(火) 23:57:58.88ID:Hn3G7vVN
ｵﾏｴの人生が終焉
0880デフォルトの名無しさん2014/10/29(水) 08:37:02.36ID:VOgtiztz
どうせエボラ上陸したらみんな終焉
0881デフォルトの名無しさん2014/10/29(水) 15:17:52.51ID:yqIOJVFi
github flowにそってブランチ作ってマスターにマージしまくる場合って
過去に作ったブランチ名を何度も使うのはやめたほうがいいですか？
0882デフォルトの名無しさん2014/10/29(水) 17:29:17.16ID:NA8+uBRT
>>880
エボラは致死率は高いものの、感染力は季節性インフルエンザより低く、
潜伏期に感染もしないため、残念ながら終焉しない
0883デフォルトの名無しさん2014/10/29(水) 17:42:32.70ID:US+EsBcT
空気感染はしないからね
アフリカの人達はあまりにも無知で無用心だったため感染が広まったみたいだね
0884デフォルトの名無しさん2014/10/29(水) 17:52:17.85ID:gUoIWkK1
いやまあ初期は誰も知識持ってないからしょうがない面もあるでしょ
犠牲者がイたからこそいろいろわかってきた
0885デフォルトの名無しさん2014/10/29(水) 17:55:24.53ID:HBXTyN9+
「エボラは存在しない！」とかいって隔離施設を襲撃したりしてたからな。
レベルが違うわ。
0886デフォルトの名無しさん2014/10/29(水) 18:18:05.77ID:US+EsBcT
中国なんかあれだけ経済大国になったにもかかわらず未だに
ブタやニワトリなどの家畜を家の中で飼ってるからね
0887デフォルトの名無しさん2014/10/29(水) 18:28:53.88ID:CVZn32SR
経済大国と田舎の農家が今までどおりなのはあまり関係ないと思うけど
偏見とすれ違いだな
0888デフォルトの名無しさん2014/10/29(水) 19:16:01.44ID:LJBpagLw
八八八
0889デフォルトの名無しさん2014/10/29(水) 19:25:48.06ID:svrkbAR0
>>881おねがいします
0890デフォルトの名無しさん2014/10/29(水) 21:18:00.89ID:QyQ56sbs
git merge して衝突が発生した時、
git add 衝突ファイル名
とコマンドすると、そのファイルは解決したことになりますが
この状態から、そのファイルを再び未解決状態に戻すには
どういうコマンドを入力したらいいのでしょうか？
0891デフォルトの名無しさん2014/10/29(水) 21:41:22.85ID:+4rbzCBy
git reset --hard
0892デフォルトの名無しさん2014/10/30(木) 09:06:31.37ID:JyGsGO1i
git ebola
0893デフォルトの名無しさん2014/10/30(木) 09:18:02.99ID:XUDk5/xR
git diff ANUS
0894デフォルトの名無しさん2014/10/30(木) 10:34:10.14ID:gxwnASCg
今いるブランチのログだけ表示する方法をおしえてください
0895デフォルトの名無しさん2014/10/30(木) 12:36:26.50ID:cQjIg7VJ
２．１．３
0896デフォルトの名無しさん2014/10/30(木) 13:06:05.22ID:YTL6Km3+
ダーー！
0897デフォルトの名無しさん2014/10/30(木) 13:28:30.39ID:UT+H+6H/
いやいやｗ
0898デフォルトの名無しさん2014/10/30(木) 19:00:08.03ID:cH0Fwfec
ブランチ名を変更したっていう記録がreflogに残ってません
これってあんまりやらないほうがいいですね
0899デフォルトの名無しさん2014/10/30(木) 19:00:38.80ID:cH0Fwfec
ブランチ名を変更した時にファイルに記録したいのでフックおしえて下さい
0900デフォルトの名無しさん2014/10/30(木) 23:59:12.26ID:B7KOSmmC
ブランチ名って記録に残さないといけないようなものなのか？
0901デフォルトの名無しさん2014/10/31(金) 00:52:37.91ID:fzEvUe3e
誰かが勝手にブランチ名を変更したのでたどれないんですよ
github flowに沿ってるのでブランチがたくさんあるので探すのに手間がかかるのですよ
0902デフォルトの名無しさん2014/10/31(金) 01:10:39.21ID:8Uf3xK8D
ブランチって複数のコミットを指すものじゃなくて
特定の１つのコミットを指すただのポインタだから辿るなんて無理じゃね
各コミットにどこのブランチから参照されたことがあるかっていう情報でも書かれてりゃいいが、たぶんないだろうし
0903デフォルトの名無しさん2014/10/31(金) 06:20:26.97ID:zV8yxXTK
ブランチってこれしか知らない
https://www.youtube.com/watch?v=HKLnmMacEB4
0904デフォルトの名無しさん2014/10/31(金) 07:55:48.48ID:yr/i2jdz
ブランチ名の変更を記録するために努力するより，その勝手な奴を探して
意思疎通をはかるほうが先のような
0905デフォルトの名無しさん2014/10/31(金) 09:31:34.00ID:Lxm1GiJ2
hgだとコミットにブランチが記録されるから、そっちから入った運用だと欲しいかもね
0906デフォルトの名無しさん2014/10/31(金) 10:32:23.44ID:ye78HJq1
なのでフックできまえんか？
0907デフォルトの名無しさん2014/11/01(土) 14:29:57.48ID:+ct8WvSM
aブランチにいます
ファイルを編集しました。
この状態でbブランチを作成してそこで別の作業がしたいんですが
aブランチの内容は作業中なのでコミットはしたくないんですが、
こういうときってどうしたらいいですか？
0908デフォルトの名無しさん2014/11/01(土) 14:40:17.17ID:1cXKFWWG
>>907
stashかclone
0909デフォルトの名無しさん2014/11/01(土) 14:42:39.31ID:hdcrWs+g
stash

まあ、しばらく離れるなら俺はコミットするけどね。
stashはスタックなので色々やるとわからなくなってるから。

どうせコミットしても後から修正できるんだしさ。
それがgitのいいところ
0910デフォルトの名無しさん2014/11/01(土) 14:46:18.15ID:3nVvYlYV
git stash
0911デフォルトの名無しさん2014/11/01(土) 15:08:18.64ID:wP/CUk9Y
俺もとりあえずコミットしておく
後で中途半端な状態のコミットはなかったことにできるし、
コミットしておけば、わけわかんなくなっちゃっても
reflogで復旧できるし
0912デフォルトの名無しさん2014/11/01(土) 15:30:13.74ID:WwPqiJUs
>git-new-workdir
>gitリポジトリに紐づく新たな作業ディレクトリを作成します。
> 別々のbranchを同時にcheckoutして、動作の比較を行ったりできます。
> 急なバグ対応が入ったりした時に、面倒なcommitやstashをせずに、すぐに作業を切り替えることができます。
> （個人的に）作業状態のまま放置できるので、どの作業をしていたのか忘れずに済みます。
http://qiita.com/yuya_presto/items/dcebbebc6b3d9cf6f542

>ただ、Windows で Git for Windows (msysGit) を使ってる場合は、そのまま持ってきても動かないので、次のようにした。
http://tech.nitoyon.com/ja/blog/2013/03/29/git-new-workdir/
0913デフォルトの名無しさん2014/11/01(土) 17:36:40.86ID:NWvPyPI3
(1)最後から2番目のpushを取り消したい
(2) 1のpush後に何回かコミットしている

リモートにパスワードを書いたファイルをあげちゃったんです！
どうにかして消したいんですがリポジトリを削除する以外でたすけてください！
個人リポジトリです。
0914デフォルトの名無しさん2014/11/01(土) 17:38:42.47ID:NWvPyPI3
あとpushしたあとに過去のコミットに戻って作業しなおしてコミットしなおしてます
0915デフォルトの名無しさん2014/11/01(土) 18:03:34.69ID:XzkwPK+7
リポジトリを削除してgit cloneしたらreflogに消えてるんですけどreflog復活できないんですか？
0916デフォルトの名無しさん2014/11/01(土) 18:13:34.29ID:FYqABB6+
>>915
削除したリポジトリを復活させられるファイルシステムまたはゴミ箱を使ってないなら無理
0917デフォルトの名無しさん2014/11/01(土) 18:15:16.51ID:iW3/zCCJ
ええええ
0918デフォルトの名無しさん2014/11/02(日) 04:01:31.80ID:k43a6lgh
gitのバックアップってみんなどうしてる？
0919デフォルトの名無しさん2014/11/02(日) 04:20:30.80ID:IBnDqJlk
リポジトリのバックアップならGitHubとかのリポジトリほスティングサービスに丸っと上げてるけど
git自体のバックアップは取ってないな、PCイカレたときにgit環境の再構築は面倒だからgitもバックアップ取っておいたほうがいいかもなあ
0920デフォルトの名無しさん2014/11/02(日) 04:50:35.89ID:6JfF1xXY
>>918
gitっていうかユーザーフォルダまるごと
オンラインバックアップソフトでバックアップしてるけど？
0921デフォルトの名無しさん2014/11/02(日) 06:46:18.61ID:LNjYg/LZ
>>918
リモートホストと、ローカルでアーカイブするディレクトリにpush。
0922デフォルトの名無しさん2014/11/02(日) 19:29:36.99ID:ThHDneSJ
>>913
個人リポジトリならrebaseで良い感じに履歴を修正してgit push -fで良いんじゃないの？
0923デフォルトの名無しさん2014/11/02(日) 22:08:30.34ID:+x3IjfRt
git clone
0924デフォルトの名無しさん2014/11/03(月) 02:37:45.68ID:AVck6ina
>922
サーバ側でgcされない限り発見されうるのでは。
0925デフォルトの名無しさん2014/11/03(月) 02:46:26.46ID:ga1lmjsH
リモートってのがGitHubみたいなリポジトリサービスを個人で使ってるとかならリポジトリ丸っと削除してから上げ直すってのがてっとり早そうだが
そうでないんなら管理者にお願いするしかないな
0926デフォルトの名無しさん2014/11/03(月) 09:27:50.81ID:1DGR/mlS
bitbucketだとpush -fやってもハッシュがわかれば辿れます
githubはどうなんでしょうかね
0927デフォルトの名無しさん2014/11/03(月) 09:52:06.95ID:ikPdAg2R
>>924
個人リポジトリなら公開しなければ良いんじゃ無くて？
0928デフォルトの名無しさん2014/11/03(月) 17:47:08.61ID:RlfDc9Qx
git checkout -b test
ファイル作成
git stash
>No local changes to save

何故保存できないんですか？
0929デフォルトの名無しさん2014/11/03(月) 18:08:06.61ID:JWZEDRHL
addしてないから
0930デフォルトの名無しさん2014/11/04(火) 10:02:07.88ID:srrbBYWq
コミットって何個ぐらい貯めてからマージしたほうがいいですか？
0931デフォルトの名無しさん2014/11/04(火) 12:27:32.90ID:shtI5m7G
ブランチした目的が完了したらマージすればよい
0932デフォルトの名無しさん2014/11/04(火) 18:40:49.16ID:h/d8a8at
最後にコミットしたファイルが何だったか確認したいんですけどどうやるんですか？
0933デフォルトの名無しさん2014/11/05(水) 07:18:20.97ID:M5idn0Tw
>>932
git show --name-only HEAD^
とか。
0934デフォルトの名無しさん2014/11/08(土) 00:19:43.30ID:fHlqfJbD
それじゃない方法合ったはずなんですが思い出せません
0935デフォルトの名無しさん2014/11/08(土) 01:23:09.15ID:v0SFyh4V
ポジトリの作成と基本的なバージョン管理――SourceTreeで始めるGitバージョン管理入門 第1回
http://sourceforge.jp/magazine/14/11/06/200000
0936デフォルトの名無しさん2014/11/08(土) 16:24:19.48ID:qwvGzBPO
ぽじぽじ
0937デフォルトの名無しさん2014/11/08(土) 21:52:16.01ID:reRJrTPU
aブランチにいる時にブランチを変更しないままbブランチの最新コミットの特定のファイルを表示する方法ありませんか？
git show HEAD bだと差分しかとれません
0938デフォルトの名無しさん2014/11/08(土) 21:52:49.00ID:reRJrTPU
git show HEAD dev test.txt
0939デフォルトの名無しさん2014/11/09(日) 14:08:12.74ID:ZRZEFjhv
git merge --squash featureしたら
fatal: You cannot combine --squash with --no-ff.ってでました
どうしてですか？
0940デフォルトの名無しさん2014/11/10(月) 02:12:22.08ID:cjWO4r21
fast forward なマージじゃ無いからじゃないかな、うん
0941デフォルトの名無しさん2014/11/10(月) 04:49:39.77ID:/MiFk0my
>>939
$ git merge --squash feature; git status
の結果を見たら判ると思う
0942デフォルトの名無しさん2014/11/10(月) 10:13:17.97ID:mJmPI0Yr
これさ.gitconfigでff = falseにしてるんですけど
たしかGIt 2.0ではff = falseがデフォルトになるからって言われててGit 1.7あたりからずっとこれ指定してたんですけど
これはずしたらエラーが出なくなったってことはGit 2.0でも ff = falseがデフォルトじゃないってことですよね
ってことはデマを流した奴ゆるせねえよ
0943デフォルトの名無しさん2014/11/10(月) 12:16:53.53ID:LG3MPbP+
はあ？
0944デフォルトの名無しさん2014/11/10(月) 14:13:03.06ID:ktQb1IT9
ふぅ
0945デフォルトの名無しさん2014/11/11(火) 00:33:46.85ID:bBHeKZ12
ff = falseじゃなくなると
git mergeしたときにmergeしたってコミットがログに残らなくなって1本化されてどのブランチからマージされたのかわからなくて不便なんですけど
こういうのが皆さんいいんですか？
0946デフォルトの名無しさん2014/11/11(火) 00:41:57.16ID:ZZYlQze/
gitにおいて「どのブランチからマージされたか」という情報は不要な情報です。

masterブランチなど特殊なものを除いて
ブランチは一時的に作られ、そして削除されるものです。

コミットは追跡しますが、ブランチは追跡しません。
なので不便でもなんでもありません。
0947デフォルトの名無しさん2014/11/11(火) 03:44:25.75ID:nS4HMCxE
>>946の言ってる「Gitにおいて」は「ぼくの考えるGitにおいて」なので、
ff mergeでもno-ff mergeでも、状況、運用に応じて使い分けるのが吉
良くないのは特に根拠、ユースケース、プロジェクトの運用法も考えずに「ff mergeこそ原則」だとか「no-ff mergeこそベストプラクティス」だとか
「pull --rebaseが常識」とか思考停止してしまうことだと思うな
0948デフォルトの名無しさん2014/11/11(火) 09:56:57.50ID:JOEQJrit
すいません横から質問させてください

■git configで ff = falseを指定した時
コミットを一本化したい→git rebaseしてからgit mergeで1本化できる
マージした情報を残したい→git mergeでマージしちゃえばOK

■git configで ff = falseを指定してない時
コミットを一本化したい→git mergeでマージしちゃえばOK
マージした情報を残したい→◎ここ教えてください◎
0949デフォルトの名無しさん2014/11/11(火) 20:56:13.09ID:UknPa1bY
>>947
> ff mergeでもno-ff mergeでも、状況、運用に応じて使い分けるのが吉

話読まないで、脊髄反射レスするなよ。

no-ffでどこのブランチからマージされたか
という情報がなくなるって話だろ。

no-ffにしたらブランチの情報は消えるが、コミットの情報は残る。
gitにおいて「どのブランチからマージされたか」という情報は不要な情報であり
コミットの情報はあるのだから追跡可能って話だろ。
0950デフォルトの名無しさん2014/11/11(火) 21:32:12.92ID:nS4HMCxE
>>949
え、ff=falseの設定がないと、Fast forwardでマージ可能なときはFast forwardになってしまい、
そういうときはマージコミットが出来ず分岐していたこともわからないのが不便、ってことを>>945は言いたいんじゃないの？
まあでもあなたの指摘で>>946は「コミットツリーは追跡可能でブランチ(名)自体は重要な存在ではない」というようなことを言っているように
思えてきたから、そもそも話が噛み合ってないのかもしれないな。

>>948
git merge --no-ff
0951デフォルトの名無しさん2014/11/12(水) 00:48:36.32ID:tAw43bMz
>>948

そういうのが必要ならCommitメッセージに
その必要な情報を書けばいいんじゃないの？
0952デフォルトの名無しさん2014/11/12(水) 01:32:41.30ID:oqW+9k0m
>>948
マージした情報を残さない場合に使うのがff。
だから君がいっていることは矛盾している。

証拠を残さない方法でマージする時に
証拠を残す方法を教えて下さいっていっているようなもの
0953デフォルトの名無しさん2014/11/12(水) 03:23:32.59ID:OHxbfa4c
githubの公開リポジトリにpull-requestが来たのですが
修正が不十分なのでさらに追記したいです。

こういう場合は一度マージしてから、
追加分を自分で書いてコミットする感じになるんでしょうか？
分散してしまう気がするんですが
0954デフォルトの名無しさん2014/11/12(水) 03:44:59.06ID:3VJGATlA
>>953
これ読んでみてね

http://postd.cc/merge-pull-request-considered-harmful/
0955デフォルトの名無しさん2014/11/12(水) 03:58:23.24ID:OHxbfa4c
>>954
なるほど、難しくてわからんｗ
頑張ってみます
0956デフォルトの名無しさん2014/11/12(水) 10:38:02.88ID:k5vltUqv
Merge pull requestボタン使わずにgit fetchして修正してからgit mergeする
0957デフォルトの名無しさん2014/11/12(水) 15:41:08.61ID:wkOcL4q8
>>954
これ重要だよね
次スレのテンプレに入れてください
0958デフォルトの名無しさん2014/11/12(水) 17:10:59.81ID:oNgPGMI+
GithubスレっつーかOSSホスティング総合スレの領分じゃないかな、これは
0959デフォルトの名無しさん2014/11/12(水) 17:22:26.94ID:nY11rrhT
前スレでGithubOKになってたけど結局どっちなんだよ
0960デフォルトの名無しさん2014/11/12(水) 17:33:45.35ID:ueT8hwxi
Githubの操作ならここでもいいけど運用は別ってことでは
0961デフォルトの名無しさん2014/11/12(水) 17:48:18.35ID:+5avtq1s
Gitolite使った場合に置き換えての質問はセーフ？
0962デフォルトの名無しさん2014/11/12(水) 18:32:03.25ID:uE+V1Fm1
>>961
GitHubやGitoliteを別の名詞に置き換えても通用する話ならいいでしょう
0963デフォルトの名無しさん2014/11/12(水) 21:31:48.76ID:aPFUo/Gh
ファイル名からパス全体を補完する設定はありませんか？
例えばgit log script/js/main.jsを入力したいときに
git log main.js[TAB]と打ったらmain.jsがscript/js/main.jsに変わる感じにしたいです
0964デフォルトの名無しさん2014/11/13(木) 03:37:28.48ID:PwH0w3L+
レポジトリの履歴から完全にファイルを削除したいのですがうまくいきません。
相談に乗ってください。

状況を説明すると
いままでソース＋実行バイナリをコミットしていた
実行バイナリのサイズは９MB程度で３〜４回コミットしていた。
cloneでとってきた時に
レポジトリサイズが２７〜８MBになってしまったのに気がつき、
バイナリを管理から外そうと思いました。
通常通りステージされているファイルを削除してコミットします。
ここまでは通常通りのファイル削除手順で、
このあと履歴からも消すために
git filter-branch -f --index-filter 'git rm -rf --ignore-unmatch dirname' HEAD
としてバイナリの入っているディレクトリごと削除しました。
念のため全てのブランチ・タグに対して行いました。
履歴上は全て削除されているのですが、
.gitディレクトリのサイズを計測すると２７〜８MBでほとんど変わっていません。
git gcもしてみましたが変化ありませんでした。
.git内に残っているファイルでサイズが大きかったのがハッシュ名.packとかいうやつでした。
こういう場合どのように対処すればよいでしょうか？
09659642014/11/13(木) 04:09:21.51ID:PwH0w3L+
もう一つ追加質問です。
config global 設定で
core.filemode=false
としており
.gitconfigにも書き込まれているのですが
レポジトリをcloneして
git config -l
すると
core.filemode=false
のうしろに
core.filemode=true
が定義されており、勝手にtrueにされているようです
cloneしたあとに.gitのconfigでいちいちローカル設定をfalseになおさないでも
cloneしたときにすでにfalseが適用されて欲しいです。
コレはどうやったら回避できるのでしょうか？
あとgit versionは 2.1.1でした。
0966デフォルトの名無しさん2014/11/13(木) 12:17:10.54ID:TfaWOQiO
http://stevelorek.com/how-to-shrink-a-git-repository.html
0967デフォルトの名無しさん2014/11/13(木) 12:54:50.49ID:TH2WjXWm
>>963
ないんじゃね？
main.js がそこらじゅうにあったらどうする？
のと
ルートから補完するならまだしも、適当にいい具合のフォルダから補完とか難しいだろ w
0968デフォルトの名無しさん2014/11/13(木) 13:07:45.40ID:UTqcb0rY
レビューするために使うツールありませんか？
githubとかそういうwebサービスは使いません
ローカルで運用します
0969デフォルトの名無しさん2014/11/13(木) 14:42:04.68ID:Z1L+ASGn
>>963
zshとかのシェルを使ってれば、**/main.jsを補完することで似たようなことはできるよ。
0970デフォルトの名無しさん2014/11/13(木) 15:30:38.12ID:A8P9e+11
>>968
何が聞きたいのかよくわからん、普通にgitじゃだめなのか
0971デフォルトの名無しさん2014/11/13(木) 15:47:46.69ID:L24TG69N
gitでどうやってレビューするんですか？
0972デフォルトの名無しさん2014/11/13(木) 15:54:59.26ID:I8aSODmI
要するにgithubみたいののローカル版がほしいのか？
0973デフォルトの名無しさん2014/11/13(木) 16:38:57.83ID:YMcDW7oP
>>963
シェルを自作しろ
0974デフォルトの名無しさん2014/11/13(木) 17:17:08.06ID:L9/PqQSO
>>972
githubは使ったことないのでわかりませんがgitlabいれないいでレビューがしたいんです
0975デフォルトの名無しさん2014/11/13(木) 20:12:05.37ID:Z1L+ASGn
>>974
SourceTreeとか使えばいいんじゃない？
0976デフォルトの名無しさん2014/11/13(木) 20:43:51.43ID:cB3M5QyA
>>967,969,973
レスthx
zsh見てみます
0977デフォルトの名無しさん2014/11/13(木) 22:02:19.69ID:PaVph4TZ
>>968
ReviewBoard、Rietveld、Gerritとかはどう?
0978デフォルトの名無しさん2014/11/13(木) 22:13:22.01ID:vd0ZyHjk
オコトワリシマス
0979デフォルトの名無しさん2014/11/13(木) 22:22:33.26ID:BiT3RuHa
gitlabがパッケージから入れられるし
一番楽だと思うけどね。
0980デフォルトの名無しさん2014/11/13(木) 22:26:20.56ID:YwgTkykc
今日git diffでレビューしたわ。
0981デフォルトの名無しさん2014/11/13(木) 22:36:32.33ID:BiT3RuHa
git diffは差分を見るだけ。

レビューするなら、diffの内容にコメントを書くことができて
コメントしたらメールなどで相手に通知がいく。
そして掲示板のように一つのスレッドで
会話が続けられる。チーム全体がその会話を見れる。
みたいな機能がないとダメ。
0982デフォルトの名無しさん2014/11/13(木) 22:54:46.27ID:51BXvgtI
ウェブアプリは嫌で、単にdiff＆メールでも嫌ってどういうこと
専用サーバー＆クライアント方式か？
0983デフォルトの名無しさん2014/11/13(木) 23:46:51.23ID:YwgTkykc
レビューなんてやりたくねーよってことだろ。
09849642014/11/14(金) 01:57:05.95ID:7CGUYUCq
>>966
> http://stevelorek.com/how-to-shrink-a-git-repository.html
ありがとうございます。
参考にさせていただきます。
0985デフォルトの名無しさん2014/11/14(金) 16:42:06.08ID:Un4oU5dg
ID:YwgTkykc
頭悪すぎワロタ
0986デフォルトの名無しさん2014/11/14(金) 18:05:19.80ID:gxvE4Z0q
>>985
頭いいあなたは理由を完結に言えるよね?
0987デフォルトの名無しさん2014/11/15(土) 12:27:41.89ID:21oH1jUA
一時的に過去のコミットした時点に戻っていろいろファイルを開いて確認してまた今編集中の所に戻る場合h
git checkoutとgit resetどっちを使うものですか？
0988デフォルトの名無しさん2014/11/15(土) 12:36:45.55ID:OXKrkrvT
>>985
理由もなく言うとか頭悪いね
0989デフォルトの名無しさん2014/11/15(土) 17:26:46.36ID:o3UfO57b
>>987
git showですませるのが簡単だが今のブランチ覚えておいてcheckoutするのも良い
0990デフォルトの名無しさん2014/11/16(日) 01:58:42.01ID:QaCyCGE3
>>986
少しは自分でも考えろよ
0991デフォルトの名無しさん2014/11/16(日) 08:35:28.94ID:UhWDCpe4
>>987
git resetってのは変更を取り消すときに使うコマンドだよ
対してcheckoutはコミット間を移動したりする
checkoutを使うべき
0992デフォルトの名無しさん2014/11/16(日) 10:35:24.28ID:9CTE3XWg
>>974
こういうのは？
https://www.atlassian.com/ja/software/stash
0993デフォルトの名無しさん2014/11/16(日) 12:17:31.32ID:m6sFd0+V
>>990
馬鹿の考えることはわからん。
0994デフォルトの名無しさん2014/11/16(日) 14:50:22.62ID:aPjF8Str
>>974
Azure
0995デフォルトの名無しさん2014/11/16(日) 14:57:02.53ID:SSwbArxn
埋め埋め
0996デフォルトの名無しさん2014/11/16(日) 19:45:09.90ID:mQePSm8M
元の質問者はわかってると思うが横からすまん。
resetは変更を取り消すというよりbranchのHEADを移動させるコマンド
と覚えておくほうが混乱しない

そのbranchのHEADからたどれなくなるから消えてるように見えるだけでコミットは残ってる
0997デフォルトの名無しさん2014/11/16(日) 20:06:34.96ID:SSwbArxn
埋め立てふせ
0998デフォルトの名無しさん2014/11/17(月) 12:31:41.48ID:EoA2znuK
Git 11(c)2ch.net
http://peace.2ch.net/test/read.cgi/tech/1416195050/

(c).2ch.net 外せないんかの
0999デフォルトの名無しさん2014/11/17(月) 12:38:36.04ID:X64fmHCX
外せない　埋め
1000デフォルトの名無しさん2014/11/17(月) 17:29:45.24ID:re+o/iO9
うんこ使えよ
1001１００１Over 1000Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。