Git 7

ソースコード管理を行う分散型バージョン管理システム、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 6
http://toro.2ch.net/test/read.cgi/tech/1369103196/

◆過去スレ
Git 5
http://toro.2ch.net/test/read.cgi/tech/1350144612/
Git 4
http://toro.2ch.net/test/read.cgi/tech/1329234309/
Git 3
http://toro.2ch.net/test/read.cgi/tech/1310403238/
Git 2
http://hibari.2ch.net/test/read.cgi/tech/1284467898/
git スレッド [Linux板]
http://hibari.2ch.net/test/read.cgi/linux/1197798039/

◆関連スレ
◆関連スレ
バージョン管理システムについて語るスレ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/

◆関連スレ 別板
CVS 1.3 [UNIX板]
http://toro.2ch.net/test/read.cgi/unix/1093611448/
subversion バージョン管理【サブバージョン】 [Linux板]
http://engawa.2ch.net/test/read.cgi/linux/1154701996/

◆関連書籍
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

>>1-3 乙

前スレ984以降何かあった？

なんもなかったと思う

プルリクエストにさdiffしてpatchした結果を送るのはありですあｋ？

ubuntu 12.4 に gitlab 入れてローカル環境ではうまくいきました。
インターネット側からも自分の gitlab 鯖につなげられるようにしたいのですが
とりあえず 22/tcp を開いておくだけで大丈夫ですか

注意点としては、ubuntu 上に作成したユーザーで
SSH不要なユーザーはSSH利用停止、
SSH使うユーザーはパスワードをガチガチにする

それくらい？？

>>7
sshdのポート変更、パスワード認証の禁止。

>>7
gitlab使ったことないけど、sshに限った話なら
公開するならポート変更しなくていい
そのかわりパスワード認証じゃなくて公開鍵認証にしないと危ない

コンフリクトが発生しないよう予防法を教えてください

常にFast-forwardな状態でマージする

パスワード認証を禁止にすると、なぜセキュリティが上がるのですか？
そのマシンを勝手に使われたり、乗っ取られたら結局終わりですよね。

勝手に使われたり、乗っ取られないのが前提なら安全と言うことですか？

簡単に言うと、強度が強くなる。
後はどうしたいかによるので自分で判断してください。

>>12
SSHのパスワード認証は攻撃多いからね
ユーザーが1人でも弱いパスワードを設定したらあっという間に入られて、
そのマシンを踏み台にして新たな攻撃が始まるよ
ガチガチにしろと言うより公開鍵認証に限定するほうが簡単で確実

SSHで鍵にパスフレーズつかえばいいんじゃないの

それは別の問題ではないかと

>>12
端末に侵入されたら、キーロガーとかでパスワードも盗まれるでしょうし、セッションジャックもある。終わってる。
入られない前提で困るのはサーバにアクセスされ続けること。
ブルートフォースでは、鍵だと相手にも強度が伝わるので諦めてくれるが、パスワードだと弱いかもなので責められ続ける。パスワードだと当然辞書も来る。
あと管理が楽。

>>11
なんか2.0からはFFがデフォルトでなんたらかんたらで
.gitconfigに
[merge]
ff false
って書いてるんですがコレで大丈夫ですか？

認証方式としては鍵認証の方が強力だけど
パスフレーズの無いsshキーファイルを参照されるとそれだけでアウトだからな
古い脆弱性のあるsshエージェント使ってる人も多いし
gitのようなバージョン管理の為だけにshellを解放するのが良くないんだろうな
面倒くさいからssh使ってるだけで

>>18
それはFF状態でも非FFマージをデフォルトにする設定で、
コンフリクトとは関係ない

そもそも秘密鍵が他人に使われない前提だからな
俺もパス入力あってもいいと思うけど、キーロガー仕組まれること考えたら断言できるほど自信ない
キーロガー仕組まれる可能性とログイン状態で別の人にPC使われる可能性どっちが高いんだろうね

あと、gitlabからshellにアクセスできるなら、それはgitlabの脆弱性だよ

キーロガー仕掛けられてたら
秘密鍵も参照されちゃうだろうしパスフレーズも取られちゃうだろうから
公開鍵認証使っててもダメじゃん

>>12
あまり引きずる話でもないけど
パスワード認証を許容すれば、関係ない端末からもブルートフォースが成立してしまう。

公開鍵認証のみにしておけば、パスワード+秘密鍵になるから、その分安全になる。
ノンパスワードの鍵作成は止めましょう。
あれは、バッチシステム用です。

この話もうちょっと続けたい・・

やっぱいいや

100％安全でないなら
意味が無いじゃないですか！

sshd側で特定のコマンドしかできないようにするのは割と簡単だった気がする。他のコマンドも要求したりしてんのかなぁ。

>>26
100%安全だと所有者も使えないだろうから意味がない。100%は有り得ない。

この世に100%なんて存在しないから全て意味がないな

100%勇気

>>29
> この世に100%なんて存在しない

その確率は何％なの？

頑張るしかないか

最近Gitを使い始めたのですが質問です
以前のコミットに戻した後，コミットを戻す前の状態に戻すことは出来ないという認識でいいのでしょうか？

>>33
戻す事はできるという認識に改めてください。

コミットのキャンセルのキャンセル？

>>34
できるんですか！
調べ方が悪かったみたいです
もうちょっと調べてみます

>>35
そうです
コミットのキャンセルのキャンセルです

git reset ORIG_HEAD とか git reflog とか

システムのデプロイにもgitコマンド使いたいんだけど
ここ落とし穴だから気をつけろ的な注意事項とかある？

gitのことをわかりやすく書かれている本はありませんか？

ありませんよ

ドキュメント嫁　それで分からなければソース嫁

どなたかご存知だったら教えていただきたいのですが
git svn clone時に空ディレクトリを無視せず取ってくる方法はないでしょうか？
git svn dcommit時に削除する方法は、ググったら出てきたのですが、、、

ダミーで空のファイル入れておくってのはダメなんかね

>>39
ググってわかりやすいと思ったサイトを印刷して
本のように綴じたら？

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

最初から書いておくべきで申し訳ないんですが、
空のファイルを入れておく話につきましては検索して知ってました。

しかし、自分の管理していないモジュールだったら空のファイルといえど勝手にコミットできませんよね。
それに些細なことですが、空のファイルのコミットのためにだけはsvnを直接 使わないとダメなので少々面倒です。。

>>39
これを気合で嫁
http://git-scm.com/book/ja

すみません。ちょっと質問なのですが、
githubで管理してる自分のプロジェクトに、海外の方からpull requestが来ました。

本来のコードへの影響を最小限にするためか、（または本人が面倒だったのか）
「既存のロジックコピペで必要なところ改変」みたいな「追加」のソースが来てます。
おかげで、似たような処理をしているロジックが結構あります。

実装された機能のアイディアはいいのですが、
改変内容が気に入らない場合、皆さんはどんな対応をしているでしょうか。

一旦受け入れて、後でガッツリ自分で改変するか、
理由を述べて却下して、相手に実装しなおしてもらうか、
どんな対応が望ましいのか、参考までに聞かせてください。
海外でどんな対応するのが一般的なのかも知りたいです。
よろしくお願いします。

こっちかな

GitHubやってる？
http://kohada.2ch.net/test/read.cgi/prog/1363523309/

gitでリポジトリを作成するとき、git initを使うんですか？

このコマンドだと自分のところが中央リポジトリになるように
思えるんですが、中央サーバに登録するには
どうしたらよいのでしょうか

git clone

>>49
サーバ側の実装による
リポジトリを作成する権限が与えられてるなら、何らかの案内があるはずだから
管理者に確認したらいいよ

>>51
すみません、わたしが管理者です
どう案内すればいいかいま検証中なんです

どこを中央サーバにするかって、単に運用方法の問題じゃないの？＠素人

中央サーバと末端PCがあって、
末端PCでプロジェクトを作ったのでそれを中央サーバに
新規に登録したいのですが
cvsのinitに相当するコマンドはgitにはないので

プロジェクトのファイルを中央サーバにコピーして
中央サーバでgit initして、それを
末端PCで git clone する という動きでよいですか？

>>54
よくない。空のリポジトリが作られるだけ
基本、サーバでgit initして、ローカルからpushだけど
実装によるから、それかかないと答えようがない

実装というか構成か

>>55
ローカルでinitしてサーバにpushすべきというのは理解しました

でも、最初の手順で空のリポジトリが作られるだけという
動きの理由がよくわかりません。

あ、逆ですか
じゃあ理解できてませんすみません

initで作られるのは空のリポジトリ
それをサーバに作った直後に、末端からcloneしたところで、エラーしか出ません
初回は必ず末端のローカルリポジトリから、コミット情報をpushしてやる必要があるのです

ということかと

んで、pushをするためには、ネットワークの構成を知る必要があるってとこかな

中央サーバに置くのは普通はbareリポジトリ
したがって中央サーバーで行うgit initは--bareオプション付き
なので>>54でgit init --bareしても空のリポジトリができるだけである
以上の思考が>>55の脳内で行われたのだろう

実際は、>>54が言うように中央サーバ上にファイルをコピーして
そのディレクトリでbareじゃないgit initすれば、
それは末端PCからgit clone可能な中央サーバ上のリポジトリになる

でも常識的に中央サーバに置くのはbareリポジトリなんで、
末端PC側でgit initで作ったリポジトリを、
中央サーバ上に作った空のbareリポジトリにpushするのがよい

中央サーバにbare形式で目的のリポジトリを作るだけなら、
ファイルコピーしてgit initで普通のリポジトリ作って
それをgit clone --bareでbareリポジトリ化するなんて方法もある

でも後々の運用を考えると、空のbareリポジトリを用意してpushしたほうがいい
空のbareリポジトリを用意する方法は、gitを直接使う以外にいろいろある

なぜ、構成を書いてくれないんだろう
もしかして、意味が伝わってないのか

構成は何を書けばよいでしょうか

マシンなら中央と端末の2台構成です。
ディレクトリなら、とりあえずファイル10個程度、ディレクトリは無しです。
開発者は二人います。ひとりはわたしです。

ああ、ごめん
>>61->>62はgit initの後にgit commit -am "〜"でリポジトリにファイルを取り込まないとダメね

書いてくれた構成よくわからなかったから、もうあてずっぽうで書くけど
git-daemon動かしてたり、gitoliteやgitlabみたいな管理ツールつかってるわけじゃないなら、サーバ上で
$git init --bare your_repo
してから、ローカルのリポジトリから
$git push user_name@server_address:your_repo master
ってすればいいよ。
あとは、ローカリにサーバから
$git clone user_name@server_address:your_repo

SSHが必要

>>64
中央サーバと呼んでるマシンのOSとサーバーソフトウェア次第で
その中央サーバにリポジトリを作る方法はいろいろあるってことだよ
君がそれを言わないから、Unixサーバのsshアカウントを利用する方法をみんな説明してる

すみません
gitでリポジトリを作る方法はsshでログインして作るのしか
知らなかったので質問の意図がわかっていませんでした。
おっしゃるとおりsshアカウント経由で作業する予定です

gitにも、cvsのようなpserver的なものがあるのですか？

>>68
Gitoliteとか良く使われてる

ここに目を通しておくといい
http://git-scm.com/book/ja/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC
4.8章にGitoliteの説明もある

リポジトリ自体はsshでログインして作るんだけどな
ていうか、ちょっとぐらいドキュメント読めよ

Gitolite使えばsshでログインしてリポジトリ作る必要無いだろう

すみませんどのページを見ても
同じことを同じやり方で解説してるところがほとんどなくて
その情報が古いのかモダンなのか間違ってるのか
とんとわからない状態でした

>>72
どのページってどこのこと。知らんよ
Chapter 4　Git サーバー
http://git-scm.com/book/ja/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC
この4章一通りよんでわからんかったら、もう無理だよ。諦めよう。
前提となるgitやサーバの知識が足りてないんだよ

gitolite使っとけばいいだろ難しいこと考える必要ないぞ
生のsshアカウントでやるのは権限とか考えるといろいろ面倒

俺もgitoliteが一番いいと思う

gitoliteってウェブインターフェースあるの？

>>76
gitoliteには組み込まれてないよ
だから、好きなウェブベースのgitクライアント使えばいいと思う
ていうか、普段使ってるgitクライアント使うのが一番いいと思うけど
turtoiseなり、sourcetreeなり

>>76
gitlabおすすめ。

gitolite＋githubクローンと
言ってもいいぐらいの
ウェブシステムだよ。

githubを使っている人や
逆に将来github使うって人には
いいとおもうよ。

あれよ
gitoliteはリポジトリとユーザ管理をgitolite-adminっていうリポジトリで行うから
そのリポジトリを自分が使いたいクライアントで触ればいいだけ

gitlabってRuby自前で2入れるように書いてあるのに、なんでわざわざインストールしてる1.8消させてんの？
自前でいれるなら、1.8消さなくてもgitlabが使えるように入れたらいいのに

>>80
Linuxはディストリがたくさんあって、
すべての環境がどうなってるのか把握できないから。
Rubyが二つ入っていると、何が起きるかわからない。

働けど働けどわがプロジェクト楽にならざり
Git手を見る

gitlabは機能見る度に入れようかなって思うんだけど、要件にデータベースがあるのをみて結局やめてしまう
>>81
ruby2を/opt/ruby2とかに入れて、gitlabでruby実行する時はそこを使うようにもできると思うんだけど

データーベースが要件で断念って
よくわからん。

ファイルと同様に極普通に使うものだろう？

>>82
歌人さんかな？

rubyのアプリは、rbenvやbundlerが良く出来てるせいで、
かなり無茶な感じに特定rubyの特定ライブラリに依存させたもの作って運用することができるけど、
OSのパッケージマネージャでそれらを管理するのは地獄の苦しみだな

今はどの言語もなんたらenvシリーズと
パッケージマネージャ揃ってるだろう？

(この流れは）アカン

せめて、gitlabとかgitoliteの流れに戻ろう

>>84
>ファイルと同様に極普通に使うものだろう？
そうかな
データベースサーバ新しく立ち上げるとか、既存のデータベースサーバにアクセスできるようにするとか
色々考えることあると思う

全部 /usr/local/mygit などにインストールして、そこから起動すればいいだろう

sqlite使えなくなってたのか。

gitを使い始めたもので管理について質問させていただきます。
WebページやWebアプリを作っているのですが、サーバ側のリモートリポジトリはそのプロジェクト毎に作成し、使うものなのでしょうか？
それとも他に一括で管理する方法があるのでしょうか？

Visual Studio 2013 Express で git が使えるようになったらしいので、今更ながら git 使い始めたんだけど、キーワード置換とかできないんだな...

>>93
質問がよくわからん
ローカルもサーバも違いはないよ

>>93
一つのリポジトリの中にディレクトリを掘って、
複数のプロジェクトのファイルを突っ込んでもいいし、
プロジェクトごとにリポジトリを作ってもいい。

どちらも一長一短ある。
プロジェクト間でファイルを共有しているなら一つのリポジトリにして、
そうでないならわけた方がいいかもしれん。

わけておけばプロジェクトごとにリポジトリのcloneが可能だが、
そうでないなら全部cloneすることになる。

プロジェクト間で共有されるファイルはsubmoduleにしたほうがいいのでは？

それ、サーバ、ローカル関係なくない？

>一括で管理する方法があるのでしょうか？
って聞いてるから、管理方法をしりたいんじゃなかろうか。。

>>96
ありがとうございます。
プロジェクトごとに分けることにします。

gitってmacやwindowsでも操作同じ？
「アリスとボブのGit入門レッスン 」という本がよさそうなんだけど
この本macで解説してるんで聞いてみた。
gitってなんでこんなに名が知られていないんでしょうかね？

>>97
俺ならsubmoduleを使うが、あの使いこなすのが難しい機能を
「使い始めた」と言っている>>93に勧める気にはなれなかったので。

>>100
git自体の操作はどれでも同じ
知名度をいうなら、プログラマでgit知らない人いないぐらいだと思うけど、>>100の周りではそうじゃないの？

ボブ「Gitからメッセージも出力されているね。」
アリス「メッセージは英語なのね・・・。」
ボブ「そうだね。英語だね。でも、簡潔な言い回しだから、じっくり読めばおおよその
意味がわかると思うよ。最初だから日本語訳を付けておくね。」

>>100
> gitってなんでこんなに名が知られていないんでしょうかね？

可哀想に。使えないならともかく知らないっていうのは、
プログラミングに興味が無いと言っているのと同じレベルだぞ

>>94
commitしたファイルのチェックサムが、リビジョンになるからね

>>101
ごもっとも　俺もいざとなったら調べて使うだろうが今のところ練習以上に使ったことはない

>>105
う〜ん、別にチェックサムでもいいのでソースに埋め込ませてくれてもいいと思うんだけど。
コミットした日時とか、人とかもあると嬉しいし...

>>107
チェックサム埋め込んだらチェックサムが変わっちゃうじゃないですか。

チェックサムを埋め込んだらチェックサムが変わってしまったでござる

チェックサムの無限ループや！

チェックサムがッ！一致するまで！再計算するのをやめないッ！

>>102>>104
ほとんどひとりで個人の趣味範囲
こういうのを使ってソフトを作成していったんですね
ソフト作りも製造業に似ていますね
どちらというと一人やっているほうが楽しいかね

>>108
Subversion 知らないの？
リポジトリから取ってくる時に埋め込むから、リポジトリのリビジョンは変わらないよ。
git でもできると思うんだけど。

キーワード置換ってなに？

>>94へ朗報>>113

>>113
それ、取得元の証明であって、手元にあるものがソース＋チェックサムだってどうやってわかんの？
そもそもcommitログでチェックサムも日時も人も全部わかるじゃん

>>116
サムチェックだと考えるからわからんのだよ。
ファイルの内容とは無関係なGUIDのような任意のIDだと考えたまえ。

任意のIDはファイル内容を変えても、変わらんよ？

Git - Gitオブジェクト
http://git-scm.com/book/ja/Git%E3%81%AE%E5%86%85%E5%81%B4-Git%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88

>>115
同一人物なんだが...

>>116
> それ、取得元の証明であって、手元にあるものがソース＋チェックサムだってどうやってわかんの？

もちろん、取得したやつは変更し放題だからリポジトリの内容と同一かは保証できないけど、あえて変なことしなきゃいいだけでしょ？
そもそもそれは Subversion でも、同じだし。

> そもそもcommitログでチェックサムも日時も人も全部わかるじゃん

いや、印刷したソースとか、実行ファイルに埋め込んでおいて、問題が発生した版はどれだっけ？ とか、git から離れたものを特定したいんよ。

>>119
あ、おまえ、スクリプト言語しか使ってないだろ？

ソースコードを直接実行するタイプの。


いるんだよねー。
ビルドという工程の存在を知らない人ってｗ

gitって奥が深い？
gitってなんの言語で書かれているの？

>>114
ソースコードの中に $Rev$ とか入れておくと、自動的にそのファイルのレビジョンに置き換えてくれる機能。
レビジョンだけでなく、ファイル名とか、コミットした日時や人とかに置き換えができる。

>>119
git でもできると思うんだけど。

ソースコードの中の著作権とかの名前のように
原則として変わらないものは意味がある。

だがコミット日時やコミットした人の名前のように
頻繁に変わるもの（$Rev$というのは変わるものにつけるもんだが）
に関して、そんなものを埋め込む意味は無い。
そんなのを埋め込んで役に立ったためしがない。

これが答え。

>>120
文字列に埋め込んで、実行ファイルがどのソースからビルドされてるかを後から確認するとかもできるよ。
ident とかそれを見るための専用コマンドがあったりしたんだが...

コミットした人ってさ、
複数の人がコミットしている場合
行ごとに違う人が修正していることって
よくある話だけど、

コミットした人の名前知ってどうすんの？

そういうのはソースに書くのではなく
バージョン管理システムに任せなさい

>>125
え？ ソースファイルってたくさんあるじゃん。
実行ファイルが、どのソースファイル（全100ファイル）郡から
ビルドされてるかしってどうするの？

そんなもん、ソースファイルに埋め込むんじゃなくて、
ビルド時に生成したリビジョン番号を埋め込むだけだろ。

>>123
やり方、教えて。

>>124
いや、君のところでは無意味なんだろうけど、有効に使ってる人もいるのよ。
SCCS から使ってるけど、有名どころの SCM でできないやつは git が初めてなんだわ。

例えばこんなの。

簡易ビルドスクリプト


$ build.sh リビジョン番号

gitから指定したリビジョン番号をチェックアウト
echo リビジョン番号 > revision.dat
コンパイル時にresivion.datを埋め込み
実行ファイル生成

>>94
SubversionとGitの大きな違いはブランチのスイッチが瞬時にできること。
対象となるブランチがローカルにあるのでそれができる。
キーワード置換があったら、ブランチのスイッチで置換が必要になるので遅くなる。
だからキーワード置換の機能はGitにはない。

Gitにキーワード置換を加えるパッチは、そういう理由でLinusに却下されている。
http://thread.gmane.org/gmane.comp.version-control.git/44750

>>129
> いや、君のところでは無意味なんだろうけど、有効に使ってる人もいるのよ。

日付ごとにディレクトリ作ってバックアップするという作業を
”有効に使っている人” もいるでしょうねｗ

意味が無いことを有効だと勘違いしているだけ。

キーワード置換なんてビルド時にやればいいだけじゃん？

ソースコードを誰が（最終）コミットしたかなんて
わかるんだしさ。なんなら全コミット者だってだせるよ？

印刷も、印刷時にキーワード埋め込みをすればいいだけ。

>>129=94=113?
ほい。
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#%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E5%B1%95%E9%96%8B

>>126
まあ、最後のコミッターにそんなに意味があるかと言われたら、俺もそれほど重要とは思えないけど、コミッターがあまり変わらない場合もあるから、できてもいいじゃんぐらいだと思う。
それはそれとして、そのファイルのレビジョンを知りたいんだよ。

>>127
もちろん、SCM に任せるんですよ？
SCM を離れたソースコードを特定したいと言う話。

>>129
やり方はここに書いてあるがはまりどころ満載なのでお勧めしない。
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#%E3%82%AD%E3%83%BC%E3%83%AF%E3%83%BC%E3%83%89%E5%B1%95%E9%96%8B

Gitを使いこなすコツは「ほかのSCMでは××だった」という考え方をすべて捨て去ること。
それができないならその「ほかのSCM」を使っていた方がいい。

Visual StudioのGitのインターフェイスが罪深いのは
「ほかのSCM」の知識でわりと使えるようになってること。
Git本来の使い方からかなり離れてる。
コマンドラインで使い方を覚えておかないと、いつかはまることになるよ。

>>135
> SCM を離れたソースコードを特定したいと言う話。

だから、SCM から離す時に埋め込めばいいじゃん。

>>135
> それはそれとして、そのファイルのレビジョンを知りたいんだよ。

gitに問い合わせればわかる。

>>130
なるほど、こう言うのがあるのか。
ちょっと見てみる、サンクス。

>>131
なるほど、だから >>130 みたいに外部でやると言うことになるのかな。
しかし、全部見れてないけど結構議論されたんだな。

>>132
> 意味が無いことを有効だと勘違いしているだけ。

まあ、俺だけならそう言う可能性もあるけど、SCCS, RCS, CVS ... 勘違いしてた人は他にも一杯いたんだよ (w
さすがに、書いてて恥ずかしくない？

話変わるけど、git bisectって凄いよね。

例えば、何処かで動きがおかしくなったとするじゃん？
どこかのリビジョンでは正常だったことがわかってる。
どこかのリビジョンではおかしくなったことがわかってる。

そういった時に、正常と異常の二つを指定するだけで
そのその中間のソースコードを取ってこれる。

そしてそれがちゃんと動いているか確かめる。
正常であればgit bisect good、異常であればgit bisect badを実行する。

そうすれば、今度は正常と異常の中間を取ってくる・・・と繰り返すので
最初以外リビジョンなんか考えずに、どこでおかしくなったかを探すことが出来る。

>>139

> まあ、俺だけならそう言う可能性もあるけど、SCCS, RCS, CVS ... 勘違いしてた人は他にも一杯いたんだよ (w
> さすがに、書いてて恥ずかしくない？

勘違いしていた人は成長した。
お前は成長しないの？

新しいものを使っていて、古いやり方をするのは
何も成長してないからね。

プログラミングでもいるんだ。
新しい言語、新しいライブラリを導入しても
古いやり方のまま続けて、導入した意味を無くす奴ってね。

>>136
> それができないならその「ほかのSCM」を使っていた方がいい。

それはそうなんだけど、Visual Studio の Express (=無償版) には、git と TFS のクライアントしかないんだわ。
まあ、貧乏なだけなんだが (w

>>137
うん、そうなんだけど、他の SCM の多くはその機能が本体に組み込みだから git もそうだと思ってたんよ。

>>138
話の流れ追えてます？

>>141
git が最新ともベストとも思えないので、成長とか意味わからん (w

>>142
そもそも将来的にメンテする可能性のあるものを何故gitからわざわざ離すのかもよく解らんのだが…
仮に離すとしても、そいつはメンテせずに
大元のほうを残して、そっち使ってメンテしないか？

94はキーワード展開のやり方教えてもらったんだから
smudge フィルタをさっさと書けよハゲ

定期的に「ある特定のファイルのリビジョン」という話をする人が出てくるなあ
俺の理解だと，gitでそういう話をするのは無意味だと思うんだけど

>>144
いや、離した奴をメンテとかは (普通は) しないよ。
実行ファイルの提供とか、印刷とか離れちゃう奴をどう特定するかの話。

>>145
まあ、あせるなよ。
せっかちなやつはモテないぞ (w

以前ファイルごとのリビジョンの話もあったけど、
ソースツリー全体まとめて何かになるのであって、ファイル単体それぞれを
適当に持って来てもどうにもならないということが理解できるかで
意見が別れるようだね。

リリース管理せずに、何かあったらファイル単体だけメールで送っちゃう
ような運用だと、ファイル単体に情報は必要だろう。
場合によっては行ごとにリビジョン番号を埋め込みたい人もいるかもしれないw

金がないなら自分で工夫するんだ。頑張れ!

>>142
Visual StudioのGitはリポジトリのビューワーとして使った方がいいよ。
あれでチェックインその他の操作を覚えてもろくなことにならない。

将来Gitを使いこなしているチームに君が加入することがなく、
チームに新たにGitを導入する指揮を君が取ることもないなら、
Visual Studioから使っていても構わないけど。

出来ないことはやってはいけないこととする流儀があるんだよね。
たとえば日本語ファイル名とか。
ファイルの名前を日本語にしてるんだぜ？馬鹿だろ？なんて真顔でのたまっていた時代、
人たちがほんとにいたんだよ。

メールでパッチ送る方法ならgitに
ついてる

まずちゃんとgitのやり方を学べ
変なやり方はやめて成長するんだ

>>150
多くの人が使っているツールのやり方と自分のやり方のどっちが良いか
って話じゃないかな。業務パッケージに業務を合わせるか、業務に合わせて
ソフトウェアをカスタマイズさせるかの違いというか。自分のやり方の
方が良いかは置いておくとしても、カスタマイズにはコストがかかるのは当然。

日本語ファイル名はMS-DOS2.11で普通に使えてましたね。UNIXの人たちは…w

nihongo-de-nani-ga-warui.txt

>>148
Subversion 使ってるので、ソースツリーのリビジョンとかは違和感ない。
ただ、印刷してレビューとか、外注さんにソース渡すとかあるんだよね。
まあ、そう言う運用には向いてないってことなんだろうな。

>>150
いまでも、日本語ファイル名は結構鬼門だよ。
海外製のツールはダメなやつ結構あるし、OSS でも Doxygen とか...

日本人（と本人は主張している）が日本語を使ってはいけない理由を説明して
一生懸命日本語を否定してた。
本来は1億人の日本人を説得するのではなく、少数にすぎないソフトウエア発行元を
説得したりお願いしたりしたほうが良かったと思う。
まして、年寄りは日本語を使いたがるとか初心者は日本語を使いたがるとか
ドザは日本語を使いたがるとか、日本語を使う人間は劣っているかのような
イメージを植え付ける必要はなかったんじゃないかな。

単にコマンドラインで日本語ファイル名を入力するのがめんどくさいから使ってないなあ

>>113
CVSの頃はよく使ってたけど、SVNだとあんま意味無いからmakeでやってたな。

>>152
MSがすぐ互換性崩して妨害しようとするから、ファイル名などのようなとこはメジャーなものでないと危険。

印刷してレビューするだけで
なんでソースコードに
リビション番号を書かないと
いけないのかわからない

印刷のヘッダに書けば事足りるだろ？

外注に渡すにしても
zipに同梱すればいいじゃないか
zipのファイル名がリビション番号
なのもよくある事だし

>>150
Unicodeが普及した後にマになるとこういう発想が出来るのか

何を勘違いしてるんだお前らは。
キーワード置換そのものが古いとか不要とかいうのはおかしいぞ。
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#%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA%E3%82%92%E3%82%A8%E3%82%AF%E3%82%B9%E3%83%9D%E3%83%BC%E3%83%88%E3%81%99%E3%82%8B

>>159-160
今までそうやってただけで、機能としてはヘッダーでもいいんだけど、そうすると印刷ソフトに依存するでしょ？
zip 同梱とかは、ソース一つとは限らないし、目視で対応付けとかは勘弁してほしい。

>>161
最近の環境使ってれば、そんな変な感覚とは思えないけど？

>>162
あぁ、それで問題ないな。

エクスポートする時やアーカイブを作る時に
自動的に入れればそれで事足りるわけだし。

>>163
> 今までそうやってただけで、機能としてはヘッダーでもいいんだけど、そうすると印刷ソフトに依存するでしょ？

なんで印刷ソフトが関係有るんだ？
エクスポートしたり、印刷する直前に、
ファイルの頭につければいいじゃないか。

それをコミットしなければいいだけの話だよ。

すべてのソースコードに一行付け足すことが君には難しいの？

>>163
ってアーカイブをする作る時に
WindowsのGUI使って
.gitディレクトリ選ばないように選択して
右クリックメニューからzip作ってそうｗ

CVSだとファイルごとにバージョン違ったりするけど、SVNやgitだと同じでしょ。それでもファイルごとに付ける意味あるのかな。それとも最後に変更したIDをつけるの?

ファイルにバージョン番号がなくて
どうやってファイルを管理するのか？

（バージョン管理ソフトを知らない）

もしファイルを二つ提示されて
それが同じかどうかどうやって判断すればいいのか？

（diffを知らない）

ファイルにバージョン番号が含まれていれば、
それが分かるんですよ。

（それ以外の方法を知らない）

いちいちファイルを手動で書き換えるのは面倒ですよね？
だからキーワード置換が必要なのです。

（自動で全部のファイルを書き換えるプログラムを作れない）

一体これの何がダメだというのでしょうか？

（プログラミング技術がない素人だから金もらってはダメ）

>>165
ああ、すまん、印刷でヘッダーっ言うと、各ページに印刷される奴のこと言ってるんだと思ったんよ。

>>166
君のおすすめの方法を教えてくれまいか。

>>167
> 最後に変更したIDをつけるの?

そう、Subversion 使ったことないかな？

>>168
> もしファイルを二つ提示されて
> それが同じかどうかどうやって判断すればいいのか？

もし、キーワード置換の話のこと言ってるとしたら、全然違う話だから。
全てのレビジョンと比較するつもりなら止めやしないけど...
まさか、違うよね？ (w

>>170
違うに決まってるだろ
そんな勘違いするのお前だけだよ。
馬鹿じゃないのか？

ここまででよくわかった。
gitにキーワード置換を搭載する意味は無い。
代替方法で、全く同じことができるし、
そもそもやる意味が無いということだ。

>>169
svnが出てくる前からcvs使ってて、svnはできることそんな変わらないのに、不便な点が多くてあんま使わなかったな。svn使ってる客ってにわかなのか、単にファイルコピーとしか使ってない人が多かったし。タグ埋め込みなら使ってたかな。

>>171
そうだよね、安心したわ。

で、
> もしファイルを二つ提示されて
なんて、どっからでてきたの？ (w

>>173
確かに、タグ埋め込みとか言ってる時点で svn 使えてなかったのは、よくわかるわ。

>>172
てか確かSVNでも非推奨ってことで、デフォルトではオフになってないっけキーワード置換

>>176
非推奨じゃないよ。
Subversion は指示されないことはやらないと言うポリシーなだけ。
拡張子で自動設定する機能もある。

やっぱり、リリース管理なんてめんどくさい、適当な仕事でいいって場合は
なんか勝手に入れてくれると楽って話だろうねえ。
まともな仕事をしている人は、そういうの認めたくないんだろう。

>>163
UNICODEは正規化の話がね。MS-DOSの頃の方がある意味まともだった。

>>178
> やっぱり、リリース管理なんてめんどくさい、適当な仕事でいいって場合は
> なんか勝手に入れてくれると楽って話だろうねえ。

ごめん、適当とか勝手にとか言ってる内容がさっぱりわからん。

>>175
どういうこと?

>>175
どういうこと?
タグじゃなくてブランチ名って言えってこと?

>>180-181
タグ埋め込みなんて言わないでしょ？
タグを打つとかは言うけど。

そもそも、キーワード置換なんて
ソースコードに入れる必要がないわけで。

あんなのCVS時代の遺産だよ。
CVSはファイル単位の管理しか出来なかったからね。

そう、リビジョン番号なんてのは
エクスポートした時に自動で埋めればいいだけ
そういうのが必要な人は自分でやればいいやん。
gitの文化で要らないものはつけてない。それだけの話。

うっとうしいので>>94はいちいちバカの相手をするのをやめてくれ。

>>184
まあそういうことみたいやね。
>>134 >>136 >>162 で URL 教えてもらえたし、あとは何とかするわ。

>>185
ああ、すまん。
マジで git 使うの初めてだから、もう少しこのスレのレベル高いかと思ってたんだけど、大体わかったから、あとは適当にスルーするわ (w

馬鹿を相手にするのは馬鹿だけってことですよ
キーワード展開については前スレでもその前のスレでも>>162のリンクで終わってる

ほんと毎回うっとおしいんだよね
テンプレにはhttp://git-scm.com/のトップだけ入れてあるけど、
日本語目次のURLとよく話題になる章の見出しも入れといたほうがいいんじゃない？
http://git-scm.com/book/ja
4. Gitサーバー
4.8 Gitolite
7. Gitのカスタマイズ
7.2 Gitの属性 (バイナリファイル / キーワード展開)
8. Gitとその他のシステムの連携
8.1 GitとSubversion (git svn)

>>182
あなたは思い込みをしているようだ。
バイナリとかにタグを入れることだよ。

こういうレベルの低い技術者が末端に居るだけなら叩き出せば済むんだが、そうでないと無駄な作業で工数取られてイライラすんだよな
マニュアルすら通読しないし救い難い。VSProを買う金すらねぇならもっと勉強しろよ。お前にゃgitはまだ早い

調べもせずに質問ってが腹立つのはわからんでも無いが、gitに早い遅いがあるのか？
嫌なら初心者スレでも立てて隔離すりゃいいんじゃね

ここはお前の日記帳だ

>>191みたいなうるさいだけで非生産的なやつが一番困る

>>192
なんかやなことでもあったんでしょ
優しくスルーしてあげましょう

Subversionでもキーワード置換できるけど使いたいという奴は老害ばかりだよ

老害かどうかなんて一概には言えんのだが、
確かにその傾向は強く感じる

キーワード置換はできるからやってるだけで
やる意味があるからやっているわけじゃない。

authorを捏造して納品しろと言われて、リリース時にヘッダを
書き換えるようにしたら簡単かつ綺麗だったので、
CVSでも置換はやらなくなったな。

しゃちょー、PeercastStationエラー落ちのままだったら
新しいクライアントつなげないから、再起動しておくれ

Git 1.8.4.2
https://code.google.com/p/git-core/downloads/list

git cloneすると
リポジトリになくてローカルにあるファイルや
ローカルで編集済みのファイルとかは
どうなりますか？

どうもならん

もうどうにもならない

pull requestでコード貰ったんですけどこれってそのまま取り込んでもＯＫですか？
ライセンスとか面倒なことになりますか？

それはpull req投げたヤツに聞けよ

githubにしろpull requestのページでコメントでやりとりできるしな

Tortoisegitを使っていて
pushするときにサブモジュールを再帰的にチェックとあるんですが
どういう意味ですか？

サブモジュールのサブモジュールのサブモジュールもチェックするよー

初めてGithubでPull request来たのですが
これってブランチを別につくってそこでテストしてから
マージするのが普通なんですかね？

すいませんmasterブランチにプルリクエストでコードが来た場合
それをtestブランチに入れる方法を教えてください

馬鹿には無理

>>210-211
You can also merge branches on the command line.

masterブランチ以外にマージするなら
Github上じゃなくて他のGitクライアントでの作業が必須だな
別にコマンドラインである必要は無いと思うけど
コマンドライン以外の手軽な方法は知らん

プルリクエスト送ってくれたとこのフォークリポジトリからローカルにフェッチだかクローンだかして
ローカルでマージテスト用ブランチ作ってそこにマージしてテストしてからローカルのマスターにマージしてプッシュ

シングル ベンティ キャラメル アーモンド ヘーゼルナッツ モカ ホワイトモカ
チョコチップ エキストラホイップ キャラメルソース チョコソース バニラクリームフラペチーノ

バカがmasterブランチにさえプルリクエストを送らなければ僕は悩まなかった

じゃあどこにプルリクエスト送るんだよ

あの、Pull Requestを取り消すほうほうってありますか？

>>219
アカウントを消す

取り消すことは出来ないけど、クローズすればいいよ。クローズする理由をコメントで添えておけば尚ＯＫ

プルリク要らなきゃプライベートリポジトリにしておけ。
金払いたくないならbitbucket.orgでやれ。

論点ずれてる

じゃ、こっちかな

GitHubやってる？
http://kohada.2ch.net/test/read.cgi/prog/1363523309/

http://itpro.nikkeibp.co.jp/article/NEWS/20130529/480625/
年収は必須です。

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

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

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

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

コードブレイクか
sshとpull requestはもうサポートされたんじゃなかったかな？

気になったけど、スキルとか年収とか書くの面倒くさそうで止めた

年収0なら0と書けば良いだけ
無理して嘘を付く必要はない

画像を加工したいのですが、変更したらコミットしていく使い方も出来ますか？

ソースコードを書く目的以外で使わないほうがいいのでしょうか？

>>227
じゃあお前の年収をここに個人が特定できるように書いてみて。
書けないのなら、書けない理由を書いてみて。

Windows で git 使おうと思ってるんだけど、まだ日本語ファイル名は鬼門なんだっけ？

>>228

差分を見るのにはいろいろ工夫が必要になるけど、
単に過去のものに戻れるだけでも版管理の意味はあるよ。

gitならテキストもバイナリも保存容量の効率変わらないし。

画像はSVGにしておけば差分取るにも効率が良い。

SVGの差分を見て何がわかるというのか？

エレメントの追加削除、属性の変更くらいならわかるだろ。

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

加工ミスしたときに前バージョンに戻るために使いたいと思います

いや、画像を修正する作業を見てみ。

画像でみればほんの僅かな修正だが、
SVGのデータで見れば、大きく変更が
ある修正が大半だよ。

それをテキストの差分見て何を読み取れるのかって話。

>>>222
これか

BitbucketでGitとMercurialの無料ソースコードホスティングを
https://bitbucket.org/

>>237
プライベート&ぼっち、って条件なら有名なトコだな

GitHubでの公開ぼっちとどっちがマシか

でもさいきなりサービス終了とかしたらどうするの？

「突然終了したらどうなるの？」
これって有償サービス無償サービスもネットもリアルも関係なく存在する話だよね

プッシュしたものが正常に送れたか確かめる方法はありますか？

あります

>>241
gitなら全コピー手元にあるんでしょ。

あそっかサービス終了してもローカルにあるから大丈夫か

それで安心なのはリポジトリのデータ保存という点だけな

データさえあればまた別のところで再開もできるし他に何が要るのか

リポジトリのデータを、Gitでバージョン管理

GitHubなどのサービス上でやったやりとりのデータが消えたら悲しいって話じゃないの？

>>241
有償無償かじゃなくて、自分でサービス立ち上げるか、ほかのサービス使うかの話でしょ

スレチじゃね？
ttp://kohada.2ch.net/test/read.cgi/prog/1363523309/

そこを正規のGitHubスレにしていいものか微妙だが
OSSのホスティングの総合スレみたいなのが欲しいところだね

【板名】 ネットサービス
【板URL】 http://toro.2ch.net/esite/
【タイトル】 OSSホスティング総合【SourceForge,GitHub,etc..】
【名前(省略可)】
【メール欄(省略可)】
【本文】↓
OSS(オープンソースソフトウェア)ホスティングサービスについて情報交換したり語り合ったりするスレ


OSSホスティングサービスの例
SourceForge GitHub GoogleCode Bitbucket Launchpad CodePlex など


Comparison of Free/Open Source Project Hosting (FOSPHost) Sites Available for Hosting Projects Externally from Project Owners
http://www.ibiblio.org/fosphost/exhost.htm

OSSホスティングサービスの比較 - Wikipedia
http://ja.wikipedia.org/wiki/OSS%E3%83%9B%E3%82%B9%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E6%AF%94%E8%BC%83

Comparison of open-source software hosting facilities - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Comparison_of_open-source_software_hosting_facilities

>>252
確かにGitHubの本スレ扱いにしていいかはちょっと迷ったんだよね
パッと思いつく対抗馬のbitbucketのスレは無かったし

>>253
まさにそんな感じのスレ欲しいｗ

素人が紛れ込んできても面倒だし、esiteじゃなくてここでいいよ。
gitやsunversionスレもソフト板じゃなくて、ここにあるので問題ないでしょ。

テンプレをブラッシュアップしてここに立てよう

おれもム板がいいと思う
ムの人しか使わないし

秘密鍵とかをDropboxにそのまま保存するのってやめたほうがいいですか？

>>257 スレ違い

日本語ファイル名使って何が悪い!
という奴らって例えば支那語のファイル名をまともに扱えない現実を見たことがないんだろうな

>>253
それ、あくまでOSS限定なんだよなー
プライベートのリポジトリホスティングサービスも扱いたいね

じゃあOSSホスティング総合スレじゃなく、リポジトリホスティング総合スレにするか

ブスはGIT使うな

>>229
個人が特定できるように書く理由ってなに？

git rm '>>263'

gitignoreにtmp/**/*って書いてもtmpフォルダ以下のファイルが無視されないんですが

.gitignore

/classes
/tmpclasses
*.class
*.jar

>>265
tmpだけでいいのでは？

.gitignoreとか.gitconfigとかこういうGitに関するファイルの一覧ってありませんか？

GitlabとSourceTreeでGitデビューし始めました。

http://blog.shinji.asia/sourcetree_git/
を参考に進めているのですが、認証エラーになります。
たぶんSourceTreeでSSHキーの生成をして
Gitlabに登録を交換しないといけないのだと思いますが
そこら辺がよく分かりません。

一通り書かれたサイトとかあれば紹介いただけないでしょうか

SourceTreeいいよね
ぼくも好きですよ
今はコマンドラインしかつかってないけど

sshのキーはどこでも作れる
っ http://www.openssl.org/

Windowsでキーの作成にputtyを使うのは地雷記事
git付属のbashで作るべき

どれで作ろうが同じじゃねーの

そもそも公開鍵と秘密鍵も理解できていないのですが
>>271
テキトーなソフトでキーみたいな暗号文字列を作ったとして
それをGitlabとSourceTreeの両方に登録したらいいんですか？

puttyで作った公開鍵をSourceTreeに登録しようとしたらパスフレーズを聞いてきて
作ったときに指定したつもりのものを入れてもBadと怒られてしまいます。

Soucetreeではどのように SSHの設定をすればいいですか？ - Bitbucket ドキュメンテーション - Atlassian Japan Confluence
https://confluence.atlassian.co.jp/pages/viewpage.action?pageId=35815464

windows版 SourceTreeでsshを利用してGitHubにpushとかpullとかする方法 - Qiita [キータ]
http://qiita.com/kyanro@github/items/60a9dc5a32ed1562fec2

Tips : SourceTree for Windows で SSH key を登録しても認証に失敗する - Qiita [キータ]
http://qiita.com/Kentrow@github/items/472c4454f92feb361cd6

SourceTree for Windowsで秘密鍵と公開鍵を生成！ ≪ LANCARD.LAB｜ランカードコムのスタッフブログ
http://www.lancard.com/blog/2013/04/11/sourcetree-for-windows%E3%81%A7%E7%A7%98%E5%AF%86%E9%8D%B5%E3%81%A8%E5%85%AC%E9%96%8B%E9%8D%B5%E3%82%92%E7%94%9F%E6%88%90%EF%BC%81/

apeirophobia: How to make SSH key with SourceTree on Windows
http://blog.img8.com/archives/2013/04/005791.html

「GitLab」を使ってGitリポジトリを管理 - Tech-Sketch
http://tech-sketch.jp/2011/12/gitlabgit.html

GitLabのヘルプページがGitHub上にあってワロタ

GitLabってGitHubのクローンだったのか

GitLabって社内LAN内にGitHubみたいな共有環境を構築するってものなのか、
個人では使う機会なさそうだな

>>271
opensslじゃなくてopensshだろ

ローカルで GitHub を構築！ Git リポジトリ管理ツール「GitLab」を Mac OS X にインストールしてみた ｜ Developers.IO
http://dev.classmethod.jp/tool/gitlab-install-mac-os-x-mountain-lion/

>>276
どうもありがとうございます。
Githubではうまくいってますが、Gitlabとの組み合わせがよく分からないんです。

しかも自分のSourceTreeが1.3.1.0と新しく、なんか微妙に画面も違うしぃ・・って風でして

うぉーー出来ました！！
SourceTree→ToolsOptionで、SSH Client のコンボボックス
OpenSSH から PuTTY/Plink に変更したら見事に成功

GitlabとはSSH通信なのでOpenSSHだと思い込んでいたのですが・・・
OpenSSHとPuTTYの違いって何ですか？
ってのはスレ違いなので、検索してきます。どうもありがとうございました。

ソケットとかいうものが問題なのか
OSがM$だとターミナル的なもの以外ではOpenSSHをうまく扱えないものがほとんどなんだよね

>>279
redmineは使ってるけどな。

M$で開発とか拷問。

vs以外で開発とか考えられん

サーバのホームディレクトリをサンバ共有したら、sshの自動認証ができなくなってちょっと焦った思い出

Gitで体をバージョン管理できたら
病気や老後に若い体に乗り換えればいいですよね
誰かそういうのできるプラグイン開発してくれませんか？

どこにも異常のない一番元気なときに
あとで簡単に各部位毎に取り出せる形で
IPSで体全体のコミットがその都度出来たら
臓器バンクビジネスにソフトバンクが手を出すだろうね

健康状態の遺伝子を保存しておけば実現可能な木もするんですけど

>>289
記憶も戸籍上の年齢や経済力も元に戻りますが

>>289
情報量が多すぎてcheckoutしたら最後のバージョンの手だけだったとか。

>>292
.gitignore

>>294
戸籍も資産もなくなるわけですね。

Git 1.8.4.3
https://code.google.com/p/git-core/downloads/list

1.8.5じゃねーのか？

gitってグーグルコード上で開発してたのか

俺の使ってるの1.8.3だった

メンテナンスしてる濱野氏がGoogleにいるからかね？
Githubにもリポジトリあるけど https://github.com/git/git
これはミラーでpull request are ignoredとか書いてあるのにいくつか飛んできてるのが笑える
Documentation/SubmittingPatches見る限り、なんか修正して欲しかったらパッチ送れって方針なのね

1.8.4に移行したらbashで日本語が入力できる！！！
1.8.3以下は今すぐ切り捨てろ！！！！

>git --version
git version 1.7.4.msysgit.0

さっき`~/.config/git/ignore`が読まれなくて手間取ったのはバージョンのせいだった

>>301
msysgit のこと？

え・・・どういう事だ・・・？
今まで日本語入力できなかったの？
日本語入力ができなかった頃なんて俺知らないんだけど・・・

1.8.4入れてGit Bashを起動してみたけど、相変わらず日本語は?????だったよ

Git GUIのほうは1.8.3のときも日本語は普通に表示できてたし

端末の問題じゃないのか。

とにかく、Windowsを使うのを止めろ

Gitですけどファイルの同期は取れるんですが
タイムスタンプがバラバラ

タイムスタンプも揃えること出来ないですか
(同期させること出来ませんか)

>>309
さんざん既出
5スレ目の1から75まであたり参照

去年から mac のターミナル（bash）で Git 使い始めて、コミットメッセージを日本語で入力してるけど問題無いよ。
git commit で vim が起動して入力しても、git commit -m でコマンドラインで入力しても問題無し。
git log で表示しても日本語が正常に表示される。

Windowsで使うときだけ地雷

Windowsが地雷

GitはコミットメッセージはUTF-8なのでUTF-8で入れてる限りWindowsでも問題無いでしょ
ところでMacはNFD-Macなパス名は解決できるの？

ファイル名やフォルダ名がShift-JISエンコードの日本語だもの

他のソフト使いにくくして、MSのソフト使わせる戦略ですから。

MSのソフトって使いやすいんですね

Appleのソフトよりは質実剛健とは思う

>>314
解決出来ないよ

いつ2.0でるのですかロードマップないんですか

直前のコミットまで戻すにはどうすればいい？

>>321

Git - 作業のやり直し
http://git-scm.com/book/ja/Git-%E3%81%AE%E5%9F%BA%E6%9C%AC-%E4%BD%9C%E6%A5%AD%E3%81%AE%E3%82%84%E3%82%8A%E7%9B%B4%E3%81%97

Git - Git によるデバッグ
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-Git-%E3%81%AB%E3%82%88%E3%82%8B%E3%83%87%E3%83%90%E3%83%83%E3%82%B0

>>314
core.precomposeunicodeを設定したら、ファイル名に対してNFC変換が行われるのでMacでもだいたいOK
実は微妙に違うんだけど、普段使う程度の文字ならだいたいOK

USBメモリのルート（ドライブレターはG:\）にクローンをしてみたのですが
fatal: destination path 'G:' already exists and is not an empty directory.
とエラーが発生してしまいます。
フォーマット直後でも同じエラーが発生します。
ルートにはクローンできないものなのでしょうか？

エクスプローラーで開いた時点でdesktop.iniやthumbs.dbができてしまってるとか？

フォルダーオプションで隠しファイルを表示するにして
「保護されたオペレーティングシステムファイルを表示しない」のチェックを外しても
desktop.ini や humbs.db が表示されないので空の状態になっていると思います

>>325
USBメモリのドライブをNTFSフォルダーにマウントするとできるかも知れない

>>325
initしてremote addしてpullすればいいんじゃない。

>>329
なぜかpullコマンドを実行してもpullが始まらない。
リモートから何も受け取っていないみたいでローカルは変化なし。

URLをタイプミスしてるとかはないの

100ファイルあるファイルの中からa.txt b.txtのみを管理したいんですが
98ファイル分を.gitignoreに書くのが面倒くさいのですが何か良い方法教えて

>>330
リモートに何もないんじゃないの。

同じリポジトリをルートじゃない普通のフォルダでは成功したとかなんじゃね

>>332
*
!a.txt

シェルでもスクリプトでもファイルの列挙を書き出してa.txtとb.txtだけ削除すればいいじゃないの

ゲームループ
1.ゲームスタート
2.あなたのAIが数を思い浮かべる(表示可能にする）
3.あなたのプログラムは敵AIの名前と思い浮かべた数の入力を待つ
4.あなたのプログラムはあなたのAIと敵AIに交互に推測させ、どちらかが当てるまで繰り返す
　（先攻が当てた場合、後攻にもう1度推測させる。両者同じ回数で当てた場合は引き分け

これって、2.のAIが数を思い浮かべるレベルのループを作れっていう意味じゃないよね？

ttps://github.com/github/gitignore
>A collection of useful .gitignore templates

これ便利そうなのに、使いたい言語のが無かった

>>332,335

gitで管理しないファイルを無視させる .gitignore｜misc｜@OMAKASE
http://www.omakase.org/misc/gitignore.html

koreka

つかオリジナルの説明読めばいいのか

Git
http://git-scm.com/docs/gitignore

githubって容量無制限？
公開されるの気にしなければ
バックアップに使える？

無制限じゃないよ、リポジトリ１つにつき1GBまでだよ

https://help.github.com/articles/what-is-my-disk-quota

>>253のスレを誰か早く立ててほしいところ
俺はこのホストは立てられませんってエラーが出て立てられんし

このスレに限らんが
公式のヘルプに答えが書いてあることを質問してくる奴って結構いるよな
日常生活でも家電とか取説読まずに分からんと憤慨してる奴みかけるし
人間って何なんだろうな

>>342
バックアップ目的ならDropBoxおすすめとか書いてあってワロタ

GitHubは完成したもののコンパイル物配布には向いてないと書いてあるな、Amazonを進めてるのな

>>344
説明書を読むだけの店員さんの仕事を確保するためだろう。

>>344
しかも過去スレに同じ質問と回答があるとかもうね

2chの過去ログ漁るのは、公式手段だと●買わないとダメだし
2chにあんま詳しくないとmimizunなど過去ログ溜めてるサイトとか知らんだろ

>>344 みたいなのが
「近頃の若いもんは・・・」
とか結構言うんだよな
人間って何なんだろうな

git init --separate-git-dir=

これ使ってる香具師いる？

>>349

最近ここは面白スレ化してないか

Googleが2ch過去ログサイトの隅々まで巡回してるのに何を言っとるんだ？

まあ、別に検索サイトや過去ログの使い方知らない訳じゃなくて、それらの手間を他人にかけてるだけだろうがな

リファレンスより使用法やフォーラムの質問のが有用ってのは
MSかなんかが統計付きで出してた
マニュアル読めって言ってる奴は自己満足の役立たず

それはリファレンスとフォーラムの両方を運営してる側が活用するデータで
他人に手間を押し付ける言い訳にしちゃダメだろ

彼は自分にとって有用という点しか見ていないみたいだし、そもそも他人に手間を掛けるとか掛けないとかいう発想がなさそう

１回１００円でマニュアルを調べて回答しますというサービスを立ち上げろよ

>>356
他人に手間かけさせるという意味ではない
質問に答えることがそいつ以外にも有用になるってこと
マニュアル読めってのは何も答えてないのと同じで自己満足

直前のコミットを書き換える場合
なんでみんなrebaseを使うんですか？

git reset --soft HEAD^
ってやったらMore?って聞かれるんですけどここで何を入力したら実行できますか？

>>355
ありがちな質問ならそれは正しい
でも、そのうちそうでない疑問もでてくるから、マニュアル不要とかあり得ん

>>359
なら、お前以外は全員知ってるような当たり前の質問すんな

>>361
cmd.exeではサーカムフレックスと改行で行の継続になる
"HEAD^"とするがよろしいかと

windows だったら、ckw で bashを使うんじゃねーの

>>360
普通はcommit --amend使うだろ

>>360>>366
commit --amendを使うとauthorの時刻が変化しないが、
「rebaseなどでcommitオブジェクトが作り直される状況を除いてはauthorとcommitterで時刻が等しいcommitオブジェクトしか作らない」という俺ルールを守るため、
俺はreset {--soft,}とaddでindex作り直してからコミットやり直す

その俺ルールのためなら、
filter-branchでまとめて書き直せばいいんでは

>>367
commit --ammend --reset-author
で更新されたと思う

＞commit --ammend --reset-author
＞で更新されたと思う

commit --amend --reset-author だごめん

コンフリクトさせないために気をつけることを何個でも良いからおしえて

rebaseできる時はする

ffマージはgitに判断させる

編集するファイル毎に専用ブランチを切る。

master以外ブランチを作らない

なるほど、その３つぐらいですかね
基本的にコンフリクトしたときの対応記事書いてるブログってクソだと思うんですよ
コンフリクトしないことが重要なのに対応の仕方だけ書かれてもねっていつも思います

変更は細かくコミットする
例えば移動コミットと変更コミットが分かれていたらその情報を利用してマージできる場面でも
一気にやってしまうとごちゃごちゃとコンフリクトする場合がある

複数人で開発してれば、どんなに気を付けてても競合する時はするけどな。

masterにあるファイルやフォルダを別フォルダに移動するときって、事前に開発者全員に知らせてから移動用のブランチ切ってやるべきかな

git checkout -fってやっていらないファイルを整理しようと思ってたのに
gitで管理されてないゴミファイルが残ったままになります
なので一度.gtディレクトリ以外を削除してからgit checkout -fってやってるんですが面倒くさいです
こういうときはどうやるんですか？

>>380
git clean

コンフリクトを検出できるようにgit使っているのに。

同一ファイルの同一行に追加されてるとgitはコンフリクトと判断するんだよね。
これがある行の上と下に分けて追加すると、両方を追加と判断できる。
gitがマージ処理をしやすくなるコーディングルールって無いものかな？

やめろ・・・やめろよっ・・・・！
運用でカバーするって・・・甘い考えっ・・・・
道具に使われている事に・・・・まるで気付いてないっ・・・・！！

>>383
どっちの行が先に処理されるべきかなんてgitさんに判断なんて無理だから仕方ない

1stペアレンツの方を先にするとか

>>380バッチ1つ作れば良いだけ

OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/

URL先にウイルスとかは言ってたりしたらおれが訴えられるから張らなかったから
必要な人は>>2以降にテンプレではっといて

>>384
むしろ道具でカバーできたり判断できることはどんどん任せ、
他にやらなければいけないこと、かんがえなければいけないことに人間は注力すべきだろう、
とマジレス

まあ--reset-authorやrebaseなど凝りだすとgitに使われている気分にはなるな

>>388
おつ

VS2012 スレで Visual Studio Tools for Git で質問したのですが
使ってる人が皆無なのか、全くのスルーだったのでこちらに参りました。

テスト的に作ったプロジェクトを GitHub 等に上げることはできましたが
別の環境（真新しい環境）で使うときがよく分かりません。

VS2012を起動させて、「新しいプロジェクト」から作るのではなくて
これから弄ろうとするプロジェクトを既に上がってる GitHub から引いてくるべきと思うのですが
どんな風にやるのでしょうか？

1台で上げ下げする解説サイトはいっぱいあるんですが
2台目以降の構築法が書かれているところが見当たらず・・・ヒントください。。

msysgit入れてgit clone

OSSスレ立った

【ネット】 GitHubに「総当たり」攻撃、安易なパスワードが破られる…セキュリティ対策を強化へ
http://uni.2ch.net/test/read.cgi/newsplus/1385019870/

Git 1.8.4.4
https://code.google.com/p/git-core/downloads/list

1.8.4なんていらんよ。
1.8.5のRCでてるんだから
そっち使う。

大事な資産をわざわざ人柱に提供するなんて

git-guiのUI違和感ある物の一部変更(デフォールトとか註釈とか)
+potに反映してない文字列のうち見えたもの翻訳したった
ttp://www1.axfc.net/u/3095162.zip
更新前と更新後と差分全部入り

>>400
Gitで管理しろよ
https://github.com/git/git/blob/master/git-gui/po/ja.po

理由は知らんが元のpot自体が更新されとらんねん
どうしろというのさw

forkだろ

Git自体のoriginってgithub？kernel.orgかと思ってたわ
git://git.kernel.org/pub/scm/git/git.git

git-scm.com のソースコードは https://github.com/git にリンクされていて
ここはmirrorだと書いてあるな。

>>296-298

Mercurialも使える方に質問です
バージョン管理システムに慣れる場合Gitとどっちが簡単ですか？

>>407
どっちが簡単かだとMercurial

最初はMercurialを使い始めて不便だなと思ってました

gitを使うようになってから、それにはちゃんと理由があるんだということに気づいたよ
↓みるといいよ
https://www.atlassian.com/ja/dvcs/overview/dvcs-options-git-or-mercuria

何か変な改行はいっちゃった

404 - Oops, you found a dead link. | Atlassian

https://www.atlassian.com/ja/dvcs/overview/dvcs-options-git-or-mercurial
ごめんやで

部分変更のみのコミット可能

これ多用してるわ

http://tortoisesvn.net/tsvn_1.8_releasenotes.html#commitparts
http://tortoisesvn.net/docs/nightly/TortoiseSVN_ja/tsvn-dug-commit.html
ファイルの一部だけをコミットする

時には、ファイルに対して行った変更の一部だけをコミットしたくなることがあるでしょう。
例えば、何かを作業をしている途中で緊急の修正をコミットする必要に迫られ、
しかも作業中のファイルに変更を加えなければならなくなった場合などです。

ファイルを右クリックし、 コンテキストメニュー → コミット後に復元 を実行してください。
これでファイルの現状のコピーが作成されます。
それからファイルを TortoiseMerge などを使用して編集し、
コミットしたくない変更点をすべて元に戻してください。
変更を保存した後で、ファイルをコミットします。

コミットが完了すると、ファイルのコピーが自動的に復元され、
コミットされていなかった変更点が元に戻ります。

誤爆？

そういやgitの-pって凄いと思ったわ。
編集中のファイルのうち一部分だけを
コミットできるんだよね。

TortoiseSVNはそれをぱくったの？

git add -pもそうだけど、
履歴を変更できないと効果半減だわ。
その気に慣れば複数のブランチを使って
コミットを綺麗になおせるのがgitの素晴らしさなんだよね。

ブランチ一つ作るのにも切り替えるのにも
慎重にならないといけないものでは
綺麗に修正することも出来んわ。

馬鹿には無理

Git 1.8.5
https://code.google.com/p/git-core/downloads/list

test

git と github の違いについてですが
git のどのパッケージを使うと
github サーバーを自分で立てられるのでしょう？

自鯖ならgithubは忘れて
「gitlab」でググろう

github Enterprise を契約すると、自鯖でたてられるよ

githubはリポジトリホスティングのサービス名である

git prepとかもいいよ
日本人が作った物だよ

420の質問の意味がよくわからないのにおまえらよく答えられるのな
何をしたくて何を知りたいのかさっぱりわからん

GitHubのフィッシングサイトを立てたいって意味か？

>>425は超絶アスペ

みなさん色々なご提案ありがとう

gitの共有リポジトリを自宅サーバーに作りたいんだけど、
相談させてください。

・自分以外に1人、外部からのアクセスを許可したい
・共有リポジトリには、自分と許可した人以外にはアクセス制限をかけたい
・サーバーはWEBサーバーとして外部公開している(HTTPのFWは開いてる)
・SSHは公開鍵認証を使用して、ローカルからのみアクセスしている(ルーターのFWのポート開けてない)
・クライアントは、二人ともWindowsのTortoiseGitを使用している (TortoiseGit使いたい)

なんだけど、どういう方法で構築するのがよいのかなぁ。。。

sshのポート開けたら終わりじゃないの

>>429
目的は自宅サーバにリポジトリを持つことなの？
もし 2 人がアクセスできるプライベートリポジトリさえあればよいのならば、
Bitbucket を使った方がよいのでは？
無料アカウントでもプライベートリポジトリをいくつでも持てるし、ユーザも最大 5 人まで使用できるよ
https://bitbucket.org

宣伝乙

その規模ならVisual Studio Onlineでいいんじゃないの？
どの規模でもいいんだけど、その規模なら無料って意味で。

外部サービスに置くのは怖いんじゃね
こちらに連絡なしに規約が変わったりするかもよ

gmailとか
DropBoxとか
怖くて使えんな

>>434
だからTFSじゃなくGitなんじゃないの？
二人だし規約が変わったらまた考えればいいでしょ。

sshのポートあけて、gitoliteでリポジトリとアクセス制限の管理するのが一番シンプルに構築できると思う

余談だけど
sshでパスワード認証はするなよ

シンプルなのはVisual Studio Onlineだろね。
登録するだけですぐ使えるから。

ステマというか堂々とした宣伝か

429です

自宅鯖を使用したい理由は、自宅鯖にあるRedmineと連携したい、ってのが大きいです。

一点確認なんですが、SSHは公開鍵認証にしてるけど、gitでsshをほかの人が使えるようにすると、
その人もPC自体をSSHで操作可能になる？

>>441
ならない

いや、なるだろ

権限次第としか。

>>429だったら、なってもおかしくはないな。

言葉が足りなかった。gitolite使えばならない
追加するのはgitolite用のアカウントだけ

その点はgit-shellで解決可能かと

Visual Studio Onlineって初めて聞いたけどgitベースなのか？
VSSはもうやめたんかよ。つーかXcodeにも対応してっしMSのくせに柔軟というか節操ないというか

Microsoft Visual Studio：一歩先を行くバージョン管理
http://www.microsoft.com/ja-jp/dev/campaign/vsstotfs/default.aspx

Visual Studio での Git の使用
http://msdn.microsoft.com/ja-jp/library/hh850437.aspx

Visual Studio Online の概要
http://www.visualstudio.com/ja-jp/products/visual-studio-online-overview-vs.aspx
>Visual Studio Online (旧 Team Foundation Service) は、クラウド内のプロジェクト データのホームです。
Visual Studio Online Basic
> 5 ユーザーまで無料です

Visual Studio Online Basic
http://www.visualstudio.com/ja-jp/products/visual-studio-online-basic-vs
>主な機能
> ?プライベートな Git リポジトリを使用してコードをクラウドに保存する

VSS光景のTeam Foundationは当然として
オープン規格でGitだけサポートってのは何故だろう、って気はする
あの会社ならSVNやHgまで同時にやれそうだし
Windows環境へのサポートは他のが良いくらいなんだが…
まあ、とはいえ選択肢があるのは良いことか

VCSスレのほうでGitはWindowsに不向きとか散々書かれてたしね

やっぱタイムスタンプも同期してくれないとWindowsでは使えんわ

えっ？

タイムスタンプ厨が出たぞー逃げろー

どうせどっかの会社ごと買ったんだろ。すぐにダメになる。

>>454
>>310

>>452
最高の分散型VCSを作ってやるぜ！
↓
検討すればするほど、gitに近付いてしまう・・・。
そうか、最高の分散型VCSは既に存在したんだ。
それはgitだ。
よって、gitをサポートすることが最善。

って経緯らしいよ。
元々、様々なVCSをサポートすることは目的じゃない。
（そういう選択肢はプラグインインターフェイスだけ用意して、実装はサードパーティ任せ。）

オプションでタイムスタンプ同期に対応したら完璧なのに
クライアントの当てにならない時計なんて信用できるか、ってやつは使わなければいいだけだし

ぐちぐち言ってないでプログラマなら自分でやれ

DropBoxがソースフリーで公開してくれたら解決だな
バイナリ差分の転送も上手にやってるし

>>310
5スレ目の75あたりって1年前なんですが、１年前から変わってないってことなんすか

いや
>>310 はタマタマ見つかったのを例に挙げただけで
もっと前から概出

既出かどうか、というより、gitはタイムスタンプに関する仕様を変更する気はさらさら無いってことでつね

仕様変わっても困らないんじゃね

そんなにタイムスタンプ同期したいなら自分でhook書けよ、と
makeがタイムスタンプ見るから勝手に変えられると俺は困る

MsBuildもタイムスタンプを見るから勝手に変えられると俺も困る
VisualStudioはMsBuildでビルドしてるので、全世界のVisualStudioユーザーも困る

困らせたいんだろ。

昔はファイルのタイムスタンプをチェックしてたけど、Git でソースプログラムを管理するようになってからはタイムスタンプを意識しなくなった

contrib/diff-highlight ってバイト単位で比較しているから日本語が化けるね
勘で書いた patch ↓
pastebin.com/gHhShciR

utf-8 決め打ちとかいまいちなので、perl 分かる人いい感じにしてください

Git 1.8.5.1 が出てたんだね（1.8.4.5 も）
https://code.google.com/p/git-core/downloads/list

タイムスタンプ対応まだ？

一生ないから自分でforkして自分で作っとけ

Gitでの管理って
リリースの際はリリース用のブランチを切るの？それともタグ付けだけいい？

>>475
そこのポリシーに従ってください。

ちなみに俺はリリース前から、開発版と安定版のブランチを使う。安定版へのマージがリリースになる。あ、でも最初のリリースまでは一本ってことだな。

その場合masterブランチはどうなってるの？

>>477
どっちだっけ。あんま気にしてない。何か違いあるの?

よく分からなくなってきた

Gitにおけるリリースブランチのつかいかた
http://www.eiplab.com/2011/06/git-release-branch/

トピックブランチと統合ブランチでの運用例
http://www.backlog.jp/git-guide/stepup/stepup1_5.html

リモートとワークツリー比較してリモートの方が最新だったらpullしてワークツリーの方が最新だったらcommit+pushみたく自動化することは出来ますか？

>>477
masterはcloneした時にとくべ扱いされるから、気にした方が良いと最近思った

>>475
Github にある Git 自身のリポジトリ（ミラー）を見ると
ブランチではなくてタグで対応してるみたいだけど。
https://github.com/git/git

>>480-481を読めば全て解決

masterブランチへのマージはリリースブランチが完成したものだけを常にマージ

リリースブランチは開発ブランチでほぼ完成であとは調整のみという段階からリリースブランチを切る

開発ブランチでは作業しない、開発ブランチからメンバーが個々に作業用ブランチを切ってそこで作業・コミットして出来上がったら開発ブランチへマージする

>>476-486
ありがとうございます勉強になりました
色んな流儀があるんですね

色んな？

皆本質は一緒だろ

つまり本質以外は違うってことですね？
あなたの言う、本質ってのはなんですか？

それぞれ別のものに見えるとしたら病院逝った方が良い

既に病院にかかってる人から言われてもな

ω

どっちでもいいだろo

>>482
？

ローカルにコミットしたもの と リモートのリポジトリ との差分を
みたいんですが、どうしたらよいでしょうか

>>495
とりあえず git branch -av とかやってみろ

Git 1.8.5.2
https://code.google.com/p/git-core/downloads/list

>>496
ありがとう

git clone ssh://[email protected]/var/lib/git/UNKO.git
とかなんとかやりますが、
この ssh://[email protected]/var/lib/git/ の部分を
設定ファイルとかに書いたりとか出来たりとかします？

>>499
[email protected]の部分はssh側の設定でaliasを付けられる

>>500
ありがとう

これgitなんかに使うのもったいないレベルのTipsやん
ほーすげぇなこれ はー

こんな感じだろ常識の範囲ではないか
Host g
Hostname github.com
User xyz
IdentityFile ~/.ssh/github

ssh_config(5) 見ておくと色々幸せになるということだな。

昔々rshというものがあってな

結局、日本語のファイル名は使えるの？

使えるよ

checkoutってあいまいだよな
git checkout branch名　はbranch切り替えだけど
git checkout file名　はローカルファイル更新なんだよな

へ？ どれもリポジトリからファイルを
チェックアウトするコマンドじゃん。

ブランチ指定したら、そのブランチのファイル全部をチェックアウトするし
ブランチとファイル名指定したら、そのブランチの特定のファイル名をチェックアウトするし
ファイル名だけだったら、カレントブランチのファイルをチェックアウトする。

全部チェックアウトじゃんか

ブランチ名とファイル名が同一のものあったら

--

普通ファイル名には拡張子つけるから
かぶることはまずないけどな。
心配な人は--をつけるようにすればいいだろう。

git checkout branch名
の場合は
ファイルの取り出しだけでなくて
カレントブランチの切り替えも行うのだから
ぜんぶ同じってことはないと思うけど

readme.mdはどのタイミングで入れるべきか教えてください

１．git initをしたあと
２．git initをするまえ
３．そのた

好きな時でいいだろ

readme.mdをaddする前

敢えてinitial commitには入れないことにしてるな。その次で入れる。
readmeは何度も書き直したくなるが、initial commitだとrebaseで手出しできない。

initial commitには何を入れるわけ？

.gitignore

何も入れずに --allow-empty

ああ、git便利すぎて幸せ。
gitに弱点ってある？

同じファイルをコミットしたらコンフリクトすること
ロックできないのが弱点

ロックという考えがもう前時代的だよね

コンフリクトをエラーのように言ってる人がけっこういる。

複数人で修正してコミットしたらコンフリクトするのだから
ロックできれば未然に防げるはずなのだ
コンフリクトを起こさないのが良いバージョン管理方法である

分散管理でロックとか不可能だろ
誰かがロックしたら全員のリポジトリのファイルにロックがかかるのかよ

いまからさGit Wikiつくろうとおもうんだけど逆引きで
そしたらテンプレに入れてくれますか？アフィ張らないので

ちなみに初心者ですけど間違っているのをここの先輩方に直してもらうためにWikiを作るのです！

サルでもわかるGit入門
http://www.backlog.jp/git-guide/

>>524
コンフリクトしてから考えればいいじゃん。
ロックされててコミットできないとか困る。

git diff
って、
git diff A B
という A、B が省略されているものだと思うんだけど
A、B が何なのかわからないので、知ってたら教えて。

>>530
AはHEADまたはindexで、Bがワーキングコピー。

git add .　ってやるとindexに保存されますけど
git commit する前にまたファイルを編集してgit add .をしたらindexを上書きしているって事であってますか？
つまり

git add.
git add.
git commit

ってやってます

>>524
コンフリクトが発生したら直せばいいだけじゃん。
バージョン管理ってそういうものですよ。

コンフリクトの修正がいやなら自分のした修正を無かったことにすればいい。
ファイルをロックされるというのはそう言うこと

コンフリクトはしたらいけないんですよ！

コンフリクトはバグみたいなもんだからな。
発生したら「あれ？ 俺やらかしちゃった？」って思わないといけない。

自分のとこを最新のにマージしてからプッシュしとらんのか

最新のにマージする時にコンフリクトが起きたらどうするんだよ！

解決しろよ
どうせどっち取るか選ばなきゃならんのだから

>>537
それ何か問題あるの？

コンフリクト起きる度にgitありがとうと思っている俺に隙は無かった

コンフリクトって何だ。コンフリクトを知りたい。by梅原

ってのは冗談で、実際にプロジェクトでgit使ってるんだがコンフリクトは一回も起こってないね。同一ファイルを同時に弄った場合でも、gitがキレイに判断してくれるおかげで助かってる。

そりゃ、同一行をいじったりしたら怒られるのは目に見えてるから、チーム間でコミュニケーションしながらだけど。

同一行をいじらないためのコミュニケーションってイヤだな

コミュニケーション不足

ソースファイルは小さく小分けする方がいいだろ
複数人で１つのソースファイルを編集する必要がある大きさなんて、
俺やってるプロジェクトでは考えられない

開発版とバグフィックスをマージしてコンフリクトとかあるだろ。

複雑さと変更箇所のばらつきは極端に偏る

コンフリクトをよく起こすファイルがある場合、設計ミスを疑うべきだな、何でそのファイルばかり修正が集中するのか

>>547
頻繁に開発が行われているモジュールなら、変更もバグフィックスも多いだろうから必然だろう。

>>548
コンフリクトがどういうときに起きるか理解してないだろ

安価するとこ間違ってるぞ

>>549
おまえがな

コンフリクトがいやならSVNみたいな集中型でlockしたほうが幸せだぞ

コンフリクトの修正手間が自分に係るのが嫌なんだろう？

コンフリクトしたら、ロックされていたつもりになって
ローカルの変更を捨てればいいだけ

コンフリクトで見つかるトラブルはまだありがたい。
相互に離れた場所で副作用でバグると見つけづらいし、片方直すと別の場所でバグる

revert

>>555
自動テストが必要だな。

「ロックを"強制"して無駄なコンフリクトをなくす」というワークフローが構築できないから

やっぱ svn でいいじゃん

ロックを強制する方が無駄が多いんだけどな

素人開発にロックは厳禁。
みんなダメもとで開発して上手く行ったのを採用するんだからロックなんてできない。
まったくもって無駄。

他人がロック中に作り貯めたやつをマージせずcommitする奴が出てくるんだよな
commitしようとしたらできなかったので、別の場所にコピーしておきましたとか
言われる。

上がそう指示するのも当たり前に見かけるという

そろそろ「バージョン管理システムについて語るスレ」に移らないか？

そもそもツールの機能に頼るからいけないんだよ
バージョン管理の番人を1人つけるだけでトラブルがびっくりするほど無くなるよ

仕様書マイスターが1人いれば効率あがるのは知ってると思うけど
バージョン管理も同じ。余裕があるプロジェクトじゃないと無理だとは思うけどな

このスレではGitと密着した話題だけしたいという人がVCS全般の話題はあっちのスレでと切に願っているわけだ

バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/

>>564
24時間不眠不休なのですね。

>>564
実際それが有用だから、Gitでpull request方式が流行ってるわけだな

無責任なパッチを気軽に投げられるからな

Gitくるぅ〜Gitくるぅ〜季節はしろくぅ〜

>>567
流行るもなにも、GitはLinux kernel用に作られたものだから、元々そういう
ワークフローが前提

そんな前提は無い

マメインラインにマージするには責任者（管理者）を通す運用が当たり前だよなあ
それができない会社は無能

豆インライン？

>>571
いやあるだろ
あの変態が作ったんだぜ？

変態でごめん。

お、おう

変態？ 俺のことか？

>>531
ありがとう
ワーキングコピーを明示的に書くとしたら
なんて書けばいいの？

手元のレポジトリを リモートにベアリポジトリとして置きたいのだけど
どうしたらよいでしょうか

git clone --bare ./sample ssh://[email protected]:/var/lig/git/sample.git

とやってもローカルに ssh: とかいうディレクトリが出来て絶望した

>>578
.

>>579
リモート側で空のベアリポジトリを作ってそこにpushする

>>581
それしかないの？
いちいちリモートにログインするのっていやなんだよな・・・

>>582
ssh使ってるならログインしなくたってできるだろ

間違えてた

git remote add origin ssh://[email protected]/var/lib/git/sample.git
git push
ってやればいいのか。

>>584
それで何をするつもりだ？

>>585
手元のレポジトリを リモートにベアリポジトリとして置きます。



これからリポジトリを作るのになぜかリポジトリがないと言われるのは
なんだろうgitさんってあんまり賢くないのかな

>>586
>>584はリモートリポジトリにoriginっていう別名をつけるだけだアホ
お前がアホなんだよハゲ

コンフリクトなんてするべきじゃない
ロックもできないとかクソすぎる
今後はGitのこういう欠点を修正した新しいバージョン管理が登場してGitなんて使われなくなるよ
そうSVNみたいな過去のものになるだけ

testブランチにいます
ファイルを更新しましたが一時的にmasterブランチに移動したいのです
このとき
１．git add をしないでmasterブランチに戻ったらtestブランチで更新したファイルはどうなるか？
２．git add をしてgit commitしないでmasterブランチに戻ったらtestブランチで更新したファイルはどうなるか？

それぞれ教えてください

>>589
Gitのリポジトリなんか簡単につくれるんだから
試しにやってみようかと思わないの？

>>588
コンフリクトを撲滅したいなら、ロックをサポートするだけじゃなくて
ブランチのマージをできないようにしないとダメだよ
どっちも導入すると随分不自由な仕組みになるな

>>590
怖くて手が震えてできませんっ！
OSが壊れたらどうしようと思って

つまんね
-35894点

>>592
まず、アル中の治療から始めましょうか

>>587
なるほど。 リモートに置くにはどうしたらいいかな。
おしえてフサフサな人

リモートにリポジトリを作る方法は、リモート側のシステムに依存する

なんパターン化あるなら、
その代表例を言えばいいよ。
1つでもいいんだぜ？

git addしたあとにまたファイルを更新したんですがこの場合はどうしたらいいんですか？
そのままgit addを取り消すのか？git addをそのままうっちゃっていいのか？

>>597
リモート側でGitoliteを使ってるなら、
gitolite-adminリポジトリのgitolite.confを編集してpushすれば新しいリモートリポジトリが作成される
そこにローカルリポジトリをpushする

>>598
git addを追加で行えばいい

GitのGUIは分岐も表示できるじゃないですか
あれをぼくも作りたいんですけど、ああいうログってgit logの出力をパースしてるだけなんでしょうか？

>>599
ありがとう
gitコマンドだけではやはり無理ってことですか
世の中うまくいかないもんですな

そもそもUNIXのコマンドは単品に機能を過剰に詰め込んだりしない
gitコマンドも同じようなポリシーで作られてる
ネットワーク関係の機能も自身が持たずにsshコマンドとかに多くを依存してる
ローカルにリポジトリを作る機能さえあればsshと組み合わせてリモートにリポジトリを作るのも簡単にできる
それによってネットワークに関わるセキュリティ的な部分をgit自身が抱え込まずにsshに任せられる
これで世の中うまくいっている

>>601
パースしてもいいし、gitのファイル構造は簡単だから自分で読んでグラフデータ構造を構築してもいい
分岐の表示はgit log --graphとかでCUIでもできる

>>603
車輪の再発明的なことを避けたってこと？

UNIXの考え方はこれでいいや。
http://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6

でかくすると保守しにくいからね。

>>605
単機能のプログラムとプログラムを繋ぐ仕組み (パイプとかシェルとか) を提供して、プログラムを組み合わせることで目的を達成するようにした。
利用者にそれなりのスキルがあることが前提になる。
あと、GUI だと繋ぐ仕組みがうまく機能してないので、GUI 上のアプリは Windows とたいして変わらない。

GUIのアプリといっても中でCUIのコマンドを組み合わせて動いてるのも多いけどな

来年こそはタイムスタンプに対応してくらさい

永遠に対応しないことが決定してる

>>602
なんか難しく考えてるみたいだが、リモートが普通のUNIXなら
ローカルでつくったベアリポジトリをリモートにコピーすればいいだけやで

>>611
sshでログインしたくなかったけど
gitサーバも立てたくないワガママが
ことの発端なので、あきらめました

×わがまま
○怠惰

>>612
ログインしなくてもscpでコピーすればいいし、
アクセスするのはsshd経由だからgitサーバはいらんよ？
ほんと何もわかってないのにに口だけ達者だな

とにかくWindowsで色つきのやつおしえて
コマンドプロンプトは色が着かない

cygwinでminttyをつかう

一応cmdでも色つくよ。
cygwinいれてexeある場所にパス通すと
lsとかのexeがつかえるのだが、
ls --colorとか打ち込むと色分けされる。

ぶっちゃけメンテとか詰めとが実用的なレベルにすらならない低さで甘いだけ。
一応機能的には色分けできる。

>>614
scpでコピペって、sshでログインするのとどれだけ違いがあるのよ
だいたい相手のファイル構成知らなきゃならない時点でダメだろ

コピペｗ
別にどこに置いてもいいんだから自分のホームディレクトリにコピーしろよ
書き込み権限無いとこに置きたいならリポジトリ管理ツール用意してもらえ

そいつはたぶんUnixとか使ったこと無いからまともに相手にしても無駄だぞ

>>620
つまらないレッテル貼りはやめなよ

GitHub for Windows のコマンドラインシェルって
プロンプトにブランチ名が色つきで表示されてた。
あのプロンプトだけは素敵だな。
それ以外は使いづらいシェルだったが。

>>621
レッテル貼りの定義はよ

修正すれど修正すれど、わが暮らし楽にならざり
Git手を見る

くだらん自尊心ばっかりだ

１．masterブランチでファイルを更新しました
２．addとかcommitとか何もしないでgit checkout -b testでtestブランチに移動しました

この場合masterブランチで更新した内容は消えてしまいますか？

git checkout -b <branch>なら消えない
既存のほかのブランチに(-bなしで)移動するなら、
消えない(git管理下でないファイルの場合)か、またはエラーになって移動できない(git管理下のファイルの場合)

ってことはtestブランチでadd してcommitしてからmasterブランチに移動したら
１の時点のファイルの内容は復活するということですか？

もう、本気で本読むとか入門サイト読んでくるとかした方がいい
何この初歩的な質問、ありえないんだけど・・・

馬鹿には無理

>>626とか>>628みたいな疑問が最初出てくるのはしょうが無いし、
本読むだけじゃなんかよくわからないだろうから、自分でリポジトリ作って試せ
git statusやgit diffで状況を確認しつついろいろやってみろ
ローカルで簡単にリポジトリ作ったり消したりできるgitの利点だ

>>629
上級者専用スレを立ててください。お願いします。

これ一通り読む気が無い人が質問してるん？
読んで分からなかったら分からなかった箇所を訊いてこいよ

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

公式なんて何の役にも立たんよ
gitなんてローカルで何の変更もしてないのに
pull繰り返すだけでコンフリしょっちゅうだし
なのにそのときどうするかなんてことは書いてない
ここの前スレだか前々スレにたどり着いてようやく解決した

つまり公式は2ch未満の肥溜め

そうだな
Junioをさっさとクビにして2chの有志がGit開発しないと

>>634
んー、状況がわからんけどブランチ切らずに修正してるのか？
gitでの修正/開発はブランチでやるのが基本だと思うのだけど。
あと、マージもあまりしない方がいいってのもある。

あと、公式のマニュアルは、そこいらの入門書買うよりおすすめできる内容だと思うけどね

あー、失礼。
コミットした人がFFしてないのか。
しょっちゅうやらかすようなら、説教ですね。

>>632
>>628の答えが分かる人が「上級者」だとでも思ってるの？
「コミットってどうするのですか？」ってレベルの質問だぞ
何でもかんでも質問するんじゃなくて、最低限は学んで来いよ

答える気がないなら黙ってろよ役立たず

馬鹿には無理

>>636
あのさ
修正も何もないんだよ
手元で何もしてないのにpull繰り返すだけでコンフリ起こすから糞だと言ってる
FFしてないわけでもない
そもそもFFでないと禁止されてて蹴られる

これはgit本体ではないと思うがpushしたら鯖側で不具合あって
手元では送れたことになってるのに鯖側では変更されてないなんてこともあったな
そんな具合であまりに不具合が多すぎる

だがしかし公式なんかにはその時どうする必要があるのかなんて書いてない
検索も実質不可能なんだな

そんなわけで作業は全てツリー外でやるようになりましたとさ

>>641
そんなバカな

「何もしていないのにパソコンが壊れた」と言ってるヤツと同じタイプか

そんなバカなことが現実に起きるのがgit
一方svnなら途中でトラブったら戻してくれる

634の時唯一参考になったのがこれ
バッチで処理できる体制は既にこさえてあるが
メモに残していつでもすぐ見られるようにはしてある

http://toro.2ch.net/test/read.cgi/tech/1310403238/499+501
git pullを試みたところ、
error: Your local changes to the following files would be overwritten by merge:
と言われました。しかし、今現在worktreeにある変更はどうでもいい些細なものなので、worktreeにある変更を
破棄して、とにかくpullしたいです。どうすればいいですか？

競合のあるbranch上で git reset --hard origin/upstream_worktree

>>641
それコンフリクトじゃないだろ
rebaseとかしてて公開していない本来pull元にすべきじゃないブランチを
おまえがpull元に指定しちゃってるだけだろ

>>646
おまえ手元で何もしてないと言ってるのに、
その>>646の手元で行った修正を無効にして強引にpullする方法が有効だった意味が理解できてる？
何も理解せずに対処療法でとりあえずうまくいったから得意満面かよｗ
本が役に立たないとか言ってるが、Junioの本をよく読めば何が起こってるのか理解できるぞ

>>642
gitは手元で送れたかどうかなんて情報は保存してないので
もう一度pushすればいいだけ
確実にpushできたかどうかはfetchして確かめろ

もしそんな不具合てんこ盛りだったらLinuxカーネルの開発には使えんわな

だーかーらー、公式が理解できない糞だから言ってるんだろうが！！！！
Junioとやらはてめえが作ってるソフトのこともろくに説明できない糞なんだよ
このスレの連中の方がJunioとやらよりよっぽどGit理解しててわかりやすく説明してくれてる
このスレがあれば糞みたいな本もGit公式とかも不要

ワラタｗｗｗｗｗｗｗｗｗ

純ちゃんの本買ってやれよｗ
ここのスレでいろいろ説明したりしてるば、最初はこの本で勉強したぞｗ

gitは動作原理が単純で中で何をやってるか理解しやすいから
原理を理解しちまえば大抵の問題は自分で対処できるんだよね
上っ面だけ理解しようとすると大変で>>651みたいに顔真っ赤になる

何故か必死な奴が何人も湧いてるけどさ
647とか648とか完全に的外れなんだよね
扱ってるのは当然許可されてる開発用の公開ブランチだし他のブランチなんか触ることはない
pull繰り返すだけで634の状況になるから646だし

651は俺じゃねえよ

>>655
改変が行われていない公開ブランチをpullしてるだけで
git reset --hard origin/upstream_worktreeが必要になるとしたら、
明らかに環境が壊れてる
gitコマンドがOSのファイルシステムを正常にアクセスできてない
どういう環境で使えばそんな馬鹿なことになるんだ？
git reset --hardでとりあえず凌いでもワークツリーの状態が
正常である保障は何もないぞ
そんな環境を使うのをやめろ

王様のブランチ

>>655
「当然許可されてる開発用の公開ブランチ」であってもrebaseされていない保障は無いぞ？
そのブランチがrebaseされていないことを確認した？
GCされてなければ今からでもreflog使えば確認できるぞ？
Junioの本をちゃんと読めばこの辺のことも理解できる

FFじゃないってgitが検出してるならそれは正常な動作だな
上流のブランチ管理してる奴が馬鹿なだけだ

>>656
普通のM$謹製vistaだからな
あいにくpcの9割はこちらの流れなんだよね
>>658
rebaseされていない保障は無いとか言われてもねえ
ローカルで何も変更してないのにまともに同期できない時点でまともじゃねえわ
646見つけるまで何度かcloneし直したわ

Junioの本だかなんだかしらねえけどさ
こちとら仕方なく使う羽目になってるだけでgitなんかには興味ねえのよ

japan.blogs.atlassian.com/2013/11/git-team-workflows-merge-or-rebase/
そのリポジトリがマージを一切せずにリベースだけでいくと決めてるならそれはそれでアリ。そのプロジェクトの方針ぐらいは尊重してやれ。
pullに--ff-onlyでも付けとけ。

windows用の単純なgit.exeって配布されて無いの？
インストーラーとかcygwinとかはできれば避けたいんだけど

gitの中身は半分bashスクリプトとpythonなんで、シェル環境ごと持ってこないと�_

プロジェクトの方針とか関係無く、公開してるブランチのコミットを改変するとか普通は有り得ないよ
リベースだけで運用するとしても、公開ブランチにリベース済みのコミットをpushすることになるだけで、
公開したコミットを改変することは普通しない

でも管理上どうしても改変したいときもあるから、それをgitは許してる
うちとか止むを得ずそれやるときはpullしてるみんなに平謝りして回る
頻繁に公開ブランチ改変してるとしたら管理が糞すぎる

ウチはこうしてる(から他のプロジェクトもこうするべきだ)なんてのはgit以前に傲慢過ぎやしないか

>>665
公開ブランチの改変のことを言ってるの？
公開ブランチのコミットを改変することの意味を理解してる？

メリットデメリットは>>661のリンク先でも論じられてるだろ
わかってやってるなら問題ない、そういうことだ

機能ブランチではrebaseしまくってmasterへはcherry-pickのみでもいいというかそっちが普通だろうけど

わかってなくてやってるから馬鹿が騒いでるんだろｗ
わかってるならpullしてる馬鹿全員にちゃんと説明して回れｗ

上の奴は、pullしてるだけのプロジェクト外の人間じゃないのか？w

>>660
cloneの必要ないだろｗ
resetだって必要無いｗ
ローカルなブランチ消して作りなせばいいだけじゃないかｗ

>>660
ローカルで変更してないわけない。
コミットしてないだけで何かしらの変更をワークツリーに加えてるから>>646で解決出来る状態になる。
おそらくコンパイルとかで生成されるファイルも管理対象にしちゃっていて、ローカルでコンパイルしたからコンフリクトしたとかじゃないの？

>>667
いやなんか勘違いしてるぞ
rebaseチームポリシーでも公開してるブランチの履歴をリベースして改変しちゃダメだ
公開ブランチへのpushはつねにFFで行う。
pushの前に非公開ブランチでリベースはすましておく。
当然ながら非公開ブランチで行うリベースは公開ブランチのコミットを巻き込んではいけない。
(公開ブランチへのpushがFFでなくなるから)

まあ公開してた機能ブランチをリベースしてマスターにpushするとかもありだと思うけどね
その時点で機能ブランチはクローズすべきだよ
もしくは機能ブランチはそのまま残して、機能ブランチから作った非公開ブランチ上でリベースしてpushするとか
公開したブランチを改変してそのまま履歴をさらに伸ばすとか絶対良いことないからやめとけ

公開ブランチをrebaseするのと
rebaseしたコミットを公開ブランチにFFでpushするのを区別できてない奴がいるのか

ちなみに、一体どんな差分がコンフリクトするの？
pullしたときの、状況の方が気になるな。

>>673
masterとの差が離れてきたとかここらで一旦履歴を可読にしたいとかで
rebaseしてmasterと足並みを揃えてから機能ブランチは継続もアリと思うけどね

>>676
自分だけがその機能ブランチを使うならそれでいいと思うよ
その機能ブランチを公開してるならブランチを変えた方がいい

お正月から賑やかだなｗおまえらｗ

>>671
たぶん上流が履歴を改変してる
origin/upstream_worktreeへのfetchはデフォルトの+つきで行われるから自動的に上書きされるけど、
それでorigin/upstream_worktreeとローカルのupstream_worktreeのFF状態が崩れるから、
非FFなマージが走ることになって失敗するんじゃないかな
本来pullしてるだけなら非FFマージは走らないからコンフリクトとか有り得ないからね

ところで、上流がpush -fされた時のメッセージはforced updateなんちゃらであって
>>646のYour local changes to the following files would be overwritten by mergeってのは出ない気がする
手元で確認して確かめた

なのでやっぱり、手元で何かしちゃってるはず

>>680
そう思うだろうけどしてないんだよね
つーか上と下関係なくね?
覚えてないけどYour local changes云々は違うかもしれんよ
そのログは参考にした対処だからね

何か月も過ぎてるから良く覚えてないけどgitと破棄で検索して見つけたのかなあ

周知もせず履歴の改変を行う管理者と
適当に検索してその場しのぎの対処で誤魔化すプログラマとか最悪だな

上から権限をスター的な構成にしたいけど難しいよな

>>683
Gitoliteとか使うんじゃダメなのか？

>>681
関係あるだろ、だってYour local〜ってのは将に手元で変更してたときのメッセージだもの

>>638
うるせーはげ

>>671
> おそらくコンパイルとかで生成されるファイルも管理対象にしちゃっていて、ローカルでコンパイルしたからコンフリクトしたとかじゃないの？

AndroidのカスROM作ろうとしてAPIにメソッド追加したりすると、ビルド生成物の一部が管理対象に含まれてるんで、こうなる。
API変更しておいて生成物の更新を忘れてたままpushすると顰蹙もの。

git reset --hard HEAD

Githubって無料じゃプライベートリポジトリ作れないの？
なんか使えねーな。
個数制限３つとかできりゃいいのに。

BitBucketの存在も知らずに「Githubって使えねえゴミ」とか罵倒する奴にGitを使ってほしくない

>>689
bitbucketとかでやればいいんじゃね

>>690-691
情報ご苦労
使えねえGithubはbitbucketに潰されろ

↓機能してるスレかは分からんが、Gitで無料でプライベートリポジトリ作れるとこ教えてくれるかもしれんぞ

OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/

>>692
わざわざ煽りご苦労。

プライベートリポジトリって秘密にしたいもの置くんだろ
無料のサービスを信用するって頭沸いてるとしか思えない

誰も信用するとは書いていないが

そこに秘密のファイル置くんだろ

無料を信用するより、信用してないとこに秘密のファイル置く方が、よりヒドイと思うんだがw

自分でGit鯖立てればいいじゃん
GitLabでもGitoliteでも好きなの選べ

アホかこいつ

プライベートでなけりゃ、無くなる心配だけすればいいけど
プライベートだと、それに加えて盗まれる心配もしなきゃならない

Github「お前のものは俺のもの」

「アトリエのどか式 Git入門」
ttp://www.atelier-nodoka.net/2013/12/c85-information/

この本ってお勧めですか？

>>703
表紙が気に入ったら買えばいいのでは？
内容はネットで読めるみたいだし。

>>702
金も払わずにプライベートリポジトリが使えて当然とか、乞食かよ

Evernote, Dropbox 「ウェルカム乞食」

>>706
EvernoteとDropboxは無料で体験してもらって有料プランに引き込むビジネスモデルだから全く話が違う。
GitHubは、まず根底に「全てのソフトウェアは自由であるべき」っていうフリーソフトウェア運動の理念があって、
フリーソフトウェアの要件のひとつである「オープンソース化」を促進するのがそもそもの存在意義なんだな。
でもそれだけじゃサービスを維持できないから、金をとってクローズドソースでのリポジトリホスティングもやってるわけ。
有料と無料の違いはプライベートにできるかどうかだけなんで、機能とかを体験するならオープンのリポジトリでやってもらえばよくて、
無料でプライベートリポジトリを提供する理由がない。文句あるなら金払うかオープンソースでどうぞって話。

自由であるべき理想、というより、お前の自由は俺に金を払わなきゃ与えない、ってことだよな。

>>708
なんで自分のことしか考えない(=金を払わない&ソースも公開しない)人間に無銭の宿(リポジトリ)を提供しなきゃならんのさ。
世の中ギブ&テイク。リポジトリを使わせてくれというのなら対価は必要だ。
GitHubの場合はそれが単なる金か、あるいは世の中への貢献(=ソースコードの公開)ということさ。
金も払わない、世の中への貢献もしない、でもリポジトリは使わせろってそっちの方が無茶苦茶言ってるぞ?

「使えねえ」なら見かけたが「使わせろ」とは誰も書いてない

>>710
?
有料でしかプライベートリポジトリ使えないのかよ、使えねぇな=無料でプライベートリポジトリ使わせろ
ってことでしょ?

>>711
使えねえから使わない。だろ
おまえホント使えなさそうだな

正確に言うと、

無料で使えないから、使わない

という話。

別にgithubの機能が劣っているわけじゃない。
むしろ優れている。

だが金かかるので使わない。

使えねえのは貧乏な俺だったというオチ

gitに無料のお試しプライベートリポジトリサービスがあればいいのに、って書いただけで
どうしてそこまで発狂できるのかふしぎ

>>715
おまえが最初に煽ったからだろ
> Githubって無料じゃプライベートリポジトリ作れないの？
> なんか使えねーな。

Githubって無料じゃプライベートリポジトリ作れないの？
なんか金払えない俺には使えねーな。

つまり、使えねえのは貧乏な俺だったというオチ

>>706
Google大先生も入れてあげて

Gitはスナップショットだから、無駄に大量にコミットしまくるとゴミデータが溜まりまくる・・・

ブランチの切り替えは大量のファイル移動があってHDD負荷が

>>720
過去のコミットは圧縮がかかるので、
差分を保持してるのとほとんど代わらない程度のディスクスペースしか消費しない

>>721
かなり大規模なプロジェクトでも、
問題になるほど大量のファイル書き換えが起こることはマレだよ

OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/
git関係ないんだから、こっちでやれよ

BitBucket使えばいいじゃん

723までで流れが元に戻ってんのに蒸し返す馬鹿なんなの

燕返し！

> 公開リポジトリにプッシュしたコミットをリベースしてはいけない
> この指針に従っている限り、すべてはうまく進みます。もしこれを守らなければ、あなたは嫌われ者となり、友人や家族からも軽蔑されることになるでしょう。

友人や家族からも軽蔑されるのかよ！

リベース、つまり今までプッシュしてないブランチにマージしたい先のブランチの最新状態を取り込むってことやな

>>728
公開したコミットをリベースする奴なんてもううちの子じゃないよ

お前の子だった覚えがないわ>>730

J( 'ｰ`)し＜ごめんね。おかあさんはじめてpull失敗して散々だったから、ごめんね

リモートブランチに含まれているコミットをrebaseしようとしたら警告が出るとか無いのか

使ったこと無いの？普通はpushできない設定になってる
リモート側で直接リベースすることはできるけど、
普通は公開してるリポジトリのブランチを直接操作しない

>>734
誤読だ
rebase段階での警告が無いと不便と思うだろう？

pushの段階のエラーで十分だわ
Gitの仕組み的にそれをチェックしようとすると実装も使い勝手も面倒なことになる

使ったこと無いのはどっちなんだ
紐付いてるupstreamと比べるだけだろ

Git使ったことないんだけど、自分だけがバージョン管理に使いたい場合、
SourceTreeとかインストールすればローカルのリポジトリって作れるの？

作りたいディレクトリの場所で
git init
と打つだけで準備はOK。
git add somefile
でステージングエリアに、
git commit
でコミット可能。　等といった要領でローカルリポジトリ作れる。

githubのプライベートリポジトリの話ではないだろうか

まさかね
ははは、かんがえすぎだよね

>>739
サンクス
やってみる

その場にリポジトリができるのは便利ではあるんだけど
バックアップ的な意味では不安なんだよな…

>>737
リベースするときに上流のリポジトリにアクセスするとかありえんわ
ローカルのremotes/originはpushした上流の情報をつねに保持してるわけじゃないからな

>>743
どーせpushまでに間が空くんだからそこまでやらんでいい
既にfetchしてる分だけで単純ミス避けには充分

>>742
バックアップとる分には不安はないのだけれど、戻し方がどうすればいいか悩むんだよね。

/直下に、.git作れば複数のサーバで同じ設定維持するの楽かも！
と、考えた時期もありましたorz

>>742
pushがバックアップでは。

>>745
設定共有目的ではないがetckeeperとかあるぞ

git diff で、すでに消したファイルが
空のファイルとみなして差分表示されるんだけど
cvsみたいに ファイルが増えた/減った だけ表示できない？

>>748

--diff-filter=AD とか --summary とか?

なんだよSourceTreeってXP じゃ動かねえじゃんかよ
激おこぷんぷんだわもう

>>748
たぶん git diff -D

84 デフォルトの名無しさん [sage] 2014/01/09(木) 07:03:24.99 ID: Be:
Github が落ちて世界中のプログラマが発狂してるｗ

85 デフォルトの名無しさん [sage] 2014/01/09(木) 09:12:51.50 ID: Be:
Github のトラブル発生から完全に回復するまで約 2 時間 30 分かかった。

Github Status

Today
23:59 UTCAll systems reporting at 100%

Yesterday, January 07, 2014
23:47 UTCEverything operating normally.
23:24 UTCWe still have one last fileserver that we're working to restore access to. Getting closer.
22:43 UTCThere's a single fileserver offline that we're working to restore access to. Almost there.
22:24 UTCGitHub and Gist are online, we're working to restore connectivity to some repositories.
22:13 UTCWe've recovered from an internal DNS outage, and are working to restore service to all repositories.
21:54 UTCGitHub and Gist are down. We're working to recover the site.
21:36 UTCWe're investigating reports of outages across GitHub and Gist.
21:33 UTCgist.github.com is offline for unscheduled maintenance.

https://status.github.com/messages

>>752
OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/

>>752
開発者ならcloneしてるのだから、svnとかほどの問題にはならないだろう。

落ちてたの気付かなかった
っていうか気づいてなくて良かった
気付いてたら発狂してるとこだった

分散型なのになんで発狂するの？
cvsをまったく笑えないよね

pushしたら自動でfetchしたいんだけどできる？

なんでgitおちたん

githubをgitと略すにわかはかえれ

>>758
せつこ、それgitちゃう! githubや!

なんの疑問も抱かずgitと打ってしまった

githubとかしょっちゅう落ちてるよ

GitってVSSみたいにファイルのチェックイン、チェックアウトを厳密に
アトミックにロックするやり方の管理もできるの？

テキストファイルみたいな中身を把握して差分を常に意識するならGit方式
でいいけど、画像ファイルとか、特定アプリのバイナリファイルの共同
開発だとVSS方式もあった方がいいよね。

ロックの管理はGit以外の方法でやればいい

アンチはGithubが落ちた、と鬼の首でも取ったように大騒ぎしたがるけど、
むしろリモートに接続しなくてもローカルのリポジトリで作業ができてしまう
Gitのすごさが立証された事象だったんだよな。

gitの凄さが立証されただけで
Githubが落ちたこととは関係ない。

リモートが落ちただけで作業ができなくなる奴が致命的に馬鹿なだけ

WikipediaをWikiと略すやつがいるように、そのうちGithubもGitと略される日が来るんだろう

だがこのスレにおいてはハブとかサバとかサブとかホモとかそういう感じで

それはWikipediaがpediaと呼ばれるくらい非現実的だな

WikipediaでないただのWikiを使う人は限りなく少ないけど、
Githubとは関係なくGitを使う人は多いからなあ

>>771
いやいやwiki使う人めちゃくちゃ多いだろ。wikipediaで使ってるmediawikiに限定するならともかく。

Wikipedia以外にWikiってものを意識して使わないような人が沢山いるって話だろ？そりゃWikiをなんらかの形で使ってる人は沢山いるだろうけど。

Wikipediaではない他のWikiをWikipediaと呼ぶ奴までいるんだぞ

mediawiki使ってるとこをWikipediaと勘違いしちゃうのは仕方ないと思うけどねー

wordpressのことをwikiって言ってる人もいたな

知ってる人とでも面倒臭がって間違いを正してあげないからなー。ホームページやハッカーに続くのか。

Bitkeeper使えよ貧乏人ども

irane

とにかく自動でfetchするようにしたいんだけどどうしたらいい？

10 fetch
20 goto 10

githubかgitlabにNGユーザーと通報機能みたいな荒らしを排除する仕組みはある？
それっぽいのなくて荒らされても止められず不特定多数のユーザーのリクエストをすべて拒否するしかなさそうだけど

荒らされる奴って荒らされる方にも問題があるんだろ

煽り抜きで、みんなドキュメントとか画像とかの管理はどうしてるの？
マジで >>764 しかないの？

>>1
このURLアクセスできる？
http://progit.org/book/ja/

こっちのURLならアクセスできる
http://git-scm.com/book/ja/

>>784
しかないの

>>783
自分も荒らされてるところ見たことないけど実際攻撃されたら
ただのgitとしてしか使えなくなるのはあまりに脆弱で不安
たとえば領土問題のある地名をデータとして持つか受け入れるプログラムの
リポジトリにクレーマーが粘着するというケースはありえるしそのとき
普通のユーザーごとリクエストを拒否するしかないのは欠陥でしょ

>>787
おまえら自分がGitスレ荒らしてるって認識はある？
Githubのことはこっちに行けよ
OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/

git diff --color で
空白のみ違うときに 豆腐を表示してくれるけど
あれウザいんでなんとかならんかな

かといって、 -w をつけると空白のみの差分を無視しちゃうので
空白は豆腐でなく空白で表示してほしい

git diff FETCH_HEAD
と書いたらfetchした分との差分になるけど
git diff
と書いたら何との差分になるの？
git diff △△△△△△
あえて明示的に書くとしたら
△△△△△△ は何になるの？

HEAD

>>789
いいアイデアがあるぜ
自分でソースを書き換えてgitを再構築するんだ
Coolだろ？

>>792
あぁ、そんなことは知ってる。

それをやらずにする方はないのかって意味なんだが、
理解できなかったか？

git config color.diff.whitespace normal

>>790
ありがとうございます
HEAD かー

>>794
ありがとうございます
こういうデフォルトで設定されているオプションを一覧したいけど
表示させる方法ってあるんですかね

>>788
すまんそのスレ知らんかった

>>784
CVSやSubversionじゃだめなの？

確かにGitってテキスト主体のオープンソースの分散開発ならいいけど、
社内とかの仕事で使うにはあまり意味ないよね。

各人勝手にソースいじることないし、最終的にどこを取り入れるか判断する
人の負担が大きいし。

>>784
textやsvgをふつーにgitで管理してる。
別にバイナリでもロックする必要性を感じない。

gitって画像のやりとりにも使えそうな気がするけど
やってはイカンのだろうな

いいんじゃないの？
本でも漫画でも同人誌でも。
著作権法に違反しないなら。

>>798
gitにかぎった話じゃないけど、内部管理とプロジェクト管理を別々のリポジトリ使うことはよくあるよ。
そういうとき、分散型の方が楽にマージできる。

一応、バイナリファイルも管理できる。
コンフリクトしやすいから--oursとか必要になるけど

>>798
お前、ソースコードの管理にしか使ってないだろ？

CVSやSubversionでどうやって
一日数回のコミットと複数のブランチを作ってマージが出来るっていうんだ？
不可能ではないが面倒くさすぎるだろ。

>>796
git config --help
では？

>>798
> CVSやSubversionじゃだめなの？

いまは Subversion 使ってるんだけど、git のローカルコミットは確かに便利なので、みんなどうしてるのかと。

>>799
> 別にバイナリでもロックする必要性を感じない。

運用でカバーできてるってこと？

>>805
バイナリ入れるのはデザイナの作った画像くらいだし、滅多に更新しないから。

>>803
コミットもブランチ分けも全部紙ベースの申請と会議で許可が出るんだよ
察してやれ…

素人が好き勝手にやるにはGitが便利
組織のなかできちんとした管理をするにはCVSが便利
って結論か。

>>808
　　　　 /: : : : : __: :/: : ::/: : :／/: : :/l::|: : :i: :l: : :ヽ: : :丶: : 丶ヾ　　　　＿＿＿
　　 　 /;,, : : : //::/: : 7l,;:≠-::/: : / .l::|: : :l: :|;,,;!: : :!l: : :i: : : :|: : ::､　 ／　　　　 ヽ
　　　 /ヽヽ: ://: :!:,X~::|: /;,,;,/: :／　 ﾘ!: ::/ﾉ　 l｀ヽl !: : |: : : :l: :l: ﾘ /　そ　そ　お　＼
　　　/: : ヽヾ/: : l/::l |／|||llllヾ,､　　/ |: :/ , -==､　l＼:::|: : : :|i: |　/ 　 う　う　 前　　|
.　　 /: : : //ヾ ; :|!: ｲ､||ll|||||::||　　　 ﾉノ　 ｲ|||||||ヾ､ |: ::|!: : ｲ: ::|/　 　な　思　が
　　 /: : ://: : :ヽｿ::ヽl |{ i||ll"ﾝ　　　 ´　　　i| l|||l"l　｀|: /|: : /'!/l 　 　 ん　う
　∠: : : ~: : : : : : : :丶ゝ-―-　　　　　 , 　ｰ=z_ｿ　　 |/ ﾊﾒ;, :: ::|.　　　だ　ん
　　 i|::ﾊ: : : : : : : : : : : ､ﾍﾍﾍﾍ　　　　 ､　　ﾍﾍﾍﾍﾍ /: : : : : ＼,|.　　　ろ　な
　　 |!l　|: : : : : : : : :､: ::＼　　　　､-―-,　　　　　　/ : : :丶;,,;,:ミヽ　　 う　 ら
　　　　　丶: :ﾊ､lヽ: :ヽ: : ::＼__　　｀~　"　　　　　 /: : ﾄ; lヽ）　　　ゝ
　　　　　　 ﾚ　｀|　｀､l｀､＞=ﾆ´　　　　　　　 ,　　_´ : :}　｀　　　／
　　　　　　　　 ,,､r"^~´"''''"t-｀r､ _　　-､　´ヽノ　＼ﾉ　　　／　　　　お ・
　　　　　　　,;'~　　_r-- ､__　　　　　~f､_>'､_　　　　　　　　 |　　で　　前 ・
　　　　　　f~　　,;"　　　　　~"t___　　　　ﾐ､ ^'t　 　 　 　 　|　　は　　ん ・
　　　　　 ,"　　,~　　　　　　　　　ヾ~'-､__　ﾐ_ξ丶　　　　　|　　な　　中 ・
　　　　　;'　　,ｲ　.. 　　　　　　　　　ヽ_　　 ヾ､0ヽ丶　　　　l　　　　　　　　　/
　　　　 （　;":: |:　:: ..　　　　　　　　　 .｀,　　 ヾ　丶 !　　　　＼＿＿＿＿／
　　　　　;;;; :: 入:: :: :: 　 　　　l｀ｰ-､　　 ）l　　 ヾ　丶
　　　　　"~､ｿ:: :い:: :　　　　　＼_　　ノ　,　　　 ヾ　丶

>>806
ああなるほど。
仕様書とかマニュアルはどうしてます？

>>810
よくよく考えると、文書類はwikiがほとんどだ。小さいアプリだとtext/plainなくらい。
マニュアルはhtmlだな。またはwikiからpdfを生成とか。

組織もでかくなって人の出入りが多かったりするとロック方式のVCSとか面倒だよ

ドキュメントのフォーマットに合わせてコードの管理方式を選択するとかアホすぎると思わんのか
コードの管理はロックの無い分散管理が便利過ぎて集中管理なんかに戻る気になれん

大きな組織では誰が何をいつやるか、というスケジューリングや担当分けの調整が
大事だから、やっぱGitは向いてないよ。

別に良い悪いじゃなくて、いい加減なオープンソース開発とかに向いている（その
ために作られた）わけでさ。

Linuxカーネルはいい加減な開発体制
弊社は中小にすぎないがLinuxカーネルのようないい加減なソフトは作っていない
よってGitなど使っては開発体制が崩壊する

Linusみたいな独裁者がいるとGitは上手くいく。
北朝鮮型。

馬鹿には無理

馬鹿には使いこなせない

分散型は個々の作業を重視した開発に向いているよね
そういう意味でオープンソフト向けなのは確かだと思う
自由気ままに各自で開発して、良ければマージしてねってスタイル向け

個々のスキルを重視できる職場向きとも思う
だけど日本の職場には向かないんじゃないかな
理由はお察s(ry

>>814
> 大きな組織では誰が何をいつやるか、というスケジューリングや担当分けの調整が
> 大事だから、やっぱGitは向いてないよ。

なんで？　その理由を書かないのはなんで？

大きな組織でのスケジューリングや担当分けの調整で
集中型のバージョン管理ツールが大活躍してるんですか？ｗｗｗ

ウォーターフォール型のプロジェクトだとGitが向いてないのは確かだね。
Gitだと頻繁にコンフリクトが起きて、それを解決する工程が割り込んでくるから
あらかじめ決められた工程を決められた日程でこなしていくウォーターフォールとは根本的に合わない。
コンフリクトするたびにそれを解決するためにスケジュールを修正し直してたらキリがない。
Gitはあくまでコンカレント開発ができるアジャイル開発のためのツール。

ウォーターフォール型のプロジェクトでコンフリクトが多発とかマジですか？ｗ

>>822
gitでコンフリクトが起こるようならsvnでも起こるでしょ
コンフリクトは分散や集中とかとは関係ないよ
ただ集中型ツールならロックというコンフリクト回避手段が用意されているだけで

ウォーターフォール開発でGitのコンフリクトは基本的には起こらないだろ
どういうときにコンフリクトするのか理解してないのか？

オープンソースなら見知らぬ他人からプルリクエスト来たりするじゃん
どうやって回避してるの？

下手っ糞なコードであちこち改編されて
プルリクエストが来た日には殺意を覚えたもんです

何を回避するんだ？

気に入らない pull request は無視すれば良いだけ

なんかGitと関係あるの？
昔からメーリングリストにパッチ投げるとか普通にあるんだが

gitでpull requestってどうやるんですか？

m９ prpr

>>831
リポジトリをクローンして修正して相手がアクセスできる場所に置いてから、
相手に連絡をつけて、レポジトリを置いた場所とマージしてちょ！という意思を伝えます。

うちも同じ感じで コミットしました って電話してる。

うちはコミットしたら課長のハンコもらって社内便でPR！

>>821
> 大きな組織でのスケジューリングや担当分けの調整で
> 集中型のバージョン管理ツールが大活躍してるんですか？ｗｗｗ

？ バージョン管理ツールはスケジューリング用のツールじゃないよ？
だから全く関係ない話で、大活躍もしないし、逆に向かないってこともない。
だって全く関係ないから。

うちは予定と予定完了をコミットして管理してる

あー、わざとらしいｗ

予定日のコミット位置は未来になるからコミットの位置では進捗確認できないのでは

そのコミットじゃねーよ。バーヤ

TODOリストをバージョン管理してるだけなんだけど？
基本的にメモとか全部Gitのレポジトリの中

Gitは〜には向かないのでは？　という意見を描いているだけなのに、Gitそのもの
ひいてはそのファンかなんか知らんがの自分さえけなされていると思って妙な反応しちゃう
人って困ったもんだよね。

大組織での開発にも、いや、Gitってこういう使い方すれば役に立つよ、という書き込みなら
まだ建設的な議論が出来そうだけど、具体的な内容ゼロの当てこすりや小馬鹿にしたような
書き込みばかり。

まあ、なんらかのコンプレックスとか後ろ暗い部分を刺激してしまうのかもしれないけど、
別にGitなんて単なる道具に過ぎないわけだし、そんなものに自意識投影しなくてもいいんじゃね？
と思う。

バージョン管理ツールで予定する前提で話してる奴とスケジューリングツール前提のやつ入り混じってて
話がかみ合ってないのに自信満々で語ってるアホがいるからややこしい

〜には向かないのでは？っていう書き込みに、
別にそんなことないよ？って答えが返ってきてるだけじゃない
それ以上の情報が欲しいとか、炎上させて情報得ようとかの糞野郎でしかないね

>>842
小馬鹿にするっていうか、「〜には向かないのでは？」って書いてる奴が馬鹿過ぎるんだものｗ

Githubについて語りたいならこっちへ

OSSホスティング総合【SourceForge,GitHub,etc..】
http://toro.2ch.net/test/read.cgi/tech/1384821518/

Gitというより分散バージョン管理の問題について語りたいならこっちへ

バージョン管理システムについて語るスレ9
http://toro.2ch.net/test/read.cgi/tech/1334766732/

×　Gitは〜には向かない
○　〜はGitには向かない

管理者、利用者含めて、運用システム構築できないんだったら、git使わないほうがいい
使う側も管理する側もgit理解してないといけないぐらいgitって自由度高すぎるんだよ
ていうのを
mercurial→gitにきて思った

草生やした会話が普通だと思ってるお客様は巣から出てこないでね
迷惑だから

Gitに向かない用途なんてないだろ
使いこなせない奴がバカなだけ
だいたい一流企業ではGit使ってる

わかってるだろうけど>>849=>>845
自演してるだけ

敵は一人妄想の奴とか自演妄想の奴って、自分に自信がないもんだから、
「自分は多数派である」という幻想にしがみつくしかないのかな？
なんか哀れっぽいw

なんで>>849=>>845だと自演なんだ？

ちなみに
Googleは独自ソース管理システムを持っててGitを使ってない
MSはVisual StuidoがようやくGitサポートし始めたとこだから、社内でも本格的には使ってないんじゃないかな？
Appleはよく知らんが使ってそう

日本のIT関係だとどうなの？使ってる率高いの？

>>852
一人二役で論争作って炎上させようとしてるからだよ
>>851で化けの皮はがれたからこんな場違いに低能な奴もう相手にされないだろうがね

>>852
MSがTFS使ってなかったら笑い話やな

また敵は一人妄想か。

>>854
いやべつに、849と845が同じ奴の書き込みでも違う奴の書き込みでも大勢に影響無いと思うのだが…？

割と大手電機メーカー子会社系列のソフト屋だけど、まわりじゃGitは使われてないね。
MSDNのライセンスを買っているからSourceSafeを使うことが多い。
WORDとかのドキュメントは差分取っても意味ないので、MSSみたいなチェックイン、チェックアウト式で充分。
ちなみにGithubはファイル交換サイト扱いでアクセスできない（w
これは大手はどこでもそうじゃないかな？

>>853
SIerは案件毎に違うだろうね
Webとかソーシャル系はほぼ使ってるだろう

上にもあったけど、Gitってやはりライナスの独裁モデルを元に発想されたと思うんですよ。
世界中のいろんな人がパッチを当てるみたいな細々した修正をプッシュしてきて、独裁者がどれを採用するかどうか決める。
そういう開発形態にピッタリなんだと思う。これならコンフリクトしても大丈夫なわけだし。

上でGitのコンフリクトの意味が分かってない人がいたけど、別にGitのツールとしてのコンフリクト回避機能に問題があるってわけじゃないんですよ。
大手だと誰がどこを直すのか決めてからやるわけで（そのミスを減らすためにバージョン管理ソフトを使うわけで）、ファイルのロックやロールバックがきちんと行われる方が大事なんですな。

Gitだと複数の人が同じところ勝手に直しだしたりしても検出できないでしょ。無駄な作業が発生するわけ。
どっちが悪いとかじゃなくて、Gitが向いてないタイプの管理が企業内にはあるってこと。
おわかりかな？

>>860
大手のウォーターフォール型の開発だと
どのモジュールを誰が弄るかとかをバージョン管理システムのロックで取り合いしたりしないよ
誰かどこを弄るとかはコード弄る前にレビューとかして明確になってるんだから

だからさ、それが完璧に機能するなら単にファイル共有でいいでしょ。
あくまでミスをなくす（あるいはミスが起きたときにリカバーする方策）目的だよ。
ほんとに頭悪いの？

誰がどこを直すかのミスを減らすためにロックを使うって、
みんながコーディング終わるまでずっとロック取り続けたりするのか？

>>863
はぁ？
お前本当にバージョン管理システム使ったことあるの？

とんだけ的外れな質問だよ？

>>860
GitHubは1人の責任者でなくメンバーそれぞれで採用を決める方法で開発運用できてるのだから独裁にこだわる必要はないでしょ
日本の慣習に合わないってだけで

>>864
Gitにはロック無いんだからここでそんなこと言われてもねえ
それともGitはバージョン管理ツールじゃないの？

また繰り返しかよ。

>>866
>Gitにはロック無いんだからここでそんなこと言われてもねえ
だからGitには向いてない組織あるよね、という話をした。

>それともGitはバージョン管理ツールじゃないの？
誰がそんなバカなこと書いているんだ？
そう読めるなら病院行け。

ほんとバカだよな。

アスペかな？

Gitにはロック無いという前提の話をしているので貼れば、
gitにロックがあるということを説明すれば話は覆る。


gitにおいてロックとは、許可がない限りマージできないということ。
これがロックと同等になる。

マージする時に、マージ担当者に「今からマージします」って言って
マージ担当者に他のマージを待ってもらうようにすればいいだけ。

subversionでもロックを掛けられるからといって
勝手にマージしたらダメだろう？
どっちみちマージ担当者に許可を得ているのだから同じことである。

いやちょっとまてよお前話の流れ掴めてないだろ
まじでお前に反論してるのが一人だと思ってるのか？

おれ
＞誰がどこを直すかのミスを減らすためにロックを使うって、
＞みんながコーディング終わるまでずっとロック取り続けたりするのか？

おまえ
＞はぁ？
＞お前本当にバージョン管理システム使ったことあるの？
＞とんだけ的外れな質問だよ？

おれ
＞Gitにはロック無いんだからここでそんなこと言われてもねえ
＞それともGitはバージョン管理ツールじゃないの？

おまえ
>>867

>>869
>gitにおいてロックとは、許可がない限りマージできないということ。
>これがロックと同等になる。

だからさあ、それ自体は間違ってないって。

もうわざとやってるだろうけど、それで良い用途と、そういう作業が発生する「無駄」を避けたい
用途があるってだよ。

もう嫌になっちゃうな頭の悪い人に説明する徒労感って（笑）
いちど読み直してみなよ、流れを。

流れって860の俺の書き込みからの、ってことね。
念の為。

> >gitにおいてロックとは、許可がない限りマージできないということ。
> >これがロックと同等になる。
>
> だからさあ、それ自体は間違ってないって。

いやこれは全然違うだろｗ

>>871
こいつのレス、事前知識がなくてもスレの内容の切り貼りで作れる内容ばかりなんだが

ファイルのロックで修正箇所ミスを偶然検知できることを期待して
集中管理方式使うとか、さすがにアホすぎる

>>871
Gitじゃなくてロックのない分散管理方式を否定したいなら
>>846 のとこへ行ってやってくれる？

否定したいわけじゃなくても>>846 のとこへ行ってやれ

分散じゃないsvnだって、普通のソースコードの管理に関してはロック無しが推奨なんだがな

上にもあったがGitが向いてない用途という話をされただけで、気が狂ったみたいなに真っ赤になって発狂する奴がいるんだな。
おまけに頭が悪くて、話も通じない。
勝手に曲解してはまともな反論したつもり（笑）
少しは恥を知れよ、まあ無理なんだろうが。

noob

大草原から来た土民の相手するのもうやめたら？

まあGitに限らず信者ってそんなもん

>>879
>>870は無視かよ。ロックの無いGitしか知らないおれに、ロックをどういう風に使ってるか教えてくれよ

そいつスレ読んで知ってるふりしてるだけのバカだから聞くだけ無駄
どのみちGitが向いてないなら向いてる管理ツールのスレに行けば用は済む

そういうことにしたいのですね

ロックをどういう風に使ってるか説明しないならそういうことになっちゃうね

>>885じゃないけど煽りを煽りと見抜けないお前らの純粋さに驚きだよ
9割が悪口のレスを律儀に相手するなんて

　　　　　　　　　　　　 ,,.. -──‐- ､
　　　　　　　　 ,. ‐'"´::::::::::::::::::::::::::::::｀`‐､
　　　　　　 ,／:::::::::::::::::::::::::::::::::::::::::::::::::::::::＼
　　　　　／:/￣'''7::r--'~l,;─--;:::::::::::::::::::::::::＼
　　　　/:::::/　　 /:/　　 ,　　　　|::|￣￣'``L::::::ヽ,
　　　/::::::::' -‐‐'::::'‐‐､/i＿＿i|/:::|　　　　　 ヾ::::::i
　　 /::::::::::::::::,､:::::::::::::::::::::::::::::::::::::'─'─'ヽ､　　i:::::i,　　　　よびましたか？
　　i:::::::::::::::::://:::::::::::/i::::::::::::::::::::::::::::;;:::::::::::｀'‐､|::::::i
　　|:::::::::::::／ '-､-┬' |::::::::::|i::::l|:::::::::||:::::::::::::::::::::::::::|
　　ヽ:::::::r'　　.r''＼ヽ､__￣ ' ￣ フ￣ヾ::::::::::::::::::::::::::|
　　,:ヘ::::|　　 l　●＼／　　､‐''~,,.. -､'ヾ;:::::::::::::::::::::::|
／　　 ヽ|.　 ´ ゝ,-‐'ﾞ　　　　`i'''"●　l　　i::::::::::::::::::::;!
.　　　　　|　　　　　　　　　　　ヽ､､��'、　 i:::::::::::::／
　　　　　 i　　　　　　 ､　,　　　　` ｀　　　 |:::::::／
　　　　　 ヽ,　　　　　r-､　　　　　　　　　 r‐''~ ＼
　　　　　　 丶,　　　 i''‐i　　　　　　　　／　　　　 ＼
　　　　　　　　＼　　|　,!　　　　　 , -''~　　　　　　　＼
.　　　　　　　　　 ＼ `''　　,,.. -'''~
　　　　　　　　　　　 ￣￣

そういうことにしたいのですね

>>874
>こいつのレス、事前知識がなくてもスレの内容の切り貼りで作れる内容ばかりなんだが
むしろスレの切り貼りで分かるレベルのことを理解できないバカがいるのが不思議なんだが（笑）

>上にもあったけど、Gitってやはりライナスの独裁モデルを元に発想されたと思うんですよ。
>世界中のいろんな人がパッチを当てるみたいな細々した修正をプッシュしてきて、独裁者がどれを採用するかどうか決める。

Gitに「開発思想」があるとしたらこれだよな
Githubはまた異なるが

pushしてきたのをどれを採用するか決めるのって
どうやって実現すればいいの？
これすごくやりたいんだけどやり方が全然わからない

マージ

タイミングと内容的に教えてくんのふりした荒らしにしか見えんな

>>860
バージョン管理システムっていうのは、修正の履歴を残すことと、過去に逆戻って取り出せる事が必要なんだよ。

だから、バージョン管理システムとしては本来ファイルをロックするという行為は必要ない。
その点は理解するべき。
まして、gitの場合、最新のものに対して以外はコミットできないのだから、なんでファイルをロックできなきゃいけないのか理解できない。

複数の人が修正すればコンフリクトは発生するものだから、組織の中で修正担当を決めるのはコンフリクトを運用回避しているだけだよ。
バージョン管理の仕組みとは次元が違う。

>>892
修正したコミットをどこかに置いてもらって、
それをチェックしてからマージするなり突っ返すなりするだけ

コミットをどこに置くかは、クローンした別のリポジトリを用意してそこにpushするのが一般的だけど、
同じレポジトリの別のブランチでもいい

別のリポジトリならpullする必要があるからpullリクエストだね
同じレポジトリの場合はpullする必要ないけど、やってることはあまり変わらん

>>892
君が独裁者となり、どれを採用するか却下するか決めれば良い。

subversionなら独裁者なんていないから
誰でも好き勝手コードをコミットできるのに。

>>895
A→B でpushしてもらって、それを見てパッチを作って
Cに適用してC→D にpushするってこと？

>>897
いや、それこそ崩壊せんかw

うわー、何か伸びとるなー
話が噛み合ってないように見えるけど

宗教戦争は神が命じなくても起きるものなのです

独裁スイッチ

>>898
Git使ってるのにパッチ作って適用する必要とかないだろ
どこかにpushしてもらったら、それを自分のローカルなレポジトリの適当なブランチに
pullして内容を確認すればいい
問題なければ正式なブランチにマージして公開レポジトリにpushだな

>>855
MSがVSS使ってないっていう笑い話があったな。

また根拠のない中傷か

そもそもVSSが酷すぎるからMSはTFSを作ったんだろ

一方Bitkeeperが只で使えなくなったと言ってライナスはGitを作った

OSS界隈でGitが使われる政治的理由は、Google臭やMicrosoft臭、IBM臭がしないから
あのコミュニティはソフトウェア技術者になれなかったものたちの怨恨で膨れ上がっている
何をするにもベストとは言い難い選択肢にも関わらず、それが使われ続けるには、
スタートアップって場所に集まるような連中が何らかのコンプレックス持ちで、
TFSとかBitkeeperみたいなプロフェッショナルたちの使う道具に反感を持ってんだよ。
何者にも成れなかった連中は何かに向いた道具なんて使いたくなかった。
親世代たちへの謀反で反逆者たちの集まり。特にその劣等感の強いのがGitコミュニティ。

>>908
アホはRubyスレに帰れ

278 名前：デフォルトの名無しさん[sage] 投稿日：2014/01/12(日) 14:55:32.49
>>268
違うね。そんなものは所詮、日本国内だけでの話。
世界中でRubyが使われる政治的理由は、Google臭やMicrosoft臭、IBM臭がしないから
あのコミュニティはソフトウェア技術者になれなかったものたちの怨恨で膨れ上がっている
何をするにもベストとは言い難い選択肢にも関わらず、それが使われ続けるには、
スタートアップって場所に集まるような連中が何らかのコンプレックス持ちで、
c#とかjavaみたいなプロフェッショナルたちの使う道具に反感を持ってんだよ。
何者にも成れなかった連中は何かに向いた道具なんて使いたくなかった。
親世代たちへの謀反で反逆者たちの集まり。特にその劣等感の強いのがRubyコミュニティ。

>>908
なにか凄い怨念を感じます！！

さすがスレ監視員の仕事は早いなw

>>885 糞壁乙

>>858
MSSなんて初めて聞いたわwww

>>811
なるほど、そう言う運用なら管理対象はほぼテキストだけだからロックとかはなくても大丈夫そうですね。

>>861
> どのモジュールを誰が弄るかとかをバージョン管理システムのロックで取り合いしたりしないよ

なんでそんな発想になるの？
ロックで取り合いするんじゃなくて、予め編集すると決めた人以外が間違って編集しないようにするだけのものですよ。

上でも書いてる人がいるけど
あらかじめ決めた人以外が間違って編集しないようにする目的には、ロックはあまり役に立たなくない？
あらかじめ決めた人がロックして編集はじめる前に、他の人が間違えて編集してコミット終えちゃったら意味ないよね？
ほんとにそんな機能が必要なら、ファイル毎にアクセス権を指定するとかの仕組みを用意した方がいいと思うんだけど

>>915
ちょっと何を言ってるのかわからない

ファイル毎のアクセス権を一時的に指定する仕組みがロックでしょ

ブランチに権限設定するだけで十分じゃないすかね
プルリクエストならチェックしてからしか編集されないからロックもいらないし

>>916
普通、ロックは誰でも取得できるよね？間違えて取得してしまう可能性もあるわけだ。
アクセス権は普通は管理者がまとめて設定する。

>>916
Aさんがfoo.cを担当することになりました。
Bさんはfoe.cを担当することになりました。
Aさんは他に作業があったのでまだfoo.cをロックしてませんでした。
Bさんは間違えてfoo.cをロックしてコミットして作業を終えてロックを開放しました。

それ非同期で分業できてます？

Aさんがfoo.cのa関数を担当することになりました。
Bさんがfoo.cをb関数を担当することになりました。

Aさんはa関数を作るためにfoo.cをロックします。
ロックされているのでBさんはb関数を作れません

こういうことになると思うけど、これどうやって解決するの？

>>920
非同期に分業するとしても全員が完全に同時に作業を始めるわけじゃないし、
複数の案件を抱えてれば一時的に作業を遅らせることもあるわけよ

>>922
遅らせる”ことも” あるわけってことは
遅らせないこともあるんだろ？

同時に作業を始められて、その方が良い場合はどうするのさ？

>>922
つまり並行して作業しないと書いてるように見えるが
どのみちリポジトリ落として作業してたらよそでロックされても関係ないよね？

>>923
同時に始めることもあれば、同時に始めないこともある。
各個人が行うロックは、同時に始めたときしか間違って編集するのを防げないから、
そんな中途半端な方式に頼るのをやめてファイル単位にアクセス権を設定した方がいいですね。

>>924
並行して作業が行われるかどうかは確定できないと書いてる。

馬鹿には無理

マージベースになったSVNでもオプションでロックが用意されてるのは
マージが難しいファイルの同時編集を避ける目的であって、
ファイルを間違えて編集するのを防止するためとかどっかズレてるんだよ
ファイル間違えて編集しちまったら諦めてリジェクトされてやり直せ

>>925
そのロックもうGitの役割じゃないというかGitの機能を損ねてると思う
Gitじゃなくて自分がやりたい開発管理でしょ

つまりさ、ロックをすると
同じファイルを平行して作業できないってことだよね？

それって不便だと思うけど。

>>919
Aさんが作業開始する前にBさんがロックを解放したなら何の問題ないし、
そうでないなら、Aさんがロックできないことに気付くので、Bさんに直接間違いを指摘すればいい。

>>921
二つのやり方がある。

1、ロックを使わない。後でマージする。

2、同一ファイルに書かれているということは、関数同士に関連があり、
マージで不具合が発生する可能性が高いので、
Aさんが作業完了した後にBさんが作業を開始する。
もし、関連がないなら別のファイルに分離し、それぞれのファイルをロックして同時に作業する。

ロックが使えるからと言って、あらゆる場面で使わなきゃいけないって事は無いんだよ。

>>931
問題あることになるだろう。
予め編集すると決めた人以外が間違って編集することを防げないんだから。
>>919や>>915は、>>914のこれに対する書き込みだぞ？話の流れ読めてる？
＞予め編集すると決めた人以外が間違って編集しないようにするだけのものですよ。

「予め編集すると決める」 -> 「ロックを取る」ことなんだよ
>>931は日本語不自由なんだからそのぐらい察してやれｗ

>>860のこの書き込みからはズレちゃってるが
「大手だと誰がどこを直すのか決めてからやるわけで（そのミスを減らすためにバージョン管理ソフトを使うわけで）、
ファイルのロックやロールバックがきちんと行われる方が大事なんですな。」
こいつは話の流れ無視して好きなこと書き込んでるだけだからしょうが無い

常にサーバーにあるオリジナルのリポジトリを参照（してロック状態を確認）しながらしか作業できないGit
退化しすぎ
コンフリクトの発生は間違えて指示出した奴と間違えて作業した奴が悪いのであってロックがないせいじゃない

緊急のバグフィックス入れたいが、開発者がロック取りっぱなしだから入れられない。しょうがないからパッチファイルにしといて後でコミットするか。あー変更されてるからマージしなきゃ。と、gitがしてくれることを手動でやることになりそう。

>>931
> ロックが使えるからと言って、あらゆる場面で使わなきゃいけないって事は無いんだよ。

じゃあ、ロック使わないでやればいいんじゃね？

ロックされていても出来る方法をあなたが書いたでしょ？
> 1、ロックを使わない。後でマージする。

常にこれをやれば、ロックは不要だよね？

排他制御であるロックと、アクセス制御は違いますよ、
っていう当たり前の事をわざわざ主張してたの？

そりゃ想定外だわ。

vcsの話なんだから、
「予め編集すると決める」はアクセス制御目的ではなく、排他制御目的で言ってるのかと思ってたよ。

後でマージすればいいだけなんだから
排他制御する必要はないと思うけどな。

まあ普通そうだけど話の発端は>>860だからね

担当者と常に連絡が付くならロックでもいいんだよね。

普段はロックでできるだけマージを排除しつつ、
緊急時はロックを解除してもらって、後からマージ。
同時にリスケジュールなどの調整も行う。

問題は担当者が不在の時。
それを考えると、最初からロックしなくていいか・・・って話になる。

昔のVSS思い出すなあ

もう当分ロックの話題は見たくないわ

「ロック」・・・そんな事はする必要がねーんだ。
なぜなら、オレや、オレたちの仲間は、
ロックするファイルがわかった時には！
実際に編集しちまって、もう既に終わってるからだ！
だから使った事がねェーッ。

「コミットする」なら使ってもいいッ！

>>943
なんで大事な最後で噛むんだよ兄貴

じゃあ、次はキーワード展開の話題に移ります＾＾

またエライ伸びててビビったぞ

なんの脈絡も無くね？
>キーワード展開

>>946
釣りネタに釣られる阿呆に対する皮肉じゃないの

その次はタイムスタンプの話題

実行属性は保存されるのにタイムスタンプは保存されない
ってのはたしかに片手落ちな感じはするな・・・
これってgit界では定番の問題なの？

MSはWindowsも使ってないんじゃないかな

タイムスタンプはmakeが使うわけで、意図的にやってると思うが。

>>948
タイムスタンプを見てビルドする前提のソースコードを管理する仕組みだから、
タイムスタンプが維持されてブランチ切り替え後のビルドがうまく走らないのは問題がある

なるほど。gitはタイムスタンプの問題点を
解決しているわけで、これは進化なのか。

進化というか、UNIXで動くソース管理ツールは昔からこうじゃないの？

>>951
それは強制される話ではない気がする
タイムスタンプを保持するかしないかは選択できるべきだよね

>>954
ソースコード管理のために必要最小限の機能だけを用意するのがGitのポリシー
実装が簡単になるし、関連ツールなんかも作りやすい

構造をシンプルにしておくことは大切だよ
以下、戦いに敗れたBazの恨み節

Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて
http://cpplover.blogspot.jp/2014/01/bazaar-ng-7.html

＞ほとんどのGitユーザーはファイルフォーマットの詳細を知っているし、たとえ知らないにせよ一日で学べる。
＞Gitのバグをソースファイル上で見つけるのは、様々なレイヤーが関係するBazaarを理解するよりも、
＞だいぶ簡単だ。新し目のBazaarのファイルフォーマットは、たいていドキュメント化されていない。
＞bzrの世界にいて何年も経た後でも、いまだに筆者は、gitのpack実装のバグを修正するほうが、
＞Bazaarのバグを修正するより簡単だと感じる。

>>955
＞必要最小限の機能だけを用意
そんなポリシーあったのか・・・ 知らなかった

diff周りとかゴチャゴチャとどんどん機能増量してっから
わりと行き当りばったりな思想だと思ってた。

てゆーか タイムスタンプを残す ってのはそんなに大変なことなの？
シンプルイズベストを理由に拒むだけの複雑さがあるとは思いにくい

簡単な実装でシンプルに実現できると思うけど、やろうとしたら
案外と難しいもんなんかな

馬鹿には無理

>>957
diffなんて枝葉部分はいいんだよ
リポジトリの構造なんかに関連するコアの部分に余分なメタデータとか肥大化させるなってことだ

diffはある意味コアな部分をシンプルに保つために機能が肥大化されたりしてるからな
リネーム関連の追跡とか

ファイルの属性ってメタデータとして別途保持してんの？

>>958
少なくともリポジトリの構造が変わるのに対応する必要がある
関連ツールは新旧リポジトリを見分けて対応する必要がでてくるな
>>956とか読んでみてよ。barはそういうのを吸収するために分厚いレイヤーをもった
複雑な構造をしててそれが開発コミュニティーにとっては障害になってたそうだ

>>961
ファイルの属性に関しては、ディクレトリの情報を保存するtreeオブジェクトの中に
「ノードの型(実行属性とか含む100644みたいなの)、実体を指すハッシュ、ファイル名」の三つの情報を保存してて、
実体のほうでヘッダにファイルサイズが保存されてるだけかな
スゲー簡単

内容のほうにファイル名がぶら下がってるのはgitの特徴ではなかろうか。

ファイル名変えるとgit追ってくれなくないか？

>>940
連絡つくのならそれこそ、ロックはいらないでしょ。
当事者間でちゃんと調整しようよ。

ロックにしろ、タイムスタンプ保持にしろ本来バージョン管理には必要ない機能だから無いことを当然として、運用を考えるべき。

それにしても、ここたまに爆発するなw

>>965
--find-renames
完璧に追跡してくれるわけではないが

git mv で変えれば追ってくれるとかじゃないのか?

>>963-964
ファイル本体の方には中身に関連する情報以外の属性は含んでないんだよな
だから中身が同じなら別のファイルでも同じファイルで管理してる

$ ls -l
total 8
-rw-r--r-- 1 root root 6 2014-01-13 21:20 bar.txt
-rw-r--r-- 1 root root 6 2014-01-13 21:12 foo.txt
$ cat foo.txt
Hello
$ cat bar.txt
Hello
$ git ls-tree HEAD
100644 blob e965047ad7c57865823c7d992b1d046ea66edf78 bar.txt
100644 blob e965047ad7c57865823c7d992b1d046ea66edf78 foo.txt

ファイルの実体を指すハッシュが一致

>>968
関係無い
git mvしてもリネームしたっていう情報が保存されるわけじゃない
diff実行時にファイルの中身をチェックしてリネームされた結果なのかどうかを推測してる
logなんかにもおなじように推測する機能がある

そもそも当てにならないマシン毎の時計を元にしたタイムスタンプや、タイムゾーンを
超えた地域とも共同開発するのがあたりまえのGitなんだから、そんなものを重視する方が
おかしい。
あくまでファイルの内容そのものだけを判断の基準にするのが優れた典なのだから。
昨日から長文でもっともらしいこと言ってるけど中身が何も無いアホな文系の書き込みして
るのはプログラマになれなかったアホが板で暴れてるようだな。他のスレまでコピペして
ご苦労なことだ。自演してもすぐわかるのにな。

>>971
＞長文でもっともらしいこと言ってるけど中身が何も無いアホな文系の書き込み

バカはすぐ文系とかレッテル貼りたがるよな（笑）

svnだとファイル移動する時にsvn mvしないと追跡しないけど、
gitだと別にgit mvしなくても、普通にmvなどで名前変えるだけで
いいから便利なんだよな。
通常のファイル処理してるだけなのに、特殊なコマンド使わなくていいからね。

mvで名前変えるとgit rmとgit addしないといけないから面倒だろ？

>>966
> 無いことを当然として、運用を考えるべき。

で、君のところはバイナリファイル (要するにマージできないファイル) の管理はどうしてるの？
git 以外を使ってるとか？

>>970
> diff実行時にファイルの中身をチェックしてリネームされた結果なのかどうかを推測してる

必要最小限の機能とかいいながらこんな余計な機能をつける奴ってバカじゃね？

>>977
だからコアな部分の機能を必要最小限と言ってるだろ

リネームに関する機能をコアな部分に組み込めば、コアだけじゃなく関連するいろいろな部分に影響がでる
diffとか一部コマンドだけで対応できれば他はシンプルななままに保てる

>>976
うちは、画像とかは担当決まってるんで複数の人が同じものを編集することは無いし、
ドキュメントはテキストベースのHTMLやらMarkdownで管理してるんでマージ可能なので、
特に問題にならない

どうしてもエクセルファイルで管理したいって部署があって
そこはエクセルファイル自体はファイル共有してるのをみんなで触って
担当者が定期的にそのファイルをコミットしてるらしい

それテキストと違って差分が分かるわけじゃないから、Gitで管理する意味ないよね。
チェクイン、チェックアウトでやった方が無駄な作業が発生しないのでは？

GitであることよりわかりやすいGUIで版を管理できることがニーズに合ったんじゃないの

progitというのを6章まで読んだが
gitって難しそうだな(vcs自体が俺にとっては初めてでもあるが)
末端開発者は実に気楽だがメンテナというマージ担当者の負担が重そうだ

>>983
負担になるようなマージ処理が発生するようなコンフリクトがあるときは
末端にリベースしてもらうから問題無い
計画的に開発してるならそういうコンフリクトはほとんど起こらないけどね

コンフリクトってテキスト的なコンフリクトの検出だけでしょgitが出来るのって
コード上の整合性での問題は検出してくれない

そんな便利なものを検出するのはVCSだけじゃ不可能だわな
ファイルを跨ってプログラムの処理がコンフリクトしてる可能性もあるわけだし
だからコミットしたら自動的にテストが走るような仕組みを作るわけで
Gitの関連ツールの作りやすさはその辺にも役立つ

ファイルロックが必要だ！

テストツール使え

次スレよろ

立てたよ

Git 8
http://toro.2ch.net/test/read.cgi/tech/1389701817/

Windowsで使うのに、どのツールを使うのが一番？
日本語メニューを希望

Eclipseに入ってるEGitは結構お気に入り

スタッシュとかフェッチとかいうカタカナメニューが並んでるツールとか
使い方を覚えられる気がしない

埋め

埋め

埋め-

埋め

働けど働けどなお我が暮らし楽にならざりGit手を見る

埋め

1000

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。