Git 6

0001デフォルトの名無しさん

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/

0002デフォルトの名無しさん

2013/05/21(火) 11:28:50.26

0003デフォルトの名無しさん

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

0004デフォルトの名無しさん

2013/05/21(火) 17:47:18.33

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

0005デフォルトの名無しさん

2013/05/21(火) 18:00:42.14

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

0006デフォルトの名無しさん

2013/05/21(火) 18:24:42.86

どこが違うんだｗ

0007デフォルトの名無しさん

2013/05/21(火) 20:27:27.03

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

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

0008デフォルトの名無しさん

2013/05/21(火) 20:45:57.85

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

0009デフォルトの名無しさん

2013/05/21(火) 20:49:06.05

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

0010デフォルトの名無しさん

2013/05/22(水) 23:55:31.37

gif←ジフ
git←ジット

0011デフォルトの名無しさん

2013/05/23(木) 00:11:42.22

cogito←コギト
git←ギット

0012デフォルトの名無しさん

2013/05/30(木) 08:03:12.77

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

0013デフォルトの名無しさん

2013/05/30(木) 08:19:51.93

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

わろす

0014デフォルトの名無しさん

2013/05/30(木) 08:31:20.23

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

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

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

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

ふ～ん。

0015デフォルトの名無しさん

2013/05/30(木) 12:45:19.64

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

0016デフォルトの名無しさん

2013/05/30(木) 12:59:51.25

これはひどい

0017デフォルトの名無しさん

2013/05/30(木) 19:48:48.10

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

0018デフォルトの名無しさん

2013/05/31(金) 00:30:01.42

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

0019デフォルトの名無しさん

2013/06/01(土) 17:19:55.26

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

0020デフォルトの名無しさん

2013/06/01(土) 18:07:22.36

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

0021デフォルトの名無しさん

2013/06/01(土) 18:56:33.22

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

0022デフォルトの名無しさん

2013/06/01(土) 19:00:09.51

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

0023デフォルトの名無しさん

2013/06/01(土) 19:01:44.47

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

002419

2013/06/01(土) 20:14:48.96

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

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

0025デフォルトの名無しさん

2013/06/01(土) 20:30:01.74

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

002619

2013/06/01(土) 21:08:46.73

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

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

0027デフォルトの名無しさん

2013/06/01(土) 22:05:18.89

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

002819

2013/06/01(土) 22:14:03.46

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

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

0029デフォルトの名無しさん

2013/06/01(土) 22:17:23.53

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

0030デフォルトの名無しさん

2013/06/01(土) 22:19:07.12

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

0031デフォルトの名無しさん

2013/06/01(土) 22:30:21.42

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

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

0032デフォルトの名無しさん

2013/06/01(土) 22:37:48.33

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

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

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

0033デフォルトの名無しさん

2013/06/01(土) 22:58:25.48

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

0034デフォルトの名無しさん

2013/06/01(土) 23:37:07.37

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

0035デフォルトの名無しさん

2013/06/02(日) 00:07:24.71

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

0036デフォルトの名無しさん

2013/06/02(日) 00:43:58.44

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

0037デフォルトの名無しさん

2013/06/02(日) 03:25:37.22

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

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

そうでないと非効率だ

0038デフォルトの名無しさん

2013/06/02(日) 03:28:44.09

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

0039デフォルトの名無しさん

2013/06/02(日) 03:46:02.28

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

0040デフォルトの名無しさん

2013/06/02(日) 11:38:21.03

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

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

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

0041デフォルトの名無しさん

2013/06/05(水) 20:04:03.61

>>12
返事キター

(●●) 様

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

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

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

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

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

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

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

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

0042デフォルトの名無しさん

2013/06/05(水) 20:19:40.68

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

0043デフォルトの名無しさん

2013/06/05(水) 23:58:44.11

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

0044デフォルトの名無しさん

2013/06/06(木) 11:24:50.99

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

0045デフォルトの名無しさん

2013/06/06(木) 11:46:23.53

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

0046デフォルトの名無しさん

2013/06/06(木) 11:57:33.66

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

0047デフォルトの名無しさん

2013/06/06(木) 12:19:05.74

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

0048デフォルトの名無しさん

2013/06/06(木) 13:15:36.02

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

0049デフォルトの名無しさん

2013/06/06(木) 13:38:19.05

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

0050デフォルトの名無しさん

2013/06/06(木) 13:46:18.50

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

0051デフォルトの名無しさん

2013/06/06(木) 16:59:54.41

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

0052デフォルトの名無しさん

2013/06/06(木) 17:07:26.93

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

0053デフォルトの名無しさん

2013/06/06(木) 17:22:38.93

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

0054デフォルトの名無しさん

2013/06/06(木) 17:29:31.17

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

0055デフォルトの名無しさん

2013/06/06(木) 17:42:26.53

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

0056デフォルトの名無しさん

2013/06/06(木) 22:09:52.71

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

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

0057デフォルトの名無しさん

2013/06/07(金) 08:07:39.73

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

0058デフォルトの名無しさん

2013/06/07(金) 08:49:15.24

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

0059デフォルトの名無しさん

2013/06/07(金) 11:25:19.35

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

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

0060デフォルトの名無しさん

2013/06/07(金) 11:49:15.77

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

0061デフォルトの名無しさん

2013/06/07(金) 15:48:26.96

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

0062デフォルトの名無しさん

2013/06/07(金) 16:09:33.23

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

0063デフォルトの名無しさん

2013/06/07(金) 16:47:33.66

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

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

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

0064デフォルトの名無しさん

2013/06/07(金) 23:02:39.65

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

0065デフォルトの名無しさん

2013/06/10(月) 12:06:58.48

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

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

0066デフォルトの名無しさん

2013/06/10(月) 12:09:27.77

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

0067デフォルトの名無しさん

2013/06/10(月) 12:18:46.68

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

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

0068デフォルトの名無しさん

2013/06/10(月) 12:46:46.02

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

0069デフォルトの名無しさん

2013/06/10(月) 13:00:36.05

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

0070デフォルトの名無しさん

2013/06/10(月) 13:03:06.73

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

0071デフォルトの名無しさん

2013/06/10(月) 13:20:07.94

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

0072デフォルトの名無しさん

2013/06/10(月) 13:21:04.71

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

0073デフォルトの名無しさん

2013/06/10(月) 13:31:08.72

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

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

0074デフォルトの名無しさん

2013/06/10(月) 13:41:00.07

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

0075デフォルトの名無しさん

2013/06/10(月) 13:47:43.49

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

0076デフォルトの名無しさん

2013/06/10(月) 14:24:31.47

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

0077デフォルトの名無しさん

2013/06/10(月) 15:00:40.33

７７

0078デフォルトの名無しさん

2013/06/10(月) 15:05:22.76

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

0079デフォルトの名無しさん

2013/06/10(月) 16:54:55.00

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

0080デフォルトの名無しさん

2013/06/10(月) 17:10:56.30

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

0081デフォルトの名無しさん

2013/06/10(月) 17:37:09.40

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

0082デフォルトの名無しさん

2013/06/19(水) 12:28:36.82ID:QJZyPKVo!

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

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

0083デフォルトの名無しさん

2013/06/19(水) 12:48:24.23

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

0084デフォルトの名無しさん

2013/06/19(水) 14:22:11.09

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

0085デフォルトの名無しさん

2013/06/21(金) 01:48:02.01

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

0086デフォルトの名無しさん

2013/06/21(金) 12:06:38.55

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

0087デフォルトの名無しさん

2013/06/21(金) 14:35:22.19

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

0088デフォルトの名無しさん

2013/06/21(金) 14:47:18.57

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

0089デフォルトの名無しさん

2013/06/21(金) 21:35:05.74

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

0090デフォルトの名無しさん

2013/06/22(土) 17:26:20.54

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

0091デフォルトの名無しさん

2013/06/22(土) 22:47:56.90

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

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

0092デフォルトの名無しさん

2013/06/23(日) 13:54:29.47

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

0093デフォルトの名無しさん

2013/06/23(日) 16:05:10.37

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

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

0094デフォルトの名無しさん

2013/06/26(水) 04:02:08.36

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

0095デフォルトの名無しさん

2013/06/27(木) 14:52:50.50

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

0096デフォルトの名無しさん

2013/06/30(日) 15:54:27.81

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

0097デフォルトの名無しさん

2013/06/30(日) 18:08:50.32

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

0098デフォルトの名無しさん

2013/06/30(日) 18:18:27.87

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

0099デフォルトの名無しさん

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

0100デフォルトの名無しさん

2013/07/03(水) NY:AN:NY.AN

なんかgithubおもくね？

0101デフォルトの名無しさん

2013/07/05(金) NY:AN:NY.AN

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

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

0102デフォルトの名無しさん

2013/07/09(火) NY:AN:NY.AN

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

0103デフォルトの名無しさん

2013/07/09(火) NY:AN:NY.AN

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

0104デフォルトの名無しさん

2013/07/09(火) NY:AN:NY.AN

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

0105デフォルトの名無しさん

2013/07/09(火) NY:AN:NY.AN

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

0106デフォルトの名無しさん

2013/07/09(火) NY:AN:NY.AN

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

0107デフォルトの名無しさん

2013/07/09(火) NY:AN:NY.AN

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

0108デフォルトの名無しさん

2013/07/09(火) NY:AN:NY.AN

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

0109デフォルトの名無しさん

2013/07/09(火) NY:AN:NY.AN

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

0110デフォルトの名無しさん

2013/07/09(火) NY:AN:NY.AN

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

0111デフォルトの名無しさん

2013/07/10(水) NY:AN:NY.AN

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

0112片山博文MZパンク ◆0lBZNi.Q7evd

2013/07/14(日) NY:AN:NY.AN

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

0113デフォルトの名無しさん

2013/07/14(日) NY:AN:NY.AN

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

0114デフォルトの名無しさん

2013/07/14(日) NY:AN:NY.AN

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

0115デフォルトの名無しさん

2013/07/14(日) NY:AN:NY.AN

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

0116デフォルトの名無しさん

2013/07/14(日) NY:AN:NY.AN

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

0117デフォルトの名無しさん

2013/07/14(日) NY:AN:NY.AN

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

0118デフォルトの名無しさん

2013/07/16(火) NY:AN:NY.AN

>>114
片山ゆうくん？

0119デフォルトの名無しさん

2013/07/16(火) NY:AN:NY.AN

>>118

0120デフォルトの名無しさん

2013/07/18(木) NY:AN:NY.AN

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

0121デフォルトの名無しさん

2013/07/19(金) NY:AN:NY.AN

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

0122デフォルトの名無しさん

2013/07/19(金) NY:AN:NY.AN

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

0123デフォルトの名無しさん

2013/07/19(金) NY:AN:NY.AN

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

0124デフォルトの名無しさん

2013/07/19(金) NY:AN:NY.AN

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

0125デフォルトの名無しさん

2013/07/20(土) NY:AN:NY.AN

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

0126デフォルトの名無しさん

2013/07/20(土) NY:AN:NY.AN

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

0127デフォルトの名無しさん

2013/07/20(土) NY:AN:NY.AN

ユーザ名は？

0128デフォルトの名無しさん

2013/07/20(土) NY:AN:NY.AN

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

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

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

0129デフォルトの名無しさん

2013/07/20(土) NY:AN:NY.AN

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

0130デフォルトの名無しさん

2013/07/20(土) NY:AN:NY.AN

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

0131デフォルトの名無しさん

2013/07/20(土) NY:AN:NY.AN

>>130
1500円です

0132デフォルトの名無しさん

2013/07/21(日) NY:AN:NY.AN

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

0133デフォルトの名無しさん

2013/07/21(日) NY:AN:NY.AN

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

0134デフォルトの名無しさん

2013/07/21(日) NY:AN:NY.AN

振り込み手数料のが高い

0135デフォルトの名無しさん

2013/07/21(日) NY:AN:NY.AN

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

0136デフォルトの名無しさん

2013/07/24(水) NY:AN:NY.AN

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

0137デフォルトの名無しさん

2013/07/24(水) NY:AN:NY.AN

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

0138デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

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

0139デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

2chもGit化するか？

0140デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

GUIだと簡単という幻想。

0141デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

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

0142デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

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

0143デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

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

0144デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

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

0145デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

ええっ！？

0146デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

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

0147デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

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

0148デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

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

0149デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

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

0150デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

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

0151デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

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

0152デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

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

0153デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

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

0154デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

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

0155デフォルトの名無しさん

2013/08/01(木) NY:AN:NY.AN

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

0156デフォルトの名無しさん

2013/08/02(金) NY:AN:NY.AN

秘書に頼めば余裕だしな

0157デフォルトの名無しさん

2013/08/02(金) NY:AN:NY.AN

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

0158デフォルトの名無しさん

2013/08/02(金) NY:AN:NY.AN

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

0159デフォルトの名無しさん

2013/08/02(金) NY:AN:NY.AN

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

0160デフォルトの名無しさん

2013/08/02(金) NY:AN:NY.AN

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

0161デフォルトの名無しさん

2013/08/02(金) NY:AN:NY.AN

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

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

0162デフォルトの名無しさん

2013/08/02(金) NY:AN:NY.AN

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

0163デフォルトの名無しさん

2013/08/02(金) NY:AN:NY.AN

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

0164デフォルトの名無しさん

2013/08/02(金) NY:AN:NY.AN

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

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

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

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

0165デフォルトの名無しさん

2013/08/02(金) NY:AN:NY.AN

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

0166デフォルトの名無しさん

2013/08/02(金) NY:AN:NY.AN

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

0167デフォルトの名無しさん

2013/08/02(金) NY:AN:NY.AN

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

0168デフォルトの名無しさん

2013/08/02(金) NY:AN:NY.AN

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

0169デフォルトの名無しさん

2013/08/02(金) NY:AN:NY.AN

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

0170デフォルトの名無しさん

2013/08/02(金) NY:AN:NY.AN

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

0171デフォルトの名無しさん

2013/08/02(金) NY:AN:NY.AN

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

0172デフォルトの名無しさん

2013/08/03(土) NY:AN:NY.AN

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

0173デフォルトの名無しさん

2013/08/03(土) NY:AN:NY.AN

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

0174デフォルトの名無しさん

2013/08/03(土) NY:AN:NY.AN

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

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

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

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

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

0175デフォルトの名無しさん

2013/08/03(土) NY:AN:NY.AN

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

0176デフォルトの名無しさん

2013/08/03(土) NY:AN:NY.AN

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

0177デフォルトの名無しさん

2013/08/03(土) NY:AN:NY.AN

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

0178デフォルトの名無しさん

2013/08/03(土) NY:AN:NY.AN

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

0179デフォルトの名無しさん

2013/08/03(土) NY:AN:NY.AN

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

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

0180デフォルトの名無しさん

2013/08/03(土) NY:AN:NY.AN

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

0181デフォルトの名無しさん

2013/08/03(土) NY:AN:NY.AN

馬鹿には無理

0182デフォルトの名無しさん

2013/08/03(土) NY:AN:NY.AN

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

0183デフォルトの名無しさん

2013/08/04(日) NY:AN:NY.AN

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

0184デフォルトの名無しさん

2013/08/04(日) NY:AN:NY.AN

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

0185デフォルトの名無しさん

2013/08/04(日) NY:AN:NY.AN

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

0186デフォルトの名無しさん

2013/08/04(日) NY:AN:NY.AN

Gif　ジフ
Git　ギット

(´Д｀)？

0187デフォルトの名無しさん

2013/08/04(日) NY:AN:NY.AN

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

0188デフォルトの名無しさん

2013/08/04(日) NY:AN:NY.AN

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

0189デフォルトの名無しさん

2013/08/04(日) NY:AN:NY.AN

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

0190デフォルトの名無しさん

2013/08/04(日) NY:AN:NY.AN

cogito ergo sum
コギト！

0191デフォルトの名無しさん

2013/08/05(月) NY:AN:NY.AN

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

0192デフォルトの名無しさん

2013/08/08(木) NY:AN:NY.AN

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

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

0193デフォルトの名無しさん

2013/08/09(金) NY:AN:NY.AN

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

0194デフォルトの名無しさん

2013/08/09(金) NY:AN:NY.AN

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

0195デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

>>193
pre-commt フックとか

0196デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

教えてください。

0197デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

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

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

0198デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

0199デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

0200デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

0201デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

0202デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

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

0203デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

0204デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

0205デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

0206デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

0207デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

0208デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

0209デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

0210デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

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

0211デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

0212デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

0213デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

0214デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

0215デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

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

0216デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

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

0217デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

0218デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

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

0219デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

0220デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

>>210
例えがうまいな

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

0221デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

0222デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

0223デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

0224デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

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

0点。

0225デフォルトの名無しさん

2013/08/10(土) NY:AN:NY.AN

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

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

0226デフォルトの名無しさん

2013/08/11(日) NY:AN:NY.AN

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

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

0227デフォルトの名無しさん

2013/08/11(日) NY:AN:NY.AN

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

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

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

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

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

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

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

としたいんですが

0228デフォルトの名無しさん

2013/08/11(日) NY:AN:NY.AN

Githubの質問じゃないし

0229デフォルトの名無しさん

2013/08/11(日) NY:AN:NY.AN

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

0230デフォルトの名無しさん

2013/08/11(日) NY:AN:NY.AN

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

0231デフォルトの名無しさん

2013/08/11(日) NY:AN:NY.AN

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

0232デフォルトの名無しさん

2013/08/11(日) NY:AN:NY.AN

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

0233デフォルトの名無しさん

2013/08/11(日) NY:AN:NY.AN

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

0234デフォルトの名無しさん

2013/08/11(日) NY:AN:NY.AN

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

0235デフォルトの名無しさん

2013/08/11(日) NY:AN:NY.AN

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

0236デフォルトの名無しさん

2013/08/12(月) NY:AN:NY.AN

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

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

0237デフォルトの名無しさん

2013/08/12(月) NY:AN:NY.AN

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

0238デフォルトの名無しさん

2013/08/12(月) NY:AN:NY.AN

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

0239デフォルトの名無しさん

2013/08/12(月) NY:AN:NY.AN

>>238
もっと～もっと～

0240デフォルトの名無しさん

2013/08/12(月) NY:AN:NY.AN

どうぞどうぞ

0241デフォルトの名無しさん

2013/08/13(火) NY:AN:NY.AN

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

0242デフォルトの名無しさん

2013/08/13(火) NY:AN:NY.AN

lolcommits
約 3,370 件（0.23 秒）

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

0243デフォルトの名無しさん

2013/08/18(日) NY:AN:NY.AN

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

0244デフォルトの名無しさん

2013/08/19(月) NY:AN:NY.AN

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

0245デフォルトの名無しさん

2013/08/20(火) NY:AN:NY.AN

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

0246デフォルトの名無しさん

2013/08/29(木) NY:AN:NY.AN

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

0247デフォルトの名無しさん

2013/08/29(木) NY:AN:NY.AN

かおないパワー！

0248デフォルトの名無しさん

2013/08/29(木) NY:AN:NY.AN

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

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

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

0249デフォルトの名無しさん

2013/08/29(木) NY:AN:NY.AN

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

0250デフォルトの名無しさん

2013/08/29(木) NY:AN:NY.AN

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

0251デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

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

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

0252デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

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

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

0253デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

commit --amend
push --force

0254デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

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

0255デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

1.2. stash -> checkout test -> stash pop

0256デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

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

0257デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

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

0258デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

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

0259251

2013/08/30(金) NY:AN:NY.AN

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

0260デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

自分で判断したまえ

0261デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

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

0262デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

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

0263デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

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

0264デフォルトの名無しさん

2013/08/30(金) NY:AN:NY.AN

>>251

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

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

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

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

0265デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

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

0266デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

>>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だと難しそうだけど。。。。

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

0267デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

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

0268デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

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

0269デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

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

0270デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

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

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

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

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

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

0271デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

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

0272デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

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

0273デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

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

0274デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

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

0275デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

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

0276デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

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

0277デフォルトの名無しさん

2013/08/31(土) NY:AN:NY.AN

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

0278デフォルトの名無しさん

2013/09/03(火) 21:06:55.92

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

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

0279デフォルトの名無しさん

2013/09/03(火) 21:31:38.54

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

0280デフォルトの名無しさん

2013/09/03(火) 22:10:32.92

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

0281デフォルトの名無しさん

2013/09/05(木) 00:18:19.85

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

0282デフォルトの名無しさん

2013/09/08(日) 02:46:33.90

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

0283デフォルトの名無しさん

2013/09/08(日) 03:58:07.60

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

0284デフォルトの名無しさん

2013/09/08(日) 09:49:38.39

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

0285デフォルトの名無しさん

2013/09/08(日) 10:11:36.86

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

0286デフォルトの名無しさん

2013/09/08(日) 12:09:28.04

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

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

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

これならおｋ？

0287デフォルトの名無しさん

2013/09/08(日) 12:11:00.91

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

0288デフォルトの名無しさん

2013/09/08(日) 12:28:36.07

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

0289デフォルトの名無しさん

2013/09/08(日) 12:51:31.46

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

0290デフォルトの名無しさん

2013/09/08(日) 12:53:02.34

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

0291デフォルトの名無しさん

2013/09/08(日) 12:55:51.27

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

0292デフォルトの名無しさん

2013/09/08(日) 12:57:33.04

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

0293デフォルトの名無しさん

2013/09/08(日) 13:02:42.59

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

0294デフォルトの名無しさん

2013/09/08(日) 13:03:07.03

>>292
どこソースよ

0295デフォルトの名無しさん

2013/09/08(日) 13:03:22.30

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

0296デフォルトの名無しさん

2013/09/08(日) 13:16:26.38

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

0297デフォルトの名無しさん

2013/09/08(日) 17:09:42.99

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

0298デフォルトの名無しさん

2013/09/08(日) 18:09:19.54

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

0299デフォルトの名無しさん

2013/09/08(日) 21:34:25.40

>>296
クマー

0300デフォルトの名無しさん

2013/09/08(日) 21:35:37.82

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

0301デフォルトの名無しさん

2013/09/09(月) 11:40:51.66

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

0302デフォルトの名無しさん

2013/09/09(月) 11:44:11.39

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

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

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

非公開フォルダー

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

にしてる

0303デフォルトの名無しさん

2013/09/09(月) 21:32:38.01

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

0304デフォルトの名無しさん

2013/09/10(火) 02:03:53.65

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

0305デフォルトの名無しさん

2013/09/11(水) 10:01:01.01

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

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

0306デフォルトの名無しさん

2013/09/11(水) 10:51:34.49

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

0307デフォルトの名無しさん

2013/09/11(水) 10:56:06.33

git-svnで満足

0308デフォルトの名無しさん

2013/09/11(水) 11:31:02.67

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

0309デフォルトの名無しさん

2013/09/11(水) 12:40:01.53

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

0310デフォルトの名無しさん

2013/09/11(水) 13:46:09.75

>>306
具体的には？

0311デフォルトの名無しさん

2013/09/11(水) 13:46:54.51

>>306 -> >>309

0312デフォルトの名無しさん

2013/09/11(水) 15:33:11.25

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

0313デフォルトの名無しさん

2013/09/11(水) 16:51:27.93

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

0314デフォルトの名無しさん

2013/09/11(水) 17:33:12.78

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

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

0315デフォルトの名無しさん

2013/09/11(水) 18:03:48.99

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

0316デフォルトの名無しさん

2013/09/11(水) 19:48:10.66

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

0317デフォルトの名無しさん

2013/09/11(水) 19:49:01.78

×共有型
○分散型

0318デフォルトの名無しさん

2013/09/11(水) 20:26:04.76

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

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

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

0319デフォルトの名無しさん

2013/09/11(水) 21:05:39.78

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

0320デフォルトの名無しさん

2013/09/11(水) 21:20:47.75

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

0321デフォルトの名無しさん

2013/09/11(水) 21:25:44.23

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

0322デフォルトの名無しさん

2013/09/11(水) 21:32:36.70

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

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

0323デフォルトの名無しさん

2013/09/11(水) 21:59:40.08

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

0324デフォルトの名無しさん

2013/09/11(水) 22:14:28.71

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

0325デフォルトの名無しさん

2013/09/11(水) 22:21:36.31

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

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

0326デフォルトの名無しさん

2013/09/11(水) 23:04:40.89

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

0327デフォルトの名無しさん

2013/09/11(水) 23:32:45.56

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

0328デフォルトの名無しさん

2013/09/11(水) 23:44:04.11

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

0329デフォルトの名無しさん

2013/09/11(水) 23:44:50.09

時代はmd

0330デフォルトの名無しさん

2013/09/12(木) 01:27:09.68

>>321
cvsを使う。

0331デフォルトの名無しさん

2013/09/12(木) 01:55:33.54

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

0332デフォルトの名無しさん

2013/09/12(木) 01:58:51.25

>>331
何が欠点なの？

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

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

0333デフォルトの名無しさん

2013/09/12(木) 02:16:01.50

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

0334デフォルトの名無しさん

2013/09/12(木) 03:51:13.42

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

0335デフォルトの名無しさん

2013/09/12(木) 07:05:56.17

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

0336デフォルトの名無しさん

2013/09/12(木) 07:55:06.28

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

0337デフォルトの名無しさん

2013/09/12(木) 08:38:16.74

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

0338デフォルトの名無しさん

2013/09/12(木) 10:12:33.52

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

0339デフォルトの名無しさん

2013/09/12(木) 11:14:10.39

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

0340デフォルトの名無しさん

2013/09/12(木) 11:17:23.02

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

0341デフォルトの名無しさん

2013/09/12(木) 11:21:15.95

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

0342デフォルトの名無しさん

2013/09/12(木) 11:22:15.24

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

0343デフォルトの名無しさん

2013/09/12(木) 11:25:13.18

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

0344デフォルトの名無しさん

2013/09/12(木) 11:26:44.94

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

0345デフォルトの名無しさん

2013/09/12(木) 11:52:09.75

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

0346デフォルトの名無しさん

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を勝手に編集してプッシュしちゃう可能性があります
こういう場面はどうやって作業するんでしょうか？

0347デフォルトの名無しさん

2013/09/12(木) 12:29:23.41

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

0348デフォルトの名無しさん

2013/09/12(木) 12:30:07.64

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

0349デフォルトの名無しさん

2013/09/12(木) 12:30:18.88

>>345
ない。

0350デフォルトの名無しさん

2013/09/12(木) 12:33:31.00

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

0351デフォルトの名無しさん

2013/09/12(木) 12:37:57.51

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

0352デフォルトの名無しさん

2013/09/12(木) 13:09:45.36

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

0353デフォルトの名無しさん

2013/09/12(木) 18:03:53.50

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

0354デフォルトの名無しさん

2013/09/12(木) 18:42:32.66

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

0355デフォルトの名無しさん

2013/09/12(木) 20:36:42.01

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

0356デフォルトの名無しさん

2013/09/12(木) 20:52:37.22

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

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

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

0357デフォルトの名無しさん

2013/09/12(木) 20:56:09.73

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

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

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

0358デフォルトの名無しさん

2013/09/12(木) 21:09:16.44

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

ならねーよ。

0359デフォルトの名無しさん

2013/09/12(木) 21:18:19.14

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

0360デフォルトの名無しさん

2013/09/12(木) 21:25:25.46

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

0361デフォルトの名無しさん

2013/09/12(木) 21:28:16.00

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

0362デフォルトの名無しさん

2013/09/12(木) 22:35:46.28

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

0363デフォルトの名無しさん

2013/09/12(木) 22:50:22.66

>>337
何で?
自分は満足なんだけど、誰も使ってないみたいだから大きな穴があるんじゃ
無いかと気になってる。

0364デフォルトの名無しさん

2013/09/12(木) 23:00:32.67

>>337じゃないけど、git-svnを使うと結局svnから逃れられなくなる。

それは単純にsvnだけ、gitだけを使うよりも難しい作業を強いられることになる。

gitのノウハウにもgit-svnを使った例は少ない。

github及び、githubクローンであるgitlabを使うときどうするのかよくわからない。

何をするにも、gitだけだとこうやるけど、そこにgit-svnがくると・・・などという話が
いつまでも付きまとってくる。

穴があるというよりも大変。

0365デフォルトの名無しさん

2013/09/12(木) 23:05:01.67

>>363
自分も使ってるけど、今のところ運用で詰んだことはないな。

0366デフォルトの名無しさん

2013/09/12(木) 23:09:50.78

>>365
開発では？

gitの特色である開発中にいくつもブランチ作って
幾つものブランチを切り替えて
歴史を修正しながら、小さな修正で
開発するってことが普通に出来るの？

0367デフォルトの名無しさん

2013/09/12(木) 23:15:25.90

>>355
cvsとかsvnでもupdateしてからcommitするようにすればロックなんて機能は必要ない。

gitの場合、pushをcommit、pullをupdateに置き換えてかんがえれば、svnからの移行もしやすいんじゃないかな。
gitはあくまで、ローカル作業がより便利になっただけだよ。

0368デフォルトの名無しさん

2013/09/12(木) 23:22:43.70

> gitはあくまで、ローカル作業がより便利になっただけだよ。
そうなんだよな。

ソースコードはサーバーで一元管理するもの。
逆に言えば、ローカルにあるものはソースコードの管理というよりも
開発そのもの。だからgitは開発がより便利になる。

ステージングとかいいよ。

開発してる時に、小さなミスを見つけて、それだけコミットしたいと思うだろう？
gitなら、git addでファイルの ”一部分” だけをステージング（ようはコミット予定リスト）し
あちこち修正途中のファイルがあったとしても、簡単にファイルの一部分だけをコミットすることができる。

svnだったら開発中によくある面倒なことを
gitであれば楽にこなしてしまう。

0369デフォルトの名無しさん

2013/09/13(金) 00:00:07.94

svnだエラーの出る状態でコミットするなとか言い出す人が多かったな。
エラーの出る状態から作り直して失敗したらどうするんだ。
svnでもブランチとか適切に運用できていればいいんだろうけど。

0370デフォルトの名無しさん

2013/09/13(金) 00:18:00.21

>>369
gitでもエラーの出る状態で入れないでよ

0371デフォルトの名無しさん

2013/09/13(金) 00:19:09.17

ローカルで正しく直してからプッシュするというのなら
エラーが出る状態でもいいかな。

0372デフォルトの名無しさん

2013/09/13(金) 00:34:16.73

エラーが出る出ない以前に
作業途中でコミットするのが納得できんな

単に途中経過を保存したいならstashがあるし
途中経過を他の人に見てもらいたいならMLや掲示板とかの方がいいだろう

0373デフォルトの名無しさん

2013/09/13(金) 00:39:20.59

>>372
stashはpopという引数があることからもわかるように
スタックという考え方が基礎になってるんだ。

作業途中の割り込み、の割り込み、の割り込み
といった用途で使うもの。

作業途中のコミットは、
いくつかの作業を並行して行っている場合に使う。

Aという作業をやっている途中で、
Bという作業をやってさらに
Cという作業に移ってAという作業に戻る。
と思ったら、Cという作業を進めなくてはならなくて
次はBみたいな。

0374デフォルトの名無しさん

2013/09/13(金) 00:54:59.34

stashはpullとかmergeする際の本当に一時的な退避にしか使わない
時間が経つとstashしておいた事実を(俺が)忘れてしまう
作業が割り込む場合は作業ブランチ切ってコミットしてる

0375デフォルトの名無しさん

2013/09/13(金) 00:59:35.14

>>367
それはロックの本質をわかってない

0376デフォルトの名無しさん

2013/09/13(金) 01:16:04.64

>>372
あとでそのエラーになった修正を使いたくなるかも知れないじゃないか。
それにチケットと関連付ける時にソースもあった方がわかりやすい。
公なとこにpushするなら、その前にまとめればいいだけだし。人のローカルリポジトリに口出しするとか、わけわからんわ。

0377デフォルトの名無しさん

2013/09/13(金) 01:16:57.33

mercurialがいろいろ縛った理由をちょっと理解できた気がする

0378デフォルトの名無しさん

2013/09/13(金) 01:24:20.08

> 人のローカルリポジトリに口出しするとか、わけわからんわ。
っ鏡

0379デフォルトの名無しさん

2013/09/13(金) 07:30:06.93

まあ言ってることが自己矛盾してるわな

0380デフォルトの名無しさん

2013/09/13(金) 08:58:47.04

作業途中でコミットできるのがgitのいいところじゃないか。
手元でずいぶん変更したけどまだビルド通らない/テスト通らない/バグが直りきってないときにコミット我慢するの？
途中まで実装したけどやってみると案外うまくいかないな。もう一つの案をで実装してみるか、ってときにその瞬間のコードをコミットしないの？

0381380

2013/09/13(金) 09:15:18.83

作業状態の保存(commit)と成果物の公開(push)を分離したところがgitの改善点だろ。
svnと同じタイミング・粒度でしかコミットしないという使い方も否定されないとしても、厳しすぎる制約を自ら課しているんだというのは認識しといた方がいいよ

0382デフォルトの名無しさん

2013/09/13(金) 09:20:31.22

もう一つの案を実装してみるときはブランチを切る
作業途中ならstashで保存する

これがベストな方法とは言わないし
他人のローカルリポジトリに口出しする気もないが
少なくとも作業途中でコミットする必然性はない

0383380

2013/09/13(金) 09:24:23.05

ブランチ切るのにコミットしないんだ。ふーん

0384デフォルトの名無しさん

2013/09/13(金) 09:24:56.57

svnでもいただろ。「また完成してない」とか言って何週間もコミットしない奴が。
手元に巨大な変更を抱えてて作業コピーの日付バックアップを一生懸命とってるの

0385デフォルトの名無しさん

2013/09/13(金) 09:29:58.54

testブランチでコード書いた後は
git checkout master
git merge test
git add -A
git commit -m "ちょめちょめ"
git push

この流れで合ってますか？

0386デフォルトの名無しさん

2013/09/13(金) 09:55:25.36

>>384
Gitでは「まだ完成してない」とか言ってpushしない奴ということになるわけですね

0387デフォルトの名無しさん

2013/09/13(金) 09:57:59.86

まああれだ。
自由ってのは便利だが、一定のルールで遵守させなければならないと。

0388デフォルトの名無しさん

2013/09/13(金) 10:07:57.29

>>385
git add -A は何をやってるの？

0389デフォルトの名無しさん

2013/09/13(金) 10:21:23.57

>>386
gitでも「まだ完成してない」と言ってコミットしないよ。きっと。
という今の流れ。

gitはそれこそstashみたいな、コミットしない自由も考慮されてるとは思うけど程度問題だな。
無闇にコミットを避けることはない

0390デフォルトの名無しさん

2013/09/13(金) 10:22:55.14

>>388
あれなんですよ
git add .
ってやると、なんかたまにgit add -A使えってメッセージが出るのです

0391デフォルトの名無しさん

2013/09/13(金) 10:28:03.32

>>390
git add . は何のためにするの？

＞testブランチでコード書いた後
これはtestブランチで書いたコードをtestブランチへコミット済みって意味？

0392デフォルトの名無しさん

2013/09/13(金) 10:28:38.23

>>367
> cvsとかsvnでもupdateしてからcommitするようにすればロックなんて機能は必要ない。

アホすぎ (w
チームにこんな奴いたら大変だろうな

0393デフォルトの名無しさん

2013/09/13(金) 10:29:15.20

いえ、ちがいます
masterブランチに移ってからaddします

0394デフォルトの名無しさん

2013/09/13(金) 10:33:52.76

>>393
何のためにtestブランチを作ったの？

0395デフォルトの名無しさん

2013/09/13(金) 10:40:32.81

merge だけでコミットされる (衝突がなければ) からその後の add と commit は無駄じゃね

0396デフォルトの名無しさん

2013/09/13(金) 11:03:05.11

ソースの頭にインクリメンタルなソースバージョンつけたいんだけど
gitってそういう思想じゃないから無理だよね・・・
どうしようかな

0397デフォルトの名無しさん

2013/09/13(金) 11:14:25.46

そんな時にセマンティックバージョニングとかいいんじゃね？

0398デフォルトの名無しさん

2013/09/13(金) 12:32:33.83

なんかすごい伸びてるな…

>>366
できるよ。自分だけだけど。

0399デフォルトの名無しさん

2013/09/13(金) 12:50:29.91

testブランチにコミットしていって、
ファイナルちょめちょめの後でmasterへマージ

0400デフォルトの名無しさん

2013/09/13(金) 13:14:13.68

gitを拡張することって言うのはできますか？
たとえば、git commit ってしたらc:\my.logに日時を記録する感じの機能をgitに組み込むなど

0401デフォルトの名無しさん

2013/09/13(金) 14:11:16.05

できるよ

0402デフォルトの名無しさん

2013/09/13(金) 19:15:58.04

>>400 適当なリポジトリで.git/hooksディレクトリの中身を読もう

0403デフォルトの名無しさん

2013/09/13(金) 20:56:48.98

>>384
いまどきのIDEだとローカルの作業履歴位はとってくれてるんだけどね。
コミットコメントが有るわけじゃないから何をやってたか分からないけど
ローカルの作業履歴としては割りと機能する。テキストエディタ以外は
認めないって人には分からないだろうけど。

0404デフォルトの名無しさん

2013/09/13(金) 21:39:01.30

Eclipseの履歴だと最低限は役に立つけどマージしたりスナップショット取ったり明示的にやれるわけじゃないし

0405デフォルトの名無しさん

2013/09/13(金) 21:52:13.00

>>400
gitのコミットログを見ればいいだけじゃん？
なんでわざわざ別に出力すんの？

0406デフォルトの名無しさん

2013/09/13(金) 22:44:41.16

>>403
エディタの編集履歴が便利なことは否定しないが、複数ファイルのスナップショットに名前をつけて保存できる機能とは区別しようぜ

0407デフォルトの名無しさん

2013/09/13(金) 22:55:30.79

>>363
git-svnだとマージに非常に制限がかかる。
そうなるとコンフリクトを恐れるようになって、いちいち手が止まってしまいストレスになる。

0408デフォルトの名無しさん

2013/09/13(金) 22:59:55.68

msysgitでdaemon立ち上げてリモートからpullやcloneしようとしたとき、たまにエラーになることが
あるんだが、原因を調べるには何を調べればいいかな？
表示されるエラーメッセージはInvalid Argumentとかearly EOFとかだけなんで意味わからん。

0409デフォルトの名無しさん

2013/09/13(金) 23:20:49.68

--verbose 付きで起動してみれば？

0410デフォルトの名無しさん

2013/09/13(金) 23:21:47.67

>>407
よく知らんのだけどrebaseじゃダメなの？

0411デフォルトの名無しさん

2013/09/14(土) 00:15:42.09

>>389
分散型だと中央を通さずに変更を渡すことが簡単だから、一部にだけ変更を伝えるという方法もあるね。

分散型はまだまだ色々な使い方ができそう。まあ運用を決めてもらわないと何もできない人には制限された方がいいんだろうけど。

0412デフォルトの名無しさん

2013/09/14(土) 00:16:03.03

>>407
dcommit時にコンフリクトするとどうなるの?
いつもrebaseしてからdcommitしてたから、意図せずマージになってたことは
ほとんど無くて、コンフリクトしたことがない。

0413デフォルトの名無しさん

2013/09/14(土) 00:40:38.03

>>412
rebaseあんまり使わないから向いてないのかも。
他のブランチでは気にせずgitらしくマージを繰り返してそれを中央リポジトリで公開して、いざsvn用のブランチに取り込もうとしてrebaseではまることが多かった。

0414デフォルトの名無しさん

2013/09/14(土) 00:44:26.35

ローカルでグチャグチャやってる分に口出す気はないよ。
それを上に持ってくんなということを言っている。

0415デフォルトの名無しさん

2013/09/14(土) 00:48:55.25

それ結局GitでもSVNでも同様だろ？

0416デフォルトの名無しさん

2013/09/14(土) 00:57:23.13

>>408
git config --global core.compression -1
でどうでしょう

0417408

2013/09/14(土) 07:24:34.77

>>409
それが、付けてもなんもわからなくて。
せめて、何に渡した何というArgumentがどうInvalidなのかくらいわかればいいんだが。

>>416
よくわからんが、エラーが出た箇所からすると関係ありそうな気がするな。
環境は会社なんで週明けに試してみるわ。ありがとう。

0418デフォルトの名無しさん

2013/09/14(土) 09:18:19.06

>>405
なんか自動化したいんだろ

0419デフォルトの名無しさん

2013/09/14(土) 10:29:28.80

>>412
rebase しないと dcommit できないんじゃないか。

0420デフォルトの名無しさん

2013/09/14(土) 10:42:48.85

>>419
dcommit時にマージされます。ローカルからはそう見える。
svn上では、update→commitに見えると思う。

0421デフォルトの名無しさん

2013/09/14(土) 14:16:33.20

>>405
複数人へのgit教育用にコミットしているかをひとつのログに集めたいから

0422デフォルトの名無しさん

2013/09/14(土) 22:52:16.95

>>420
㌧
自分が使ってた当時、怒られた記憶があったんだが。

0423デフォルトの名無しさん

2013/09/14(土) 23:55:50.48

>>422
コンフリクトした場合という話の流れを見逃してた。
コンフリクトした場合はどうなるかやったことがありません。
しなければマージされます。

0424デフォルトの名無しさん

2013/09/15(日) 07:40:17.91

svn dcommit時にsvn rebaseはされる
svn rebaseはrebaseもしている
最新リビジョンの先にしかコミットできないのと
svnのコミットにハッシュ振る必要があるので
ここでコンフリクトした場合確か無名ブランチに飛ばされるはず
自分はdevブランチ上で解決するようにしてるからあまり見たことないけど
共有がgitでも共有リポジトリの歴史いじることは推奨されてない気がするから
運用は似たようなもんじゃないの
？

0425デフォルトの名無しさん

2013/09/15(日) 09:35:25.12

ぼくはこれからバージョン0.0から始まるプログラムを作ろうと思います
1.0まで作ったとします。コミットもプッシュもたくさんやってきました
そしてバージョンアップさせていき2.0になりました
そこで質問です
やっぱりバージョンが違う場合でも同じリポジトリにコミットとプッシュするほうがいいのでしょうか？
あとバージョンごとにブランチは分けたほうがいいでしょうか？

0426デフォルトの名無しさん

2013/09/15(日) 09:44:38.26

そんなめんどくさいことしない

0427デフォルトの名無しさん

2013/09/16(月) 16:48:00.63

>>421
git logで誰がいつcommitしたか残ってるけど？？？

0428デフォルトの名無しさん

2013/09/16(月) 18:34:00.17

違うんです、commitした時点で別のログに記録したいんです

0429デフォルトの名無しさん

2013/09/16(月) 18:38:41.35

>>400
.git/hookでできるんじゃないの
拡張じゃなくて組み込まれてる機能だけど

0430デフォルトの名無しさん

2013/09/19(木) 23:11:39.01

CドライブとDドライブがあるんですが
Cドライブでコードを書いて、Dドライブをgithubの代わりとしてここにpushしたいのですが
こういう場合って、Dドライブのほうでgit init --bareってやってから
Cドライブ側でgit clone　～ってやるべきでしょうか？

0431デフォルトの名無しさん

2013/09/19(木) 23:50:18.12

HerokuとGithubしか使ったこと無く、Git単体で運用はしたことないんですが、
既に存在するプロジェクトのフォルダに対して

git init

git add .
git commit -m "comment"

を実行した場合、.gitフォルダにこれまでのバージョンが記録されていって、
いざとなれば、巻き戻せたりするんですよね？

0432デフォルトの名無しさん

2013/09/20(金) 00:17:54.09

>>431
目の前の箱で試してみろ

0433デフォルトの名無しさん

2013/09/20(金) 00:20:17.14

>>432
試してますが自身がないんです

0434デフォルトの名無しさん

2013/09/20(金) 00:44:10.93

Githubって使った事ないけど、
ローカルリポジトリ無くても
使えるものなの？

0435デフォルトの名無しさん

2013/09/20(金) 00:58:24.60

ローカルリポジトリは必要かもしれません。

ただしいつもgit cloneしてから、add, commit, pushしています。

0436デフォルトの名無しさん

2013/09/20(金) 01:10:41.71

ふーん、くろーうしてるんだな。

あっそ。

0437デフォルトの名無しさん

2013/09/20(金) 22:25:18.51

初心者がhelloworldやるのはgithubってやつでいいの？

0438デフォルトの名無しさん

2013/09/20(金) 22:27:49.10

try gitでもやってれば

0439デフォルトの名無しさん

2013/09/20(金) 22:31:10.14

全世界にhelloworldを公開したければ。
gitとgithubの違い分かってる？チーズとチーズケーキくらい違うよ。

0440デフォルトの名無しさん

2013/09/20(金) 22:34:11.91

githubでhelloworldやっちゃった
テヘ

0441デフォルトの名無しさん

2013/09/20(金) 22:35:10.10

「GitHub HelloWorld」でググるとみんなやってます

0442デフォルトの名無しさん

2013/09/20(金) 22:42:24.20

Hello Worldからforkする人っているの

0443デフォルトの名無しさん

2013/09/20(金) 23:03:11.09

初心者とかがレベルごとにステップアップできる
gitがあればいいのによくわらないけど

0444デフォルトの名無しさん

2013/09/20(金) 23:15:24.16

>>439
ケーキとケーキ屋くらい違うと思うな。
試しに作った初めてのケーキをケーキ屋に並べるとか、恥ずかしすぎる。

0445デフォルトの名無しさん

2013/09/20(金) 23:22:06.35

ぼくは恋人の始めてのケーキも味があっていいと思うんだ（直訳）

0446デフォルトの名無しさん

2013/09/20(金) 23:30:59.55

445さんすてき！抱いて！
男だけど

0447デフォルトの名無しさん

2013/09/20(金) 23:41:06.57

HelloWorldをＧｉｔHubに公開したからって誰かアクセスしてくるわけでもあるまいし
GitHub側が禁止してんならともかく何でもうｐしてけ

0448デフォルトの名無しさん

2013/09/21(土) 00:33:50.50

おまえらがうるさいから
今HelloWorldのリポジトリを削除していってるよ

0449デフォルトの名無しさん

2013/09/21(土) 01:07:54.68

どうしよう、俺もSandBoxプロジェクト削除してこようかな

0450デフォルトの名無しさん

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したかったのですが、ここからどうしたらいいでしょうか？

0451デフォルトの名無しさん

2013/09/21(土) 16:54:50.56

俺だったら自殺もんのミス

0452デフォルトの名無しさん

2013/09/21(土) 16:55:42.26

バージョン管理システムなんだから前の状態に戻せるんじゃないの？

0453デフォルトの名無しさん

2013/09/21(土) 16:57:38.23

git logのオプションに--graphと--reverseを付けられないんですが
--graphで表示したものを逆順に表示する方法ありませんか？

0454デフォルトの名無しさん

2013/09/21(土) 17:00:32.88

>>450
そのままmasterにマージしてpushすればいいんじゃね

0455デフォルトの名無しさん

2013/09/21(土) 17:08:11.83

×バージョン管理システムなんだから前の状態に戻せるんじゃないの？
○バージョン管理システムなんだから間違った状態も保存される。

間違った状態そのものを完全に履歴から抹殺するのは非常手段。

0456デフォルトの名無しさん

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.
ってなりました

0457デフォルトの名無しさん

2013/09/21(土) 21:07:39.45

Githubで質問です。
Pull Requestが来たんですが、内容の一部だけ採用して、他の部分は今までの自分のでいきたい、
という場合はどう処理すればよいのでしょうか？

0458デフォルトの名無しさん

2013/09/21(土) 21:09:17.87

全部まとめて送るなカスって送っとけ

0459デフォルトの名無しさん

2013/09/21(土) 21:10:46.12

一部だけ採用できるってことは別種の変更がひとつにまとまってるってことだろ？
コミット分けろボケって言っとけ

で、全部マージするんじゃなくて好きなやつだけcherry-pickするとか

0460デフォルトの名無しさん

2013/09/21(土) 21:13:13.72

ぼくもきれいなおねえさんに、ちぇりーぴっくされたいです。

0461デフォルトの名無しさん

2013/09/22(日) 03:03:18.32

GitHubの質問ってこのスレでいいのん？

0462デフォルトの名無しさん

2013/09/22(日) 03:18:31.00

内容によるだろうな

0463デフォルトの名無しさん

2013/09/22(日) 10:43:36.96

指定したcommitに対応するtagがあればそれを表示する方法は？

0464デフォルトの名無しさん

2013/09/22(日) 10:58:58.87

リモートのブランチをマージすることはできないの？

0465デフォルトの名無しさん

2013/09/22(日) 11:04:23.25

できますん

0466デフォルトの名無しさん

2013/09/22(日) 13:00:59.45

,gitignoreの記述で、
サブディレクトリ以下には適用されない、
そのディレクトリ直下のみのパターンを書く方法は？

0467デフォルトの名無しさん

2013/09/22(日) 13:31:09.00

パターンを/からはじめる

0468デフォルトの名無しさん

2013/09/22(日) 13:46:13.30

>>463
git tag --points-at hoge
Tagとハッシュの一覧は
git show-ref --tags

0469デフォルトの名無しさん

2013/09/22(日) 14:51:00.75

ファイルごとにバージョン番号を自動採番したいけど
どうしたらいいんだろうか

0470デフォルトの名無しさん

2013/09/22(日) 15:03:54.92

バージョン番号って何だ？

0471デフォルトの名無しさん

2013/09/22(日) 15:55:22.54

>>470
そのファイルのバージョン

0472デフォルトの名無しさん

2013/09/22(日) 15:57:16.58

>>470
CVSにたとえるなら $Id$ みたいなものがほしい

0473デフォルトの名無しさん

2013/09/22(日) 15:58:43.14

>>470
そのファイルのコミット回数のようなものでも構いません

0474デフォルトの名無しさん

2013/09/22(日) 16:09:36.28

exportだかarchiveだかの時に置換フィルタをかけるやり方はなんかあった気がするけど
そもそもgitのIDだかってSHA-1ハッシュ値だから、何も嬉しくない気が

0475デフォルトの名無しさん

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#キーワード展開

0476デフォルトの名無しさん

2013/09/22(日) 16:42:58.40

バージョン番号1のファイルがあったとして、
そのファイルを複数のローカルリポジトリで更新したら
それぞれのリポジトリでのバージョン番号はどうなるんだ？

0477デフォルトの名無しさん

2013/09/22(日) 17:03:54.74

>>461

GitHubやってる？
http://kohada.2ch.net/test/read.cgi/prog/1363523309/

0478デフォルトの名無しさん

2013/09/22(日) 17:22:33.30

>>476
それぞれ2になるんじゃね
んでマージすると一気に4になるんだよきっと

0479デフォルトの名無しさん

2013/09/22(日) 17:42:34.93

>>476,478
「どちらも2になって、マージすると3になる」説を推す
マージすると大きいほうの番号より1大きい番号になるってことで

それより不可解なのは番号がファイルごとに振られていることだな

0480デフォルトの名無しさん

2013/09/22(日) 17:59:31.29

いやおまえらｗ仮にもバージョン番号なんだから、
同じバージョン番号の違う内容のファイルがあったらダメだろｗ

0481デフォルトの名無しさん

2013/09/22(日) 18:03:56.28

つまりブランチ名がバージョン番号に含まれればいいのか！
いやちがう
レポジトリを一意に識別するための名前も含まれる必要があるのか！

0482デフォルトの名無しさん

2013/09/22(日) 18:10:00.24

ローカルリポジトリでは番号をインクリメントさせません。

0483デフォルトの名無しさん

2013/09/22(日) 18:25:26.05

>>482
メインのリポジトリで複数のブランチに別れたときはどうするの？

0484デフォルトの名無しさん

2013/09/22(日) 18:46:53.20

どうやらgitのやり方とはそぐわないことをやりたいらしいってことは分かった
で、何をするためにバージョン番号とやらが必要なんだ？

0485デフォルトの名無しさん

2013/09/22(日) 19:08:33.03

コミットIDさえあればそのリポジトリに存在するすべてのファイルの状態を特定できるんだから、
レポジトリの内容を元にバイナリを作ったりデプロイするときに
コミットIDを保存すればいいと思うのだけどね

0486デフォルトの名無しさん

2013/09/22(日) 19:22:24.03

俺の周りでもファイルごと版数にこだわる人たちが多いよ。
SVNに移行したのも最近だよ。(やっとタグをつけるプロパティを発見したらしい)

どうも、バラバラなファイルが集まったものが成果物という認識らしい。
だから何が集まってできたものか管理したいらしい。
それにしてもいろいろ的外れなわけだけど。

0487デフォルトの名無しさん

2013/09/22(日) 19:34:30.74

>>486
> やっとタグをつけるプロパティを発見したらしい

なんかどえらいもん発見してるな (w

0488デフォルトの名無しさん

2013/09/22(日) 19:42:25.50

おっと、分かってると思うけどCVSと同じように$Id$とかを置き換える設定ね

0489デフォルトの名無しさん

2013/09/22(日) 19:46:04.82

>>488
CVSの$ID$はブランチ切ったりマージしたときはどうなるの？

0490デフォルトの名無しさん

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の外で行えばいいんじゃないでしょうか?
ヘッダにそれらしい版数をつけるスクリプトを流すとか。

0491デフォルトの名無しさん

2013/09/22(日) 20:12:15.63

Gitはブランチを切ったときにどっちが親とかの概念がないからなあ
もとのブランチのファイルが1.2で
新しいブランチのファイルが1.2.1とか
そういうやり方は馴染まないよね

0492デフォルトの名無しさん

2013/09/22(日) 20:33:51.96

ようするにgit以外のやり方でgitを使おうとして大混乱、でFA？

0493デフォルトの名無しさん

2013/09/22(日) 21:13:40.77

gitを使うのに、git以外のやり方をすると
何もかもぶち壊しになるよ。
gitつかう意味がなくなる。

やめたほうがいいじゃなくて、
やめろって命令するレベル。

0494デフォルトの名無しさん

2013/09/22(日) 23:13:35.91

話は少し違うけどファイル別にコミット時のバージョンが保持されると、identコマンドでリンクされているソースのバージョンが取れるから便利だよ。

再現試験とか、リリース間違いの発見とか。

0495デフォルトの名無しさん

2013/09/22(日) 23:29:03.79

だからコミットIDをひとつだけ埋め込んどけば
リンクされてる全ソースが特定できるんだってば

0496デフォルトの名無しさん

2013/09/23(月) 00:17:14.27

「ファイルごとの版数が分かる」じゃなくて
「ファイルごとの版数しかわからない」だったんだよね。(タグは打てるけど)

コミットIDが分かるようになったんだから、もういいじゃん。

0497デフォルトの名無しさん

2013/09/23(月) 03:37:42.42

>>460
財布の中身だけチェリーピックしてもいいですか？

0498デフォルトの名無しさん

2013/09/23(月) 08:20:52.67

gitは開発中に回せ回せで使っておいて
特定時点の動くものをsvnなどに
まとめるのがいいのか？

0499デフォルトの名無しさん

2013/09/23(月) 08:38:32.18

>>498 まとめるのはgitじゃダメなん？

0500デフォルトの名無しさん

2013/09/23(月) 08:44:00.30

>>498 まとめるのはgitじゃダメなん？

0501デフォルトの名無しさん

2013/09/23(月) 10:27:09.72

>>498
Are you kidding?

0502デフォルトの名無しさん

2013/09/23(月) 10:38:24.27

You gonna dig this.

0503デフォルトの名無しさん

2013/09/23(月) 10:41:32.31

git使うならこれもつかったほうがいいってやつ教えて

0504デフォルトの名無しさん

2013/09/23(月) 10:55:41.23

source tree

0505デフォルトの名無しさん

2013/09/23(月) 12:15:15.39

tig

0506デフォルトの名無しさん

2013/09/23(月) 12:34:05.81

>>503
tig

0507デフォルトの名無しさん

2013/09/23(月) 14:11:01.02

>>498
forkしたものをそのまま後悔とか？

0508デフォルトの名無しさん

2013/09/23(月) 15:39:50.36

>>500
いいと思うよ。
きちんとバージョン番号振ってくれればそれでいい。

0509デフォルトの名無しさん

2013/09/23(月) 15:44:01.93

バージョン番号って年月日＋ビルド番号じゃないの？
あとそれにブランチ名をくっつけて
バージョン番号。

0510デフォルトの名無しさん

2013/09/23(月) 15:47:07.11

日付も入れるの？

0511デフォルトの名無しさん

2013/09/23(月) 15:48:31.58

よく入ってるよね？

0512453

2013/09/23(月) 15:49:46.64

どなたかお願いします

0513デフォルトの名無しさん

2013/09/23(月) 15:50:56.79

それはアンパンマンに任せよう

0514デフォルトの名無しさん

2013/09/23(月) 15:54:12.16

>>508
分散バージョン管理環境では、
ファイル単位での単純なバージョン番号に依存したら危険なのは理解できる？

0515デフォルトの名無しさん

2013/09/23(月) 15:56:31.87

必要なのは各々のファイルをなんらかのIDで特定できることだよね？

0516デフォルトの名無しさん

2013/09/23(月) 16:41:23.02

バージョン番号が増えていく数字でないと嫌で、$Id$でその数字をファイルに展開したいという人は、gitを使わないほうがいい。
そのやり方は絶対にgitとなじまない。

0517デフォルトの名無しさん

2013/09/23(月) 16:49:18.09

>>514
幹側では分散させない運用なので問題ありません。

0518デフォルトの名無しさん

2013/09/23(月) 16:53:57.06

>>517
ローカルにビルドしたとき困るじゃん？
バージョン番号とファイルの内容が一致してなくて混乱する

0519デフォルトの名無しさん

2013/09/23(月) 18:31:02.61

>>517
>>494でもふれたけど、コミット時のバージョンと今使っているファイルのバージョンがわかれば、あとの調査はバージョン管理システムの仕組みですればいいのだから、ファイル別にとかにこだわる理由はないよね？

それでもこだわりたいのなら、まずはその理由を明確にするべき、今の状態だと単につっているようにしか見えない

ファイル別に数字のバージョンがつくのはciとかco時代の名残だよ。
分散型ではファイル別からプロジェクト別へと管理する単位がシステム的に変わってる

0520デフォルトの名無しさん

2013/09/23(月) 18:41:40.85

そこは「分散型では」ってわけじゃないだろ。

0521デフォルトの名無しさん

2013/09/23(月) 18:47:02.50

ちょっと思いついたことがあるんですけど
gitを使った掲示板ってありませんよね？
pushしてレスするの

0522デフォルトの名無しさん

2013/09/23(月) 18:49:10.22

githubじゃなくて？

0523デフォルトの名無しさん

2013/09/23(月) 19:46:02.04

>>519
gitではまとめて管理「できる」という認識です。

0524デフォルトの名無しさん

2013/09/24(火) 04:00:22.55

>>521
github の wiki

0525デフォルトの名無しさん

2013/09/24(火) 04:12:03.72

>>523
gitでできるかどうかではなく、
自分がどうしたいかで考えなよ。

まず、プロジェクトのファイルってのは
単体でバージョン管理しても意味が無い。

バージョン1のファイルとバージョン2のファイルを
組み合わせて使っても正しく動かないからだ。

バージョン管理の世界は、そうやってファイル単体で
バージョン管理するのは意味が無いよね。ってことで
コミット単位でバージョンを管理する方法に進化してきた。

えっと、ここまでは理解できる？

0526デフォルトの名無しさん

2013/09/24(火) 09:37:19.57

>>521
掲示板じゃないけど、BitbucketのWikiはGitだったよ。

0527デフォルトの名無しさん

2013/09/24(火) 11:21:16.11

>>525
＞自分がどうしたいかで考えなよ
ファイルごとにバージョン番号をつけたいです

0528デフォルトの名無しさん

2013/09/24(火) 11:21:50.94

>>525
＞単体でバージョン管理しても意味が無い
私どもにとっては意味があります

0529デフォルトの名無しさん

2013/09/24(火) 11:22:49.62

>>525
＞バージョン1のファイルとバージョン2のファイルを
＞組み合わせて使っても正しく動かないからだ
それはさらに全体のバージョン（タグ）を使って管理します

0530デフォルトの名無しさん

2013/09/24(火) 11:31:48.90

>>527
ファイル内に直接バージョン書いておいたらいいじゃない
そのファイル単独をgitでバージョン管理したいなら、そのファイルのみでリポジトリ作ってgit submoduleとかで管理すべきでしょ

0531デフォルトの名無しさん

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に日付を展開する程度でも十分だと思うけど

0532デフォルトの名無しさん

2013/09/24(火) 12:03:49.65

git使わないほうがいいんじゃないのか

0533デフォルトの名無しさん

2013/09/24(火) 12:06:47.69

日付フォルダ最強

0534デフォルトの名無しさん

2013/09/24(火) 13:15:42.32

確かにgit使わないが正解だわ

0535デフォルトの名無しさん

2013/09/24(火) 13:21:54.13

普段は日付フォルダにしといて
動作確認出来たまとまったバージョンだけコミットするのもアリ

0536デフォルトの名無しさん

2013/09/24(火) 13:35:31.82

いやいやいやｗ

0537デフォルトの名無しさん

2013/09/24(火) 14:16:02.29

ファイルごとにバージョン管理したいならサブモジュールって手法もある。
やりたい事とあってるかわからないけど。

あと考えついたのはファイル単位でコミットしてコミットする時のコメントでバージョン番号残すとか、それくらいかな。

0538デフォルトの名無しさん

2013/09/24(火) 14:22:58.37

pushしたときに指定したバッチファイルを実行するようにする方法をおしえて

0539デフォルトの名無しさん

2013/09/24(火) 14:33:26.50

>>527
それは目的でなく手段では?
ファイルごとにバージョン番号をつけた結果、何を得られるの?

0540デフォルトの名無しさん

2013/09/24(火) 14:38:04.35

俺も聞こうと思ってたこと>>539が聞いてくれてた
目的決めるのマジ重要

0541デフォルトの名無しさん

2013/09/24(火) 14:46:04.85

>>539
>>528さんが何をしたいのか…。
目的は私も知りたいですけどね。

0542デフォルトの名無しさん

2013/09/24(火) 16:01:08.19

答える側は、それはファイルごとにバージョン付ける以外の方法で解決すべき問題なんだろうと思ってるし、
質問する側は、他の方法で解決するという選択肢はないと思ってる感じ

0543デフォルトの名無しさん

2013/09/24(火) 16:11:18.47

527～529の書きこみが
話が通じてない雰囲気がぷんぷんするね

0544デフォルトの名無しさん

2013/09/24(火) 16:42:08.29

cvsでスキルが停滞してる現場のコード規約なんだろ。あるいは元請けのカスエンジニアあたりが無意味な要求してきたりな。gitでやるが間違い。だからcvsかsvnでやっとけ。
あとgit svnはハマりポイント多いからやめとけ。工数浪費していい事がねえから

0545片山博文MZコスモ ◆T6xkBnTXz7B0

2013/09/24(火) 17:04:37.27

githubで公開したリリースは削除できないの？

0546デフォルトの名無しさん

2013/09/24(火) 17:10:26.19

gitリポジトリをdropboxに保存したいんですが
gitリポジトリを暗号化するほうほうないですか？

0547デフォルトの名無しさん

2013/09/24(火) 17:20:31.51

GitHubはこちら

GitHubやってる？
http://kohada.2ch.net/test/read.cgi/prog/1363523309/

0548デフォルトの名無しさん

2013/09/24(火) 17:42:47.29

皆さん機能追加やバグ修正用のブランチ名ってどんな風にしてますか？
日付、BTSの該当チケットID、機能の簡単な説明文などありますが
どんなものが便利か悩んでます

0549デフォルトの名無しさん

2013/09/24(火) 17:52:36.89

チケットID?

0550片山博文MZコスモ ◆T6xkBnTXz7B0

2013/09/24(火) 18:06:23.06

>>547 移動します。

0551デフォルトの名無しさん

2013/09/24(火) 18:26:06.71

>>544 あの頑固さは規約でそう決まってるみたいな臭いがする態度だな
>>546 微妙にスレチ　なぜ暗号化するのをよく考えてからTrueCryptでｇｇれ
>>548 機能の説明文に一票

0552デフォルトの名無しさん

2013/09/24(火) 19:08:00.49

会社ではJira issueのIDを名前にしてブランチ切っている。

0553デフォルトの名無しさん

2013/09/24(火) 21:36:32.42

>>544
git svnのハマりポイントって何?
使ってるから予め知っておきたい。

0554デフォルトの名無しさん

2013/09/24(火) 21:38:24.93

>>527
> ＞自分がどうしたいかで考えなよ
> ファイルごとにバージョン番号をつけたいです

それは本当にお前がやりたいことなのか？

やりたいと思っているならば、
そこに理由が必ず存在するはずだ。

その理由を言ってみてくれ。
それがないなら、実はやりたいとは思っていないということになる。

0555デフォルトの名無しさん

2013/09/24(火) 22:18:37.96

ファイルに付いたバージョン番号を眺めるのが趣味なのかもしれない

0556デフォルトの名無しさん

2013/09/24(火) 22:52:06.22

>>553
別人だけどsvnの外部参照は使えないと思った方が良さそうだったよ

0557デフォルトの名無しさん

2013/09/26(木) 04:25:57.70

>>553
svnを単体プロジェクト推奨レイアウト使ってれば早々困ることはない。
svnはフリーダムな運用が可能で、現場だとかなりワイルドな使い方をされる事が多いからgit svnだと追跡しきれない事がままある。gitはファイル名文字コード問題も完全じゃない。あと忘れた。
個人なら中央もgitでFAだな

0558デフォルトの名無しさん

2013/09/26(木) 11:02:15.52

githubにpull requestを送る方法って
そのリポジトリにmasterブランチ以外のブランチでプッシュするだけでいいですか？

0559デフォルトの名無しさん

2013/09/26(木) 11:45:36.56

GitHub固有のサービスの質問はこちらへ

GitHubやってる？
http://kohada.2ch.net/test/read.cgi/prog/1363523309/

0560デフォルトの名無しさん

2013/09/26(木) 12:09:44.75

pull requestはgithub固有の内容じゃないのでここでOKです

0561デフォルトの名無しさん

2013/09/26(木) 12:25:57.02

じゃあ、git request-pullの話をしましょう

0562デフォルトの名無しさん

2013/09/26(木) 23:47:09.46

>>559
つい先日まで静かだったスレが活気づいててワロタ

0563デフォルトの名無しさん

2013/09/28(土) 13:52:09.53

ブランチの特定のファイルだけマスターにマージって出来ないのでしょうか？

ブランチの特定のファイルの何行以下だけ
マスターにマージという形も出きるといいのですが

0564デフォルトの名無しさん

2013/09/28(土) 14:00:02.33

ほしいファイルだけぬくかたちでコミットし直してマージかなぁ。
ソースツリーかえるとあとでコンフリクトしそう

0565デフォルトの名無しさん

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
基本的にこれしか知りません

0566デフォルトの名無しさん

2013/09/28(土) 21:05:45.92

ここはgitスレだぞ、そんな程度で許される訳がないだろう
今すぐ$ git clone https://github.com/git/gitして原典をくまなく読むんだ

0567デフォルトの名無しさん

2013/09/28(土) 21:09:06.43

先輩すいませんでした今すぐ読んできます

0568デフォルトの名無しさん

2013/09/28(土) 21:10:53.01

>>565
使ってるところはほとんど無いと思う。
まだ趣味の世界。

といか、職場でうちらが布教活動する感じだね（笑

rebaseの使い方、とくにontoを指定するケースは、覚えた方がいい。
branchの移動や部分的な取り込みで使う。

0569デフォルトの名無しさん

2013/09/28(土) 21:13:19.07

至急！！！！！
他人のリポジトリにDeleteボタンがありますけどこれ勝手に押したら消えますか？
https://github.com/git/hello-world/blob/master/php.php

0570デフォルトの名無しさん

2013/09/28(土) 21:21:53.38

GitHub固有のサービスの質問はこちらへ

GitHubやってる？
http://kohada.2ch.net/test/read.cgi/prog/1363523309/

0571デフォルトの名無しさん

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

0572デフォルトの名無しさん

2013/09/28(土) 21:29:06.06

deleteボタンにカーソルを合わせただけです

0573デフォルトの名無しさん

2013/09/28(土) 21:32:36.13

>>569

>>437-448 あたりをよく読め
ハローワールドなんか作ってんじゃねえぞ
さっさと消せ

0574デフォルトの名無しさん

2013/09/29(日) 09:11:01.63

>>563
1) --no-commitでコミット前に止める。
2) マージしたくないファイルをcheckout HEAD ファイル名で戻す。
マージしたくないファイルが大量にある場合はマージしたいファイルの方をリネームなりでとって置いてからcheckout HEAD . で全ファイルを戻し、とって置いたファイルでさらに上書きする
3) addしてcommit

0575デフォルトの名無しさん

2013/09/29(日) 09:17:00.49

注意事項として、git的にはmasterに反映しないことを選んだファイルも含めてマージされたことになるから、後から残りのファイルをマージしようとしても上手く行かない。
段階的にマージすることが目的ならマージ元のコミットを分割する方が良い。

0576デフォルトの名無しさん

2013/09/29(日) 16:28:13.98

JavascriptでGitを再実装したら
340万円もらえるってよ

JS-Git - Fundraisers
https://www.bountysource.com/fundraisers/325-js-git

0577デフォルトの名無しさん

2013/09/29(日) 18:39:11.74

javascriptってファイル操作とか出来たんだっけ？

0578デフォルトの名無しさん

2013/09/29(日) 18:42:16.53

いまどきのは出来るよ

0579デフォルトの名無しさん

2013/09/30(月) 01:54:49.17

Gitで、
「どこそこにあるリポジトリのこのコミット」
を表すにはどう示す（書く）のいいでしょうか? よく使われる書式があったりしないでしょうか?
リポジトリのURLとコミットIDがあれば情報としては足りますが、ブランチ名もいっしょに示したほうが親切かなと思ってます。

0580デフォルトの名無しさん

2013/09/30(月) 02:02:33.99

リポジトリのURLとコミットID書いて、コメントでブランチ名を追加すれば？
同じことでしょ？ｗ

0581デフォルトの名無しさん

2013/10/01(火) 03:23:36.75

sirokuma @Wiki - gitコマンド
ttp://www11.atwiki.jp/sirokuma/pages/40.html

0582デフォルトの名無しさん

2013/10/01(火) 16:30:09.33

gitのコマンドは直感的じゃ無いからな・・・
cvsのコマンド形態で分散型ならよかった

0583デフォルトの名無しさん

2013/10/01(火) 17:08:45.07

コミットオブジェクトの意味が理解できると安心して無茶ができるようになって快適なのだけどね
そのへんが理解できてないと各操作が恐ろしい

0584デフォルトの名無しさん

2013/10/01(火) 17:14:00.60

>コミットオブジェクトの意味

はよ説明

0585デフォルトの名無しさん

2013/10/01(火) 17:55:16.57

>>584
この辺から勉強してみたらいいんじゃないか？
http://keijinsonyaban.blogspot.jp/2011/05/git.html

0586デフォルトの名無しさん

2013/10/01(火) 18:07:59.45

㌧

0587デフォルトの名無しさん

2013/10/01(火) 19:02:06.23

あのオプション体系考えたの誰なんだろう
センス無さすぎる

0588デフォルトの名無しさん

2013/10/01(火) 19:03:55.31

おみゃーがセンスあるものを作れにゃー

0589デフォルトの名無しさん

2013/10/01(火) 21:40:30.82

gitのcheckouｔって日本語に訳すならどんな感じになる
一般英語ならcheck outは「貸し出す」ってことだけどgitのもそんな感じでおｋ？

0590デフォルトの名無しさん

2013/10/01(火) 21:47:34.99

片仮名でチェックアウト以外の何物でもないと思うが……
君、ホテルのチェックアウトはどう表現しているんだい。

0591デフォルトの名無しさん

2013/10/01(火) 21:51:27.47

外泊

0592デフォルトの名無しさん

2013/10/01(火) 21:51:56.31

gitの場合、他のVCSが使ってたコマンドに相当する機能程度の意味だよ
gitのcheckoutには少なくとも3つの別の機能があるしね

0593デフォルトの名無しさん

2013/10/01(火) 21:56:14.94

gitのcheckoutに○○しつつチェックアウト
以外の機能ってなんかあるのか？

0594デフォルトの名無しさん

2013/10/01(火) 21:56:45.21

>>590
普通に「精算」でしょ

0595デフォルトの名無しさん

2013/10/01(火) 22:27:27.68

チェックメイトで

0596デフォルトの名無しさん

2013/10/01(火) 22:50:55.81

むしろ、一連の作業の開始って意味では
「チェックイン」の方がホテル的にイメージに合ってるんじゃね？
とか10年以上前にVCSの話を聞いたときにフーンと思った

0597デフォルトの名無しさん

2013/10/01(火) 23:09:39.50

チェックアウト

荷物（リポジトリ）を持ってホテル（masterブランチ）から出る

0598デフォルトの名無しさん

2013/10/01(火) 23:10:37.88

チェックアウト

精算（現時点のリポジトリをまとめて）してホテル（masterブランチ）から出る

0599デフォルトの名無しさん

2013/10/01(火) 23:29:15.83

チェケラッチョ♪

0600デフォルトの名無しさん

2013/10/02(水) 01:18:36.75

>>582
cvsは知らんけどsvn使ってた俺から見ればgitよりhgのほうが直感的だと思う

0601デフォルトの名無しさん

2013/10/02(水) 01:24:50.52

自分が知っているものと同じか似ているものを"直感的"って言う人って居るよね。

0602デフォルトの名無しさん

2013/10/02(水) 01:26:45.81

git使いのことだな

0603デフォルトの名無しさん

2013/10/02(水) 01:27:24.71

QWERTY配列は直感的です。

0604デフォルトの名無しさん

2013/10/02(水) 01:28:07.39

checkoutというのが直観的かどうか

0605デフォルトの名無しさん

2013/10/02(水) 01:52:03.98

数字の箱とか犬クラスに近い危険な香りがする

0606デフォルトの名無しさん

2013/10/02(水) 06:33:31.87

>>601はmercurialとcvsを使ったことがない

0607デフォルトの名無しさん

2013/10/02(水) 09:58:56.69

荒らしと関わらない場合は「完全スルー」がベスト。

0608デフォルトの名無しさん

2013/10/02(水) 10:29:06.07

hgの方がコマンド体系は良く出来ている
と思う

0609デフォルトの名無しさん

2013/10/02(水) 10:41:34.04

hgのことなんて知らない奴の方が多いんだから
どう良く出来てるのか説明できないなら便所の落書きだな

0610デフォルトの名無しさん

2013/10/02(水) 11:58:40.80

毎日新聞か

0611デフォルトの名無しさん

2013/10/02(水) 13:21:44.00

井の中の蛙大海を知らず

0612デフォルトの名無しさん

2013/10/02(水) 14:32:42.79

【分散型バージョン管理】 Mercurial 2【hg】
http://toro.2ch.net/test/read.cgi/tech/1321109748/

0613デフォルトの名無しさん

2013/10/02(水) 14:38:37.67

gitしか知らない馬鹿が増えてきたな

0614デフォルトの名無しさん

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/

0615デフォルトの名無しさん

2013/10/02(水) 15:40:21.53

>>606は自分に理解できるレベルのことを直感的と言う。

0616デフォルトの名無しさん

2013/10/02(水) 15:40:43.14

プロジェクトに途中から参加する場合、まず最初にやるのは
git cloneですか？

あと毎日最初にやるのはgit fetchですか？

0617デフォルトの名無しさん

2013/10/02(水) 15:56:30.53

>>616
普通は fork かなぁ
clone したあとすぐ branch 作るならそれでもいい

0618デフォルトの名無しさん

2013/10/02(水) 20:10:48.65

forkってどうやるの
git fork http://～
て感じ？

0619デフォルトの名無しさん

2013/10/02(水) 20:23:20.85

>>601
それすげー同意。超あるあるだわ
git使いとかってほんとにgitを直感的とか思い込んでて怖いよね

0620デフォルトの名無しさん

2013/10/02(水) 20:42:50.04

このスレ読み返してみたけどgitのコマンドを直感的って言ってるやつは一人もいないよ
hgのコマンドを直感的って言ってるやつはいるけど

0621デフォルトの名無しさん

2013/10/02(水) 20:43:42.97

>>618
forkはgithubのことだろう
git一般的にはcloneでいいよ

0622デフォルトの名無しさん

2013/10/02(水) 21:11:45.22

互いにライバルとしてgitとmercurialは現在似たような機能を有するようになってるけど
根本的にアプローチが違うと思う
mercurialは既存のVCSの延長線上で今風の要請に応える形だが、gitは既存のVCSの否定から
始まって、UIを既存のVCSに寄せていった形

0623デフォルトの名無しさん

2013/10/02(水) 21:35:51.46

VCS?

0624デフォルトの名無しさん

2013/10/02(水) 21:36:23.11

Version Control System

0625デフォルトの名無しさん

2013/10/02(水) 21:45:45.85

GitとMercurialについて語りたいならこっちのスレでやれや

バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/

0626デフォルトの名無しさん

2013/10/02(水) 23:34:00.79

>>619
gitを使い込んでて、あのコマンド、オプション体系を直感的だと思う奴はいないと思う
慣れればなんとかなるとは思ってるだろうけど

0627デフォルトの名無しさん

2013/10/03(木) 00:40:21.78

何をどう直せと言ってるんだ？

0628デフォルトの名無しさん

2013/10/03(木) 00:44:44.16

別に直す必要はないよ
シェルの補完とかがあればそのまま使うのも問題無いし
頻繁に使うコマンドやオプションは自分で定義しなおせばいい

0629デフォルトの名無しさん

2013/10/03(木) 01:44:05.10

>>628
うん。それは知ってる。

どう直せと言ってるのか知りたいだけ

0630デフォルトの名無しさん

2013/10/03(木) 02:02:37.77

>>629
直感的ではないというだけの話だろ
どう直したら直感的になるか、なんて知るかよ

0631デフォルトの名無しさん

2013/10/03(木) 02:07:51.12

コマンドが全部日本語的になれば日本人にとって直感的になるんじゃね

英語だとcheckoutみたいに何となく意味をとらえづらいというか
checkoutとはそういうもんだと言う認識が出来るまでの辛抱ではあるが

0632デフォルトの名無しさん

2013/10/03(木) 02:13:41.04

それだと結局、直感＝自分の知ってるものと同じにしかならないだろ。

ソースコードのバージョン管理なんか普段の生活でやらないだろ？

例えばタッチパネルの使い方みたいに指で触れば動くという使い方は
タッチパネル以外の普段の生活でやることなんで”直感的” という考えは成り立つ。

でもソースコードのバージョン管理は、似たようなものが他にない。
だから直感的なんて考え方がそもそもありえない。
あるとするならば、自分が知ってる他のバージョン管理ソフトと同じかどうかって言うこと。

他の人も言ってるように、直感的なんて言葉を使わずに、
俺の知ってる○○とコマンド体系が違うヤダヤダって言えばいいんだよ。

0633デフォルトの名無しさん

2013/10/03(木) 02:15:30.67

>>631
git ソースコード編集開始とでも書けばわかるのか？
全然日本語が適切じゃないが。

どっちみち専門用語にしかならんのだから
直感的になることなんてありえないよ。

0634デフォルトの名無しさん

2013/10/03(木) 02:25:24.86

バージョン管理のコマンド系に命名規則の規格を設ければいいんだよ！

0635デフォルトの名無しさん

2013/10/03(木) 02:27:25.75

checkoutにこだわっちゃってる奴がいるんだな
CVSとかと意味が違うから、気になって、気になって、気になって、仕方無いんだろうな

0636デフォルトの名無しさん

2013/10/03(木) 02:34:35.25

>>631
日本語とかそういうのじゃないよ。gitのコマンドは引数によって同じコマンドでも
想像していた動きと違う動きをする部分でしょ。作りながら色々と機能追加する
場合によくある。ルールを決めてやり直すには普及しすぎてるのが頭の痛い
ところだろうね。

0637デフォルトの名無しさん

2013/10/03(木) 02:38:56.02

>>636
だからー。それがなにか言えって。

ぐだぐだしてるのは、それが何かを言ってないから
誰も賛同しようがないんだよ。

0638デフォルトの名無しさん

2013/10/03(木) 02:40:41.00

>>636
たとえばどんなコマンドですか？checkout？ｗｗ

0639デフォルトの名無しさん

2013/10/03(木) 02:42:03.92

checkoutがブームなん？

0640デフォルトの名無しさん

2013/10/03(木) 02:45:50.82

0641デフォルトの名無しさん

2013/10/03(木) 02:49:19.17

まずリポジトリってのはgitは分散型だから
”ローカル”に有るんだよね。

0642デフォルトの名無しさん

2013/10/03(木) 03:03:33.54

RCSとSCCSが無い

0643デフォルトの名無しさん

2013/10/03(木) 03:04:35.61

ハードゲイ

0644デフォルトの名無しさん

2013/10/03(木) 04:10:01.57

頻繁に使う機能にオプション2個指定が必要とか

0645デフォルトの名無しさん

2013/10/03(木) 04:25:04.52

なぜ違うものを比べようとするのか。

0646デフォルトの名無しさん

2013/10/03(木) 04:34:15.12

必要に応じて何でも覚えていけばいいさ

0647デフォルトの名無しさん

2013/10/03(木) 05:11:13.45

物覚えが悪くなった
あとせっかく覚えても
すぐ忘れるようになった

0648デフォルトの名無しさん

2013/10/03(木) 05:43:21.83

>>644
具体的に何のコマンドの何のオプションですか？

0649デフォルトの名無しさん

2013/10/03(木) 09:28:01.72

・checkoutにbranchの切り替えとファイルの取り出し(上書き確認も無し)の2つの用途がある
・gitのrevertとcvs/svn/hg/bzrのrevertは全く意味が違う
・git独特のstaging
hgも使い込むとrecord,mqに手を出すだろうからstagingは擁護できるが上2つはちょっとね
今更変えられないだろうけど

0650デフォルトの名無しさん

2013/10/03(木) 09:30:39.20

checkoutは有名だとして、他にはbranchとかかね。
引数無し→全ブランチの表示
引数1個→現在のブランチから引数で指定した名前のブランチの作成
引数2個→2つ目に指定したブランチから1つ目に指定したブランチの作成
引数1個+mオプション→現在のブランチの名前を引数で指定した名前に変更
引数2個+mオプション→1つ目に指定したブランチの名前を2つ目に指定した名前に変更
引数1個以上+dオプション→指定したすべてのブランチを削除

あと、diffはよくワーキングディレクトリとHEADの指定を間違うな。差分が出なくて、あれ？って思うことが多い。

0651デフォルトの名無しさん

2013/10/03(木) 09:50:49.69

結局checkoutだけなんだな

stagingもrevertも単にgit側の仕様が気に喰わんって言ってるだけじゃないか

branchはcreate-branchとかmv-branchとかdelete-branchとか作れってことか？
そんなのはメンドクサイだけなんで勘弁してほしい

diffは具体的にどうしろと？
いまのHEAD、index、workの構造に忠実な指定方法よりいいのがあるのか？

0652デフォルトの名無しさん

2013/10/03(木) 09:52:59.05

頻繁に使う機能にオプション2個指定が必要な例はどうなった？

0653デフォルトの名無しさん

2013/10/03(木) 10:33:35.36

とりあえずバージョン管理はgitからはじめてるんですけど
他にも有名なバージョン管理システムにsvnとかhgがあるじゃないですか
gitを覚えれば他の2つも簡単に覚えられますか？

0654デフォルトの名無しさん

2013/10/03(木) 10:41:45.11

覚えられません。

0655デフォルトの名無しさん

2013/10/03(木) 10:59:36.99

むしろgitは最後にした方がいい

0656デフォルトの名無しさん

2013/10/03(木) 11:08:54.50

branchは別にサブコマンドでいいけど、stashやtagと微妙に統一されてないのはなんとかしてほしい

0657デフォルトの名無しさん

2013/10/03(木) 11:16:51.29

>>656
stashやtagと何を統一すればいいの？

0658デフォルトの名無しさん

2013/10/03(木) 11:17:15.25

gitは内部仕様がコマンド体系に中途半端に現われてしまっているのが失敗してる。
svnの「ブランチとタグはありましぇーん」と同じ失敗。

0659デフォルトの名無しさん

2013/10/03(木) 11:20:01.64

>>657
オプション。git branch(オプション無し)、git stash list、git tag --listみたいな。

0660デフォルトの名無しさん

2013/10/03(木) 11:20:13.06

ブランチだろうがタグだろうがコミットだろうが全部hashで指定できるのがすごく気に入ってる

0661デフォルトの名無しさん

2013/10/03(木) 11:26:01.92

>>659
git branch --list は使えますよ
git stash の次はコマンドで統一されてるんで --list とかにされても困ります

0662デフォルトの名無しさん

2013/10/03(木) 11:30:50.73

>>661
そもそも
>git stash の次はコマンドで統一されてるんで
がtagもstashもそうなってなかったり、オプション無しの動作がバラバラだったりするのは気にならんのかね？

0663デフォルトの名無しさん

2013/10/03(木) 11:50:15.75

>>662
オプション無しの動作は統一されるより良く使われる機能が割り当てられるべきだとおもうけど？

一部コマンドが2段階になってるのも、
無理に1段階にして妙な名前になったり妙なオプション指定することになるよりはいいかな

そんなことが気になるようだと、一般的なUnixコマンドの中に
hg xxx とか git xxxみたいな二段階コマンドが紛れ込んでるのも気になるの？

0664デフォルトの名無しさん

2013/10/03(木) 11:56:50.65

なんでgitは最後のほうがいいんですか？
やっぱりnoobお断りな
プログラミング言語で言えばパソコン初心者がいきなりC++を覚えるとか
小学生がいきなり東大入試受けるぐらいの最難関なソフトウェアなのですか？

0665デフォルトの名無しさん

2013/10/03(木) 12:18:33.83

>>663
ちげー。
git stashがサブコマンド的記法をするならgit tagも-mや-rじゃなくてgit tag mvやrmでいいだろって話だ

0666デフォルトの名無しさん

2013/10/03(木) 12:29:18.26

>>665
それをやっちまったら使いにくいだろう
gitやhgも他のUnixコマンドに合わせて
サブコマンド指定なんてやめて全部オプションでやれって言ってるようなもんだ

0667デフォルトの名無しさん

2013/10/03(木) 12:40:43.18

普通のコマンドはサブコマンド指定なんか無しでオプション指定だけの方がいいね
でもgitやhgみたいな複雑なコマンドは、オプションよりもサブコマンドにしたほうがいいね

普通のサブコマンドは2段階のサブコマンド指定なんか無しでオプション指定だけのほうがいいね
でもgit stashやgit bundleみたいな複雑なサブコマンドは、オプションよりも2段階のサブコマンドのほうがいいね

0668デフォルトの名無しさん

2013/10/03(木) 12:55:36.79

なんつう一貫性のなさ。
tagもstashもbranchも、中に作成、リネーム、削除、一覧などを内包してるという意味では揃えるべき。
>>667の論で言うならbundleなんかオプションでいい

0669デフォルトの名無しさん

2013/10/03(木) 13:09:09.41

stashやbundleのサブコマンドを適当にオプションなんかに割り振られたら泣くわｗ
やたら一貫性を重視するやつのUIは使いにくくてかなわん

0670デフォルトの名無しさん

2013/10/03(木) 13:12:18.92

全部をサブサブコマンド化は勘弁だし
全部をサブコマンド+オプションにするのもサブコマンドが増えてくるとオプションのパターンが増えすぎだと思うし

昔から存在するよく使われるコマンドはサブコマンド+オプションで、
あとから追加された新しい概念のコマンドはサブサブコマンドみたいな感じなのは、わりと妥当だと思うけどね

0671デフォルトの名無しさん

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になったら使いにくそうだな・・・
どっちかに揃えるとか却下だな

0672デフォルトの名無しさん

2013/10/03(木) 14:33:01.22

まあ、要するに直感的を目指すと一貫性を追求することになって冗長かつ使いにくくなるんだよ
だからgitには慣れるしかない

0673デフォルトの名無しさん

2013/10/03(木) 14:52:05.89

冗長で結構
使いやすさに関しては好きにエイリアス作ればええねん
git brd (git branch -D) とか
git std (git stash drop) とか

0674デフォルトの名無しさん

2013/10/03(木) 15:01:59.39

慣れれば良いだけならどっちでも良いだろ

0675デフォルトの名無しさん

2013/10/03(木) 15:27:14.37

AndroidとiPhoneの2つのスマートフォンを使っていますという感じか。
どっちももはやスマートフォンってレベルじゃねーよというｗ

0676デフォルトの名無しさん

2013/10/03(木) 15:35:45.39

スレが超加速しててワロタ

0677デフォルトの名無しさん

2013/10/03(木) 16:22:09.47

>>664
gitの良さを味わっちゃったら他のクソCVSにはもう触りたくない
そんな話でしょ

0678デフォルトの名無しさん

2013/10/03(木) 16:24:00.55

またgit信者が来たか・・・
お互いの利点を確認できるって意味だろ
gitしか知らない奴はホント屑ばっかだな

0679デフォルトの名無しさん

2013/10/03(木) 16:26:48.07

個人でCVSを使う分には好きなのを選べばいいし
他人のプロジェクトに参加したいんならそこの流儀に合わせればいい
何の議論の余地もない

0680デフォルトの名無しさん

2013/10/03(木) 16:27:19.41

CVS?

0681デフォルトの名無しさん

2013/10/03(木) 16:37:18.46

>>680
Version Control SystemのVCSのつもりでした　恥ずかしい

>>678
はい、煽りに対して煽りを書いた屑です。サーセン

0682デフォルトの名無しさん

2013/10/03(木) 16:57:50.79

ttp://gitolite.com/gcs/index.html

0683デフォルトの名無しさん

2013/10/03(木) 17:46:28.94

cvsでできてgitではできないことって結構多いからな
その機能を必要としていた人にはちょっとつらい

0684デフォルトの名無しさん

2013/10/03(木) 17:48:47.56

たとえば？

0685デフォルトの名無しさん

2013/10/03(木) 17:50:51.07

その機能の必要性は？(ﾆﾔｧ

0686デフォルトの名無しさん

2013/10/03(木) 17:52:19.87

今日のお祭り会場はこちらですか？

0687デフォルトの名無しさん

2013/10/03(木) 19:13:08.80

svnからの移行が自然なのはhg
gitは何でもやろうとして何がなんだか分からなくなる

0688デフォルトの名無しさん

2013/10/03(木) 19:24:24.27

つまり、githubはオワコン？

0689デフォルトの名無しさん

2013/10/03(木) 19:30:56.97

>>683
任意のmodule単位のcheckoutは便利だな。それを想定して作ったリポジトリは未だにcvsで運用してる。
多いとは思わないけど。

0690デフォルトの名無しさん

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 - は不可能というのも不思議

0691デフォルトの名無しさん

2013/10/03(木) 22:03:49.67

https://code.google.com/p/git-core/downloads/list
git　1.8.4.1

0692デフォルトの名無しさん

2013/10/03(木) 22:26:08.52

C言語とJavaと違うからって文句言うのか！gitとcvsが違うからって文句言うわがままな奴は

0693デフォルトの名無しさん

2013/10/03(木) 22:42:19.78

すいません！
前回commitしたファイルを全部知りたいんですがどうやって調べるのか教えてください

0694デフォルトの名無しさん

2013/10/03(木) 22:52:21.16

こう？
git log --stat

0695デフォルトの名無しさん

2013/10/03(木) 23:03:40.18

git log --name-stat HEAD~1..HEAD

0696デフォルトの名無しさん

2013/10/03(木) 23:30:15.65

>>694-695
たすかりました！

0697デフォルトの名無しさん

2013/10/04(金) 11:05:23.93

Rubyにgollumっていうwikiエンジンがあるじゃないですか
あれはgitにコミットするとデータが反映するそうなんですが
どうやって最新の内容を取得しているのでしょうか？

0698デフォルトの名無しさん

2013/10/04(金) 11:08:59.92

ソース嫁

0699デフォルトの名無しさん

2013/10/04(金) 11:41:58.92

リポジトリへのコミット時にリポジトリからデータ取り込むスクリプト起動？とか想像したが
こいつはHTTPアクセス時にリポジトリから直接データ取って来てページ作ってんのかな

0700デフォルトの名無しさん

2013/10/05(土) 13:47:01.95

github、RubyとMVCの限界を悟りC#とMVVMに全面移行　／　オープンソース界に激震
http://engawa.2ch.net/test/read.cgi/poverty/1380941226/

0701デフォルトの名無しさん

2013/10/05(土) 13:52:53.27

ビックウェーブきたなｗｗｗ

0702デフォルトの名無しさん

2013/10/05(土) 16:36:44.30

twitterもRuby使うのやめたって言ってたし
Rbyってそんな使えないんか

0703デフォルトの名無しさん

2013/10/05(土) 16:37:59.12

日本人は役立たずってことか

0704デフォルトの名無しさん

2013/10/05(土) 16:46:35.63

GitHubやってる？
http://kohada.2ch.net/test/read.cgi/prog/1363523309/

0705デフォルトの名無しさん

2013/10/05(土) 17:52:43.51

>>702
立ち上げには良いけど、長期的にメンテし続けるには向かないってことでしょ

0706デフォルトの名無しさん

2013/10/05(土) 23:17:18.40

処理系として気が効いてる分、負荷は高い。
rubyでさっさと立ち上げて、アクセス集中して負荷に耐えられないくらいになれば
大成功ってわけで。

まあ、実際はそのままぽしゃるプロジェクトが大量に存在してるんだけどな。

0707デフォルトの名無しさん

2013/10/05(土) 23:25:47.85

railsってそんなに生産性高いの？

0708デフォルトの名無しさん

2013/10/05(土) 23:38:17.57

全面移行とかデマじゃないか

0709デフォルトの名無しさん

2013/10/05(土) 23:53:35.57

>>707
素のRubyに比べたら
そうとう生産性高いよ。

他のフレームワークと比べたら
同じぐらいだけど。

0710デフォルトの名無しさん

2013/10/07(月) 03:26:42.80

>>705
railsは立ち上げはもちろん長期的にメンテし続けるのにもそんな悪くないよ
問題はサービスの規模が大きくなるのに合わせて拡張しようとするとき、
主にコスト的な面でより効率的な選択肢が他にいろいろあるというだけ

0711デフォルトの名無しさん

2013/10/07(月) 12:35:54.01

>>710
railsというかrubyの問題だけど長期間メンテナンスしてるとinstance_ofだらけになる。

0712デフォルトの名無しさん

2013/10/08(火) 00:40:20.10

railsはやっぱり覚えるべきか・・・

0713デフォルトの名無しさん

2013/10/08(火) 09:37:27.60

しかしC#だとmono必須か、、環境によってはRailsより入れにくい

0714デフォルトの名無しさん

2013/10/08(火) 09:40:35.16

C#やるならどうせwin鯖だろ

0715デフォルトの名無しさん

2013/10/08(火) 09:46:28.75

githubがC#使うとか言ってるのはクライアントの話だから鯖とか関係ない

0716デフォルトの名無しさん

2013/10/08(火) 09:51:16.29

今までクライアントにRuby使ってたのか

0717デフォルトの名無しさん

2013/10/08(火) 09:53:26.81

クライアントとサーバーのコードを共通化出来るに越したことないから、そのうちサーバーサイドもc#になるかもね
mono使ってるんだから、サーバーはそのままunixサーバーでいいわけだし

0718デフォルトの名無しさん

2013/10/08(火) 10:24:47.74

>>716
いままではC++とかJavaとかかな

0719デフォルトの名無しさん

2013/10/08(火) 11:16:06.91

つまりmsysgitっていうのをインストールするとき.NETフレームワークがないと使えないってことですか？

0720デフォルトの名無しさん

2013/10/08(火) 11:24:04.94

Gitに関係ないから>>704でやれ

0721デフォルトの名無しさん

2013/10/08(火) 12:26:45.32

>>720はgithubスレを立てた>>1

0722720

2013/10/08(火) 13:43:10.99

>>721
https://github.com/hub2ch/hub2ch
こんな恥ずかしいやつと一緒にするなｗ

0723デフォルトの名無しさん

2013/10/08(火) 13:46:34.06

forkボタン押すとforkした連中が見られるのな

0724デフォルトの名無しさん

2013/10/08(火) 16:28:12.37

najeira: Gitの運用ルール、ワークフローを考えてみた 2
http://najeira.blogspot.jp/2013/04/git-2.html

これってどうなん？妥当な方法なん？

0725デフォルトの名無しさん

2013/10/08(火) 19:29:15.12

うんこ

0726デフォルトの名無しさん

2013/10/08(火) 23:40:47.47

指定した二つのコミットの間で変更、追加、削除したファイルの一覧を表示する方法は？

0727デフォルトの名無しさん

2013/10/09(水) 00:13:07.35

git logを自分好みでguiに表示したいんですけど
apiみたいなのってないんですか？

0728デフォルトの名無しさん

2013/10/09(水) 01:14:06.53

git logに--formatオプション食わせれば好きなフォーマットでデータ吐いてくれる

0729デフォルトの名無しさん

2013/10/09(水) 02:59:26.76

>>726
こう？
git diff --name-stat commit1..commit2

0730デフォルトの名無しさん

2013/10/09(水) 09:46:15.04

git log --format=jsonとかxmlとかcsvってやってみたけどデータとれなかった
嘘を教えられたのだ！

0731デフォルトの名無しさん

2013/10/09(水) 09:54:14.20

>>730
man読めよ。

0732デフォルトの名無しさん

2013/10/09(水) 10:14:36.95

>>730
ほんまもんのアホがいる

0733デフォルトの名無しさん

2013/10/09(水) 10:59:34.25

非分散型のgitって無い？

0734デフォルトの名無しさん

2013/10/09(水) 11:02:21.67

>>733
svnとか使えばいいだろ

0735デフォルトの名無しさん

2013/10/09(水) 12:11:51.81

svnはあの開発陣のCVSヘイトっぷりが怖くてキモくて嫌だった

0736デフォルトの名無しさん

2013/10/09(水) 12:16:11.60

>>735
ならCVS使っとけ
というかというかこっちのスレに行け

バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/

非分散型が目当てならgitには全く関係無い

0737デフォルトの名無しさん

2013/10/09(水) 12:29:15.77

分散型でも一点のみで使ったら事実上は非分散では？

0738デフォルトの名無しさん

2013/10/09(水) 12:43:44.47

gitはローカルリポジトリだけだと一人でしか使えないじゃん

0739デフォルトの名無しさん

2013/10/09(水) 13:44:08.60

>>733
非分散(集中？)な時点でgit のメリットの8割を失ってね？

0740デフォルトの名無しさん

2013/10/09(水) 16:11:11.59

そうか
開発中はgitで自由に開発して、リリースの段階になったら
svnにコミットすればいいのか。

これですべての問題が解決しそうだぞ。検討してみる

0741デフォルトの名無しさん

2013/10/09(水) 17:08:47.75

それなら中央もgitでいいじゃん

0742デフォルトの名無しさん

2013/10/09(水) 17:20:03.03

中央までgitにしたら困らない？大丈夫？

0743デフォルトの名無しさん

2013/10/09(水) 17:26:52.31

サーバがsvnのときとgitのときで大きく違うのはリポジトリ作成と公開の部分だよね

0744デフォルトの名無しさん

2013/10/09(水) 18:07:35.30

複数人で使うときに使うコマンドを全部おしえて

0745デフォルトの名無しさん

2013/10/09(水) 18:13:02.62

>>744
流石に全部となると、git入門とかでググったほうがいいんじゃね

0746デフォルトの名無しさん

2013/10/09(水) 19:25:45.68

>>742
何が困るんだ？

0747デフォルトの名無しさん

2013/10/09(水) 22:42:54.73

>>740
オールgitに比べて、中央svnローカルgitにする利点ってなんだ？
中央svnローカルgitは分散管理のままなのは理解してるかな？

0748デフォルトの名無しさん

2013/10/09(水) 23:01:38.55

オールgit・・・gitだけを覚えれば良い
git+svn・・・gitとsvn、そしてgitとsvnの連携の三つを覚えないといけない。

たとえsvnの経験者であったとしても
git+svnは、svnを忘れてgitだけを覚えればいいのと違い
gitとsvnの連携という、余計なことを覚えないといけない。

0749デフォルトの名無しさん

2013/10/09(水) 23:22:06.54

非分散管理希望とか言っといて
svn+gitで問題解決とかわけがわからんなｗ

0750デフォルトの名無しさん

2013/10/10(木) 00:00:56.81

今Gitサーバをインストールするなら何がお勧め？
数人程度の単一プロジェクトで

0751デフォルトの名無しさん

2013/10/10(木) 00:17:49.15

Gitを入れるのがいいんじゃないかな？

0752デフォルトの名無しさん

2013/10/10(木) 00:34:04.52

>>750
gitlabお勧め

0753デフォルトの名無しさん

2013/10/10(木) 00:37:06.29

その数人がUnixアカウントやssh使うのに抵抗が無ければ、
特別なものを入れる必要もないけどねえ

0754デフォルトの名無しさん

2013/10/10(木) 00:46:07.25

>>753
じゃあ聞くが、中央リポジトリどうやってんの？
そこにコミットされたものの把握とかどうやってんの？
コミットされたコードに対するコメントやレビューどうやってんの？
複数人で共有しているリポジトリの管理どうやってんの？
masterへのマージどうやってんの？
不正（質の悪い）コードのマージをどうやって管理してるの？

人が数人集まるってことは、
コミュニケーションが生まれるってこと。
gitだけでどうやってコミュニケーションするの？

0755デフォルトの名無しさん

2013/10/10(木) 00:58:44.32

＞中央リポジトリどうやってんの？
＞そこにコミットされたものの把握とかどうやってんの？
＞ masterへのマージどうやってんの？
このへんは別に特別なものはいらんな
UNIXアカウント+sshだけでおｋ

＞複数人で共有しているリポジトリの管理どうやってんの？
リポジトリの管理って具体的に何？

＞不正（質の悪い）コードのマージをどうやって管理してるの？
＞コミットされたコードに対するコメントやレビューどうやってんの？
＞人が数人集まるってことは、
＞コミュニケーションが生まれるってこと。
＞ gitだけでどうやってコミュニケーションするの？

Gitはバージョン管理ツールであって、
コミュニケーションツールではありません

0756デフォルトの名無しさん

2013/10/10(木) 01:06:18.13

例えばこんな場合。

ローカルだけで開発していたら他人の進捗状況がわからない。
だから中央リポジトリは必要。

中央リポジトリにあるものをだれでも勝手に
消したりできたらまずいから権限の概念が必要になる。

ただし管理者のみが中央リポジトリを作成できるなら
中央リポジトリを作るために管理者にお伺いを建てないといけなくなる
これは良くない。

理想は誰でも中央リポジトリをサクッと作れて、
権限がある人だけが消したりできる。
プロジェクトに参加者を登録して、参加者に
閲覧専用権限を与えたり、コミット権限を与えたりしたい。
コミットに関するコメントを付けたい。
それらを自動的にメールで通知したい。

ということで、gitだけではできないことを行うために
サーバーが必要になる。

0757デフォルトの名無しさん

2013/10/10(木) 01:08:13.41

>>755
> Gitはバージョン管理ツールであって、
> コミュニケーションツールではありません

だから、git以外のgitサーバーを使うって話になるんだろ？
こっちは最初からgitではない物＝特別なものを入れるって話をしてるんだが？

お前は、git以外に入れる必要はない＝gitでコミュニケーションも
できるっていいたいんだろう？

0758デフォルトの名無しさん

2013/10/10(木) 01:10:58.32

なんで「Gitサーバをインストールする」が
コミュニケーションツールを導入するまで飛躍するんだよｗアホかｗ

0759デフォルトの名無しさん

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

0760デフォルトの名無しさん

2013/10/10(木) 01:19:27.65

>>756
誰でも中央リポジトリを作れるのと権限がある人だけが消せるを両立させるのは難しいかな
閲覧専用権限もちょっと難しい
でも質問の「数人程度の単一プロジェクト」ならこんなのいらんだろ

＞コミットに関するコメントを付けたい。
＞自動的にメールで通知したい。
全部メールでやればいい

それ以外はUNIXアカウント+ssh+gitだけでできるから

0761デフォルトの名無しさん

2013/10/10(木) 01:20:59.61

>>760
いるかいらんかは
お前が決めるな。

0762デフォルトの名無しさん

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からのオプショナルな機能を実現するために
他のものをインストールする必要があるわけ

0763デフォルトの名無しさん

2013/10/10(木) 01:25:18.79

>>761
いるかいらんをお前も決めるな
おれはできると可能性を述べているにすぎないぞ

0764デフォルトの名無しさん

2013/10/10(木) 01:25:32.88

単一プロジェクトでも
自分用ツールを皆と共有するために
リポジトリ作りたくなるし、
gitサーバーがあったほうが柔軟で便利だろ。

メール？送信するのが面倒だろ。
どうやって掲示板のやりとりみたいなものを
数人でメールでやるんだ？

できるのと、簡単に便利にできるのとでは
わけが違う。

入れないほうがいいという理由がない。

0765デフォルトの名無しさん

2013/10/10(木) 01:27:50.27

>>762
実現可能かどうかは論点じゃないんだよ。

実現可能かどうかで言えば
ソースコード管理もディレクトリコピーで実現可能。

そういうことじゃないだろ？
どれだけ簡単にできるかが重要なんだよ。

頑張ってgitサーバー相当のことが出来るようになりました！
は意味が無い。最初からgitサーバー使えばいいと言われて終わり。

0766デフォルトの名無しさん

2013/10/10(木) 01:28:35.11

>>764
自分用ツールを皆と共有するためにリポジトリ作る用途なら
UNIXアカウント+ssh+git で全然問題無いです

0767デフォルトの名無しさん

2013/10/10(木) 01:30:58.82

>766
UNIXアカウントが必要な時点で問題ありだろ。
お前のコードにアクセスするために、
お前のマシンに俺のアカウントを作らなければならないということだ。

0768デフォルトの名無しさん

2013/10/10(木) 01:32:19.88

>>765
全然頑張る必要とかないよ？
gitアカウント作ってユーザーをgitアカウントと同じグループに所属させておく
gitアカウントで適当なディクレトリ作って
chmod g+rws ディクレトリ; cd ディクレトリ; git init --bara --shared

この程度で「ssh://UNIXマシンのホスト/ディクレトリ」でアクセスできる中央リポジトリが完成

denyNonFastforwardとdenyDeletes辺りを設定しておけば、
コミットを「消す」ことはできなくなるから致命的な悪さをされる心配も無い

0769デフォルトの名無しさん

2013/10/10(木) 01:32:39.97

なんでもExcelでやろうとする奴と
同じ臭いを感じるなｗ

0770デフォルトの名無しさん

2013/10/10(木) 01:34:09.87

>>767
中央リポジトリをつくるマシンにアカウント作るだけです

0771デフォルトの名無しさん

2013/10/10(木) 01:35:08.83

>>768
それをユーザー全員がやらないといけないよね。

gitサーバーがあれば、そういう面倒な作業なしに
バンバン共有リポジトリ作れるし、
もっと複雑な権限管理もできるし、
ダッシュボードから今何が起きているかを把握できるし
その上コミュニケーションツールまでついてくる。

超便利なツール VS 頑張れば同じことが出来る。あれしてこれして・・・

ご苦労さんｗ

0772デフォルトの名無しさん

2013/10/10(木) 01:36:32.68

>>770
じゃあ、次にプロジェクトを複数作って、
プロジェクトごとに参加者が違います。

同じユーザーでもプロジェクトが違えば
見れたり見れなかったり書き込み権限があったりなかったりします。

ってときはどうするの？

0773デフォルトの名無しさん

2013/10/10(木) 01:36:47.33

>>771
いや、これをやるのは中央リポジトリをつくる人だけ

0774デフォルトの名無しさん

2013/10/10(木) 01:37:52.99

>>772
だから単一プロジェクトでの話をしてるんだろ？
参加者が違うプロジェクトをつくるならグループを追加すればいいよ

0775デフォルトの名無しさん

2013/10/10(木) 01:39:36.45

>>773
「中央リポジトリを作る人」がいるってのが
そもそも問題。権力者ってのはなるべく排除するべき。

共有の中央リポジトリであれば
管理者一人でもいいが、
個人が中央リポジトリを作りたい場合もある。

個人が作った中央リポジトリは、
管理者を除いて、個人のみが管理できる。
その個人が許せば、他のユーザーにも閲覧権限や
管理言言を与えることも可能。

開発をしていればこういうことはやりたいと思うのが普通。

0776デフォルトの名無しさん

2013/10/10(木) 01:39:41.74

>>769
逆だな
サーバ必須とかのやつからExcel使いと同じ臭いを感じる
もっと臨機応変にやってくれよ

0777デフォルトの名無しさん

2013/10/10(木) 01:41:35.87

>>774
単一プロジェクトと言われたからといって、
本当に単一プロジェクトでしか通用しないテクニックを
だすのは愚か。

> 参加者が違うプロジェクトをつくるならグループを追加すればいいよ
で、閲覧権限と書き込み権限はどうするの？
人によって権限を与えたり与えなかったりしたいんだよね。

0778デフォルトの名無しさん

2013/10/10(木) 01:42:32.80

>>776
あのー？
最初からおすすめのgitサーバーの話をしてるんですが？

お前、柔軟性ないね。
素直にgitサーバーの話をスレばいいじゃんか。

もしかして、知らないの？って思われるよっていうか思ってるｗ

0779デフォルトの名無しさん

2013/10/10(木) 01:43:12.29

>>777
閲覧専用権限は難しいと言ってるだろ
書き込み権限はグループに追加するユーザで制御できる

0780デフォルトの名無しさん

2013/10/10(木) 01:44:45.41

>>778
だから、おれとしては、その程度の規模でUNIXアカウント+sshの使用に抵抗が無いならという条件で、
UNIXアカウント+ssh+gitをオススメしてるんだよ
お前が別のものをオススメするのは勝手だ

0781デフォルトの名無しさん

2013/10/10(木) 01:44:51.07

>>779
難しいならだめじゃんか。

なんで、githubのように
優れたツールがあるのに
それを使わないの？

gitサーバーを使いたくないって話をしてるんじゃないんだよ。
gitサーバーを使いたい。おすすめは？って話をしてるんだよ。

0782デフォルトの名無しさん

2013/10/10(木) 01:45:27.95

>>778
サーバ立てなきゃ絶対ダメとかのどこが柔軟性なんだよ

0783デフォルトの名無しさん

2013/10/10(木) 01:45:52.20

>>780
だから俺は、お前のおすすめは
おすすめじゃないって話をしてるんだよ。

だってコミュニケーションツールもついてないじゃん。

0784デフォルトの名無しさん

2013/10/10(木) 01:46:25.97

>>781
それが必要ないなら問題ないだろ
選ぶのは質問者だ

0785デフォルトの名無しさん

2013/10/10(木) 01:46:36.37

>>782
サーバーを建てないという条件で
頑張るお前よりはよっぽど柔軟。

どっちが選択肢が多いかね？

0786デフォルトの名無しさん

2013/10/10(木) 01:49:01.06

>>784
質問者は既にgitサーバーを選んでいる。
今の質問はどのgitサーバーがオススメかだ。

0787デフォルトの名無しさん

2013/10/10(木) 01:49:25.04

>>783
俺のおすすめは、お前にとってはおすすめじゃないだけだろ
俺のおすすめは変わらんよ
どういうものなのか説明はした
実際おれは数人程度でリポジトリを共有する目的でコレを使ってる
選ぶのは質問者

0788デフォルトの名無しさん

2013/10/10(木) 01:51:07.18

>>787
質問がどのgitサーバーがオススメか？である以上
gitサーバーを答えなければならない。
お前の答えは、質問に答えていない。
論外なんだよ。

0789デフォルトの名無しさん

2013/10/10(木) 01:52:02.01

なんかよくわからんけどこえーよ

0790デフォルトの名無しさん

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ができることだ

0791デフォルトの名無しさん

2013/10/10(木) 02:20:22.66

IDないからだれがだれだかわからなくてめんどくせーなおい

0792デフォルトの名無しさん

2013/10/10(木) 02:24:32.80

まあ>>790のURLを読めばよい
そこは両者オススメみたいだし

0793デフォルトの名無しさん

2013/10/10(木) 02:27:00.73

Gitって循環参照とか出来るの？
コンピューターA
↑参照
コンピューターB
↑参照
コンピューターC
↑参照
コンピューターA

こんな風にしたらどうなる？

0794デフォルトの名無しさん

2013/10/10(木) 02:27:29.33

>>775
開発したことがあるならなおさら中央リポジトリの重要性を痛感するはず

0795デフォルトの名無しさん

2013/10/10(木) 02:30:29.98

>>793
コンピューターっていうのは特定マシンのリポジトリの意味かな？

0796デフォルトの名無しさん

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

0797デフォルトの名無しさん

2013/10/10(木) 03:41:17.36

ブランチのことか
別に問題ないよ
ただその四つのブランチが共通の祖先のコミットをもってないと困ると思うが

0798デフォルトの名無しさん

2013/10/10(木) 06:30:39.80

一人で使うなら好きにしなさい
複数で使うならgitoliteにしなさい

0799デフォルトの名無しさん

2013/10/10(木) 08:37:35.32

>>756
その文章の中で
>gitだけではできないこと
ってどれなの？

0800デフォルトの名無しさん

2013/10/10(木) 09:05:57.52

何だか知らんがそんなにgitが嫌ならsvnでも使っとけバーロー

0801デフォルトの名無しさん

2013/10/10(木) 09:19:58.74

伸びてんなー

0802デフォルトの名無しさん

2013/10/10(木) 09:39:39.75

gitだとバージョン番号つけられないね

0803デフォルトの名無しさん

2013/10/10(木) 09:44:12.83

この伸びてるのはgit大好きな馬鹿同士じゃないか

>>802
>>531

0804デフォルトの名無しさん

2013/10/10(木) 09:44:52.63

タグにバージョンつけてるけど

0805デフォルトの名無しさん

2013/10/10(木) 10:38:21.03

>>803
おもしろそう
これを使えば$Id$がつくれるのかな

0806デフォルトの名無しさん

2013/10/10(木) 10:53:23.91

9月入った辺りから伸びが凄いな
ビックウェーブ来てる？

0807デフォルトの名無しさん

2013/10/10(木) 12:12:48.06

来てますがうちはビッグウェーブに乗るというより押し流されてますよ
開発者の人数だけグラフがスパイラルしているのはなかなかキレイです

0808デフォルトの名無しさん

2013/10/10(木) 14:23:39.77

空のリポジトリから作り始める時もmasterじゃなくて適当なブランチ作ってやり始めるのが筋？

0809デフォルトの名無しさん

2013/10/10(木) 15:07:32.38

いいえ

0810デフォルトの名無しさん

2013/10/10(木) 17:07:38.36

城戸君は新人Webコーダーで聞き間違えが多いタイプ
田中君は人のコードをパクル様なことをするタイプ
こういう二つのタイプの人間がいるとします
この二人にプロジェクトを任せるのですが
城戸君は聞き間違えが多いので本来Aを作るところを間違えてBを作ってコミットしました
そのあと田中君はググって見つけたブログのコードを自分の担当のBにコピペしてコミットしました
こういう場合はどうしたらいいでしょうか？

0811デフォルトの名無しさん

2013/10/10(木) 17:15:04.85

＞ Bにコピペ
これはBを全部書き換えてしまったのかな？
それともBの一部を書き換えたのかな？

0812デフォルトの名無しさん

2013/10/10(木) 17:18:42.43

Bのファイルをお互いいじったところはコンフリクトして、
かぶってないところはコンフリクトしません
たぶん

0813デフォルトの名無しさん

2013/10/10(木) 17:22:08.09

>>810 = >>812なの？

0814デフォルトの名無しさん

2013/10/10(木) 17:26:56.56

>>810
マージするためにgit使ってるんだろ。

0815デフォルトの名無しさん

2013/10/10(木) 17:28:28.02

マージしてしまった後に、
城戸君はBをAにどうやって直すべきかって話じゃないのか？

0816デフォルトの名無しさん

2013/10/10(木) 17:29:23.27

城戸って珍しい名前だな
じょうど
じょうと
しろと
しろど
変換に出てこない

0817デフォルトの名無しさん

2013/10/10(木) 17:31:50.78

城戸＝キド

0818デフォルトの名無しさん

2013/10/10(木) 17:32:51.28

逆に、城戸をコピーして選択状態にして変換キーでもいいんやで

0819デフォルトの名無しさん

2013/10/10(木) 17:33:15.52

>>815
古いBをAにマージするだけじゃないの。

>>816
きど

0820デフォルトの名無しさん

2013/10/10(木) 17:46:32.58

正しいAをマージするとたぶん田中くんの修正がコンフリクトするから
それをどうするかってことかね？
コンフリクトしない場合でもやばい感じにマージされる可能性はあるかもだけど
どっちにしろ田中くんと城戸くんで相談だよね

めんどくさければ田中くんの修正がなかったように正しいAをマージしてしまって
田中君にはAに合わせて直した修正を改めてコミットしてもらえばいいかも？

0821デフォルトの名無しさん

2013/10/10(木) 21:57:08.65

>>810を読む限り、マージする前の話でしょ

あとは、本来出来上がってるはずのAができあがっておらず、どうしたらいいんだろうっていう問題だよ
城戸君は間違えが多い、一方の田中君はどっかから適当に拾ってくる
納期が迫っている中さあどうしよう？

0822デフォルトの名無しさん

2013/10/10(木) 21:59:21.08

納期のことは忘れたほうがいいよ。
理想的なやり方を追求すればいい。

納期の話を含めると、ダメなやり方が答えになるから。

0823デフォルトの名無しさん

2013/10/10(木) 22:00:50.81

gitがどうとかいう以前の問題のような

0824デフォルトの名無しさん

2013/10/10(木) 22:45:07.29

そんな使えない奴はクビで

0825デフォルトの名無しさん

2013/10/10(木) 23:03:10.27

マージする必要あるのか？
二人して同じもの作ったのなら、どちらかを破棄するだけだと思うのだけど。。。
たぶん、Bを破棄して、田中君がAつくるんじゃね？
昼ゴチって感じで

0826デフォルトの名無しさん

2013/10/10(木) 23:25:44.16

城戸君がBを revert するだけで済む話に聞こえるけどそうじゃないのかな

0827デフォルトの名無しさん

2013/10/10(木) 23:27:37.39

作業がなかったことになったら給料泥棒じゃん

0828デフォルトの名無しさん

2013/10/11(金) 00:11:06.14

給料も無くせばいいだろ

0829710

2013/10/11(金) 02:25:32.11

>>827
ぐだぐだのコードなら、ないほうがまだマシ。

0830デフォルトの名無しさん

2013/10/11(金) 06:30:51.70

まずは>>810が日本語を勉強するべき

0831デフォルトの名無しさん

2013/10/11(金) 23:18:50.52

.gitと同じディレクトリにsampleディレクトリがあるんですけど
このディレクトリを除外したい場合githubで.人様のgitignore見てたんですが
/sample
sample/
/sample/
って３通りに書き方を見るんですがどれが正しいでしょうか？

0832デフォルトの名無しさん

2013/10/11(金) 23:34:46.68

たすけてくださああああああい
これで1版最初にコミットしたところのソースコードが見たくて
git checkout ランダムな文字
ってしたんですが
git logをみたら戻った所以降のコミットのログがありません！
git reflogでランダムな文字列を表示してまた　git checkout ランダムな文字　で戻れました
こういうふうに過去のソースコードがみたくて一時的に戻したい場合はどうやるのが正しかったのでしょうか？

0833デフォルトの名無しさん

2013/10/12(土) 00:32:15.17

git checkout master
とかブランチ名を指定すればどこからでも戻ってこれるんでない？
あとは
git show 0123456789abcdef:path/to/filename
みたいに書けば特定のコミット時点の特定のファイルをいちいちチェックアウトせずに表示できたと思う

0834デフォルトの名無しさん

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ブランチでも参照できるのは何でなの？

0835デフォルトの名無しさん

2013/10/12(土) 00:46:29.27

add されてない未管理状態のファイルは何もせずに放置される

0836デフォルトの名無しさん

2013/10/12(土) 01:08:03.44

>>835
マジか、㌧クス
じゃあブランチは別のフォルダで作らんとダメなのか

0837デフォルトの名無しさん

2013/10/12(土) 01:32:43.62

>>831

/sample/ で。

0838デフォルトの名無しさん

2013/10/12(土) 01:48:46.77

>>836
なぜそうなるのか分からん
普通は同じフォルダでいいんじゃないの

0839デフォルトの名無しさん

2013/10/12(土) 02:47:20.21

別のブランチ作ってそこで作ったファイルと競合おこさないの？

0840デフォルトの名無しさん

2013/10/12(土) 03:07:50.93

>>839
a.exe の事だよね？

$ echo "*.exe" > .gitignore
$ git add .gitignore
$ git commit -m "initial commit"

ここで何してるの

0841デフォルトの名無しさん

2013/10/12(土) 03:19:17.49

つまり、競合おこしたくないファイルはバイナリだろうとバージョン管理に入れろってこと？
わかった、そうする

0842デフォルトの名無しさん

2013/10/12(土) 06:21:36.68

普通、make cleanとかするだろ。

0843デフォルトの名無しさん

2013/10/12(土) 11:28:32.72

権限を750に設定したいphpとhtmlの環境をgitで管理するのってどうすればいいですか？

テストサーバのリポジトリ---gitリポジトリ---本サーバのリポジトリ
みたいな環境で、テストサーバで750でファイルを作成して、コミット、プッシュする
そして、本サーバでプルしたら、別ユーザにも実行権限が付いてしまう

直接、実行環境にプルできたら楽でいいなって思ったんですが
デプロイ用のスクリプト作って、プルした環境からサーバの実行環境に入れなきゃだめ？

0844デフォルトの名無しさん

2013/10/12(土) 12:22:10.58

>>843
gitはユーザを区別しない実行可能フラグしか管理しないからデフォルトでは無理じゃないかと
post-receiveフックを使えばpullのときに任意のスクリプト走らせられるから、お望みの動作をするスクリプト書けばいいと思うよ

0845デフォルトの名無しさん

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

0846デフォルトの名無しさん

2013/10/12(土) 16:31:35.04

複数人で作業するときって別の人が編集するファイルを編集したらどうなりますか？

0847デフォルトの名無しさん

2013/10/12(土) 16:34:36.46

>>846
別の人が編集する前に編集され書き換わります。

0848デフォルトの名無しさん

2013/10/12(土) 21:43:34.68

git clone リポジトリのurl
ってやるとクローンで着ますが、
存在しないurlだと失敗しますよね
なので、そのリポジトリが存在するかしないか（もしくは、cloneで取得できるかできないか）をチェックするだけのコマンドってありませんか？

0849デフォルトの名無しさん

2013/10/12(土) 22:27:25.73

ls-remote

0850デフォルトの名無しさん

2013/10/12(土) 23:06:08.75

それってgitで始まるurlにも使えるの？
[email protected]:hub2ch/hub2ch.git
みたいな

0851デフォルトの名無しさん

2013/10/12(土) 23:11:03.56

git://github.com/～/～.git
とかのことだよね？いま試してみたらできたよ。

0852デフォルトの名無しさん

2013/10/13(日) 11:19:55.92

http://trac-hacks.org/wiki/GitPlugin

0853デフォルトの名無しさん

2013/10/13(日) 11:49:16.26

gitignoreに
/test/
って書いたのに
testディレクトリの中のファイルを編集してからgit statusってやると
modified: test/test.html
modified: test/test2.html
って表示されてしまいます！
このままaddしてcommitしたらtestディレクトリのファイルも記録されちゃいますよね！？

0854デフォルトの名無しさん

2013/10/13(日) 11:59:10.37

.gitignoreに
./test/
って書けよ

0855デフォルトの名無しさん

2013/10/13(日) 12:06:36.52

>>853
.gitignoreは既にリポジトリで管理対象になってるファイルには効かないよ
ファイルを管理対象にするまえに.gitignoreを書かないとダメ
管理対象から外したいならgit rmしてコミットすれば
その後はそのファイルをいじってもgit statusには出てこなくなる

0856デフォルトの名無しさん

2013/10/13(日) 12:08:03.73

>>854
それは駄目だろ

0857デフォルトの名無しさん

2013/10/13(日) 12:30:58.56

ちょｗｗｗｗうはｗｗｗｗ
git rm test/test.html
ってやったらファイルそのものが消えましたｗｗｗ
つられました～～～

0858デフォルトの名無しさん

2013/10/13(日) 12:40:26.27

>>857
おう悪い
消さずに管理対象から外すコマンドは忘れた
とりあえず消える前のがコミットされてるんだから
checkoutで復活させてくれ

0859デフォルトの名無しさん

2013/10/13(日) 12:44:26.17

>>857
--cached
ってか、そんな基本しらねーのかよ本１冊読めよ

0860デフォルトの名無しさん

2013/10/13(日) 20:55:20.82

テストファイルってgitで管理するべきですか？

0861デフォルトの名無しさん

2013/10/13(日) 21:11:16.71

自動テストを行うコードのことならyes

0862デフォルトの名無しさん

2013/10/13(日) 21:13:09.67

>>860
テストファイルが何だかわからないが、Junitとかを使ったテストプログラムのコードとかなら、ソースコードとバージョンを合わせないとだから、管理すべき。

0863710

2013/10/13(日) 21:33:34.46

>>862
結果はどうしてる？

0864デフォルトの名無しさん

2013/10/13(日) 22:06:29.98

>>863
結果という成果物が、ログ、オブジェクトに関わらずgitの管理内に入ることはない

0865デフォルトの名無しさん

2013/10/13(日) 22:12:46.00

テストの結果なんて「OK」と(ほか数行)しか書かれてないわけで保持するという発想はなかったな

0866デフォルトの名無しさん

2013/10/13(日) 22:21:58.20

failばっかりの状態からバージョン管理をはじめるなら、
OKが増えていくのを見てニヤニヤするためにバージョン管理するのは有りな気がする
いつどのテストが通るようになったかわかるし

全部OKじゃないとコミットを許さないなら、管理する価値はないでしょ

0867デフォルトの名無しさん

2013/10/13(日) 22:42:00.60

再生成できるものをリポジトリに入れるのは違和感があるので、指定されたコミットをチェックアウトしてビルド・テストを実行するスクリプトを作ろう
リポジトリに入れてもいい成果物は再生成が面倒or時間がかかるものという認識だ

0868デフォルトの名無しさん

2013/10/13(日) 22:51:06.61

このテストいつ通るようになったっけ？
で全履歴を二分木探索でテストスクリプト走らせるとなると、結構な時間がかかるはず
リポジトリに入れるのが気持ち悪いなら、git notesにでも入れときゃいいんじゃね

0869710

2013/10/13(日) 22:58:59.11

>>867
うちでは、出荷版とかは入れてる。
再作成しても同じバイナリにはならない環境があるからねぇ。

0870デフォルトの名無しさん

2013/10/13(日) 23:03:04.42

JavaだけどバイナリはVCSではなくてArtifactoryで管理している。
メインブランチと開発ブランチ、Jenkinsが自動でビルドとテストをして合格すれば
Artifactoryにプッシュする。

0871デフォルトの名無しさん

2013/10/13(日) 23:06:16.00

リビルドするたびに、バイナリ変わる環境なんて
メモリエラーとかハードが壊れてるだけ

0872デフォルトの名無しさん

2013/10/13(日) 23:07:06.50

>>870
CraftBukkitか？

0873710

2013/10/13(日) 23:17:17.19

>>871
ビルド日時を埋め込むシステムなんて珍しくないんだが、無知ってこんな分かりやすい餌にも食いつくんだな (w

0874デフォルトの名無しさん

2013/10/13(日) 23:34:21.57

珍しくないというか、PE(Windowsのexe)にもあるよね。

0875デフォルトの名無しさん

2013/10/13(日) 23:40:33.27

それはそういうソフトだな。
ビルドするたびに、バイナリ変わるビルドツールなんて
コンパイラとしておかしいわ

0876デフォルトの名無しさん

2013/10/13(日) 23:42:28.94

PGO使うとバイナリが変わるというか、変えるために使うんだよね。

0877710

2013/10/13(日) 23:44:51.06

>>875
> コンパイラとしておかしいわ

素人さんはそう言ってりゃいいんだろうけど...

0878デフォルトの名無しさん

2013/10/13(日) 23:47:53.23

いったい、どこのマイナーなツール使ってるんだかｗ

0879デフォルトの名無しさん

2013/10/13(日) 23:48:50.76

素人にここまで浸食されてるのってこの業界だけだよね。
大工さんと日曜大工のお父さんじゃだいぶ差があるのに。
金返せと言われても文句言えない。

0880710

2013/10/13(日) 23:57:10.19

>>878
自分の環境が全てと思ってる奴 ≡ 素人

0881デフォルトの名無しさん

2013/10/14(月) 00:00:36.33

>>880
さすがgit玄人ですね
かっこいい＾＾

0882デフォルトの名無しさん

2013/10/14(月) 00:08:45.33

ここで喧嘩しないでよ
>>878-879
とか単なる煽りあいでしょ。せめてgit絡めて話して

0883デフォルトの名無しさん

2013/10/14(月) 00:11:56.27

git commit >>710 -m '荒らしてんなボケ'

0884デフォルトの名無しさん

2013/10/14(月) 00:29:15.34

OSのヘッダファイルはgitで管理するべきだろうか？
ヘッダファイルが変わるとバイナリ変わっちゃうんだよね

0885デフォルトの名無しさん

2013/10/14(月) 00:36:31.41

>>884
ビルド環境はcloneした先で構築すりゃいい
ソース上で管理するなら、それぞれmake -fのターゲットファイルを用意する
READMEに情報かいてるのもあるかな

0886885

2013/10/14(月) 01:23:28.84

無視してください

0887デフォルトの名無しさん

2013/10/14(月) 04:23:20.47

>>863
テスト結果はcommitしない。
欲しくなったら、その版をcheckoutしてまた作ればいいから。

0888デフォルトの名無しさん

2013/10/14(月) 04:35:24.27

>>868
二分探索なら履歴の数はそんなに関係なさそうだから、一回のテストが遅いのかな。
そんな時間かかるのに毎回入れるとなると、commit時に時間掛かりそう。たまにしかpushしないリポジトリでのみとっとけばいいのかな。
ナイトリービルドとかの時のテスト結果を上書きしないで、とっておいたほうが良さそう。

0889デフォルトの名無しさん

2013/10/14(月) 04:42:27.48

テスト結果のcommitはしたことがないけれども、するにしてもCIツールからだと思うな。
開発者マシン上でのテスト結果なんて信用できないでしょ。

0890デフォルトの名無しさん

2013/10/14(月) 09:08:09.31

日付と時刻を付けたファイル名で毎回保存すればいいだけ

0891デフォルトの名無しさん

2013/10/14(月) 09:43:44.34

>>887
「そのときのテスト結果」はとっといたほうがいいぞ。
gitに入っているのが環境の全てと言い張れるほど自信ないし。

0892デフォルトの名無しさん

2013/10/14(月) 09:54:30.96

とっとくとしてもコミットには含めないかな
コミットIDと対応づけてどっかに保存だ

0893デフォルトの名無しさん

2013/10/14(月) 10:05:44.22

ID発行して、品保のハンコつきで、鍵付きロッカーに保存

0894デフォルトの名無しさん

2013/10/14(月) 10:11:57.68

単純に git notes を使うのではダメなのか?

0895デフォルトの名無しさん

2013/10/14(月) 10:27:21.19

gitで画像を管理場合、画像の比較ってどうやるの？

0896デフォルトの名無しさん

2013/10/14(月) 10:28:36.65

gitでaddしてcommitするとき
gitで現在のファイルの内容が記録されていくじゃないですか
この記録される内容っていうのはファイルの内容全てなのか、直前のファイルの内容からの差分なのか、どういうふうに岐路ｋうされていうのですか？

0897デフォルトの名無しさん

2013/10/14(月) 10:33:51.55

>>895
>>475のURLのバイナリファイルの差分

0898デフォルトの名無しさん

2013/10/14(月) 10:34:44.65

>>896
変更されたファイルの内容全部

0899デフォルトの名無しさん

2013/10/14(月) 10:36:07.07

>>896
gitの場合は、ファイルの内容丸ごと。

0900デフォルトの名無しさん

2013/10/14(月) 10:36:59.33

gitの場合ってことは、、、、CSVとかMがつくやつ（名前忘れた）とかSVNは違うの？

0901デフォルトの名無しさん

2013/10/14(月) 10:38:08.39

違うソフトだけど
出来ることは、だいたい同じ

0902デフォルトの名無しさん

2013/10/14(月) 10:39:22.27

昔のバージョン管理ツールは差分だけを保存してたよ

0903デフォルトの名無しさん

2013/10/14(月) 10:42:11.53

>>894
git notesに複数のディクレトリに格納された複数のファイルとかも添付できるん？
git logの表示の邪魔にならない？

0904710

2013/10/14(月) 10:42:21.11

>>892
どうせどこかに保存するなら、SCM に保存する。

0905デフォルトの名無しさん

2013/10/14(月) 10:44:01.58

(なんでこの人ずっとコテつけてんの)

0906デフォルトの名無しさん

2013/10/14(月) 10:45:28.53

差分だけ管理するタイプだといろいろ処理が増えるからダメだよな
Gitは全文保存するから賢い

0907デフォルトの名無しさん

2013/10/14(月) 10:46:07.31

>>904
バージョン間の差分とかチェックするときに邪魔じゃん

0908デフォルトの名無しさん

2013/10/14(月) 10:48:31.05

すいません、C:\site\index.htmlを１０回コミットしたんですけど
３回目にコミットしたこのファイルの内容だけを取って来て
C:\backup\index.hmlに保存するコマンドってありませんか？

0909デフォルトの名無しさん

2013/10/14(月) 10:48:34.46

マージしたりチェリーピックしたりパッチ作ったりするのにもいちいち邪魔だな

0910デフォルトの名無しさん

2013/10/14(月) 10:54:56.31

git checkout HEAD~7 -- C:\site\index.html
copy C:\site\index.html C:\backup\

0911710

2013/10/14(月) 10:56:59.55

>>907
え゛っ！？
マジで意味わからん。

0912デフォルトの名無しさん

2013/10/14(月) 11:01:20.07

>>911
二つのコミットを指定して差分をとったら、
そのコミット間のソースの差分だけが出てきて欲しい
テスト結果をコミットに含めてたらテスト結果まで全部でてくるだろう？

0913デフォルトの名無しさん

2013/10/14(月) 11:03:37.61

えええ、元のファイルの内容を過去のに戻さないとダメですか？

0914デフォルトの名無しさん

2013/10/14(月) 11:05:48.25

はい

0915デフォルトの名無しさん

2013/10/14(月) 11:14:42.92

そんなことはない

0916デフォルトの名無しさん

2013/10/14(月) 11:15:04.28

git show HEAD~7:(リポジトリ内パス)/index.html > C:\backup\index.hml
でどうだろうか
Windowsのコマンドプロンプトでgit showをリダイレクトしても改行コードは変化しなかったような気がする
(core.autocrlf=falseでLFなファイルしか書かないうちの環境のせいかもしれんが)

0917710

2013/10/14(月) 11:19:26.43

>>912
ソースと違う所に入れるでしょ？普通。

0918デフォルトの名無しさん

2013/10/14(月) 11:21:52.57

>>917
いちいち日本語がわかりにくいんだが
ソースと違うリポジトリという意味かね？それなら別にかまわないよ

0919710

2013/10/14(月) 11:39:51.47

>>918
はあ？
フォルダの概念ないの？

0920デフォルトの名無しさん

2013/10/14(月) 11:46:25.25

(だから、何でこの人ずっとコテつけてんの）

0921デフォルトの名無しさん

2013/10/14(月) 11:46:48.46

>>919
差分取るときテスト結果のディレクトリ以外を毎回指定するのかよ馬鹿すぎるな
マージするときはどうしてんの？Fast-Forwardじゃなければほぼコンフリクトするだろ？

0922デフォルトの名無しさん

2013/10/14(月) 11:50:49.00

レス乞食は無視した方がいい

0923デフォルトの名無しさん

2013/10/14(月) 11:51:00.70

>>891
なんか環境が足りないバグなら追加してcommitすればいいんじゃない。ある環境でしか通らないテストなら、余計に保存してそれを信じる意味ないし。

0924デフォルトの名無しさん

2013/10/14(月) 11:53:25.89

>>920
コテつけるのも付けないのも自由だよ。
お前が言った所で、お前の願いはかないませんｗ

0925デフォルトの名無しさん

2013/10/14(月) 11:55:25.79

ところでフォルダって何？
ここgitのスレだよな？

0926デフォルトの名無しさん

2013/10/14(月) 11:55:29.25

すいません複数人でpushするときって
masterブランチの内容をpushするべきでしょうか？

0927デフォルトの名無しさん

2013/10/14(月) 11:56:01.26

逃げたか

0928710

2013/10/14(月) 11:57:09.51

>>921
> 差分取るときテスト結果のディレクトリ以外を毎回指定するのかよ馬鹿すぎるな

おいおい大丈夫か？
テスト結果を通常のソースとかを管理しているフォルダと違うフォルダに入れるだけだろ？

0929デフォルトの名無しさん

2013/10/14(月) 11:58:30.22

>>920
すまん、外し忘れだわ。

0930デフォルトの名無しさん

2013/10/14(月) 12:01:36.32

>>928
レポジトリ直下に複数の管理対象ファイルやディレクトリを置く場合がある
それにそもそも指定が必要な手間をかけるの自体が馬鹿すぎるわ

それでマージはどうしてるの？

0931デフォルトの名無しさん

2013/10/14(月) 12:22:41.34

>>930
自分の知らないことは馬鹿としか言えない人なんだな、頭固いんじゃね？
あと、しきりにマージって言ってるけど、普通に考えて結果に対してマージが発生するような運用はしないと思うんだけど...

0932デフォルトの名無しさん

2013/10/14(月) 12:22:55.84

何をそんなにしつこいのかわからん
マージしたらどうせテストしなおしなんだから、テスト結果ファイルも作り直しでしょ
「マージ作業」をする必要がない

0933デフォルトの名無しさん

2013/10/14(月) 12:46:42.21

>>931-932
まじで意味がわからないんだけど？
どういうタイミングでテスト結果をコミットする運用なんだ？
マージで問題にならないってことはローカルリポジトリでテストした結果は
コミットしないようにするんだよね？

0934デフォルトの名無しさん

2013/10/14(月) 12:49:17.80

もしかして1人で開発してるんじゃね？ｗ

0935デフォルトの名無しさん

2013/10/14(月) 12:52:28.26

テスト結果もマージすりゃいいだろ？
たかがソースコードのバックアップに
何をごちゃごちゃ言ってるのか。

0936デフォルトの名無しさん

2013/10/14(月) 12:57:08.65

>>933
だーかーらー、テスト結果ファイルがコンフリクトしたらテストを走らせるだけでしょ
っていうかコンフリクトしなくてもテストは走らせるよね？

0937デフォルトの名無しさん

2013/10/14(月) 12:58:20.83

>>935
だれかがテスト結果を含めてコミットしたブランチを
自分でもテスト結果を含めてコミットしたローカルブランチにマージしたら
テスト結果なんて自動マージできないから(されても困るが)コンフリクトだろ？
そんな物の解消いちいちやってられるか

0938デフォルトの名無しさん

2013/10/14(月) 12:58:26.81

まーじで意味わからん

0939デフォルトの名無しさん

2013/10/14(月) 13:01:41.67

>>936
テスト済みであってもコンフリクトするだろ？
マージがコンフリクトで止まった状態でテスト走らせてその結果使って
コンフリクト解消操作してマージを完了させるわけか？
マジですかｗ

0940デフォルトの名無しさん

2013/10/14(月) 13:02:10.22

こいつ、まともにgit使ったことないんだろうな

0941デフォルトの名無しさん

2013/10/14(月) 13:04:20.20

たぶん基本Fast-forwardな状態でマージが進むような使いかたしかしてないんだろ
お一人様でやってるとか

0942デフォルトの名無しさん

2013/10/14(月) 13:13:06.98

コンフリクトを修正する方法に慣れたいので
git initからコンフリクトして、コンフリクトを解消するまでの手順を教えてください

0943デフォルトの名無しさん

2013/10/14(月) 13:26:52.21

まあ一人でソースのバックアップ目的でgit使うなら何ぶち込んでも問題にならんわな

0944デフォルトの名無しさん

2013/10/14(月) 13:29:05.02

一人で使ってるけど、どこ修正したかをgit statusとかgit diffで頻繁に確認しながら進めるんで、
余分なものは絶対管理から外す

0945デフォルトの名無しさん

2013/10/14(月) 13:35:37.76

>>933
> まじで意味がわからないんだけど？

テスト毎にコミットする人決めときゃいいだけでしょ？

0946デフォルトの名無しさん

2013/10/14(月) 13:39:00.00

おまえら、まさかマージした時に
自動的にコミットとかしてないよな？

コミットする前にテストは必須。
テストを実行してから
OKならそのテスト結果毎コミットする。

これでなんの問題が有るんだよ？

0947デフォルトの名無しさん

2013/10/14(月) 13:39:27.07

git statusにコミットしないファイルが出てきちゃう環境な奴は二流

0948デフォルトの名無しさん

2013/10/14(月) 13:40:45.68

>>946
>>937

0949デフォルトの名無しさん

2013/10/14(月) 13:42:25.70

>>947
これってどうふうにしたら再現できますか？

0950デフォルトの名無しさん

2013/10/14(月) 13:43:26.98

結果が全パスなら保存する価値がないし(通ったぞという証拠?)
全パスでないならpushすべきでない、と思った。

0951デフォルトの名無しさん

2013/10/14(月) 13:48:18.31

>>949
ホームやリポジトリのgitignoreを適切に設定していない場合におこります

0952デフォルトの名無しさん

2013/10/14(月) 13:52:53.56

>>946
「マージした時に自動的にコミットするな」が意味不明
gitでマージするときには
マージコミットができるかFF状態でHEADを移動するかどっちかだよね？

0953デフォルトの名無しさん

2013/10/14(月) 13:53:53.88

>>950
> 通ったぞという証拠?

テスト実施日時とかの情報もあるよ。

0954デフォルトの名無しさん

2013/10/14(月) 13:56:35.10

>>953
コミット時には必ずテストすべきなんだから、コミット日時がテスト実施日時なのでは？

0955デフォルトの名無しさん

2013/10/14(月) 13:59:53.25

gitなら、ビルド通るぐらいの確認でコミットする
pushする前には、それなりのテストをするけど

0956デフォルトの名無しさん

2013/10/14(月) 15:22:07.42

>>954
テストって言っても結合テストとか、システムテストとかもあるでしょ。

0957デフォルトの名無しさん

2013/10/14(月) 15:57:04.67

jasmine使ってテストが書かれていてgithubに公開しているのオープンソースを何でもいいので教えてください

0958デフォルトの名無しさん

2013/10/14(月) 16:19:00.79

もはやGitとは何も関係無いな

0959デフォルトの名無しさん

2013/10/14(月) 16:27:21.00

すいません書き込むスレまちがいました

0960デフォルトの名無しさん

2013/10/14(月) 16:37:56.81

git for windows がバージョンアップされましたよ

0961デフォルトの名無しさん

2013/10/14(月) 17:23:58.45

>>938

0962デフォルトの名無しさん

2013/10/15(火) 00:18:28.83

>>946
ローカルではコミットはCTRL+S連打レベルでガンガンするよ
上流にはテストに通ってから入れる

0963デフォルトの名無しさん

2013/10/15(火) 00:57:50.86

CTRL+R？

0964デフォルトの名無しさん

2013/10/15(火) 01:07:51.52

端末出力の一時停止？
Emacsでインクリメンタルサーチ？

0965デフォルトの名無しさん

2013/10/15(火) 04:48:43.55

>>964
横だけど、保存なみにってことでしょ。

0966デフォルトの名無しさん

2013/10/15(火) 09:28:44.56

素でわからんかった。
皆キーバインド同じだと思ってんのか。

0967デフォルトの名無しさん

2013/10/15(火) 11:22:34.68

eamcsのキーバインドもWinの推奨ショートカットに変更した

0968デフォルトの名無しさん

2013/10/15(火) 11:23:25.78

>>964
いまどき端末出力の一時停止なんて有効にしてるやつはおらんよ

0969デフォルトの名無しさん

2013/10/15(火) 11:54:56.47

えーtelnet(ssh)でしょっちゅう止めちゃってすぐに^Q押してるけどな

0970デフォルトの名無しさん

2013/10/15(火) 15:39:52.14

一時停止、使う時も間々あるし無効にしたいって感じの機能じゃないな。

0971デフォルトの名無しさん

2013/10/15(火) 16:33:44.17

:wなら頻繁に打つ、GUIだとcommand+Sだな
あ、でもVisualStudioだと代わりにビルドしちゃうわw

0972デフォルトの名無しさん

2013/10/15(火) 16:51:23.72

MacにいったりWinにいったり忙しいなｗ
俺もだけど・・・

0973デフォルトの名無しさん

2013/10/15(火) 16:56:14.75

Macってさ常に最新のGitとかJavaとかgccとか言語やツールが使いたい場合
ソースコードをコンパイルしてインストールしていく形なの？
それともWindowsみたいにインストーラーダウンロードして自動でインストールしたり、圧縮ファイルを解凍して自分でフォルダに置いてインストールするタイプなの？
それともLinuxでいうyumやaptみたいにコマンド一発で入れられるの？

0974デフォルトの名無しさん

2013/10/15(火) 17:06:39.23

どうやって入れたかによる
公式のAppStore経由だと自動で通知が来てアップデート
コマンドラインツールだと、MacPortsというのがあるのでそれで
ソースから入れたらもちろｎソースからだし、apt使ってる人もいるみたいね

0975デフォルトの名無しさん

2013/10/15(火) 17:15:37.87

最近はHomebiewってのが多いけど、個人的には好かん。

0976デフォルトの名無しさん

2013/10/15(火) 17:16:27.71

Homebrew

どうやって i を打ったんだ俺

0977デフォルトの名無しさん

2013/10/15(火) 17:18:04.23

>>973
・ソースコンパイル
どーにも最新版が欲しいときにはやらなくもない
一応Unixではあるので、(Xが絡まなければ)素直に行けることが多い

・パッケージマネージャ
標準ではないが、有名なのがいくつかある
ちと更新遅かったりもするが、用意されてればコマンド一発でDL&インスコ出来て楽

・アーカイブやイメージからのインストール(オンラインソフトはもちろん、パッケージソフトでもよくあるパターン)
大概.appファイル1個が入ってるので、それを
アプリケーションフォルダにドラッグ&ドロップ。
それだけで標準ランチャにも出るようになる。
アプリケーションフォルダにはダブクリで起動するファイルしか置いてないので
アプリケーションフォルダ自体もランチャ代わりとしても使える。
必要ファイルはその中に内包してるので、移動するファイルは1個でいい。

・きっちりウィザードやインストーラ付き
意外にレア。常駐系や、システムへ変更を加える必要のあるソフトだけ。

・展開すると多数のファイルあって、配置する場所を考える必要があるもの。
稀に。プラグインとか、そういうプラグインの塊みたいなソフトではたまにある。

0978デフォルトの名無しさん

2013/10/15(火) 17:18:53.55

あ、書き忘れたけどストアからインストールも確かに主流になってきたね

0979デフォルトの名無しさん

2013/10/15(火) 17:27:47.12

おれみたいなWindowsしか使ったことない人間がいきなりMac使っても混乱しそうだ

0980デフォルトの名無しさん

2013/10/15(火) 17:42:30.63

>>979
まあ、別のOSだから仕方ないね
逆に純粋培養マカーからすりゃ、解凍して.dllとかの関係ないモン出てきたり
置いた後ショートカットも作らなきゃランチャに出てこんのはワケ分からんと思うぜ

0981デフォルトの名無しさん

2013/10/15(火) 17:43:37.83

あと…CUIアプリに関しては、Windowsが一番敷居高いぞ

0982デフォルトの名無しさん

2013/10/15(火) 18:12:35.00

ここはいつから雑談スレになったんだ？

0983デフォルトの名無しさん

2013/10/15(火) 19:26:35.65

面目ない

0984デフォルトの名無しさん

2013/10/15(火) 21:33:26.22

>>979
windowsもMacと一緒だろ。app形式がないくらいで。標準でコンパイラがないからソースコードも面倒か。
Linuxの標準でついてるパッケージマネージャが一番楽だ。