Git 6

1 ：デフォルトの名無しさん：2013/05/21(火) 11:26:36.94

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
http://git-scm.com/

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

◆前スレ
Git 5
http://toro.2ch.net/test/read.cgi/tech/1350144612/

2 ：デフォルトの名無しさん：2013/05/21(火) 11:28:50.26

3 ：デフォルトの名無しさん：2013/05/21(火) 11:29:24.67

◆関連書籍
Gitによるバージョン管理
2011/10
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06864-5

実用Git
2010/02
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
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06767-9

4 ：デフォルトの名無しさん：2013/05/21(火) 17:47:18.33

　　　　　＿＿＿_∩＿∩
　　～／　　　　　　・　・＼
　　　（　　　　　　　　 ∀ 　）　　＜ぼく、4ゲット君
　　　　＼／＼／＼／＼／

5 ：デフォルトの名無しさん：2013/05/21(火) 18:00:42.14

　　　　　＿＿＿_∩＿∩
　　～／　　　　　　・　・＼
　　　（　　　　　　　　 ∀ 　）　　＜あたち、5ゲットちゃん
　　　　＼／＼／＼／＼／

6 ：デフォルトの名無しさん：2013/05/21(火) 18:24:42.86

どこが違うんだｗ

7 ：デフォルトの名無しさん：2013/05/21(火) 20:27:27.03

>>3
書籍じゃないけど参考になるのでぺたり

http://git-scm.com/book/ja

8 ：デフォルトの名無しさん：2013/05/21(火) 20:45:57.85

>>7
すばらしい
>>1に書いておくべき

9 ：デフォルトの名無しさん：2013/05/21(火) 20:49:06.05

すでに書いてある。URLが変わっただけ。

10 ：デフォルトの名無しさん：2013/05/22(水) 23:55:31.37

gif←ジフ
git←ジット

11 ：デフォルトの名無しさん：2013/05/23(木) 00:11:42.22

cogito←コギト
git←ギット

12 ：デフォルトの名無しさん：2013/05/30(木) 08:03:12.77

http://itpro.nikkeibp.co.jp/article/NEWS/20130529/480625/

13 ：デフォルトの名無しさん：2013/05/30(木) 08:19:51.93

>>12
>年収は必須です。

わろす

14 ：デフォルトの名無しさん：2013/05/30(木) 08:31:20.23

Q. Pull Requests、Forkなどの機能はありますか？

A. 申し訳ありません現在は実装しておりません。
    作ってる本人も欲しい機能なので結構早く実装されるとおもいます。

Q. Gitサーバーにsshでアクセスすることは可能ですか？

A. 申し訳ありません現在HTTPSのみ対応しております。
    開発チームがそれなりにがんばっているので、それなりな時期に対応できるとおもいます。
    俺が実装してやるぜ！という奇特な方はこちらからご応募ください。
http://www.bizreach.co.jp/recruit/

ふ～ん。

15 ：デフォルトの名無しさん：2013/05/30(木) 12:45:19.64

また画面丸パクリだったりするのかな

16 ：デフォルトの名無しさん：2013/05/30(木) 12:59:51.25

これはひどい

17 ：デフォルトの名無しさん：2013/05/30(木) 19:48:48.10

誰かが負荷かけて潰すだろうな

18 ：デフォルトの名無しさん：2013/05/31(金) 00:30:01.42

>>14
スクロールして一瞬びびった。グロ画像かと思ったじゃねーか。

19 ：デフォルトの名無しさん：2013/06/01(土) 17:19:55.26

CVSユーザーです。gitの場合CVSのモジュール一つにつき
一つのリポジトリを用意する必要があるという認識で良いですか？

20 ：デフォルトの名無しさん：2013/06/01(土) 18:07:22.36

gitを学ぶならCVSのことは全部忘れた方がいいと思うよ

21 ：デフォルトの名無しさん：2013/06/01(土) 18:56:33.22

いや、忘れる必要は無いだろ。技術者として。

22 ：デフォルトの名無しさん：2013/06/01(土) 19:00:09.51

そういう意味で言ってるんじゃないと思うぞ・・・

23 ：デフォルトの名無しさん：2013/06/01(土) 19:01:44.47

あんな男のことはもう忘れて俺だけを見ろって意味か

24 ：19：2013/06/01(土) 20:14:48.96

>>20
比較しながら違いを見ていかないと覚えられない性格でなんす。

知っているなら意地悪しないで教えていただけなせんか？

25 ：デフォルトの名無しさん：2013/06/01(土) 20:30:01.74

管理方針によっても変わりますが、CVSのモジュールにひとつに対して、
Gitではひとつのベアリポジトリと複数のリポジトリを作ることになると思われます

26 ：19：2013/06/01(土) 21:08:46.73

>>25
ありがとうございます。

ベアリポジトリというのが、CVSのトランク
ただのリポジトリというのがCVSのブランチ
にあたるものですよね？

27 ：デフォルトの名無しさん：2013/06/01(土) 22:05:18.89

根本的に違う
入門記事とかそこらじゅうにあるんだから
ちょっとは自分で調べろよ

28 ：19：2013/06/01(土) 22:14:03.46

>>27
きちんと理解できてないかもしれませんが、入門記事は読んでます。

お手間をかけて申し訳ございませんが、どう根本的に違うのか教えていただけないでしょうか。

29 ：デフォルトの名無しさん：2013/06/01(土) 22:17:23.53

>>27
機能的な意味では確かに全く違うが、
運用的な側面で比較するなら妥当な気もする

30 ：デフォルトの名無しさん：2013/06/01(土) 22:19:07.12

根本的に違うものが比較できるかよ。
事実がどうかは別として、根本的に違うと理解してる奴に聞くことじゃない。
悪意があるようにしか思えん。

31 ：デフォルトの名無しさん：2013/06/01(土) 22:30:21.42

そもそもCVS流儀の使い方をするならgit使う必要ないだろ
CVSが流石に古くなってきたって程度の理由ならsvnにしとけ

仕事で自分の意思でなくgitに移行することになったんなら
こんなところで質問すんな
誰か犠牲者がでる

32 ：デフォルトの名無しさん：2013/06/01(土) 22:37:48.33

>>30
横やりだが、上のやり取りを見て一言。

俺はCVS→SVN→GITとの流れで使ってきた人間だが
>>26の言いたいことはわかるし、>>27の根本的に違うという発言も理解出来る。

>>26
多分、あなたの考えで問題ない(だろう)よ。

33 ：デフォルトの名無しさん：2013/06/01(土) 22:58:25.48

>>19
そういうことだな。
一部だけのチェックアウトができないから未だにcvsで運用しているレポジトリがあるわ。

34 ：デフォルトの名無しさん：2013/06/01(土) 23:37:07.37

>>24
CVSはどうやって覚えたんだ？
CVSを知らなかったときのことを思い出せ。

35 ：デフォルトの名無しさん：2013/06/02(日) 00:07:24.71

>>34
一度覚えたら、その比較でしか覚えられないだろ？
日本人に日本語を覚えた時のように英語を覚えろと言っても無理だろ？

36 ：デフォルトの名無しさん：2013/06/02(日) 00:43:58.44

どうだろ
母国語以外で比較しないと意味ないな
既に英語を知ってる人が
フランス語を覚える時は
英語を忘れた方が良くね？

37 ：デフォルトの名無しさん：2013/06/02(日) 03:25:37.22

>>36
そんなことはないだろ。

話をプログラムミング言語に移すと
Java使いがC#覚える時は大抵比較的で覚えるだろ

そうでないと非効率だ

38 ：デフォルトの名無しさん：2013/06/02(日) 03:28:44.09

他の言語を覚えるのはまた1から始まりじゃないからな
共通して利用できる部分は多々ある

39 ：デフォルトの名無しさん：2013/06/02(日) 03:46:02.28

>>37
C#は、ほとんどJavaのパクリじゃないか。

40 ：デフォルトの名無しさん：2013/06/02(日) 11:38:21.03

>>19
合ってる。
gitはリポジトリの一部をチェックアウトできないので、
CVSのモジュールごとにリポジトリを作る必要がある。

>>26
違う。ベアリポジトリは集中管理用のリポジトリ。

CVSのチェックアウトに一番近い概念はgitではリポジトリのクローン。
みんなが参照する中央のリポジトリがベアリポジトリ、
それをクローンして各自が作業に使うのがノンベアリポジトリ。

41 ：デフォルトの名無しさん：2013/06/05(水) 20:04:03.61

>>12
返事キター

(●●) 様

はじめまして。
株式会社ビズリーチCTOの△◎◇と申します。

この度はコードブレイクにご登録いただきまして、
誠にありがとうございます。

ご挨拶といたしまして、私たちが「コードブレイク」を始めた理由と
機能についてお話させてください。

■コードブレイクを始めた理由

私はITエンジニアなどのIT・Webエンジニアが
正当に評価されていないことに古くから疑問を持っていました。

高度な技術を持つIT・Webスペシャリストは、世界中で重宝される存在です。
しかし日本においては、必ずしもその通りではなく、評価されるべき人材が、
正当な評価とそれに見合う報酬を受け取っているとは言い切れません。

優秀なIT・Webエンジニアが
自分の市場価値を正しく把握することで、
もっともふさわしい仕事とそれに見合う報酬を受け取ってほしい。
「codebreak;（コードブレイク）」は、そんな想いから作ったサービスです。
サービス名には、IT・Webエンジニアの周りを取り巻いていた、
不必要な「規約、規則＝code」を「壊す、打ち破る＝break」という想いを込めています。

■コードブレイクの機能
以下略

42 ：デフォルトの名無しさん：2013/06/05(水) 20:19:40.68

Webエンジニアなんてプログラマーの中でも底辺じゃん

43 ：デフォルトの名無しさん：2013/06/05(水) 23:58:44.11

>>42
昔から「士農工商犬プログラマ」と言うように
そもそもからプログラマーが底辺なんだから、
底辺の中で上下を決めた所でしょうもない

44 ：デフォルトの名無しさん：2013/06/06(木) 11:24:50.99

Gitのリベースとは、SVNで言うところの
「機能ブランチの再統合マージ」のことですよね？

45 ：デフォルトの名無しさん：2013/06/06(木) 11:46:23.53

Gitのリベースはブランチをマージするとかじゃない場合も使える
ひとつのブランチ上でコミットの順番を入れ替えるとかもリベース

46 ：デフォルトの名無しさん：2013/06/06(木) 11:57:33.66

コミットログの編集、削除やらも git rebase やな

47 ：デフォルトの名無しさん：2013/06/06(木) 12:19:05.74

リポジトリ内に既にあるものを変更するからって何でもかんでもrebaseに押し込めすぎ

48 ：デフォルトの名無しさん：2013/06/06(木) 13:15:36.02

コミットが何なのかを理解すれば、その何でもかんでもと思ってることが
rebaseひとつで済む理由を理解できる。

49 ：デフォルトの名無しさん：2013/06/06(木) 13:38:19.05

で、そういうオペレーションをrebaseって言葉で表現するの？

50 ：デフォルトの名無しさん：2013/06/06(木) 13:46:18.50

覚えるの面倒だから全部rebaseでいい

51 ：デフォルトの名無しさん：2013/06/06(木) 16:59:54.41

だがブランチ切り替えをcheckoutにしたのは異論あり

52 ：デフォルトの名無しさん：2013/06/06(木) 17:07:26.93

ファイルを指定したときとブランチ名指定したときで全く違う機能持ってるのはよくないな

53 ：デフォルトの名無しさん：2013/06/06(木) 17:22:38.93

rebaseと比較の上で考えると全く違うってほどでもない。

54 ：デフォルトの名無しさん：2013/06/06(木) 17:29:31.17

ファイル指定の時にワークのファイル保護さえしてくれれば良い気がした。
なんであそこだけノーガードなんだろ？

55 ：デフォルトの名無しさん：2013/06/06(木) 17:42:26.53

いやいやcheckoutのそれはまったく違うぞｗ
それに比べたらrebaseがやることは常に一緒。

56 ：デフォルトの名無しさん：2013/06/06(木) 22:09:52.71

gitのuiは飾りです。偉い人にはそれが分からんのですよ。

従来のSCMとは概念から違うのに、既存のSCMと無理矢理コマンド合せようとしたから破綻してる。

57 ：デフォルトの名無しさん：2013/06/07(金) 08:07:39.73

UIが内部的な処理に引き擦られてしまっているだけ
ボトムアップな作り方だからそうなったというだけ

58 ：デフォルトの名無しさん：2013/06/07(金) 08:49:15.24

つまり、片手を鼻くそほじるためにあけるためだけのものではなく、
gitの概念をきちんと理解した上での新しい憂を作れと。

59 ：デフォルトの名無しさん：2013/06/07(金) 11:25:19.35

-リモートとローカルのマージ
-メインブランチとトピックブランチのマージ

上記は全く違うものだと思うのですが、
皆さんは両方ともマージと呼んで混乱しないんですか？

60 ：デフォルトの名無しさん：2013/06/07(金) 11:49:15.77

FFマージと非FFマージとFF状態での非FF形式のマージ。
非FF状態でFF形式のマージはできない。
このぐらいしか意識してない。

61 ：デフォルトの名無しさん：2013/06/07(金) 15:48:26.96

～と～のマージと呼ぶ方が混乱する。
～から～へのマージと呼んでもらえば、何を対象にしてても同じ

62 ：デフォルトの名無しさん：2013/06/07(金) 16:09:33.23

VisualSVNServer的なWindows上に簡単に
インストール出来るgitサーバーパッケージ
って無いんですか？

63 ：デフォルトの名無しさん：2013/06/07(金) 16:47:33.66

repoの話題はここでいいんかな

複数のgitリポジトリを包含したrepoで、新規にtopicブランチをつくりたいです。

$ repo start topic --all
みたいにするとtopicブランチは出来上がるんだけど、ブランチ元がずいぶん昔の
バージョンになってしまう。
現在 $repo status とかで見えているカレントのブランチから派生させたいんだけど
どうやったらよいですか？

64 ：デフォルトの名無しさん：2013/06/07(金) 23:02:39.65

>>59
>-リモートとローカルのマージ
gitの場合はこれが無い
存在するのはリモートと関連付けられたローカルとのマージのみ
ローカルとリモートを同期させるかは別問題

65 ：デフォルトの名無しさん：2013/06/10(月) 12:06:58.48

git-svnの利用に関して質問です。

Subversionの場合、よく一つのリポジトリで複数のexeやlibを
管理することが多いです。そんな場合でもgit-svnは利用できますか？

66 ：デフォルトの名無しさん：2013/06/10(月) 12:09:27.77

>>65
そのような用途には若干不向きです

67 ：デフォルトの名無しさん：2013/06/10(月) 12:18:46.68

>>66
不可能だと思って聞いたんですが、「不向き」とおっしゃるということは
可能ということですか？

<追加質問>
もし、1リポジトリ＝1exeが保証されているとして、
リモートリポジトリをSVNである場合の不利な点って何が有りますか？

68 ：デフォルトの名無しさん：2013/06/10(月) 12:46:46.02

そりゃ全部いっしょくたにすりゃ可能は可能だろｗ

69 ：デフォルトの名無しさん：2013/06/10(月) 13:00:36.05

>>65
バイナリも管理(リポジトリに登録)できるか、という意味であればできる。

70 ：デフォルトの名無しさん：2013/06/10(月) 13:03:06.73

>>67
中央管理だからサーバーが死んだら終わりってくらい？

71 ：デフォルトの名無しさん：2013/06/10(月) 13:20:07.94

>>69
バイナリ管理は出来るのは大前提であり、
1リポジトリ＝1exeが守れなくてもgit-svnで運用できるかという
ことを私は聞きたかったのですが…。

72 ：デフォルトの名無しさん：2013/06/10(月) 13:21:04.71

>>70
ネットワーク速度的やCPU処理速度的な
デメリットは特にないということですか？

73 ：デフォルトの名無しさん：2013/06/10(月) 13:31:08.72

速度はハード性能を上げれば済む話

機能的な差が無いかが気になる

74 ：デフォルトの名無しさん：2013/06/10(月) 13:41:00.07

>>71
出来る出来ないで言えば出来る
と言っておろう

75 ：デフォルトの名無しさん：2013/06/10(月) 13:47:43.49

画像大量にブチ込むとかやってる人居ない?

76 ：デフォルトの名無しさん：2013/06/10(月) 14:24:31.47

>>74
その出来るという運用方法を教えていただけないでしょうか。

77 ：デフォルトの名無しさん：2013/06/10(月) 15:00:40.33

７７

78 ：デフォルトの名無しさん：2013/06/10(月) 15:05:22.76

>>74
出来ないなら出来ないと認めればいいのに orz
突っ込む方も突っ込む方だが…

79 ：デフォルトの名無しさん：2013/06/10(月) 16:54:55.00

そもそも何が出来ないと思ってるか不明。不便を許容したら大抵のことは可能の範疇にはいるだろ？
なんとかして運用方法を知りたいというよりも、なんとかして不可能という言質を引き出したいように見える。
git-svnはsubversionリポジトリのサブディレクトリと関連付られるんだから、製品それぞれを別のリモート名にすりゃ良いんじゃないの？

80 ：デフォルトの名無しさん：2013/06/10(月) 17:10:56.30

たくさんのexeファイルを含むSVNのリポジトリをgit-svnで管理できるか？ってことだよね
できるんじゃないの？
exeファイルの数やサイズや更新頻度によっては実用にならない可能性はあるけど
それは知らんから、試してみてくれ

81 ：デフォルトの名無しさん：2013/06/10(月) 17:37:09.40

>>79の冷静な対応に感動した

82 ：デフォルトの名無しさん：2013/06/19(水) 12:28:36.82 ID:QJZyPKVo!

git clone githubでクローンしたいプロジェクトのurl

cloneした状態でgit logをすると元のプロジェクトの人が貯めてきたログが残っています。
こういうのってcloneした後に.gitディレクトリを消してからgit initってしてリポジトリを作るものでしょうか？
それともこのcloneしてそのままaddとかcommitをしていくべきでしょうか？

83 ：デフォルトの名無しさん：2013/06/19(水) 12:48:24.23

githubでクローンしたいプロジェクトを
自分のプロジェクトに fork してから
git clone 自分のプロジェクトのurl

84 ：デフォルトの名無しさん：2013/06/19(水) 14:22:11.09

>>75
広告デザインとか、ウェブサイトのデザインで使うときには、材料を全部入れる。
Macのgitブラウザは、よく使うフォーマットの画像がプレビューできるので
画像のdiffもバイナリdiffじゃなく、プレビューで見られるので便利。

85 ：デフォルトの名無しさん：2013/06/21(金) 01:48:02.01

LinuxでGUIからgit使うのにお勧めツールないでしょうか
redmineみたいな感じでチケット管理もできると最高なのですが

86 ：デフォルトの名無しさん：2013/06/21(金) 12:06:38.55

まるでWindowsにならあるような書き方ですが
もちろんWindows版にもありません。

87 ：デフォルトの名無しさん：2013/06/21(金) 14:35:22.19

Windowsの方はVisualStudioがgitのネイティブサポートを始めたよね。まだβっぽいけど。

88 ：デフォルトの名無しさん：2013/06/21(金) 14:47:18.57

チケット管理が無いとダメなら
giteyeとかsoucetreeみたいな普通のクライアントじゃ無理なんじゃ？

89 ：デフォルトの名無しさん：2013/06/21(金) 21:35:05.74

コマンドラインで使うのが一番便利だと思うのだけどなあ。

90 ：デフォルトの名無しさん：2013/06/22(土) 17:26:20.54

全体をだらだら眺めるような時はtigとか使うのも便利だと思うよ

91 ：デフォルトの名無しさん：2013/06/22(土) 22:47:56.90

tig試しに使って見たことはあるのだけど、結局、logformatに%dの出力足せばすむ話だし。
差分もvim -R -食わせちゃった方がなれていることもあって不便はかんじないんだよなぁ
そもそも、git guiとかgtk一応はいってるてのもある。
Xming知ってから世界はかわった(笑)

コンフリクトした時、meld使うくらい？
ってことで、rebaseできるものでもなければguiあんま必要ない。
っていうか、rebaseのできるguiってありそうでないよね。

92 ：デフォルトの名無しさん：2013/06/23(日) 13:54:29.47

SourceTreeは普通のrebaseもインタラクティブrebaseもできる
それだけでは細かくコミット編集するのにはまだ不便だが
普通に使うのには十分だと思う

93 ：デフォルトの名無しさん：2013/06/23(日) 16:05:10.37

おお、それは朗報。後で少し調べてみよう。
rebaseって、tagやbranchため込んでると手間が増えて手でやるの面倒だったんだ。
branchからbranchつくってるやつとか。

それとも、tagはpushする直前につけて、branchはmergeしたあとはすぐ削除したほうがいいのかな？

94 ：デフォルトの名無しさん：2013/06/26(水) 04:02:08.36

$git --init
$touch ticket.org
でemacs使った簡易Redmineもどきできるな

95 ：デフォルトの名無しさん：2013/06/27(木) 14:52:50.50

gitweb ってブランチの表示機能が無いのか～
結構良いデキなのに、惜しいなぁ

96 ：デフォルトの名無しさん：2013/06/30(日) 15:54:27.81

複数のbranchがあるリポジトリで、リモートのすべてのbranchの変更点をローカルに反映
させたい場合、checkout/pullを全branchについて実行するより簡単な方法ってありますか？

97 ：デフォルトの名無しさん：2013/06/30(日) 18:08:50.32

ブランチ未指定でプルプルすればいいんじゃないの？

98 ：デフォルトの名無しさん：2013/06/30(日) 18:18:27.87

すいません、プルプルってなんです？

99 ：デフォルトの名無しさん：2013/06/30(日) 18:19:41.48

How to fetch all git branches - Stack Overflow
http://stackoverflow.com/questions/10312521/how-to-fetch-all-git-branches

100 ：デフォルトの名無しさん：2013/07/03(水) 13:34:28.85

なんかgithubおもくね？

101 ：デフォルトの名無しさん：2013/07/05(金) 12:41:49.72

儲からなくてもいいんだってさ。

和製GitHubの「gitBREAK」は「儲からなくてもいい」
ttp://www.atmarkit.co.jp/ait/articles/1307/03/news002.html

102 ：デフォルトの名無しさん：2013/07/09(火) 10:50:38.92

あるタグとあるタグの差分をファイル名一覧だけ表示したい

103 ：デフォルトの名無しさん：2013/07/09(火) 11:09:56.92

>>101
プライベートリポジトリでも運営は閲覧できるというクソみたいな規約や
職種・年収記入が必須とか
退会手続きはフォームから記入とか
今は直ったらしいけど、いろいろアレすぎて触れられねーよ

104 ：デフォルトの名無しさん：2013/07/09(火) 11:40:35.73

>>103
>プライベートリポジトリでも運営は閲覧できるというクソみたいな規約や
これはキモイ

105 ：デフォルトの名無しさん：2013/07/09(火) 11:42:50.26

>>103
年収記入はネタだろ
あれは大いにウケタ

106 ：デフォルトの名無しさん：2013/07/09(火) 11:57:40.54

商品(奴隷)のカタログなので価格は必須

107 ：デフォルトの名無しさん：2013/07/09(火) 20:43:23.20

みんなGitで使うディレクトリはまとめてる？

108 ：デフォルトの名無しさん：2013/07/09(火) 22:18:41.21

まとめるという、意味が分からん

109 ：デフォルトの名無しさん：2013/07/09(火) 23:02:42.84

自分は work-git というフォルダ以下に置いてたりするけどそういうことじやないかな。
work は subversion リポジトリとして使ってた。

110 ：デフォルトの名無しさん：2013/07/09(火) 23:37:29.55

>>107
共有は/var/vcsに、workは~/usrにだいたいのプロジェクトを入れている。あと別ホストにバックアップであげてるな。
3箇所だからまとめてないっとことだな。

111 ：デフォルトの名無しさん：2013/07/10(水) 21:03:01.95

>>107
Gitというよりそういう系は~/proj以下に置いていて、そんなかで適当に種類別に分けてる。
て、Git関係ないけど

112 ：片山博文MZパンク ◆0lBZNi.Q7evd ：2013/07/14(日) 00:50:04.61

sjisのソースをgithubに登録したらまずいっすか？

113 ：デフォルトの名無しさん：2013/07/14(日) 01:02:21.92

>>112
知らないからやってみて報告してくれ

114 ：デフォルトの名無しさん：2013/07/14(日) 01:48:51.26

>>112
片山さんgithubやってるの？

115 ：デフォルトの名無しさん：2013/07/14(日) 07:51:48.53

家でGitの練習したいんだけど
どこかに手軽にcloneできるリポジトリーみたいなのないかな

116 ：デフォルトの名無しさん：2013/07/14(日) 08:39:48.55

githubにいくらでもあるじゃないですか～

117 ：デフォルトの名無しさん：2013/07/14(日) 08:56:19.92

練習ならローカルに自分で作ったbare repositoryをcloneすればいいんじゃない？
push/pullは自由だし、すぐ消せるし

118 ：デフォルトの名無しさん：2013/07/16(火) 13:09:29.50

>>114
片山ゆうくん？

119 ：デフォルトの名無しさん：2013/07/16(火) 18:54:42.71

>>118

120 ：デフォルトの名無しさん：2013/07/18(木) 13:03:03.34

GUIはTortoiseGitしか無いし、それで十分と思ってきたけど、
SourceTreeがGitに対応して、なかなか使える感じになってきたね。
ちょっともっさり気味だが。

121 ：デフォルトの名無しさん：2013/07/19(金) 01:06:09.53

Eclipseのプラグインがオススメ

122 ：デフォルトの名無しさん：2013/07/19(金) 03:15:40.04

SourceTreeはsquash mergeができないのが厳しい。一応追加機能の要望は出てるみたいだけどね。

123 ：デフォルトの名無しさん：2013/07/19(金) 07:31:51.35

まぁ細かい作業はターミナルでやればええやん
GUIとしてはグラフも十分見やすいしあれはあれでいいや。

124 ：デフォルトの名無しさん：2013/07/19(金) 10:36:26.13

おれも、SourceTree はグラフやdiff を見るためのツールとして使っている。
何らかの変更処理は、コマンドラインでやっている。

125 ：デフォルトの名無しさん：2013/07/20(土) 12:24:52.10

現状は、CLIとGUIで使い分けだな

126 ：デフォルトの名無しさん：2013/07/20(土) 16:31:29.02

git clone ssh:192.168.0.1/tmp/Depot/XXXXX.gitが、
ホストサーバーのLinuxの中だとつながるのに
Windowsからだとつながりません
cygwinもmsysgitもsshでシェルにはログインできるけど
git コマンドはパスワードがPermission deniedで弾かれちゃいます
なぜでしょう？

127 ：デフォルトの名無しさん：2013/07/20(土) 16:55:23.98

ユーザ名は？

128 ：デフォルトの名無しさん：2013/07/20(土) 18:20:20.40

すみません。ユーザー名がXXXXとすると
[email protected]'s Passwordって聞かれるので
どこかで勝手に認識してるのかな？と思ってるんですが．．．

と思ったらユーザー名ってWindowsのログオンユーザー名が使われるのかな？微妙に大文字小文字がLinux側と違うけどこれが原因？

git のログインアカウントって指定できるんでしょうか？

129 ：デフォルトの名無しさん：2013/07/20(土) 18:29:19.63

git clone ssh://[email protected].～

130 ：デフォルトの名無しさん：2013/07/20(土) 18:41:28.22

あーーーーーりがとうございましたーー
うまく行きましたーーー

131 ：デフォルトの名無しさん：2013/07/20(土) 19:32:42.08

>>130
1500円です

132 ：デフォルトの名無しさん：2013/07/21(日) 00:53:56.24

スイス銀行のいつもの口座へ３日以内に振り込んでくれ

133 ：デフォルトの名無しさん：2013/07/21(日) 00:56:16.22

1500円ぐらい、おまけしてやれよ

134 ：デフォルトの名無しさん：2013/07/21(日) 02:31:51.24

振り込み手数料のが高い

135 ：デフォルトの名無しさん：2013/07/21(日) 10:32:18.84

これ見て勉強汁
http://www.youtube.com/watch?v=b1vNBa4kCyM&list=PLoqUxxYo1OIYDBWTUQ9jDBh4-lAfK-WFc

136 ：デフォルトの名無しさん：2013/07/24(水) 13:32:33.73

手を動かして楽しみながら覚えるならこっち
http://k.swd.cc/learnGitBranching-ja/

137 ：デフォルトの名無しさん：2013/07/24(水) 21:54:59.82

GUIができるようになるまでGitは使わない

138 ：デフォルトの名無しさん：2013/08/01(木) 17:29:18.73

プログラマーだけがプロジェクトに関わってるなら今すぐGitにするわｗ

139 ：デフォルトの名無しさん：2013/08/01(木) 17:31:13.65

2chもGit化するか？

140 ：デフォルトの名無しさん：2013/08/01(木) 17:35:33.84

GUIだと簡単という幻想。

141 ：デフォルトの名無しさん：2013/08/01(木) 18:02:36.33

今の時代企画やデザイナーさんにコマンドラインおぼえろとか言っても無理でしょ…

142 ：デフォルトの名無しさん：2013/08/01(木) 18:22:31.00

>>138
あー、全く同意。もちろん個人ではgit使いまくり。楽しくて仕方ない。

143 ：デフォルトの名無しさん：2013/08/01(木) 18:39:33.42

GUIにしたところで、いちいちどうやるのか聞いてくる。GUIは教えづらいし、こっちがGUIも覚えなきゃいけない。

144 ：デフォルトの名無しさん：2013/08/01(木) 18:48:52.48

コマンドラインはコマンドライン状態にする前提とかがあるから面倒なんだよ。GUIのが遥かに教えやすい。
覚えなきゃいけないとか言ってるのは、プログラマーとしてどうなのよと思うわ。

145 ：デフォルトの名無しさん：2013/08/01(木) 19:04:46.04

ええっ！？

146 ：デフォルトの名無しさん：2013/08/01(木) 19:08:22.12

プログラマじゃない人にとってって意味でしょ

147 ：デフォルトの名無しさん：2013/08/01(木) 19:31:15.23

プログラマーとしてどうなのよ

148 ：デフォルトの名無しさん：2013/08/01(木) 19:38:34.76

底辺にはsourcetreeのguiで見える程度の機能で余る。
コマンドラインでしか触れない機能は選民だけが使えばいい。
それほどgitは便利。

149 ：デフォルトの名無しさん：2013/08/01(木) 20:42:55.88

CLIで出来ることでも、左手でおにぎり食べながら作業するときは
GUIでやった方が効率はあがる。つまりそういうこと。

150 ：デフォルトの名無しさん：2013/08/01(木) 21:26:33.35

>>144
コマンドライン状態って何?
遠隔地に居る人にGUIで指示するしてる人が、もっと右、丸に毛の生えたアイコンの…とか言っているの聞いてると笑いそうになる。CUIならコピーしてメールで送れる。GUIだといろんなソフトあるし、具体的な操作方法は調べないといけない。
君はそのソフトに触らなくてもどう操作すればいいのか、わかるのか?

151 ：デフォルトの名無しさん：2013/08/01(木) 21:30:25.83

だから、そもそもLinuxコマンドラインだけでやってる職場がどんだけあるんだっての。
GUIの操作方法なんて「調べる」ってほどのものかよ。

152 ：デフォルトの名無しさん：2013/08/01(木) 21:43:32.62

そりゃ調べなきゃいかんだろ
バージョンがちょっと違ったら別の画面見て話してたなんてことが
しょっちゅう起きるのに

153 ：デフォルトの名無しさん：2013/08/01(木) 21:48:34.63

いったん会社で導入して、バージョンが変わったからと言ってプログラマーがいちいち説明することなんてないだろ。
メジャーなTortoiseSVNなんかでもそうだろ。たかがバージョン管理ソフトでそんな大袈裟なことはない。

154 ：デフォルトの名無しさん：2013/08/01(木) 21:51:09.19

一応正確に言っておくと、SVNとクライアントソフトとしてのTortoiseSVNの組み合わせって意味な。

155 ：デフォルトの名無しさん：2013/08/01(木) 23:59:50.15

たかがバージョン管理にコマンドや仕様を覚えさせられるのは迷惑だろ

156 ：デフォルトの名無しさん：2013/08/02(金) 00:08:12.93

秘書に頼めば余裕だしな

157 ：デフォルトの名無しさん：2013/08/02(金) 01:30:15.95

GUIだと、仕様とやる事とボタンの位置を覚えなきゃいけないと言う。

158 ：デフォルトの名無しさん：2013/08/02(金) 03:28:48.53

なんだそりゃ。それが大変なことだとは思わないが、プログラマ以外に納得させなきゃ導入できんぞ。

159 ：デフォルトの名無しさん：2013/08/02(金) 08:39:40.33

GUIだと、自動化が面倒くさいと思う。

160 ：デフォルトの名無しさん：2013/08/02(金) 08:41:59.12

Gitはたかがバージョン管理ツールではない
これは編集過程を柔軟に管理するツール
わたしにとってはエディタやIDEと同じぐらい重要
GUIはGitを従来のバージョン管理ツールの枠に押し込めてしまうようなものしか存在しないから
現時点ではコマンドラインで使わないとその真価は発揮できない

161 ：デフォルトの名無しさん：2013/08/02(金) 09:11:09.36

>>160
>GUIはGitを従来のバージョン管理ツールの枠に押し込めてしまうようなものしか存在しないから

Git for Windows は使ってみたことある？

162 ：デフォルトの名無しさん：2013/08/02(金) 09:55:54.61

>>161
Interactive rebaseに対するGUIが整備されてるなら試してみようと思うんだけど
どんな感じ？

163 ：デフォルトの名無しさん：2013/08/02(金) 10:41:16.46

日常のルーチン化した部分はワンタッチでポンと出来て
そうでない部分はこまごまとコマンドラインで作業して
という住み分けが出来るならGUI使いたい

164 ：デフォルトの名無しさん：2013/08/02(金) 11:29:06.61

diffとかmergeとかはGUIを使ってやりたいね。

特にコンフリクトした場合の対応とか。ネットに普通に転がってるのだと
ふわふわした説明で競合を解決してと書いてあるようなのが多い。

mergetoolコマンド使って外部のGUIプログラムを使ってどうこうするとか
いうのを書いてあるのはほとんど無いよね。

あとは、ログのツリーはGUIで見れたほうが分かりやすいとは思う。

165 ：デフォルトの名無しさん：2013/08/02(金) 11:52:27.27

WinMergeってどうなの？使える？

166 ：デフォルトの名無しさん：2013/08/02(金) 13:31:15.05

>>165
gitからWinmergeは使える。
Winmergeからgitは使えない。

167 ：デフォルトの名無しさん：2013/08/02(金) 18:35:03.96

せっかく来たのに
まだ決定打的なGUI出来てないの
また明日こよ

168 ：デフォルトの名無しさん：2013/08/02(金) 20:25:16.84

>>167
もう来なくていいよ。

169 ：デフォルトの名無しさん：2013/08/02(金) 21:40:46.98

いやいや、>>167が決定打的なGUIをひっさげて明日再びやってくるって意味だろう

170 ：デフォルトの名無しさん：2013/08/02(金) 22:52:20.86

昔VSSとか使ってたくらいで、オライリーのGit本読んで
使い始めたけど、これカーネル開発を世界規模で共同開発するとかには
確かに必須の物なんだろうけど、
例えば10人くらいの同じ部屋にいるプロジェクトで使うには
機能過剰な気もするな。
あと使い手を凄く選ぶ（難しい）と思う。
単純なチェックイン・チェックアウト型の排他管理も要件を満たすなら良いと思うな
Gitにもファイルの排他編集機能とか有ったらいい気がするんだけど

171 ：デフォルトの名無しさん：2013/08/02(金) 23:43:38.23

そういう用途なら素直にsubversion使ったほうがいいと思う
分散型はfile lockは事実上不可能だし意味が無い

172 ：デフォルトの名無しさん：2013/08/03(土) 00:10:14.61

>>170
過剰な機能ってなんだ？

173 ：デフォルトの名無しさん：2013/08/03(土) 00:26:18.08

ログ見るのとhunk単位ステージングだけはGUIかなにかあったほうが楽だな
pullやmergeやrebaseだとコマンドラインのほうが細かいとこに手が届く

174 ：デフォルトの名無しさん：2013/08/03(土) 07:00:21.22

>>170
>あと使い手を凄く選ぶ（難しい）と思う。

チームに新人が来る度にBTSの使い方も含めて分散型VCS(会社はMercurialなんだけどね)を
使った開発のイテレーションの回し方を一通り指導するけれども、特に困難は無いなぁ。
個人的経験の範囲だけど使い手は選ばないと思う。ちゃんと学べば誰でも普通に使える。

単に分散VCSの使い方を教えるだけではダメで、トピックブランチを切って手元のリポジトリ
でこまめにコミットやマージをする開発スタイルとセットで教えないと御利益は伝わりにくい。

>例えば10人くらいの同じ部屋にいるプロジェクトで使う

今のプロジェクトの最小単位はそんな規模だけど、普通に便利。
上司が明日からSubversionにしますとか言い出したら普通に暴動が起きると思う。

175 ：デフォルトの名無しさん：2013/08/03(土) 11:04:58.66

>>174
ドックフードを食べるという訳じゃないが、チュートリアルプロジェクトみたいので
回すのは結構いいかもね。頭の中身をテキストに落としただけで実際に机上で
すら回したことのないライブラリ管理を押し付けるのは止めてくださいという
プロジェクトは多いからね。

176 ：デフォルトの名無しさん：2013/08/03(土) 11:21:12.25

難しいと言ってる香具師は選ばれたんだよ
あきらめろ

177 ：デフォルトの名無しさん：2013/08/03(土) 13:25:47.03

底辺web土方が一番使ってる気がする。
全般的に頭が悪いので高度な機能？は使わないから
こんなにわかりやすくて便利なものはない

178 ：デフォルトの名無しさん：2013/08/03(土) 13:49:57.86

Gitみたいな分散型VCSを使わないのは
高機能エディタやIDEを使わずにメモ帳でプログラムするみたいなもんだ

179 ：デフォルトの名無しさん：2013/08/03(土) 16:35:23.05

ちょっと視点を変えると、分散型のVCSを使っていなかった時代はファイルの更新履歴の
管理はIDE等が持つUndoやローカル編集履歴機能に頼る比率がより大きかった気がする。
そういうのは更新内容のコメントが残らないしチームで共有もされない。

コミットの相手はローカルだしブランチを切るのも手軽なのでとにかくコミットが気軽。
記録に残るコメント付きコミットの頻度がサーバー上のtrunkをみんなで突っつくよりも
格段に向上するだけでも分散VCSを使う価値はあると思う。

180 ：デフォルトの名無しさん：2013/08/03(土) 18:09:50.66

コマンドでたいていのことはできるんだけど
履歴みたり差分みたりするのはツールがないと不便
なんか中途半端なんだよな

181 ：デフォルトの名無しさん：2013/08/03(土) 18:52:32.38

馬鹿には無理

182 ：デフォルトの名無しさん：2013/08/03(土) 23:56:53.50

馬鹿にもソース管理できるようにするツールだろ

183 ：デフォルトの名無しさん：2013/08/04(日) 02:04:41.61

cui派だけどtigはあった方がいい

184 ：デフォルトの名無しさん：2013/08/04(日) 02:29:04.75

正直、Winしか使って無い人にLinuxCUIを教えるくらい難しい。そこがネック。

185 ：デフォルトの名無しさん：2013/08/04(日) 03:50:13.78

svnの時はコミットするのに慎重になっていたが、gitだとバシバシできて良い。

186 ：デフォルトの名無しさん：2013/08/04(日) 17:32:40.98

Gif　ジフ
Git　ギット

(´Д｀)？

187 ：デフォルトの名無しさん：2013/08/04(日) 19:16:02.94

Gimp　ギ・・・ジン・・・ギンプ（小声）

188 ：デフォルトの名無しさん：2013/08/04(日) 21:16:24.35

>>184
コピペもできないのか。

189 ：デフォルトの名無しさん：2013/08/04(日) 22:19:27.78

コピペ失敗したときに不安のストレス与えて可哀想だろ

190 ：デフォルトの名無しさん：2013/08/04(日) 23:52:04.75

cogito ergo sum
コギト！

191 ：デフォルトの名無しさん：2013/08/05(月) 00:26:30.63

>>189
コピペしてもエンターする前に見直せるけど、ミスクリックは見直せないね。

192 ：デフォルトの名無しさん：2013/08/08(木) 03:16:05.55

githubが無くても、git使ってた？

サービスたち上げること考えたら、割と他のVCSの方が使いやすくパッケージングされてるように感じた。

193 ：デフォルトの名無しさん：2013/08/09(金) 14:08:55.72

特定のディレクトリ以下のファイルを自動でリポジトリに追加することってできませんか？

194 ：デフォルトの名無しさん：2013/08/09(金) 14:30:17.84

シェルスクリプトを定期的に動かせばいいんじゃないの？

195 ：デフォルトの名無しさん：2013/08/10(土) 05:04:59.56

>>193
pre-commt フックとか

196 ：デフォルトの名無しさん：2013/08/10(土) 15:58:49.25

gitのメリットがいまいちわかりません。
一人でテストケース書かない俺でも使うメリットありますでしょうか。
コードはPHP。

今はdropboxを使って、古いコードに戻してます。

教えてください。

197 ：デフォルトの名無しさん：2013/08/10(土) 17:15:47.13

メリット:
将来集団での開発に参加したときに恥をかかない。昔svnは今はgitも一般教養。

DropBoxはファイル単位での履歴しか持っていないけれども、gitというか一般論と
してバージョン管理システムはプロジェクト全体のスナップショットの履歴を持つ。
プロジェクト全体を何週間前に動いた状態とかにコマンド一発で巻き戻せる。
(もちろん個別ファイルの巻き戻しも可能)
便利かどうかは別としてVCSを使ったバージョン管理というのはそういうものだから
慣れていて損はない。

単にファイルを巻き戻すだけではなく古いファイルと内容を比較するといった操作
が用意されている。DropBoxだとこれは面倒臭いでしょ。

git的な事情としてブランチベースの開発がし易い。何か新しい機能追加をする場合
はブランチという派生バージョンを作って、そちらを書き換えて、上手く動いたら
メインブランチに変更内容をマージして書き戻すというサイクルを細かく繰り返す。
個人利用であっても複数の開発トピックが同時進行する場合は便利。
そしてブランチベースの開発も一般教養になりつつあるから知らないと恥ずかしい。

198 ：デフォルトの名無しさん：2013/08/10(土) 17:36:36.74

たかがGit位、知らない奴がいたら教えてやれば済むことだと思うんだけど
Git知らなきゃ恥って思ってる人たちはメディアで饒舌な人たちに
踊らされ過ぎなんじゃ無いだろうかと．．．
Git知ってるからといってそれにいかほどの価値があるというのだろうか

199 ：デフォルトの名無しさん：2013/08/10(土) 17:40:19.13

>>198
なんかトラウマあったんだろうな...

200 ：デフォルトの名無しさん：2013/08/10(土) 17:51:30.88

「（他のを使っているから）Gitを知らない」ならともかくとして

「プログラマーなのにバージョン管理の利点自体を知らない」レベルだと普通に恥ずかしいし、知らない事が恥に値する程の価値は十分有るでしょ

201 ：デフォルトの名無しさん：2013/08/10(土) 18:06:45.97

どうだろう、例えば独学で凄い3Dグラフィックエンジン作ってた様な人が
仮にバージョン管理システムの存在をこれまで知らなかったとしても
いくらもその人の価値を落とすようなことは無いと思うんだよね
業務でプログラムしてました、これまでバージョン管理とか使ったことありません
みたいな事を想定して恥だと言ってるんだと思うんだけど
個人的に思うのは、世の中で知る価値のある技術的なトピックというのは
ひとりの人間が一生かけても取得出来ない数があるのは明らかで
こう言うなんというか、自分の知ってる10のうちから謎々を出してしか
人の価値を計れないと、自分より優れた人の価値は絶対に計れないだろうなぁと

202 ：デフォルトの名無しさん：2013/08/10(土) 18:11:48.54

Gitを知っている事に価値があるかはともかく、Gitの類を使った開発に参加する際に
Gitの使い方を知らなければその人は当面無価値だよね。参加できないのだから。

受け入れる側が懇切丁寧親切に教えてくれるラッキーなケースもあるだろうけど、
そういう受け入れる側にしても新しいメンバーに予め期待する予備知識は年と共に
どんどん変化するわけで。

知らんことが出てきたら人に教えてもらう一方で裏では恥ずかしいと危機感持って
自分で学んでキャッチアップするぐらいでないと色々大変だと思う。

203 ：デフォルトの名無しさん：2013/08/10(土) 18:20:54.39

俺なら git 知ってるとどや顔してる奴より、git のマニュアル渡したら人に聞きながらでも、それなりに使える奴を選ぶわ。

204 ：デフォルトの名無しさん：2013/08/10(土) 18:22:38.19

どうしてもgitを理解できなくて悔しいんだろうな
有用なプログラムを作れるようなレベルの人はgit程度簡単に使いこなせる

205 ：デフォルトの名無しさん：2013/08/10(土) 18:36:54.97

> どうしてもgitを理解できなくて悔しいんだろうな

誰のことだろう...
仮想敵作って、一人相撲が趣味なのか？

206 ：デフォルトの名無しさん：2013/08/10(土) 18:37:01.42

ドヤ顔していようが素直な顔していようが関係無いけどね。
ドヤ顔していたところで抜けている事柄に関しては必ずボロが出るし。

ただボロが出た後で抜けをどう埋めるかの姿勢の差はでかいと思うけど。
自学するドヤ顔と指示待ち素直、どちらを選ぶ?

207 ：デフォルトの名無しさん：2013/08/10(土) 18:42:06.49

おまえらそんなに他人に教えるのイヤか？ｗ
使い方くらい教えてやれよ、性格悪いな。

208 ：デフォルトの名無しさん：2013/08/10(土) 18:44:10.97

>>197
ありがとうございます！

209 ：デフォルトの名無しさん：2013/08/10(土) 18:45:16.67

ここにいるみなさんはテストケースも書かれてるんでしょうか？

皆さんきっちりしてそう。

210 ：デフォルトの名無しさん：2013/08/10(土) 18:50:04.48

まあ、VCSの知識は運転免許証みたいなものだ。

みんなが車を走らせる公道に出てくる際は必ず持ち合わせるべきもの。
そしてとるのも難しくない、教習所でちゃんと学べば基本的に誰でもとれる。
ただ最近は道交法の改正で分散型という仕組みが出来たので多少混乱はあるらしい。

就職してからの免許証取得も可能だろうけれども出来れば就職前の取得が望ましい。
運転免許証を持っていてもペーパーだと仕事で必要になった時に困るよね。

211 ：デフォルトの名無しさん：2013/08/10(土) 19:11:31.99

VCS の知識ぐらい持ってて当たり前だが、会社によって使ってる VCS 違うんだから、就職前に取得とか言われてもなぁ。

そもそも ClearCase なんて個人じゃ買えないしな (w

212 ：デフォルトの名無しさん：2013/08/10(土) 19:30:17.79

それは就職後にどんな車を仕事用に割り振りられるか解らないから、就職前に免許を取って
適当な車を乗り回すのは無駄だと言う程度には不思議な理屈だなぁ。

応用が利かないので車を乗り換える度にイチから運転方法を覚え直す人ならともかく、普通は
別の車であっても運転経験があれば新しい車もあまり時間をかけずに乗りこなせると思うけど。
仮に仕事の現場で特殊車両に乗る人でも関連作業で普通の車を運転する機会も多いでしょ。

213 ：デフォルトの名無しさん：2013/08/10(土) 19:43:16.28

っていうかバージョン管理ってそんなに難しいか？
いやGitの機能が奥深いのは分かるけど、普通に使うのに十分なレベルなら
自習でも一週間もかからないだろうし、業務なら簡単なチュートリアル
読んで貰うくらいで十分だろ？間違ってる？
知ってるとか知らないって事が、そんなに問題になるとは思えないんだけど

214 ：デフォルトの名無しさん：2013/08/10(土) 19:50:38.32

とかいいながら1ヶ月かかっても使えない>>213なのであった

215 ：デフォルトの名無しさん：2013/08/10(土) 19:55:22.57

>>212
事前に特定の車両の免許を取れと言ってる奴に言ってやれよ

> Gitの類を使った開発に参加する際にGitの使い方を知らなければその人は当面無価値だよね。

>>213
何か嫌なことでもあったんだろ。

216 ：デフォルトの名無しさん：2013/08/10(土) 20:16:17.23

>>215
べつにそれは特定の車両を使っている現場ではその車両を運転できないと無価値だと
言っているだけであって、別にだからその特定の車両の免許を事前に取れと言って
いる訳では無いでしょ。

gitでもhgでもsvnでも、何でも良いから事前にVCSを使った開発経験を持っていれば
仮に他所で他のVCSを使っていても教える方も教わる方も双方共に楽が出来る。

そしてその中から何を選ぶかと問われれば、昔svn今ならgitはリーズナブルな選択
だと思うけれどもね。現場で使う頻度云々もあるけれども、今は公開リポジトリを
利用するのにもこの二つは広く使われるなど応用も広いと思うのだけど。

217 ：デフォルトの名無しさん：2013/08/10(土) 20:31:43.34

バージョン管理システム自体は簡単でもバージョン管理そのものはプロジェクト管理と
関連するから単純な作業じゃないよね。

218 ：デフォルトの名無しさん：2013/08/10(土) 20:48:42.78

>>216
>その特定の車両の免許を事前に取れと言っている訳では無いでしょ。

>> Gitの使い方を知らなければその人は当面無価値だよね。

君は、Git の前に日本語覚えるべき

219 ：デフォルトの名無しさん：2013/08/10(土) 20:58:03.19

>>218
日本語以前の問題で、理屈をちゃんと踏まえる習慣をつけないとプログラミングの
世界では不味いと思うよ。

「無価値だよね」から「特定の車両の免許を取れ」と勝手読みするのに至るまで
いくつの理屈をすっ飛ばしたのかな。

220 ：デフォルトの名無しさん：2013/08/10(土) 20:58:14.56

>>210
例えがうまいな

ただ、自転車で十分！！とかいって道路走って信号無視してる奴が迷惑なんだよ！！w

221 ：デフォルトの名無しさん：2013/08/10(土) 21:06:26.53

>>220
あと基本的な運転技術自体は座学や教習所内の運転コースで学べるのだけれども、実際に
公道で周囲の車の流れにのって運転するには隣に指導員が乗った路上講習や免許取得後に
実際に他の車の集団が走っている中を運転して場数を踏まないことには如何ともし難い
のもどことなく似ている。

222 ：デフォルトの名無しさん：2013/08/10(土) 21:18:37.82

>>196
行ごとにいつ、どうして変更したかわかるようになるよ。
>>198
今まで教えてすぐ使いこなせた奴はいなかったな。やはり習熟が必要。

223 ：デフォルトの名無しさん：2013/08/10(土) 21:25:29.08

>>219
　　　　　　git の知識が無いのは無価値 ⇔ 無免許
　　　　　　　　　↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
特定の VCS (git) について知識を得とけ ⇔ 特定の免許を取っとけ

引っ込みつかなくなっているだけならまだしも、マジでこれぐらいの論理が組み立てられないと、この業界だと辛くないか？ (w

224 ：デフォルトの名無しさん：2013/08/10(土) 21:36:31.82

>>223
横方向のアナロジーは解らないでもないし、一生懸命視覚化しようとした努力は
買うけど。

> git の知識が無いのは無価値 -> 特定の VCS (git) について知識を得とけ

誰も書いていないじゃん。「Gitの類を使った開発に参加する際にGitの使い方を
知らなければ」という自分で引用した仮定すらすっ飛ばしているし。

0点。

225 ：デフォルトの名無しさん：2013/08/10(土) 23:12:38.82

>>224
そんなレスしてて楽しいの？

傍から見ると、可哀想にしか見えないんだけど。

226 ：デフォルトの名無しさん：2013/08/11(日) 13:07:07.13

>>192
> サービスたち上げること考えたら、割と他のVCSの方が使いやすくパッケージングされてるように感じた。

ネット越しでも共有フォルダ使うならなんもいらないし、
httpでもapacheにgit-http-backendのリンクを食わせるだけで
超お手軽だろ?

227 ：デフォルトの名無しさん：2013/08/11(日) 13:52:33.90

Githubのスレが見当たらないんですけど、Githubの質問はスレ違いなんでしょうか。

あるプロジェクトを自分のリポジトリにフォークして、自分のフォークリポジトリに少しずつチマチマとコメントつけてコミットしてるんですが、
それを元のリポジトリに、毎回のコメントごとコミットってできるんでしょうか？

つまり、
コミット "初回"
コミット "2回目。○○を直しました。"
コミット "3回目。■■を直しました。"

とフォークしたリポジトリにコミットしたのを元のリポジトリに

コミット　"フォークからのコミットです"

とまとめてコミットではなくて

コミット "フォークからのコミットです。初回"
コミット "フォークからのコミットです。2回目。○○を直しました。"
コミット "フォークからのコミットです。3回目。■■を直しました。"

としたいんですが

228 ：デフォルトの名無しさん：2013/08/11(日) 14:19:53.81

Githubの質問じゃないし

229 ：デフォルトの名無しさん：2013/08/11(日) 18:34:45.74

gitって有料ばかりだけど皆有料プラン使ってるの？
フリーでコードを公開ってのもあれだけど、有料プランの出費もいたいなぁ。

230 ：デフォルトの名無しさん：2013/08/11(日) 18:42:30.22

>>229
gitは基本無料ですよ

231 ：デフォルトの名無しさん：2013/08/11(日) 18:44:05.49

>>230
ありがとうございます。
無料だとコードを晒さないといけませんよね？
俺の作ったコードなんて誰も触らないでしょうけど。

232 ：デフォルトの名無しさん：2013/08/11(日) 18:54:29.80

俺もコード晒さずにただで使ってるよ。git。

233 ：デフォルトの名無しさん：2013/08/11(日) 18:54:33.62

>>231
まず、git とgithubは異なるものね
で、github について言えば、無料なら晒さなければならないのはその通り
それが嫌なのであれば、git+dropbox とか、bitbucket とか代替案はいろいろとあるよ

234 ：デフォルトの名無しさん：2013/08/11(日) 18:54:39.61

gitとgithubを勘違いしてないか

235 ：デフォルトの名無しさん：2013/08/11(日) 19:50:38.30

232,233,234
ありがとうございます。
同じものだと思ってました。
ググってみます！

236 ：デフォルトの名無しさん：2013/08/12(月) 15:18:35.50

>どうだろう、例えば独学で凄い3Dグラフィックエンジン作ってた様な人が
>仮にバージョン管理システムの存在をこれまで知らなかったとしても
>いくらもその人の価値を落とすようなことは無いと思うんだよね

言ってることは理解出来るが
一緒に仕事したくないタイプ

237 ：デフォルトの名無しさん：2013/08/12(月) 15:26:32.95

>>236
俺は、お前を排除するね

238 ：デフォルトの名無しさん：2013/08/12(月) 15:36:49.05

>>237
俺は、おまえを虐めるね

239 ：デフォルトの名無しさん：2013/08/12(月) 16:04:22.86

>>238
もっと～もっと～

240 ：デフォルトの名無しさん：2013/08/12(月) 18:16:27.78

どうぞどうぞ

241 ：デフォルトの名無しさん：2013/08/13(火) 14:48:19.68

lolcommitsって真面目に使っている人っているのかなw
http://mroth.github.io/lolcommits/

242 ：デフォルトの名無しさん：2013/08/13(火) 16:10:38.58

lolcommits
約 3,370 件（0.23 秒）

使ってないでいいんじゃね？
わざわざこれがなにか調べる気も
しないけど

243 ：デフォルトの名無しさん：2013/08/18(日) 18:45:56.41

せっかく来たのに
まだ決定打的なGUI出来てないの
また明日こよ

244 ：デフォルトの名無しさん：2013/08/19(月) 08:43:57.48

>>243
頑張ってください！
応援してます！

245 ：デフォルトの名無しさん：2013/08/20(火) 23:21:27.01

永遠に明日を待ち続けるのであった

246 ：デフォルトの名無しさん：2013/08/29(木) 14:01:24.88

無いなら俺が作ると考えない奴に明日はかおない

247 ：デフォルトの名無しさん：2013/08/29(木) 14:29:39.89

かおないパワー！

248 ：デフォルトの名無しさん：2013/08/29(木) 15:07:24.36

gitconfigでaliasに
log = log --date～
みたいな感じで書いたんですが
デフォルトのlogで表示されます

l = log --date～
って書くと反映されました

aliasでlogが反映されないのはなぜですか？

249 ：デフォルトの名無しさん：2013/08/29(木) 15:28:48.95

>>248
仕様です
> To avoid confusion and troubles with script usage, aliases that hide existing Git commands are ignored.

250 ：デフォルトの名無しさん：2013/08/29(木) 15:40:14.20

そうだったんですか！
わかりました！

251 ：デフォルトの名無しさん：2013/08/30(金) 09:48:10.09

間違えてIDとパスワードを含んだコードを間違えてあげてしまったので、
至急ローカルでコードからIDとパスワードを削除して
git add -A
git commit -m "IDとパスワードを消した"
git push origin master
ってしたんですが
githubの履歴にはIDとパスワードが入ってるコードが閲覧できてしまいますよね
こういう場合はどうしたらいいでしょうか？

やり方がわからずリポジトリごと消してるので一応被害はありません

252 ：デフォルトの名無しさん：2013/08/30(金) 10:32:59.71

testブランチを切り替えるのを忘れてしまい、masterブランチでコードを編集してしまったのですが
この場合、.
編集したファイルを別のディレクトリにバックアップ
↓
git checkout -fで元に戻す
↓
git checkout -b testでtestブランチに切り替える
↓
バックアップしたファイルで元のファイルを上書き
という流れで解決はしたのですが、ものすごい面倒くさいです

以下の3つの状態それぞれのケースでもっとよい方法がございましたらどうか伝授してください
１．git addする前
２．git addした後
３．git commitした後

253 ：デフォルトの名無しさん：2013/08/30(金) 11:23:12.44

commit --amend
push --force

254 ：デフォルトの名無しさん：2013/08/30(金) 11:31:53.37

commit 前なら git stash save; git checkout xxx; git stash pop で大体おｋ。
commit してしまったら git reset HEAD^ でひとつ戻ってから同様にやればいい・・・と思う。たぶん。きっと。おそらく。

255 ：デフォルトの名無しさん：2013/08/30(金) 11:33:30.87

1.2. stash -> checkout test -> stash pop

256 ：デフォルトの名無しさん：2013/08/30(金) 18:46:58.21

githubで自分のリポジトリでpull requestを送る練習をしてるんですが
branchはmasterじゃないほうがいいということなんですが
branch名は他の人とかぶらない様なネーミングをつけておいたほうがいいですか？
もし他の人とbranch名がかぶったらコンフリクトになっちゃいますよね？

257 ：デフォルトの名無しさん：2013/08/30(金) 19:13:56.07

ブランチ名はリポジトリローカルなので、被ってもOK
自分のリモートとローカルでも別の名前使えるよ
ただ自動で生成されるコミットメッセージに出てきて紛らわしいので、意味のある名前が推奨されてる

258 ：デフォルトの名無しさん：2013/08/30(金) 19:23:36.18

>>256
自分のリポジトリにpushして自分にpull requestするならブランチ名は重なってちゃまずいと思うけど
forkしたリポジトリにpushしてオリジナルのリポジトリにpull requestするなら、
ブランチ名の重複は考えなくていいんじゃないの？

259 ：251：2013/08/30(金) 21:09:59.03

>>253
>>254
>>255
これのうちぼくへの暖かい回答はどれですか

260 ：デフォルトの名無しさん：2013/08/30(金) 21:20:11.19

自分で判断したまえ

261 ：デフォルトの名無しさん：2013/08/30(金) 21:23:28.30

まあ、問題のない世代からブランチを作り直してmasterを別のものにするしかないと思う。
編集履歴なくってしまったら、バージョン管理にならなしね。
pullしている人には事前の連絡を忘れずに

262 ：デフォルトの名無しさん：2013/08/30(金) 22:52:30.71

おいおい。消す方法あるぞ。ちょっと待ってろ。

263 ：デフォルトの名無しさん：2013/08/30(金) 22:55:25.71

stashという便利なコマンドがあるんですね！勉強になりました

264 ：デフォルトの名無しさん：2013/08/30(金) 22:58:51.64

>>251

Gitポケットリファレンス
http://www.amazon.co.jp/dp/477415184X

の71ページに書いてある。
まさにコミットしてはいけないパスワードファイルをコミット
してしまった場合の対応。

git filter-branchコマンドを利用するらしい。
更にその後reflogも消すためにgit gcを行う。

細かいやり方は書くだけでも面倒くさいので
本を見るか、ぐぐってくれ。

265 ：デフォルトの名無しさん：2013/08/31(土) 00:02:30.00

>>251
こういうのってどうやって管理するのがいいの？
gitでコミットするファイル内では別ファイルを読み込む形にして、その別ファイルは.gitignoreに追加するのとかいいかなと思うんやけど。。
oauthライブラリ作ってて同じことやったことある

266 ：デフォルトの名無しさん：2013/08/31(土) 00:40:02.10

>>262
これかぁ。
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

知らなかったや。
結果的には、同じになりそうだけれど、filter-btanchだと、他のブランチにも影響してくれるみたいだね。

>>265
本物のデータファイルを管理下に配置するのが間違いだと思う。
あと、個人的には、addのとき手抜きしないとかかなぁ
GUIだと難しそうだけど。。。。

#久しぶりに規制とれたさて、いつまで持つやら

267 ：デフォルトの名無しさん：2013/08/31(土) 00:46:11.13

password.yml はリポジトリに入れない。
間違ってコミットしないように、.gitignoreに指定しておく。
代わりにpassword.yml.sample をリポジトリに入れる。

268 ：デフォルトの名無しさん：2013/08/31(土) 10:02:15.89

>>264
宣伝成功！！！！！

269 ：デフォルトの名無しさん：2013/08/31(土) 12:10:38.34

コミットをするタイミングがわかりません
やっぱり仕事でやるならコミットもきれいにしないといけないのでしょうか？
ちょっと更新したらコミットとかやめるべきですか？

270 ：デフォルトの名無しさん：2013/08/31(土) 13:02:43.46

>>269
細かい更新でコミットするのは問題ない
むしろやった方がいい。

コミットは単なるファイルセーブじゃないんで、
コミット＝アプリが正しく動く状態にしないといけない。

でかい機能追加であっても、正しく動く状態を保ちつつ
小さい修正を繰り返して開発できるはず。
その小さい修正ごとにコミットする。

リモートリポジトリに送信しない限り
歴史は自由に書き換え可能なのだから
最終的にバグやミスがないコミットの連続になる。

これを開発用のブランチで行う。
最終的にmasterにマージするときに
一つのコミットにまとめるかどうかは方針次第。

271 ：デフォルトの名無しさん：2013/08/31(土) 13:14:28.25

俺は動かない状態でも一時的な作業用のブランチ作ってコミットするのはよくやる (workとか、それとわかりやすい名前がいい)
動く状態になったらちゃんとしたブランチに merge --squash して作業ブランチ削除、みたいな感じ

272 ：デフォルトの名無しさん：2013/08/31(土) 13:21:11.32

履歴に残さない一時的なコミットなら
どうでもいいよ。

273 ：デフォルトの名無しさん：2013/08/31(土) 13:27:27.17

全プッシュ！
全プッシュ！

274 ：デフォルトの名無しさん：2013/08/31(土) 15:29:04.99

へ？git push 以外になんか引数必要だっけ？へ？

275 ：デフォルトの名無しさん：2013/08/31(土) 15:29:46.59

git push するときに　up streamだかなんかってエラーがでたんですけど
どういうことかわかりません

276 ：デフォルトの名無しさん：2013/08/31(土) 15:34:55.79

>>275
たぶん、現在のブランチがリモートブランチと紐づいてなくて、どこにプッシュすればいいのかわからんのです
git push origin master
みたいに指定すればプッシュできませんか？

277 ：デフォルトの名無しさん：2013/08/31(土) 15:35:35.63

たぶんそれかもしれません
やってみます

278 ：デフォルトの名無しさん：2013/09/03(火) 21:06:55.92

githubで複数のpull requestをtestブランチで送られてきた場合どうすればいいんですか！？
そのままマージボタンを1個ずつおしちゃっていいのですか！？コンフリクトしますよね？
それともひとつローカルに映して手作業でコミットとプッシュを繰り返すのでしょうか！？

これが怖くてpull request全部無視

279 ：デフォルトの名無しさん：2013/09/03(火) 21:31:38.54

先着順にマージして、コンフリクトするようなら
送り主にそっちでrebaseし直してくださいやがれって言えばいい

280 ：デフォルトの名無しさん：2013/09/03(火) 22:10:32.92

どんな状況であれローカルでpull・mergeすれば結果はいかようにでもできるはずだが

281 ：デフォルトの名無しさん：2013/09/05(木) 00:18:19.85

GitHubで非公開リポジトリを作った場合に
その中に作られるWikiも非公開になるんでしょうか？

282 ：デフォルトの名無しさん：2013/09/08(日) 02:46:33.90

.git のあるディレクトリごとzipで圧縮したファイルを
電子メールでやりとりすれば
githubいらないな

283 ：デフォルトの名無しさん：2013/09/08(日) 03:58:07.60

.git のあるディレクトリごとzipで圧縮したファイルを
電子メールでやりとりのが大変すぎるから
github必要だな

284 ：デフォルトの名無しさん：2013/09/08(日) 09:49:38.39

.gitで管理しているディレクトリがＡ君とＢ君で違うとダメなきがするんですけど

285 ：デフォルトの名無しさん：2013/09/08(日) 10:11:36.86

そもそも分散リポジトリの意味がないきがするんですけど

286 ：デフォルトの名無しさん：2013/09/08(日) 12:09:28.04

A君とB君はそれぞれローカルリポジトリを持ってそこで作業する

修正を相手に送りたいときはローカルリポジトリのコピーをメールで送る

メールで送られてきたリポジトリは自分のローカルリポジトリとは別の
場所に展開して、そのリポジトリからpullして相手のコミットを取り込む

これならおｋ？

287 ：デフォルトの名無しさん：2013/09/08(日) 12:11:00.91

なぜパッチセットでもバンドルでもなくリポジトリ全部を送るのよ

288 ：デフォルトの名無しさん：2013/09/08(日) 12:28:36.07

リポジトリ全部を送る話をしてるからだよｗくうきよめｗ

289 ：デフォルトの名無しさん：2013/09/08(日) 12:51:31.46

作業中のファイルがあるディレクトリを丸ごとzipで圧縮して
外付けHDDかなんかに貯めていけば
gitもいらないな

290 ：デフォルトの名無しさん：2013/09/08(日) 12:53:02.34

>>286
俺が前にこのすれで質問したことあるけど
リポジトリを別のフォルダに移動したいとき、そのまま移動したらおかしくなったよ
だからむり

291 ：デフォルトの名無しさん：2013/09/08(日) 12:55:51.27

>>286みたいなアホな使い方でもGitの効果は絶大だぞ
作業ディレクトリを丸ごとZipで溜めていくなんかとは全然違う

292 ：デフォルトの名無しさん：2013/09/08(日) 12:57:33.04

GitってPythonでできてるんですよね
何でPythonインストールしてないのに動くんでしょうか？

293 ：デフォルトの名無しさん：2013/09/08(日) 13:02:42.59

>>290
普通にできる。前スレ670でリポジトリの移動がうまくいかないとか言ってたやつか？
お前のやり方がマズイだけという結論になっただろ。

294 ：デフォルトの名無しさん：2013/09/08(日) 13:03:07.03

>>292
どこソースよ

295 ：デフォルトの名無しさん：2013/09/08(日) 13:03:22.30

>>292
GitはC言語。一部Perlとかのスクリプトも使ってるけど。

296 ：デフォルトの名無しさん：2013/09/08(日) 13:16:26.38

>>282
git自体に差分をメールにする機能があるのに。
あと圧縮は本質でなくて、アーカイブな。
あと.git以下か、bearだけていいだろ。

297 ：デフォルトの名無しさん：2013/09/08(日) 17:09:42.99

git daemon立ち上げるという選択肢はどうですか

298 ：デフォルトの名無しさん：2013/09/08(日) 18:09:19.54

>>289
それはただの簡易バックアップ、バージョン管理じゃない。

299 ：デフォルトの名無しさん：2013/09/08(日) 21:34:25.40

>>296
クマー

300 ：デフォルトの名無しさん：2013/09/08(日) 21:35:37.82

>>292
Mercurialと間違えてるだろ

301 ：デフォルトの名無しさん：2013/09/09(月) 11:40:51.66

gitの使い方覚えるつもりない人とgit使うためには
ディレクトリまるごとコピーして
>>282
みたいにすればいい

302 ：デフォルトの名無しさん：2013/09/09(月) 11:44:11.39

githubに公開する部分と
公開できない部分を

非公開フォルダー/公開フォルダー

みたいに分割すると落だけど
間違って非公開のを公開してしまいそうで

非公開フォルダー

かなり違う場所/公開フォルダー

にしてる

303 ：デフォルトの名無しさん：2013/09/09(月) 21:32:38.01

SVNほのうが簡単、わかりやすい

304 ：デフォルトの名無しさん：2013/09/10(火) 02:03:53.65

svnでgitと同じように運用しようとすると難しすぎる。使いこなすとsvnには戻れない。

305 ：デフォルトの名無しさん：2013/09/11(水) 10:01:01.01

>>303
SVNが分かりやすいと言ってSVNを使い続けるのもアリだけど、最終的にはGitがSVNよりも優れていることに気付いて「何でもっと早くGitを理解しなかったんだろう」と後悔することになる…かもしれない。

こういう違いがあるんだくらいはGitの事、分かってあげてほしいな。

306 ：デフォルトの名無しさん：2013/09/11(水) 10:51:34.49

優れているかどうかなんて、使い方次第じゃね？
Gitなりの使い方しないなら意味ないし。

307 ：デフォルトの名無しさん：2013/09/11(水) 10:56:06.33

git-svnで満足

308 ：デフォルトの名無しさん：2013/09/11(水) 11:31:02.67

うむ。結局の所、両方知ってない奴はカス。

309 ：デフォルトの名無しさん：2013/09/11(水) 12:40:01.53

>>305
gitは分散型というのが最大の長所だけど
運用形態によっては最大の短所になり得る

310 ：デフォルトの名無しさん：2013/09/11(水) 13:46:09.75

>>306
具体的には？

311 ：デフォルトの名無しさん：2013/09/11(水) 13:46:54.51

>>306 -> >>309

312 ：デフォルトの名無しさん：2013/09/11(水) 15:33:11.25

>>309
分散型であることが短所になるって具体的にはどういう場合にどういう所がそうなるの?

313 ：デフォルトの名無しさん：2013/09/11(水) 16:51:27.93

>>310,312
横レスだけど、コミット権の制御ができなくてpushのときにrejectするしかないってのが一つ思いついた

314 ：デフォルトの名無しさん：2013/09/11(水) 17:33:12.78

分散型の最大の欠点は、ユーザーアクセス権限の制御が不能なところ。
誰でも触れるし、ロックも出来ない。

だから今は複数のツールを同時に使っていくしかない。

315 ：デフォルトの名無しさん：2013/09/11(水) 18:03:48.99

githubとか使ったことない人なのかな…

316 ：デフォルトの名無しさん：2013/09/11(水) 19:48:10.66

共有型の最大の欠点はロック出来ない事じゃね？
いわゆるオフィス系ドキュメントを分散型で共有管理しようとすると、先祖帰り問題が発生してしまう可能性が高い

317 ：デフォルトの名無しさん：2013/09/11(水) 19:49:01.78

×共有型
○分散型

318 ：デフォルトの名無しさん：2013/09/11(水) 20:26:04.76

分散型とかどうでもいいよ。

gitの利点はそういうところじゃない。
コミット忘れを修正することが出来るのがメリットだ。

もちろんコミット忘れだけじゃない。
あの時ああいう順番で修正すればよかったとか
コミットしてしまった後で後悔することの多くをgitなら直すことが可能。

319 ：デフォルトの名無しさん：2013/09/11(水) 21:05:39.78

オフィスのドキュメントのよーなバイナリ形式で扱うのが間違い
マークダウン記法みたいなテキスト形式の記法を使えばマージできるからロックとか要らないでしょ

320 ：デフォルトの名無しさん：2013/09/11(水) 21:20:47.75

http://the-gay-bar.com/2010/06/23/managing-zip-based-file-formats-in-git/

321 ：デフォルトの名無しさん：2013/09/11(水) 21:25:44.23

リポジトリに大量にデータが追加されてて、全部ダウンロードすると時間かかるので
特定のディレクトリに入ってるファイルとディレクトリだけ取得したいんですがいい方法ないですか？
sparsecheckoutはＮＧです

322 ：デフォルトの名無しさん：2013/09/11(水) 21:32:36.70

>>320
MS-OFFICEファイルのdiffだけだったら、TortoiseのDiff-Scriptsでも使えば
綺麗に表示できるよ。

マージができない大欠点はどうにもならないけど。

323 ：デフォルトの名無しさん：2013/09/11(水) 21:59:40.08

>>321
特定のディレクトリを指定して clone するのは無理だと思うが
特定のブランチだけをフェッチする操作ならできる。

324 ：デフォルトの名無しさん：2013/09/11(水) 22:14:28.71

>>320のはコメントを読んだ方がいいよ
いや別に何もよくはならないけど

325 ：デフォルトの名無しさん：2013/09/11(水) 22:21:36.31

>>319
> オフィスのドキュメントのよーなバイナリ形式で扱うのが間違い

働いたことないんだろうな...

326 ：デフォルトの名無しさん：2013/09/11(水) 23:04:40.89

文章はTeXにしている俺に死角は無かった

327 ：デフォルトの名無しさん：2013/09/11(水) 23:32:45.56

オープンソースプロジェクトでdocとかodtそのまま突っ込んでいるのは見た事ないぜ

328 ：デフォルトの名無しさん：2013/09/11(水) 23:44:04.11

それ以上にTeX突っ込んでいるの見た事ないぜ

329 ：デフォルトの名無しさん：2013/09/11(水) 23:44:50.09

時代はmd

330 ：デフォルトの名無しさん：2013/09/12(木) 01:27:09.68

>>321
cvsを使う。

331 ：デフォルトの名無しさん：2013/09/12(木) 01:55:33.54

>>318
＞コミットしてしまった後で後悔することの多くをgitなら直すことが可能
そこは利点ではなく欠点だろう。

332 ：デフォルトの名無しさん：2013/09/12(木) 01:58:51.25

>>331
何が欠点なの？

お前はミスをしないというのか？
変なことを言うやつだな。

なぜgitが歴史を変更できる手段を持っているのか
その理由を考えたことはあるのか？

333 ：デフォルトの名無しさん：2013/09/12(木) 02:16:01.50

>>332
そういうのを手元でやってるうちはいいけどな
ローカルと同じ感覚でやられると非常に迷惑

334 ：デフォルトの名無しさん：2013/09/12(木) 03:51:13.42

パスワードを書いたファイルをコミットしちゃった、、とかかｗ

335 ：デフォルトの名無しさん：2013/09/12(木) 07:05:56.17

>>333
こういうやり取り見てると、まだ SVN でいいや...
と、思う。

336 ：デフォルトの名無しさん：2013/09/12(木) 07:55:06.28

>>333
ローカルとリモートの区別があるから、
そういうことをローカルに手元でできるのがいいんじゃない

337 ：デフォルトの名無しさん：2013/09/12(木) 08:38:16.74

>>307
git-svnの運用は諦めた

338 ：デフォルトの名無しさん：2013/09/12(木) 10:12:33.52

>>336
普通に考えて、push済みのcommitに対してやらかしてはまるバカがいるってことでしょ。
そういう奴は、なんでやっちゃダメなのか理解できてないんだろうし。

339 ：デフォルトの名無しさん：2013/09/12(木) 11:14:10.39

push済みのコミットを上書きさせないようにすることもできるし、
push自体をできなくしてpull request使うとかすればいい

340 ：デフォルトの名無しさん：2013/09/12(木) 11:17:23.02

githubからパスワードが書かれたファイルを履歴を含めて完全に抹消する方法を至急おしえてｋづあしあ！
急いでます

341 ：デフォルトの名無しさん：2013/09/12(木) 11:21:15.95

首吊れば完全末梢できるよ

342 ：デフォルトの名無しさん：2013/09/12(木) 11:22:15.24

>>340
Githubに上げたパスワード削除
でググレ

343 ：デフォルトの名無しさん：2013/09/12(木) 11:25:13.18

gitを使う上で起こりうるトラブルを全部おしえて

344 ：デフォルトの名無しさん：2013/09/12(木) 11:26:44.94

>>343
gitを使う上で起こりうるトラブル
でググレ

345 ：デフォルトの名無しさん：2013/09/12(木) 11:52:09.75

>>316
ロックさせたければ VSS をつかえって感じだが、
それはともかく、ロックしたければ subversion だと svn lock があるが、
git にはそういうのないんだっけ？

346 ：デフォルトの名無しさん：2013/09/12(木) 12:14:48.47

http://localhost/ripojitori/daikibo/site/library/内のファイルを5人で作業します
A君はdatabase.phpを作業して
B君はview.phpとlang.phpを作業して
他の人は別のファイルを作業します

んで、A君はチーム作業を無視してview.phpを勝手に編集してプッシュしちゃう可能性があります
こういう場面はどうやって作業するんでしょうか？

347 ：デフォルトの名無しさん：2013/09/12(木) 12:29:23.41

誰か一人がpushするようにする
ほかの人はその人にpullリクエストを送ってマージしてもらう

348 ：デフォルトの名無しさん：2013/09/12(木) 12:30:07.64

>>346
A君はdatabase.phpを編集するといっても自分の好きにデタラメ編集してもいいってわけじゃないだろ？
バグを作りこめは当然修正する必要がある
A君が自分のdatabase.phpにバグを作りこむのも、自分の担当じゃないview.phpを編集してしまうのも、一緒だろ？
履歴が残るんだからもしA君がview.phpを編集したコミットがあったら、それをrevertさせればいい

349 ：デフォルトの名無しさん：2013/09/12(木) 12:30:18.88

>>345
ない。

350 ：デフォルトの名無しさん：2013/09/12(木) 12:33:31.00

Gitにファイルロックとか追加されても激しく面倒というかまともに機能しないだろうから
どうしても必要な奴らはプロジェクト管理ツールのレベルでそういう機能を用意すればいいだろう

351 ：デフォルトの名無しさん：2013/09/12(木) 12:37:57.51

>>345
分散型の思想に反する機能なので無理

352 ：デフォルトの名無しさん：2013/09/12(木) 13:09:45.36

分散型の思想とかそんな高尚な観点から来てるわけじゃなく、author管理と
リポジトリのアクセス権限管理を別にしてしまってるところからして無理。

353 ：デフォルトの名無しさん：2013/09/12(木) 18:03:53.50

>>340
履歴上のファイル削除ならフィルタ掛けて一括削除みたいば事で出来るって本に書いてあったな。

354 ：デフォルトの名無しさん：2013/09/12(木) 18:42:32.66

Mercurialにはクライアント側でファイルアクセスを禁止する
ロックの拡張機能があったけど
使い物になるのかどうか

355 ：デフォルトの名無しさん：2013/09/12(木) 20:36:42.01

>>351 が正解
どんなにロックしても、gitに慣れた者ならばローカルにcloneしてpushする瞬間だけロックを取得するような使い方をするようになるだろうから意味ない。
例えばVSSの場合だったら、ロック中のファイルを編集するために別のフォルダに退避して、ロックが外れた時に上書き保存するようになる。
バージョン管理が不慣れな者にとってはロック方式が馴染みやすいかもしれないけど、そういう者はgitは使えないから関係ないし。

356 ：デフォルトの名無しさん：2013/09/12(木) 20:52:37.22

>>333
> そういうのを手元でやってるうちはいいけどな
> ローカルと同じ感覚でやられると非常に迷惑

履歴の修正っていうのは、ローカルでやる作業なんだけど、
ローカルと同じ感覚でやられると迷惑ってどういうこと？

レスの内容によっては、お前が使い方わかってないだけじゃんってことになりそうだが。

357 ：デフォルトの名無しさん：2013/09/12(木) 20:56:09.73

間違った使い方をする奴は迷惑。
それって何使っても当てはまるだろう。

subversionを1ファイルずつコミットする奴は迷惑。
ほらなｗ

間違った使い方をするのは、そいつが迷惑という話であって、
gitの問題ではない。

358 ：デフォルトの名無しさん：2013/09/12(木) 21:09:16.44

>>355
> 例えばVSSの場合だったら、ロック中のファイルを編集するために別のフォルダに退避して、ロックが外れた時に上書き保存するようになる。

ならねーよ。

359 ：デフォルトの名無しさん：2013/09/12(木) 21:18:19.14

add してcommitしたあとにpushするじゃないですか
pushする前に他の人が先にpushするかもしれないのでfetch & mergeしてからpushしたほうがいいのでしょうか？

360 ：デフォルトの名無しさん：2013/09/12(木) 21:25:25.46

>>359
fetch? pullじゃなくて？

361 ：デフォルトの名無しさん：2013/09/12(木) 21:28:16.00

pullしちゃいけなくてfetch & mergeがいいって記事みたんです

362 ：デフォルトの名無しさん：2013/09/12(木) 22:35:46.28

>>357
svnを使い慣れた人間にgitを使わせる場合には、gitとしての使い方を教育せずに
gitを使わせるような奴はそいつが悪いってことになる。

363 ：デフォルトの名無しさん：2013/09/12(木) 22:50:22.66

>>337
何で?
自分は満足なんだけど、誰も使ってないみたいだから大きな穴があるんじゃ
無いかと気になってる。

364 ：デフォルトの名無しさん：2013/09/12(木) 23:00:32.67

>>337じゃないけど、git-svnを使うと結局svnから逃れられなくなる。

それは単純にsvnだけ、gitだけを使うよりも難しい作業を強いられることになる。

gitのノウハウにもgit-svnを使った例は少ない。

github及び、githubクローンであるgitlabを使うときどうするのかよくわからない。

何をするにも、gitだけだとこうやるけど、そこにgit-svnがくると・・・などという話が
いつまでも付きまとってくる。

穴があるというよりも大変。

365 ：デフォルトの名無しさん：2013/09/12(木) 23:05:01.67

>>363
自分も使ってるけど、今のところ運用で詰んだことはないな。

366 ：デフォルトの名無しさん：2013/09/12(木) 23:09:50.78

>>365
開発では？

gitの特色である開発中にいくつもブランチ作って
幾つものブランチを切り替えて
歴史を修正しながら、小さな修正で
開発するってことが普通に出来るの？

367 ：デフォルトの名無しさん：2013/09/12(木) 23:15:25.90

>>355
cvsとかsvnでもupdateしてからcommitするようにすればロックなんて機能は必要ない。

gitの場合、pushをcommit、pullをupdateに置き換えてかんがえれば、svnからの移行もしやすいんじゃないかな。
gitはあくまで、ローカル作業がより便利になっただけだよ。

368 ：デフォルトの名無しさん：2013/09/12(木) 23:22:43.70

> gitはあくまで、ローカル作業がより便利になっただけだよ。
そうなんだよな。

ソースコードはサーバーで一元管理するもの。
逆に言えば、ローカルにあるものはソースコードの管理というよりも
開発そのもの。だからgitは開発がより便利になる。

ステージングとかいいよ。

開発してる時に、小さなミスを見つけて、それだけコミットしたいと思うだろう？
gitなら、git addでファイルの ”一部分” だけをステージング（ようはコミット予定リスト）し
あちこち修正途中のファイルがあったとしても、簡単にファイルの一部分だけをコミットすることができる。

svnだったら開発中によくある面倒なことを
gitであれば楽にこなしてしまう。

369 ：デフォルトの名無しさん：2013/09/13(金) 00:00:07.94

svnだエラーの出る状態でコミットするなとか言い出す人が多かったな。
エラーの出る状態から作り直して失敗したらどうするんだ。
svnでもブランチとか適切に運用できていればいいんだろうけど。

370 ：デフォルトの名無しさん：2013/09/13(金) 00:18:00.21

>>369
gitでもエラーの出る状態で入れないでよ

371 ：デフォルトの名無しさん：2013/09/13(金) 00:19:09.17

ローカルで正しく直してからプッシュするというのなら
エラーが出る状態でもいいかな。

372 ：デフォルトの名無しさん：2013/09/13(金) 00:34:16.73

エラーが出る出ない以前に
作業途中でコミットするのが納得できんな

単に途中経過を保存したいならstashがあるし
途中経過を他の人に見てもらいたいならMLや掲示板とかの方がいいだろう

373 ：デフォルトの名無しさん：2013/09/13(金) 00:39:20.59

>>372
stashはpopという引数があることからもわかるように
スタックという考え方が基礎になってるんだ。

作業途中の割り込み、の割り込み、の割り込み
といった用途で使うもの。

作業途中のコミットは、
いくつかの作業を並行して行っている場合に使う。

Aという作業をやっている途中で、
Bという作業をやってさらに
Cという作業に移ってAという作業に戻る。
と思ったら、Cという作業を進めなくてはならなくて
次はBみたいな。

374 ：デフォルトの名無しさん：2013/09/13(金) 00:54:59.34

stashはpullとかmergeする際の本当に一時的な退避にしか使わない
時間が経つとstashしておいた事実を(俺が)忘れてしまう
作業が割り込む場合は作業ブランチ切ってコミットしてる

375 ：デフォルトの名無しさん：2013/09/13(金) 00:59:35.14

>>367
それはロックの本質をわかってない

376 ：デフォルトの名無しさん：2013/09/13(金) 01:16:04.64

>>372
あとでそのエラーになった修正を使いたくなるかも知れないじゃないか。
それにチケットと関連付ける時にソースもあった方がわかりやすい。
公なとこにpushするなら、その前にまとめればいいだけだし。人のローカルリポジトリに口出しするとか、わけわからんわ。

377 ：デフォルトの名無しさん：2013/09/13(金) 01:16:57.33

mercurialがいろいろ縛った理由をちょっと理解できた気がする

378 ：デフォルトの名無しさん：2013/09/13(金) 01:24:20.08

> 人のローカルリポジトリに口出しするとか、わけわからんわ。
っ鏡

379 ：デフォルトの名無しさん：2013/09/13(金) 07:30:06.93

まあ言ってることが自己矛盾してるわな

380 ：デフォルトの名無しさん：2013/09/13(金) 08:58:47.04

作業途中でコミットできるのがgitのいいところじゃないか。
手元でずいぶん変更したけどまだビルド通らない/テスト通らない/バグが直りきってないときにコミット我慢するの？
途中まで実装したけどやってみると案外うまくいかないな。もう一つの案をで実装してみるか、ってときにその瞬間のコードをコミットしないの？

381 ：380：2013/09/13(金) 09:15:18.83

作業状態の保存(commit)と成果物の公開(push)を分離したところがgitの改善点だろ。
svnと同じタイミング・粒度でしかコミットしないという使い方も否定されないとしても、厳しすぎる制約を自ら課しているんだというのは認識しといた方がいいよ

382 ：デフォルトの名無しさん：2013/09/13(金) 09:20:31.22

もう一つの案を実装してみるときはブランチを切る
作業途中ならstashで保存する

これがベストな方法とは言わないし
他人のローカルリポジトリに口出しする気もないが
少なくとも作業途中でコミットする必然性はない

383 ：380：2013/09/13(金) 09:24:23.05

ブランチ切るのにコミットしないんだ。ふーん

384 ：デフォルトの名無しさん：2013/09/13(金) 09:24:56.57

svnでもいただろ。「また完成してない」とか言って何週間もコミットしない奴が。
手元に巨大な変更を抱えてて作業コピーの日付バックアップを一生懸命とってるの

385 ：デフォルトの名無しさん：2013/09/13(金) 09:29:58.54

testブランチでコード書いた後は
git checkout master
git merge test
git add -A
git commit -m "ちょめちょめ"
git push

この流れで合ってますか？

386 ：デフォルトの名無しさん：2013/09/13(金) 09:55:25.36

>>384
Gitでは「まだ完成してない」とか言ってpushしない奴ということになるわけですね

387 ：デフォルトの名無しさん：2013/09/13(金) 09:57:59.86

まああれだ。
自由ってのは便利だが、一定のルールで遵守させなければならないと。

388 ：デフォルトの名無しさん：2013/09/13(金) 10:07:57.29

>>385
git add -A は何をやってるの？

389 ：デフォルトの名無しさん：2013/09/13(金) 10:21:23.57

>>386
gitでも「まだ完成してない」と言ってコミットしないよ。きっと。
という今の流れ。

gitはそれこそstashみたいな、コミットしない自由も考慮されてるとは思うけど程度問題だな。
無闇にコミットを避けることはない

390 ：デフォルトの名無しさん：2013/09/13(金) 10:22:55.14

>>388
あれなんですよ
git add .
ってやると、なんかたまにgit add -A使えってメッセージが出るのです

391 ：デフォルトの名無しさん：2013/09/13(金) 10:28:03.32

>>390
git add . は何のためにするの？

＞testブランチでコード書いた後
これはtestブランチで書いたコードをtestブランチへコミット済みって意味？

392 ：デフォルトの名無しさん：2013/09/13(金) 10:28:38.23

>>367
> cvsとかsvnでもupdateしてからcommitするようにすればロックなんて機能は必要ない。

アホすぎ (w
チームにこんな奴いたら大変だろうな

393 ：デフォルトの名無しさん：2013/09/13(金) 10:29:15.20

いえ、ちがいます
masterブランチに移ってからaddします

394 ：デフォルトの名無しさん：2013/09/13(金) 10:33:52.76

>>393
何のためにtestブランチを作ったの？

395 ：デフォルトの名無しさん：2013/09/13(金) 10:40:32.81

merge だけでコミットされる (衝突がなければ) からその後の add と commit は無駄じゃね

396 ：デフォルトの名無しさん：2013/09/13(金) 11:03:05.11

ソースの頭にインクリメンタルなソースバージョンつけたいんだけど
gitってそういう思想じゃないから無理だよね・・・
どうしようかな

397 ：デフォルトの名無しさん：2013/09/13(金) 11:14:25.46

そんな時にセマンティックバージョニングとかいいんじゃね？

398 ：デフォルトの名無しさん：2013/09/13(金) 12:32:33.83

なんかすごい伸びてるな…

>>366
できるよ。自分だけだけど。

399 ：デフォルトの名無しさん：2013/09/13(金) 12:50:29.91

testブランチにコミットしていって、
ファイナルちょめちょめの後でmasterへマージ

400 ：デフォルトの名無しさん：2013/09/13(金) 13:14:13.68

gitを拡張することって言うのはできますか？
たとえば、git commit ってしたらc:\my.logに日時を記録する感じの機能をgitに組み込むなど

401 ：デフォルトの名無しさん：2013/09/13(金) 14:11:16.05

できるよ

402 ：デフォルトの名無しさん：2013/09/13(金) 19:15:58.04

>>400 適当なリポジトリで.git/hooksディレクトリの中身を読もう

403 ：デフォルトの名無しさん：2013/09/13(金) 20:56:48.98

>>384
いまどきのIDEだとローカルの作業履歴位はとってくれてるんだけどね。
コミットコメントが有るわけじゃないから何をやってたか分からないけど
ローカルの作業履歴としては割りと機能する。テキストエディタ以外は
認めないって人には分からないだろうけど。

404 ：デフォルトの名無しさん：2013/09/13(金) 21:39:01.30

Eclipseの履歴だと最低限は役に立つけどマージしたりスナップショット取ったり明示的にやれるわけじゃないし

405 ：デフォルトの名無しさん：2013/09/13(金) 21:52:13.00

>>400
gitのコミットログを見ればいいだけじゃん？
なんでわざわざ別に出力すんの？

406 ：デフォルトの名無しさん：2013/09/13(金) 22:44:41.16

>>403
エディタの編集履歴が便利なことは否定しないが、複数ファイルのスナップショットに名前をつけて保存できる機能とは区別しようぜ

407 ：デフォルトの名無しさん：2013/09/13(金) 22:55:30.79

>>363
git-svnだとマージに非常に制限がかかる。
そうなるとコンフリクトを恐れるようになって、いちいち手が止まってしまいストレスになる。

408 ：デフォルトの名無しさん：2013/09/13(金) 22:59:55.68

msysgitでdaemon立ち上げてリモートからpullやcloneしようとしたとき、たまにエラーになることが
あるんだが、原因を調べるには何を調べればいいかな？
表示されるエラーメッセージはInvalid Argumentとかearly EOFとかだけなんで意味わからん。

409 ：デフォルトの名無しさん：2013/09/13(金) 23:20:49.68

--verbose 付きで起動してみれば？

410 ：デフォルトの名無しさん：2013/09/13(金) 23:21:47.67

>>407
よく知らんのだけどrebaseじゃダメなの？

411 ：デフォルトの名無しさん：2013/09/14(土) 00:15:42.09

>>389
分散型だと中央を通さずに変更を渡すことが簡単だから、一部にだけ変更を伝えるという方法もあるね。

分散型はまだまだ色々な使い方ができそう。まあ運用を決めてもらわないと何もできない人には制限された方がいいんだろうけど。

412 ：デフォルトの名無しさん：2013/09/14(土) 00:16:03.03

>>407
dcommit時にコンフリクトするとどうなるの?
いつもrebaseしてからdcommitしてたから、意図せずマージになってたことは
ほとんど無くて、コンフリクトしたことがない。

413 ：デフォルトの名無しさん：2013/09/14(土) 00:40:38.03

>>412
rebaseあんまり使わないから向いてないのかも。
他のブランチでは気にせずgitらしくマージを繰り返してそれを中央リポジトリで公開して、いざsvn用のブランチに取り込もうとしてrebaseではまることが多かった。

414 ：デフォルトの名無しさん：2013/09/14(土) 00:44:26.35

ローカルでグチャグチャやってる分に口出す気はないよ。
それを上に持ってくんなということを言っている。

415 ：デフォルトの名無しさん：2013/09/14(土) 00:48:55.25

それ結局GitでもSVNでも同様だろ？

416 ：デフォルトの名無しさん：2013/09/14(土) 00:57:23.13

>>408
git config --global core.compression -1
でどうでしょう

417 ：408：2013/09/14(土) 07:24:34.77

>>409
それが、付けてもなんもわからなくて。
せめて、何に渡した何というArgumentがどうInvalidなのかくらいわかればいいんだが。

>>416
よくわからんが、エラーが出た箇所からすると関係ありそうな気がするな。
環境は会社なんで週明けに試してみるわ。ありがとう。

418 ：デフォルトの名無しさん：2013/09/14(土) 09:18:19.06

>>405
なんか自動化したいんだろ

419 ：デフォルトの名無しさん：2013/09/14(土) 10:29:28.80

>>412
rebase しないと dcommit できないんじゃないか。

420 ：デフォルトの名無しさん：2013/09/14(土) 10:42:48.85

>>419
dcommit時にマージされます。ローカルからはそう見える。
svn上では、update→commitに見えると思う。

421 ：デフォルトの名無しさん：2013/09/14(土) 14:16:33.20

>>405
複数人へのgit教育用にコミットしているかをひとつのログに集めたいから

422 ：デフォルトの名無しさん：2013/09/14(土) 22:52:16.95

>>420
㌧
自分が使ってた当時、怒られた記憶があったんだが。

423 ：デフォルトの名無しさん：2013/09/14(土) 23:55:50.48

>>422
コンフリクトした場合という話の流れを見逃してた。
コンフリクトした場合はどうなるかやったことがありません。
しなければマージされます。

424 ：デフォルトの名無しさん：2013/09/15(日) 07:40:17.91

svn dcommit時にsvn rebaseはされる
svn rebaseはrebaseもしている
最新リビジョンの先にしかコミットできないのと
svnのコミットにハッシュ振る必要があるので
ここでコンフリクトした場合確か無名ブランチに飛ばされるはず
自分はdevブランチ上で解決するようにしてるからあまり見たことないけど
共有がgitでも共有リポジトリの歴史いじることは推奨されてない気がするから
運用は似たようなもんじゃないの
？

425 ：デフォルトの名無しさん：2013/09/15(日) 09:35:25.12

ぼくはこれからバージョン0.0から始まるプログラムを作ろうと思います
1.0まで作ったとします。コミットもプッシュもたくさんやってきました
そしてバージョンアップさせていき2.0になりました
そこで質問です
やっぱりバージョンが違う場合でも同じリポジトリにコミットとプッシュするほうがいいのでしょうか？
あとバージョンごとにブランチは分けたほうがいいでしょうか？

426 ：デフォルトの名無しさん：2013/09/15(日) 09:44:38.26

そんなめんどくさいことしない

427 ：デフォルトの名無しさん：2013/09/16(月) 16:48:00.63

>>421
git logで誰がいつcommitしたか残ってるけど？？？

428 ：デフォルトの名無しさん：2013/09/16(月) 18:34:00.17

違うんです、commitした時点で別のログに記録したいんです

429 ：デフォルトの名無しさん：2013/09/16(月) 18:38:41.35

>>400
.git/hookでできるんじゃないの
拡張じゃなくて組み込まれてる機能だけど

430 ：デフォルトの名無しさん：2013/09/19(木) 23:11:39.01

CドライブとDドライブがあるんですが
Cドライブでコードを書いて、Dドライブをgithubの代わりとしてここにpushしたいのですが
こういう場合って、Dドライブのほうでgit init --bareってやってから
Cドライブ側でgit clone　～ってやるべきでしょうか？

431 ：デフォルトの名無しさん：2013/09/19(木) 23:50:18.12

HerokuとGithubしか使ったこと無く、Git単体で運用はしたことないんですが、
既に存在するプロジェクトのフォルダに対して

git init

git add .
git commit -m "comment"

を実行した場合、.gitフォルダにこれまでのバージョンが記録されていって、
いざとなれば、巻き戻せたりするんですよね？

432 ：デフォルトの名無しさん：2013/09/20(金) 00:17:54.09

>>431
目の前の箱で試してみろ

433 ：デフォルトの名無しさん：2013/09/20(金) 00:20:17.14

>>432
試してますが自身がないんです

434 ：デフォルトの名無しさん：2013/09/20(金) 00:44:10.93

Githubって使った事ないけど、
ローカルリポジトリ無くても
使えるものなの？

435 ：デフォルトの名無しさん：2013/09/20(金) 00:58:24.60

ローカルリポジトリは必要かもしれません。

ただしいつもgit cloneしてから、add, commit, pushしています。

436 ：デフォルトの名無しさん：2013/09/20(金) 01:10:41.71

ふーん、くろーうしてるんだな。

あっそ。

437 ：デフォルトの名無しさん：2013/09/20(金) 22:25:18.51

初心者がhelloworldやるのはgithubってやつでいいの？

438 ：デフォルトの名無しさん：2013/09/20(金) 22:27:49.10

try gitでもやってれば

439 ：デフォルトの名無しさん：2013/09/20(金) 22:31:10.14

全世界にhelloworldを公開したければ。
gitとgithubの違い分かってる？チーズとチーズケーキくらい違うよ。

440 ：デフォルトの名無しさん：2013/09/20(金) 22:34:11.91

githubでhelloworldやっちゃった
テヘ

441 ：デフォルトの名無しさん：2013/09/20(金) 22:35:10.10

「GitHub HelloWorld」でググるとみんなやってます

442 ：デフォルトの名無しさん：2013/09/20(金) 22:42:24.20

Hello Worldからforkする人っているの

443 ：デフォルトの名無しさん：2013/09/20(金) 23:03:11.09

初心者とかがレベルごとにステップアップできる
gitがあればいいのによくわらないけど

444 ：デフォルトの名無しさん：2013/09/20(金) 23:15:24.16

>>439
ケーキとケーキ屋くらい違うと思うな。
試しに作った初めてのケーキをケーキ屋に並べるとか、恥ずかしすぎる。

445 ：デフォルトの名無しさん：2013/09/20(金) 23:22:06.35

ぼくは恋人の始めてのケーキも味があっていいと思うんだ（直訳）

446 ：デフォルトの名無しさん：2013/09/20(金) 23:30:59.55

445さんすてき！抱いて！
男だけど

447 ：デフォルトの名無しさん：2013/09/20(金) 23:41:06.57

HelloWorldをＧｉｔHubに公開したからって誰かアクセスしてくるわけでもあるまいし
GitHub側が禁止してんならともかく何でもうｐしてけ

448 ：デフォルトの名無しさん：2013/09/21(土) 00:33:50.50

おまえらがうるさいから
今HelloWorldのリポジトリを削除していってるよ

449 ：デフォルトの名無しさん：2013/09/21(土) 01:07:54.68

どうしよう、俺もSandBoxプロジェクト削除してこようかな

450 ：デフォルトの名無しさん：2013/09/21(土) 16:52:31.32

git checkout -b test
ファイル編集
git add .
git commit -m "コミットします"
git push
でgithubにtestブランチができます
ここで「はっ！」と気づいたのですが、間違えてtestブランチにpushしてしまいました
testブランチじゃなくてmasterブランチにpushしたかったのですが、ここからどうしたらいいでしょうか？

451 ：デフォルトの名無しさん：2013/09/21(土) 16:54:50.56

俺だったら自殺もんのミス

452 ：デフォルトの名無しさん：2013/09/21(土) 16:55:42.26

バージョン管理システムなんだから前の状態に戻せるんじゃないの？

453 ：デフォルトの名無しさん：2013/09/21(土) 16:57:38.23

git logのオプションに--graphと--reverseを付けられないんですが
--graphで表示したものを逆順に表示する方法ありませんか？

454 ：デフォルトの名無しさん：2013/09/21(土) 17:00:32.88

>>450
そのままmasterにマージしてpushすればいいんじゃね

455 ：デフォルトの名無しさん：2013/09/21(土) 17:08:11.83

×バージョン管理システムなんだから前の状態に戻せるんじゃないの？
○バージョン管理システムなんだから間違った状態も保存される。

間違った状態そのものを完全に履歴から抹殺するのは非常手段。

456 ：デフォルトの名無しさん：2013/09/21(土) 17:10:59.62

もどしてやらないとダメでしょうか？

そのままpushしたら
To git@～.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to 'git@～.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first merge the remote changes (e.g.,
hint: 'git pull') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
ってなりました

457 ：デフォルトの名無しさん：2013/09/21(土) 21:07:39.45

Githubで質問です。
Pull Requestが来たんですが、内容の一部だけ採用して、他の部分は今までの自分のでいきたい、
という場合はどう処理すればよいのでしょうか？

458 ：デフォルトの名無しさん：2013/09/21(土) 21:09:17.87

全部まとめて送るなカスって送っとけ

459 ：デフォルトの名無しさん：2013/09/21(土) 21:10:46.12

一部だけ採用できるってことは別種の変更がひとつにまとまってるってことだろ？
コミット分けろボケって言っとけ

で、全部マージするんじゃなくて好きなやつだけcherry-pickするとか

460 ：デフォルトの名無しさん：2013/09/21(土) 21:13:13.72

ぼくもきれいなおねえさんに、ちぇりーぴっくされたいです。

461 ：デフォルトの名無しさん：2013/09/22(日) 03:03:18.32

GitHubの質問ってこのスレでいいのん？

462 ：デフォルトの名無しさん：2013/09/22(日) 03:18:31.00

内容によるだろうな

463 ：デフォルトの名無しさん：2013/09/22(日) 10:43:36.96

指定したcommitに対応するtagがあればそれを表示する方法は？

464 ：デフォルトの名無しさん：2013/09/22(日) 10:58:58.87

リモートのブランチをマージすることはできないの？

465 ：デフォルトの名無しさん：2013/09/22(日) 11:04:23.25

できますん

466 ：デフォルトの名無しさん：2013/09/22(日) 13:00:59.45

,gitignoreの記述で、
サブディレクトリ以下には適用されない、
そのディレクトリ直下のみのパターンを書く方法は？

467 ：デフォルトの名無しさん：2013/09/22(日) 13:31:09.00

パターンを/からはじめる

468 ：デフォルトの名無しさん：2013/09/22(日) 13:46:13.30

>>463
git tag --points-at hoge
Tagとハッシュの一覧は
git show-ref --tags

469 ：デフォルトの名無しさん：2013/09/22(日) 14:51:00.75

ファイルごとにバージョン番号を自動採番したいけど
どうしたらいいんだろうか

470 ：デフォルトの名無しさん：2013/09/22(日) 15:03:54.92

バージョン番号って何だ？

471 ：デフォルトの名無しさん：2013/09/22(日) 15:55:22.54

>>470
そのファイルのバージョン

472 ：デフォルトの名無しさん：2013/09/22(日) 15:57:16.58

>>470
CVSにたとえるなら $Id$ みたいなものがほしい

473 ：デフォルトの名無しさん：2013/09/22(日) 15:58:43.14

>>470
そのファイルのコミット回数のようなものでも構いません

474 ：デフォルトの名無しさん：2013/09/22(日) 16:09:36.28

exportだかarchiveだかの時に置換フィルタをかけるやり方はなんかあった気がするけど
そもそもgitのIDだかってSHA-1ハッシュ値だから、何も嬉しくない気が

475 ：デフォルトの名無しさん：2013/09/22(日) 16:38:46.50

フックはあるから自分でスクリプト書けばいいんじゃないかな　なんでファイルごとのバージョン番号なんてものが必要になるのかは理解しがたいが
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%81%AE%E5%B1%9E%E6%80%A7#キーワード展開

476 ：デフォルトの名無しさん：2013/09/22(日) 16:42:58.40

バージョン番号1のファイルがあったとして、
そのファイルを複数のローカルリポジトリで更新したら
それぞれのリポジトリでのバージョン番号はどうなるんだ？

477 ：デフォルトの名無しさん：2013/09/22(日) 17:03:54.74

>>461

GitHubやってる？
http://kohada.2ch.net/test/read.cgi/prog/1363523309/

478 ：デフォルトの名無しさん：2013/09/22(日) 17:22:33.30

>>476
それぞれ2になるんじゃね
んでマージすると一気に4になるんだよきっと

479 ：デフォルトの名無しさん：2013/09/22(日) 17:42:34.93

>>476,478
「どちらも2になって、マージすると3になる」説を推す
マージすると大きいほうの番号より1大きい番号になるってことで

それより不可解なのは番号がファイルごとに振られていることだな

480 ：デフォルトの名無しさん：2013/09/22(日) 17:59:31.29

いやおまえらｗ仮にもバージョン番号なんだから、
同じバージョン番号の違う内容のファイルがあったらダメだろｗ

481 ：デフォルトの名無しさん：2013/09/22(日) 18:03:56.28

つまりブランチ名がバージョン番号に含まれればいいのか！
いやちがう
レポジトリを一意に識別するための名前も含まれる必要があるのか！

482 ：デフォルトの名無しさん：2013/09/22(日) 18:10:00.24

ローカルリポジトリでは番号をインクリメントさせません。

483 ：デフォルトの名無しさん：2013/09/22(日) 18:25:26.05

>>482
メインのリポジトリで複数のブランチに別れたときはどうするの？

484 ：デフォルトの名無しさん：2013/09/22(日) 18:46:53.20

どうやらgitのやり方とはそぐわないことをやりたいらしいってことは分かった
で、何をするためにバージョン番号とやらが必要なんだ？

485 ：デフォルトの名無しさん：2013/09/22(日) 19:08:33.03

コミットIDさえあればそのリポジトリに存在するすべてのファイルの状態を特定できるんだから、
レポジトリの内容を元にバイナリを作ったりデプロイするときに
コミットIDを保存すればいいと思うのだけどね

486 ：デフォルトの名無しさん：2013/09/22(日) 19:22:24.03

俺の周りでもファイルごと版数にこだわる人たちが多いよ。
SVNに移行したのも最近だよ。(やっとタグをつけるプロパティを発見したらしい)

どうも、バラバラなファイルが集まったものが成果物という認識らしい。
だから何が集まってできたものか管理したいらしい。
それにしてもいろいろ的外れなわけだけど。

487 ：デフォルトの名無しさん：2013/09/22(日) 19:34:30.74

>>486
> やっとタグをつけるプロパティを発見したらしい

なんかどえらいもん発見してるな (w

488 ：デフォルトの名無しさん：2013/09/22(日) 19:42:25.50

おっと、分かってると思うけどCVSと同じように$Id$とかを置き換える設定ね

489 ：デフォルトの名無しさん：2013/09/22(日) 19:46:04.82

>>488
CVSの$ID$はブランチ切ったりマージしたときはどうなるの？

490 ：デフォルトの名無しさん：2013/09/22(日) 20:04:31.03

ブランチはピリオドで区切った数字が増える。1.2からブランチして1.2.1.1とか
1.5にマージすると1.6じゃないのかなあ。要はただのcommitだよ。
cvsでもリビジョンの数字自体に意味はない。ルールわかりやすいけどただのID。

そういや、ファイルごとの版数を管理したがる人たちは、cvsでも数字に意味を
持たせたがってた。要所要所でリビジョン番号を手で指定するとかw
全ファイルわざわざリビジョンを変えたりしてたよw
ファイルごとに変えたいんじゃなかったのか? 意味分かんねえw

というわけで、リリース物の管理はgitの外で行えばいいんじゃないでしょうか?
ヘッダにそれらしい版数をつけるスクリプトを流すとか。

491 ：デフォルトの名無しさん：2013/09/22(日) 20:12:15.63

Gitはブランチを切ったときにどっちが親とかの概念がないからなあ
もとのブランチのファイルが1.2で
新しいブランチのファイルが1.2.1とか
そういうやり方は馴染まないよね

492 ：デフォルトの名無しさん：2013/09/22(日) 20:33:51.96

ようするにgit以外のやり方でgitを使おうとして大混乱、でFA？

493 ：デフォルトの名無しさん：2013/09/22(日) 21:13:40.77

gitを使うのに、git以外のやり方をすると
何もかもぶち壊しになるよ。
gitつかう意味がなくなる。

やめたほうがいいじゃなくて、
やめろって命令するレベル。

494 ：デフォルトの名無しさん：2013/09/22(日) 23:13:35.91

話は少し違うけどファイル別にコミット時のバージョンが保持されると、identコマンドでリンクされているソースのバージョンが取れるから便利だよ。

再現試験とか、リリース間違いの発見とか。

495 ：デフォルトの名無しさん：2013/09/22(日) 23:29:03.79

だからコミットIDをひとつだけ埋め込んどけば
リンクされてる全ソースが特定できるんだってば

496 ：デフォルトの名無しさん：2013/09/23(月) 00:17:14.27

「ファイルごとの版数が分かる」じゃなくて
「ファイルごとの版数しかわからない」だったんだよね。(タグは打てるけど)

コミットIDが分かるようになったんだから、もういいじゃん。

497 ：デフォルトの名無しさん：2013/09/23(月) 03:37:42.42

>>460
財布の中身だけチェリーピックしてもいいですか？

498 ：デフォルトの名無しさん：2013/09/23(月) 08:20:52.67

gitは開発中に回せ回せで使っておいて
特定時点の動くものをsvnなどに
まとめるのがいいのか？

499 ：デフォルトの名無しさん：2013/09/23(月) 08:38:32.18

>>498 まとめるのはgitじゃダメなん？

500 ：デフォルトの名無しさん：2013/09/23(月) 08:44:00.30

>>498 まとめるのはgitじゃダメなん？

501 ：デフォルトの名無しさん：2013/09/23(月) 10:27:09.72

>>498
Are you kidding?

502 ：デフォルトの名無しさん：2013/09/23(月) 10:38:24.27

You gonna dig this.

503 ：デフォルトの名無しさん：2013/09/23(月) 10:41:32.31

git使うならこれもつかったほうがいいってやつ教えて

504 ：デフォルトの名無しさん：2013/09/23(月) 10:55:41.23

source tree

505 ：デフォルトの名無しさん：2013/09/23(月) 12:15:15.39

tig

506 ：デフォルトの名無しさん：2013/09/23(月) 12:34:05.81

>>503
tig

507 ：デフォルトの名無しさん：2013/09/23(月) 14:11:01.02

>>498
forkしたものをそのまま後悔とか？

508 ：デフォルトの名無しさん：2013/09/23(月) 15:39:50.36

>>500
いいと思うよ。
きちんとバージョン番号振ってくれればそれでいい。

509 ：デフォルトの名無しさん：2013/09/23(月) 15:44:01.93

バージョン番号って年月日＋ビルド番号じゃないの？
あとそれにブランチ名をくっつけて
バージョン番号。

510 ：デフォルトの名無しさん：2013/09/23(月) 15:47:07.11

日付も入れるの？

511 ：デフォルトの名無しさん：2013/09/23(月) 15:48:31.58

よく入ってるよね？

512 ：453：2013/09/23(月) 15:49:46.64

どなたかお願いします

513 ：デフォルトの名無しさん：2013/09/23(月) 15:50:56.79

それはアンパンマンに任せよう

514 ：デフォルトの名無しさん：2013/09/23(月) 15:54:12.16

>>508
分散バージョン管理環境では、
ファイル単位での単純なバージョン番号に依存したら危険なのは理解できる？

515 ：デフォルトの名無しさん：2013/09/23(月) 15:56:31.87

必要なのは各々のファイルをなんらかのIDで特定できることだよね？

516 ：デフォルトの名無しさん：2013/09/23(月) 16:41:23.02

バージョン番号が増えていく数字でないと嫌で、$Id$でその数字をファイルに展開したいという人は、gitを使わないほうがいい。
そのやり方は絶対にgitとなじまない。

517 ：デフォルトの名無しさん：2013/09/23(月) 16:49:18.09

>>514
幹側では分散させない運用なので問題ありません。

518 ：デフォルトの名無しさん：2013/09/23(月) 16:53:57.06

>>517
ローカルにビルドしたとき困るじゃん？
バージョン番号とファイルの内容が一致してなくて混乱する

519 ：デフォルトの名無しさん：2013/09/23(月) 18:31:02.61

>>517
>>494でもふれたけど、コミット時のバージョンと今使っているファイルのバージョンがわかれば、あとの調査はバージョン管理システムの仕組みですればいいのだから、ファイル別にとかにこだわる理由はないよね？

それでもこだわりたいのなら、まずはその理由を明確にするべき、今の状態だと単につっているようにしか見えない

ファイル別に数字のバージョンがつくのはciとかco時代の名残だよ。
分散型ではファイル別からプロジェクト別へと管理する単位がシステム的に変わってる

520 ：デフォルトの名無しさん：2013/09/23(月) 18:41:40.85

そこは「分散型では」ってわけじゃないだろ。

521 ：デフォルトの名無しさん：2013/09/23(月) 18:47:02.50

ちょっと思いついたことがあるんですけど
gitを使った掲示板ってありませんよね？
pushしてレスするの

522 ：デフォルトの名無しさん：2013/09/23(月) 18:49:10.22

githubじゃなくて？

523 ：デフォルトの名無しさん：2013/09/23(月) 19:46:02.04

>>519
gitではまとめて管理「できる」という認識です。

524 ：デフォルトの名無しさん：2013/09/24(火) 04:00:22.55

>>521
github の wiki

525 ：デフォルトの名無しさん：2013/09/24(火) 04:12:03.72

>>523
gitでできるかどうかではなく、
自分がどうしたいかで考えなよ。

まず、プロジェクトのファイルってのは
単体でバージョン管理しても意味が無い。

バージョン1のファイルとバージョン2のファイルを
組み合わせて使っても正しく動かないからだ。

バージョン管理の世界は、そうやってファイル単体で
バージョン管理するのは意味が無いよね。ってことで
コミット単位でバージョンを管理する方法に進化してきた。

えっと、ここまでは理解できる？

526 ：デフォルトの名無しさん：2013/09/24(火) 09:37:19.57

>>521
掲示板じゃないけど、BitbucketのWikiはGitだったよ。

527 ：デフォルトの名無しさん：2013/09/24(火) 11:21:16.11

>>525
＞自分がどうしたいかで考えなよ
ファイルごとにバージョン番号をつけたいです

528 ：デフォルトの名無しさん：2013/09/24(火) 11:21:50.94

>>525
＞単体でバージョン管理しても意味が無い
私どもにとっては意味があります

529 ：デフォルトの名無しさん：2013/09/24(火) 11:22:49.62

>>525
＞バージョン1のファイルとバージョン2のファイルを
＞組み合わせて使っても正しく動かないからだ
それはさらに全体のバージョン（タグ）を使って管理します

530 ：デフォルトの名無しさん：2013/09/24(火) 11:31:48.90

>>527
ファイル内に直接バージョン書いておいたらいいじゃない
そのファイル単独をgitでバージョン管理したいなら、そのファイルのみでリポジトリ作ってgit submoduleとかで管理すべきでしょ

531 ：デフォルトの名無しさん：2013/09/24(火) 11:47:01.22

>>527-529
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%81%AE%E5%B1%9E%E6%80%A7
そこまでこだわりがあるならここみて頑張ってカスタマイズすればいい
ここではIdにハッシュを展開してるけど、
やろうと思えばメインリポジトリの特定ブランチにコミットされた回数とかを展開することもできるよ
たぶんIdはハッシュのままでDateに日付を展開する程度でも十分だと思うけど

532 ：デフォルトの名無しさん：2013/09/24(火) 12:03:49.65

git使わないほうがいいんじゃないのか

533 ：デフォルトの名無しさん：2013/09/24(火) 12:06:47.69

日付フォルダ最強

534 ：デフォルトの名無しさん：2013/09/24(火) 13:15:42.32

確かにgit使わないが正解だわ

535 ：デフォルトの名無しさん：2013/09/24(火) 13:21:54.13

普段は日付フォルダにしといて
動作確認出来たまとまったバージョンだけコミットするのもアリ

536 ：デフォルトの名無しさん：2013/09/24(火) 13:35:31.82

いやいやいやｗ

537 ：デフォルトの名無しさん：2013/09/24(火) 14:16:02.29

ファイルごとにバージョン管理したいならサブモジュールって手法もある。
やりたい事とあってるかわからないけど。

あと考えついたのはファイル単位でコミットしてコミットする時のコメントでバージョン番号残すとか、それくらいかな。

538 ：デフォルトの名無しさん：2013/09/24(火) 14:22:58.37

pushしたときに指定したバッチファイルを実行するようにする方法をおしえて

539 ：デフォルトの名無しさん：2013/09/24(火) 14:33:26.50

>>527
それは目的でなく手段では?
ファイルごとにバージョン番号をつけた結果、何を得られるの?

540 ：デフォルトの名無しさん：2013/09/24(火) 14:38:04.35

俺も聞こうと思ってたこと>>539が聞いてくれてた
目的決めるのマジ重要

541 ：デフォルトの名無しさん：2013/09/24(火) 14:46:04.85

>>539
>>528さんが何をしたいのか…。
目的は私も知りたいですけどね。

542 ：デフォルトの名無しさん：2013/09/24(火) 16:01:08.19

答える側は、それはファイルごとにバージョン付ける以外の方法で解決すべき問題なんだろうと思ってるし、
質問する側は、他の方法で解決するという選択肢はないと思ってる感じ

543 ：デフォルトの名無しさん：2013/09/24(火) 16:11:18.47

527～529の書きこみが
話が通じてない雰囲気がぷんぷんするね

544 ：デフォルトの名無しさん：2013/09/24(火) 16:42:08.29

cvsでスキルが停滞してる現場のコード規約なんだろ。あるいは元請けのカスエンジニアあたりが無意味な要求してきたりな。gitでやるが間違い。だからcvsかsvnでやっとけ。
あとgit svnはハマりポイント多いからやめとけ。工数浪費していい事がねえから

545 ：片山博文MZコスモ ◆T6xkBnTXz7B0 ：2013/09/24(火) 17:04:37.27

githubで公開したリリースは削除できないの？

546 ：デフォルトの名無しさん：2013/09/24(火) 17:10:26.19

gitリポジトリをdropboxに保存したいんですが
gitリポジトリを暗号化するほうほうないですか？

547 ：デフォルトの名無しさん：2013/09/24(火) 17:20:31.51

GitHubはこちら

GitHubやってる？
http://kohada.2ch.net/test/read.cgi/prog/1363523309/

548 ：デフォルトの名無しさん：2013/09/24(火) 17:42:47.29

皆さん機能追加やバグ修正用のブランチ名ってどんな風にしてますか？
日付、BTSの該当チケットID、機能の簡単な説明文などありますが
どんなものが便利か悩んでます

549 ：デフォルトの名無しさん：2013/09/24(火) 17:52:36.89

チケットID?

550 ：片山博文MZコスモ ◆T6xkBnTXz7B0 ：2013/09/24(火) 18:06:23.06

>>547 移動します。

551 ：デフォルトの名無しさん：2013/09/24(火) 18:26:06.71

>>544 あの頑固さは規約でそう決まってるみたいな臭いがする態度だな
>>546 微妙にスレチ　なぜ暗号化するのをよく考えてからTrueCryptでｇｇれ
>>548 機能の説明文に一票

552 ：デフォルトの名無しさん：2013/09/24(火) 19:08:00.49

会社ではJira issueのIDを名前にしてブランチ切っている。

553 ：デフォルトの名無しさん：2013/09/24(火) 21:36:32.42

>>544
git svnのハマりポイントって何?
使ってるから予め知っておきたい。

554 ：デフォルトの名無しさん：2013/09/24(火) 21:38:24.93

>>527
> ＞自分がどうしたいかで考えなよ
> ファイルごとにバージョン番号をつけたいです

それは本当にお前がやりたいことなのか？

やりたいと思っているならば、
そこに理由が必ず存在するはずだ。

その理由を言ってみてくれ。
それがないなら、実はやりたいとは思っていないということになる。

555 ：デフォルトの名無しさん：2013/09/24(火) 22:18:37.96

ファイルに付いたバージョン番号を眺めるのが趣味なのかもしれない

556 ：デフォルトの名無しさん：2013/09/24(火) 22:52:06.22

>>553
別人だけどsvnの外部参照は使えないと思った方が良さそうだったよ

557 ：デフォルトの名無しさん：2013/09/26(木) 04:25:57.70

>>553
svnを単体プロジェクト推奨レイアウト使ってれば早々困ることはない。
svnはフリーダムな運用が可能で、現場だとかなりワイルドな使い方をされる事が多いからgit svnだと追跡しきれない事がままある。gitはファイル名文字コード問題も完全じゃない。あと忘れた。
個人なら中央もgitでFAだな

558 ：デフォルトの名無しさん：2013/09/26(木) 11:02:15.52

githubにpull requestを送る方法って
そのリポジトリにmasterブランチ以外のブランチでプッシュするだけでいいですか？

559 ：デフォルトの名無しさん：2013/09/26(木) 11:45:36.56

GitHub固有のサービスの質問はこちらへ

GitHubやってる？
http://kohada.2ch.net/test/read.cgi/prog/1363523309/

560 ：デフォルトの名無しさん：2013/09/26(木) 12:09:44.75

pull requestはgithub固有の内容じゃないのでここでOKです

561 ：デフォルトの名無しさん：2013/09/26(木) 12:25:57.02

じゃあ、git request-pullの話をしましょう

562 ：デフォルトの名無しさん：2013/09/26(木) 23:47:09.46

>>559
つい先日まで静かだったスレが活気づいててワロタ

563 ：デフォルトの名無しさん：2013/09/28(土) 13:52:09.53

ブランチの特定のファイルだけマスターにマージって出来ないのでしょうか？

ブランチの特定のファイルの何行以下だけ
マスターにマージという形も出きるといいのですが

564 ：デフォルトの名無しさん：2013/09/28(土) 14:00:02.33

ほしいファイルだけぬくかたちでコミットし直してマージかなぁ。
ソースツリーかえるとあとでコンフリクトしそう

565 ：デフォルトの名無しさん：2013/09/28(土) 20:59:42.53

やっぱり職場ではgitを使いこなしてないと即戦力にはなりませんか？
git clone ～
git init
git add .
git commit -m "新規作成した"
git checkout -f
git checkout -b test
git merge test
基本的にこれしか知りません

566 ：デフォルトの名無しさん：2013/09/28(土) 21:05:45.92

ここはgitスレだぞ、そんな程度で許される訳がないだろう
今すぐ$ git clone https://github.com/git/gitして原典をくまなく読むんだ

567 ：デフォルトの名無しさん：2013/09/28(土) 21:09:06.43

先輩すいませんでした今すぐ読んできます

568 ：デフォルトの名無しさん：2013/09/28(土) 21:10:53.01

>>565
使ってるところはほとんど無いと思う。
まだ趣味の世界。

といか、職場でうちらが布教活動する感じだね（笑

rebaseの使い方、とくにontoを指定するケースは、覚えた方がいい。
branchの移動や部分的な取り込みで使う。

569 ：デフォルトの名無しさん：2013/09/28(土) 21:13:19.07

至急！！！！！
他人のリポジトリにDeleteボタンがありますけどこれ勝手に押したら消えますか？
https://github.com/git/hello-world/blob/master/php.php

570 ：デフォルトの名無しさん：2013/09/28(土) 21:21:53.38

GitHub固有のサービスの質問はこちらへ

GitHubやってる？
http://kohada.2ch.net/test/read.cgi/prog/1363523309/

571 ：デフォルトの名無しさん：2013/09/28(土) 21:28:26.36

>>569

[Sign out]
You must be signed in and on a branch to make or propese changes

[Sign in]
Fork this project and delete file

572 ：デフォルトの名無しさん：2013/09/28(土) 21:29:06.06

deleteボタンにカーソルを合わせただけです

573 ：デフォルトの名無しさん：2013/09/28(土) 21:32:36.13

>>569

>>437-448 あたりをよく読め
ハローワールドなんか作ってんじゃねえぞ
さっさと消せ

574 ：デフォルトの名無しさん：2013/09/29(日) 09:11:01.63

>>563
1) --no-commitでコミット前に止める。
2) マージしたくないファイルをcheckout HEAD ファイル名で戻す。
マージしたくないファイルが大量にある場合はマージしたいファイルの方をリネームなりでとって置いてからcheckout HEAD . で全ファイルを戻し、とって置いたファイルでさらに上書きする
3) addしてcommit

575 ：デフォルトの名無しさん：2013/09/29(日) 09:17:00.49

注意事項として、git的にはmasterに反映しないことを選んだファイルも含めてマージされたことになるから、後から残りのファイルをマージしようとしても上手く行かない。
段階的にマージすることが目的ならマージ元のコミットを分割する方が良い。

576 ：デフォルトの名無しさん：2013/09/29(日) 16:28:13.98

JavascriptでGitを再実装したら
340万円もらえるってよ

JS-Git - Fundraisers
https://www.bountysource.com/fundraisers/325-js-git

577 ：デフォルトの名無しさん：2013/09/29(日) 18:39:11.74

javascriptってファイル操作とか出来たんだっけ？

578 ：デフォルトの名無しさん：2013/09/29(日) 18:42:16.53

いまどきのは出来るよ

579 ：デフォルトの名無しさん：2013/09/30(月) 01:54:49.17

Gitで、
「どこそこにあるリポジトリのこのコミット」
を表すにはどう示す（書く）のいいでしょうか? よく使われる書式があったりしないでしょうか?
リポジトリのURLとコミットIDがあれば情報としては足りますが、ブランチ名もいっしょに示したほうが親切かなと思ってます。

580 ：デフォルトの名無しさん：2013/09/30(月) 02:02:33.99

リポジトリのURLとコミットID書いて、コメントでブランチ名を追加すれば？
同じことでしょ？ｗ

581 ：デフォルトの名無しさん：2013/10/01(火) 03:23:36.75

sirokuma @Wiki - gitコマンド
ttp://www11.atwiki.jp/sirokuma/pages/40.html

582 ：デフォルトの名無しさん：2013/10/01(火) 16:30:09.33

gitのコマンドは直感的じゃ無いからな・・・
cvsのコマンド形態で分散型ならよかった

583 ：デフォルトの名無しさん：2013/10/01(火) 17:08:45.07

コミットオブジェクトの意味が理解できると安心して無茶ができるようになって快適なのだけどね
そのへんが理解できてないと各操作が恐ろしい

584 ：デフォルトの名無しさん：2013/10/01(火) 17:14:00.60

>コミットオブジェクトの意味

はよ説明

585 ：デフォルトの名無しさん：2013/10/01(火) 17:55:16.57

>>584
この辺から勉強してみたらいいんじゃないか？
http://keijinsonyaban.blogspot.jp/2011/05/git.html

586 ：デフォルトの名無しさん：2013/10/01(火) 18:07:59.45

㌧

587 ：デフォルトの名無しさん：2013/10/01(火) 19:02:06.23

あのオプション体系考えたの誰なんだろう
センス無さすぎる

588 ：デフォルトの名無しさん：2013/10/01(火) 19:03:55.31

おみゃーがセンスあるものを作れにゃー

589 ：デフォルトの名無しさん：2013/10/01(火) 21:40:30.82

gitのcheckouｔって日本語に訳すならどんな感じになる
一般英語ならcheck outは「貸し出す」ってことだけどgitのもそんな感じでおｋ？

590 ：デフォルトの名無しさん：2013/10/01(火) 21:47:34.99

片仮名でチェックアウト以外の何物でもないと思うが……
君、ホテルのチェックアウトはどう表現しているんだい。

591 ：デフォルトの名無しさん：2013/10/01(火) 21:51:27.47

外泊

592 ：デフォルトの名無しさん：2013/10/01(火) 21:51:56.31

gitの場合、他のVCSが使ってたコマンドに相当する機能程度の意味だよ
gitのcheckoutには少なくとも3つの別の機能があるしね

593 ：デフォルトの名無しさん：2013/10/01(火) 21:56:14.94

gitのcheckoutに○○しつつチェックアウト
以外の機能ってなんかあるのか？

594 ：デフォルトの名無しさん：2013/10/01(火) 21:56:45.21

>>590
普通に「精算」でしょ

595 ：デフォルトの名無しさん：2013/10/01(火) 22:27:27.68

チェックメイトで

596 ：デフォルトの名無しさん：2013/10/01(火) 22:50:55.81

むしろ、一連の作業の開始って意味では
「チェックイン」の方がホテル的にイメージに合ってるんじゃね？
とか10年以上前にVCSの話を聞いたときにフーンと思った

597 ：デフォルトの名無しさん：2013/10/01(火) 23:09:39.50

チェックアウト

荷物（リポジトリ）を持ってホテル（masterブランチ）から出る

598 ：デフォルトの名無しさん：2013/10/01(火) 23:10:37.88

チェックアウト

精算（現時点のリポジトリをまとめて）してホテル（masterブランチ）から出る

599 ：デフォルトの名無しさん：2013/10/01(火) 23:29:15.83

チェケラッチョ♪

600 ：デフォルトの名無しさん：2013/10/02(水) 01:18:36.75

>>582
cvsは知らんけどsvn使ってた俺から見ればgitよりhgのほうが直感的だと思う

601 ：デフォルトの名無しさん：2013/10/02(水) 01:24:50.52

自分が知っているものと同じか似ているものを"直感的"って言う人って居るよね。

602 ：デフォルトの名無しさん：2013/10/02(水) 01:26:45.81

git使いのことだな

603 ：デフォルトの名無しさん：2013/10/02(水) 01:27:24.71

QWERTY配列は直感的です。

604 ：デフォルトの名無しさん：2013/10/02(水) 01:28:07.39

checkoutというのが直観的かどうか

605 ：デフォルトの名無しさん：2013/10/02(水) 01:52:03.98

数字の箱とか犬クラスに近い危険な香りがする

606 ：デフォルトの名無しさん：2013/10/02(水) 06:33:31.87

>>601はmercurialとcvsを使ったことがない

607 ：デフォルトの名無しさん：2013/10/02(水) 09:58:56.69

荒らしと関わらない場合は「完全スルー」がベスト。

608 ：デフォルトの名無しさん：2013/10/02(水) 10:29:06.07

hgの方がコマンド体系は良く出来ている
と思う

609 ：デフォルトの名無しさん：2013/10/02(水) 10:41:34.04

hgのことなんて知らない奴の方が多いんだから
どう良く出来てるのか説明できないなら便所の落書きだな

610 ：デフォルトの名無しさん：2013/10/02(水) 11:58:40.80

毎日新聞か

611 ：デフォルトの名無しさん：2013/10/02(水) 13:21:44.00

井の中の蛙大海を知らず

612 ：デフォルトの名無しさん：2013/10/02(水) 14:32:42.79

【分散型バージョン管理】 Mercurial 2【hg】
http://toro.2ch.net/test/read.cgi/tech/1321109748/

613 ：デフォルトの名無しさん：2013/10/02(水) 14:38:37.67

gitしか知らない馬鹿が増えてきたな

614 ：デフォルトの名無しさん：2013/10/02(水) 14:58:48.17

>>2

◆関連スレ
バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/
CVS導入スレ～ Rev.3
http://toro.2ch.net/test/read.cgi/tech/1113141518/
Subversion r14
http://toro.2ch.net/test/read.cgi/tech/1326806859/
【分散型バージョン管理】 Mercurial 2【hg】
http://toro.2ch.net/test/read.cgi/tech/1321109748/
【bzr】Bazaarでバージョン管理 Rev 4
http://toro.2ch.net/test/read.cgi/tech/1356521407/

615 ：デフォルトの名無しさん：2013/10/02(水) 15:40:21.53

>>606は自分に理解できるレベルのことを直感的と言う。

616 ：デフォルトの名無しさん：2013/10/02(水) 15:40:43.14

プロジェクトに途中から参加する場合、まず最初にやるのは
git cloneですか？

あと毎日最初にやるのはgit fetchですか？

617 ：デフォルトの名無しさん：2013/10/02(水) 15:56:30.53

>>616
普通は fork かなぁ
clone したあとすぐ branch 作るならそれでもいい

618 ：デフォルトの名無しさん：2013/10/02(水) 20:10:48.65

forkってどうやるの
git fork http://～
て感じ？

619 ：デフォルトの名無しさん：2013/10/02(水) 20:23:20.85

>>601
それすげー同意。超あるあるだわ
git使いとかってほんとにgitを直感的とか思い込んでて怖いよね

620 ：デフォルトの名無しさん：2013/10/02(水) 20:42:50.04

このスレ読み返してみたけどgitのコマンドを直感的って言ってるやつは一人もいないよ
hgのコマンドを直感的って言ってるやつはいるけど

621 ：デフォルトの名無しさん：2013/10/02(水) 20:43:42.97

>>618
forkはgithubのことだろう
git一般的にはcloneでいいよ

622 ：デフォルトの名無しさん：2013/10/02(水) 21:11:45.22

互いにライバルとしてgitとmercurialは現在似たような機能を有するようになってるけど
根本的にアプローチが違うと思う
mercurialは既存のVCSの延長線上で今風の要請に応える形だが、gitは既存のVCSの否定から
始まって、UIを既存のVCSに寄せていった形

623 ：デフォルトの名無しさん：2013/10/02(水) 21:35:51.46

VCS?

624 ：デフォルトの名無しさん：2013/10/02(水) 21:36:23.11

Version Control System

625 ：デフォルトの名無しさん：2013/10/02(水) 21:45:45.85

GitとMercurialについて語りたいならこっちのスレでやれや

バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/

626 ：デフォルトの名無しさん：2013/10/02(水) 23:34:00.79

>>619
gitを使い込んでて、あのコマンド、オプション体系を直感的だと思う奴はいないと思う
慣れればなんとかなるとは思ってるだろうけど

627 ：デフォルトの名無しさん：2013/10/03(木) 00:40:21.78

何をどう直せと言ってるんだ？

628 ：デフォルトの名無しさん：2013/10/03(木) 00:44:44.16

別に直す必要はないよ
シェルの補完とかがあればそのまま使うのも問題無いし
頻繁に使うコマンドやオプションは自分で定義しなおせばいい

629 ：デフォルトの名無しさん：2013/10/03(木) 01:44:05.10

>>628
うん。それは知ってる。

どう直せと言ってるのか知りたいだけ

630 ：デフォルトの名無しさん：2013/10/03(木) 02:02:37.77

>>629
直感的ではないというだけの話だろ
どう直したら直感的になるか、なんて知るかよ

631 ：デフォルトの名無しさん：2013/10/03(木) 02:07:51.12

コマンドが全部日本語的になれば日本人にとって直感的になるんじゃね

英語だとcheckoutみたいに何となく意味をとらえづらいというか
checkoutとはそういうもんだと言う認識が出来るまでの辛抱ではあるが

632 ：デフォルトの名無しさん：2013/10/03(木) 02:13:41.04

それだと結局、直感＝自分の知ってるものと同じにしかならないだろ。

ソースコードのバージョン管理なんか普段の生活でやらないだろ？

例えばタッチパネルの使い方みたいに指で触れば動くという使い方は
タッチパネル以外の普段の生活でやることなんで”直感的” という考えは成り立つ。

でもソースコードのバージョン管理は、似たようなものが他にない。
だから直感的なんて考え方がそもそもありえない。
あるとするならば、自分が知ってる他のバージョン管理ソフトと同じかどうかって言うこと。

他の人も言ってるように、直感的なんて言葉を使わずに、
俺の知ってる○○とコマンド体系が違うヤダヤダって言えばいいんだよ。

633 ：デフォルトの名無しさん：2013/10/03(木) 02:15:30.67

>>631
git ソースコード編集開始とでも書けばわかるのか？
全然日本語が適切じゃないが。

どっちみち専門用語にしかならんのだから
直感的になることなんてありえないよ。

634 ：デフォルトの名無しさん：2013/10/03(木) 02:25:24.86

バージョン管理のコマンド系に命名規則の規格を設ければいいんだよ！

635 ：デフォルトの名無しさん：2013/10/03(木) 02:27:25.75

checkoutにこだわっちゃってる奴がいるんだな
CVSとかと意味が違うから、気になって、気になって、気になって、仕方無いんだろうな

636 ：デフォルトの名無しさん：2013/10/03(木) 02:34:35.25

>>631
日本語とかそういうのじゃないよ。gitのコマンドは引数によって同じコマンドでも
想像していた動きと違う動きをする部分でしょ。作りながら色々と機能追加する
場合によくある。ルールを決めてやり直すには普及しすぎてるのが頭の痛い
ところだろうね。

637 ：デフォルトの名無しさん：2013/10/03(木) 02:38:56.02

>>636
だからー。それがなにか言えって。

ぐだぐだしてるのは、それが何かを言ってないから
誰も賛同しようがないんだよ。

638 ：デフォルトの名無しさん：2013/10/03(木) 02:40:41.00

>>636
たとえばどんなコマンドですか？checkout？ｗｗ

639 ：デフォルトの名無しさん：2013/10/03(木) 02:42:03.92

checkoutがブームなん？

640 ：デフォルトの名無しさん：2013/10/03(木) 02:45:50.82

641 ：デフォルトの名無しさん：2013/10/03(木) 02:49:19.17

まずリポジトリってのはgitは分散型だから
”ローカル”に有るんだよね。

642 ：デフォルトの名無しさん：2013/10/03(木) 03:03:33.54

RCSとSCCSが無い

643 ：デフォルトの名無しさん：2013/10/03(木) 03:04:35.61

ハードゲイ

644 ：デフォルトの名無しさん：2013/10/03(木) 04:10:01.57

頻繁に使う機能にオプション2個指定が必要とか

645 ：デフォルトの名無しさん：2013/10/03(木) 04:25:04.52

なぜ違うものを比べようとするのか。

646 ：デフォルトの名無しさん：2013/10/03(木) 04:34:15.12

必要に応じて何でも覚えていけばいいさ

647 ：デフォルトの名無しさん：2013/10/03(木) 05:11:13.45

物覚えが悪くなった
あとせっかく覚えても
すぐ忘れるようになった

648 ：デフォルトの名無しさん：2013/10/03(木) 05:43:21.83

>>644
具体的に何のコマンドの何のオプションですか？

649 ：デフォルトの名無しさん：2013/10/03(木) 09:28:01.72

・checkoutにbranchの切り替えとファイルの取り出し(上書き確認も無し)の2つの用途がある
・gitのrevertとcvs/svn/hg/bzrのrevertは全く意味が違う
・git独特のstaging
hgも使い込むとrecord,mqに手を出すだろうからstagingは擁護できるが上2つはちょっとね
今更変えられないだろうけど

650 ：デフォルトの名無しさん：2013/10/03(木) 09:30:39.20

checkoutは有名だとして、他にはbranchとかかね。
引数無し→全ブランチの表示
引数1個→現在のブランチから引数で指定した名前のブランチの作成
引数2個→2つ目に指定したブランチから1つ目に指定したブランチの作成
引数1個+mオプション→現在のブランチの名前を引数で指定した名前に変更
引数2個+mオプション→1つ目に指定したブランチの名前を2つ目に指定した名前に変更
引数1個以上+dオプション→指定したすべてのブランチを削除

あと、diffはよくワーキングディレクトリとHEADの指定を間違うな。差分が出なくて、あれ？って思うことが多い。

651 ：デフォルトの名無しさん：2013/10/03(木) 09:50:49.69

結局checkoutだけなんだな

stagingもrevertも単にgit側の仕様が気に喰わんって言ってるだけじゃないか

branchはcreate-branchとかmv-branchとかdelete-branchとか作れってことか？
そんなのはメンドクサイだけなんで勘弁してほしい

diffは具体的にどうしろと？
いまのHEAD、index、workの構造に忠実な指定方法よりいいのがあるのか？

652 ：デフォルトの名無しさん：2013/10/03(木) 09:52:59.05

頻繁に使う機能にオプション2個指定が必要な例はどうなった？

653 ：デフォルトの名無しさん：2013/10/03(木) 10:33:35.36

とりあえずバージョン管理はgitからはじめてるんですけど
他にも有名なバージョン管理システムにsvnとかhgがあるじゃないですか
gitを覚えれば他の2つも簡単に覚えられますか？

654 ：デフォルトの名無しさん：2013/10/03(木) 10:41:45.11

覚えられません。

655 ：デフォルトの名無しさん：2013/10/03(木) 10:59:36.99

むしろgitは最後にした方がいい

656 ：デフォルトの名無しさん：2013/10/03(木) 11:08:54.50

branchは別にサブコマンドでいいけど、stashやtagと微妙に統一されてないのはなんとかしてほしい

657 ：デフォルトの名無しさん：2013/10/03(木) 11:16:51.29

>>656
stashやtagと何を統一すればいいの？

658 ：デフォルトの名無しさん：2013/10/03(木) 11:17:15.25

gitは内部仕様がコマンド体系に中途半端に現われてしまっているのが失敗してる。
svnの「ブランチとタグはありましぇーん」と同じ失敗。

659 ：デフォルトの名無しさん：2013/10/03(木) 11:20:01.64

>>657
オプション。git branch(オプション無し)、git stash list、git tag --listみたいな。

660 ：デフォルトの名無しさん：2013/10/03(木) 11:20:13.06

ブランチだろうがタグだろうがコミットだろうが全部hashで指定できるのがすごく気に入ってる

661 ：デフォルトの名無しさん：2013/10/03(木) 11:26:01.92

>>659
git branch --list は使えますよ
git stash の次はコマンドで統一されてるんで --list とかにされても困ります

662 ：デフォルトの名無しさん：2013/10/03(木) 11:30:50.73

>>661
そもそも
>git stash の次はコマンドで統一されてるんで
がtagもstashもそうなってなかったり、オプション無しの動作がバラバラだったりするのは気にならんのかね？

663 ：デフォルトの名無しさん：2013/10/03(木) 11:50:15.75

>>662
オプション無しの動作は統一されるより良く使われる機能が割り当てられるべきだとおもうけど？

一部コマンドが2段階になってるのも、
無理に1段階にして妙な名前になったり妙なオプション指定することになるよりはいいかな

そんなことが気になるようだと、一般的なUnixコマンドの中に
hg xxx とか git xxxみたいな二段階コマンドが紛れ込んでるのも気になるの？

664 ：デフォルトの名無しさん：2013/10/03(木) 11:56:50.65

なんでgitは最後のほうがいいんですか？
やっぱりnoobお断りな
プログラミング言語で言えばパソコン初心者がいきなりC++を覚えるとか
小学生がいきなり東大入試受けるぐらいの最難関なソフトウェアなのですか？

665 ：デフォルトの名無しさん：2013/10/03(木) 12:18:33.83

>>663
ちげー。
git stashがサブコマンド的記法をするならgit tagも-mや-rじゃなくてgit tag mvやrmでいいだろって話だ

666 ：デフォルトの名無しさん：2013/10/03(木) 12:29:18.26

>>665
それをやっちまったら使いにくいだろう
gitやhgも他のUnixコマンドに合わせて
サブコマンド指定なんてやめて全部オプションでやれって言ってるようなもんだ

667 ：デフォルトの名無しさん：2013/10/03(木) 12:40:43.18

普通のコマンドはサブコマンド指定なんか無しでオプション指定だけの方がいいね
でもgitやhgみたいな複雑なコマンドは、オプションよりもサブコマンドにしたほうがいいね

普通のサブコマンドは2段階のサブコマンド指定なんか無しでオプション指定だけのほうがいいね
でもgit stashやgit bundleみたいな複雑なサブコマンドは、オプションよりも2段階のサブコマンドのほうがいいね

668 ：デフォルトの名無しさん：2013/10/03(木) 12:55:36.79

なんつう一貫性のなさ。
tagもstashもbranchも、中に作成、リネーム、削除、一覧などを内包してるという意味では揃えるべき。
>>667の論で言うならbundleなんかオプションでいい

669 ：デフォルトの名無しさん：2013/10/03(木) 13:09:09.41

stashやbundleのサブコマンドを適当にオプションなんかに割り振られたら泣くわｗ
やたら一貫性を重視するやつのUIは使いにくくてかなわん

670 ：デフォルトの名無しさん：2013/10/03(木) 13:12:18.92

全部をサブサブコマンド化は勘弁だし
全部をサブコマンド+オプションにするのもサブコマンドが増えてくるとオプションのパターンが増えすぎだと思うし

昔から存在するよく使われるコマンドはサブコマンド+オプションで、
あとから追加された新しい概念のコマンドはサブサブコマンドみたいな感じなのは、わりと妥当だと思うけどね

671 ：デフォルトの名無しさん：2013/10/03(木) 13:28:10.86

git branch -D ブランチ名
git branch -d ブランチ名
git branch ブランチ名
git branch
git stash save
git stash list
git stash apply

branchとstashでよく使うのはこの辺か
branchが2段階コマンドになったら面倒そうだし、
stashが-sとか-aとか--listになったら使いにくそうだな・・・
どっちかに揃えるとか却下だな

672 ：デフォルトの名無しさん：2013/10/03(木) 14:33:01.22

まあ、要するに直感的を目指すと一貫性を追求することになって冗長かつ使いにくくなるんだよ
だからgitには慣れるしかない

673 ：デフォルトの名無しさん：2013/10/03(木) 14:52:05.89

冗長で結構
使いやすさに関しては好きにエイリアス作ればええねん
git brd (git branch -D) とか
git std (git stash drop) とか

674 ：デフォルトの名無しさん：2013/10/03(木) 15:01:59.39

慣れれば良いだけならどっちでも良いだろ

675 ：デフォルトの名無しさん：2013/10/03(木) 15:27:14.37

AndroidとiPhoneの2つのスマートフォンを使っていますという感じか。
どっちももはやスマートフォンってレベルじゃねーよというｗ

676 ：デフォルトの名無しさん：2013/10/03(木) 15:35:45.39

スレが超加速しててワロタ

677 ：デフォルトの名無しさん：2013/10/03(木) 16:22:09.47

>>664
gitの良さを味わっちゃったら他のクソCVSにはもう触りたくない
そんな話でしょ

678 ：デフォルトの名無しさん：2013/10/03(木) 16:24:00.55

またgit信者が来たか・・・
お互いの利点を確認できるって意味だろ
gitしか知らない奴はホント屑ばっかだな

679 ：デフォルトの名無しさん：2013/10/03(木) 16:26:48.07

個人でCVSを使う分には好きなのを選べばいいし
他人のプロジェクトに参加したいんならそこの流儀に合わせればいい
何の議論の余地もない

680 ：デフォルトの名無しさん：2013/10/03(木) 16:27:19.41

CVS?

681 ：デフォルトの名無しさん：2013/10/03(木) 16:37:18.46

>>680
Version Control SystemのVCSのつもりでした　恥ずかしい

>>678
はい、煽りに対して煽りを書いた屑です。サーセン

682 ：デフォルトの名無しさん：2013/10/03(木) 16:57:50.79

ttp://gitolite.com/gcs/index.html

683 ：デフォルトの名無しさん：2013/10/03(木) 17:46:28.94

cvsでできてgitではできないことって結構多いからな
その機能を必要としていた人にはちょっとつらい

684 ：デフォルトの名無しさん：2013/10/03(木) 17:48:47.56

たとえば？

685 ：デフォルトの名無しさん：2013/10/03(木) 17:50:51.07

その機能の必要性は？(ﾆﾔｧ

686 ：デフォルトの名無しさん：2013/10/03(木) 17:52:19.87

今日のお祭り会場はこちらですか？

687 ：デフォルトの名無しさん：2013/10/03(木) 19:13:08.80

svnからの移行が自然なのはhg
gitは何でもやろうとして何がなんだか分からなくなる

688 ：デフォルトの名無しさん：2013/10/03(木) 19:24:24.27

つまり、githubはオワコン？

689 ：デフォルトの名無しさん：2013/10/03(木) 19:30:56.97

>>683
任意のmodule単位のcheckoutは便利だな。それを想定して作ったリポジトリは未だにcvsで運用してる。
多いとは思わないけど。

690 ：デフォルトの名無しさん：2013/10/03(木) 21:54:06.23

・スペース区切りの順番で混乱することがあるので、hgみたいに-rオプションでコミット指定できたらいいと思う
　git log branch filename
　git grep pattern branch
・git show branch:filename に対して git blame branch filename という統一性のなさ
・標準入出力 git bundle create - branch はOKで git bundle unbundle - は不可能というのも不思議

691 ：デフォルトの名無しさん：2013/10/03(木) 22:03:49.67

https://code.google.com/p/git-core/downloads/list
git　1.8.4.1

692 ：デフォルトの名無しさん：2013/10/03(木) 22:26:08.52

C言語とJavaと違うからって文句言うのか！gitとcvsが違うからって文句言うわがままな奴は

693 ：デフォルトの名無しさん：2013/10/03(木) 22:42:19.78

すいません！
前回commitしたファイルを全部知りたいんですがどうやって調べるのか教えてください

694 ：デフォルトの名無しさん：2013/10/03(木) 22:52:21.16

こう？
git log --stat

695 ：デフォルトの名無しさん：2013/10/03(木) 23:03:40.18

git log --name-stat HEAD~1..HEAD

696 ：デフォルトの名無しさん：2013/10/03(木) 23:30:15.65

>>694-695
たすかりました！

697 ：デフォルトの名無しさん：2013/10/04(金) 11:05:23.93

Rubyにgollumっていうwikiエンジンがあるじゃないですか
あれはgitにコミットするとデータが反映するそうなんですが
どうやって最新の内容を取得しているのでしょうか？

698 ：デフォルトの名無しさん：2013/10/04(金) 11:08:59.92

ソース嫁

699 ：デフォルトの名無しさん：2013/10/04(金) 11:41:58.92

リポジトリへのコミット時にリポジトリからデータ取り込むスクリプト起動？とか想像したが
こいつはHTTPアクセス時にリポジトリから直接データ取って来てページ作ってんのかな

700 ：デフォルトの名無しさん：2013/10/05(土) 13:47:01.95

github、RubyとMVCの限界を悟りC#とMVVMに全面移行　／　オープンソース界に激震
http://engawa.2ch.net/test/read.cgi/poverty/1380941226/

701 ：デフォルトの名無しさん：2013/10/05(土) 13:52:53.27

ビックウェーブきたなｗｗｗ

702 ：デフォルトの名無しさん：2013/10/05(土) 16:36:44.30

twitterもRuby使うのやめたって言ってたし
Rbyってそんな使えないんか

703 ：デフォルトの名無しさん：2013/10/05(土) 16:37:59.12

日本人は役立たずってことか

704 ：デフォルトの名無しさん：2013/10/05(土) 16:46:35.63

GitHubやってる？
http://kohada.2ch.net/test/read.cgi/prog/1363523309/

705 ：デフォルトの名無しさん：2013/10/05(土) 17:52:43.51

>>702
立ち上げには良いけど、長期的にメンテし続けるには向かないってことでしょ

706 ：デフォルトの名無しさん：2013/10/05(土) 23:17:18.40

処理系として気が効いてる分、負荷は高い。
rubyでさっさと立ち上げて、アクセス集中して負荷に耐えられないくらいになれば
大成功ってわけで。

まあ、実際はそのままぽしゃるプロジェクトが大量に存在してるんだけどな。

707 ：デフォルトの名無しさん：2013/10/05(土) 23:25:47.85

railsってそんなに生産性高いの？

708 ：デフォルトの名無しさん：2013/10/05(土) 23:38:17.57

全面移行とかデマじゃないか

709 ：デフォルトの名無しさん：2013/10/05(土) 23:53:35.57

>>707
素のRubyに比べたら
そうとう生産性高いよ。

他のフレームワークと比べたら
同じぐらいだけど。

710 ：デフォルトの名無しさん：2013/10/07(月) 03:26:42.80

>>705
railsは立ち上げはもちろん長期的にメンテし続けるのにもそんな悪くないよ
問題はサービスの規模が大きくなるのに合わせて拡張しようとするとき、
主にコスト的な面でより効率的な選択肢が他にいろいろあるというだけ

711 ：デフォルトの名無しさん：2013/10/07(月) 12:35:54.01

>>710
railsというかrubyの問題だけど長期間メンテナンスしてるとinstance_ofだらけになる。

712 ：デフォルトの名無しさん：2013/10/08(火) 00:40:20.10

railsはやっぱり覚えるべきか・・・

713 ：デフォルトの名無しさん：2013/10/08(火) 09:37:27.60

しかしC#だとmono必須か、、環境によってはRailsより入れにくい

714 ：デフォルトの名無しさん：2013/10/08(火) 09:40:35.16

C#やるならどうせwin鯖だろ

715 ：デフォルトの名無しさん：2013/10/08(火) 09:46:28.75

githubがC#使うとか言ってるのはクライアントの話だから鯖とか関係ない

716 ：デフォルトの名無しさん：2013/10/08(火) 09:51:16.29

今までクライアントにRuby使ってたのか

717 ：デフォルトの名無しさん：2013/10/08(火) 09:53:26.81

クライアントとサーバーのコードを共通化出来るに越したことないから、そのうちサーバーサイドもc#になるかもね
mono使ってるんだから、サーバーはそのままunixサーバーでいいわけだし

718 ：デフォルトの名無しさん：2013/10/08(火) 10:24:47.74

>>716
いままではC++とかJavaとかかな

719 ：デフォルトの名無しさん：2013/10/08(火) 11:16:06.91

つまりmsysgitっていうのをインストールするとき.NETフレームワークがないと使えないってことですか？

720 ：デフォルトの名無しさん：2013/10/08(火) 11:24:04.94

Gitに関係ないから>>704でやれ

721 ：デフォルトの名無しさん：2013/10/08(火) 12:26:45.32

>>720はgithubスレを立てた>>1

722 ：720：2013/10/08(火) 13:43:10.99

>>721
https://github.com/hub2ch/hub2ch
こんな恥ずかしいやつと一緒にするなｗ

723 ：デフォルトの名無しさん：2013/10/08(火) 13:46:34.06

forkボタン押すとforkした連中が見られるのな

724 ：デフォルトの名無しさん：2013/10/08(火) 16:28:12.37

najeira: Gitの運用ルール、ワークフローを考えてみた 2
http://najeira.blogspot.jp/2013/04/git-2.html

これってどうなん？妥当な方法なん？

725 ：デフォルトの名無しさん：2013/10/08(火) 19:29:15.12

うんこ

726 ：デフォルトの名無しさん：2013/10/08(火) 23:40:47.47

指定した二つのコミットの間で変更、追加、削除したファイルの一覧を表示する方法は？

727 ：デフォルトの名無しさん：2013/10/09(水) 00:13:07.35

git logを自分好みでguiに表示したいんですけど
apiみたいなのってないんですか？

728 ：デフォルトの名無しさん：2013/10/09(水) 01:14:06.53

git logに--formatオプション食わせれば好きなフォーマットでデータ吐いてくれる

729 ：デフォルトの名無しさん：2013/10/09(水) 02:59:26.76

>>726
こう？
git diff --name-stat commit1..commit2

730 ：デフォルトの名無しさん：2013/10/09(水) 09:46:15.04

git log --format=jsonとかxmlとかcsvってやってみたけどデータとれなかった
嘘を教えられたのだ！

731 ：デフォルトの名無しさん：2013/10/09(水) 09:54:14.20

>>730
man読めよ。

732 ：デフォルトの名無しさん：2013/10/09(水) 10:14:36.95

>>730
ほんまもんのアホがいる

733 ：デフォルトの名無しさん：2013/10/09(水) 10:59:34.25

非分散型のgitって無い？

734 ：デフォルトの名無しさん：2013/10/09(水) 11:02:21.67

>>733
svnとか使えばいいだろ

735 ：デフォルトの名無しさん：2013/10/09(水) 12:11:51.81

svnはあの開発陣のCVSヘイトっぷりが怖くてキモくて嫌だった

736 ：デフォルトの名無しさん：2013/10/09(水) 12:16:11.60

>>735
ならCVS使っとけ
というかというかこっちのスレに行け

バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/

非分散型が目当てならgitには全く関係無い

737 ：デフォルトの名無しさん：2013/10/09(水) 12:29:15.77

分散型でも一点のみで使ったら事実上は非分散では？

738 ：デフォルトの名無しさん：2013/10/09(水) 12:43:44.47

gitはローカルリポジトリだけだと一人でしか使えないじゃん

739 ：デフォルトの名無しさん：2013/10/09(水) 13:44:08.60

>>733
非分散(集中？)な時点でgit のメリットの8割を失ってね？

740 ：デフォルトの名無しさん：2013/10/09(水) 16:11:11.59

そうか
開発中はgitで自由に開発して、リリースの段階になったら
svnにコミットすればいいのか。

これですべての問題が解決しそうだぞ。検討してみる

741 ：デフォルトの名無しさん：2013/10/09(水) 17:08:47.75

それなら中央もgitでいいじゃん

742 ：デフォルトの名無しさん：2013/10/09(水) 17:20:03.03

中央までgitにしたら困らない？大丈夫？

743 ：デフォルトの名無しさん：2013/10/09(水) 17:26:52.31

サーバがsvnのときとgitのときで大きく違うのはリポジトリ作成と公開の部分だよね

744 ：デフォルトの名無しさん：2013/10/09(水) 18:07:35.30

複数人で使うときに使うコマンドを全部おしえて

745 ：デフォルトの名無しさん：2013/10/09(水) 18:13:02.62

>>744
流石に全部となると、git入門とかでググったほうがいいんじゃね

746 ：デフォルトの名無しさん：2013/10/09(水) 19:25:45.68

>>742
何が困るんだ？

747 ：デフォルトの名無しさん：2013/10/09(水) 22:42:54.73

>>740
オールgitに比べて、中央svnローカルgitにする利点ってなんだ？
中央svnローカルgitは分散管理のままなのは理解してるかな？

748 ：デフォルトの名無しさん：2013/10/09(水) 23:01:38.55

オールgit・・・gitだけを覚えれば良い
git+svn・・・gitとsvn、そしてgitとsvnの連携の三つを覚えないといけない。

たとえsvnの経験者であったとしても
git+svnは、svnを忘れてgitだけを覚えればいいのと違い
gitとsvnの連携という、余計なことを覚えないといけない。

749 ：デフォルトの名無しさん：2013/10/09(水) 23:22:06.54

非分散管理希望とか言っといて
svn+gitで問題解決とかわけがわからんなｗ

750 ：デフォルトの名無しさん：2013/10/10(木) 00:00:56.81

今Gitサーバをインストールするなら何がお勧め？
数人程度の単一プロジェクトで

751 ：デフォルトの名無しさん：2013/10/10(木) 00:17:49.15

Gitを入れるのがいいんじゃないかな？

752 ：デフォルトの名無しさん：2013/10/10(木) 00:34:04.52

>>750
gitlabお勧め

753 ：デフォルトの名無しさん：2013/10/10(木) 00:37:06.29

その数人がUnixアカウントやssh使うのに抵抗が無ければ、
特別なものを入れる必要もないけどねえ

754 ：デフォルトの名無しさん：2013/10/10(木) 00:46:07.25

>>753
じゃあ聞くが、中央リポジトリどうやってんの？
そこにコミットされたものの把握とかどうやってんの？
コミットされたコードに対するコメントやレビューどうやってんの？
複数人で共有しているリポジトリの管理どうやってんの？
masterへのマージどうやってんの？
不正（質の悪い）コードのマージをどうやって管理してるの？

人が数人集まるってことは、
コミュニケーションが生まれるってこと。
gitだけでどうやってコミュニケーションするの？

755 ：デフォルトの名無しさん：2013/10/10(木) 00:58:44.32

＞中央リポジトリどうやってんの？
＞そこにコミットされたものの把握とかどうやってんの？
＞ masterへのマージどうやってんの？
このへんは別に特別なものはいらんな
UNIXアカウント+sshだけでおｋ

＞複数人で共有しているリポジトリの管理どうやってんの？
リポジトリの管理って具体的に何？

＞不正（質の悪い）コードのマージをどうやって管理してるの？
＞コミットされたコードに対するコメントやレビューどうやってんの？
＞人が数人集まるってことは、
＞コミュニケーションが生まれるってこと。
＞ gitだけでどうやってコミュニケーションするの？

Gitはバージョン管理ツールであって、
コミュニケーションツールではありません

756 ：デフォルトの名無しさん：2013/10/10(木) 01:06:18.13

例えばこんな場合。

ローカルだけで開発していたら他人の進捗状況がわからない。
だから中央リポジトリは必要。

中央リポジトリにあるものをだれでも勝手に
消したりできたらまずいから権限の概念が必要になる。

ただし管理者のみが中央リポジトリを作成できるなら
中央リポジトリを作るために管理者にお伺いを建てないといけなくなる
これは良くない。

理想は誰でも中央リポジトリをサクッと作れて、
権限がある人だけが消したりできる。
プロジェクトに参加者を登録して、参加者に
閲覧専用権限を与えたり、コミット権限を与えたりしたい。
コミットに関するコメントを付けたい。
それらを自動的にメールで通知したい。

ということで、gitだけではできないことを行うために
サーバーが必要になる。

757 ：デフォルトの名無しさん：2013/10/10(木) 01:08:13.41

>>755
> Gitはバージョン管理ツールであって、
> コミュニケーションツールではありません

だから、git以外のgitサーバーを使うって話になるんだろ？
こっちは最初からgitではない物＝特別なものを入れるって話をしてるんだが？

お前は、git以外に入れる必要はない＝gitでコミュニケーションも
できるっていいたいんだろう？

758 ：デフォルトの名無しさん：2013/10/10(木) 01:10:58.32

なんで「Gitサーバをインストールする」が
コミュニケーションツールを導入するまで飛躍するんだよｗアホかｗ

759 ：デフォルトの名無しさん：2013/10/10(木) 01:17:40.34

>>758
Gitサーバーに役目にコミュニケーションツールまで含まれるからだよ。

Gitサーバーがどんな機能を持っているのか調べなさい。

http://git-scm.com/book/ja/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC

http://git-scm.com/book/ja/Git-サーバー-GitWeb
http://git-scm.com/book/ja/Git-サーバー-Gitosis
http://git-scm.com/book/ja/Git-サーバー-Gitolite

http://git-scm.com/book/ja/Git-サーバー-Git-のホスティング
GitHub

760 ：デフォルトの名無しさん：2013/10/10(木) 01:19:27.65

>>756
誰でも中央リポジトリを作れるのと権限がある人だけが消せるを両立させるのは難しいかな
閲覧専用権限もちょっと難しい
でも質問の「数人程度の単一プロジェクト」ならこんなのいらんだろ

＞コミットに関するコメントを付けたい。
＞自動的にメールで通知したい。
全部メールでやればいい

それ以外はUNIXアカウント+ssh+gitだけでできるから

761 ：デフォルトの名無しさん：2013/10/10(木) 01:20:59.61

>>760
いるかいらんかは
お前が決めるな。

762 ：デフォルトの名無しさん：2013/10/10(木) 01:24:16.33

>>759
そこで述べてるGitサーバの主要な機能はUNIXアカウント+ssh+gitで実現可能
http://git-scm.com/book/ja/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC

4.6からのオプショナルな機能を実現するために
他のものをインストールする必要があるわけ

763 ：デフォルトの名無しさん：2013/10/10(木) 01:25:18.79

>>761
いるかいらんをお前も決めるな
おれはできると可能性を述べているにすぎないぞ

764 ：デフォルトの名無しさん：2013/10/10(木) 01:25:32.88

単一プロジェクトでも
自分用ツールを皆と共有するために
リポジトリ作りたくなるし、
gitサーバーがあったほうが柔軟で便利だろ。

メール？送信するのが面倒だろ。
どうやって掲示板のやりとりみたいなものを
数人でメールでやるんだ？

できるのと、簡単に便利にできるのとでは
わけが違う。

入れないほうがいいという理由がない。

765 ：デフォルトの名無しさん：2013/10/10(木) 01:27:50.27

>>762
実現可能かどうかは論点じゃないんだよ。

実現可能かどうかで言えば
ソースコード管理もディレクトリコピーで実現可能。

そういうことじゃないだろ？
どれだけ簡単にできるかが重要なんだよ。

頑張ってgitサーバー相当のことが出来るようになりました！
は意味が無い。最初からgitサーバー使えばいいと言われて終わり。

766 ：デフォルトの名無しさん：2013/10/10(木) 01:28:35.11

>>764
自分用ツールを皆と共有するためにリポジトリ作る用途なら
UNIXアカウント+ssh+git で全然問題無いです

767 ：デフォルトの名無しさん：2013/10/10(木) 01:30:58.82

>766
UNIXアカウントが必要な時点で問題ありだろ。
お前のコードにアクセスするために、
お前のマシンに俺のアカウントを作らなければならないということだ。

768 ：デフォルトの名無しさん：2013/10/10(木) 01:32:19.88

>>765
全然頑張る必要とかないよ？
gitアカウント作ってユーザーをgitアカウントと同じグループに所属させておく
gitアカウントで適当なディクレトリ作って
chmod g+rws ディクレトリ; cd ディクレトリ; git init --bara --shared

この程度で「ssh://UNIXマシンのホスト/ディクレトリ」でアクセスできる中央リポジトリが完成

denyNonFastforwardとdenyDeletes辺りを設定しておけば、
コミットを「消す」ことはできなくなるから致命的な悪さをされる心配も無い

769 ：デフォルトの名無しさん：2013/10/10(木) 01:32:39.97

なんでもExcelでやろうとする奴と
同じ臭いを感じるなｗ

770 ：デフォルトの名無しさん：2013/10/10(木) 01:34:09.87

>>767
中央リポジトリをつくるマシンにアカウント作るだけです

771 ：デフォルトの名無しさん：2013/10/10(木) 01:35:08.83

>>768
それをユーザー全員がやらないといけないよね。

gitサーバーがあれば、そういう面倒な作業なしに
バンバン共有リポジトリ作れるし、
もっと複雑な権限管理もできるし、
ダッシュボードから今何が起きているかを把握できるし
その上コミュニケーションツールまでついてくる。

超便利なツール VS 頑張れば同じことが出来る。あれしてこれして・・・

ご苦労さんｗ

772 ：デフォルトの名無しさん：2013/10/10(木) 01:36:32.68

>>770
じゃあ、次にプロジェクトを複数作って、
プロジェクトごとに参加者が違います。

同じユーザーでもプロジェクトが違えば
見れたり見れなかったり書き込み権限があったりなかったりします。

ってときはどうするの？

773 ：デフォルトの名無しさん：2013/10/10(木) 01:36:47.33

>>771
いや、これをやるのは中央リポジトリをつくる人だけ

774 ：デフォルトの名無しさん：2013/10/10(木) 01:37:52.99

>>772
だから単一プロジェクトでの話をしてるんだろ？
参加者が違うプロジェクトをつくるならグループを追加すればいいよ

775 ：デフォルトの名無しさん：2013/10/10(木) 01:39:36.45

>>773
「中央リポジトリを作る人」がいるってのが
そもそも問題。権力者ってのはなるべく排除するべき。

共有の中央リポジトリであれば
管理者一人でもいいが、
個人が中央リポジトリを作りたい場合もある。

個人が作った中央リポジトリは、
管理者を除いて、個人のみが管理できる。
その個人が許せば、他のユーザーにも閲覧権限や
管理言言を与えることも可能。

開発をしていればこういうことはやりたいと思うのが普通。

776 ：デフォルトの名無しさん：2013/10/10(木) 01:39:41.74

>>769
逆だな
サーバ必須とかのやつからExcel使いと同じ臭いを感じる
もっと臨機応変にやってくれよ

777 ：デフォルトの名無しさん：2013/10/10(木) 01:41:35.87

>>774
単一プロジェクトと言われたからといって、
本当に単一プロジェクトでしか通用しないテクニックを
だすのは愚か。

> 参加者が違うプロジェクトをつくるならグループを追加すればいいよ
で、閲覧権限と書き込み権限はどうするの？
人によって権限を与えたり与えなかったりしたいんだよね。

778 ：デフォルトの名無しさん：2013/10/10(木) 01:42:32.80

>>776
あのー？
最初からおすすめのgitサーバーの話をしてるんですが？

お前、柔軟性ないね。
素直にgitサーバーの話をスレばいいじゃんか。

もしかして、知らないの？って思われるよっていうか思ってるｗ

779 ：デフォルトの名無しさん：2013/10/10(木) 01:43:12.29

>>777
閲覧専用権限は難しいと言ってるだろ
書き込み権限はグループに追加するユーザで制御できる

780 ：デフォルトの名無しさん：2013/10/10(木) 01:44:45.41

>>778
だから、おれとしては、その程度の規模でUNIXアカウント+sshの使用に抵抗が無いならという条件で、
UNIXアカウント+ssh+gitをオススメしてるんだよ
お前が別のものをオススメするのは勝手だ

781 ：デフォルトの名無しさん：2013/10/10(木) 01:44:51.07

>>779
難しいならだめじゃんか。

なんで、githubのように
優れたツールがあるのに
それを使わないの？

gitサーバーを使いたくないって話をしてるんじゃないんだよ。
gitサーバーを使いたい。おすすめは？って話をしてるんだよ。

782 ：デフォルトの名無しさん：2013/10/10(木) 01:45:27.95

>>778
サーバ立てなきゃ絶対ダメとかのどこが柔軟性なんだよ

783 ：デフォルトの名無しさん：2013/10/10(木) 01:45:52.20

>>780
だから俺は、お前のおすすめは
おすすめじゃないって話をしてるんだよ。

だってコミュニケーションツールもついてないじゃん。

784 ：デフォルトの名無しさん：2013/10/10(木) 01:46:25.97

>>781
それが必要ないなら問題ないだろ
選ぶのは質問者だ

785 ：デフォルトの名無しさん：2013/10/10(木) 01:46:36.37

>>782
サーバーを建てないという条件で
頑張るお前よりはよっぽど柔軟。

どっちが選択肢が多いかね？

786 ：デフォルトの名無しさん：2013/10/10(木) 01:49:01.06

>>784
質問者は既にgitサーバーを選んでいる。
今の質問はどのgitサーバーがオススメかだ。

787 ：デフォルトの名無しさん：2013/10/10(木) 01:49:25.04

>>783
俺のおすすめは、お前にとってはおすすめじゃないだけだろ
俺のおすすめは変わらんよ
どういうものなのか説明はした
実際おれは数人程度でリポジトリを共有する目的でコレを使ってる
選ぶのは質問者

788 ：デフォルトの名無しさん：2013/10/10(木) 01:51:07.18

>>787
質問がどのgitサーバーがオススメか？である以上
gitサーバーを答えなければならない。
お前の答えは、質問に答えていない。
論外なんだよ。

789 ：デフォルトの名無しさん：2013/10/10(木) 01:52:02.01

なんかよくわからんけどこえーよ

790 ：デフォルトの名無しさん：2013/10/10(木) 01:56:53.63

>>785-786 >>788
いやまてよ専用サーバーが動いてないだけで
UNIXアカウント+ssh+gitだけで
gitサーバーとして機能するぞ？

gitサーバが何なのか理解できてない？
お前らが挙げた
http://git-scm.com/book/ja/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC
を自分でよく読めよ？
gitサーバーの主要な機能はpushとpullができることだ

791 ：デフォルトの名無しさん：2013/10/10(木) 02:20:22.66

IDないからだれがだれだかわからなくてめんどくせーなおい

792 ：デフォルトの名無しさん：2013/10/10(木) 02:24:32.80

まあ>>790のURLを読めばよい
そこは両者オススメみたいだし

793 ：デフォルトの名無しさん：2013/10/10(木) 02:27:00.73

Gitって循環参照とか出来るの？
コンピューターA
↑参照
コンピューターB
↑参照
コンピューターC
↑参照
コンピューターA

こんな風にしたらどうなる？

794 ：デフォルトの名無しさん：2013/10/10(木) 02:27:29.33

>>775
開発したことがあるならなおさら中央リポジトリの重要性を痛感するはず

795 ：デフォルトの名無しさん：2013/10/10(木) 02:30:29.98

>>793
コンピューターっていうのは特定マシンのリポジトリの意味かな？

796 ：デフォルトの名無しさん：2013/10/10(木) 03:27:48.98

git checkout hoge
git merge master
git checkout foo
git merge hoge
git checkout bar
git merge foo
git checkout master
git merge bar

797 ：デフォルトの名無しさん：2013/10/10(木) 03:41:17.36

ブランチのことか
別に問題ないよ
ただその四つのブランチが共通の祖先のコミットをもってないと困ると思うが

798 ：デフォルトの名無しさん：2013/10/10(木) 06:30:39.80

一人で使うなら好きにしなさい
複数で使うならgitoliteにしなさい

799 ：デフォルトの名無しさん：2013/10/10(木) 08:37:35.32

>>756
その文章の中で
>gitだけではできないこと
ってどれなの？

800 ：デフォルトの名無しさん：2013/10/10(木) 09:05:57.52

何だか知らんがそんなにgitが嫌ならsvnでも使っとけバーロー

801 ：デフォルトの名無しさん：2013/10/10(木) 09:19:58.74

伸びてんなー

802 ：デフォルトの名無しさん：2013/10/10(木) 09:39:39.75

gitだとバージョン番号つけられないね

803 ：デフォルトの名無しさん：2013/10/10(木) 09:44:12.83

この伸びてるのはgit大好きな馬鹿同士じゃないか

>>802
>>531

804 ：デフォルトの名無しさん：2013/10/10(木) 09:44:52.63

タグにバージョンつけてるけど

805 ：デフォルトの名無しさん：2013/10/10(木) 10:38:21.03

>>803
おもしろそう
これを使えば$Id$がつくれるのかな

806 ：デフォルトの名無しさん：2013/10/10(木) 10:53:23.91

9月入った辺りから伸びが凄いな
ビックウェーブ来てる？

807 ：デフォルトの名無しさん：2013/10/10(木) 12:12:48.06

来てますがうちはビッグウェーブに乗るというより押し流されてますよ
開発者の人数だけグラフがスパイラルしているのはなかなかキレイです

808 ：デフォルトの名無しさん：2013/10/10(木) 14:23:39.77

空のリポジトリから作り始める時もmasterじゃなくて適当なブランチ作ってやり始めるのが筋？

809 ：デフォルトの名無しさん：2013/10/10(木) 15:07:32.38

いいえ

810 ：デフォルトの名無しさん：2013/10/10(木) 17:07:38.36

城戸君は新人Webコーダーで聞き間違えが多いタイプ
田中君は人のコードをパクル様なことをするタイプ
こういう二つのタイプの人間がいるとします
この二人にプロジェクトを任せるのですが
城戸君は聞き間違えが多いので本来Aを作るところを間違えてBを作ってコミットしました
そのあと田中君はググって見つけたブログのコードを自分の担当のBにコピペしてコミットしました
こういう場合はどうしたらいいでしょうか？

811 ：デフォルトの名無しさん：2013/10/10(木) 17:15:04.85

＞ Bにコピペ
これはBを全部書き換えてしまったのかな？
それともBの一部を書き換えたのかな？

812 ：デフォルトの名無しさん：2013/10/10(木) 17:18:42.43

Bのファイルをお互いいじったところはコンフリクトして、
かぶってないところはコンフリクトしません
たぶん

813 ：デフォルトの名無しさん：2013/10/10(木) 17:22:08.09

>>810 = >>812なの？

814 ：デフォルトの名無しさん：2013/10/10(木) 17:26:56.56

>>810
マージするためにgit使ってるんだろ。

815 ：デフォルトの名無しさん：2013/10/10(木) 17:28:28.02

マージしてしまった後に、
城戸君はBをAにどうやって直すべきかって話じゃないのか？

816 ：デフォルトの名無しさん：2013/10/10(木) 17:29:23.27

城戸って珍しい名前だな
じょうど
じょうと
しろと
しろど
変換に出てこない

817 ：デフォルトの名無しさん：2013/10/10(木) 17:31:50.78

城戸＝キド

818 ：デフォルトの名無しさん：2013/10/10(木) 17:32:51.28

逆に、城戸をコピーして選択状態にして変換キーでもいいんやで

819 ：デフォルトの名無しさん：2013/10/10(木) 17:33:15.52

>>815
古いBをAにマージするだけじゃないの。

>>816
きど

820 ：デフォルトの名無しさん：2013/10/10(木) 17:46:32.58

正しいAをマージするとたぶん田中くんの修正がコンフリクトするから
それをどうするかってことかね？
コンフリクトしない場合でもやばい感じにマージされる可能性はあるかもだけど
どっちにしろ田中くんと城戸くんで相談だよね

めんどくさければ田中くんの修正がなかったように正しいAをマージしてしまって
田中君にはAに合わせて直した修正を改めてコミットしてもらえばいいかも？

821 ：デフォルトの名無しさん：2013/10/10(木) 21:57:08.65

>>810を読む限り、マージする前の話でしょ

あとは、本来出来上がってるはずのAができあがっておらず、どうしたらいいんだろうっていう問題だよ
城戸君は間違えが多い、一方の田中君はどっかから適当に拾ってくる
納期が迫っている中さあどうしよう？

822 ：デフォルトの名無しさん：2013/10/10(木) 21:59:21.08

納期のことは忘れたほうがいいよ。
理想的なやり方を追求すればいい。

納期の話を含めると、ダメなやり方が答えになるから。

823 ：デフォルトの名無しさん：2013/10/10(木) 22:00:50.81

gitがどうとかいう以前の問題のような

824 ：デフォルトの名無しさん：2013/10/10(木) 22:45:07.29

そんな使えない奴はクビで

825 ：デフォルトの名無しさん：2013/10/10(木) 23:03:10.27

マージする必要あるのか？
二人して同じもの作ったのなら、どちらかを破棄するだけだと思うのだけど。。。
たぶん、Bを破棄して、田中君がAつくるんじゃね？
昼ゴチって感じで

826 ：デフォルトの名無しさん：2013/10/10(木) 23:25:44.16

城戸君がBを revert するだけで済む話に聞こえるけどそうじゃないのかな

827 ：デフォルトの名無しさん：2013/10/10(木) 23:27:37.39

作業がなかったことになったら給料泥棒じゃん

828 ：デフォルトの名無しさん：2013/10/11(金) 00:11:06.14

給料も無くせばいいだろ

829 ：710：2013/10/11(金) 02:25:32.11

>>827
ぐだぐだのコードなら、ないほうがまだマシ。

830 ：デフォルトの名無しさん：2013/10/11(金) 06:30:51.70

まずは>>810が日本語を勉強するべき

831 ：デフォルトの名無しさん：2013/10/11(金) 23:18:50.52

.gitと同じディレクトリにsampleディレクトリがあるんですけど
このディレクトリを除外したい場合githubで.人様のgitignore見てたんですが
/sample
sample/
/sample/
って３通りに書き方を見るんですがどれが正しいでしょうか？

832 ：デフォルトの名無しさん：2013/10/11(金) 23:34:46.68

たすけてくださああああああい
これで1版最初にコミットしたところのソースコードが見たくて
git checkout ランダムな文字
ってしたんですが
git logをみたら戻った所以降のコミットのログがありません！
git reflogでランダムな文字列を表示してまた　git checkout ランダムな文字　で戻れました
こういうふうに過去のソースコードがみたくて一時的に戻したい場合はどうやるのが正しかったのでしょうか？

833 ：デフォルトの名無しさん：2013/10/12(土) 00:32:15.17

git checkout master
とかブランチ名を指定すればどこからでも戻ってこれるんでない？
あとは
git show 0123456789abcdef:path/to/filename
みたいに書けば特定のコミット時点の特定のファイルをいちいちチェックアウトせずに表示できたと思う

834 ：デフォルトの名無しさん：2013/10/12(土) 00:39:35.45

Git for WindowsのGit Bashで

$ mkdir test
$ cd test
$ git init
$ git config user.name "FOO bar"
$ git config user.email "[email protected]"
$ echo "*.exe" > .gitignore
$ git add .gitignore
$ git commit -m "initial commit"
$ git branch mybranch
$ git checkout mybranch
$ vim hello.c
$ gcc hello.c
$ git add hello.c
$ git commit -m "add hello.c"
$ ls
a.exe hello.c
$ git checkout master
$ ls
a.exe

という具合にやってみたんだけど
mybranchブランチでコンパイルして出来た a.exe がmasterブランチに移っても消えなかったんだけど
mybranchブランチで作ったファイルがmasterブランチでも参照できるのは何でなの？

835 ：デフォルトの名無しさん：2013/10/12(土) 00:46:29.27

add されてない未管理状態のファイルは何もせずに放置される

836 ：デフォルトの名無しさん：2013/10/12(土) 01:08:03.44

>>835
マジか、㌧クス
じゃあブランチは別のフォルダで作らんとダメなのか

837 ：デフォルトの名無しさん：2013/10/12(土) 01:32:43.62

>>831

/sample/ で。

838 ：デフォルトの名無しさん：2013/10/12(土) 01:48:46.77

>>836
なぜそうなるのか分からん
普通は同じフォルダでいいんじゃないの

839 ：デフォルトの名無しさん：2013/10/12(土) 02:47:20.21

別のブランチ作ってそこで作ったファイルと競合おこさないの？

840 ：デフォルトの名無しさん：2013/10/12(土) 03:07:50.93

>>839
a.exe の事だよね？

$ echo "*.exe" > .gitignore
$ git add .gitignore
$ git commit -m "initial commit"

ここで何してるの

841 ：デフォルトの名無しさん：2013/10/12(土) 03:19:17.49

つまり、競合おこしたくないファイルはバイナリだろうとバージョン管理に入れろってこと？
わかった、そうする

842 ：デフォルトの名無しさん：2013/10/12(土) 06:21:36.68

普通、make cleanとかするだろ。

843 ：デフォルトの名無しさん：2013/10/12(土) 11:28:32.72

権限を750に設定したいphpとhtmlの環境をgitで管理するのってどうすればいいですか？

テストサーバのリポジトリ---gitリポジトリ---本サーバのリポジトリ
みたいな環境で、テストサーバで750でファイルを作成して、コミット、プッシュする
そして、本サーバでプルしたら、別ユーザにも実行権限が付いてしまう

直接、実行環境にプルできたら楽でいいなって思ったんですが
デプロイ用のスクリプト作って、プルした環境からサーバの実行環境に入れなきゃだめ？

844 ：デフォルトの名無しさん：2013/10/12(土) 12:22:10.58

>>843
gitはユーザを区別しない実行可能フラグしか管理しないからデフォルトでは無理じゃないかと
post-receiveフックを使えばpullのときに任意のスクリプト走らせられるから、お望みの動作をするスクリプト書けばいいと思うよ

845 ：デフォルトの名無しさん：2013/10/12(土) 16:10:58.30

>>843
こんなやり方もある
http://stackoverflow.com/questions/10783678/git-shell-script-execute-permissions-enforced
この回答のcleanをsmudgeに変えるといいよ

Git - Git の属性
http://git-scm.com/book/ja/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%81%AE%E5%B1%9E%E6%80%A7

846 ：デフォルトの名無しさん：2013/10/12(土) 16:31:35.04

複数人で作業するときって別の人が編集するファイルを編集したらどうなりますか？

847 ：デフォルトの名無しさん：2013/10/12(土) 16:34:36.46

>>846
別の人が編集する前に編集され書き換わります。

848 ：デフォルトの名無しさん：2013/10/12(土) 21:43:34.68

git clone リポジトリのurl
ってやるとクローンで着ますが、
存在しないurlだと失敗しますよね
なので、そのリポジトリが存在するかしないか（もしくは、cloneで取得できるかできないか）をチェックするだけのコマンドってありませんか？

849 ：デフォルトの名無しさん：2013/10/12(土) 22:27:25.73

ls-remote

850 ：デフォルトの名無しさん：2013/10/12(土) 23:06:08.75

それってgitで始まるurlにも使えるの？
[email protected]:hub2ch/hub2ch.git
みたいな

851 ：デフォルトの名無しさん：2013/10/12(土) 23:11:03.56

git://github.com/～/～.git
とかのことだよね？いま試してみたらできたよ。

852 ：デフォルトの名無しさん：2013/10/13(日) 11:19:55.92

http://trac-hacks.org/wiki/GitPlugin

853 ：デフォルトの名無しさん：2013/10/13(日) 11:49:16.26

gitignoreに
/test/
って書いたのに
testディレクトリの中のファイルを編集してからgit statusってやると
modified: test/test.html
modified: test/test2.html
って表示されてしまいます！
このままaddしてcommitしたらtestディレクトリのファイルも記録されちゃいますよね！？

854 ：デフォルトの名無しさん：2013/10/13(日) 11:59:10.37

.gitignoreに
./test/
って書けよ

855 ：デフォルトの名無しさん：2013/10/13(日) 12:06:36.52

>>853
.gitignoreは既にリポジトリで管理対象になってるファイルには効かないよ
ファイルを管理対象にするまえに.gitignoreを書かないとダメ
管理対象から外したいならgit rmしてコミットすれば
その後はそのファイルをいじってもgit statusには出てこなくなる

856 ：デフォルトの名無しさん：2013/10/13(日) 12:08:03.73

>>854
それは駄目だろ

857 ：デフォルトの名無しさん：2013/10/13(日) 12:30:58.56

ちょｗｗｗｗうはｗｗｗｗ
git rm test/test.html
ってやったらファイルそのものが消えましたｗｗｗ
つられました～～～

858 ：デフォルトの名無しさん：2013/10/13(日) 12:40:26.27

>>857
おう悪い
消さずに管理対象から外すコマンドは忘れた
とりあえず消える前のがコミットされてるんだから
checkoutで復活させてくれ

859 ：デフォルトの名無しさん：2013/10/13(日) 12:44:26.17

>>857
--cached
ってか、そんな基本しらねーのかよ本１冊読めよ

860 ：デフォルトの名無しさん：2013/10/13(日) 20:55:20.82

テストファイルってgitで管理するべきですか？

861 ：デフォルトの名無しさん：2013/10/13(日) 21:11:16.71

自動テストを行うコードのことならyes

862 ：デフォルトの名無しさん：2013/10/13(日) 21:13:09.67

>>860
テストファイルが何だかわからないが、Junitとかを使ったテストプログラムのコードとかなら、ソースコードとバージョンを合わせないとだから、管理すべき。

863 ：710：2013/10/13(日) 21:33:34.46

>>862
結果はどうしてる？

864 ：デフォルトの名無しさん：2013/10/13(日) 22:06:29.98

>>863
結果という成果物が、ログ、オブジェクトに関わらずgitの管理内に入ることはない

865 ：デフォルトの名無しさん：2013/10/13(日) 22:12:46.00

テストの結果なんて「OK」と(ほか数行)しか書かれてないわけで保持するという発想はなかったな

866 ：デフォルトの名無しさん：2013/10/13(日) 22:21:58.20

failばっかりの状態からバージョン管理をはじめるなら、
OKが増えていくのを見てニヤニヤするためにバージョン管理するのは有りな気がする
いつどのテストが通るようになったかわかるし

全部OKじゃないとコミットを許さないなら、管理する価値はないでしょ

867 ：デフォルトの名無しさん：2013/10/13(日) 22:42:00.60

再生成できるものをリポジトリに入れるのは違和感があるので、指定されたコミットをチェックアウトしてビルド・テストを実行するスクリプトを作ろう
リポジトリに入れてもいい成果物は再生成が面倒or時間がかかるものという認識だ

868 ：デフォルトの名無しさん：2013/10/13(日) 22:51:06.61

このテストいつ通るようになったっけ？
で全履歴を二分木探索でテストスクリプト走らせるとなると、結構な時間がかかるはず
リポジトリに入れるのが気持ち悪いなら、git notesにでも入れときゃいいんじゃね

869 ：710：2013/10/13(日) 22:58:59.11

>>867
うちでは、出荷版とかは入れてる。
再作成しても同じバイナリにはならない環境があるからねぇ。

870 ：デフォルトの名無しさん：2013/10/13(日) 23:03:04.42

JavaだけどバイナリはVCSではなくてArtifactoryで管理している。
メインブランチと開発ブランチ、Jenkinsが自動でビルドとテストをして合格すれば
Artifactoryにプッシュする。

871 ：デフォルトの名無しさん：2013/10/13(日) 23:06:16.00

リビルドするたびに、バイナリ変わる環境なんて
メモリエラーとかハードが壊れてるだけ

872 ：デフォルトの名無しさん：2013/10/13(日) 23:07:06.50

>>870
CraftBukkitか？

873 ：710：2013/10/13(日) 23:17:17.19

>>871
ビルド日時を埋め込むシステムなんて珍しくないんだが、無知ってこんな分かりやすい餌にも食いつくんだな (w

874 ：デフォルトの名無しさん：2013/10/13(日) 23:34:21.57

珍しくないというか、PE(Windowsのexe)にもあるよね。

875 ：デフォルトの名無しさん：2013/10/13(日) 23:40:33.27

それはそういうソフトだな。
ビルドするたびに、バイナリ変わるビルドツールなんて
コンパイラとしておかしいわ

876 ：デフォルトの名無しさん：2013/10/13(日) 23:42:28.94

PGO使うとバイナリが変わるというか、変えるために使うんだよね。

877 ：710：2013/10/13(日) 23:44:51.06

>>875
> コンパイラとしておかしいわ

素人さんはそう言ってりゃいいんだろうけど...

878 ：デフォルトの名無しさん：2013/10/13(日) 23:47:53.23

いったい、どこのマイナーなツール使ってるんだかｗ

879 ：デフォルトの名無しさん：2013/10/13(日) 23:48:50.76

素人にここまで浸食されてるのってこの業界だけだよね。
大工さんと日曜大工のお父さんじゃだいぶ差があるのに。
金返せと言われても文句言えない。

880 ：710：2013/10/13(日) 23:57:10.19

>>878
自分の環境が全てと思ってる奴 ≡ 素人

881 ：デフォルトの名無しさん：2013/10/14(月) 00:00:36.33

>>880
さすがgit玄人ですね
かっこいい＾＾

882 ：デフォルトの名無しさん：2013/10/14(月) 00:08:45.33

ここで喧嘩しないでよ
>>878-879
とか単なる煽りあいでしょ。せめてgit絡めて話して

883 ：デフォルトの名無しさん：2013/10/14(月) 00:11:56.27

git commit >>710 -m '荒らしてんなボケ'

884 ：デフォルトの名無しさん：2013/10/14(月) 00:29:15.34

OSのヘッダファイルはgitで管理するべきだろうか？
ヘッダファイルが変わるとバイナリ変わっちゃうんだよね

885 ：デフォルトの名無しさん：2013/10/14(月) 00:36:31.41

>>884
ビルド環境はcloneした先で構築すりゃいい
ソース上で管理するなら、それぞれmake -fのターゲットファイルを用意する
READMEに情報かいてるのもあるかな

886 ：885：2013/10/14(月) 01:23:28.84

無視してください

887 ：デフォルトの名無しさん：2013/10/14(月) 04:23:20.47

>>863
テスト結果はcommitしない。
欲しくなったら、その版をcheckoutしてまた作ればいいから。

888 ：デフォルトの名無しさん：2013/10/14(月) 04:35:24.27

>>868
二分探索なら履歴の数はそんなに関係なさそうだから、一回のテストが遅いのかな。
そんな時間かかるのに毎回入れるとなると、commit時に時間掛かりそう。たまにしかpushしないリポジトリでのみとっとけばいいのかな。
ナイトリービルドとかの時のテスト結果を上書きしないで、とっておいたほうが良さそう。

889 ：デフォルトの名無しさん：2013/10/14(月) 04:42:27.48

テスト結果のcommitはしたことがないけれども、するにしてもCIツールからだと思うな。
開発者マシン上でのテスト結果なんて信用できないでしょ。

890 ：デフォルトの名無しさん：2013/10/14(月) 09:08:09.31

日付と時刻を付けたファイル名で毎回保存すればいいだけ

891 ：デフォルトの名無しさん：2013/10/14(月) 09:43:44.34

>>887
「そのときのテスト結果」はとっといたほうがいいぞ。
gitに入っているのが環境の全てと言い張れるほど自信ないし。

892 ：デフォルトの名無しさん：2013/10/14(月) 09:54:30.96

とっとくとしてもコミットには含めないかな
コミットIDと対応づけてどっかに保存だ

893 ：デフォルトの名無しさん：2013/10/14(月) 10:05:44.22

ID発行して、品保のハンコつきで、鍵付きロッカーに保存

894 ：デフォルトの名無しさん：2013/10/14(月) 10:11:57.68

単純に git notes を使うのではダメなのか?

895 ：デフォルトの名無しさん：2013/10/14(月) 10:27:21.19

gitで画像を管理場合、画像の比較ってどうやるの？

896 ：デフォルトの名無しさん：2013/10/14(月) 10:28:36.65

gitでaddしてcommitするとき
gitで現在のファイルの内容が記録されていくじゃないですか
この記録される内容っていうのはファイルの内容全てなのか、直前のファイルの内容からの差分なのか、どういうふうに岐路ｋうされていうのですか？

897 ：デフォルトの名無しさん：2013/10/14(月) 10:33:51.55

>>895
>>475のURLのバイナリファイルの差分

898 ：デフォルトの名無しさん：2013/10/14(月) 10:34:44.65

>>896
変更されたファイルの内容全部

899 ：デフォルトの名無しさん：2013/10/14(月) 10:36:07.07

>>896
gitの場合は、ファイルの内容丸ごと。

900 ：デフォルトの名無しさん：2013/10/14(月) 10:36:59.33

gitの場合ってことは、、、、CSVとかMがつくやつ（名前忘れた）とかSVNは違うの？

901 ：デフォルトの名無しさん：2013/10/14(月) 10:38:08.39

違うソフトだけど
出来ることは、だいたい同じ

902 ：デフォルトの名無しさん：2013/10/14(月) 10:39:22.27

昔のバージョン管理ツールは差分だけを保存してたよ

903 ：デフォルトの名無しさん：2013/10/14(月) 10:42:11.53

>>894
git notesに複数のディクレトリに格納された複数のファイルとかも添付できるん？
git logの表示の邪魔にならない？

904 ：710：2013/10/14(月) 10:42:21.11

>>892
どうせどこかに保存するなら、SCM に保存する。

905 ：デフォルトの名無しさん：2013/10/14(月) 10:44:01.58

(なんでこの人ずっとコテつけてんの)

906 ：デフォルトの名無しさん：2013/10/14(月) 10:45:28.53

差分だけ管理するタイプだといろいろ処理が増えるからダメだよな
Gitは全文保存するから賢い

907 ：デフォルトの名無しさん：2013/10/14(月) 10:46:07.31

>>904
バージョン間の差分とかチェックするときに邪魔じゃん

908 ：デフォルトの名無しさん：2013/10/14(月) 10:48:31.05

すいません、C:\site\index.htmlを１０回コミットしたんですけど
３回目にコミットしたこのファイルの内容だけを取って来て
C:\backup\index.hmlに保存するコマンドってありませんか？

909 ：デフォルトの名無しさん：2013/10/14(月) 10:48:34.46

マージしたりチェリーピックしたりパッチ作ったりするのにもいちいち邪魔だな

910 ：デフォルトの名無しさん：2013/10/14(月) 10:54:56.31

git checkout HEAD~7 -- C:\site\index.html
copy C:\site\index.html C:\backup\

911 ：710：2013/10/14(月) 10:56:59.55

>>907
え゛っ！？
マジで意味わからん。

912 ：デフォルトの名無しさん：2013/10/14(月) 11:01:20.07

>>911
二つのコミットを指定して差分をとったら、
そのコミット間のソースの差分だけが出てきて欲しい
テスト結果をコミットに含めてたらテスト結果まで全部でてくるだろう？

913 ：デフォルトの名無しさん：2013/10/14(月) 11:03:37.61

えええ、元のファイルの内容を過去のに戻さないとダメですか？

914 ：デフォルトの名無しさん：2013/10/14(月) 11:05:48.25

はい

915 ：デフォルトの名無しさん：2013/10/14(月) 11:14:42.92

そんなことはない

916 ：デフォルトの名無しさん：2013/10/14(月) 11:15:04.28

git show HEAD~7:(リポジトリ内パス)/index.html > C:\backup\index.hml
でどうだろうか
Windowsのコマンドプロンプトでgit showをリダイレクトしても改行コードは変化しなかったような気がする
(core.autocrlf=falseでLFなファイルしか書かないうちの環境のせいかもしれんが)

917 ：710：2013/10/14(月) 11:19:26.43

>>912
ソースと違う所に入れるでしょ？普通。

918 ：デフォルトの名無しさん：2013/10/14(月) 11:21:52.57

>>917
いちいち日本語がわかりにくいんだが
ソースと違うリポジトリという意味かね？それなら別にかまわないよ

919 ：710：2013/10/14(月) 11:39:51.47

>>918
はあ？
フォルダの概念ないの？

920 ：デフォルトの名無しさん：2013/10/14(月) 11:46:25.25

(だから、何でこの人ずっとコテつけてんの）

921 ：デフォルトの名無しさん：2013/10/14(月) 11:46:48.46

>>919
差分取るときテスト結果のディレクトリ以外を毎回指定するのかよ馬鹿すぎるな
マージするときはどうしてんの？Fast-Forwardじゃなければほぼコンフリクトするだろ？

922 ：デフォルトの名無しさん：2013/10/14(月) 11:50:49.00

レス乞食は無視した方がいい

923 ：デフォルトの名無しさん：2013/10/14(月) 11:51:00.70

>>891
なんか環境が足りないバグなら追加してcommitすればいいんじゃない。ある環境でしか通らないテストなら、余計に保存してそれを信じる意味ないし。

924 ：デフォルトの名無しさん：2013/10/14(月) 11:53:25.89

>>920
コテつけるのも付けないのも自由だよ。
お前が言った所で、お前の願いはかないませんｗ

925 ：デフォルトの名無しさん：2013/10/14(月) 11:55:25.79

ところでフォルダって何？
ここgitのスレだよな？

926 ：デフォルトの名無しさん：2013/10/14(月) 11:55:29.25

すいません複数人でpushするときって
masterブランチの内容をpushするべきでしょうか？

927 ：デフォルトの名無しさん：2013/10/14(月) 11:56:01.26

逃げたか

928 ：710：2013/10/14(月) 11:57:09.51

>>921
> 差分取るときテスト結果のディレクトリ以外を毎回指定するのかよ馬鹿すぎるな

おいおい大丈夫か？
テスト結果を通常のソースとかを管理しているフォルダと違うフォルダに入れるだけだろ？

929 ：デフォルトの名無しさん：2013/10/14(月) 11:58:30.22

>>920
すまん、外し忘れだわ。

930 ：デフォルトの名無しさん：2013/10/14(月) 12:01:36.32

>>928
レポジトリ直下に複数の管理対象ファイルやディレクトリを置く場合がある
それにそもそも指定が必要な手間をかけるの自体が馬鹿すぎるわ

それでマージはどうしてるの？

931 ：デフォルトの名無しさん：2013/10/14(月) 12:22:41.34

>>930
自分の知らないことは馬鹿としか言えない人なんだな、頭固いんじゃね？
あと、しきりにマージって言ってるけど、普通に考えて結果に対してマージが発生するような運用はしないと思うんだけど...

932 ：デフォルトの名無しさん：2013/10/14(月) 12:22:55.84

何をそんなにしつこいのかわからん
マージしたらどうせテストしなおしなんだから、テスト結果ファイルも作り直しでしょ
「マージ作業」をする必要がない

933 ：デフォルトの名無しさん：2013/10/14(月) 12:46:42.21

>>931-932
まじで意味がわからないんだけど？
どういうタイミングでテスト結果をコミットする運用なんだ？
マージで問題にならないってことはローカルリポジトリでテストした結果は
コミットしないようにするんだよね？

934 ：デフォルトの名無しさん：2013/10/14(月) 12:49:17.80

もしかして1人で開発してるんじゃね？ｗ

935 ：デフォルトの名無しさん：2013/10/14(月) 12:52:28.26

テスト結果もマージすりゃいいだろ？
たかがソースコードのバックアップに
何をごちゃごちゃ言ってるのか。

936 ：デフォルトの名無しさん：2013/10/14(月) 12:57:08.65

>>933
だーかーらー、テスト結果ファイルがコンフリクトしたらテストを走らせるだけでしょ
っていうかコンフリクトしなくてもテストは走らせるよね？

937 ：デフォルトの名無しさん：2013/10/14(月) 12:58:20.83

>>935
だれかがテスト結果を含めてコミットしたブランチを
自分でもテスト結果を含めてコミットしたローカルブランチにマージしたら
テスト結果なんて自動マージできないから(されても困るが)コンフリクトだろ？
そんな物の解消いちいちやってられるか

938 ：デフォルトの名無しさん：2013/10/14(月) 12:58:26.81

まーじで意味わからん

939 ：デフォルトの名無しさん：2013/10/14(月) 13:01:41.67

>>936
テスト済みであってもコンフリクトするだろ？
マージがコンフリクトで止まった状態でテスト走らせてその結果使って
コンフリクト解消操作してマージを完了させるわけか？
マジですかｗ

940 ：デフォルトの名無しさん：2013/10/14(月) 13:02:10.22

こいつ、まともにgit使ったことないんだろうな

941 ：デフォルトの名無しさん：2013/10/14(月) 13:04:20.20

たぶん基本Fast-forwardな状態でマージが進むような使いかたしかしてないんだろ
お一人様でやってるとか

942 ：デフォルトの名無しさん：2013/10/14(月) 13:13:06.98

コンフリクトを修正する方法に慣れたいので
git initからコンフリクトして、コンフリクトを解消するまでの手順を教えてください

943 ：デフォルトの名無しさん：2013/10/14(月) 13:26:52.21

まあ一人でソースのバックアップ目的でgit使うなら何ぶち込んでも問題にならんわな

944 ：デフォルトの名無しさん：2013/10/14(月) 13:29:05.02

一人で使ってるけど、どこ修正したかをgit statusとかgit diffで頻繁に確認しながら進めるんで、
余分なものは絶対管理から外す

945 ：デフォルトの名無しさん：2013/10/14(月) 13:35:37.76

>>933
> まじで意味がわからないんだけど？

テスト毎にコミットする人決めときゃいいだけでしょ？

946 ：デフォルトの名無しさん：2013/10/14(月) 13:39:00.00

おまえら、まさかマージした時に
自動的にコミットとかしてないよな？

コミットする前にテストは必須。
テストを実行してから
OKならそのテスト結果毎コミットする。

これでなんの問題が有るんだよ？

947 ：デフォルトの名無しさん：2013/10/14(月) 13:39:27.07

git statusにコミットしないファイルが出てきちゃう環境な奴は二流

948 ：デフォルトの名無しさん：2013/10/14(月) 13:40:45.68

>>946
>>937

949 ：デフォルトの名無しさん：2013/10/14(月) 13:42:25.70

>>947
これってどうふうにしたら再現できますか？

950 ：デフォルトの名無しさん：2013/10/14(月) 13:43:26.98

結果が全パスなら保存する価値がないし(通ったぞという証拠?)
全パスでないならpushすべきでない、と思った。

951 ：デフォルトの名無しさん：2013/10/14(月) 13:48:18.31

>>949
ホームやリポジトリのgitignoreを適切に設定していない場合におこります

952 ：デフォルトの名無しさん：2013/10/14(月) 13:52:53.56

>>946
「マージした時に自動的にコミットするな」が意味不明
gitでマージするときには
マージコミットができるかFF状態でHEADを移動するかどっちかだよね？

953 ：デフォルトの名無しさん：2013/10/14(月) 13:53:53.88

>>950
> 通ったぞという証拠?

テスト実施日時とかの情報もあるよ。

954 ：デフォルトの名無しさん：2013/10/14(月) 13:56:35.10

>>953
コミット時には必ずテストすべきなんだから、コミット日時がテスト実施日時なのでは？

955 ：デフォルトの名無しさん：2013/10/14(月) 13:59:53.25

gitなら、ビルド通るぐらいの確認でコミットする
pushする前には、それなりのテストをするけど

956 ：デフォルトの名無しさん：2013/10/14(月) 15:22:07.42

>>954
テストって言っても結合テストとか、システムテストとかもあるでしょ。

957 ：デフォルトの名無しさん：2013/10/14(月) 15:57:04.67

jasmine使ってテストが書かれていてgithubに公開しているのオープンソースを何でもいいので教えてください

958 ：デフォルトの名無しさん：2013/10/14(月) 16:19:00.79

もはやGitとは何も関係無いな

959 ：デフォルトの名無しさん：2013/10/14(月) 16:27:21.00

すいません書き込むスレまちがいました

960 ：デフォルトの名無しさん：2013/10/14(月) 16:37:56.81

git for windows がバージョンアップされましたよ

961 ：デフォルトの名無しさん：2013/10/14(月) 17:23:58.45

>>938

962 ：デフォルトの名無しさん：2013/10/15(火) 00:18:28.83

>>946
ローカルではコミットはCTRL+S連打レベルでガンガンするよ
上流にはテストに通ってから入れる

963 ：デフォルトの名無しさん：2013/10/15(火) 00:57:50.86

CTRL+R？

964 ：デフォルトの名無しさん：2013/10/15(火) 01:07:51.52

端末出力の一時停止？
Emacsでインクリメンタルサーチ？

965 ：デフォルトの名無しさん：2013/10/15(火) 04:48:43.55

>>964
横だけど、保存なみにってことでしょ。

966 ：デフォルトの名無しさん：2013/10/15(火) 09:28:44.56

素でわからんかった。
皆キーバインド同じだと思ってんのか。

967 ：デフォルトの名無しさん：2013/10/15(火) 11:22:34.68

eamcsのキーバインドもWinの推奨ショートカットに変更した

968 ：デフォルトの名無しさん：2013/10/15(火) 11:23:25.78

>>964
いまどき端末出力の一時停止なんて有効にしてるやつはおらんよ

969 ：デフォルトの名無しさん：2013/10/15(火) 11:54:56.47

えーtelnet(ssh)でしょっちゅう止めちゃってすぐに^Q押してるけどな

970 ：デフォルトの名無しさん：2013/10/15(火) 15:39:52.14

一時停止、使う時も間々あるし無効にしたいって感じの機能じゃないな。

971 ：デフォルトの名無しさん：2013/10/15(火) 16:33:44.17

:wなら頻繁に打つ、GUIだとcommand+Sだな
あ、でもVisualStudioだと代わりにビルドしちゃうわw

972 ：デフォルトの名無しさん：2013/10/15(火) 16:51:23.72

MacにいったりWinにいったり忙しいなｗ
俺もだけど・・・

973 ：デフォルトの名無しさん：2013/10/15(火) 16:56:14.75

Macってさ常に最新のGitとかJavaとかgccとか言語やツールが使いたい場合
ソースコードをコンパイルしてインストールしていく形なの？
それともWindowsみたいにインストーラーダウンロードして自動でインストールしたり、圧縮ファイルを解凍して自分でフォルダに置いてインストールするタイプなの？
それともLinuxでいうyumやaptみたいにコマンド一発で入れられるの？

974 ：デフォルトの名無しさん：2013/10/15(火) 17:06:39.23

どうやって入れたかによる
公式のAppStore経由だと自動で通知が来てアップデート
コマンドラインツールだと、MacPortsというのがあるのでそれで
ソースから入れたらもちろｎソースからだし、apt使ってる人もいるみたいね

975 ：デフォルトの名無しさん：2013/10/15(火) 17:15:37.87

最近はHomebiewってのが多いけど、個人的には好かん。

976 ：デフォルトの名無しさん：2013/10/15(火) 17:16:27.71

Homebrew

どうやって i を打ったんだ俺

977 ：デフォルトの名無しさん：2013/10/15(火) 17:18:04.23

>>973
・ソースコンパイル
どーにも最新版が欲しいときにはやらなくもない
一応Unixではあるので、(Xが絡まなければ)素直に行けることが多い

・パッケージマネージャ
標準ではないが、有名なのがいくつかある
ちと更新遅かったりもするが、用意されてればコマンド一発でDL&インスコ出来て楽

・アーカイブやイメージからのインストール(オンラインソフトはもちろん、パッケージソフトでもよくあるパターン)
大概.appファイル1個が入ってるので、それを
アプリケーションフォルダにドラッグ&ドロップ。
それだけで標準ランチャにも出るようになる。
アプリケーションフォルダにはダブクリで起動するファイルしか置いてないので
アプリケーションフォルダ自体もランチャ代わりとしても使える。
必要ファイルはその中に内包してるので、移動するファイルは1個でいい。

・きっちりウィザードやインストーラ付き
意外にレア。常駐系や、システムへ変更を加える必要のあるソフトだけ。

・展開すると多数のファイルあって、配置する場所を考える必要があるもの。
稀に。プラグインとか、そういうプラグインの塊みたいなソフトではたまにある。

978 ：デフォルトの名無しさん：2013/10/15(火) 17:18:53.55

あ、書き忘れたけどストアからインストールも確かに主流になってきたね

979 ：デフォルトの名無しさん：2013/10/15(火) 17:27:47.12

おれみたいなWindowsしか使ったことない人間がいきなりMac使っても混乱しそうだ

980 ：デフォルトの名無しさん：2013/10/15(火) 17:42:30.63

>>979
まあ、別のOSだから仕方ないね
逆に純粋培養マカーからすりゃ、解凍して.dllとかの関係ないモン出てきたり
置いた後ショートカットも作らなきゃランチャに出てこんのはワケ分からんと思うぜ

981 ：デフォルトの名無しさん：2013/10/15(火) 17:43:37.83

あと…CUIアプリに関しては、Windowsが一番敷居高いぞ

982 ：デフォルトの名無しさん：2013/10/15(火) 18:12:35.00

ここはいつから雑談スレになったんだ？

983 ：デフォルトの名無しさん：2013/10/15(火) 19:26:35.65

面目ない

984 ：デフォルトの名無しさん：2013/10/15(火) 21:33:26.22

>>979
windowsもMacと一緒だろ。app形式がないくらいで。標準でコンパイラがないからソースコードも面倒か。
Linuxの標準でついてるパッケージマネージャが一番楽だ。