５ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

1 ：デフォルトの名無しさん：2014/06/22(日) 17:40:25.81 ID: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/

2 ：デフォルトの名無しさん：2014/06/22(日) 18:02:10.08 ID:b06vElF6

ｲﾁｵﾂ

3 ：デフォルトの名無しさん：2014/06/22(日) 18:33:54.01 ID:2+Nzucu/

Gitを使うと早漏になるの？だったら嫌だなあ、使うの控えるべきかしら？

4 ：デフォルトの名無しさん：2014/06/22(日) 18:45:39.07 ID:Zf5ltYR1

ｱｰｲｷｿ

5 ：デフォルトの名無しさん：2014/06/22(日) 18:55:46.49 ID:3ROl0TsY

　∧＿∧　　　　　　 SVN？ ぎっとぎとにしてやんよ
　(　･ω･)＝つ≡つ
　(っ　≡つ＝つ
　/　　　) ﾊﾞﾊﾞﾊﾞﾊﾞ
　( /￣∪

6 ：デフォルトの名無しさん：2014/06/22(日) 19:03:02.96 ID:kD+jIMJ8

　　　　 　　　　　　　　　　ノ 　　　　 ﾟ.ﾉヽ　 , /}　　　　　　...
　　　　　　　　　　　　,,ｲ`"　　　　　､-' 　 `;_' '　　　　..::::::::::::::...
　　　,-､　　_.._　　　(　　　　　　　　(,(~ヽ'~　　　　　..:::::::::::::::::::::::
　）'~ 　ﾚｰ'　　〉　　 ヽ　　　　　　　i`'}　　　　　　　.:::::::::::::::::::::::
　~つ　　 　　'-ｰ､　　i　　　　　　　|　i'　　　　　...:::::::::::::::::::::::
　／　　　　　　 <　　/　　　　　。/ 　 !　　......:::::::::::::::::::::::::　　　　これは>>1乙じゃなくて
/　　　　　　　　　~^´　　　　 /},-''　,●::::::::::::::::::::::::::::::::::::
i､　　　　　　　　,i'　_,,...,-‐-､/　　　 i　 ::::::::　　.:::::::::::::
..ゝ　　　　　　　　<,,-＝=､　　　,,-,/　　　　　 .:::::::::::　　　　　　　　　　　　放射能がうんたら
　)　　　　　　　{~''~>`v-''`ｰﾞ`'~　　　　　　　..:::::::::　　　　　　　　　　　　　　　　　　　　　　　　　　........::.
　{　　　　　　　 ﾚ_ﾉ　　　　　　　　　　　　..::::::::.　　　　　　　　　　　　　　　　　　　　　　　　　......:::::::::
ノ　　　　　　　　　''　　　　　　　　　　　..:::::::　　　　　　　　　　　　　　　　　　　　　　　 ...::.:...:::::::::
　　　　　　　　　　　　　　　　　　　　 .:::::::::　　　　　　　　　　　　　　　　　　　　　...:......::::::::::::　.
　　　　　　　　　　　　　　　　　　　　.:::::::::::.　　　　　　　　.....　　　　　 ..　　..::::::::::::::::::::::::　　　:::.
　　　　　　　　　　　　　　　　　　　　::::::::::::::::.::::::....:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::..　::　 ::..
　　　　　　　　　　　　　　　　　　　 .::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::　:::　　　　::.
　　　　　　　　　　　　　　　　　　　　:::::::::::::::::　::::::::::::::::::::::::::::::　:::::
　　　　　　　　　　　　　　　　　　　　　　　　　 .::　　　 ::.　　:::

7 ：デフォルトの名無しさん：2014/06/23(月) 10:11:42.41 ID: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/

8 ：デフォルトの名無しさん：2014/06/23(月) 10:12:16.78 ID: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

9 ：デフォルトの名無しさん：2014/06/24(火) 10:55:31.19 ID:BxyDqmCe

スレ立てて書き込み少な目で放置しとくと落ちるのは自動なのか？このスレは大丈夫なのかね？

10 ：デフォルトの名無しさん：2014/06/24(火) 12:46:36.12 ID:/C23Uhbr

入門Git以外は手に取ってみる価値もない
でFA?

11 ：デフォルトの名無しさん：2014/06/24(火) 14:19:17.66 ID:oDNeDxJ6

GoogleAppsScriptで書いたソースをgitでリポジトリ管理するにはどうすればいい？

12 ：デフォルトの名無しさん：2014/06/24(火) 16:36:15.78 ID:Q+GgUeFG

>>11
import/exportができるみたいだからそれ使えばいいんじゃないの？
http://qiita.com/soundTricker/items/e75ee1f2a7d89fa60a60

単に特殊なデプロイが必要になるってだけ。

13 ：デフォルトの名無しさん：2014/06/25(水) 10:27:08.76 ID:51nve3hM

import/export を自動化するスクリプトを GoogleAppsScript で書けないかな

14 ：デフォルトの名無しさん：2014/06/26(木) 08:42:26.78 ID:rb3EhG0/

>>10
どっちの？

15 ：デフォルトの名無しさん：2014/06/26(木) 10:06:12.43 ID:BCJ2ygce

念のためにこっちにも
Git 2.0.1 リリース
https://github.com/git/git/releases/tag/v2.0.1

16 ：デフォルトの名無しさん：2014/06/26(木) 11:59:36.41 ID:lzGhXXy2

>>14 君には入門Gitが入門gitに見えるのかね

17 ：デフォルトの名無しさん：2014/06/26(木) 15:13:00.47 ID:I1GlggqH

スレ番も数字じゃなくハッシュ値で

18 ：デフォルトの名無しさん：2014/06/26(木) 20:19:34.54 ID:uNXRCBxV

さ　あ　、　も　り　あ　が　っ
　　　　　　　　　　　　　　　　　　て
　　　　　　　　　　　　　　　　　　　　　ま
　　　　　　　　　　　　　　　　　　　　　　　い
　　　　　　　　　　　　　　　　　　　　　　　　 り
　　　　　　　　　　　　　　　　　　　　　　　　　 ま
　　　　　　　　　　　　　　　　　　　　　　　　　　 し
　　　　　　　　　　　　 　　　　　　　　　　　　　　た

19 ：デフォルトの名無しさん：2014/06/27(金) 12:01:47.48 ID:wewJM3ti

兆戦の皿が白ばっかりなのは
土器みたいに茶色いままだと
うんこが付いてても気付かないから

20 ：デフォルトの名無しさん：2014/06/27(金) 22:32:20.88 ID:VuPlBIMA

日本の器に黒っぽいのが有るのはうんこが付いてても気にせず食べるから？

21 ：デフォルトの名無しさん：2014/06/28(土) 01:35:08.69 ID:sQNJ1q5c

皿にうんこが付く状況ってどんなんだよ

22 ：デフォルトの名無しさん：2014/06/28(土) 04:37:58.98 ID:w+QI/fAg

器にうんこが付くという発想がないから

23 ：デフォルトの名無しさん：2014/06/28(土) 04:57:32.01 ID:sKWOMnpi

トンスルランドでは台所に便所紙捨てるところがあるんだっけ

24 ：デフォルトの名無しさん：2014/06/28(土) 06:10:14.26 ID:WBXNiQjo

日本に観光に来てる連中は
ホテルのトイレでも紙をゴミ箱に入れるので
従業員を困らせている

25 ：デフォルトの名無しさん：2014/06/28(土) 06:50:34.22 ID:6GT+Y+O2

日本も戦前は同じだったそうだよ

26 ：デフォルトの名無しさん：2014/06/28(土) 07:49:42.50 ID:88+ODrtr

ここまで Git の話なし

27 ：デフォルトの名無しさん：2014/06/28(土) 10:47:37.20 ID:pkB82Erl

今日のうんこスレはここですか

28 ：デフォルトの名無しさん：2014/06/28(土) 23:12:42.12 ID:c56+A2pI

一、清潔な食事運搬用バケツと雑巾バケツの区別をよく教えること。

こんな注意書きが必要な連中なので

29 ：デフォルトの名無しさん：2014/06/29(日) 00:18:04.03 ID:/NI7q9pJ

敗戦直前の日本の雑誌に、汚れたバケツに貯まった雨水を飲み水に使うことの美徳が書かれていたって話を思い出すな

それはともかく、Gitのブランチ管理はややこしいよなー
未だに解説読みながらやってる

30 ：デフォルトの名無しさん：2014/06/29(日) 00:54:31.86 ID:f0WIPed4

gitのブランチ管理じゃなく
git flowもしくはgithub flowのブランチ管理がややこしいのでは

31 ：デフォルトの名無しさん：2014/06/30(月) 22:40:23.98 ID: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 'git@github.com:username/repo.git'

originを変更しないと駄目な理由を分かりやすく教えてください

32 ：デフォルトの名無しさん：2014/06/30(月) 22:46:39.87 ID: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 で公開されています。

33 ：31：2014/06/30(月) 23:03:26.98 ID:5h8Y0Ud2

>>32
おお！素早いご指摘どうもです
よく理解できました
これからはそのドキュメントを良く読むようにします

34 ：デフォルトの名無しさん：2014/06/30(月) 23:10:54.18 ID:v5UqmfMQ

っていうかGitHubってhttpsでのpushに対応してたっけ？

35 ：デフォルトの名無しさん：2014/06/30(月) 23:24:02.07 ID:ocNeWDMt

httpsのアドレス宛にいつもpushしてるが

36 ：デフォルトの名無しさん：2014/07/01(火) 02:04:03.39 ID:uudBEfHR

>>31
単にpushする先を指定してないだけだろ。

URL指定でcloneしているから、
originと紐付いてないだろうし。

37 ：デフォルトの名無しさん：2014/07/01(火) 20:07:37.99 ID:dBLK7YMD

ローカルリポジトリのブランチhogeにコミットしました

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

取り消すにはどうすればいいのでしょうか？

38 ：デフォルトの名無しさん：2014/07/01(火) 20:22:39.16 ID:M2q2ii4G

パルプンテを唱える。

39 ：デフォルトの名無しさん：2014/07/01(火) 20:23:17.83 ID:M2q2ii4G

もしくはメガンテ

40 ：37：2014/07/01(火) 20:24:46.81 ID: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にコミットされたということですよね？

41 ：デフォルトの名無しさん：2014/07/01(火) 20:25:26.30 ID:rJGfEq1K

用語が変なのはgit使いでなくsvn使いとかか

42 ：デフォルトの名無しさん：2014/07/01(火) 20:28:16.54 ID:sZ99gDnh

>>37
リモートリポジトリの管理者にごめんなさいして、どう処理するか相談する

43 ：37：2014/07/01(火) 20:39:43.94 ID:dBLK7YMD

リモートリポジトリをcloneしてmasterブランチのlog見たらコミット履歴にありませんでしたが・・・
どこにコミットされたのでしょうか・・・

>>41
その通りです

44 ：デフォルトの名無しさん：2014/07/01(火) 20:44:17.29 ID:rJGfEq1K

用語がめちゃくちゃで何を言ってるのか何をやりたいのかさっぱり分からん

45 ：デフォルトの名無しさん：2014/07/01(火) 20:54:30.74 ID: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 のどっち？

46 ：37：2014/07/01(火) 22:06:47.31 ID:dBLK7YMD

質問が不明瞭、かつ書き間違いなどがあり申し訳ありませんでした。
もう一度できるだけ詳しく正確に書くように致します。

47 ：デフォルトの名無しさん：2014/07/01(火) 22:21:48.75 ID: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)を見ても変わってないんです…。

48 ：デフォルトの名無しさん：2014/07/01(火) 23:38:48.46 ID:sZ99gDnh

>>47
それは、ローカルのmasterブランチをhttps://hoge.com/fuga.gitのmasterブランチにpushしただけだね
https://hoge.com/fuga.gitのmasterブランチの最新が9frr0bfに更新されてるはずだよ

49 ：デフォルトの名無しさん：2014/07/02(水) 00:34:49.55 ID:KQlLn9XQ

>>48
ありがとうございました。
しかし、幾ら試してもhttps://hoge.com/fuga.gitのmasterのコミットログにないんです・・・。

恐らくこのまま放置することにします。
長々と書き込んでしまいすいませんでした。

50 ：デフォルトの名無しさん：2014/07/02(水) 01:06:49.78 ID:OroZGiqB

>>49
いやだから、書き込みを良く見てくれ
「ローカルのbranchBじゃなくて、ローカルのmasterを、リモートのmasterへpusuしてる」
したがって、ローカルのbranchBにコミットしたx.cppファイルがhttps://hoge.com/fuga.gitのmasterに無いのは当然

それて、pushが成功したかどうかはファイルの有無じゃなくてハッシュで確認しろ
git branch -av で各ブランチと対応するハッシュを確認できる

51 ：デフォルトの名無しさん：2014/07/02(水) 01:17:52.28 ID:En/r/TGL

pusu

52 ：デフォルトの名無しさん：2014/07/02(水) 01:26:05.54 ID:OroZGiqB

>>50-51
おう、pusuはpushのタイポな

53 ：デフォルトの名無しさん：2014/07/02(水) 01:29:18.74 ID:En/r/TGL

example.なんとか使えつって教わらなかったのか

54 ：デフォルトの名無しさん：2014/07/02(水) 22:13:56.81 ID:mhKrJc1t

VisualStudioのExpressでバージョン管理したいからGit入れたいんだけど
GUIで楽にローカルリポジトリ作る方法ってある？

55 ：デフォルトの名無しさん：2014/07/02(水) 23:02:29.91 ID:87h9OT3W

はい、tortoisegitさんお呼びですよ

56 ：デフォルトの名無しさん：2014/07/02(水) 23:06:30.92 ID:mhKrJc1t

亀ってリポジトリ作れるの？

57 ：デフォルトの名無しさん：2014/07/02(水) 23:40:22.67 ID:j/Db3LoH

もちろん

58 ：デフォルトの名無しさん：2014/07/02(水) 23:50:54.99 ID:mhKrJc1t

単独で作れるのか
ありがとう

59 ：デフォルトの名無しさん：2014/07/02(水) 23:55:08.90 ID:87h9OT3W

Visual Studioに組み込めるプラグインもあるかも知れんけど
わかんね。msdnでも覗いてみれ。

60 ：デフォルトの名無しさん：2014/07/03(木) 03:35:02.68 ID:LFvCfQY8

VSに組み込めるプラグインがあるとしても、Expressは拡張機能サポートしてないからどのみちダメじゃないか？

61 ：デフォルトの名無しさん：2014/07/03(木) 03:39:50.30 ID:j0zMe+Fe

VS2013ならMSが公式でGitのプラグインを出してなかったか

62 ：デフォルトの名無しさん：2014/07/03(木) 05:54:32.69 ID:DIfIjFzr

Azure専用

63 ：デフォルトの名無しさん：2014/07/03(木) 06:02:01.97 ID:fWjka1bK

Windowsが7以降ならSourceTreeもあるな

64 ：デフォルトの名無しさん：2014/07/03(木) 09:57:25.05 ID:T6nbxnRY

2013はExpressでもIDEからgit使えるけど、どうもわかりにくい
ankhsvnくらいに手軽だといいのだが、、、よって亀とコマンドライン併用
Xcodeの内蔵はかなり使いやすいと思った。

65 ：デフォルトの名無しさん：2014/07/03(木) 19:41:43.68 ID:dti37cU6

msysgitダウンロード出来ねぇ…
500ってなんだ…

66 ：デフォルトの名無しさん：2014/07/03(木) 21:06:15.26 ID:tTUYGcci

サーバの内部エラー

67 ：デフォルトの名無しさん：2014/07/03(木) 21:06:41.59 ID:tTUYGcci

https://github.com/msysgit/msysgit/releases/
行けた

68 ：デフォルトの名無しさん：2014/07/03(木) 21:16:47.31 ID:dti37cU6

ありがと！いけた

69 ：デフォルトの名無しさん：2014/07/03(木) 21:22:28.52 ID:dti37cU6

gitは正常に終了しませんでした (終了コード 128)

とか言われた…
なんだこれ…

70 ：デフォルトの名無しさん：2014/07/03(木) 21:29:51.18 ID:ljTzUKRX

あ〜、俺もそれなった。64bit Windows7
余計な物が入るのがいやなんだろうけど
msysgit諦めて
http://git-scm.com/
から丸々落としたら問題なくインストールできた

71 ：デフォルトの名無しさん：2014/07/03(木) 21:31:59.03 ID:VhhMtL7W

…え？
git-scmからmsysgitじゃないWindows用gitが入手できたの？

72 ：デフォルトの名無しさん：2014/07/03(木) 21:39:27.88 ID:dti37cU6

>>70
おｋ入れてみる

…の前にアンインスコしとこっと

73 ：デフォルトの名無しさん：2014/07/04(金) 01:20:38.78 ID:ZQHJOpH+

msysgitのアンインスコがそもそも出来なくねえか？
ネットにはコントロールパネルからアンインスコしろと書いてあったが
インスコの途中でエラッたからかどうか分からんが、そんなものはなかった

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

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

個人的には、改行コードを勝手に変換されるなんて害以外の何物でもないと思うので
問題ないなら、何も変換させたくないのだが

74 ：デフォルトの名無しさん：2014/07/04(金) 08:40:05.93 ID:xvFt74Dw

>>73
いろいろな環境でやるならlfだけにしておいて、各環境でチェックアウト時にcr,crlf,lfで使うのが楽じゃない？
ソースじゃなくてなんか特殊なファイルとか管理するならきめうちのほうがいいかもだし、
自分ひとり開発とかチームで環境が変わる要素がないならそのままでもよい

75 ：デフォルトの名無しさん：2014/07/04(金) 20:58:59.90 ID:G9V8ZPtC

企業でgit使う場合ってリポジトリは暗号化して使うものですか？そのへん詳しい人教えてください

76 ：デフォルトの名無しさん：2014/07/04(金) 21:41:37.64 ID:KGk1oj/Q

>>75
基本的に、暗号化してからadd,commitするよ

77 ：デフォルトの名無しさん：2014/07/04(金) 22:46:19.47 ID:VHgyx1X4

>>75
詳しくはないけど。
鍵やデータはバージョン管理しないんじゃない。暗号化するようなファイルシステムなら、されちゃうかもだけど。

78 ：デフォルトの名無しさん：2014/07/04(金) 23:32:09.16 ID:7y8V145d

ん？Git-scmってのはmsysgitの代わりに使うって認識で良いの？

79 ：デフォルトの名無しさん：2014/07/05(土) 00:32:02.32 ID:7oOEkOAN

msysGitというプロジェクトでWindows用のGitが開発されていて
その成果は(Linux版やMac版も含めた)Gitの総合サイトであるgit-scmでも
やはりWindows用Gitとして配布されている…？

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

…俺もWindows版はよく知らんので、誰かツッコミ頼む

80 ：デフォルトの名無しさん：2014/07/05(土) 01:34:47.12 ID: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
の方じゃないかな？

前者はバイナリだけの配布で、
後者はネットワーク経由インストールでコンパイル環境なんかも含めたすべてを落とせる？

81 ：デフォルトの名無しさん：2014/07/05(土) 05:17:04.89 ID:SaA3Dhwi

そこで、cygwin で git ですよ。
オレオレビルドで、新しいリリースがすぐ使える

82 ：デフォルトの名無しさん：2014/07/05(土) 14:14:39.37 ID:oc6wEiev

http://tracpath.com/bootcamp/learning_tortoisegit.html
これ見ながらやろうと思っても、Git Bash起動するとすぐ画面閉じるんだけど
Git bashってどうやって使うの

83 ：デフォルトの名無しさん：2014/07/05(土) 14:29:48.66 ID:oA33QTWa

>>82
msysgit のインストールに失敗してるんだろ

84 ：デフォルトの名無しさん：2014/07/05(土) 14:45:31.43 ID:oc6wEiev

あれ？もしかしてmsysgitインストールしたらmsysgitってフォルダ作られる？
C:\Program Files (x86)\Git
とは別に？

85 ：デフォルトの名無しさん：2014/07/05(土) 14:57:24.31 ID:Q/k3+41v

win7にmsysgitをインストールしたら↓のディレクトリにインスト―ルされたけど、Git Bashもこの中だし

C:\Users\Hiroshi\AppData\Local\Programs\Git

86 ：デフォルトの名無しさん：2014/07/05(土) 15:03:51.27 ID:oc6wEiev

そうか…やっぱ失敗してんのかな
500から403に変わってGoogle Codeからは相変わらずダウソ出来ないし
もう少し探してみるか…
ありがとなヒロシ

87 ：デフォルトの名無しさん：2014/07/05(土) 15:16:53.89 ID:oA33QTWa

>>86
しばらく前から動かないって言ってるひとか？
インストールに失敗してるんじゃなくて、アンインストールに失敗してるんじゃないか？
ゴミが残ってて新しくインストールしたmsysgitがうまく動かないみたいな感じ

88 ：デフォルトの名無しさん：2014/07/05(土) 15:51:10.99 ID:oc6wEiev

うーん
つってもとりあえず『アンインストールとまたは変更』から削除したんだけど
それじゃ足りないのかな？
ゴミがどこに残り得るのかすらわからんのだけど

89 ：デフォルトの名無しさん：2014/07/05(土) 15:59:32.61 ID:oA33QTWa

そういうのは地味に調べるか、できなきゃOS再インスコかね
自分もWindowsはよくわからんから、Winでこの手のツールをインストールしまくるのは嫌だね
なので、構成を自分でだいたい把握できてるcygwin版を使ってる

90 ：デフォルトの名無しさん：2014/07/05(土) 20:52:23.99 ID:oc6wEiev

なんなのこれ…
Stack trace:
Frame Function Args
688100 [main] sh.exe" 8060 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
724705 [main] sh.exe" 8060 handle_exceptions: Error while dumping state (probably corrupted stack)

91 ：デフォルトの名無しさん：2014/07/05(土) 21:02:46.99 ID:Q/k3+41v

お前のwindowsが単にぶっこわれてるだけなんじゃね

92 ：デフォルトの名無しさん：2014/07/05(土) 21:03:11.07 ID:oA33QTWa

>>90
それは STATUS_ACCESS_VIOLATION でググルと対策らしいのが出てくるぞ
TEMPフォルダ絡みらしい

93 ：デフォルトの名無しさん：2014/07/05(土) 21:08:28.81 ID:oA33QTWa

中途半端にGitのコードにユニコード対応とか入れた影響なんだろうなあ
日本語Win環境なんかじゃ試して無いだろうし
オリジナルのGitがほぼそのまま動くCygwinがやっぱええわ

94 ：デフォルトの名無しさん：2014/07/05(土) 21:20:01.50 ID:oc6wEiev

>>92
おぉ、ほんとだありがとう
キャッシュ自体1.5Gもあったしちょうどよかった…

95 ：デフォルトの名無しさん：2014/07/05(土) 21:35:39.83 ID:DUJJhZn/

>>93
なんかユニコードがらみで問題でもあったの？

96 ：デフォルトの名無しさん：2014/07/05(土) 21:58:23.52 ID:oA33QTWa

>>95
TEMPフォルダにゴミがあると>>90みたいに落ちるらしい
特に日本語ファイル名のファイルとかあるとダメ
Unicode対応前のバージョンなら問題無いとか

97 ：デフォルトの名無しさん：2014/07/06(日) 01:52:41.07 ID:2At6bBxp

やっと使えるようになったよ
ありがとう

コミットの概念が、SVNとちょっと違うのかなぁ
また混乱したら聞きにくるよ
繰り返しになるけどありがとね

98 ：デフォルトの名無しさん：2014/07/06(日) 02:22:08.53 ID:hcqFkKqd

なんで頑なにPro Gitとかを読もうってしないんだ連中は

99 ：デフォルトの名無しさん：2014/07/06(日) 12:57:28.08 ID:IqnhNmsn

ここの先輩って一つのフォルダにどのくらいプロジェクトを詰め込んでるのか教えてください

100 ：デフォルトの名無しさん：2014/07/06(日) 15:24:57.69 ID:f2dQpJou

自分も興味ある＞どのくらい詰め込んでるのか

今はSubversionで10くらいのシステムを1システム1リポジトリで管理。
1システム(1リポジトリ)の中で document/client/server/moduleA/moduleB/... と複数ディレクトリを作って管理してる
Gitの場合、systemA-server/systemA-client という単位でリポジトリ作った方がいい？

101 ：デフォルトの名無しさん：2014/07/06(日) 16:16:31.85 ID:aXyTuyHi

>>100
ケースバイケースとしか言いようがないけど、Subversionに比べてGitではリポジトリを分けることが多くなった。
っていうか、「フォルダ」と「プロジェクト」って、「リポジトリ」とどういう関係があるのか説明してくれないと上手いこと答えられないかも。

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

Subversionと違って、独立したものをなんでもかんでもリポジトリに突っ込むと別々に開発したときにマージが発生しまくってめんどくさいし、
Subversionでいうところのupdateをかけるフォルダの単位でリポジトリを分けたほうが面倒がないよ。Gitはリポジトリの一部だけを最新にするってことができないから。

102 ：デフォルトの名無しさん：2014/07/06(日) 18:40:54.69 ID:8H24GUT0

systemA-serverとsystemA-clientにリポジトリを分けた時なんだけど、
両方で使えるライブラリがあったとする。

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

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

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

まったくgitはよく考えて作られてるよ。

103 ：デフォルトの名無しさん：2014/07/06(日) 18:45:43.21 ID:8H24GUT0

それからorphanブランチっていうのも忘れちゃいけないね。

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

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

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

systemA-serverとsystemA-clientに別のリポジトリに分けなくても、
別のリポジトリにわかれているかのように使うことだって出来る。

104 ：デフォルトの名無しさん：2014/07/06(日) 18:50:04.07 ID:J6LM3Iar

MavenとかRubyGemみたいな仕組みが利用できる言語なら、
ライブラリをsubmoduleで取り込む必要は無いね
まあでもそういうのが常に使えるわけじゃないからsubmoduleの仕組みを作ったんだと思うけど

105 ：デフォルトの名無しさん：2014/07/06(日) 23:12:18.37 ID:5OIsyZ4O

コードを修正するたびにコミットログにupdateって書いてすぐにpushするんですけど
pushってどのタイミングでやってますか？

106 ：デフォルトの名無しさん：2014/07/06(日) 23:23:33.10 ID:HJxqGFZE

>>105
テスト合格したらプッシュ

107 ：100：2014/07/06(日) 23:58:38.68 ID:Jh/5AOzt

>>101-104
ありがとうございます。
知らないこと・未経験なことばかりで勉強になりますm(_ _)m

108 ：デフォルトの名無しさん：2014/07/07(月) 06:17:17.82 ID:JBDMezlo

updateなんて意味のないメッセージのコミットは、pushする前に分かりやすくメッセージを書き換えたりsquashしたりした方がいいよ

109 ：デフォルトの名無しさん：2014/07/07(月) 08:35:06.30 ID:dSawaSg/

commit はこまめに
完全に動かない時は動かない理由も書いて commit
push は動作確認出来たものを push
どうしても動作テスト通っていないものを push したいときは branch で

110 ：デフォルトの名無しさん：2014/07/07(月) 08:36:37.14 ID:iqLntt6B

何回か前の commit のメッセージにスペルミスがあったのに気付きました
恥ずかしいので治しておきたいのですが過去の commit のコメントを治せますか？

111 ：デフォルトの名無しさん：2014/07/07(月) 09:33:06.41 ID:sxx7xYnm

俺もそれ知りたいです
そういうときはいつもgit initからやり直してたので

112 ：デフォルトの名無しさん：2014/07/07(月) 09:49:15.90 ID:TkAvh2GT

git rebase rewordでググれ

113 ：デフォルトの名無しさん：2014/07/07(月) 11:22:17.68 ID:qZJT4lFx

git rebase -i commit~1
って感じ

114 ：デフォルトの名無しさん：2014/07/07(月) 16:51:47.32 ID:KZfau/wE

スペルミスにより別の存在する単語になって文全体の意味が違うくなるってなら直す必要もあるかもだが
そうでなく本来のスペルを予測可能な範囲なら大抵はいちいち直さんやろ

115 ：デフォルトの名無しさん：2014/07/07(月) 21:00:46.13 ID:rOGGoQLa

subversionもそうだけど、なんでコメントって
気軽に直せないんだろう？

git rebaseでもコメント修正したら
コミットID変わっちゃうし。

116 ：デフォルトの名無しさん：2014/07/07(月) 21:09:20.24 ID:eRMueaNX

バージョン管理に関しては気軽に修正できるっていうのは必ずしも良いことではない
Gitは気軽に修正できる代わりにハッシュが必ず変わって修正が明白になるようにした

117 ：デフォルトの名無しさん：2014/07/07(月) 22:03:17.69 ID:rOGGoQLa

いや、今の話はソースコードじゃなくて
コミットログの話だから。
さすがにソースコードを気軽に編集できればなんて話はしてない。

気軽に編集できる git notes をなぜ作ったのか？
コミットログを修正できればよかったのではないかって話。

118 ：デフォルトの名無しさん：2014/07/07(月) 22:16:10.15 ID:eRMueaNX

コメントの修正も基本的には問題あるよ？
同じバージョンやハッシュでコメントの違うコミットがOKなVCSがあるとして
それらのコミットを先祖に持つ二つのブランチをマージするときどっちのコメントが引き継がれるべきだと思う？

notesはこういうときどんな扱いしてるんだろ

119 ：デフォルトの名無しさん：2014/07/07(月) 22:39:39.79 ID:GtUCyZaI

タイポを修正したコミットのメッセージがタイポしてたら死んでも直したくなるだろ

120 ：デフォルトの名無しさん：2014/07/07(月) 22:53:15.16 ID:4tIz5IJL

subversionは、コミットログを編集できるよ

121 ：デフォルトの名無しさん：2014/07/07(月) 23:00:28.64 ID:eRMueaNX

それはまあ、非分散型だから問題にならないのかな？
分散型の場合にはコメントの編集がコミットを特定するIDとかに反映されないようだと困る

122 ：デフォルトの名無しさん：2014/07/07(月) 23:03:08.44 ID:rnTCx4k1

コミットの私物化

123 ：デフォルトの名無しさん：2014/07/07(月) 23:23:04.44 ID:YLk007Ty

>>115
> subversionもそうだけど、なんでコメントって気軽に直せないんだろう？

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

git は難しいと思うよ。
A さんと B さんで違う内容に編集したらどうするかとかから決めないとダメだろうし。

124 ：デフォルトの名無しさん：2014/07/07(月) 23:40:30.30 ID:aVaaFMZ2

gitはコマンドや引数が複雑化しすぎている
今後登場するバージョン管理システムでこれを克服しなければならない
例えばlogとreflogならgit logとgit log -ref

125 ：デフォルトの名無しさん：2014/07/07(月) 23:41:56.88 ID:aVaaFMZ2

統一できるコマンドは統一するのが大事
reflogはlogに吸収させてしまえばいい
そしてコマンドに対する引数もなるべく少なくすること

126 ：デフォルトの名無しさん：2014/07/07(月) 23:42:42.69 ID:aVaaFMZ2

gitはphpみたいに汚い

127 ：デフォルトの名無しさん：2014/07/07(月) 23:58:44.89 ID:KZfau/wE

BazaarやMercurialとかの他の分散型はgitほと汚くないの？

128 ：デフォルトの名無しさん：2014/07/08(火) 00:04:03.61 ID:TkAvh2GT

reword >>126
squash >>125
squash >>124

# The first commit's message is:
汚いレスを圧縮

129 ：デフォルトの名無しさん：2014/07/08(火) 00:18:25.88 ID:u9V+tSfl

よくも悪くも Linux なんだなぁと思う。
個人的には FreeBSD + Subversion の方が肌に合う。

130 ：デフォルトの名無しさん：2014/07/08(火) 01:36:57.96 ID:hxSm+BQN

コミットログなんて、探すときのヒントなだけで、結局はChangeLogやdiffで確認するだろ。あとはtagとか。

131 ：デフォルトの名無しさん：2014/07/08(火) 01:52:11.38 ID:iPzcgb4Q

リポジトリに対するログと、
作業スペースの履歴のログで意味が違うだろ

132 ：デフォルトの名無しさん：2014/07/08(火) 02:06:34.79 ID:aM3L01D8

まさに意味が違うという話をしてたんじゃないの？

133 ：デフォルトの名無しさん：2014/07/09(水) 10:21:12.64 ID:7mAKqlSH

>>114
fileId を fieId と書いてしまって
field って言う別の存在する単語と見間違えます
どうしたら治せますか？

>>121
コミットのコメントのログをバージョン管理に入れてしまえば良い

134 ：デフォルトの名無しさん：2014/07/11(金) 00:22:31.17 ID:sjma/frv

git push -uの-uってなんですか？
毎回-u付けないといけないんですか？

135 ：デフォルトの名無しさん：2014/07/11(金) 00:41:29.05 ID:YU+Bm/Jy

>>134
ヘルプくらい嫁
http://git-scm.com/docs/git-push

136 ：デフォルトの名無しさん：2014/07/11(金) 06:25:33.53 ID:jWWrmOK/

必要なときは付けろとgitに言われる

137 ：デフォルトの名無しさん：2014/07/16(水) 01:04:59.81 ID:1BA7HWeq

PJはSVN使ってるんだけど、諸事情あって今俺が書いてるソースはリリース直前までコミットできない
さすがに不安なんで、git-svnでローカルにだけでもgitとしてコミットしようとしてるんだけど、
git-svnって、TortoiseGitでもできるん？
git自体触ったこともないので、GUIなくてコマンド覚えるのに時間かかるようだったら諦める

138 ：デフォルトの名無しさん：2014/07/16(水) 09:01:10.65 ID:7fshRLGV

>>137
TortoiseGitでも出来るが、gitを使ったことがないとちょっと解りにくいかも。

139 ：デフォルトの名無しさん：2014/07/16(水) 09:51:25.74 ID:YAHvhD3g

最初TortoiseGitだとできるように見えなかったのが、コマンドでgit-svn使い始めたら
あちこちちゃんと対応してることにきがついたｗ

140 ：デフォルトの名無しさん：2014/07/16(水) 11:03:35.86 ID:nVCK3WYF

initial commitってどのタイミングでコミットしたらいいのか教えてください
作るものは掲示板でお考えください
まずファイル構成を決めて空のファイルを作ってコミットするのか
何もファイルが存在しない状態でコミットするのか
ある程度動くものができたらコミットするのか
本当にわかりません

141 ：デフォルトの名無しさん：2014/07/16(水) 11:48:22.12 ID:qYDy3YV9

特にセオリーは決まってなかったと思う
わからないなら空commitでおｋかと

142 ：デフォルトの名無しさん：2014/07/16(水) 13:12:44.48 ID:dtGU31iT

initial なら 空っぽの RADME.md だけ作って commit てる
とりあえず何か commmit しとかないと diff がエラーになる

143 ：デフォルトの名無しさん：2014/07/16(水) 13:30:32.92 ID:Sd4M1rY0

リリースバージョンで1.0と2.3とかつける時のコミットログはなんて書きますか？
git commit -m "Release: 1.0"みたいな感じ？

144 ：デフォルトの名無しさん：2014/07/16(水) 13:45:29.77 ID:G80bT3bq

最近はREADMEをマークダウンで書いたりするのか。

145 ：デフォルトの名無しさん：2014/07/16(水) 13:46:33.57 ID:G80bT3bq

>>143
tagつけるので、コミットメッセージは気にしない。

146 ：デフォルトの名無しさん：2014/07/16(水) 13:47:41.27 ID:YAHvhD3g

GitHub使うとそれがデフォだったりするからな

147 ：デフォルトの名無しさん：2014/07/16(水) 14:05:10.01 ID:Hxrp0ywP

GitHubだとリポジトリのリンク開いたときにトップディレクトリのREADME.mdをHTMLに変換して表示してくれるからね
トップディレクトリの一覧の下にそれを表示するんで、トップディレクトリ自体にはあまりファイルとかたくさん置かないようにしとくと更に見やすくて良い

148 ：デフォルトの名無しさん：2014/07/16(水) 14:15:16.78 ID:Hxrp0ywP

>>142
一番最初に--allow-emptyで完全空っぽのコミット作ったりすると問題ある？

149 ：デフォルトの名無しさん：2014/07/16(水) 14:19:26.07 ID:G80bT3bq

>>146
>>147
なるほろ。githubか。

150 ：デフォルトの名無しさん：2014/07/17(木) 18:11:47.91 ID:FWioQIqe

プッシュし終わった跡に間違いに気づいてコミットしなおした
git commit -m "update"
git push
git add -A
git commit --amend -m "update"
ここからプッシュした内容をけして新しいコミットのをプッシュする場合はどうしたらよいか？

151 ：デフォルトの名無しさん：2014/07/17(木) 18:23:12.64 ID:FWioQIqe

なんかgit pushしたら
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'git@*********:*********/*******.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
って出たのでgit pullしたら
Auto-merging server.php
CONFLICT (content): Merge conflict in server.php
Automatic merge failed; fix conflicts and then commit the result.
ってなったのでコンフリクトを直してaddしてcommitしてpushしました
>>150の跡にどうするのが一番良かったのか教えて下さい

152 ：デフォルトの名無しさん：2014/07/17(木) 18:37:46.64 ID:5+M8kOpG

>>150-151
そもそも>>150をやってはいけない
pushしたコミットを--amendで直してはいけない

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

push -fをしてもいいのは、push先のリポジトリを自分しか見てないような場合とか、
自分以外の人が見てる場合にはその自分以外の人全員にpush -fする旨の許可を貰えるような場合

153 ：デフォルトの名無しさん：2014/07/17(木) 18:40:00.40 ID:FWioQIqe

なるほどそうでしたか
これからはやらないことにします
こういうときって２回目のコミットログはfixとかって書いとけばいいですかね？

154 ：デフォルトの名無しさん：2014/07/17(木) 19:54:07.75 ID:5+M8kOpG

>>153
コミットメッセージは何をfixしたとかupdateしたとかまで書いておいたほうがいいと思うけどね

155 ：デフォルトの名無しさん：2014/07/17(木) 21:16:30.65 ID:0NORU4KM

チケット駆動とGitの組み合わせで開発するときに
何かするたびにチケット切って、それにあわせたブランチをGitで切って作業する運用って
プロジェクト中盤以降なら修正とか改善の粒度も小さいからしっくりくるんだけど
プロジェクトの何もない最初のほうは、１つの大きな機能の実装に2週間とかかかって、
それのせいでブランチ閉じられずにマージコミットやコンフリクトがあふれてなんかしっくりこない。

チケット駆動してる人は最初からチケット駆動してる？
それとも落ち着くまではmasterに直接コミット突っ込んだりしてる？

156 ：デフォルトの名無しさん：2014/07/17(木) 21:21:35.53 ID:iWQxEqkT

>>153-154
--autosquash用のフォーマットの"fixup! 修正先のコミットID"、でいいよ
元々何をしたかったかは直前のコミットメッセージにあるわけだし

157 ：デフォルトの名無しさん：2014/07/17(木) 21:36:45.43 ID:OTputfOO

コミットごとにpushするのはやめたほうがいい？

158 ：デフォルトの名無しさん：2014/07/17(木) 21:48:15.42 ID:f9EwQ7K8

fixed #1223とかrefs #4643とかだな。
コメントだけではそれが安定か不安定かくらいしか見てない。
ローカルだとadhocとかno testとかもある。

159 ：デフォルトの名無しさん：2014/07/18(金) 00:19:24.35 ID:9lilrWED

個人的なリポジトリなら自分が見やすいよう好きにすればいいし
共同のリポジトリなら仲間同士でルール決めてやるほうがよい
git flowやgithub flowあたりのメジャーなやりかたを採用するのもよい
コミットごとのpushがリポジトリを見づらくしてるよう思うのなら仲間と相談してしないようにルールを決めればよい

160 ：デフォルトの名無しさん：2014/07/18(金) 01:07:16.29 ID:97CjBc8L

内容書くと、どこまで書くかという程度がそれぞれなので、文句が出る。

161 ：デフォルトの名無しさん：2014/07/18(金) 01:23:55.70 ID:fn9HMHhn

>>150
> プッシュし終わった跡に間違いに気づいてコミットしなおした
> git commit -m "update"
> git push
> git add -A
> git commit --amend -m "update"
> ここからプッシュした内容をけして新しいコミットのをプッシュする場合はどうしたらよいか？

単純にpushしたらだめという意見が多いが別にそんなことはない。
運用の仕方による。

gitlabを使った場合のやり方。
メインのリポジトリからforkした個人のリモートリポジトリを作る。
これはgitlabにforkって機能があるんでそれを使うだけ。

メインのリポジトリには直接pushしない。個人のリモートリポジトリにpushする。
個人のリモートリポジトリは個人のものだから--amendして直してpushしていい。

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

162 ：デフォルトの名無しさん：2014/07/18(金) 06:26:27.67 ID:P4uOsCCD

>>151

>>150 をやってしまったのなら pull してコンフリクトを治して add して commit して push するのが一番良い

163 ：デフォルトの名無しさん：2014/07/18(金) 07:43:45.67 ID:NmG7h+bv

>>161
>>151 が聞いているのは
>>150 の状況にならないためにはどうすれば良いのか？ではなくて
>>150 の状況になってしまった場合どうすれば良かったのか？だから
その回答は今回の場合は適切じゃない

あ
でも
>>150 へのレスだからいいのかな

164 ：デフォルトの名無しさん：2014/07/18(金) 08:06:52.12 ID:Vkkmxlwy

上書きしないですぐに修正コミット追加するかrevertしてじっくり修正
誰もrevert使ってないのは縛りプレイなの？

165 ：デフォルトの名無しさん：2014/07/18(金) 09:10:39.82 ID:fn9HMHhn

>>164
通常のコミットと、マージコミットと二つあるんだよね。

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

とかいう、通常のコミットだけの履歴を作りたいのかと。
こういうのは、機能毎にマージコミットであるべき。

166 ：デフォルトの名無しさん：2014/07/18(金) 19:58:00.50 ID:kcaMBvas

SGitってアンドロイドアプリ使ってみたことある人いる？便利なのかな

167 ：デフォルトの名無しさん：2014/07/18(金) 20:58:14.38 ID:wFp38Dl6

2.0.2

168 ：デフォルトの名無しさん：2014/07/20(日) 12:13:18.06 ID:6LE+xCsK

コミットてどのタイミングでやるべきか教えてください
例えば設定ファイルで設定を書いたらそこで1コミット

169 ：デフォルトの名無しさん：2014/07/20(日) 18:25:37.05 ID:k6VJN0Us

はい

170 ：デフォルトの名無しさん：2014/07/20(日) 18:45:06.24 ID:OS5ZzYFf

>>168
そんなのローカルルール。
特に分散型は同一プロジェクト内でも、リポジトリごとに違うことも。

171 ：デフォルトの名無しさん：2014/07/20(日) 18:47:28.99 ID:llZw+pKm

>>168
後でいくらでも直せるんだから
ローカルでコミットするタイミングは
バックアップとっておきたいと思ったタイミングだな。

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

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

意味が無いことはしない。意味があることをする。と考えれば
コミットに分けておくと、何かあった時に便利だなってことに
コミットすればいいんだよ。

172 ：デフォルトの名無しさん：2014/07/20(日) 20:52:14.88 ID:zKSe34gp

1〜3回目のコミットをまとめる方法をおしえて
いま10回目のコミットまでしてある

173 ：デフォルトの名無しさん：2014/07/20(日) 22:04:48.48 ID:zKSe34gp

mkdir a
touch t.txt
git init
git add -A
git commit -m "ic"
mkdir b
git checkout -f←bディレクトリが残ったままとなる。なぜですか？

174 ：デフォルトの名無しさん：2014/07/20(日) 23:31:18.41 ID:667cWtBA

checkout は、リポジトリに登録している物に対して作用する
b は、リポジトリの管理外だから無視する

175 ：デフォルトの名無しさん：2014/07/20(日) 23:36:41.49 ID:tRUHKzxS

ってことはいちいちrm -rf * *.*ってやらないとだめそうですね
めんどくせえ

176 ：デフォルトの名無しさん：2014/07/20(日) 23:37:11.83 ID:PtZju0so

何のために？

177 ：デフォルトの名無しさん：2014/07/20(日) 23:53:43.91 ID:Veyq7Blc

いちからか？

178 ：デフォルトの名無しさん：2014/07/20(日) 23:54:29.30 ID:tRUHKzxS

ファイルとかディレクトリを作った後にやりなおしたいんですよ

179 ：デフォルトの名無しさん：2014/07/21(月) 00:21:33.87 ID:jb5Wh/p0

追跡されてないファイルやディレクトリを消すコマンドがあるかもね！？

180 ：デフォルトの名無しさん：2014/07/21(月) 00:40:34.84 ID:bGaWqmfa

そ、その、、コマンドをどうかおしえてください・・・ガクッ

181 ：デフォルトの名無しさん：2014/07/21(月) 02:42:51.85 ID:Udsw+XFD

git clean

182 ：デフォルトの名無しさん：2014/07/21(月) 04:21:43.81 ID:DpfIQ25M

ファイルが無い空のディレクトリをpushしたいのですが
addしてもcommitしてもpush出来ません＞＜

183 ：デフォルトの名無しさん：2014/07/21(月) 05:28:30.74 ID:75s/cUSB

>>182
.gitkeep

184 ：デフォルトの名無しさん：2014/07/21(月) 09:50:04.00 ID:W2ckSfZN

ダミーファイルを置いておくという古典的方法じゃダメなん

185 ：デフォルトの名無しさん：2014/07/21(月) 12:48:57.77 ID:mYM6Tgvw

.gitkeep って要するにダミーファイルだよな

186 ：デフォルトの名無しさん：2014/07/21(月) 13:39:37.03 ID:jb5Wh/p0

今のところGit公式には.gitkeepを特別扱いするようなコードは無くてただのダミーファイルだよね？
ぶっちゃけ空の.gitignoreの方が悪影響は少ないと思うんだけど
名前が良くないってことなんだろうなあ

187 ：デフォルトの名無しさん：2014/07/21(月) 13:47:36.43 ID:By4oX885

というか.gitignoreには「役割がある」からダメなんだと思う
「空のフォルダだけど必要なんです」と言うニュアンスを伝えるにはちょっと

188 ：デフォルトの名無しさん：2014/07/21(月) 13:54:08.75 ID:Emref6q+

いくら「ローカルルールで違う」って言っても
さすがに「コミットメッセージの2行目は空行」を守ってないところはイメージできない

189 ：デフォルトの名無しさん：2014/07/21(月) 14:16:55.97 ID:VU7LZ8It

ちゃんげログでもおいておけばいいじゃん

190 ：デフォルトの名無しさん：2014/07/21(月) 15:59:18.02 ID:l1b5gSje

gitkeepの悪影響とは

191 ：デフォルトの名無しさん：2014/07/21(月) 16:05:11.66 ID:FbNmBe/D

SCM変わったときに「Gitじゃないんだけどなー」と悶々とする。
CVSの頃は .keepme って名前のファイルがよくあったけど、
Svn文化を経由するときに失伝したらしい

192 ：デフォルトの名無しさん：2014/07/21(月) 16:06:20.21 ID:kkLNQHqq

空のディレクトリが必要って状況が想像できない

193 ：デフォルトの名無しさん：2014/07/21(月) 16:20:40.07 ID:FbNmBe/D

入門書とかにハッキリとは書かれてないので
運用してる人は少ないが、公開リポジトリの統合ブランチであっても
「このブランチはrebaseされることあるから、この上で作業すんなよ」
って予め宣言した使い捨てブランチを用意しとけば
そのブランチはpush -fしても全然問題ない。

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

こうしとけばmasterより先の使い捨て部分はいつでもやり直せる。
revertでもいいんだがゴミがたまるのが辛いし、
失敗してもやり直せる安心感にはかなわない感じ。

194 ：デフォルトの名無しさん：2014/07/21(月) 16:23:02.25 ID:nldUh4DS

>>192
その理屈だと、ディレクトリの中を空にしたら
自動的にディレクトリが消えたほうがいいってことになるよ。

195 ：デフォルトの名無しさん：2014/07/21(月) 16:25:00.39 ID:nldUh4DS

>>193
rebaseしてはいけないのは、”共有の"ブランチであって、
共有してないものはrebaseしてかまわないんだよね。

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

そんなのケースバイケースだろうと。

196 ：デフォルトの名無しさん：2014/07/21(月) 16:32:44.93 ID:VU7LZ8It

いやいや自分のやり方以外は認められず否定しかできないのがお前らgitterという生き物

197 ：デフォルトの名無しさん：2014/07/21(月) 16:54:37.93 ID:PFpi7FDC

>>195-196は同じことを違う側面から見ているのだと思う。
多分、微妙に知識がついて「○○したらダメ」「デフォルトの○○は有害でしかない」というような意見を見て信じこむから否定しかできなくなるんだよね。
で、そういうメリットデメリットを考えられない人がブログとかで同じことを強く喧伝するので広まっていくんじゃないのかな

自分も大抵のことはケースバイケースだと思うわ。

198 ：デフォルトの名無しさん：2014/07/21(月) 16:55:57.76 ID:jb5Wh/p0

公開リポジトリ上のブランチのリベースは、回りに周知できてるならいいんじゃないか？
自分用のブランチだからcloneして参照すんなとか、
cloneして見ててもいいけどpullは失敗するかもしんないからそんときは自分でなんとかしろとか

ただ、周知できてないと、まえにこのスレにも沸いたキチガイみたいに
ただpullしてるだけなのにリポジトリ壊れたーとか言い出す奴がでる

199 ：デフォルトの名無しさん：2014/07/21(月) 17:16:50.55 ID:dhFOCTWb

linuxのiptablesの設定ファイルとかをgithubで公開したいんですけどどんなやり方がありますか？

200 ：デフォルトの名無しさん：2014/07/21(月) 17:22:44.80 ID:FbNmBe/D

みなさん、ブログの記事かじっただけの
「だれかがかんがえたさいきょうのワークフロー」
信者を相手に苦労してそうだなｗ

201 ：デフォルトの名無しさん：2014/07/21(月) 17:28:50.82 ID:jb5Wh/p0

>>193はあんたの考えたサイキョウのワークフローじゃないのかよｗ

202 ：199：2014/07/21(月) 17:37:02.31 ID:mynP+LTE

俺の質問に誰か！

203 ：デフォルトの名無しさん：2014/07/21(月) 17:37:51.41 ID:mYM6Tgvw

>>194
そういうOSが有ってもいいとふとおもった

204 ：デフォルトの名無しさん：2014/07/21(月) 18:02:50.97 ID:W2ckSfZN

その理屈だと初期ファイルをパラメータに渡さないとディレクトリを作れないってことになるよ
ついでにディレクトリと初期ファイルの権限設定も一緒に渡せると素晴らしいね

205 ：デフォルトの名無しさん：2014/07/21(月) 18:18:51.76 ID:kkLNQHqq

gitで空ディレクトリを管理したいって話の流れで
何で一般的なファイルシステムでの話になってんだよ

206 ：デフォルトの名無しさん：2014/07/21(月) 18:29:09.64 ID:nldUh4DS

>>205
ソースコードをチェックアウトすると、
ファイルシステムにディレクトリができるから。

結局のところ、空ディレクトリをgitで管理したい事の本質は
clone・checkoutした時に空ディレクトリを作りたいかって
ことになるんだよ。

207 ：デフォルトの名無しさん：2014/07/21(月) 19:00:28.92 ID:FbNmBe/D

>>199
単一のファイルを公開したいだけならGistに貼るのがお手軽でいいんじゃね？

208 ：デフォルトの名無しさん：2014/07/21(月) 20:46:28.55 ID:By4oX885

>>192
プロジェクトのディレクトリ構造を予め決めたい場合とか無いの？

209 ：デフォルトの名無しさん：2014/07/21(月) 22:18:25.16 ID:75s/cUSB

>>188
何そのルール。コミットメッセージは1行しか書いたことない。

210 ：デフォルトの名無しさん：2014/07/21(月) 22:18:48.89 ID:GJtkXJR5

でも、そのディレクトリ構造すらバージョン管理するケースを考えれば、プロジェクトのディレクトリ構造は生成スクリプトにしておくべきなのかもな

211 ：デフォルトの名無しさん：2014/07/21(月) 22:51:42.93 ID:Udsw+XFD

>>209
http://keijinsonyaban.blogspot.jp/2011/01/git.html?m=1
これによると段落が続く場合は空行が必須っぽい

212 ：デフォルトの名無しさん：2014/07/21(月) 22:52:10.89 ID:gNmDhqbD

>>210
> そのディレクトリ構造すらバージョン管理するケースを考えれば
subversionでは普通に出来たから、そこから移行してきた所が「同じこと出来ないの？」と思うのは分かる。
(出来たというか、タグやブランチもディレクトリ構造の履歴記録の応用として実現してるぐらいなんで>SVN)

213 ：デフォルトの名無しさん：2014/07/21(月) 23:20:16.59 ID:VU7LZ8It

ただpullしてるだけなのにconflict起こすからなんらかの介入が必要になるのがgitとかいう糞vps

214 ：デフォルトの名無しさん：2014/07/21(月) 23:26:47.51 ID:CUNvmPzK

今までの仕事で見たコミットログ
インターンで毎回こういうコミットログを送る奴がいた

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

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

その他メンバーに報告したい事：
〜ここに10行ぐらい〜

215 ：デフォルトの名無しさん：2014/07/21(月) 23:30:01.63 ID:75s/cUSB

>>211
メールにするようなローカルの場合じゃないか。

216 ：デフォルトの名無しさん：2014/07/21(月) 23:43:14.00 ID:Udsw+XFD

>>215
> 変更に対する短い（50文字以下の）要約
>
> もし必要なら、より詳しい説明を述べる。
> 約72文字ほどで折り返すようにせよ。
>ある文脈では、最初の行はE-Mailの件名になり、残りのテキストが本文になる。
> 空行で本文と要約を分離するのは絶対に必要だ（本文を省略していない限り）。
> もしも二つを繋げてしまうと、rebaseのようなツールが混乱する可能性がある。

とあるからgitの仕様として空行は必要なんじゃない？
あ、でも要約を抜き出すときは空行があれば便利ってだけのことなのか

217 ：デフォルトの名無しさん：2014/07/21(月) 23:54:33.85 ID:75s/cUSB

>>216
その前提がローカルって言っている。

218 ：デフォルトの名無しさん：2014/07/21(月) 23:55:00.47 ID:NsSxsujv

rewrite aaa.txt (98%)

commitしたときに98%って表示されたんですけどこれ何？

219 ：デフォルトの名無しさん：2014/07/22(火) 00:18:41.70 ID:oEdY4w5f

>>217
gitのコマンドラインの内蔵ツールの一部が前提としている条件なんだから、「ローカルルール」は言い過ぎなんじゃないの？
守らなくても動作しなくなるわけではないという意味では必須ではないだろうけど。
言葉の定義の問題になっちゃうけど、公式推奨ルール的なものはローカルルールとは言わないと思うけどね、普通は。

220 ：デフォルトの名無しさん：2014/07/22(火) 04:14:16.08 ID:VGbmS+Eh

>>219
その内蔵のロジックを使ってる人にしか意味がないルール。
実装だ、というのであれば上記のように使わないという選択肢があるが、ルールは守るべきものでしょう。
単なるツールなのだから、ルールなんて無い気もするし。

単にそうなるというなら実装。
必要な場所では守るべきものなら、ローカルルール。
そういう場合もあるから、こうする癖をつけておいた方がいいというなら、ノウハウ、プラクティス。

221 ：デフォルトの名無しさん：2014/07/22(火) 04:57:47.89 ID:m2X37Pt+

ローカル言いたいだけだろ
反抗期みたいなもんだから、スルーしときなよ

222 ：デフォルトの名無しさん：2014/07/22(火) 09:35:51.95 ID:VGbmS+Eh

了解

223 ：デフォルトの名無しさん：2014/07/22(火) 14:01:00.00 ID:9vLp8hBC

>>218
DNA鑑定の結果

224 ：デフォルトの名無しさん：2014/07/22(火) 18:10:41.04 ID:DgetY8L8

コミットログをどうやって書いてるのか参考にしたいので
誰かおすすめのリポジトリおしえて

225 ：デフォルトの名無しさん：2014/07/22(火) 18:11:31.13 ID:DgetY8L8

コミットが2000ぐらいあるリポジトリをクローンしたいんだけどさ
全部クローンするのは時間かかるので最初の1から50までのコミットだけ取る場合のやり方をおしえて

226 ：デフォルトの名無しさん：2014/07/22(火) 18:34:12.18 ID:9vLp8hBC

>>224
git

227 ：デフォルトの名無しさん：2014/07/22(火) 18:34:36.00 ID:rhcifys/

＞最初の1から50まで
「最新50コミット」って意味なら、きっちり需要を満たしているかはわからないけど
git clone --depth=50 repos
ちなみに今テストしたらreposがローカルにある場合は「file://path/to/repos」としないと全部コピーしちゃうので注意

228 ：デフォルトの名無しさん：2014/07/22(火) 19:09:09.68 ID:W07N6TR2

ちがうよ最初の方の1から50
git init して一番初めの1から50まで

229 ：デフォルトの名無しさん：2014/07/22(火) 21:32:24.88 ID:XzkIJVA+

Gitの場合、最初のコミットが1つじゃない可能性があるから
最初のコミットから50までっていう指定は無理なんじゃないか？

230 ：デフォルトの名無しさん：2014/07/22(火) 21:36:56.63 ID:K/PzrTBo

最初のコミットだけじゃなくて、3つめまではどれかって話だよな。

A
│＼
↓　↓
o　　o
↓　↓
o　　o
↓　↓
C　　B

231 ：デフォルトの名無しさん：2014/07/22(火) 21:41:51.82 ID:IAzhYGe7

おそらくすべてのコミットの時系列的に50個目ってことっしょ
SVN的な

232 ：デフォルトの名無しさん：2014/07/22(火) 22:50:30.79 ID:VGbmS+Eh

おそらく何にも考えてないだけっしょ

233 ：デフォルトの名無しさん：2014/07/22(火) 23:07:48.53 ID:XzkIJVA+

ああたしかに、最初がひとつでも、HEADがひとつに定まらん可能性があるのな
HEADが複数な場合、そのそれぞれに対応したブランチ名が無いし、困ってしまうね

234 ：デフォルトの名無しさん：2014/07/23(水) 08:17:37.76 ID:VxAus1Vh

HEADがひとつだとして、最初から50番目のコミットIDがわかれば、git fetchでいけるかと思ったけどうまくいかないね
hgだとclone -r コミットIDで途中までcloneできるんだけど

235 ：デフォルトの名無しさん：2014/07/23(水) 11:50:34.68 ID:7MX9nHNJ

コミットログのよりよい書き方とかブランチの切り方とかコマンドを実行するタイミングとかいろいろ教えてください
ログは英語で書けないので日本語で書くものでお願いします
php rssdownload.php http://フィードのurl
でフィードを取得して最新1件をファイルに追記していくプログラムでお考えください
まだ何もコードを書いてない状態でgit init;git add .;git commit -m "Initial commit";します
そしてここでgit checkout -b develop
クラスと必要なメソッドを書きます。メソッドの中身はまだ書きません
class Rssdownload{public function getFeed(){//空}などいくつかメソッドを書く}
そしてgit add .;git commit -m "クラスとメソッドのスケルトンを追加"
ここからメソッドの中にコードを書きます。一番最初にgetFeedメソッドにダウンロードする処理を書きます
そして書きましたのでgit add .;git commit -m "フィードをダウンロードするメソッドを書いた"
git checkout master
git merge develop

こんな感じでいいでしょうか？

236 ：デフォルトの名無しさん：2014/07/23(水) 11:59:10.93 ID:rdKtmwhJ

コミットは日本語使わない方が安全

237 ：デフォルトの名無しさん：2014/07/23(水) 12:37:02.01 ID:GD00E4+x

>>235
だめです。

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

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

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

だけどこれはメインブランチにマージされる時に一つ、
または機能の単位毎にまとめられます。

238 ：235：2014/07/23(水) 12:49:27.98 ID:7Q0hA37B

おらがいなかもんだおもってうそこぐな>>237

239 ：デフォルトの名無しさん：2014/07/23(水) 13:19:16.16 ID:iSdQDUGU

>>228
ぶっちゃけそんなもんを必要とする場面が想像できなくて、ただの煽りとしか思えないが、
とりあえず思いつくやり方は
一旦cloneする→cloneしたやつでgit resetする→さらにそこからcloneする
とかかな？

240 ：デフォルトの名無しさん：2014/07/23(水) 13:26:25.75 ID:WJZjj5QG

それじゃだめです巨大リポジトリからダウンロードすると通信料かかるのです

241 ：デフォルトの名無しさん：2014/07/23(水) 13:56:00.92 ID:iSdQDUGU

モバイルで全部事足りるからって固定回線全部捨てたお前が悪い

242 ：デフォルトの名無しさん：2014/07/23(水) 14:03:19.99 ID:xMQ/Q89h

subversion で旧バージョンをもとにフォークしたときは普通にgit svn clone できたけど
元がgit だと全部持ってきたほうがよさそうね

243 ：デフォルトの名無しさん：2014/07/24(木) 14:59:58.63 ID:+FhslZO7

Git 2.0.3 リリース
https://github.com/git/git/releases/tag/v2.0.3

244 ：デフォルトの名無しさん：2014/07/24(木) 15:37:36.88 ID:r6QGED5m

ブランチを切り替えて作業した内容をmasterブランチにマージする場合の定石コマンドを教えて

245 ：デフォルトの名無しさん：2014/07/24(木) 15:46:46.70 ID:2xZpDB05

github で自分のブランチから master->branch の pull request を作る

246 ：デフォルトの名無しさん：2014/07/24(木) 16:59:10.13 ID:EZX0DS/3

自分の作業用ブランチならrebaseしてpushしてもいいの?

247 ：デフォルトの名無しさん：2014/07/24(木) 17:17:53.40 ID:RXCuruZL

その質問には答えられません

248 ：デフォルトの名無しさん：2014/07/24(木) 18:38:47.92 ID:2xZpDB05

自己責任で済まないからな

249 ：デフォルトの名無しさん：2014/07/24(木) 18:43:04.61 ID:4y3AwbX8

>>246
運用上、そのブランチをベースにして誰かがコミットを重ねてなきゃいいよ

250 ：デフォルトの名無しさん：2014/07/24(木) 19:12:11.39 ID:eQap2LAf

>>246
キチガイがpullする可能性があるかどうかも気にしておけ！

251 ：デフォルトの名無しさん：2014/07/24(木) 20:44:52.79 ID:EZX0DS/3

バックアップ的にpushしときたいんだよね
この時点で間違ってるのかな

252 ：デフォルトの名無しさん：2014/07/24(木) 20:58:24.83 ID:HrSZ7LES

そのためのブランチ

253 ：デフォルトの名無しさん：2014/07/24(木) 21:04:30.41 ID:eQap2LAf

まあ、外部にpushしとくと少し安心感が増すよね
rebaseすること前提の個人ブランチ名の運用ルールでも決めときゃいいんじゃない？

254 ：デフォルトの名無しさん：2014/07/24(木) 21:26:52.08 ID:f4kjQ3wJ

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

255 ：デフォルトの名無しさん：2014/07/24(木) 21:34:03.12 ID:f4kjQ3wJ

>>253
決める必要あるの？

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

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

もっともうちではgitlabつかって、個人リポジトリにforkして
リポジトリ間でMerge Request（githubでいうPull Request）を
送ってるけどね。共有リポジトリは共有ブランチだけになるし、
そのほうがフローが綺麗なんだよ。

256 ：デフォルトの名無しさん：2014/07/24(木) 21:34:07.17 ID:pB/6WHYI

masterにマージしてpushしちゃうかもしれないのがキチガイのキチガイたる所以

257 ：デフォルトの名無しさん：2014/07/24(木) 21:35:16.51 ID:eQap2LAf

>>254
修正前と修正後をマージすることになるから、場合によってはコンフリクトするよね？

258 ：デフォルトの名無しさん：2014/07/24(木) 21:39:07.36 ID:eQap2LAf

コンフリクトするならマシかな？
修正前と後が両方残るような変な感じにマージされちゃわない？

259 ：デフォルトの名無しさん：2014/07/24(木) 21:48:24.81 ID:pB/6WHYI

>>255は統合マネージャー型のワークフロー前提だから話が噛み合わない
中央集権型のワークフローの場合にどうしよう？って話

260 ：デフォルトの名無しさん：2014/07/24(木) 21:52:46.54 ID:f4kjQ3wJ

>>256
> masterにマージしてpushしちゃうかもしれないのがキチガイのキチガイたる所以

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

gitlabでそうしてるけど？

261 ：デフォルトの名無しさん：2014/07/24(木) 21:54:30.75 ID:f4kjQ3wJ

>>259
なんだよ、統合なんたらとか集中とか
自分用語言われてもわからんわｗ

gitなんだからgitらしく使え。

262 ：デフォルトの名無しさん：2014/07/24(木) 21:56:38.90 ID: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

263 ：デフォルトの名無しさん：2014/07/24(木) 22:02:39.01 ID:pB/6WHYI

あ、>>161でも噛み合ってない。

264 ：デフォルトの名無しさん：2014/07/24(木) 23:04:41.17 ID:eQap2LAf

>>254
$ (mkdir foo1; cd foo1; git init; date > date1.txt; git add date1.txt; git commit -m "foo1 repo 1st")
$ git clone foo1 foo2
$ (cd foo1; git mv date1.txt date2.txt; git commit --amend --no-edit)
$ (cd foo2; git pull --no-edit)
$ (cd foo1; ls)
date2.txt
$ (cd foo2; ls)
date1.txt date2.txt

foo1レポジトリはdate1.txtを作ってそれをdate2.txtにmvしてコミット書き換え
それをcloneしてpullしていたfoo2には、date1.txtとdate2.txtの両方残っちゃった！

265 ：デフォルトの名無しさん：2014/07/24(木) 23:08:12.80 ID:f4kjQ3wJ

>>264
何か問題が？

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

最新のブランチに同期したいなら、消してから取り直すだけでいい。

266 ：デフォルトの名無しさん：2014/07/24(木) 23:15:59.98 ID:eQap2LAf

>>265
>>264は自分でcloneしてるけど、当然のことながら他人がcloneしてpullした場合にも同じことがおこるんだよ？
>>254の「別にpullされても、その人のlogがおかしくなるだけだろ？ 」これが間違ってるって言ってるの
おかしくなるのはlogだけじゃなくてリポジトリそのものが整合取れてない状態になる
自分なら消して取り直せばいいが、他人は気がつかない可能性があるのがわからんのか？

267 ：デフォルトの名無しさん：2014/07/24(木) 23:22:28.57 ID:f4kjQ3wJ

え？ リポジトリはその人のローカルリポジトリでしょ？
そんなの知ったことじゃないじゃない。

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

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

それを他人が勝手に盗んで、その人のローカルリポジトリの
ブランチをどう書き換えようが、その他人さんが自分で責任もつことでしょ。

268 ：デフォルトの名無しさん：2014/07/24(木) 23:27:36.97 ID:eQap2LAf

>>267
ふざけるなよ
おまえ自分の書いた>>254をよく読め

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

pullされたら、エラーもでるし、logだけじゃなくてレポジトリそのものがおかしくなる場合もある
FFできないマージコミットになるだけなんかでは断じてない

269 ：デフォルトの名無しさん：2014/07/24(木) 23:56:15.78 ID:lcgW/ICS

masterの話は誰もしてない

270 ：デフォルトの名無しさん：2014/07/24(木) 23:59:45.07 ID:RXCuruZL

あいまいな質問する奴と
あいないな質問にエスパーして答える奴
この２種類がいる限り

271 ：デフォルトの名無しさん：2014/07/25(金) 00:00:33.90 ID:J29irW36

あと>>264も別にリポジトリはおかしくなってない
reflog見て適当なとこにresetするだけだ

272 ：デフォルトの名無しさん：2014/07/25(金) 00:03:19.67 ID:oxVV+Dk5

>>271
reflogみて適当なところにresetしなきゃならないってことを、どうやって気がつけばいいいんだ

273 ：デフォルトの名無しさん：2014/07/25(金) 00:03:44.97 ID:J29irW36

>>272
pullしたときforced update云々出るだろ

274 ：デフォルトの名無しさん：2014/07/25(金) 00:09:45.52 ID:oxVV+Dk5

>>273
すべての人がforced updateに気づいて正しく対処できるとおもってんのか？

275 ：デフォルトの名無しさん：2014/07/25(金) 00:10:01.25 ID:J29irW36

ていうか話がずれてて、他人の個人用ブランチをワーキングエリアに(カレントブランチに実際のファイルとして)展開してる馬鹿がいて
そいつが更にpullしたときにワーキングエリアが変になるってだけの話だろ？
masterか、チェックアウトされる可能性がある共有ブランチ書き換えない限りeQap2LAfの言うようなことは起きんよ
どう考えても「そんなこと知ったことではない」が正しい

276 ：デフォルトの名無しさん：2014/07/25(金) 00:12:51.68 ID:oxVV+Dk5

まずは>>254が間違ってましたってゴメンナサイするのが先だろ
そして他人から見えるブランチをrebaseする可能性がある場合には
それが明確になるよう運用しなければいけない理由がわかったか？

277 ：デフォルトの名無しさん：2014/07/25(金) 00:13:38.00 ID:0uQevWYT

>>246
結論
こういう(>>247-276)トラブルを避けるためにもやらないのが無難
やるならトラブルを引き起こすリスクを覚悟した上で自己責任で

278 ：デフォルトの名無しさん：2014/07/25(金) 00:14:51.81 ID:HVzq131/

100行あるコードをコミットしました
そして10行まで削除してコードを書きなおそうと思います
そこで最後にコミットした内容を見ながらコードを書きたいんですけど
最後のコードを表示する方法を教えてください

279 ：デフォルトの名無しさん：2014/07/25(金) 00:15:17.80 ID:J29irW36

いや変なのは明らかにeQap2LAfなんだが・・・

280 ：デフォルトの名無しさん：2014/07/25(金) 00:18:50.16 ID:oxVV+Dk5

>>279
自分がおかしくないと思うなら、>>254が間違ってたことをまずは肯定してくれないかな？

281 ：デフォルトの名無しさん：2014/07/25(金) 00:19:44.83 ID:0uQevWYT

>>278
2ペインの片方に最後のコードを表示できる賢いIDEを使いましょう

282 ：デフォルトの名無しさん：2014/07/25(金) 00:24:31.90 ID:eA/GtSQx

>>281
そんなIDEは無いよ

283 ：デフォルトの名無しさん：2014/07/25(金) 00:25:55.65 ID:0uQevWYT

じゃあ諦めましょう。

284 ：デフォルトの名無しさん：2014/07/25(金) 00:32:09.56 ID:oxVV+Dk5

俺の使ってるIntelliJ IDEAは、前回コミットした内容をウィンドウに表示しながら別のウィンドウでそのファイルを編集できるぞ

さらに、編集中のウィンドウでは前回のコミットからどの行が編集されたかマークが表示されて、
そのマークをクリックすれば編集前の行の内容がポップアップで表示される

285 ：デフォルトの名無しさん：2014/07/25(金) 18:57:19.85 ID:voM5b4Ni

>>266
> >>254の「別にpullされても、その人のlogがおかしくなるだけだろ？ 」これが間違ってるって言ってるの

わからん。解説たのむ。例えばふたつのリポジトリ
* A氏のリポジトリrepo-a、
* A氏のリポジトリからcloneしたB氏のリポジトリrepo-b
があったとする。
1. A氏がrepo-aに作業用ブランチworkをpushした。
2. B氏がrepo-aのworkをrepo-bにpull
3. B氏がrepo-bのwork上に独自にコミットを追加した。
4. A氏がworkをrebaseしてrepo-aにpushした
5. B氏がrepo-aのworkをpull -> repo-bのworkでマージ発生。
6. B氏発狂
7. A氏「しらねーよ。repo-aは正常だよ？」
何が問題なんだぜ？あえて言えば3でB氏がworkにコミット追加するのが間違いだが。

286 ：デフォルトの名無しさん：2014/07/25(金) 19:25:08.83 ID:oxVV+Dk5

>>285
>>264の例をよく見てもらえばわかると思うんだけど、
B氏が単にcloneしてpullしただけで非FFのマージが発生する
そのマージはコンフリクトするか、まちがったマージになる

287 ：デフォルトの名無しさん：2014/07/25(金) 19:43:14.81 ID:oxVV+Dk5

cloneしてその後リベースされたのをpullした場合

リベースされたrepo-aをfetchした段階でこうなる
repo-bのwork -> repo-aのworkのリベース前のコミット
repo-bのremotes/repo-a/work -> repo-aのworkのリベース後のコミット

そして次にmergeが動いてrepo-bのworkにrepo-bのremotes/repo-a/workをマージする
この2つのコミットは非FFな関係だからガチのマージが動くことになる
都合よくリベース前側のコミットの差分を無視なんかしてくれないからマズイ結果になる

288 ：デフォルトの名無しさん：2014/07/25(金) 19:59:14.18 ID:J29irW36

だから>>286が間違いだっての
workブランチをワークスペースに展開してない限り何も起きねーよ

289 ：デフォルトの名無しさん：2014/07/25(金) 20:09:14.32 ID:oxVV+Dk5

>>288
repo-aのworkブランチをcloneしてpullした場合の話をしてます
>>285もそういう前提の話でおｋ？

290 ：デフォルトの名無しさん：2014/07/25(金) 21:06:16.92 ID:voM5b4Ni

>>287
> 都合よくリベース前側のコミットの差分を無視なんかしてくれないからマズイ結果になる
うんうん、
5. B氏がrepo-aのworkをpull -> repo-bのworkでマージ発生。
のことだよね？

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

B氏がそれを避けられないほど間抜けだっつう話だとしても、
B氏を哀れだとは思うがB氏以外の人が負担を強いられるべき問題だとは思わない。

291 ：デフォルトの名無しさん：2014/07/25(金) 21:33:38.76 ID:oxVV+Dk5

>>290
5.が起こるのに3.は必要無いってことです

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

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

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

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

292 ：249：2014/07/25(金) 22:17:26.06 ID:nlpJ8mOy

なんとなく >>291 の主張していることが理解できた気がする。

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

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

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

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

よくない。>>254を否定する同じ理屈で「gitは危険だから使うべきでない」とも言える。
前提がバカバカしい。

293 ：デフォルトの名無しさん：2014/07/25(金) 22:26:51.08 ID:oxVV+Dk5

>>292
いや、ちょっとまってくれよ？

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

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

この250に対する254の書き込みが間違ってるかどうかだぞ？
>>291の※の指摘をよく見てくれ
おれの指摘は上記の書き込み以外の前提は全く無い
勝手に前提を仮定しないでくれ

294 ：デフォルトの名無しさん：2014/07/25(金) 22:31:44.14 ID:oxVV+Dk5

作業用ブランチならrebaseしていいのかを議論する上で、実際にどんな影響があるのかをしっかり認識しておくのが重要だと思うんだ
それなのに、>>254のように間違った認識しかできてない状態で議論を進めるのは危険だろ
だからまず>>254の認識が間違ってることをはっきりさせたいんだ

どんな影響があるかをしっかり認識した上で、
勝手にpullする人の責任だっていう意見ならそれはそれでいいと思う

295 ：デフォルトの名無しさん：2014/07/25(金) 22:32:04.58 ID:9e0PWdlB

gitスレって荒れやすいね

296 ：デフォルトの名無しさん：2014/07/25(金) 23:06:02.09 ID:CnocSSYp

こんなの荒れてるうちに入らない
荒れているっていうのはこういうことを言うのだよ黄猿君
【PHP】下らねぇ質問はID出して書き込みやがれ 135
http://kanae.2ch.net/test/read.cgi/php/1405860979/

297 ：デフォルトの名無しさん：2014/07/25(金) 23:18:58.22 ID:9e0PWdlB

俺がスレ荒れてると思えばそうなんだろう、俺ん中ではな！

298 ：デフォルトの名無しさん：2014/07/25(金) 23:22:28.88 ID:voM5b4Ni

>>291
> 5.が起こるのに3.は必要無いってことです
たしかに別に3がなくても5で不要なマージコミットできちゃうね。
でもそれってB氏の責任というのが俺の立場だなぁ。

> ※そういうブランチがあったら誰も困らないなんてことは無い。そのpullしてる人は困る
つまり、
>>254「(pullした奴以外)誰も困らねーだろ」
>>250「pullした奴が困ってるじゃねーか」
ということかな。だいぶ君の主張が理解できた気がする。(つづく)

299 ：デフォルトの名無しさん：2014/07/25(金) 23:23:17.38 ID:voM5b4Ni

だが、これを聞いてもやはりpullした奴(例えばB氏)が気をつけるべきだというのが俺の見解だよ。
理由はpullした奴(例えばB氏)も実はそんなに困らないからなんだ。
昔のGitだと当てまらないことも多いかもしれないが、
1. 上流を参照するだけのブランチはpull --rebaseで更新するようにする
2. 勝手に古いブランチを捨てるのが嫌ならpull --ff-onlyで上流のrebaseを検出できるようにする
3. git fetch 時の出力に (forced update) と表示されてないか注意しておく
4. pull/merge前の git status/checkout のときに your branch and'origin/work' have divergedと出力されない (ca be fast-forwardedと出力される)のを確認する
5. merge時のff-onlyとかをconfigに指定しとく
などなど (他にもある) 、いくらでも避ける手段はあるうえ、
万が一pullしてmergeが発生してしまったとしても、
resetやreflog, conflicしていた場合はmerge --abortとかで戻れるわけだし。
merge発生に気づかないほど間抜けなら(ry

300 ：249：2014/07/25(金) 23:28:10.04 ID:nlpJ8mOy

>>293-294
お前さんの言いたいことはよくわかった。

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

キチガイが勝手に俺のブランチをpullしてrebaseしてmasterにマージしたらかなわんね。
すべてを破壊するキチガイの存在を肯定した議論など何の役にも立たない。

301 ：デフォルトの名無しさん：2014/07/25(金) 23:31:00.30 ID:oKdTZN9u

> キチガイが勝手に俺のブランチをpullしてrebaseしてmasterにマージしたらかなわんね。

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

キチガイを持ち出すなら、キチガイが会社中のパソコンを
壊しまわることもあるので、それはキチガイをどうにかすればいいという話で
もはやgit関係ない。何を使おうが壊そうと思えば壊せる。

302 ：デフォルトの名無しさん：2014/07/25(金) 23:34:04.18 ID:oxVV+Dk5

>>299
何度も言いますが、誰が気をつけるべきかという問題と、>>254が間違ってるかどうかは、関係ありません

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

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

そういうわけで、>>254が間違っているかどうかを答えて頂けませんか？

303 ：249：2014/07/25(金) 23:34:35.23 ID:nlpJ8mOy

そう。>>250 から先はgit関係なくてほとんど意味がない。

「gitを使ってどういう嫌がらせができるか」という話にしかならない

304 ：デフォルトの名無しさん：2014/07/25(金) 23:36:29.29 ID:voM5b4Ni

>>300 >>291
pullしてmerge発生したのに気づかず上流のmasterにpushしちゃうってことを危惧してたの？
だとしたらそんなことするアホにpush権限与えてしまった上流リポジトリのオーナーが間抜けって話だね。

305 ：デフォルトの名無しさん：2014/07/25(金) 23:36:32.91 ID:oxVV+Dk5

>>300
実際にpullされたときにどういう現象が起こるかどうかをはっきりさせておくのは重要だと思いませんか？
それをはっきりさせることでどこまで許容できるかという話が可能になります

306 ：デフォルトの名無しさん：2014/07/25(金) 23:40:56.18 ID:oxVV+Dk5

>>304
>>161あたりがこの話題の元になってると思うんですよ

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

レビューしてるひとに迷惑かかりますよね？rebaseしてるからレビューするひとは毎回ブランチ作り直しです

307 ：デフォルトの名無しさん：2014/07/25(金) 23:45:53.97 ID:voM5b4Ni

>>302
> そういうわけで、>>254が間違っているかどうかを答えて頂けませんか？

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

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

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

だから、単純に字面を額面通りに捉えて >>254 が間違っているという主張には賛同できないな。
どうだろう？

308 ：249：2014/07/25(金) 23:51:17.91 ID:nlpJ8mOy

>>304
「気づかず」ではなくて >>291 が主張しているのは半ば意図的に
他人の「作業」ブランチをベースとしたブランチを作った上でそれを操作してmasterに
マージする(など各種ブランチ操作)が技術的に可能、という話だと思う。
元のブランチがそれを意図していないなら嫌がらせの類だと感じる。
masterにマージするのはそいつでも他の誰かでもいい。

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

そういう話にしかならないから不毛

309 ：デフォルトの名無しさん：2014/07/25(金) 23:51:38.74 ID:oxVV+Dk5

>>307
なぜあなたは>>254の最後の「誰も困らねーだろ」が「(pullした奴以外)誰も困らねーだろ」であることを知っているのでしょうか？
私は文面どおり「 (pullされた奴もpullした奴も)誰も困らねーだろ」の意味にとりました
なぜなら1行目と2行目でpullした奴に実質的に影響が無いということを述べているからです

あなたは>>254かエスパーなのでしょうか？

310 ：デフォルトの名無しさん：2014/07/25(金) 23:54:12.80 ID:voM5b4Ni

>>306
> レビューしてるひとに迷惑かかりますよね？rebaseしてるからレビューするひとは毎回ブランチ作り直しです
それでいいのでは。

レビューで出される指摘事項に依存すると思うけど、
「あっちのコミットとこっちのコミットは一つのコミットにするべきだから、fixupして」
あるいは
「このコミットは2種類の変更が混じってるから分割して」
とかの指摘だった場合、rebase以外で対応するのは原理的に無理だよ?

311 ：デフォルトの名無しさん：2014/07/25(金) 23:57:06.19 ID:oxVV+Dk5

>>307
とりあえずあなたは、>>254の3行目に関しては文面どおり捕らえれば間違っているが、
「(pullした奴以外)誰も困らねーだろ」と解釈できるから間違っていないという意見ということでいいですか？

>>254の1行目と2行目はどう解釈しようも無く間違っているということでいいですか？

312 ：249：2014/07/25(金) 23:59:51.07 ID:nlpJ8mOy

>>307

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

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

でもオリジナルのブランチの作者がrebaseするとかしないとかもう全然関係ないのがね。
意図的に人を困らせる操作なんかいくらでもあるので

313 ：デフォルトの名無しさん：2014/07/26(土) 00:00:00.83 ID:p4ua17EP

>>309
まず、おれは >>254 じゃないよ

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

普段も上流をそのまま追いかけたいブランチをチェックアウトしてる場合、
上流からfetchする際は上流のrebaseが無かったか、mergeする前にfast-forwardになるか
必ずチェックするし。

314 ：デフォルトの名無しさん：2014/07/26(土) 00:01:49.35 ID:JET6jTHt

>>310
常に問題無いというわけでは無いですよね
レビューする人も人間ですからミスしてpullしちゃう可能性があります
なのでレビューのやりとりでrebaseするかどうかをはっきり表明しておく必要があると思います

315 ：デフォルトの名無しさん：2014/07/26(土) 00:08:57.84 ID:JET6jTHt

>>313
なるほど。たぶんあなたは>>254の1〜2行目の問題に>>298で初めて気がついたからそういう解釈になってしまったのですね

316 ：249：2014/07/26(土) 00:11:27.38 ID:7f7nHnx7

>>>307
>なぜあなたは>>254の最後の「誰も困らねーだろ」が「(pullした奴以外)誰も困らねーだろ」であることを知っているのでしょうか？
>私は文面どおり「 (pullされた奴もpullした奴も)誰も困らねーだろ」の意味にとりました

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


この板もID出るようになってるのか。いいことだ。

317 ：デフォルトの名無しさん：2014/07/26(土) 00:12:26.21 ID:JET6jTHt

>>313
本来こういう迷惑をかけないために公開リポジトリはrebaseしないというルールがあるのですけどね
＞普段も上流をそのまま追いかけたいブランチをチェックアウトしてる場合、
＞上流からfetchする際は上流のrebaseが無かったか、mergeする前にfast-forwardになるか
＞必ずチェックするし。
チェックする必要があるというのは修羅の国ですね

318 ：249：2014/07/26(土) 00:17:47.11 ID:7f7nHnx7

>>317

ヒント
> 246 ：デフォルトの名無しさん：2014/07/24(木) 16:59:10.13 ID:EZX0DS/3
> 自分の作業用ブランチならrebaseしてpushしてもいいの

319 ：デフォルトの名無しさん：2014/07/26(土) 00:19:37.53 ID:p4ua17EP

>>314
レビューしてもらう側からrebaseしたよ、と言うのは親切かもしれないけど、
レビューする側(とくにmergeする責任を負う奴)は master..topic にどういうコミットが
表示されるかぐらいはチェックするよ。つーかそれがレビューという作業だと思うけど？

topicを送ってきた相手によっては、
「そいつの仕事を完全に信頼してるので言われたとおりmergeする」
ってのもあるかもしれないよ。
でもそれによって送ってきた奴のミスが伝搬してしまうのはしょうがないよな。
そんなこと言い始めたらいくらでも変な状況は想定できるわけだし。

320 ：デフォルトの名無しさん：2014/07/26(土) 00:19:47.98 ID:JET6jTHt

>>316
1行目と2行目でpullする人には実質的な影響無いよ！ってことを述べているのに、
3行目が突然(pullする人以外)誰も困らないよ！って意味になってるとしたらおかしいですよね？
普通に考えれば(pullする人は)誰も困らないよ！って意味になると思います。

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

321 ：デフォルトの名無しさん：2014/07/26(土) 00:22:24.95 ID:p4ua17EP

>>315
>>254
> 別にpullされても、その人のlogがおかしくなるだけだろ？
> エラーが出るわけでもない、ただFFできないからマージコミットになるだけ。
ここかい？
間違いがあるとしたら、
「エラーが出るわけでもない」→コンフリクトすることもあるね
くらいかな。
他にどんな間違いが？

322 ：デフォルトの名無しさん：2014/07/26(土) 00:24:55.79 ID:p4ua17EP

>>320
おおぅ、そういう解釈してるの？
> ＞別にpullされても、その人のlogがおかしくなるだけだろ？
ここの「その人」はpullした人だよ。明確にpullした人に(表面上)困ることが示されてる。

323 ：デフォルトの名無しさん：2014/07/26(土) 00:26:11.79 ID:p4ua17EP

>>322
> ここの「その人」はpullした人だよ。明確にpullした人に(表面上)困ることが示されてる。
いかん、俺の日本語が不自由になってきた
(誤) pullした人に(表面上)困ること
(正) pullした人に(表面上)困ったことがおきること
です。

324 ：デフォルトの名無しさん：2014/07/26(土) 00:28:41.04 ID:JET6jTHt

>>321
「logがおかしくなるだけ」では無いですね？コミットの内容もおかしくなります
「ただFFできないからマージコミットになるだけ」では無いですね？
不正なマージコミットになることを「ただFFできないからマージコミットになるだけ」と表現するのは無茶だと思います

325 ：デフォルトの名無しさん：2014/07/26(土) 00:31:07.31 ID:p4ua17EP

>>324
> >>321
> 「logがおかしくなるだけ」では無いですね？コミットの内容もおかしくなります
> 「ただFFできないからマージコミットになるだけ」では無いですね？
> 不正なマージコミットになることを「ただFFできないからマージコミットになるだけ」と表現するのは無茶だと思います
ごもっとも。
だがその状態はpullしたやつの手元のワーキングツリーで起こってるだけでしょ？

326 ：デフォルトの名無しさん：2014/07/26(土) 00:33:37.83 ID:JET6jTHt

>>322-323
>>254の1〜2行目からはコミットの内容までがおかしくなると考えてるとは読み取れないのですが？
つまりpullerには実質的な影響は無いと考えていると思われます

327 ：デフォルトの名無しさん：2014/07/26(土) 00:39:35.54 ID:JET6jTHt

>>325
pullしたやつの手元のワーキングツリーで起こってるから、pullした奴が困るのです

328 ：デフォルトの名無しさん：2014/07/26(土) 00:40:04.95 ID:p4ua17EP

>>326
> >>254の1〜2行目からはコミットの内容までがおかしくなると考えてるとは読み取れないのですが？
> つまりpullerには実質的な影響は無いと考えていると思われます
いやいやいや、そこから共有できてないのか。

ログが違う(ログに現れるコミットが違う。たとえば余計な空のコミットが存在する)だけであっても、
Gitの性質上、それ以外、例えばブランチ先端のツリーが全く同一、差分などなど諸々が同じであったとしても、
Gitの履歴としては全くの別物になっている、というのがGitのメカニズムだし
Gitユーザの常識だと思うんだが。(よほどの初心者は違うかもしれんが)

329 ：デフォルトの名無しさん：2014/07/26(土) 00:42:58.86 ID:JET6jTHt

>>328
つまり、その状態を「ただFFできないからマージコミットになるだけ」と表現する>>254が馬鹿だったということでいいですか？

330 ：デフォルトの名無しさん：2014/07/26(土) 00:44:08.14 ID:p4ua17EP

>>327
> pullしたやつの手元のワーキングツリーで起こってるから、pullした奴が困るのです
そうだね。pullしたやつが可哀想だね。
でも本当はpullした奴も困らないでしょ？ と俺はずっと言っているわけだ。
>>299 を100回くらい読んではくれまいか。

331 ：デフォルトの名無しさん：2014/07/26(土) 00:52:49.47 ID:p4ua17EP

パトラッシュ、疲れたろう。僕も疲れたんだ。なんだか、とても眠いんだ。

332 ：デフォルトの名無しさん：2014/07/26(土) 00:55:04.24 ID:JET6jTHt

>>330
>>299は良いことが書いてあると思いますよ
pull --ff-onlyするようにとか簡単でいいですね
ただ、なぜそういうことをする必要があるかということを>>254を見て誤解してしまったような人は理解できないと思うんですよ
なので、>>254の「ただFFできないからマージコミットになるだけ」とかを見た人が誤解しないように
真意をはっきりさせておく必要があると思います

333 ：デフォルトの名無しさん：2014/07/26(土) 00:56:18.19 ID:JET6jTHt

>>331
寝たら死にますよ

334 ：デフォルトの名無しさん：2014/07/26(土) 01:05:33.08 ID:3J1xCNng

>>332
ということにしたいのですね。

335 ：デフォルトの名無しさん：2014/07/26(土) 01:17:03.50 ID:7f7nHnx7

>>327
貴方は細かいところによく気づく素晴らしい力を持っていますね。
更に文脈を読み大意を掴む力をつけるとさらに価値あるエンジニアになれると思います。頑張ってくださいね。

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

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

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

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

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

つまり他人の作業ブランチをpullしたキチガイさんが困るだけ、ってところだと思いますよ。
そのキチガイの他には影響は及ばないからそんなもの考慮する必要はない、という主張です。きっと。
あとは枝葉だから誰も気にしなかった。しかし貴方は気づいた。素晴らしい

336 ：デフォルトの名無しさん：2014/07/26(土) 01:19:31.48 ID:JET6jTHt

>>334
はい

337 ：デフォルトの名無しさん：2014/07/26(土) 01:20:14.56 ID:JET6jTHt

>>335
あなたは素晴らしいエスパーですね！

338 ：デフォルトの名無しさん：2014/07/26(土) 05:18:57.35 ID:hlVwYF+4

とりあえず、>>320みたいな
「誰も困らないよ」という文の解釈を巡って、
「(世の中全員が)誰も困らないよ」という意味になるのが正しくて「(キチガイ以外)誰も困らないよ」という意味になるのは間違っている、とかいう主張は無意味だと思うけどな。
前者か後者か曖昧なのでどっちの意味で使ったのか説明してくれ、ということだったら意味はあると思うが、
こういう文脈依存性の高いものの場合でのそういう主張は結局「文字で書かれていない部分は俺の解釈が絶対なんだ、そうでないニュアンスで文を書く奴は馬鹿」とオレオレ基準で読解力のなさを示してるだけ。
一見客観的に文意を判断してる風に説明するからたちがわるいけどな。(そして>>320も俺の意見は客観的で絶対正しいと思ってるだろう)

読解力の無いやつほど短文で文意が厳密に決まるような表現が出来ると思ってるし、文意を厳密にするために正確に冗長に表現すると長文で読めないとか言い出すよね。
自分の言語に対する理解が完全で、他人の理解が完全でないとどうして決めつけられるのか。自分の言語が間違っているという意識はないのか。謎である

339 ：デフォルトの名無しさん：2014/07/26(土) 07:41:09.25 ID:ZVICdgrk

困る人が居る場合
困る人に原因があることをもって
自己責任ということにしておけば
楽と言えば楽

340 ：235：2014/07/26(土) 08:18:47.28 ID:mdOIZXZW

それがこれまでもこれからもお前らそのものｼﾞｬﾈｰｶ

341 ：デフォルトの名無しさん：2014/07/26(土) 12:06:27.97 ID:JET6jTHt

>>338
まだやるんですか？＾＾

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

この3行は、最後の行だけじゃなくて全部突っ込みどころ満載なんですよ！その辺理解してください
2行目がほぼ間違ってるだろうということは>>335でも納得してもらえました
2行目が間違っているとなると、1行目のlogが何を指しているのかがよくわからなくなります
3行目の誰？が実際に誰のことなのかよくわからないというのもあなたが指摘しているとおりです

342 ：デフォルトの名無しさん：2014/07/26(土) 12:15:29.67 ID:8QVtVKLI

コミットログのuser.mailって後から一括とかで変えられる? またはpushするのだけとか。
変えた場合、同じコミットとして認識される?

343 ：デフォルトの名無しさん：2014/07/26(土) 12:23:24.99 ID:2fRRiDMt

1.無理
2.無理

344 ：デフォルトの名無しさん：2014/07/26(土) 12:26:52.71 ID:JET6jTHt

>>342
user.mailの設定を変えても、過去のコミットの中のAuthorとかは変わらないです
過去のコミットの中のAuthorとかを変更する場合には、git filter-branchとか使ってまとめてコミットを改変します
改変したコミットは改変前のコミットとは別物になります

345 ：デフォルトの名無しさん：2014/07/26(土) 12:36:29.64 ID:hlVwYF+4

>>341
2行目が間違ってたとしても、1行目の文意が示してるのは「pullしたやつが困る」と解釈できる。
なので3行目は「pullするような馬鹿はほっといて、それ以外は誰も困らない」って解釈できる。
>>322 >>335もそう言ってるじゃん。
だから、2行目が間違った内容かどうかというのとは別に、3行目の「誰も」をどう解釈するのかという問題は、1行目の意味を重視するのか2行目の間違った内容との整合性を重視するのかで変わってくる。
それでもあなたは「文全体の整合性を考えたら『誰も』はpullした奴も含む」と主張したくなるかもしれないが、
だとするならば1行目の「logがおかしくなる」という表現と3行目の「困らない」という表現は整合していないという考え方もある。

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

>>276あたりから>>254は間違ってるって言ってるけど、建設的な議論をするならそもそも具体的にどこが間違ってるのかさっさと指摘するべきだし、
あなたの行動は>>294あたりでは「どんな影響があるのか実際の動作について皆理解してないぞ」と2行目についての指摘をしているようでありながら、結局は>>254が完全に間違っているみたいな方向に誘導しているわけで、一貫した整合性はないじゃん。
その辺が「一見客観的に文意を判断してる風だからたちがわるい」所以だ。

346 ：デフォルトの名無しさん：2014/07/26(土) 12:45:46.50 ID:8QVtVKLI

>>344
ありがとう。

347 ：デフォルトの名無しさん：2014/07/26(土) 13:15:08.95 ID:JET6jTHt

>>345
>>254の3行に整合性がとれていないということにも合意して頂けるのですね
>>254が(特に2行目が)間違ってることは、>>264で超具体的に指摘しています
順番にコピペして実行してもらえれば状況が完全に再現できる親切設計ですよ？
何度も言っていますが、私の目的はリベースによって>>264で示すような状況が発生することを知ってもらうことです

348 ：デフォルトの名無しさん：2014/07/26(土) 13:25:03.01 ID:4Rh4oPzG

議論のための議論はよそでどうぞ

349 ：デフォルトの名無しさん：2014/07/26(土) 13:49:51.02 ID:hlVwYF+4

>>347
それならば具体的に間違っているgitの挙動についての主張に終始すべきだよね。
「誰も」をどう解釈するのかなんていう目的外のことを「普通はこう解釈する」なんていう根拠の無い理由で主張して、>>254全体について「間違っているからごめんなさいしなきゃいけないね」と思っていると
とれる発言を繰り返したことは事実の追及からは外れた個人攻撃に近いものだと思うし、少なくとも不必要な「やりすぎ」だということについては理解してもらえるのかな？

350 ：デフォルトの名無しさん：2014/07/26(土) 14:02:54.21 ID:JET6jTHt

>>349
具体的に指摘した>>264に対する回答が>>265とか>>267ですからね
それを>>268で指摘したら当人は消えてしまうし
特にやりすぎたとは思いません
>>254の人はその発言を訂正して、矛盾してる部分の整合性を正すべきだと思いますよ

351 ：デフォルトの名無しさん：2014/07/26(土) 14:20:28.86 ID:hlVwYF+4

>>350
なるほど 整合性を正すべきだというのは理解した
では「普通はこう解釈する」という根拠では、「誰も」の解釈についての主張しても>>254の発言の整合性が一層低いんだということを客観的には納得させられないということについては認められる？
それとも「誰も」についても「文字通り全員」じゃないとダメだと思っている？

352 ：デフォルトの名無しさん：2014/07/26(土) 14:22:54.04 ID:2fRRiDMt

進化しないのがダメという人間と安定しないのがダメという人間とで意見が合うはずがない

353 ：デフォルトの名無しさん：2014/07/26(土) 14:29:49.12 ID:JET6jTHt

>>351
普通はこう解釈するを、私はこう解釈するに訂正してもいいですよ？
ただし、「誰も困らない。」を「(pullした人以外)誰も困らない。」だと解釈すべきだという意見は受け入れられないですね。
これに関してはどういう意味だったかは本人に説明してもらうしかない。

354 ：デフォルトの名無しさん：2014/07/26(土) 14:54:32.80 ID:hlVwYF+4

>>353
もちろん「ただし、『誰も困らない。』を『(pullした人以外)誰も困らない。』だと解釈すべきだ」と主張しているわけではないよ。
曖昧な部分だから立場によって解釈に幅がある、だから>>320みたいな「私はこう解釈した、そしたら全然整合性がとれなくてメチャクチャだ、だからおかしい」という主張は
わざとメチャクチャになるように(自分の立場に有利になるように）解釈しているととれるので客観性のある主張ではないと言える。
だから「そんな発言をわざわざする人は読解力がないことを自ら主張しているようなもの」と>>338で言ったわけだよ。

355 ：デフォルトの名無しさん：2014/07/26(土) 15:11:15.70 ID:JET6jTHt

>>354
>>320は曖昧な部分を私なりに解釈してみたってだけなのですが？
解釈したら整合性がとれなくなってメチャクチャだと言っているのは誰なんです？

356 ：デフォルトの名無しさん：2014/07/26(土) 15:31:20.95 ID:hlVwYF+4

>>355
「私なりに解釈した結果」「突っ込みどころ満載」なのは「私なりに解釈した結果」メチャクチャだ、と言ってるのと同じじゃない？

357 ：デフォルトの名無しさん：2014/07/26(土) 15:39:23.70 ID:JET6jTHt

>>356
解釈したら整合性がとれなくてメチャクチャになるというわけではないですよ？
正常に解釈するのが難しいぐらい曖昧でメチャクチャで突っ込みどころ満載なんです

358 ：デフォルトの名無しさん：2014/07/26(土) 15:47:06.41 ID:hlVwYF+4

>>357
「正常に解釈するのが難しい」ってのはやっぱり読解力がないってことだね。

359 ：デフォルトの名無しさん：2014/07/26(土) 15:54:08.89 ID:JET6jTHt

>>358
私に読解力が無いのはどうでもいいんですが
>>254が「正常に解釈するのが難しいぐらい曖昧でメチャクチャで突っ込みどころ満載」に関しては否定なのでしょうか？
>>254の3行の整合性が取れてないという意見は肯定してもらえたような気がするのですが？

整合性はとれてないけど、正常に解釈できない程ではないという感じですか？

360 ：デフォルトの名無しさん：2014/07/26(土) 16:05:26.17 ID:hlVwYF+4

>>359
そう、「整合性はとれてないけど、正常に解釈できない程ではない」かな。
「(pullされる想定のブランチじゃないけど)pullされたら、その人のログがおかしくなるだけ」→「(想定外のpullする奴以外)誰も困らない」
　　　　└→「(おかしくなると言っても)エラーでないしマージコミットになるだけ」
という構造になっていると解釈していて、どのようにおかしくなるかというのはまた別の話を適当に差し込んでしまったんじゃないかな（間違っている内容ではあるが)。
で、こういう解釈をすると整合性がとれていないのは2行目だけで、そこを除くと意味が通るから「正常に解釈するのが難しいぐらいに〜」というのには同意できないな

361 ：デフォルトの名無しさん：2014/07/26(土) 16:24:38.62 ID:JET6jTHt

>>360
2行目を無かったことにすれば正常に解釈できるからメチャクチャじゃないと言うわけですかｗ了解しましたｗ
素晴らしい読解力ですねｗ

362 ：デフォルトの名無しさん：2014/07/26(土) 16:51:35.72 ID:02EFznKI

そういうスレたててやれ

363 ：デフォルトの名無しさん：2014/07/26(土) 17:56:19.94 ID:hp9e8t10

グダグダうるせえなどこかに内容をまとめろや

364 ：デフォルトの名無しさん：2014/07/26(土) 19:41:06.42 ID:tno9AbkY

これが日本人流の議論なんだな
最高戦争指導会議もこんなんだったんだろうな

365 ：デフォルトの名無しさん：2014/07/26(土) 20:00:28.24 ID:AxEipSYW

話豚切って悪いがまとめるとこんな感じ

この大田の相談に乗ったのが東大航空研究所の小川太一郎教授だった。
実験に協力した谷一郎東大教授によれば「昭和十九年夏、東大航研で
小川教授から新しい依頼があった。
小川さんは広い見識と温かい包容によって声望が高く、
外部から持ち込まれる相談の窓口の役割を余儀なくされていた。
その僅か前に、大田正一海軍少尉が火薬ロケット推進の特攻機の着想を持参し、
海軍上層部を動かすための基礎資料の作成を依頼していたのである。
私に求められたのは、木村秀政助教授の描いた三面図を基に、
風洞実験の助けを借りて、空気力学的特性を推定することであった。
仕事自体はさほど困難ではないが、特攻機が母機を離れた後は、
生還の可能性の全くないことを知って私はたじろいだ。」という。
http://ja.wikipedia.org/wiki/%E6%A1%9C%E8%8A%B1_%28%E8%88%AA%E7%A9%BA%E6%A9%9F%29

366 ：デフォルトの名無しさん：2014/07/26(土) 20:06:16.38 ID:AULF2YtD

もうアホどもはまとめてNGにぶっ込めばいいよ

367 ：デフォルトの名無しさん：2014/07/27(日) 08:43:57.53 ID:CtoyiymM

IDが導入されて良かった

368 ：デフォルトの名無しさん：2014/07/27(日) 13:38:06.07 ID:y0Xr839x

ID赤い奴は自動で消える仕組み

369 ：デフォルトの名無しさん：2014/07/27(日) 14:06:02.09 ID:wYLTHqwt

とっくに透明よ

370 ：デフォルトの名無しさん：2014/07/27(日) 14:58:07.68 ID:kK8gelhu

ID変えました（笑）

371 ：デフォルトの名無しさん：2014/07/27(日) 16:36:09.04 ID:fFsyojt4

忍法帳で判るんじゃね

372 ：デフォルトの名無しさん：2014/07/27(日) 22:23:32.23 ID:IbdTfPHn

パスワードを書いたままbitbucketにpushしたので
git push -f origin HEAD^:masterをやったんですけど一応pushした内容の1つ前には戻ったんですが
pushしたものが最近の活動ってところのログからたどれてしまい、アクセスすると内容が表示されてしまいました！
このやり方で合ってたんでしょうか？どうやって消せますか？

373 ：デフォルトの名無しさん：2014/07/27(日) 22:34:22.42 ID:PFdtsvV+

>>372
push -fして取り消したコミットもお主の最近の活動だから表示しておいてやるよ！

374 ：デフォルトの名無しさん：2014/07/27(日) 22:43:56.24 ID:IbdTfPHn

つまりそれって僕しか見えないものですか？
他の人には絶対に見えませんかね？

375 ：デフォルトの名無しさん：2014/07/27(日) 22:49:55.98 ID:PFdtsvV+

>>374
いや知らん。とりあえずリポジトリの設定を一時的にでも非公開にしとけよ
最悪bitbucket側でリポジトリを消して新しい空のリポジトリつくって、ローカルにある修正済みのブランチをpushすりゃいいんでないの？

376 ：デフォルトの名無しさん：2014/07/27(日) 22:59:07.09 ID:IbdTfPHn

いちおうコミットログのページにも表示はされてないんですけど
その取り消したコミットログのurlにアクセスすると表示されちゃうんですよ
複数人で操作してるリポジトリなので消すのはやべぇっすよ

377 ：デフォルトの名無しさん：2014/07/27(日) 23:28:17.58 ID:PFdtsvV+

>>376
Gitの仕様としてはブランチのコミットログからは消えても、
鯖のリポジトリ側ではGCされるまでそのコミットは残ってるしreflogとかで調べてそのコミットにアクセスできる

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

問題は、bitbucketにおいて、他のユーザがそのコミットにアクセスする手段を提供してるか？
強制的にexpireする機能をユーザーに提供してるか？
あたりかな？bitbucketに詳しい人にでも聞いてください

378 ：デフォルトの名無しさん：2014/07/28(月) 08:09:52.74 ID:aDCUknIL

rebaseが重すぎる
もっと早くならんのか

379 ：デフォルトの名無しさん：2014/07/28(月) 09:08:00.51 ID:bfSVrt1T

Githubでの同じ事例への対処法が沢山転がってるだろう

380 ：デフォルトの名無しさん：2014/07/28(月) 13:01:40.77 ID:JUp78osr

gitホスティングサービスが作りたいんですがヒントください
何で作りたいかというと↓のサービスが有料なのが気に入らないのでこれよりもいい物を作りたいからです
http://jp.techcrunch.com/2014/07/28/jp20140728universions/

381 ：デフォルトの名無しさん：2014/07/28(月) 13:20:52.08 ID:h3Aquzzx

OSSホスティング総合【SourceForge,GitHub,etc..】
http://peace.2ch.net/test/read.cgi/tech/1384821518/

382 ：デフォルトの名無しさん：2014/07/28(月) 14:44:42.56 ID:+qczOS9S

黒い画面て

383 ：デフォルトの名無しさん：2014/07/28(月) 17:20:29.69 ID:b9cEV/Qq

日本人が作るとおままごとツールになりそうでなんとも

384 ：デフォルトの名無しさん：2014/07/28(月) 18:20:02.23 ID:FHFsPlLG

開発方法寄りの話になるんだけど、
フレームワークで開発者が作ったもの置くディレクトリと、フレームワーク自体のライブラリのディレクトリが混在してたりする。phpとか。ログの出力先まで含まれていたり。
gitに含めるのはどこまで?

385 ：デフォルトの名無しさん：2014/07/28(月) 18:30:18.38 ID:0rL2fBex

設定ファイルのデフォルトが示していればディレクトリも入るんじゃ？
セットアップのスクリプトが生成するようにすれば不要かもね。

386 ：デフォルトの名無しさん：2014/07/28(月) 18:45:28.43 ID:WkBzZDWV

あー、今ちょうどそんなプロジェクトやってる。
同じプロジェクトだったりしてw

387 ：デフォルトの名無しさん：2014/07/28(月) 18:56:57.67 ID:bfSVrt1T

同僚が2chに質問してたら退職も辞さない

388 ：デフォルトの名無しさん：2014/07/28(月) 19:29:29.32 ID:0rL2fBex

同僚がすげーキーボード叩いてる、
お、がんばってるな、とモニター覗き込む、
なんか掲示板に質問を一生懸命書いている…

コードの割に叩く回数が多いと思ったのはコレか！

389 ：デフォルトの名無しさん：2014/07/28(月) 19:57:06.47 ID:FHFsPlLG

人のプロジェクト引き継ぐと、開発したものじゃないものも大量に入ってて、どこ見ていいかわかんなかったりするんだよね。
例えばdjangoだとprojectごとでなく、appだけ入れておいた方が使いやすいと思うんだ。
mavenとかは余計なものが含まれなくて見やすい。

390 ：デフォルトの名無しさん：2014/07/28(月) 20:11:31.94 ID:Wt0X9vvC

環境再構築したときにそのまま使うファイルはignore
それ以外全部Git

391 ：デフォルトの名無しさん：2014/07/28(月) 20:15:35.59 ID:WkBzZDWV

バイナリとかどうしてる

392 ：デフォルトの名無しさん：2014/07/28(月) 20:25:25.88 ID:Wt0X9vvC

忘れてた
バイナリとIDEやプロジェクトの設定ファイルも除外
他人が入れて邪魔になるもんは大体入れんやろ

393 ：デフォルトの名無しさん：2014/07/28(月) 21:08:52.61 ID:0rL2fBex

最初だけ必要、でも同期されると邪魔、だけど時々大きく変わる場合同期が必要・・・

サンプルファイルをリネームコピーで使ってもらって説明にそう明記かな？

394 ：デフォルトの名無しさん：2014/07/29(火) 23:47:58.65 ID:ZWA+OWxm

全部禁止にしてから個別に管理するものを指定するために.gitignoreにこうかきました
*
*.*
.gitignore
!test/*.js
これだとtest/test.jsがgit statusに出て来ません
test/test.jsは作って有ります
どう修正したらいいですか？

395 ：デフォルトの名無しさん：2014/07/30(水) 07:09:44.67 ID:SFUuJg+H

*
*.*
.gitignore
!/test
/test/*
!/test/*.js

396 ：デフォルトの名無しさん：2014/07/30(水) 12:27:46.44 ID:q1vJpBfq

なぜ馬鹿は笑ってゴマカス

397 ：デフォルトの名無しさん：2014/07/30(水) 15:09:39.87 ID:x/403miQ

>>394
http://quartet-communications.com/info/technology/13642

398 ：デフォルトの名無しさん：2014/07/31(木) 03:13:30.62 ID:SIeAhRnd

EGitの質問ってこのスレでいいのかな？

399 ：デフォルトの名無しさん：2014/07/31(木) 03:24:03.69 ID:ipo4JPES

>>398
Eclipse統合M35【Java/C++/Ruby/Python/Scala】
http://peace.2ch.net/test/read.cgi/tech/1405391739/

400 ：デフォルトの名無しさん：2014/07/31(木) 03:29:48.85 ID:SIeAhRnd

他のGitクライアントはこのスレでよくて
プラグイン形式のGitクライアントはアカンのか
わかったよ

401 ：デフォルトの名無しさん：2014/07/31(木) 06:46:03.60 ID:gyCr5AMO

こっちでもいいとおもうけど
あっちのほうが答えられる人多いかもね

402 ：デフォルトの名無しさん：2014/07/31(木) 12:08:31.40 ID:jdJsZ4Jc

プラグインありにすると
Azure のひとも流れ込んできそう

403 ：デフォルトの名無しさん：2014/07/31(木) 16:50:59.03 ID:MnJeD9xE

Git 2.0.4 リリース
https://github.com/git/git/releases/tag/v2.0.4

404 ：デフォルトの名無しさん：2014/07/31(木) 17:09:33.92 ID:uBAJx71I

もうgit 2.1.0の開発はじまってんのか

405 ：デフォルトの名無しさん：2014/07/31(木) 21:59:02.03 ID:w9LroIYe

そりゃそうだろ。
開発は止まることなく続くんだから
2.0がリリースされたら2.1の開発の開始よ。

406 ：デフォルトの名無しさん：2014/07/31(木) 22:26:16.95 ID:WgloAiw2

おれみたいなショボグラマはリリースノートの長さにビビる
ソフトウェアを作るって大変なんだな

407 ：デフォルトの名無しさん：2014/07/31(木) 23:35:44.21 ID:uCJCqnN7

プログラミングの技能は関係ないだろ

408 ：デフォルトの名無しさん：2014/07/31(木) 23:55:37.91 ID:KWL6BjZO

予定は未定ですから
ここまでやった目安にしてるVerとかリリース番号は

409 ：デフォルトの名無しさん：2014/08/01(金) 01:05:09.48 ID:qcYKpf5p

もうちょいメンテナンスしてからでもいいと思うんだよ２．１

410 ：デフォルトの名無しさん：2014/08/01(金) 04:04:44.68 ID:7R/51h0c

>>404
並行開発のためのブランチじゃないか。

411 ：デフォルトの名無しさん：2014/08/01(金) 05:30:01.08 ID:Mjd2jJg4

GitHub微妙にレイアウト変えんなよ
間違って違う機能のボタン押しちゃったじゃないか

412 ：デフォルトの名無しさん：2014/08/01(金) 10:11:50.93 ID: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 される

413 ：デフォルトの名無しさん：2014/08/01(金) 11:29:11.79 ID:HYcTfRZh

バージョン番号が細分化されてるソフトは不安定なソフトである象徴ｗ

414 ：デフォルトの名無しさん：2014/08/01(金) 12:14:59.79 ID:j/JylWKV

Unix文化圏は x.y.z のバージョン番号がわりと普通

415 ：デフォルトの名無しさん：2014/08/01(金) 12:58:26.33 ID:KQKeUN6R

>>413
firefoxをdisるのはもっとやれ

416 ：デフォルトの名無しさん：2014/08/01(金) 13:59:39.14 ID:c/SITlPI

>>415
え？今は31だぞ

417 ：デフォルトの名無しさん：2014/08/01(金) 15:21:40.83 ID:HYcTfRZh

メインバージョンが頻繁に上がるソフトは主流ではない、主流から外れたソフトｗ

418 ：デフォルトの名無しさん：2014/08/01(金) 15:43:48.75 ID:5YlCHfl7

細かく分かれてるのはサポートと製品管理に力を入れてるってことじゃねーの

419 ：デフォルトの名無しさん：2014/08/01(金) 16:06:36.71 ID:f/bFolqg

2.6.32-431.23.3.el6

420 ：デフォルトの名無しさん：2014/08/01(金) 16:34:28.73 ID:UcA9GDEc

>>418
ちげーよ

421 ：デフォルトの名無しさん：2014/08/02(土) 00:52:36.46 ID:SZsUPcoF

>>417
ウェッブ業界人に人気のChrome先生をdisるのはやめろ

422 ：デフォルトの名無しさん：2014/08/05(火) 09:38:21.98 ID:wIW++7Ni

Git 2.1.0-rc1 リリース
https://github.com/git/git/releases/tag/v2.1.0-rc1

423 ：デフォルトの名無しさん：2014/08/05(火) 10:34:04.15 ID:hWvlZYlP

リリースノートの日本語ぐらい書けや

424 ：デフォルトの名無しさん：2014/08/05(火) 13:26:33.16 ID:z3s8hGoL

お、どうしたどうしたｗ

425 ：デフォルトの名無しさん：2014/08/05(火) 23:52:18.73 ID:64utEkfv

Git2.0Winインストーラまだかよ

426 ：デフォルトの名無しさん：2014/08/06(水) 00:08:09.00 ID:GxwqgVuS

git2.0の使いたい機能があるの？それとも2.0以前のバグに悩まされてるの？

427 ：デフォルトの名無しさん：2014/08/06(水) 00:19:37.21 ID:IlVwDJHj

Macが2.0だから

428 ：デフォルトの名無しさん：2014/08/06(水) 00:38:57.57 ID:Tye/sJpW

cygwin使っとけ

429 ：デフォルトの名無しさん：2014/08/10(日) 08:23:27.47 ID:aTEKyeJh

http://www.buzzword.jp/img/face10.png

430 ：デフォルトの名無しさん：2014/08/10(日) 20:12:45.54 ID:dsJn6Bct

guro

431 ：デフォルトの名無しさん：2014/08/10(日) 21:23:21.99 ID:46zegaug

kaba

432 ：デフォルトの名無しさん：2014/08/12(火) 09:29:02.31 ID: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
と表示させたいです

433 ：デフォルトの名無しさん：2014/08/12(火) 09:44:11.02 ID:lLNyag2q

git log --follow bar.c

434 ：デフォルトの名無しさん：2014/08/12(火) 10:02:09.04 ID:CaL42KsB

Thx!!

435 ：デフォルトの名無しさん：2014/08/12(火) 23:58:44.30 ID:F2vV/z0S

SourceTree1.6betaでUTF-8の日本語のdiff文字化けが直っていました
https://twitter.com/sourcetree

436 ：デフォルトの名無しさん：2014/08/13(水) 23:46:46.70 ID:0VzL4TYP

最初のコミットってどのあたりですればいい？
全然コンパイルどころか形もなってない段階のから？
それとも部分的なコンパイルくらいは可能な段階になったあたり？
はたまたテスティングやアルファ版と呼ばれるくらいの段階？

437 ：デフォルトの名無しさん：2014/08/13(水) 23:56:34.28 ID:FF7HYwuu

・空の.gitignore置いたら
・Readme書いたら
・プロジェクトファイルやソリューションファイル、メイクファイルなどを作成したら
・仮のmain()書いたら

個人的には…開発環境が決め打ちなら3番目や環境によっては4番目、リポジトリサービスが決め打ちなら2番目、何も無いなら1番目かなあ

438 ：デフォルトの名無しさん：2014/08/14(木) 00:06:25.41 ID:UwSdLV//

作業履歴は1から残しとくべきだよね

439 ：デフォルトの名無しさん：2014/08/14(木) 00:11:59.96 ID:mP75ikG7

コンパイルすら通らない段階からコミットしていいのですね

440 ：デフォルトの名無しさん：2014/08/14(木) 00:36:51.50 ID:DeyF+ee0

完成直前のデータ消失上等ならコミットしないでもいいんじゃねーの

441 ：デフォルトの名無しさん：2014/08/14(木) 00:37:21.42 ID:K2fde6cH

最近だと最初にベースとなるコードをツールで自動生成することが多いんで
まずはその生成前と後の状態をコミットしちゃうな

442 ：デフォルトの名無しさん：2014/08/14(木) 02:09:36.84 ID:56cGoOWs

開発時の作業はブランチを切ってやるもの
ならマスターブランチの履歴も汚れない

443 ：デフォルトの名無しさん：2014/08/14(木) 02:21:00.12 ID:cpAbF84S

バージョン管理でえらく潔癖症な人多いな

444 ：デフォルトの名無しさん：2014/08/14(木) 02:45:25.37 ID:UiK3whtS

>>443
バージョン管理ソフトはバックアップソフトじゃないからね。
直近の1週間分のコードがあればいいとかいうわけじゃない。

コミットはどんな修正をしたか、またはどんな修正をするかを
表しているので、変なコミットを作るのはよくないよ。

445 ：デフォルトの名無しさん：2014/08/14(木) 02:53:22.08 ID:9Vu8tjE9

日付フォルダにうんざりした人が使うものだからな

ｇｄｇｄなら日付フォルダと大差ないじゃんって話になってしまう

446 ：デフォルトの名無しさん：2014/08/14(木) 03:05:53.73 ID:ytFl/Oa9

適当にコミットして後で潰したり並べ替えたりすればいいんだよ
変数名関数名然り、こういう時の手際でおつむの差が出る

447 ：デフォルトの名無しさん：2014/08/14(木) 03:14:26.01 ID:UiK3whtS

>>446
すっかりgitになれてしまって、
色々なファイルを修正しつつ、定期的にコードをコミットする段階で
git add -pとかで一部だけコミットして、いくつかのコミットを
意味のある単位に並び替えたりコミットをまとめたりという作業が
スムーズにできるようになったよ

ほんとgitは開発に便利。

448 ：デフォルトの名無しさん：2014/08/14(木) 11:25:35.52 ID:XPpNgzhX

確かにファイルを保存するタイミングでコミットする癖がついた。rebaseしてsquashしてmerge。
流れとか気にせず目の前にあるコードにだけ集中できるのがこんなに快適だとは思わなかったよ。

449 ：デフォルトの名無しさん：2014/08/16(土) 03:15:24.55 ID:UcWHe/+M

msysgit
Git-1.9.4-preview20140815

450 ：デフォルトの名無しさん：2014/08/16(土) 05:30:09.74 ID:7Fp1jvse

Rebaseをドラッグ＆ドロップでできるとこまでGUI化したツールができたら面白そう
事務職も使いだすだろう

451 ：デフォルトの名無しさん：2014/08/16(土) 05:51:17.63 ID:LOtWkDZk

>>450
> Rebaseをドラッグ＆ドロップでできるとこまでGUI化したツールができたら面白そう

それは無理。

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

無理なのは、rebaseした時に起きるコンフリクトの解消。
単純に難しいというのもあるし、
バイナリは解消できない（一報を捨てることしか出来ない）
それは「すなわちデータが消えた」という騒ぎになる。

452 ：デフォルトの名無しさん：2014/08/16(土) 21:56:22.07 ID:UcWHe/+M

https://github.com/git/git/blob/v2.1.0/Documentation/RelNotes/2.1.0.txt

453 ：デフォルトの名無しさん：2014/08/18(月) 20:43:47.81 ID: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

454 ：デフォルトの名無しさん：2014/08/18(月) 20:54:26.50 ID:IPiH7YvP

msysgitの2.0はよ

455 ：デフォルトの名無しさん：2014/08/20(水) 19:50:34.58 ID:b2jSERqi

新しいSourceTree行選択後ハンクに戻れないじゃん
クソアプデ

456 ：デフォルトの名無しさん：2014/08/21(木) 01:34:03.06 ID:Nk//m6zY

「アプデ」の三文字を見た瞬間鳥肌が立った

457 ：デフォルトの名無しさん：2014/08/21(木) 01:46:32.19 ID:tOl9rabw

花言葉は「進捗が遅れ気味」

458 ：デフォルトの名無しさん：2014/08/21(木) 04:47:49.84 ID:e2XVI0jx

git使い始めてみたけどかなり良いね
上の方のレスを参考にして、まずブランチ切って、適当に作業して、
ある程度まとまったらgit merge --squashでそのブランチの内容全てを一度でコミットする
という使い方に落ち着いた

459 ：デフォルトの名無しさん：2014/08/21(木) 06:33:14.84 ID:Dozm2kfh

適当に作業してる途中はブランチでコミットしないの？

460 ：デフォルトの名無しさん：2014/08/21(木) 06:39:52.57 ID:e2XVI0jx

もちろんするよ
merge --squashをするとブランチに適用されてるコミットをすべてひとまとめにして
一度のマージで本ブランチに適用できる
その際にコミットもしなきゃいけないから一度のコミットという表現を使った

461 ：デフォルトの名無しさん：2014/08/24(日) 21:45:44.50 ID:52mNGxWX

15時間でわかるgitってどう？

462 ：デフォルトの名無しさん：2014/08/24(日) 22:47:01.58 ID:xfU4T7hj

16時間は必要そうな印象を受けた

463 ：デフォルトの名無しさん：2014/08/24(日) 23:06:32.86 ID:0LPRT5si

アマで見たとこよさげ
今度立ち読みしたい

464 ：デフォルトの名無しさん：2014/08/25(月) 00:38:40.81 ID:py1PbdDs

>>461
たまたま今日買ってきて3時間目まで読んだところだが
CLIなんて面倒臭くてやってられんぜ
俺はSouceTreeでいくぜって人にはよさそう

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

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

んなもの、ネットにいくらでもあるだろって人には
15時間で分かるGitはヌルくて高いだけの本かも。
ざーっと、全体を読んだ限りだと、
”SourceTree　使い方”とかでググって手に入る情報ばっかりだし、
要領の良い人、本が嫌いな人には不要な本

465 ：デフォルトの名無しさん：2014/08/25(月) 02:19:16.20 ID:yZn9y/8B

ネットで調べりゃなんでも分かる、ってまあ他でも良く言われるけど、結局
本買う人って時間を金で買ってることでしょ。
わざわざ探している時間の方がもったいない、時間単金の高い人というか。
その辺りは大切というか、ヒマで貧乏な人と優先順位とか価値観が違うからねえ。
あと上の本よりはやっぱり「GitHub実践入門」の方が良書と思う。

466 ：デフォルトの名無しさん：2014/08/25(月) 02:23:05.61 ID:OTL7uAT+

情報の量質共にネット以下のくだらない本が増えたのも事実

467 ：デフォルトの名無しさん：2014/08/25(月) 02:33:56.63 ID:py1PbdDs

p66〜の競合の解決
って説明の部分だと、いきなりコンフリクト解決の方法の話になる

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

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

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

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

と変なところで尻切れトンボになってる。
まあ、技術評論社の初版第1刷だし、こんなもん？

468 ：デフォルトの名無しさん：2014/08/25(月) 05:40:22.74 ID:qum3FgxP

>>465
時間を節約したい人こそ要点だけつまめるネットのほうが向いてる
ゴミ情報しかない場合もあるがGitは充実してる
本のほうが順序だって読み進めるので時間かかるうえに
入門レベルの本じゃ結局肝心の細部はネットで実例を探したほうが的確な情報を得られる

あとまあ件の本だがいくらCLIを避けたところでRebaseまわりはコマンド使うことになると思う
こないだSTのGUIでコンフリクトのあるリベースしようとしたら強制終了されてcmdで直した
エラーの解消はだいたいGUIじゃ詰まるだろうし強制プッシュもできなかったよな？
GUIだけで使おうと思ってもかえって苦行なので要所要所でCLIを覚えるべき
なおGitHub実践入門はCLIの学習には使えないのでその用途で買ってはいけない

469 ：デフォルトの名無しさん：2014/08/25(月) 09:06:55.86 ID:85j5blVH

本は、全体を通して体系的に知識を整理出来るのがいいのよ
記憶の中でおおよそページのあの辺りに書いてあったなって
知識と物理的位置が紐付いて記憶出来るのもいい。
個別の問題解決に対してはネットの方が早いし詳細が得られると感じてる

スレチですな

470 ：デフォルトの名無しさん：2014/08/25(月) 11:34:31.85 ID:V08rwKRx

一般的に、本ほどまとまっているサイトは無い。

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

本300ページに相当するサイトはあるのか？
と考えれば自ずと理解できるだろう。

471 ：デフォルトの名無しさん：2014/08/25(月) 11:39:09.96 ID:ksmxv1nf

>>470
msdnは本というより図書館な感じ
まず棚を探さないといかんってのがね…

472 ：デフォルトの名無しさん：2014/08/25(月) 11:41:19.15 ID:7ENIkGwq

詳しいところは英文だからね

473 ：デフォルトの名無しさん：2014/08/25(月) 12:43:14.79 ID:C0s8ILgV

Gitの仕組みさえ理解したら、UIは陸亀さんでいいような希ガス
svnも陸亀さんなので両方入れるとコンテキストメニューでアレだが

474 ：デフォルトの名無しさん：2014/08/25(月) 18:00:46.08 ID:ksmxv1nf

Tortoiseってリクガメだったのか、ウミガメとは違うのね

475 ：デフォルトの名無しさん：2014/08/25(月) 18:07:02.98 ID:l2Fadlu9

俺の長年の調査によるとウミガメは turtle のようだ

476 ：デフォルトの名無しさん：2014/08/25(月) 19:11:19.20 ID:qD2gbKMt

gitを使いこなせない（というかバージョン管理を使いこなせない）

git add .
git commit -m "some update"

の全く無意味な動作の繰り返しだは

477 ：デフォルトの名無しさん：2014/08/25(月) 19:13:33.72 ID:qD2gbKMt

どうしても雑多な書き換えが多くてコメントをまとめられない
もっと細かな単位でコミットしていけばいいんだろうけど
どうしても不精だから雑多な変更等が溜まってからコミットするから適当なコメントがつけられない

478 ：デフォルトの名無しさん：2014/08/25(月) 19:48:48.33 ID:KUe7O5sS

add -pというものがあるのじゃよ

479 ：デフォルトの名無しさん：2014/08/25(月) 20:00:14.51 ID:yjE0cHrF

分類してまとめるのもスキルのうち

480 ：デフォルトの名無しさん：2014/08/25(月) 21:06:21.83 ID:ISmNy6hh

適当なタイミングで適当な小さいコミットをしまくってrebase -iできれいにまとめるってのもあるんじゃよ
git-nowってコマンド作ってそうやってる人もいるみたい

481 ：デフォルトの名無しさん：2014/08/25(月) 23:13:30.25 ID:C0s8ILgV

>>474
海亀はタートルやからね

482 ：デフォルトの名無しさん：2014/08/25(月) 23:50:37.85 ID:QhfqmC/d

あいつら海亀なのに下水道に住んでたのか

483 ：デフォルトの名無しさん：2014/08/26(火) 00:04:19.90 ID:mhCqY7ev

useBitmap = true だとなんか調子悪い。。

484 ：デフォルトの名無しさん：2014/08/26(火) 05:13:51.51 ID:tGns6ZHL

結局、一度馴れてしまえばコマンドが一番楽なのかな

485 ：デフォルトの名無しさん：2014/08/26(火) 05:52:36.84 ID:NQFYEExI

ずっとコマンドラインで使ってたけど
IDE組み込みのGit関連機能も慣れるとなかなか便利だよ
まあコマンドラインでやったほうが早いとかコマンドライン必須なこともあるけど
だいたいはIDE側だけで済む

486 ：デフォルトの名無しさん：2014/08/26(火) 08:30:49.41 ID:+r6eU4rX

せんせーemacsのexecute-extended-commandから使うのはIDE側ですかー? コマンドですかー?

487 ：デフォルトの名無しさん：2014/08/26(火) 09:00:21.23 ID:7aPILC/T

自分でタイプしないなら前者になるんじゃないの？ってどうでもいい話だったね

488 ：デフォルトの名無しさん：2014/08/26(火) 09:52:19.13 ID:oyYbyyhj

元気のGUIはコマンドカタカタ打たなくてもマウスクリックだけでブランチいじれるのでそっちのほうがラク

489 ：デフォルトの名無しさん：2014/08/27(水) 01:04:07.93 ID:E5NysQ8U

試してみるか？ 俺だって元コマンドーだ

490 ：デフォルトの名無しさん：2014/08/27(水) 01:20:08.22 ID:DkXXItR4

てめぇなんか怖かねえ

491 ：デフォルトの名無しさん：2014/08/27(水) 02:30:33.45 ID:eiNaMy6m

こんなの飛行機じゃないわ！羽のついたGNUよ！

492 ：デフォルトの名無しさん：2014/08/27(水) 08:39:15.33 ID:E5NysQ8U

どこで使い方を習った？
15時間で分かるGitを読んだのよ！

493 ：デフォルトの名無しさん：2014/08/28(木) 00:41:35.30 ID:j/KGK/aT

勝手にフォークしてソースは盗む、スパゲティにする、俺のコードをマージしろなんて突然メチャクチャは言い出す。
かと思ったらバイナリファイル管理論争に巻き込んで大勢死人は出す、挙句Githubでソーシャル開発とか、あんた人間なの！？
お次はrebaseときたわ。2ちゃんねらが、あんたを炎上させようとしたから助けたわ。そうしたら私まで追われる身よ！

494 ：デフォルトの名無しさん：2014/08/28(木) 12:39:43.40 ID:pLtajWiU

やっぱダラダラ長いとネタの面白さもガタ落ちだな

495 ：デフォルトの名無しさん：2014/08/28(木) 12:47:49.81 ID:Q4RzOOjO

野郎ぶっスカッシュしてやる！

496 ：デフォルトの名無しさん：2014/08/29(金) 00:14:52.86 ID:0lr9wl8v

git reset --hard

497 ：デフォルトの名無しさん：2014/08/29(金) 00:45:07.44 ID:t+ZmPWDd

rm -rf $(git rev-parse --git-dir)

498 ：デフォルトの名無しさん：2014/08/29(金) 03:42:56.43 ID:dVjZbmRE

でかくなったファイルを分割するとき(だいたい真っ二つにすると思ってもらっていいです)
それぞれの断片の履歴を追えるようにするにはどうしたらいいですか?
どちらかが new file になってしまうのですが…

499 ：デフォルトの名無しさん：2014/08/29(金) 06:13:20.06 ID:bRof6i8E

追うオプションがあるだろ

500 ：デフォルトの名無しさん：2014/08/29(金) 08:57:31.48 ID:dduCj2SP

>>496
ワロタ

501 ：デフォルトの名無しさん：2014/08/29(金) 11:16:27.08 ID:9OWc8ATu

>>498
やり方が間違ってるよ。そういう場合はリファクタリングをしよう。

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

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

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

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

最後に不要になったAのコードとテストを削除する。

502 ：デフォルトの名無しさん：2014/08/29(金) 11:33:27.01 ID:TBK0UDGJ

>>498
分割してnew fileのままコミット。
$ git show -C30

503 ：デフォルトの名無しさん：2014/08/29(金) 17:23:54.33 ID:dVjZbmRE

>502
blameでもいけますね。ありがとうございます。

504 ：デフォルトの名無しさん：2014/08/30(土) 15:34:04.65 ID:4WQaR9Xf

お前らの所って、もう2.xに移行した？
良くなってるならうちも移行しようか考えてる

505 ：デフォルトの名無しさん：2014/08/30(土) 15:37:38.87 ID:AoE8b4bU

3.xが出たら2.xに移行しようと思う
メジャーバージョンは常にひとつ下で追いかけるほうがいい

506 ：デフォルトの名無しさん：2014/08/30(土) 15:46:53.99 ID:yHmhwtLF

こいつ2.x出る前何使ってたんだ

507 ：デフォルトの名無しさん：2014/08/30(土) 15:59:05.20 ID:AoE8b4bU

何だお前は、俺は生まれたときからそういう姿勢で生きてきたとでも思ってんのか

508 ：デフォルトの名無しさん：2014/08/30(土) 16:29:41.63 ID:4WQaR9Xf

git ってこないだ1.9 が出て、移行しようと思ってたらあっという間に2.1だからな。
Linux のKernel並に3カ月おきに新しいのを出していくつもりなんかな？

509 ：デフォルトの名無しさん：2014/08/30(土) 16:33:45.21 ID:JAT13qNM

常時2を使ってるが、特に問題ないな

510 ：デフォルトの名無しさん：2014/08/30(土) 16:39:38.95 ID:QM2vBzSO

msysgit使いなので2.xに移行できませんえん

511 ：デフォルトの名無しさん：2014/08/30(土) 17:31:04.08 ID:eMjEoUcz

>>503
非難でいけるんだ

512 ：デフォルトの名無しさん：2014/08/30(土) 22:26:33.50 ID:fZGGp6dM

git reset

513 ：デフォルトの名無しさん：2014/08/31(日) 01:06:46.53 ID:b8tx/Oby

>>507
違うの？ 尊敬したのに損した

514 ：デフォルトの名無しさん：2014/08/31(日) 01:33:47.19 ID:DCfsrrwi

ここでメジャーバージョンが上がったのに大した意味はないよね
マイナーバージョンと同レベルの変更だし、ここで止めても仕方ないよ

515 ：デフォルトの名無しさん：2014/09/01(月) 12:34:03.18 ID: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

516 ：デフォルトの名無しさん：2014/09/01(月) 12:59:42.75 ID:ZKcbbA9k

で、何をしたらどうなったの

517 ：デフォルトの名無しさん：2014/09/01(月) 19:49:14.98 ID:09g8ZS7k

>>512
git init
git commit --allow-empty -m "Empty"

518 ：デフォルトの名無しさん：2014/09/02(火) 01:06:47.06 ID:6AEFW/2e

allow empty で作ったコミットが
rebase で消されたり
rebase -i の中断要因になったり
あれどうにしてほしいなあ。
なんでrebaseにもallow emptyがないんだろう？

519 ：デフォルトの名無しさん：2014/09/02(火) 01:23:39.86 ID: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したらいいのかわかりません
どのブランチで編集したか調べる方法を教えてください

520 ：デフォルトの名無しさん：2014/09/02(火) 02:21:12.97 ID:fFmOi5Cz

シェルの履歴を見ればどのブランチをチェックアウトした状態だったか分かるんじゃね

521 ：デフォルトの名無しさん：2014/09/02(火) 02:48:39.82 ID:H6/bQ2I4

>>518
allow-empty の説明を読んで俺は使わなくなったよ

522 ：デフォルトの名無しさん：2014/09/02(火) 02:54:30.64 ID:4W2L00Fu

>>518
allow-emptyを何の用途に使ってるの？

この機能って、

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

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

rebaseしたくなった時って言うのは、何かのコミットが存在しているわけで、
その時は自動的に消えて欲しいわけで、よく考えられた機能だなぁって
思ってるんだけど。

523 ：デフォルトの名無しさん：2014/09/02(火) 11:03:20.34 ID:AWoqLo6D

git config local user.name "zxy"すると
git config -lでみるとglobalに登録したuser.nameが残ってて2つ表示されるんですけどこれで大丈夫ですか？

524 ：デフォルトの名無しさん：2014/09/02(火) 13:14:58.49 ID:YTDTwniL

git stashって新規作成ファイルは保存してくれないんですけど
誤ってmasterで作業してた時、今の作業状態を別ブランチに映す場合はどうやってますか？

525 ：デフォルトの名無しさん：2014/09/02(火) 13:47:47.99 ID:ja7HZQJ9

新規ファイル（管理されてないファイル）なら
設定ファイルなどと同様、ブランチ移動に関して
全く関与しないので、普通にstashして移動してstash popできるが？

526 ：デフォルトの名無しさん：2014/09/02(火) 13:49:11.62 ID:ja7HZQJ9

まあ、オプションで新規ファイルとかもstashしてくれるけど、
間違ったブランチで作業して移動する時に、オプション使ったこと無い。

527 ：デフォルトの名無しさん：2014/09/03(水) 12:10:14.74 ID:YNir0Y9+

gitlab入れたけどメモリ1GB環境だと重くてすぐ消した

528 ：デフォルトの名無しさん：2014/09/03(水) 12:19:42.32 ID:Bk50IRfN

>>527
これ見たの？
https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/requirements.md

529 ：デフォルトの名無しさん：2014/09/03(水) 13:57:46.99 ID:4uEkndM7

gogs軽いぞ
中華でベータだけど

530 ：デフォルトの名無しさん：2014/09/03(水) 14:10:55.95 ID:7PpuCQwz

ベータは動作環境が狭いからなあ、、、ってgolangなのか

531 ：デフォルトの名無しさん：2014/09/04(木) 17:16:52.33 ID: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

532 ：531：2014/09/04(木) 17:17:30.34 ID:so/xiuM/

masterブランチを汚さず別ブランチで作業してコミットをまとめるのってこれで合ってますか？

533 ：デフォルトの名無しさん：2014/09/04(木) 18:18:50.75 ID:r3dec82J

いいと思うよ

534 ：デフォルトの名無しさん：2014/09/04(木) 18:30:31.98 ID:agrvnvoZ

>>532
merge --squashの方が楽じゃない?

535 ：デフォルトの名無しさん：2014/09/04(木) 19:47:20.06 ID:SNsufMBL

最近仕事で触り始めたので勉強中です(SourceTreeと一緒に使っています)
GitFlowでリリースブランチを切るとリリース対象のファイルが表示されますが、
そのリリース対象のファイルをコマンドライン等で反映先のディレクトリに
リリースするような方法はないでしょうか？

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

宜しくお願いします。

536 ：531：2014/09/04(木) 19:51:21.34 ID: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

537 ：デフォルトの名無しさん：2014/09/05(金) 00:52:21.25 ID:XPb05F9M

>>536
狙ってマージコミットを作ったのならそれでいいんじゃね
もし一本道になって欲しいなら設定を見直したほうがいい
そのログなら通常fast-forwardになるはずだから、常に--no-ffを使う設定がされてそう

538 ：デフォルトの名無しさん：2014/09/05(金) 23:45:43.67 ID:SZP3vN/x

gitconfigで
[merge]
ff = false
って設定してありました
確か昔どこかの記事やらスライドを見て設定したかもしれません

539 ：デフォルトの名無しさん：2014/09/06(土) 00:12:55.88 ID:LAlkQfIz

masterブランチにはREADME.mdしか置いてありません。
htmlファイルを作るためにhtmlブランチを作りました。
htmlファイルが完成したのでjavascriptでhtml要素を操作するコードを書くのでjavascriptブランチを作ります。
さて、この場合htmlブランチからjavascriptブランチを作ってhtmlブランチとjavascriptブランチをマージして完成したらmasterとマージするのがいいのか、
masterブランチからjavascriptブランチを作って、htmlブランチとjavascriptブランチを1つずつmasterブランチにマージしていくのがいいのか
どれが定番なのか教えてください

540 ：デフォルトの名無しさん：2014/09/06(土) 00:27:36.41 ID:mpUeuKJh

めんどくせえ
git-flowCI覚えて出直してこい

541 ：デフォルトの名無しさん：2014/09/06(土) 00:28:04.39 ID:mpUeuKJh

flowとCI

542 ：539＠代行レス：2014/09/06(土) 01:13:35.47 ID:nVESKkfI

ありがとうございますflow と ci覚えてきます

543 ：デフォルトの名無しさん：2014/09/06(土) 11:23:01.20 ID:MWnQ8CWe

git checkout ハッシュ

過去の履歴に戻った後に最新のコミットにハッシュを使わないで戻る方法を伝授してください

544 ：デフォルトの名無しさん：2014/09/06(土) 11:43:50.26 ID:kRNHJ6eY

開発では常にmergeをno-fast-forwardに統一するべきである
pull requestを送る場合は常にrebaseでコミットをまとめてから送るべきである

545 ：デフォルトの名無しさん：2014/09/06(土) 11:46:11.69 ID:kRNHJ6eY

ブランチは必ずmasterから分岐させるべきである
ごちゃごちゃしたブランチのコミットを整理するためにrebaseを使うべきではない
masterからブランチを派生させることを心得ておけばrebaseを使う必要がなくなる

546 ：デフォルトの名無しさん：2014/09/06(土) 12:31:08.84 ID:wsRqGyAq

>>544-545
場合によりけり

「○○の場合は」と書いてないお前の書き込みに
価値はない。

547 ：デフォルトの名無しさん：2014/09/06(土) 12:50:50.05 ID:Y581x5zV

まだmergeもrebaseも使ったこと無いから勉強になります

548 ：デフォルトの名無しさん：2014/09/06(土) 13:35:24.57 ID:Spv4j8U1

>>545に同意
>>546ルールを決めないから「場合によりけり」って曖昧な事を抜かす。こういう奴が一番リポジトリを壊す

549 ：デフォルトの名無しさん：2014/09/06(土) 13:41:13.86 ID:YGfPHROT

だからどんなルールにするかが場合によりけりなんだろ

550 ：デフォルトの名無しさん：2014/09/06(土) 14:06:03.08 ID:oq2XdgVR

クソルールでダメなリポジトリを作らないようにしましょうって話じゃないの？

551 ：デフォルトの名無しさん：2014/09/06(土) 14:20:16.91 ID:ssgHRQI6

銀の銃弾を探しに行くのは構わんが錫の銃弾を売りに来るのはやめろ

552 ：デフォルトの名無しさん：2014/09/06(土) 16:37:53.08 ID:iAGDf1Qx

>>543
git reset --hard ブランチ

553 ：デフォルトの名無しさん：2014/09/06(土) 19:34:47.94 ID:nW4UkLOS

>>550
まったくもってその通り。

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

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

素人がルール作るなっての。

554 ：デフォルトの名無しさん：2014/09/06(土) 19:39:26.80 ID:xP6IFMix

>>546
どんな場合のことを言っているのか分からないのでそのレスから価値が生まれてこない。

555 ：デフォルトの名無しさん：2014/09/06(土) 19:57:34.14 ID:SoF/8Pjd

>>554
え？ それで言い返したつもり？ｗ

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

じゃあ言ってることはあってるじゃんｗ

556 ：デフォルトの名無しさん：2014/09/06(土) 21:13:44.84 ID:A8IOA0fF

>>545
マスターの先頭ににリリースバージョンでないコミットを置かれると第三者が利用しにくい
二行目も作業内容の一時的な保存を禁止されるのでこれも不便

教えて乞食か煽り目的かな？

557 ：デフォルトの名無しさん：2014/09/06(土) 21:28:01.09 ID:WRbx/+ja

それはタグを付けろよ

558 ：デフォルトの名無しさん：2014/09/06(土) 21:31:50.31 ID:WRbx/+ja

書き漏れたけどstashもな

559 ：デフォルトの名無しさん：2014/09/06(土) 21:53:32.48 ID:A8IOA0fF

論争煽りと書くべきだった

560 ：デフォルトの名無しさん：2014/09/07(日) 22:02:25.60 ID:nk2Tw+Xt

同一リポジトリの他のブランチのファイルを今のブランチにコピーする方法ありませんか？

561 ：デフォルトの名無しさん：2014/09/07(日) 23:37:55.06 ID:GBwjwKNH

checkoutでできなかったっけ？

562 ：デフォルトの名無しさん：2014/09/08(月) 00:12:41.29 ID:WRBqI71e

指定したブランチ全体をチェックアウト
特定のファイルをチェックアウト
指定したブランチの特定のファイルをチェックアウト

563 ：デフォルトの名無しさん：2014/09/08(月) 00:22:41.19 ID:qdDflaMT

masterブランチは.gitignoreしか置いてない状態で
開発用ブランチAでファイルを作成・編集しコミットして開発用ブランチBに切り替えました
開発用ブランチBで同じファイルを作成して編集してたんですがコミットしないと開発用ブランチAに戻れません。
一時的にAにもどってまたBで作業したいんですがどうやってコミットせずにAに切り替えられますか？

564 ：デフォルトの名無しさん：2014/09/08(月) 00:23:17.05 ID:NAv86kVA

gitのやり方にこだわらなければ普通にできるっしょ
リポジトリ外に一度当該ファイルだけコピーしてチェックアウトしてからそれを持ってくればいいだけなんだし

565 ：デフォルトの名無しさん：2014/09/08(月) 00:23:46.20 ID:NAv86kVA

>>564は>>560宛てね

566 ：デフォルトの名無しさん：2014/09/08(月) 00:33:25.80 ID:crPwpkXi

>>563
スタッシュ

567 ：デフォルトの名無しさん：2014/09/08(月) 00:48:37.10 ID:+kFenLfh

俺ならいっそコミットしちゃうかな
どうせsquashでまとめちゃうし

568 ：デフォルトの名無しさん：2014/09/08(月) 02:03:41.81 ID:qdDflaMT

>>566
Bでまだコミットしてない状態だとstashに追加できません
>>567
コミットするしか無いですかね＞＜

569 ：デフォルトの名無しさん：2014/09/08(月) 02:31:07.78 ID:NAv86kVA

それはstashの使い方というかgitを理解してない感じだね

570 ：デフォルトの名無しさん：2014/09/08(月) 06:44:26.76 ID:VKDX8UYB

とにかくgit stashしてみればええんやで

571 ：デフォルトの名無しさん：2014/09/08(月) 08:20:59.95 ID:p1aOvVUP

git squash
とか
git stash
と間違えて
git sqash
と書きそう

572 ：デフォルトの名無しさん：2014/09/08(月) 08:39:16.65 ID:0SpwLnTc

>>568
git stash save -u

573 ：デフォルトの名無しさん：2014/09/08(月) 08:52:05.03 ID:BIFfl8OH

>>568
>>564 は無視か？
どうせ中身はファイルなんだから、もうコピーして戻してやりたいことやってからコピーしたファイル戻せよ
いったいどういうgitの使い方したらそうなるんだよ

574 ：デフォルトの名無しさん：2014/09/08(月) 11:01:43.42 ID:4rWcgI79

>>552
detached from なんちゃらってでました
git checkout ブランチ
これでいけました

575 ：デフォルトの名無しさん：2014/09/08(月) 11:07:08.95 ID:C+vypWur

>>574
????
それは単にブランチを移動しただけでは????

576 ：デフォルトの名無しさん：2014/09/08(月) 15:05:57.76 ID:U7j04x7O

ブランチ移動といってもそのブランチのHEADになるからいいんでないの

577 ：デフォルトの名無しさん：2014/09/08(月) 16:13:28.41 ID:0SpwLnTc

そもそも>>543は単にブランチ移動したかっただけなんじゃないか

578 ：デフォルトの名無しさん：2014/09/08(月) 16:36:32.50 ID:dO+Fd23e

HEAD^とHEAD@{0}違う？

579 ：デフォルトの名無しさん：2014/09/08(月) 16:49:04.96 ID:dO+Fd23e

コミットを取り消したいからgit reset --hard HEAD@{0}ってやったのに戻らないから
git reset --hard HEAD@{1}ってやって{}の部分を2とか3とかいろいろやったらreflogがごちゃごちゃしてしまいました
一番最新のコミットに戻すにはreflogでHEAD@{番号}を調べる方法しかないですか？

580 ：デフォルトの名無しさん：2014/09/08(月) 17:20:11.18 ID:0SpwLnTc

>>579
最新のコミットを取り消すためにHEAD@{〜}とか使う必要無い
reflogを理解できてないのにHEAD@{〜}を使うなよ
その状態から元に戻すにはreflog見るのが簡単だけど

581 ：デフォルトの名無しさん：2014/09/08(月) 17:33:52.09 ID:K8Q6FwjA

>>579
HEAD@なんて表記やめてlog見て戻りたいところのハッシュ値で指定してやったら?

582 ：デフォルトの名無しさん：2014/09/08(月) 17:40:52.81 ID:dO+Fd23e

>>

583 ：デフォルトの名無しさん：2014/09/08(月) 17:45:44.75 ID:0SpwLnTc

自分も慣れてないころresetとかrebaseする前には git log --oneline の結果を数行コピペしておいたな

584 ：デフォルトの名無しさん：2014/09/08(月) 17:48:49.27 ID:dO+Fd23e

>>580
git reset --hard HEAD^を使えってことですね承知しました

>>581
git reset --hard HEAD@{3}
と
git reset --hard ハッシュ
で
同じ所には戻れたんですがここから最新のコミットに戻る方法がreflogから番号もしくはハッシュ調べてそれを
git reset --hard 番号orハッシュ
で最新に戻れるんですがHEAD@{番号}よりハッシュのほうがいいのは何か利点があるのでしょうか？

585 ：デフォルトの名無しさん：2014/09/08(月) 17:55:56.63 ID:0SpwLnTc

>>584
HEADいじる度にHEAD@{番号}が指すコミットは変わっちまうだろ？
おまえさんも>>579でごちゃごちゃになったと書いてるじゃないか
ハッシュが指すコミットはどんなにHEADをいじくり回しても変わらないから混乱しない

586 ：デフォルトの名無しさん：2014/09/08(月) 18:12:44.41 ID:dO+Fd23e

あああなるほど、わかりました
これからはハッシュでやります

587 ：デフォルトの名無しさん：2014/09/08(月) 22:00:31.11 ID:WRBqI71e

reflogを変えずにcheckoutがしたい、

588 ：デフォルトの名無しさん：2014/09/08(月) 23:26:45.85 ID:ndMr36Oi

HEADを直接弄ればいいんじゃね

589 ：デフォルトの名無しさん：2014/09/08(月) 23:36:58.07 ID:1ZckH/5F

やはりローカルにsvnの俺様リポジトリこさえて併用するのがベストだな

590 ：デフォルトの名無しさん：2014/09/09(火) 00:18:50.36 ID:u4zCVMc4

>>587
ブランチ名@{番号}の方ならcheckoutじゃ変わらんぞ

591 ：デフォルトの名無しさん：2014/09/09(火) 22:34:56.56 ID:qWpgvOTn

Git 2.1リリース
http://www.infoq.com/jp/news/2014/09/git21-release-whats-new

592 ：デフォルトの名無しさん：2014/09/09(火) 22:38:42.96 ID:SubzMxGE

2.1リリースから何日たってると思ってんだよノロマ

593 ：デフォルトの名無しさん：2014/09/09(火) 22:53:14.21 ID:gKfU6Dxq

msysgitのリリースはよ

594 ：デフォルトの名無しさん：2014/09/09(火) 23:35:10.97 ID:Q2wSWXGV

もう Cygwin でいいよ。

595 ：デフォルトの名無しさん：2014/09/09(火) 23:57:07.76 ID:6C8BCa3g

>>592
＞作者： Sergio De Simone , 翻訳者 笹井 崇司 投稿日 2014年9月8日
ノロマは笹井に対して言ってるんだよな？

596 ：デフォルトの名無しさん：2014/09/10(水) 00:25:05.56 ID:yTyA0sMk

msysgitってそんなに違うのか？
統合して欲しいが、どうなんだろ

597 ：デフォルトの名無しさん：2014/09/10(水) 01:34:09.48 ID:LZqJBGfN

Cygwin版はCygwin自体が最大の枷だわな
あれを枷と思わない人には良いのかも知れんが

598 ：デフォルトの名無しさん：2014/09/10(水) 02:16:09.01 ID:Kk1nHIci

>>595
自信満々にここに貼りつけた>>591==>>595に対してに決まってんだろ

599 ：デフォルトの名無しさん：2014/09/10(水) 05:03:54.50 ID:4LqmTc+v

windowsが枷

600 ：デフォルトの名無しさん：2014/09/10(水) 07:06:01.73 ID:SIxieRJp

他人に対する罵倒だと思い込まないと精神が死ぬ

601 ：デフォルトの名無しさん：2014/09/10(水) 07:15:50.74 ID:MqMxecSj

>>591==>>595だと思い込まないと精神が死ぬ

602 ：デフォルトの名無しさん：2014/09/10(水) 09:56:29.50 ID:av5QsdtA

>>593
同意

>>594
cygwin は捨てて良い

>>596
違う

>>597
同意

>>599
嫌なら使うなよ

603 ：デフォルトの名無しさん：2014/09/10(水) 12:24:04.63 ID:4LqmTc+v

>>602
俺はwindows使ってないよ

604 ：デフォルトの名無しさん：2014/09/10(水) 13:39:34.62 ID:UVf8c3/I

Cygwinが枷になってる人達はどんな環境でどんなプログラム言語使ってるのか気になる
コマンドプロンプトな環境で使ってたりするの？

605 ：デフォルトの名無しさん：2014/09/10(水) 14:00:31.43 ID:D/KQTinb

msysgitだとエクスプローラの右クリックメニューで色々できるからじゃね

606 ：デフォルトの名無しさん：2014/09/10(水) 14:12:57.98 ID:D/KQTinb

cygwinにgit入れてみたけど
msysgitのgit bashみたいに現在のブランチ名を表示するのってどうやんの？

607 ：デフォルトの名無しさん：2014/09/10(水) 14:17:09.16 ID:D/KQTinb

gitのコマンドやスイッチの補完もmsysgitのgit bashにはあるけど
cygwinでやる場合はこれらは自分でセットせにゃならんのかな

608 ：デフォルトの名無しさん：2014/09/10(水) 14:19:48.68 ID:D/KQTinb

msysgitのインストールフォルダにあるgit-prompt.shをそのまま持ってくればいいかな

609 ：デフォルトの名無しさん：2014/09/10(水) 14:24:08.72 ID:UVf8c3/I

>>606-607
bash-completionとgit-completionっていうパッケージが入ってれば補完されるかな
プロンプトはPS1を適当に設定すればいい

610 ：デフォルトの名無しさん：2014/09/10(水) 14:59:27.04 ID:D/KQTinb

補完はgit-completionで出来た
ありがとね

611 ：デフォルトの名無しさん：2014/09/10(水) 15:11:10.16 ID:D/KQTinb

gitkが起動しないし解決法探るの面倒草…
これさcygwinでgitやる場合は導入にかなり手間かかるね
msysgitでいいや

612 ：デフォルトの名無しさん：2014/09/10(水) 15:19:14.08 ID:/KH51cxp

cygwinは窓から捨てろ

613 ：デフォルトの名無しさん：2014/09/10(水) 15:21:16.53 ID:UVf8c3/I

使いこなせないならしょうがないな

614 ：デフォルトの名無しさん：2014/09/10(水) 15:36:40.99 ID:1paU2wgw

cygwinを使うならvirtualboxにlinuxを入れろ
cygwinの知識なんて何にも訳にたたねえよ

615 ：デフォルトの名無しさん：2014/09/10(水) 15:59:36.12 ID:D/KQTinb

それは手段が目的になってねえか？
Windows上で開発してるのをgitで管理するって話なんだから仮想環境にlinux構築する意味ねえし
たしかにCygwinはLinux使うより手間や面倒多いし、Cygwinはどうしてもって奴用の手段だな
git使いたいだけならcygwinよりもmsysgitかその他のWindows用gitクライアント使うのが一番いいな

616 ：デフォルトの名無しさん：2014/09/10(水) 16:46:31.97 ID:D/KQTinb

やっとCygwinでgitkを起動できたがやっぱmsysgitのほうがいいわ

617 ：デフォルトの名無しさん：2014/09/10(水) 17:04:25.68 ID:1paU2wgw

>>614
そうだよcygwin使いはcygwinを使うことが目的になってんだろ

618 ：デフォルトの名無しさん：2014/09/10(水) 17:36:42.05 ID:UVf8c3/I

>>614
Windows上で動かすIDEがgitコマンド使ってるんでWindows側で動いてないとダメなんだよ
それだけならmsysgitでもいいんだけど、msysgitには無いUnixコマンドも使いたかったりするんでCygwinになる

>>617
Cygwinにこだわってるわけじゃない
Windows上でなるべく制限の無いUnixコマンドが使いたいんだよ
バーチャルマシン上のLinuxや別のLinuxマシンにログインしたりもするがそれとは用途が違うんだ

619 ：デフォルトの名無しさん：2014/09/10(水) 19:49:05.34 ID:CyIX6v51

本日のあぼーん


↓

620 ：デフォルトの名無しさん：2014/09/10(水) 19:59:56.78 ID:XdlQkfFb

ここは俺たちの日記帳だ！

621 ：デフォルトの名無しさん：2014/09/10(水) 20:25:18.54 ID:OJY5gFsq

毎月このスレッドを作業記録として提出しましょう

622 ：デフォルトの名無しさん：2014/09/11(木) 17:23:25.71 ID:/FTCw4HW

msysgitのgit bashとCygwinのbashの違いはパス名で大文字小文字を区別するかしないかの違いがあるね

623 ：デフォルトの名無しさん：2014/09/11(木) 17:27:15.91 ID:SNUYrGFx

/cygdrive/c/hoge
と
/c/hoge
の違いもなかったっけ

624 ：デフォルトの名無しさん：2014/09/11(木) 18:13:14.92 ID:92Rqckl0

>>622-623
その辺はどちらも設定次第じゃない？

625 ：デフォルトの名無しさん：2014/09/11(木) 18:54:51.03 ID:/FTCw4HW

設定で変えられるかというより
大半がデフォルトの設定のまま使える
なるべく手間や面倒が省けるほうがいいっしょ

626 ：デフォルトの名無しさん：2014/09/11(木) 19:12:18.48 ID:92Rqckl0

それだったら「デフォルト設定に違いがあるね」って最初から書こう

627 ：デフォルトの名無しさん：2014/09/11(木) 21:40:05.41 ID:eOvHxe0S

2.2 ドラフト

628 ：デフォルトの名無しさん：2014/09/13(土) 22:45:09.53 ID:QgtGsY/0

デザインが決まらないので5個ぐらい作る場合
ブランチを5つ作るのか
master
design1
design2
design3
design4
design5

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

こんなふうに思いつきましたがどうやるのが一番いいですか？

629 ：デフォルトの名無しさん：2014/09/13(土) 23:30:29.19 ID:OGauqNqE

どっちでも一緒だと分かれば、さらに一歩git使いに近づいてる

630 ：デフォルトの名無しさん：2014/09/14(日) 01:03:24.60 ID:pOqGUkHF

ディレクトリを分けなくてよくなるわけではない

631 ：デフォルトの名無しさん：2014/09/14(日) 01:05:48.64 ID:hXoVPBM+

後者のやりかたのほうが俺は好きかな
masterを汚さずにやるから

632 ：デフォルトの名無しさん：2014/09/14(日) 01:09:36.99 ID:a/rqPd2y

>>631
どうやって前者の方法で
masterを汚すの？

633 ：デフォルトの名無しさん：2014/09/14(日) 19:07:15.19 ID:z5w391po

msysgitのgit bashやべえな
ファイル名の大文字小文字を変えるのを認識しやがらねえ
git mv file.txt File.txt
だと失敗
git mv file.txt file.txt.tmp
git mv file.txt.tmp File.txt
と二度やったらやっと登録できた

634 ：デフォルトの名無しさん：2014/09/14(日) 19:09:37.99 ID:a/rqPd2y

>>633
認識したら困るだろ。
cp a.txt A.txtってやったら、
A.txt （= a.txt） を削除してから、a.txtを読み取ってコピーすることになるんだぞ。
既に消されてるというのに。

635 ：デフォルトの名無しさん：2014/09/14(日) 19:15:57.12 ID:t5hepJjd

>>633
git mv -f file.txt File.txt

636 ：デフォルトの名無しさん：2014/09/14(日) 19:53:01.69 ID:/nrQFrnK

git mvって必要あるの？ファイルを移動したら勝手に追跡してくれるじゃん

637 ：デフォルトの名無しさん：2014/09/14(日) 20:26:24.05 ID:z5w391po

msysgitのgit bashだと普通に大文字小文字変えるだけではファイル名の変更が認識されないんだよ
File.txtに変えたのに内部ではfile.txtのまんま
>>633のようにgit mv２つを実行するとやっとrename file.txt -> File.txt と認識される、んでコミットすりゃ晴れて内部でもFile.txtになる

638 ：デフォルトの名無しさん：2014/09/14(日) 20:33:58.96 ID:t5hepJjd

>>636
git mv a.txt b.txt の代わりに mv a.txt b.txt すると、git add b.txt と git rm a.txt もしないといけないかな

639 ：デフォルトの名無しさん：2014/09/14(日) 20:40:10.82 ID:t5hepJjd

>>637
mv file.txt File.txt で変えてしまった後なら、
これでいい
git rm --cache file.txt
git add File.txt

640 ：デフォルトの名無しさん：2014/09/15(月) 01:12:30.44 ID:c0zpNvUD

共有(bare)リポジトリをDropboxに置く使い方があちこちで
紹介されていますが、リポジトリが壊れたりする危険性は
ないのでしょうか?
複数のcloneから同時にpushしたりしたら...
でも、ssh経由で共有する場合も同じような状況に
なりそうで、大丈夫だったりします?

641 ：デフォルトの名無しさん：2014/09/15(月) 01:37:45.54 ID:+Ldu6wso

dropboxが動いている時にファイルを更新したら最新ファイルがアップロードされなかった事があったから
dropbox起動中はgitの操作をしないほうがいいかもよ

642 ：デフォルトの名無しさん：2014/09/15(月) 01:45:31.18 ID:75pLEfoa

Dropboxが怖いなら無料のリポジトリサービスでも使えばいいだろＪＫ

643 ：デフォルトの名無しさん：2014/09/15(月) 05:02:51.46 ID:9UWhhSIJ

>>640
複数の場所で共有していると壊れるだろうね。

AとBの両方で作業したら
新しい方のファイルで更新されるし。

644 ：デフォルトの名無しさん：2014/09/15(月) 08:54:23.82 ID:fTGIYQla

>>633
ファイルシステムとそのAPIに文句を言うべきかと

645 ：デフォルトの名無しさん：2014/09/16(火) 21:22:17.79 ID:gF8SSz86

objectsの下のファイルがそろってさえいれば、headsは衝突してもどうにかなるんでは〜

646 ：デフォルトの名無しさん：2014/09/17(水) 19:31:27.50 ID:3n4VSMqM

Dropbox で bare リポジトリ共有って、そもそも開発者1人が前提なんじゃないんかね

Dropbox 上で安全にやるなら、公開個人リポジトリ＆中央リポジトリ管理者方式で
管理者が手動プルリクもどき頑張る、みたいなやり方かね
この場合のプルリクって、「僕のリポジトリクローンして○○ブランチを中央の master ににマージしてください」とかメール出すやつ

647 ：デフォルトの名無しさん：2014/09/17(水) 21:31:10.41 ID:nOBr1X2H

一時期複数人でDropbox&bundleやってた
これなら衝突は問題無いはずだけど操作が面倒で結局サーバーたてた

648 ：デフォルトの名無しさん：2014/09/17(水) 21:46:44.89 ID:bNvg7Npd

pushするときにロックファイルがあればpush失敗させればいいよ
フック書けばどうとでもできる

649 ：デフォルトの名無しさん：2014/09/19(金) 19:31:27.86 ID: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です

この現象の原因及び解決方法、またパーミッションの変え方などを教えて下さい。

650 ：デフォルトの名無しさん：2014/09/20(土) 10:44:57.72 ID:Xc99Cp2d

git statusをやるとファイルとディレクトリ名がでますが
ディレクトリの中に含まれているファイルとかも確認したい時はどうやるんですか？

651 ：デフォルトの名無しさん：2014/09/20(土) 19:53:38.75 ID:I6a2TTeN

ｌｓ -alR

ディレクトリの中に含まれているファイルのとかの何を確認したいの？

652 ：デフォルトの名無しさん：2014/09/20(土) 20:05:43.56 ID:W3bmv3cS

>>650
git status -u

653 ：デフォルトの名無しさん：2014/09/21(日) 07:36:29.91 ID:vYPwYIwQ

Git 2.1.1 リリース
https://github.com/git/git/releases/tag/v2.1.1

654 ：デフォルトの名無しさん：2014/09/22(月) 12:56:54.30 ID:/Ev3c58M

今までコミットしたときのnameとemailを書き換えたいんですがどうやれますか？
それが無理なら１からリポジトリ作るしかないですよね

655 ：デフォルトの名無しさん：2014/09/22(月) 13:32:54.45 ID: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
> メールアドレスの一括変更

656 ：デフォルトの名無しさん：2014/09/22(月) 13:35:46.03 ID:xorcTHrm

歴史の捏造ニダ
朝日NHKの得意技ニダ

657 ：デフォルトの名無しさん：2014/09/22(月) 13:36:02.21 ID:3YN9TFHL

>>654
http://qiita.com/seamountain@github/items/d70216a5bc16a88ed932#1-3

658 ：デフォルトの名無しさん：2014/09/23(火) 22:16:54.41 ID:mVrPrFOF

Update draft release notes to 2.2

659 ：名無しさん：2014/09/24(水) 17:04:03.73 ID:Qh5bz0XT

Gitならgitlabが一番いいと個人的には思う

660 ：デフォルトの名無しさん：2014/09/24(水) 17:07:19.80 ID:27efG/Se

いきなり何の話よ

661 ：649：2014/09/24(水) 21:00:45.42 ID:hKGm5mT1

>>649ですが自己解決しました。
post-commitのスクリプトの一行目に
#!/bin/sh
を追加したところ動きました(windowsなのでいらないと思っていました)
お騒がせしました。

662 ：デフォルトの名無しさん：2014/09/24(水) 21:57:41.06 ID:im18uCU9

>>661
＞error: cannot spawn .git/hooks/post-commit: No such file or directory
このエラーメッセージでググれば一番最初にヒットするのがmsysgitでも #! つけろだからな

663 ：デフォルトの名無しさん：2014/09/28(日) 01:34:48.16 ID:S3ctTNeN

git notesにtodoって書いたりする？

664 ：デフォルトの名無しさん：2014/09/28(日) 01:42:50.80 ID:RZX9lPG9

は？

665 ：デフォルトの名無しさん：2014/09/28(日) 02:08:11.01 ID:S3ctTNeN

msysgit使ってるんだけど
git notes add -m "〜"で書き込むとgit notes showでもちゃんと日本語で出るんだけど
-mを使わずvim起動して書き込むとgit notes showで日本語が出ず文字化け状態になる
git diffでも文字化けはするけど同じ状態
でもgit commitでは-mで書いてもvimで書いてもgit logやgit showでちゃんと日本語が表示される
この違いは何で？

666 ：デフォルトの名無しさん：2014/09/28(日) 02:09:44.62 ID:S3ctTNeN

gitkやgit guiでは日本語表示は問題ないんだけど
git bashだとShift_JISは相性悪かったりすんのかね

667 ：デフォルトの名無しさん：2014/09/28(日) 02:13:08.66 ID:S3ctTNeN

ちがうな
gitkだとgit notes -mで書いた日本語がnotesのコミット見ると文字化けしてる、git bashの逆だ
でもnotesをくっつけたコミットオブジェクトのコメント欄ではgit bash同様に文字化けしてない

668 ：デフォルトの名無しさん：2014/09/28(日) 02:24:17.67 ID:V6A0YAer

msysは知らんけど今時文字コードはutf-8で統一しとくものでは？
gitkの文字コードは、git config gui.encoding utf-8

669 ：デフォルトの名無しさん：2014/09/28(日) 03:15:33.58 ID:S3ctTNeN

どうもgit bash上で入力したものは(コードページは932なのに)全部utf-8になるみたいだね
謎なのは
git commitなどで起動するvimでの日本語入力はutf-8になるけど
git notes addで起動するvimでの日本語入力はShift_JISになってしまう

>>668
ソースコードにutf-8を使えないのでどうしようもない

670 ：デフォルトの名無しさん：2014/09/28(日) 03:20:33.14 ID:S3ctTNeN

nkfを導入してエディタをvimから別のに変更するしかないか

671 ：デフォルトの名無しさん：2014/09/28(日) 03:26:58.26 ID:Z+K69R8V

>>670
$ chcp.com 65001
でどうだろう

672 ：デフォルトの名無しさん：2014/09/28(日) 03:28:15.63 ID:L8CmCeM8

>>669
＞ソースコードにutf-8を使えないのでどうしようもない
SJISしか解釈しないソフト？
それとも社是？

673 ：デフォルトの名無しさん：2014/09/28(日) 03:42:36.32 ID: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を認識できない

674 ：デフォルトの名無しさん：2014/09/28(日) 03:49:03.75 ID:S3ctTNeN

>>670の方策でFAのようだからスレ汚しスマソでおやすみ

675 ：デフォルトの名無しさん：2014/09/28(日) 10:04:21.42 ID: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も足しておいた方がよさそう

676 ：デフォルトの名無しさん：2014/09/28(日) 12:17:40.34 ID:HJquXbDq

windowsはコマンドの引数にUTF-8の文字列を渡すと正しく受け取れない
標準入力で渡せば問題無い

677 ：デフォルトの名無しさん：2014/09/28(日) 12:23:04.07 ID:/z7vQ2zP

その手があったか！(bar)

678 ：デフォルトの名無しさん：2014/09/28(日) 12:34:35.51 ID:5eGkIoPA

cygwin使えよ

679 ：デフォルトの名無しさん：2014/09/28(日) 14:59:33.29 ID:urGSMMdQ

msysgitのgit notesだけiconvが機能してない

680 ：デフォルトの名無しさん：2014/09/28(日) 15:46:18.48 ID:urGSMMdQ

$ iconv -f sjis -t utf-8 source.file | cat

681 ：デフォルトの名無しさん：2014/09/28(日) 16:00:23.77 ID:urGSMMdQ

もしくは
$ cat source.file | iconv -f sjis -t utf-8 | iconv -f utf-8 -t sjis

682 ：デフォルトの名無しさん：2014/09/28(日) 16:13:34.60 ID: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のファイルを渡しても正しく表示される

683 ：デフォルトの名無しさん：2014/09/28(日) 16:22:01.64 ID: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の出力と整合性がとれない

684 ：デフォルトの名無しさん：2014/09/28(日) 18:51:05.51 ID:O58wbOXV

>>675でFA

685 ：デフォルトの名無しさん：2014/09/29(月) 12:35:23.79 ID:AsmfGn0v

一応、git-bashもShellshockアウトだな

686 ：デフォルトの名無しさん：2014/09/29(月) 12:50:04.02 ID:PkV280SH

やはりな

687 ：デフォルトの名無しさん：2014/09/29(月) 15:44:57.22 ID:yq8evElj

Windows版EmacsのVCでgitを使ってると-mでコミットメッセージを渡すから
utf-8でメッセージを書くとおもいっきりログが化ける

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

もう少し詳細が知りたい人がいたら続き書く

688 ：デフォルトの名無しさん：2014/09/29(月) 19:14:19.81 ID:WBYZ6MwM

msysGit 使ってるけど UTF-8 で全然問題ない

689 ：デフォルトの名無しさん：2014/09/29(月) 19:21:36.88 ID:yq8evElj

>>688
参考までにどういう手順(使ってるシェルとか)でコミットメッセージを書いてるか教えてくれ

690 ：デフォルトの名無しさん：2014/09/29(月) 19:30:25.36 ID:DImY60Do

半角英数記号だけにして日本語を使わなければWindowsだろうとエンコード関係なくて無問題

691 ：デフォルトの名無しさん：2014/09/29(月) 22:14:27.58 ID:pB5pThCu

msysgitでShift JIS運用してる奴けっこういるんだなあ

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

この辺全部Shift JISに統一してるの？すげー危なっかしいんだけどｗ

692 ：デフォルトの名無しさん：2014/09/29(月) 22:44:47.36 ID:0qyZ7Y3Q

nihongo

693 ：デフォルトの名無しさん：2014/09/30(火) 13:57:13.53 ID:CMcuQWVl

ファイル経由だと問題ない

694 ：デフォルトの名無しさん：2014/09/30(火) 14:38:49.81 ID:slTS89tz

Git for Windowsがバージョンアップでやっと2.0かなとおもったらshellshock対策だったでござる

695 ：デフォルトの名無しさん：2014/09/30(火) 15:05:01.92 ID:GTUBo0R8

じらしやがる

696 ：デフォルトの名無しさん：2014/10/01(水) 08:57:22.72 ID:0Rd3PZj2

Git 2.1.2 リリース
https://github.com/git/git/releases/tag/v2.1.2

697 ：デフォルトの名無しさん：2014/10/01(水) 19:15:25.68 ID:DMZSGVKB

今書いてるコードを失敗作だったから特定のコミットまで戻ってコードを書きたい場合は
git checkout ハッシュ
でいいですか？

698 ：デフォルトの名無しさん：2014/10/01(水) 19:27:03.97 ID:9jQnFvsv

そんな質問よりも、ここで失敗作という単語を選ぶそのセンスに興味がある

699 ：デフォルトの名無しさん：2014/10/01(水) 20:24:46.22 ID:Z2lIlKnF

失敗も含めて記録です

700 ：デフォルトの名無しさん：2014/10/01(水) 20:33:58.26 ID:tKVi5+VE

>>697
ブランチをどんな風に使ってるかによる

701 ：デフォルトの名無しさん：2014/10/01(水) 20:47:35.90 ID:T6Ti1llJ

checkoutじゃなくてresetじゃね？

702 ：デフォルトの名無しさん：2014/10/01(水) 21:21:20.45 ID:tKVi5+VE

適当にブランチ作ってコード書いてるときは俺だったらこうするね
git checkout -b 新しいブランチ名 ハッシュ

git checkout ハッシュ の後に git checkout -b 新しいブランチ名 でもいい

703 ：デフォルトの名無しさん：2014/10/01(水) 22:41:43.10 ID:h9BOR5vi

どこにもpushしてない前提なら

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

でとりあえず失敗作も取っておく

704 ：デフォルトの名無しさん：2014/10/01(水) 22:45:53.29 ID:2NEK614A

CUIでgit使ってる人に聞きたいんだけど
ハッシュって直接タイプしてる？コピペ？

705 ：デフォルトの名無しさん：2014/10/01(水) 23:17:33.05 ID:ZUQc71vZ

>>703
なんでpushしたらの前提なのかおしえてください

706 ：デフォルトの名無しさん：2014/10/01(水) 23:22:06.58 ID:FCLAwuTf

pushしてないなら、ね。
pushしてしまったブランチ名を変えてしまうと、後でわかりにくくなるから。
だからpushしてあるなら、今作業中のブランチはそのままにして、新しいブランチ名で作業開始するなあ。

707 ：デフォルトの名無しさん：2014/10/03(金) 00:32:08.85 ID: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がコミットされてないってことですか？

708 ：デフォルトの名無しさん：2014/10/03(金) 01:07:29.08 ID:lJ+fGULR

>>707
addでステージングしてない、
またはステージングしたあとに変更されて、ステージとワークの差分が残った。
commit -aしたら。

709 ：デフォルトの名無しさん：2014/10/03(金) 01:46:23.01 ID:tlslc8rS

gui使え捗る

710 ：デフォルトの名無しさん：2014/10/03(金) 06:37:37.72 ID:uoUrCJpL

この辺のGitの動きを知らなかったらUI関係なく使い物にならん

711 ：デフォルトの名無しさん：2014/10/03(金) 19:52:57.55 ID:0fNFd6Zz

Changes to be committed: ならaddはされてるんじゃ？

712 ：デフォルトの名無しさん：2014/10/03(金) 21:49:40.10 ID:AgIiHhZF

>>704
とりあえず先頭5文字ぐらいタイプして一意じゃなかったらコピペかな。

713 ：デフォルトの名無しさん：2014/10/03(金) 22:01:30.75 ID:lJ+fGULR

>>711
ファイルをaddするんじゃない、差分をaddするんだ。

714 ：デフォルトの名無しさん：2014/10/03(金) 22:41:09.35 ID:bwpHkU5/

そんなあなたにはMercurialがオススメ

715 ：デフォルトの名無しさん：2014/10/04(土) 15:44:59.48 ID:SmsUE6ND

add驚く

716 ：デフォルトの名無しさん：2014/10/04(土) 15:55:57.79 ID:klU9cMDD

あ？

717 ：デフォルトの名無しさん：2014/10/04(土) 18:48:11.03 ID:lz81iwIl

内藤やるやんwwwwwwww

718 ：デフォルトの名無しさん：2014/10/04(土) 19:52:27.34 ID:UfGxrzJu

>>707
それまさにコミット直前の状態。
多分コミットしようとしたときに何かエラーが起きて失敗してる。
git log で確認するべし。

719 ：デフォルトの名無しさん：2014/10/06(月) 13:34:47.78 ID:+251wIR0

git mv old.txt new.txt
してコミットした後に
一番最初にコミットした時のold.txtの内容をnew.txtに持ってきたい場合はどうやるんでしょうか？

720 ：デフォルトの名無しさん：2014/10/06(月) 16:13:08.43 ID:LCKE4ThM

gitのmvは古いファイル消して同じ内容の新しいファイル作るようなものだから
revertみたいな巻き戻し的な操作ではそういうのはできないんじゃないかなあ？
だからその最初のコミットのold.txtの内容でnew.txtを上書きしてコミットするしかないんじゃないの？

上書きするのはこんな感じかな
git cat-file blob 最初のコミットのハッシュ:old.txt > new.txt

721 ：デフォルトの名無しさん：2014/10/06(月) 16:49:30.61 ID:f7RfeMbE

コミットがold.txtファイル単体のものだったらrevertでnew.txtの内容がold.txtのものになったよ
戻したい時点のコミットに他のファイルもあると他のも戻されちゃうけど

722 ：デフォルトの名無しさん：2014/10/06(月) 16:50:08.14 ID: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

723 ：デフォルトの名無しさん：2014/10/06(月) 16:59:08.86 ID:LCKE4ThM

ためしてみた
たしかにrevertで新しいファイル名のまま中身だけ戻るわ
revertも元に戻すコミットを作るだけだから
mvのつながりさえ検知できるのなら、こんな芸当ができるってわけか

724 ：デフォルトの名無しさん：2014/10/06(月) 21:01:02.75 ID:5SQO2Mek

サブモジュールの循環参照ってありうる？

725 ：デフォルトの名無しさん：2014/10/07(火) 11:51:46.80 ID:bg20eE9e

gitを使ってnvmをインストールしたんですが
今入っているバージョンが0.16.1で最新版が0.17.2です
.nvmディレクトリでgit pullしたんですけど最新版になりません
こういうのってどうやってアップグレードするんでしょうか？

726 ：デフォルトの名無しさん：2014/10/07(火) 13:48:31.25 ID:42Rhg3Aa

>>725
そんなもんnodeのスレ行って聞けよ
やり方なんてリポジトリ次第だ
ちらっとREADME見る限りじゃ最新のタグをcheckoutする必要があるみたいだが

727 ：725：2014/10/07(火) 14:04:31.66 ID:62qC9bSD

>>726
いやリポジトリの内容を最新にしたいんですよ

728 ：デフォルトの名無しさん：2014/10/07(火) 14:18:40.49 ID:42Rhg3Aa

>>727
pullすればリポジトリは最新になってるよ
でもリポジトリを最新にしただけじゃディレクトリに展開されるファイルが最新になるわけじゃないんだよ
デフォルトのmasterブランチが最新とは限らないし
どのブランチやタグが最新の内容を指してるかとか
どうやって最新のブランチを使うべきかとかはリポジトリ依存

729 ：デフォルトの名無しさん：2014/10/07(火) 19:45:20.87 ID:Z7Aoevpe

あー初心者垢からしか評価こないんじゃーぬるぽ

730 ：デフォルトの名無しさん：2014/10/11(土) 00:02:08.18 ID:Yf2b8D8g

>>552
過去に編集したファイルを確認したいんですがこういう時ってどうやって戻るんでしょうか？
ブランチはmasterしか使用していません

731 ：デフォルトの名無しさん：2014/10/11(土) 00:53:01.04 ID:Rdrw9x2+

>>730
SourceTree

732 ：デフォルトの名無しさん：2014/10/11(土) 08:27:23.90 ID:cLKjQNHa

今Aというbranchをcheckoutしていて、別のBというbranchをAと同じcommitに持って来たいとき
こんな風にしてるけど、

$ git checkout B
$ git reset --hard A

最終的に作業ツリーの中身は作業前と同じになるけどタイムスタンプだけ変わってしまう。
作業ツリーに触らずに同じことをできないかな？

733 ：デフォルトの名無しさん：2014/10/11(土) 08:42:35.63 ID:Rdrw9x2+

>>732
zipで固めておくとか。

マジレスすると、そんな細かいことは気にしないのがgitを快適に使う秘訣だと最近気づいたよ。

734 ：デフォルトの名無しさん：2014/10/11(土) 08:50:58.68 ID:1vz5EW/S

>>732
git branch -D B
git checkout -b B
とかじゃダメなの？

735 ：デフォルトの名無しさん：2014/10/11(土) 08:54:32.95 ID:OrDwN+4S

タイムスタンプなんてチェックアウトするたびに変わるんだからどうしようもない

736 ：デフォルトの名無しさん：2014/10/11(土) 08:57:40.41 ID:8zrlM+r5

gitを改造すればいいじゃん

737 ：デフォルトの名無しさん：2014/10/11(土) 09:00:59.26 ID:u8e8Yi+s

ホントになあ
reset --hardだと部分的に元に戻すことができないからcheckout HEAD (ディレクトリ名)を使ったら
変更が無くても指定したディレクトリ以下全部作り直されるし

でも>>732のケースは>>734か、git branch -f B Aでいいと思う

738 ：デフォルトの名無しさん：2014/10/11(土) 09:18:27.51 ID:cLKjQNHa

>>737
ありがとう、バッチシです。
本来必要ないリビルドで何分も待たされるのをずっと我慢してた。

739 ：デフォルトの名無しさん：2014/10/11(土) 09:27:25.81 ID:1gHC+Rt5

>>731
それ使えません
linuxで定番ありますか？

740 ：デフォルトの名無しさん：2014/10/11(土) 10:23:56.57 ID:8zrlM+r5

percol と スクリプトと p4merge で過去差分を見るツール作った

741 ：デフォルトの名無しさん：2014/10/11(土) 14:24:23.48 ID:Rdrw9x2+

>>739
Linux用GUIクライアントのおすすめはSmartGit/Hgとgitgってのがあるらしい。
使ったことないけど。日本語がちゃんと使えるといいね…。
http://softwarerecs.stackexchange.com/questions/292/gui-for-git-and-mercurial-on-linux-similar-to-atlassian-sourcetree

742 ：デフォルトの名無しさん：2014/10/11(土) 16:07:33.78 ID:+RfzhL5s

>>730
普通に git checkout ハッシュ でいいのでは
戻りたい地点はgit logで知らべる

743 ：デフォルトの名無しさん：2014/10/11(土) 16:12:33.60 ID:aOjCrPms

gitbookくらい一通り読んでくればいいのに不精な人が多いんだなあ

744 ：デフォルトの名無しさん：2014/10/11(土) 16:41:25.60 ID:9AEIvNa2

>>742
そうするとブランチが

745 ：デフォルトの名無しさん：2014/10/11(土) 17:41:24.23 ID:1vz5EW/S

ブランチがなんだよ
とりあえず見るだけならエディタやIDEの機能を使うのがいいと思うんだが何使ってるんだ？
コマンドラインからでいいならとりあえずこれで見れる
git cat-file blob ハッシュ:ファイルのパス | less
じっくり見たいなら自分のリポジトリをcloneしてしまってもいい

746 ：デフォルトの名無しさん：2014/10/11(土) 18:13:32.74 ID:6HL2TmPS

>>730
git show $version:$filename
とかいうこと?

747 ：デフォルトの名無しさん：2014/10/11(土) 18:41:13.11 ID:N8j8zGao

過去のリビジョンに戻る時にgit checkoutはやるべきではない
git reset を使うべきだ

748 ：デフォルトの名無しさん：2014/10/11(土) 18:50:18.29 ID:0tst77Z4

過去のリビジョンをチェックアウトする時がcheckoutで
過去のリビジョンまでコミットを戻すのがresetだろ。

ぜんぜん違うものだって。そんな違いもわからんの？

749 ：デフォルトの名無しさん：2014/10/11(土) 19:08:30.34 ID:aOjCrPms

作業ファイル一式を入れ替えるのがcheckout
resetはブランチが参照するコミットを変更するのが主目的

750 ：デフォルトの名無しさん：2014/10/11(土) 19:09:00.88 ID:aOjCrPms

ブランチじゃねえHEADだ

751 ：デフォルトの名無しさん：2014/10/12(日) 07:03:10.69 ID:oWlxOy9Q

この辺よく分かってないんだけど、--hard リセットはresetとcheckoutを同時にやるって事なのかな？

752 ：デフォルトの名無しさん：2014/10/12(日) 10:38:52.27 ID:p0nnbQFv

checkoutは引数次第でいろんなことをするから
「checkoutをする」だけ言われても何を意図してるのかわからん

753 ：デフォルトの名無しさん：2014/10/12(日) 11:52:33.48 ID:e6aIROEn

>>752
>>730

754 ：デフォルトの名無しさん：2014/10/12(日) 12:23:19.27 ID:p0nnbQFv

>>753
過去に編集したファイルを見るためにcheckoutを使うとしても、
「過去のハッシュ」を指定してcheckout以外にも
「過去のハッシュ:ファイル名」を指定してcheckoutするとかでも見れるのはわかるよな？
前者はカレントブランチが変わってしまうけど、後者はそのままだ

755 ：デフォルトの名無しさん：2014/10/12(日) 12:54:05.07 ID:sOwm7/3X

linuxで過去の状態のファイルが見たいんなら，tigもいいと思うんよ

756 ：デフォルトの名無しさん：2014/10/12(日) 14:10:40.60 ID:IX57hp7+

featureブランチとかtopicブランチってあるけど
英和辞書のfeatureやtopicだと意味が分からん
gitではどういう意味で使われてるん？

757 ：デフォルトの名無しさん：2014/10/12(日) 14:30:11.95 ID:z1NIPMV8

機能と話題じゃねーの

758 ：デフォルトの名無しさん：2014/10/12(日) 21:07:29.18 ID:IX57hp7+

機能ブランチって特定の機能を作るってこと？
話題ブランチってちょっと意味が分からない

759 ：デフォルトの名無しさん：2014/10/12(日) 21:27:26.08 ID:N2wuPuuE

特定の機能を追加するっていうトピック・話題・テーマ、特定のバグを潰すってトピック

760 ：デフォルトの名無しさん：2014/10/12(日) 21:34:18.14 ID:z1NIPMV8

両方トピックじゃねーか！
間違ってはいない

761 ：デフォルトの名無しさん：2014/10/13(月) 10:39:05.48 ID: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できますか？

762 ：デフォルトの名無しさん：2014/10/13(月) 11:05:19.89 ID:Ka1C2n0c

$ git checkout master
$ git branch testtest origin/master
$ git rebase testtest
$ git push origin/master

これでどうよ？

763 ：デフォルトの名無しさん：2014/10/13(月) 11:11:11.28 ID:UiUWyauZ

すいません誰もいないと思って先走ってgit pullしたらコンフリクトしました
ありがとうございます

764 ：デフォルトの名無しさん：2014/10/13(月) 13:47:51.26 ID:yFRqmPNp

自分のところとコンフリクトしてんじゃね

765 ：デフォルトの名無しさん：2014/10/13(月) 23:03:04.45 ID:0GIv1UTW

あとはコンフリクトを解決すればOK

766 ：デフォルトの名無しさん：2014/10/14(火) 10:26:22.58 ID:8E9fzGhm

tortoiseGitでローカルにコミットしても
赤！アイコンが消えないでござる

767 ：デフォルトの名無しさん：2014/10/14(火) 14:50:34.16 ID:a754JoyQ

git branch feature/aaaみたいにスラッシュ区切りのブランチを見かけますが
これは何の意味があるんですか？

768 ：デフォルトの名無しさん：2014/10/14(火) 22:05:41.58 ID:F0kchRkJ

featureって意味があるよ！

769 ：デフォルトの名無しさん：2014/10/15(水) 06:17:23.46 ID:t4MHvgx0

ふゅーちゃーってたしか機能って意味もあるからなんか特化した開発してるんじゃない？

770 ：デフォルトの名無しさん：2014/10/15(水) 06:56:43.14 ID:ZR9Ve6JZ

ふゅーちゃーはfuture(未来)、feature(機能、特徴)はふぃーちゃー。

771 ：デフォルトの名無しさん：2014/10/15(水) 06:58:06.42 ID:t4MHvgx0

おーそーりー。

772 ：デフォルトの名無しさん：2014/10/15(水) 16:42:35.08 ID:B8bsm/f7

>>767
利点は知らないけど
.git/refs/heads 内にディレクトリが作られる
SourceTreeみたいなGUIクライアントがフォルダとして扱ってくれるからとか？

773 ：デフォルトの名無しさん：2014/10/20(月) 01:38:24.79 ID:6j05cluu

こんな新刊でてた。
読んだ人評価よろ。

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

そろそろ入門書や解説書が増えてきたし、リスト付くってテンプレに入れたいね。
各書の寸評も入れて。

774 ：デフォルトの名無しさん：2014/10/20(月) 02:46:47.42 ID:gc0RlShe

2chにそんなものいらん

775 ：デフォルトの名無しさん：2014/10/20(月) 06:21:53.91 ID:8ZypDjIK

高杉

776 ：デフォルトの名無しさん：2014/10/20(月) 08:41:42.03 ID:ZbmD4P58

４００ページか・・・
イエローページって呼ぶわｗ

777 ：デフォルトの名無しさん：2014/10/20(月) 09:20:28.20 ID:Xd0rYRkq

宣伝成功！！！！

778 ：デフォルトの名無しさん：2014/10/20(月) 10:27:00.91 ID:9PaXcFMy

マインスイーパ？

779 ：デフォルトの名無しさん：2014/10/20(月) 10:46:20.24 ID:5bAFSmmu

何十円なら買えるんだよ

780 ：デフォルトの名無しさん：2014/10/20(月) 12:12:25.60 ID:4QGk34Ml

ジャンプなんか400ページ超えてて
300円しないというのに。

781 ：デフォルトの名無しさん：2014/10/20(月) 12:29:43.87 ID:6InD2oEn

イエローページならなんと！

782 ：デフォルトの名無しさん：2014/10/20(月) 12:34:28.67 ID:Ze8iUggo

>>780
つまりGitの擬人化漫画を描けば良いと？

783 ：デフォルトの名無しさん：2014/10/20(月) 19:47:31.74 ID:kEWHmjOP

ジットちゃん

784 ：デフォルトの名無しさん：2014/10/20(月) 19:51:57.33 ID:qTy0O4wa

沈黙待機系少女じっとタン

785 ：デフォルトの名無しさん：2014/10/20(月) 19:52:16.07 ID:gc0RlShe

ツイッターで描いたら流行りそう

786 ：デフォルトの名無しさん：2014/10/20(月) 20:56:25.96 ID:ZbmD4P58

じっとタン「push・・・来ない・・・」

787 ：デフォルトの名無しさん：2014/10/20(月) 22:31:36.94 ID:wK6yDOM4

ジットじゃなくギットだとおもいまーっす

788 ：デフォルトの名無しさん：2014/10/20(月) 22:52:41.69 ID:aZfIvSfB

俺的にはジットの方が近いな。
何が正しいかといえばgitだろう。

789 ：デフォルトの名無しさん：2014/10/20(月) 23:02:37.46 ID:KfYW9NVG

gif(ジフ)、git(ギット)一貫してない！
でググってみたら、元の発音もそもそも一貫してないんだな

gifは本来はギフだろうが、設計者がjif(ジフ)が正しいと言ったようだ

790 ：デフォルトの名無しさん：2014/10/20(月) 23:02:39.90 ID:qTy0O4wa

>>786
イイねb

>>787
ふたご設定とか？

791 ：デフォルトの名無しさん：2014/10/20(月) 23:09:30.25 ID:kEWHmjOP

テーマ曲は「ギットギトにしてやんよ」

792 ：デフォルトの名無しさん：2014/10/20(月) 23:10:23.03 ID:qTy0O4wa

脂っぽくてヤダー。Orz

793 ：デフォルトの名無しさん：2014/10/20(月) 23:12:25.78 ID:gc0RlShe

バイキンマンポジで

794 ：デフォルトの名無しさん：2014/10/21(火) 01:05:27.81 ID:MKkuO4Nj

「ギットギトにしてやんよ」だったら、脂性でギットギトのデブオタが丁度いい

795 ：デフォルトの名無しさん：2014/10/21(火) 01:07:53.10 ID:dWXgLBxs

WindowsのOSが萌えキャラ化されたから
バージョン管理ソフトも萌えキャラ化される日も近いかもな
GITちゃんSVNちゃんCVNSちゃんHGちゃんBZRちゃん

796 ：デフォルトの名無しさん：2014/10/21(火) 01:12:09.79 ID:98IF0d26

VSSちゃん「ぶ・・・ぶっす・・・」

797 ：デフォルトの名無しさん：2014/10/21(火) 01:31:49.82 ID:rLdpxu5/

デザイナーもバージョン管理ソフト使ってるんだから誰かやってそうな気もするけど無いのか

798 ：デフォルトの名無しさん：2014/10/21(火) 06:13:36.21 ID:ndQNY/8a

作者がぎっとだと明言しとる

799 ：デフォルトの名無しさん：2014/10/21(火) 08:12:10.54 ID:8oGIBXRE

>>789
ローマ字読みを｢本来｣とは言えないんじゃ…
でもなんとなく英語風に読もうと思えば
gifはジフ、gitはギットって読めると思うんだけどな

800 ：デフォルトの名無しさん：2014/10/21(火) 10:00:13.51 ID:OGY/NnRX

gをジーと読むからだろうけし、略語由来は読み方がいろいろ
giftはギフト

801 ：デフォルトの名無しさん：2014/10/21(火) 12:09:20.75 ID:LDDYL1oQ

gingerはジンジャー

802 ：デフォルトの名無しさん：2014/10/21(火) 13:56:45.17 ID:3SFXCOz9

magitは?

803 ：デフォルトの名無しさん：2014/10/22(水) 03:30:24.61 ID:NoApm9kp

テクニカルタームとしてJITが存在するのに、gitをジットと読むわけないだろ。

804 ：デフォルトの名無しさん：2014/10/22(水) 08:38:44.29 ID:sB6ga6u2

magicはマジック
magitはマギット

805 ：デフォルトの名無しさん：2014/10/22(水) 09:49:48.53 ID:CQ3LWgmB

gitってフィンランド語だっけ？

806 ：デフォルトの名無しさん：2014/10/22(水) 11:17:33.32 ID:yVOzWn6d

両手の指をピストルのように構え前に突き出して叫ぶんだ。「ギット！！」

807 ：デフォルトの名無しさん：2014/10/22(水) 11:35:06.82 ID:G2nqW3Ft

intelligence インテリゲンチャ

808 ：デフォルトの名無しさん：2014/10/22(水) 15:36:23.51 ID:1vGBv3op

働けど働けど　我が暮らし楽にならず
Git 手を見る

809 ：デフォルトの名無しさん：2014/10/22(水) 15:47:47.36 ID:kKncjr9Q

GitGitだった

810 ：デフォルトの名無しさん：2014/10/22(水) 16:18:12.92 ID:yVOzWn6d

Git君は来ない 一人きりのクリスマスイブ

811 ：デフォルトの名無しさん：2014/10/22(水) 17:34:15.15 ID:09vRtLa/

GitGitにしてゃんょ

812 ：デフォルトの名無しさん：2014/10/22(水) 19:38:47.95 ID:mh35NEK4

君たちリポジトリは何個ぐらい持ってますか？

813 ：デフォルトの名無しさん：2014/10/22(水) 19:42:18.40 ID:DBSwOXHr

40くらいかな。

814 ：デフォルトの名無しさん：2014/10/22(水) 20:35:24.61 ID:rV+YylK+

Gigaはギガ
Giganticはジャイガンティック
だから命名した人がこう読む、というのがなけりゃどっちの読み方が正しいかは英語では決まらないでしょ。

815 ：デフォルトの名無しさん：2014/10/22(水) 21:15:08.52 ID:9Jwqj8Ni

オーレーはジャキガーン、歌鬼大Show

816 ：デフォルトの名無しさん：2014/10/23(木) 02:22:04.66 ID:QsQhyUlJ

danger

817 ：デフォルトの名無しさん：2014/10/23(木) 03:08:23.65 ID:9xQ1BkMO

ダンゲア？

818 ：デフォルトの名無しさん：2014/10/23(木) 06:51:15.76 ID:QsQhyUlJ

anger

819 ：デフォルトの名無しさん：2014/10/23(木) 07:47:48.13 ID:I5sCFcB1

git 来る��

820 ：デフォルトの名無しさん：2014/10/23(木) 11:09:22.09 ID:wVXZyphH

ちょっと git してろよ

821 ：デフォルトの名無しさん：2014/10/23(木) 11:34:05.42 ID:6plD894T

gitをgit見てました

822 ：デフォルトの名無しさん：2014/10/23(木) 11:48:39.74 ID:ISc0F2Qf

>>810

823 ：デフォルトの名無しさん：2014/10/23(木) 11:51:26.14 ID:c5DrjxEb

GIMPはギンプでほぼ統一されてるな。

JOJOは第5部だけGIOGIOだ。ザ行で発音するのはイタリア由来かね？

824 ：デフォルトの名無しさん：2014/10/23(木) 12:16:58.01 ID:q5HQpAt6

http://ja.wikipedia.org/wiki/GIMP
> GIMP（ギンプ、ジンプ、GNU Image Manipulation Program）は

って書いてあるのに、何を根拠に統一されていると
思ったの？

825 ：デフォルトの名無しさん：2014/10/23(木) 12:51:10.62 ID:ISc0F2Qf

GNU って何て読むの

826 ：デフォルトの名無しさん：2014/10/23(木) 12:53:25.44 ID:q5HQpAt6

じーぬ

827 ：デフォルトの名無しさん：2014/10/23(木) 12:53:42.10 ID:I+m4T/U6

reset,add,commit,remote,log,reflog,checkout,branck,clone,rm,mv
とりあえずこのコマンドだけ覚えれば複数人で開発する時は問題ないと思ってるんですけど他にもあれば教えてください

828 ：デフォルトの名無しさん：2014/10/23(木) 12:57:46.69 ID:q5HQpAt6

bisectが入ってないとは開発者とは思えないな。

829 ：デフォルトの名無しさん：2014/10/23(木) 13:25:03.63 ID:1sBnQq4K

>>825
グニュー(ニューはねちっこく)

830 ：デフォルトの名無しさん：2014/10/23(木) 14:50:03.96 ID:eDVkHXcG

branch の綴りを間違えるとはほんとに使ってるとは思えないな。

831 ：デフォルトの名無しさん：2014/10/23(木) 14:51:39.25 ID:d2dt+BtO

>>827
push、pull。
ルールによってはtag。

832 ：デフォルトの名無しさん：2014/10/23(木) 16:49:47.11 ID:DGTXOsmr

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

833 ：デフォルトの名無しさん：2014/10/23(木) 16:55:02.78 ID:d2dt+BtO

>>832
好きにしろ。
どれも入ってなかったので、最も単純そうなものを入れておいただけだ。

834 ：デフォルトの名無しさん：2014/10/23(木) 17:00:46.99 ID:91hl1kT/

>>827
status
diff

835 ：デフォルトの名無しさん：2014/10/23(木) 17:18:28.62 ID:AJSC2eer

ぼっち開発で使って見ようと思うのだけどおすすめの運用教えてください

836 ：デフォルトの名無しさん：2014/10/23(木) 19:00:05.17 ID:49+zpQPL

git flow
github flow
gitlab flow
好きなのを選べ

837 ：デフォルトの名無しさん：2014/10/23(木) 22:03:02.25 ID:q5HQpAt6

>>827
blame、showが入ってない。最初だけだがinitもいるだろ。
複数人開発ならcherry-pickもつかうな。

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

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

git pullだけで済むことをわざわざfetchしてmergeしているみると
毎回そんなことやってんのかな？って思ってしまう。

838 ：デフォルトの名無しさん：2014/10/23(木) 22:09:56.33 ID:q5HQpAt6

>>835
バージョン管理する意味をしっかり理解することだな。

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

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

コミットは過去の作業履歴じゃなくて、一つ一つが意味のある修正で
その一つを取り出して、このコミットでは何を変えたのかがわかるようにする。

839 ：デフォルトの名無しさん：2014/10/24(金) 01:28:59.20 ID:2TlSkpOq

ソースはwikipedia(笑)

840 ：デフォルトの名無しさん：2014/10/24(金) 01:34:15.46 ID:2TlSkpOq

GitHubの追跡しにくさてすげーよな
どんだけセンスのない奴ばかり集まればあれほど使いにくくなるのだろうか

841 ：デフォルトの名無しさん：2014/10/24(金) 02:23:08.36 ID:En8l5okm

んで使いやすいGitリポジトリサービスはどこよ？GitLab？bitbucket？

842 ：デフォルトの名無しさん：2014/10/24(金) 08:51:59.42 ID:agHk22KZ

>>840
twitter よりマシ

843 ：デフォルトの名無しさん：2014/10/24(金) 12:56:07.98 ID:UyJ9AldF

>>840
GitHubの追跡ってのがよくわからん。
そもそもあんたgit使って追跡できる？

git使って追跡できるんだから追跡に
GitHubにたよる必要はないはずなんだが。

844 ：デフォルトの名無しさん：2014/10/24(金) 13:11:51.01 ID:l44t8Ym7

CodeBreakがクソな理由＆使ってはいけない理由

・ソースコードに連絡先を書いてはいけない。WordPressのテーマファイルのように作者と連絡先を記載すると利用規約第12条違反となる。

845 ：デフォルトの名無しさん：2014/10/24(金) 13:22:44.70 ID:UyJ9AldF

http://codebreak.com/ja/contents/rules/

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

ソースコードや個人情報等の情報およびその投稿に関する禁止事項
1. 悪意のあるプログラムその他のソースコードを配布または公開すること
2. 第三者の権利を侵害しまたは法令ないし公序良俗に反し、またはそのおそれのある情報を投稿すること
3. ソースコードに、自己または第三者の連絡先を記載または暗示すること
4. その他当社が不適切と判断する情報を投稿すること

846 ：デフォルトの名無しさん：2014/10/24(金) 13:23:14.18 ID:UyJ9AldF

その他一般的な禁止事項
1. 当社もしくは第三者の著作権、特許権、実用新案権、意匠権、商標権その他知的所有権を侵害し、またはそのおそれがある行為
2. 当社もしくは第三者の財産権、プライバシーもしくは肖像権その他の人格権を侵害し、またはそのおそれのある行為
3. 当社もしくは第三者を不当に差別もしくは誹謗中傷し、第三者への不当な差別を助長し、又はその名誉もしくは信用を毀損し、またはそのおそれのある行為
4. 自分以外の人物や組織（架空の人物や組織を含みます。以下同じ）を名乗ったり、代表権や代理権がないにもかかわらずあるものと装ったり、又は他の人物や組織と提携、協力関係にあると偽って本システムを利用する行為
5. 法令、公序良俗又は本規約に反し、またはそのおそれがあると当社が判断する行為
6. 当社もしくは第三者の権利を侵害し、またはそのおそれがあると当社が判断する行為
7. 面識のない異性または同性との性交、性交類似行為、わいせつな行為、出会い等を主な目的として利用する行為
8. 当社の業務運営を妨げると当社が判断する行為
9. 当社および本システムの信用を損ねるまたは損ねるおそれがあると当社が判断する行為
10. 本システムを通じて入手した情報を、複製、販売、出版、その他私的利用の範囲を超えて使用する行為
11. 正当な権限無く、利用者のシステム認証およびセキュリティの探求、本システムの非公開情報やアカウントにアクセスし、またはアクセスしようとする行為
12. 本システムの運営として当社が使用する当社又は第三者のサーバーに負担をかける行為、もしくは、本システムの運営やネットワーク・システムに支障、損害を与える行為、又はこれらのおそれのある行為
13. その他当社が別途禁止する行為

847 ：デフォルトの名無しさん：2014/10/24(金) 21:06:13.80 ID:RHs71UjF

>>841
Gitbucket

848 ：デフォルトの名無しさん：2014/10/25(土) 00:20:51.78 ID:jrmrNsb2

例えばあるcveに関する修正調べるだけの用で
プログラム自体に何の興味もねえのにいちいちクローンなんかしてられねえつーの

849 ：デフォルトの名無しさん：2014/10/25(土) 00:22:20.70 ID:SRh9eelG

GitHubの追跡にクローンの必要ないだろ、Watchにチェック入れりゃ更新がメールで届くし、スター付けるだけでもトップページで更新確認できるだろ

850 ：デフォルトの名無しさん：2014/10/25(土) 11:25:50.96 ID:baN3kQAe

>>848
Changelogみればいいだけじゃないの？

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

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

つまりあんたは技術者なのに技術がないっていうこと。

851 ：デフォルトの名無しさん：2014/10/25(土) 11:49:41.62 ID:iDGC2gg+

branch前（幹の部分）にコミットを追加したら、
branchにもそのコミットが反映されるかとおもったらそうではなかった。
(rebase -iでmasterの最新のコミットを幹の部分に入れ込んだ)

branchの親を付け替えることができればよさそうですが、
そのようなことはできますか？

852 ：851：2014/10/25(土) 12:00:16.99 ID:iDGC2gg+

>>851の追加です。
あるいはこういう場合、
全branchに、cherrypickで同じコミットをあてていくべきなんでしょうか？

853 ：デフォルトの名無しさん：2014/10/25(土) 12:12:14.07 ID:baN3kQAe

よくわからんけど、ontoかいな。

854 ：デフォルトの名無しさん：2014/10/25(土) 12:37:04.05 ID:OsyjfeG2

>>852
分岐前のbranchを分岐後のbranchにマージ
あるいは分岐後のbranchを分岐前のbranchに対してrebase

855 ：デフォルトの名無しさん：2014/10/25(土) 13:17:24.15 ID:Nj8R3giM

なんとかフローに従っていればチェリーピックとか使う必要ないよね

856 ：デフォルトの名無しさん：2014/10/25(土) 13:39:02.31 ID: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と同じでしょうか。

分岐点より前のものにコミット変更やると、どうしても分岐点後の各ブランチとは別歴史となってしまいそうな気がしてきました。

857 ：デフォルトの名無しさん：2014/10/25(土) 14:13:41.92 ID:tjXcLkh9

リベースしたら変更したコミット以降全部再作成されるから当然のこと

858 ：デフォルトの名無しさん：2014/10/25(土) 14:23:33.80 ID:OsyjfeG2

> 分岐点より前のものにコミット変更やると、どうしても分岐点後の各ブランチとは別歴史となってしまいそうな気がしてきました。

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

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

これもそう。
なので普通は別ブランチの変更を取り込むときはmergeする。

859 ：デフォルトの名無しさん：2014/10/25(土) 14:26:53.51 ID:baN3kQAe

>>856
コミットIDなどと言ったりするから勘違いされやすいと思うが、
IDというのはそのコミットに対する番号ではなくて、
過去の歴史すべての情報を含んでいるんだよ。

あるIDとあるIDが同じであれば、
過去の歴史も全て一緒になる。

860 ：デフォルトの名無しさん：2014/10/25(土) 20:54:32.21 ID:rEnLKs1o

>>859のいうIDって何のことだ？

861 ：デフォルトの名無しさん：2014/10/26(日) 00:39:38.99 ID:KYTvr3GZ

848だけどさ
Changelog見たかったんだけどな
存在しなかったんだよね
リリースノートも更新されてないしね

それがぺちぱーというタイプの生き物なんだよ

862 ：848：2014/10/26(日) 11:01:41.57 ID:MKtCgGPk

>>861
私になりすまして、私のレスをPHP叩くネタにしないでくれませんか？
根性ねじ曲がっていますね。

863 ：デフォルトの名無しさん：2014/10/26(日) 12:54:04.01 ID:dbycS4MG

>>837
そこはcpじゃなくてlnだろ

864 ：デフォルトの名無しさん：2014/10/26(日) 13:44:32.29 ID:E7QfrGU+

まあそこまで厳密に考えなくてもｗ

865 ：デフォルトの名無しさん：2014/10/26(日) 22:30:45.78 ID:KYTvr3GZ

頭の悪いぺちぱーがなりすましかよ(笑)

866 ：デフォルトの名無しさん：2014/10/26(日) 23:34:05.33 ID:Uxx8sszV

なぁ
リモートのmasterをローカルにcloneするやん？
自分の作業をするためにローカルにブランチ作ってcheckoutするやん？
したら修正とかやってコミットしよんよ
んでどないすんの？
オレオレブランチをリモートのmasterにあげたいんや

867 ：デフォルトの名無しさん：2014/10/26(日) 23:59:51.36 ID:KYTvr3GZ

権限と許可あるなら押せば〜
ないなら差分送りつけるなり
そいつらの流儀に従え

868 ：デフォルトの名無しさん：2014/10/27(月) 01:18:10.93 ID:KfSASuUC

他人のリポジトリ好きにしたいとか頭おかC

869 ：デフォルトの名無しさん：2014/10/27(月) 02:25:43.24 ID:dBZ7xcRa

元のmasterを自分のアカウントでfork
その修正したbranchを自分のforkしたリポジトリにpullrequest
自分のリポジトリのbranchを元のmasterにpullrequest

870 ：デフォルトの名無しさん：2014/10/27(月) 04:14:33.93 ID:XzKSKrvp

リモートという言葉が他人のリポジトリを指すわけではないのに他人のリポジトリと決め付けて話をすすめるエスパーたち

871 ：デフォルトの名無しさん：2014/10/27(月) 04:28:32.43 ID:BepvCTPK

>>870
自分のなら>>867の1行目で話終わってるだろ。それ以外の場合は多岐に渡るため、いろいろ補足が出てるんだろ。

872 ：デフォルトの名無しさん：2014/10/27(月) 09:13:57.19 ID:3pkGW4w9

なんで？

873 ：デフォルトの名無しさん：2014/10/27(月) 09:42:13.06 ID:wK4QYAC1

自分のリモートなら push

874 ：デフォルトの名無しさん：2014/10/28(火) 00:53:31.06 ID:mFnj7HRR

commitするまえにgit diffで表示される内容を
commitした後に見る方法をおしえてください

875 ：デフォルトの名無しさん：2014/10/28(火) 01:05:28.82 ID:2moDL6+C

>>874
これか?

http://qiita.com/hide/items/17b970c485e803cbce08
>直前の commit による変更を表示
>
>git diff HEAD^ HEAD
>
>HEAD と HEAD^ の差分を表示するコマンド。
>commit 直後によく実行する。

876 ：デフォルトの名無しさん：2014/10/28(火) 01:21:14.87 ID:mFnj7HRR

ありがとうございますそれです

877 ：デフォルトの名無しさん：2014/10/28(火) 07:47:04.20 ID:3xBkNC1k

>>874
git show

878 ：デフォルトの名無しさん：2014/10/28(火) 23:54:47.08 ID:sTktv/Nl

Web制作者のためのGitHubの教科書 チームの効率を最大化する共同開発ツール
http://www.amazon.co.jp/dp/4844337009/

なぜかWeb製作に特化した本。普通の入門書はそろそろ飽和気味でこういう
毛色が変わったのがでてくるようになったのか。
そろそろブームも終焉かな。

879 ：デフォルトの名無しさん：2014/10/28(火) 23:57:58.88 ID:Hn3G7vVN

ｵﾏｴの人生が終焉

880 ：デフォルトの名無しさん：2014/10/29(水) 08:37:02.36 ID:VOgtiztz

どうせエボラ上陸したらみんな終焉

881 ：デフォルトの名無しさん：2014/10/29(水) 15:17:52.51 ID:yqIOJVFi

github flowにそってブランチ作ってマスターにマージしまくる場合って
過去に作ったブランチ名を何度も使うのはやめたほうがいいですか？

882 ：デフォルトの名無しさん：2014/10/29(水) 17:29:17.16 ID:NA8+uBRT

>>880
エボラは致死率は高いものの、感染力は季節性インフルエンザより低く、
潜伏期に感染もしないため、残念ながら終焉しない

883 ：デフォルトの名無しさん：2014/10/29(水) 17:42:32.70 ID:US+EsBcT

空気感染はしないからね
アフリカの人達はあまりにも無知で無用心だったため感染が広まったみたいだね

884 ：デフォルトの名無しさん：2014/10/29(水) 17:52:17.85 ID:gUoIWkK1

いやまあ初期は誰も知識持ってないからしょうがない面もあるでしょ
犠牲者がイたからこそいろいろわかってきた

885 ：デフォルトの名無しさん：2014/10/29(水) 17:55:24.53 ID:HBXTyN9+

「エボラは存在しない！」とかいって隔離施設を襲撃したりしてたからな。
レベルが違うわ。

886 ：デフォルトの名無しさん：2014/10/29(水) 18:18:05.77 ID:US+EsBcT

中国なんかあれだけ経済大国になったにもかかわらず未だに
ブタやニワトリなどの家畜を家の中で飼ってるからね

887 ：デフォルトの名無しさん：2014/10/29(水) 18:28:53.88 ID:CVZn32SR

経済大国と田舎の農家が今までどおりなのはあまり関係ないと思うけど
偏見とすれ違いだな

888 ：デフォルトの名無しさん：2014/10/29(水) 19:16:01.44 ID:LJBpagLw

八八八

889 ：デフォルトの名無しさん：2014/10/29(水) 19:25:48.06 ID:svrkbAR0

>>881おねがいします

890 ：デフォルトの名無しさん：2014/10/29(水) 21:18:00.89 ID:QyQ56sbs

git merge して衝突が発生した時、
git add 衝突ファイル名
とコマンドすると、そのファイルは解決したことになりますが
この状態から、そのファイルを再び未解決状態に戻すには
どういうコマンドを入力したらいいのでしょうか？

891 ：デフォルトの名無しさん：2014/10/29(水) 21:41:22.85 ID:+4rbzCBy

git reset --hard

892 ：デフォルトの名無しさん：2014/10/30(木) 09:06:31.37 ID:JyGsGO1i

git ebola

893 ：デフォルトの名無しさん：2014/10/30(木) 09:18:02.99 ID:XUDk5/xR

git diff ANUS

894 ：デフォルトの名無しさん：2014/10/30(木) 10:34:10.14 ID:gxwnASCg

今いるブランチのログだけ表示する方法をおしえてください

895 ：デフォルトの名無しさん：2014/10/30(木) 12:36:26.50 ID:cQjIg7VJ

２．１．３

896 ：デフォルトの名無しさん：2014/10/30(木) 13:06:05.22 ID:YTL6Km3+

ダーー！

897 ：デフォルトの名無しさん：2014/10/30(木) 13:28:30.39 ID:UT+H+6H/

いやいやｗ

898 ：デフォルトの名無しさん：2014/10/30(木) 19:00:08.03 ID:cH0Fwfec

ブランチ名を変更したっていう記録がreflogに残ってません
これってあんまりやらないほうがいいですね

899 ：デフォルトの名無しさん：2014/10/30(木) 19:00:38.80 ID:cH0Fwfec

ブランチ名を変更した時にファイルに記録したいのでフックおしえて下さい

900 ：デフォルトの名無しさん：2014/10/30(木) 23:59:12.26 ID:B7KOSmmC

ブランチ名って記録に残さないといけないようなものなのか？

901 ：デフォルトの名無しさん：2014/10/31(金) 00:52:37.91 ID:fzEvUe3e

誰かが勝手にブランチ名を変更したのでたどれないんですよ
github flowに沿ってるのでブランチがたくさんあるので探すのに手間がかかるのですよ

902 ：デフォルトの名無しさん：2014/10/31(金) 01:10:39.21 ID:8Uf3xK8D

ブランチって複数のコミットを指すものじゃなくて
特定の１つのコミットを指すただのポインタだから辿るなんて無理じゃね
各コミットにどこのブランチから参照されたことがあるかっていう情報でも書かれてりゃいいが、たぶんないだろうし

903 ：デフォルトの名無しさん：2014/10/31(金) 06:20:26.97 ID:zV8yxXTK

ブランチってこれしか知らない
https://www.youtube.com/watch?v=HKLnmMacEB4

904 ：デフォルトの名無しさん：2014/10/31(金) 07:55:48.48 ID:yr/i2jdz

ブランチ名の変更を記録するために努力するより，その勝手な奴を探して
意思疎通をはかるほうが先のような

905 ：デフォルトの名無しさん：2014/10/31(金) 09:31:34.00 ID:Lxm1GiJ2

hgだとコミットにブランチが記録されるから、そっちから入った運用だと欲しいかもね

906 ：デフォルトの名無しさん：2014/10/31(金) 10:32:23.44 ID:ye78HJq1

なのでフックできまえんか？

907 ：デフォルトの名無しさん：2014/11/01(土) 14:29:57.48 ID:+ct8WvSM

aブランチにいます
ファイルを編集しました。
この状態でbブランチを作成してそこで別の作業がしたいんですが
aブランチの内容は作業中なのでコミットはしたくないんですが、
こういうときってどうしたらいいですか？

908 ：デフォルトの名無しさん：2014/11/01(土) 14:40:17.17 ID:1cXKFWWG

>>907
stashかclone

909 ：デフォルトの名無しさん：2014/11/01(土) 14:42:39.31 ID:hdcrWs+g

stash

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

どうせコミットしても後から修正できるんだしさ。
それがgitのいいところ

910 ：デフォルトの名無しさん：2014/11/01(土) 14:46:18.15 ID:3nVvYlYV

git stash

911 ：デフォルトの名無しさん：2014/11/01(土) 15:08:18.64 ID:wP/CUk9Y

俺もとりあえずコミットしておく
後で中途半端な状態のコミットはなかったことにできるし、
コミットしておけば、わけわかんなくなっちゃっても
reflogで復旧できるし

912 ：デフォルトの名無しさん：2014/11/01(土) 15:30:13.74 ID: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/

913 ：デフォルトの名無しさん：2014/11/01(土) 17:36:40.86 ID:NWvPyPI3

(1)最後から2番目のpushを取り消したい
(2) 1のpush後に何回かコミットしている

リモートにパスワードを書いたファイルをあげちゃったんです！
どうにかして消したいんですがリポジトリを削除する以外でたすけてください！
個人リポジトリです。

914 ：デフォルトの名無しさん：2014/11/01(土) 17:38:42.47 ID:NWvPyPI3

あとpushしたあとに過去のコミットに戻って作業しなおしてコミットしなおしてます

915 ：デフォルトの名無しさん：2014/11/01(土) 18:03:34.69 ID:XzkwPK+7

リポジトリを削除してgit cloneしたらreflogに消えてるんですけどreflog復活できないんですか？

916 ：デフォルトの名無しさん：2014/11/01(土) 18:13:34.29 ID:FYqABB6+

>>915
削除したリポジトリを復活させられるファイルシステムまたはゴミ箱を使ってないなら無理

917 ：デフォルトの名無しさん：2014/11/01(土) 18:15:16.51 ID:iW3/zCCJ

ええええ

918 ：デフォルトの名無しさん：2014/11/02(日) 04:01:31.80 ID:k43a6lgh

gitのバックアップってみんなどうしてる？

919 ：デフォルトの名無しさん：2014/11/02(日) 04:20:30.80 ID:IBnDqJlk

リポジトリのバックアップならGitHubとかのリポジトリほスティングサービスに丸っと上げてるけど
git自体のバックアップは取ってないな、PCイカレたときにgit環境の再構築は面倒だからgitもバックアップ取っておいたほうがいいかもなあ

920 ：デフォルトの名無しさん：2014/11/02(日) 04:50:35.89 ID:6JfF1xXY

>>918
gitっていうかユーザーフォルダまるごと
オンラインバックアップソフトでバックアップしてるけど？

921 ：デフォルトの名無しさん：2014/11/02(日) 06:46:18.61 ID:LNjYg/LZ

>>918
リモートホストと、ローカルでアーカイブするディレクトリにpush。

922 ：デフォルトの名無しさん：2014/11/02(日) 19:29:36.99 ID:ThHDneSJ

>>913
個人リポジトリならrebaseで良い感じに履歴を修正してgit push -fで良いんじゃないの？

923 ：デフォルトの名無しさん：2014/11/02(日) 22:08:30.34 ID:+x3IjfRt

git clone

924 ：デフォルトの名無しさん：2014/11/03(月) 02:37:45.68 ID:AVck6ina

>922
サーバ側でgcされない限り発見されうるのでは。

925 ：デフォルトの名無しさん：2014/11/03(月) 02:46:26.46 ID:ga1lmjsH

リモートってのがGitHubみたいなリポジトリサービスを個人で使ってるとかならリポジトリ丸っと削除してから上げ直すってのがてっとり早そうだが
そうでないんなら管理者にお願いするしかないな

926 ：デフォルトの名無しさん：2014/11/03(月) 09:27:50.81 ID:1DGR/mlS

bitbucketだとpush -fやってもハッシュがわかれば辿れます
githubはどうなんでしょうかね

927 ：デフォルトの名無しさん：2014/11/03(月) 09:52:06.95 ID:ikPdAg2R

>>924
個人リポジトリなら公開しなければ良いんじゃ無くて？

928 ：デフォルトの名無しさん：2014/11/03(月) 17:47:08.61 ID:RlfDc9Qx

git checkout -b test
ファイル作成
git stash
>No local changes to save

何故保存できないんですか？

929 ：デフォルトの名無しさん：2014/11/03(月) 18:08:06.61 ID:JWZEDRHL

addしてないから

930 ：デフォルトの名無しさん：2014/11/04(火) 10:02:07.88 ID:srrbBYWq

コミットって何個ぐらい貯めてからマージしたほうがいいですか？

931 ：デフォルトの名無しさん：2014/11/04(火) 12:27:32.90 ID:shtI5m7G

ブランチした目的が完了したらマージすればよい

932 ：デフォルトの名無しさん：2014/11/04(火) 18:40:49.16 ID:h/d8a8at

最後にコミットしたファイルが何だったか確認したいんですけどどうやるんですか？

933 ：デフォルトの名無しさん：2014/11/05(水) 07:18:20.97 ID:M5idn0Tw

>>932
git show --name-only HEAD^
とか。

934 ：デフォルトの名無しさん：2014/11/08(土) 00:19:43.30 ID:fHlqfJbD

それじゃない方法合ったはずなんですが思い出せません

935 ：デフォルトの名無しさん：2014/11/08(土) 01:23:09.15 ID:v0SFyh4V

ポジトリの作成と基本的なバージョン管理――SourceTreeで始めるGitバージョン管理入門 第1回
http://sourceforge.jp/magazine/14/11/06/200000

936 ：デフォルトの名無しさん：2014/11/08(土) 16:24:19.48 ID:qwvGzBPO

ぽじぽじ

937 ：デフォルトの名無しさん：2014/11/08(土) 21:52:16.01 ID:reRJrTPU

aブランチにいる時にブランチを変更しないままbブランチの最新コミットの特定のファイルを表示する方法ありませんか？
git show HEAD bだと差分しかとれません

938 ：デフォルトの名無しさん：2014/11/08(土) 21:52:49.00 ID:reRJrTPU

git show HEAD dev test.txt

939 ：デフォルトの名無しさん：2014/11/09(日) 14:08:12.74 ID:ZRZEFjhv

git merge --squash featureしたら
fatal: You cannot combine --squash with --no-ff.ってでました
どうしてですか？

940 ：デフォルトの名無しさん：2014/11/10(月) 02:12:22.08 ID:cjWO4r21

fast forward なマージじゃ無いからじゃないかな、うん

941 ：デフォルトの名無しさん：2014/11/10(月) 04:49:39.77 ID:/MiFk0my

>>939
$ git merge --squash feature; git status
の結果を見たら判ると思う

942 ：デフォルトの名無しさん：2014/11/10(月) 10:13:17.97 ID:mJmPI0Yr

これさ.gitconfigでff = falseにしてるんですけど
たしかGIt 2.0ではff = falseがデフォルトになるからって言われててGit 1.7あたりからずっとこれ指定してたんですけど
これはずしたらエラーが出なくなったってことはGit 2.0でも ff = falseがデフォルトじゃないってことですよね
ってことはデマを流した奴ゆるせねえよ

943 ：デフォルトの名無しさん：2014/11/10(月) 12:16:53.53 ID:LG3MPbP+

はあ？

944 ：デフォルトの名無しさん：2014/11/10(月) 14:13:03.06 ID:ktQb1IT9

ふぅ

945 ：デフォルトの名無しさん：2014/11/11(火) 00:33:46.85 ID:bBHeKZ12

ff = falseじゃなくなると
git mergeしたときにmergeしたってコミットがログに残らなくなって1本化されてどのブランチからマージされたのかわからなくて不便なんですけど
こういうのが皆さんいいんですか？

946 ：デフォルトの名無しさん：2014/11/11(火) 00:41:57.16 ID:ZZYlQze/

gitにおいて「どのブランチからマージされたか」という情報は不要な情報です。

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

コミットは追跡しますが、ブランチは追跡しません。
なので不便でもなんでもありません。

947 ：デフォルトの名無しさん：2014/11/11(火) 03:44:25.75 ID:nS4HMCxE

>>946の言ってる「Gitにおいて」は「ぼくの考えるGitにおいて」なので、
ff mergeでもno-ff mergeでも、状況、運用に応じて使い分けるのが吉
良くないのは特に根拠、ユースケース、プロジェクトの運用法も考えずに「ff mergeこそ原則」だとか「no-ff mergeこそベストプラクティス」だとか
「pull --rebaseが常識」とか思考停止してしまうことだと思うな

948 ：デフォルトの名無しさん：2014/11/11(火) 09:56:57.50 ID:JOEQJrit

すいません横から質問させてください

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

■git configで ff = falseを指定してない時
コミットを一本化したい→git mergeでマージしちゃえばOK
マージした情報を残したい→◎ここ教えてください◎

949 ：デフォルトの名無しさん：2014/11/11(火) 20:56:13.09 ID:UknPa1bY

>>947
> ff mergeでもno-ff mergeでも、状況、運用に応じて使い分けるのが吉

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

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

no-ffにしたらブランチの情報は消えるが、コミットの情報は残る。
gitにおいて「どのブランチからマージされたか」という情報は不要な情報であり
コミットの情報はあるのだから追跡可能って話だろ。

950 ：デフォルトの名無しさん：2014/11/11(火) 21:32:12.92 ID:nS4HMCxE

>>949
え、ff=falseの設定がないと、Fast forwardでマージ可能なときはFast forwardになってしまい、
そういうときはマージコミットが出来ず分岐していたこともわからないのが不便、ってことを>>945は言いたいんじゃないの？
まあでもあなたの指摘で>>946は「コミットツリーは追跡可能でブランチ(名)自体は重要な存在ではない」というようなことを言っているように
思えてきたから、そもそも話が噛み合ってないのかもしれないな。

>>948
git merge --no-ff

951 ：デフォルトの名無しさん：2014/11/12(水) 00:48:36.32 ID:tAw43bMz

>>948

そういうのが必要ならCommitメッセージに
その必要な情報を書けばいいんじゃないの？

952 ：デフォルトの名無しさん：2014/11/12(水) 01:32:41.30 ID:oqW+9k0m

>>948
マージした情報を残さない場合に使うのがff。
だから君がいっていることは矛盾している。

証拠を残さない方法でマージする時に
証拠を残す方法を教えて下さいっていっているようなもの

953 ：デフォルトの名無しさん：2014/11/12(水) 03:23:32.59 ID:OHxbfa4c

githubの公開リポジトリにpull-requestが来たのですが
修正が不十分なのでさらに追記したいです。

こういう場合は一度マージしてから、
追加分を自分で書いてコミットする感じになるんでしょうか？
分散してしまう気がするんですが

954 ：デフォルトの名無しさん：2014/11/12(水) 03:44:59.06 ID:3VJGATlA

>>953
これ読んでみてね

http://postd.cc/merge-pull-request-considered-harmful/

955 ：デフォルトの名無しさん：2014/11/12(水) 03:58:23.24 ID:OHxbfa4c

>>954
なるほど、難しくてわからんｗ
頑張ってみます

956 ：デフォルトの名無しさん：2014/11/12(水) 10:38:02.88 ID:k5vltUqv

Merge pull requestボタン使わずにgit fetchして修正してからgit mergeする

957 ：デフォルトの名無しさん：2014/11/12(水) 15:41:08.61 ID:wkOcL4q8

>>954
これ重要だよね
次スレのテンプレに入れてください

958 ：デフォルトの名無しさん：2014/11/12(水) 17:10:59.81 ID:oNgPGMI+

GithubスレっつーかOSSホスティング総合スレの領分じゃないかな、これは

959 ：デフォルトの名無しさん：2014/11/12(水) 17:22:26.94 ID:nY11rrhT

前スレでGithubOKになってたけど結局どっちなんだよ

960 ：デフォルトの名無しさん：2014/11/12(水) 17:33:45.35 ID:ueT8hwxi

Githubの操作ならここでもいいけど運用は別ってことでは

961 ：デフォルトの名無しさん：2014/11/12(水) 17:48:18.35 ID:+5avtq1s

Gitolite使った場合に置き換えての質問はセーフ？

962 ：デフォルトの名無しさん：2014/11/12(水) 18:32:03.25 ID:uE+V1Fm1

>>961
GitHubやGitoliteを別の名詞に置き換えても通用する話ならいいでしょう

963 ：デフォルトの名無しさん：2014/11/12(水) 21:31:48.76 ID:aPFUo/Gh

ファイル名からパス全体を補完する設定はありませんか？
例えばgit log script/js/main.jsを入力したいときに
git log main.js[TAB]と打ったらmain.jsがscript/js/main.jsに変わる感じにしたいです

964 ：デフォルトの名無しさん：2014/11/13(木) 03:37:28.48 ID:PwH0w3L+

レポジトリの履歴から完全にファイルを削除したいのですがうまくいきません。
相談に乗ってください。

状況を説明すると
いままでソース＋実行バイナリをコミットしていた
実行バイナリのサイズは９MB程度で３〜４回コミットしていた。
cloneでとってきた時に
レポジトリサイズが２７〜８MBになってしまったのに気がつき、
バイナリを管理から外そうと思いました。
通常通りステージされているファイルを削除してコミットします。
ここまでは通常通りのファイル削除手順で、
このあと履歴からも消すために
git filter-branch -f --index-filter 'git rm -rf --ignore-unmatch dirname' HEAD
としてバイナリの入っているディレクトリごと削除しました。
念のため全てのブランチ・タグに対して行いました。
履歴上は全て削除されているのですが、
.gitディレクトリのサイズを計測すると２７〜８MBでほとんど変わっていません。
git gcもしてみましたが変化ありませんでした。
.git内に残っているファイルでサイズが大きかったのがハッシュ名.packとかいうやつでした。
こういう場合どのように対処すればよいでしょうか？

965 ：964：2014/11/13(木) 04:09:21.51 ID: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でした。

966 ：デフォルトの名無しさん：2014/11/13(木) 12:17:10.54 ID:TfaWOQiO

http://stevelorek.com/how-to-shrink-a-git-repository.html

967 ：デフォルトの名無しさん：2014/11/13(木) 12:54:50.49 ID:TH2WjXWm

>>963
ないんじゃね？
main.js がそこらじゅうにあったらどうする？
のと
ルートから補完するならまだしも、適当にいい具合のフォルダから補完とか難しいだろ w

968 ：デフォルトの名無しさん：2014/11/13(木) 13:07:45.40 ID:UTqcb0rY

レビューするために使うツールありませんか？
githubとかそういうwebサービスは使いません
ローカルで運用します

969 ：デフォルトの名無しさん：2014/11/13(木) 14:42:04.68 ID:Z1L+ASGn

>>963
zshとかのシェルを使ってれば、**/main.jsを補完することで似たようなことはできるよ。

970 ：デフォルトの名無しさん：2014/11/13(木) 15:30:38.12 ID:A8P9e+11

>>968
何が聞きたいのかよくわからん、普通にgitじゃだめなのか

971 ：デフォルトの名無しさん：2014/11/13(木) 15:47:46.69 ID:L24TG69N

gitでどうやってレビューするんですか？

972 ：デフォルトの名無しさん：2014/11/13(木) 15:54:59.26 ID:I8aSODmI

要するにgithubみたいののローカル版がほしいのか？

973 ：デフォルトの名無しさん：2014/11/13(木) 16:38:57.83 ID:YMcDW7oP

>>963
シェルを自作しろ

974 ：デフォルトの名無しさん：2014/11/13(木) 17:17:08.06 ID:L9/PqQSO

>>972
githubは使ったことないのでわかりませんがgitlabいれないいでレビューがしたいんです

975 ：デフォルトの名無しさん：2014/11/13(木) 20:12:05.37 ID:Z1L+ASGn

>>974
SourceTreeとか使えばいいんじゃない？

976 ：デフォルトの名無しさん：2014/11/13(木) 20:43:51.43 ID:cB3M5QyA

>>967,969,973
レスthx
zsh見てみます

977 ：デフォルトの名無しさん：2014/11/13(木) 22:02:19.69 ID:PaVph4TZ

>>968
ReviewBoard、Rietveld、Gerritとかはどう?

978 ：デフォルトの名無しさん：2014/11/13(木) 22:13:22.01 ID:vd0ZyHjk

オコトワリシマス

979 ：デフォルトの名無しさん：2014/11/13(木) 22:22:33.26 ID:BiT3RuHa

gitlabがパッケージから入れられるし
一番楽だと思うけどね。

980 ：デフォルトの名無しさん：2014/11/13(木) 22:26:20.56 ID:YwgTkykc

今日git diffでレビューしたわ。

981 ：デフォルトの名無しさん：2014/11/13(木) 22:36:32.33 ID:BiT3RuHa

git diffは差分を見るだけ。

レビューするなら、diffの内容にコメントを書くことができて
コメントしたらメールなどで相手に通知がいく。
そして掲示板のように一つのスレッドで
会話が続けられる。チーム全体がその会話を見れる。
みたいな機能がないとダメ。

982 ：デフォルトの名無しさん：2014/11/13(木) 22:54:46.27 ID:51BXvgtI

ウェブアプリは嫌で、単にdiff＆メールでも嫌ってどういうこと
専用サーバー＆クライアント方式か？

983 ：デフォルトの名無しさん：2014/11/13(木) 23:46:51.23 ID:YwgTkykc

レビューなんてやりたくねーよってことだろ。

984 ：964：2014/11/14(金) 01:57:05.95 ID:7CGUYUCq

>>966
> http://stevelorek.com/how-to-shrink-a-git-repository.html
ありがとうございます。
参考にさせていただきます。

985 ：デフォルトの名無しさん：2014/11/14(金) 16:42:06.08 ID:Un4oU5dg

ID:YwgTkykc
頭悪すぎワロタ

986 ：デフォルトの名無しさん：2014/11/14(金) 18:05:19.80 ID:gxvE4Z0q

>>985
頭いいあなたは理由を完結に言えるよね?

987 ：デフォルトの名無しさん：2014/11/15(土) 12:27:41.89 ID:21oH1jUA

一時的に過去のコミットした時点に戻っていろいろファイルを開いて確認してまた今編集中の所に戻る場合h
git checkoutとgit resetどっちを使うものですか？

988 ：デフォルトの名無しさん：2014/11/15(土) 12:36:45.55 ID:OXKrkrvT

>>985
理由もなく言うとか頭悪いね

989 ：デフォルトの名無しさん：2014/11/15(土) 17:26:46.36 ID:o3UfO57b

>>987
git showですませるのが簡単だが今のブランチ覚えておいてcheckoutするのも良い

990 ：デフォルトの名無しさん：2014/11/16(日) 01:58:42.01 ID:QaCyCGE3

>>986
少しは自分でも考えろよ

991 ：デフォルトの名無しさん：2014/11/16(日) 08:35:28.94 ID:UhWDCpe4

>>987
git resetってのは変更を取り消すときに使うコマンドだよ
対してcheckoutはコミット間を移動したりする
checkoutを使うべき

992 ：デフォルトの名無しさん：2014/11/16(日) 10:35:24.28 ID:9CTE3XWg

>>974
こういうのは？
https://www.atlassian.com/ja/software/stash

993 ：デフォルトの名無しさん：2014/11/16(日) 12:17:31.32 ID:m6sFd0+V

>>990
馬鹿の考えることはわからん。

994 ：デフォルトの名無しさん：2014/11/16(日) 14:50:22.62 ID:aPjF8Str

>>974
Azure

995 ：デフォルトの名無しさん：2014/11/16(日) 14:57:02.53 ID:SSwbArxn

埋め埋め

996 ：デフォルトの名無しさん：2014/11/16(日) 19:45:09.90 ID:mQePSm8M

元の質問者はわかってると思うが横からすまん。
resetは変更を取り消すというよりbranchのHEADを移動させるコマンド
と覚えておくほうが混乱しない

そのbranchのHEADからたどれなくなるから消えてるように見えるだけでコミットは残ってる

997 ：デフォルトの名無しさん：2014/11/16(日) 20:06:34.96 ID:SSwbArxn

埋め立てふせ

998 ：デフォルトの名無しさん：2014/11/17(月) 12:31:41.48 ID:EoA2znuK

Git 11(c)2ch.net
http://peace.2ch.net/test/read.cgi/tech/1416195050/

(c).2ch.net 外せないんかの

999 ：デフォルトの名無しさん：2014/11/17(月) 12:38:36.04 ID:X64fmHCX

外せない　埋め

1000 ：デフォルトの名無しさん：2014/11/17(月) 17:29:45.24 ID:re+o/iO9

うんこ使えよ

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。