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

Git 9

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2014/04/12(土) 13:22:20.98ID:s4x1CSLN
ソースコード管理を行う分散型バージョン管理システム、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 8
http://toro.2ch.net/test/read.cgi/tech/1389701817/
0017デフォルトの名無しさん2014/04/14(月) 06:07:54.65ID:eZQPfKWX
>>16
本を紹介すると
> Gitに関係ないGitHubの話や質問をここですることを受け入れるかということです
になるんだ...

なんかの宗教なの? (w
0018デフォルトの名無しさん2014/04/14(月) 06:12:49.91ID:1BzKypQe
GitHubはGit関係なので
話題にしてOK
0019デフォルトの名無しさん2014/04/14(月) 06:23:10.46ID:7zmL9s1f
祝・GitHub解禁
0020デフォルトの名無しさん2014/04/14(月) 06:33:02.10ID:1BzKypQe
gitやるなら、gitコマンドだけじゃなくて
gitを使った開発手法も対象内だし、
gitサーバーやgitワークフローもgitの話題の一つ。

GitHubはそのサーバーとワークフローのためのツールなんだから
このスレで全然問題ない。
0021デフォルトの名無しさん2014/04/14(月) 06:54:18.95ID:r6Wx+cLS
OpenSSLにすごいバグがあるらしいけど、OpenSSHは大丈夫なのかな。SSHでgitサーバに接続してます。
0022デフォルトの名無しさん2014/04/14(月) 07:13:46.54ID:7zmL9s1f
>>20
BitbucketとSourceForgeもいけるね
やったー
0023デフォルトの名無しさん2014/04/14(月) 08:56:01.10ID:AmAJMm0T
>>9
ステマすんなゴミ
0024デフォルトの名無しさん2014/04/14(月) 09:08:38.81ID:1BzKypQe
>>22
はい、そのとおりですよ。
gitサーバーとしての使い方なら
問題ありません。
0025デフォルトの名無しさん2014/04/14(月) 09:48:57.46ID:6tPspeJq
http://yamaha-webmusic.github.io/
http://yamaha-webmusic.github.io/nsx1-apps/manual/

こういうアカウントってフォローするのどうやるの?
0026デフォルトの名無しさん2014/04/14(月) 09:52:00.42ID:toZF1Crt
git 単体で ITS なしの運用って辛いな・・・
なんでメールのみでのやりとりなんだ・・・
0027デフォルトの名無しさん2014/04/14(月) 13:45:30.96ID:gAJOCe3S
ITSって何だ?
0028デフォルトの名無しさん2014/04/14(月) 14:04:20.03ID:toZF1Crt
>>27
ガチで5分で分かるITS/BTS&使えるツール6選 (1/7)
http://www.atmarkit.co.jp/ait/articles/1306/26/news012.html
0029デフォルトの名無しさん2014/04/14(月) 14:48:38.62ID:pS18deUR
発行追跡システマ
0030デフォルトの名無しさん2014/04/14(月) 16:08:45.44ID:gAJOCe3S
>>28
おぉ、さんきゅ。
ITSだけでググっても、明らかに関係無さそうなヤツしか出てこなかったから何かと思ったよ。
関東ITなんちゃらとか、なんちゃら交通システムとか。
0031デフォルトの名無しさん2014/04/14(月) 21:07:55.30ID:Uax92dk0
関東ITはなかなか良いぞ
0032デフォルトの名無しさん2014/04/14(月) 22:59:31.00ID:XW768nZt
>>14
レスありがとうございました!
やはり再構成していくしかないですよね。
そんな感じでやっていこうと思います。
0033デフォルトの名無しさん2014/04/15(火) 20:21:29.46ID:LX0BNsfx
Gitって色々あるけどどう違うのかわからない。
GitHubのアカウントをとってみたり、>>8のリンク先を見たりしたが
色々種類があってわからない。

やりたい事は「プログラムのバージョン管理をしたい(Gitはそう言う用途だからあたりまえだかけど)」と言う事と
何より重要なのが「ソースコードを誰にも見られたくない」と言う事くらいかな。
後は、「どこにいてもソースが落とせる」ってのもある。
GitHubはTwitterみたいなUIだから「どこにいてもソースが落とせる」って事はできそうだけど色んな人から見られそう。
>>8のはローカルで管理する感じなのかな?

良ければ初心者に簡単なGitを教えて下さい。
0034デフォルトの名無しさん2014/04/15(火) 20:33:20.49ID:D1Ol4DiB
「ソースコードを誰にも見られたくない」ならローカルで完結させるしかないね
0035デフォルトの名無しさん2014/04/15(火) 20:34:19.07ID:CXoafp6W
たくさんあるってどういうこっちゃ。クライアントプログラムは色々あるかもしれんが git は一種類しかないぞ。
github は git を使ったホスティングサービスであって git の一種ってわけじゃない。
ホスティングサービスどれがいい?って質問なら↓の方が回答もらえるんでないかな。
・OSSホスティング総合【SourceForge,GitHub,etc..】
ttp://toro.2ch.net/test/read.cgi/tech/1384821518/

他人にソースを見られたくない場合は
・自分で git のサーバを建てる
・ローカルで使う
・プライベートリポジトリをサポートしてるホスティングサービスを使う(大抵は有料)

github もプライベートリポジトリサポートしてるけど有料だね。パブリックだと無料だけど。
自分でサーバを建てる場合も自由になるサーバ持ってないならどっかから借りなきゃいけないから有料になる。
0036デフォルトの名無しさん2014/04/15(火) 21:13:10.96ID:Td9RmRcX
初心者ですが、
Gitの説明でよくブランチの分岐が書いてあってそれでrebaseだcherry-pickだ等々
説明が書いてあるけど、
このブランチの構造自体は皆さんgitのログとかから頭の中でイメージしたり
できるんですか? 自分にはまずそこが問題w
0037デフォルトの名無しさん2014/04/15(火) 21:44:05.28ID:z6touH+D
VPSを自分専用のgit鯖にしてる。
って、ssh開けるだけだから、鯖という言い方もおかしいか。

自宅鯖が安心最安だろうけど、1k円/月くらいあれば安いVPSあるんじゃないか。
0038デフォルトの名無しさん2014/04/15(火) 21:45:31.32ID:z6touH+D
>>36
git graphっていう、よく出回ってるalias見て理解してる。つもり。
0039デフォルトの名無しさん2014/04/15(火) 21:58:59.82ID:OKvn8yBf
git log --gragh --all
でツリー出てくるよ。
コミットログの書式短いのにした方が見やすいけど。
0040デフォルトの名無しさん2014/04/15(火) 22:10:15.34ID:JExjPciB
とりあえずならこんな感じか
git log --graph --all --decorate --oneline

自分はこれだとちょっと表示が気に食わないので、
--decorate --onelineの代わりに--pretty=formatで表示を加工してる
0041デフォルトの名無しさん2014/04/15(火) 23:55:03.38ID:4LopPBVb
俺はDropboxにbareリポジトリ置いてるだけだ。
壊れるのが怖いから時々zipに固めてるけど。
0042デフォルトの名無しさん2014/04/16(水) 00:09:16.13ID:7KV1DqqH
>>34-35
ありがとうございます。
>>8を見ながらインストールしてみました。
取り合えずローカルで使う予定なのでコミットまで一通りやってみました。

ローカルで使うならリポジトリの共有以降は不要ですよね(Gitとしての恩赦も薄そうだけど)

皆さんはリモート使って他の人と共同で何かを作ってるんでしょうか?
仕事で使う以外はローカルでも不便しなさそうですが、勉強のため開発と平行して使い方を勉強していこうかな。
0043デフォルトの名無しさん2014/04/16(水) 00:27:33.04ID:23qQxnbb
リモートリポジトリを使った共同作業が git の本領発揮するとこだから読んでおいたほうがいいと思うけどな
一人で使ってるんだとしても、作業用のローカルリポジトリとリモートの(別にリモートじゃなくてもいいが)マスターリポジトリが分かれてると
push/pull のタイミングでコミット纏めたりとか出来て都合がよかったりするし

自分は githubでプログラム書いたり設定ファイル載せたりしてる
基本的に自分ひとりで書いてるけど誰かが勝手にバグ直してパッチ送ってきてくれたりして楽しいよ
逆に公開されてるソフトなんかで気になる部分を修正してパッチ送ったりとかね

とりあえずアカウントでもとって練習用として色々遊んでみたらいいんじゃない
0044デフォルトの名無しさん2014/04/16(水) 00:37:04.13ID:FwnwH35E
>>36
githubフローに近いやり方で開発している。

自分が開発しているブランチがどこから分岐したかとかは一応把握してる。
それでも忘れるけど忘れたらgit log --decorateで確認するだけ。

自分が作業中のブランチはそんなに多数に平行して
開発するわけじゃないので、数個にしかならない。

他人のブランチの状態や過去のブランチは何も考えていない。
知りたくなったら調べるけど、基本的に無監視。

気にしてるのは、masterが更新されたかどうか。
基本的に自分のブランチは「masterの最新からの開発」という形にしたいから
誰かがマージしてmasterが更新されたら、git rebase masterして
masterの最新からの開発に配置し直す。・・・ってのを定期的に行う。

あとは単純にmasterにリベースしづらい時とか、一時的に他の人のコミットを取りたいとか
なんかミスってコミットを整理し直したいとかイレギュラーな作業でcherry-pickを使う程度。

まあ分岐しまくってそれを把握しなきゃってことはまずないよ。過去は忘れて、自分の現在の作業分だけ。
0045片山博文MZバグロボ ◆T6xkBnTXz7B0 2014/04/16(水) 01:17:21.34ID:9W1Fzx+3
VS2013でgit使ってるか?
どうやるの?
0046デフォルトの名無しさん2014/04/16(水) 01:21:41.21ID:xXOno5ZN
Use Visual Studio with Git
http://msdn.microsoft.com/en-us/library/hh850437.aspx
0047デフォルトの名無しさん2014/04/16(水) 01:35:45.97ID:vWpEG2+U
>>36
初心者はgitk --allでビジュアルに状態を確認しながら
雰囲気をつかむと良いと思う。

あと、「開発・バグフィックスはすべてトピックブランチを作って作業する。」
「トピックは原則としてmasterから分岐する」などのルールを設けて、
確認しないといけないこと(分岐元がどこか、とか)を減らす。

統合ブランチは master またはmasterの先端に作った使い捨てブランチだけにして、
マージ状況は log --oneline --first-parentで俯瞰するなど
ワークフローを工夫すれば、正確なコミットグラフをイメージしなくても
だいたいの状況を把握できるようになる。
0048デフォルトの名無しさん2014/04/16(水) 03:11:28.56ID:EGmRT2AB
たまーに他人のコミットとコンフリクトしまくったりマージのミスでバグが混入したりするから、そういうときにコミットツリーをよく確認したいときは、
SourceTreeとかGitHub/BitBucketとかのサービスで詳細に把握しようと思うことはあるかな。大抵はそこまで把握しなくてもトラブらないけど。
0049デフォルトの名無しさん2014/04/16(水) 03:16:00.58ID:FwnwH35E
それってツリー見てなにかわかるん?
0050デフォルトの名無しさん2014/04/16(水) 03:22:23.47ID:LjaPwUAW
というよりbisectだよね
0051デフォルトの名無しさん2014/04/16(水) 03:24:09.57ID:O1uBrWmJ
自動ビルドテストしようず
GitHubでプルリクエストすればマージ前でも自動テストしてくれるみたいだからリモート環境だけでテストできるんじゃないの
やったことないしどうせ自動化のテストはローカルでしなきゃならんけど
0052デフォルトの名無しさん2014/04/16(水) 03:40:07.18ID:FwnwH35E
そういやbisectで思い出したけど、
テストコードをしっかり書いているとする。

バグが何処かで混入されたとして、
それを見逃したということはテストコードがなかったということになる。

そこで新たにテストコードを追加する。
さて、このテストコードを使って、どこでバグが混入されたかを
bisectで調べるにはどうしたらいいだろう?

git bisectをするたびにコミットが変わるのはいいんだが、
そのコミットには当然追加されたテストコードは含まれていない。

やばい、酒ははいってて、何を書いているのかわからないwwww
0053デフォルトの名無しさん2014/04/16(水) 03:40:53.57ID:FwnwH35E
おーい、ちゃんと文章なりたってるかー?w
0054デフォルトの名無しさん2014/04/16(水) 03:49:55.54ID:EGmRT2AB
>>49
上手いこと説明できないが、ツリーがないよりあったほうがマージのやり直しはしやすい気がする。たぶん自分が関わってるプロジェクトの特性上のものだと思う。
まあ、ツリーだけってよりは1個1個コミットを見ていってそのローカルブランチではなにをするつもりだったのかとかを解釈していくという方が重要なのだろうけど。
>>51
インタラクティブなアプリだと自動でのビルドテストがかなり難しいんだよね。
OpenGLとかメディア系ライブラリと各種センサを使ったアプリとかだと、描画が想定通り行われてるかとか、ムービーが正しく再生されてるかとか、
センサの値が正しく反映されてるかとか、そういうものをテストコード書くのが難しすぎる、というか結局人間が解釈しないとOKかNGか判断できないものが
多すぎてTDDしづらいんだよね。ゲームとか典型例なんじゃないかな?
0055デフォルトの名無しさん2014/04/16(水) 04:03:18.65ID:O1uBrWmJ
>>54
そりゃ無理だな
UIが複雑なのはテストの維持がめんどすぎて割に合わない
0056デフォルトの名無しさん2014/04/16(水) 12:51:47.35ID:LjaPwUAW
>>52
git bisectはコミットされてないdiffを各コミットに適用してくれるから、
テストコードを自動マージできるように書いて
それをコミットしないままbisectすればできるよ
0057デフォルトの名無しさん2014/04/16(水) 14:21:34.93ID:zACk8w4U
漏れはソースを他人に見せたくて仕方がない
露出狂鴨試練
0058デフォルトの名無しさん2014/04/16(水) 21:49:07.29ID:SSurM9Qy
git statusをgit sだったりgsにエイリアスを設定して短くするやり方ありますよね
これgitの開発人たちに公認公式のエイリアスの設定方法って公開してませんかね?
0059デフォルトの名無しさん2014/04/16(水) 21:52:45.78ID:23qQxnbb
alias の設定の「仕方」なら公認公式もへったくれもなく今やってる方法が公式だろうと思うが
大抵の人が設定してるであろう、一般的な alias の一覧みたいなのないかってことかね
0060デフォルトの名無しさん2014/04/16(水) 22:13:23.97ID:QCJjs0GG
git config alias.変更表示 diff

こんなのがあったところで使うかよw
そんなの自分の自由
0061デフォルトの名無しさん2014/04/16(水) 22:59:29.71ID:HsjrRpyw
shellのalias使えば良いだけじゃね?
0062デフォルトの名無しさん2014/04/16(水) 23:18:22.32ID:YDFUIFCV
git sとか一意に出来るところまであれば自動で補完して実行する機能をオンオフ出来れば良さそう
0063デフォルトの名無しさん2014/04/17(木) 03:15:07.74ID:KNGPRiph
>>56
サンクス
コミットしないままbisectできたのか。
まあ確かに動き的にはcheckoutしているだけだもんな。
0064デフォルトの名無しさん2014/04/17(木) 03:18:41.09ID:KNGPRiph
>>58
subversionを真似したら?
短いエイリアスがあるから。

gitのコマンドが長いのは、短縮は自分で好きなの
割り当る用だと思ったりもしてるんだけど
なんか理由あるのかな?
0065デフォルトの名無しさん2014/04/17(木) 13:12:49.12ID:ns8t/lZO
設定してあるエイリアス晒してみる
st = status
ci = commit
co = checkout
br = branch
dif = diff
difc = diff --cached
lo = log --oneline
lf = log --first-parent
lof = log --oneline --first-parent
0066デフォルトの名無しさん2014/04/17(木) 13:45:04.02ID:aPfzsLri
statusはsだろうが
commitはcだろうが
きめえよ
0067デフォルトの名無しさん2014/04/17(木) 14:05:07.53ID:vWEx34Yo
一番良く使うstatusとかlogはシェル関数で置き換えちゃってるな
gst = git status -s -b
glo = git log --graph --branches --remotes --pretty=format:'%C(black white)%h%Creset%C(blue bold)%d%Creset %s'
0068デフォルトの名無しさん2014/04/17(木) 16:24:56.84ID:xYf1zYlh
>br = branch
わかる
>dif = diff
まぁ、わかる
>ci = commit
どういうことなの
せめてcmでしょ
0069デフォルトの名無しさん2014/04/17(木) 16:47:58.48ID:ns8t/lZO
>>68
俺はかつてCVSユーザだったんだが、
CVSのcommitはciというエイリアスを持ってたんだよ。
SVNもciはcommitのエイリアスになってるだろ?

といってもそもそも何でCVSのcommitがciなんだよ?って話だよな。
CVSは当初、その前に流行した単一ファイルバージョン管理用RCSにかぶせてつかう
ディレクトリツリー管理拡張のためのラッパースクリプトとして登場した。
RCSのコミットに相当する操作はcheck inと呼ばれ、コマンドはciだった。
CVS, SVNはそれを継承してるというわけだ。

現在でも主要なディストロはだいたいRCSのパッケージを持ってて、
インストールすればciコマンドを使えるぞ。
ちなみにRCSのcheckoutは当然coだから使い方はmanを見てくれ。
0070デフォルトの名無しさん2014/04/17(木) 17:02:55.46ID:x5+myCPx
ci co は結構多いと思うぞ。
過去の VC の流れで。
0071デフォルトの名無しさん2014/04/17(木) 17:04:57.52ID:7VV2HzZ+
checkinの略だったよね?
0072デフォルトの名無しさん2014/04/17(木) 17:32:10.40ID:x5+myCPx
github で gitconfig alias で検索すると結構色々でてきて面白いな
https://github.com/search?l=ini&;q=gitconfig+alias&ref=searchresults&type=Code

わりとみんな同じ感じなんだねえ
0073デフォルトの名無しさん2014/04/17(木) 17:33:57.98ID:xYf1zYlh
そうなんか、知らんかった
調べたらmercurialもciなんだな
0074デフォルトの名無しさん2014/04/17(木) 17:38:39.61ID:Fx1ijgIa
branchはbだろうが
diffはdだ!
0075デフォルトの名無しさん2014/04/17(木) 17:44:29.46ID:x5+myCPx
一文字だと不安(?)なのか二文字が多いなgithubだと
0076デフォルトの名無しさん2014/04/17(木) 18:39:15.48ID:ns8t/lZO
2文字派か1文字派か。主要コマンドは比較的統一してる人多いね
0077デフォルトの名無しさん2014/04/17(木) 18:50:05.36ID:gzIoS/KQ
cがかぶりやすいからだなw
0078デフォルトの名無しさん2014/04/17(木) 18:52:52.00ID:zmGYf3iT
おれはねエイリアスでgit revertをecho ""に設定している
危ないコマンドや初心者が過去を隠すために使うようなコマンドをあえて禁止している
0079デフォルトの名無しさん2014/04/17(木) 18:56:43.52ID:vWEx34Yo
git revertは危なくもないし過去を隠すコマンドでもないだろ
0080デフォルトの名無しさん2014/04/17(木) 20:34:51.97ID:ns8t/lZO
むしろイケてない過去のコミットを無かったことにできるのがgitの利点かと思うが
0081デフォルトの名無しさん2014/04/17(木) 21:44:17.51ID:XZy5mn+7
revertを禁止にするならresetも禁止にするべき
前進あるのみ
0082デフォルトの名無しさん2014/04/17(木) 21:47:12.93ID:KNGPRiph
え? エイリアスの話?

俺は、

bisect bad に bisect-fixed を
bisect good に bisect-unfixed を
割り当ててる。

便利だよ。
0083デフォルトの名無しさん2014/04/17(木) 22:05:50.07ID:i6eMI8h0
晒してみる。省略形は多用するとクセになるから避けてるなぁ

[alias]
serve = daemon --reuseaddr --base-path=. --export-all --verbose
stat = status --short --branch
exec = "!exec "
0084デフォルトの名無しさん2014/04/17(木) 22:10:52.86ID:u3XqYAfL
>>36ですが皆さん(>>38-40 >>44 >>47 >>48)アドバイスをどうもありがとうございます。

いやーgitをよく知らないままgitで大勢でメンテしているプロジェクトに送り込まれて
しまいまして。

とりあえずgitkとかで表示してみました... うわっ、平行な線が沢山走っている部分が!
なんか宇宙戦艦ヤマトのワープの図を複雑にしたような(たとえが古いか)
線が沢山集中した部分でチェックアウトするともの凄い速度で開発できたりとか
0085デフォルトの名無しさん2014/04/17(木) 22:23:16.22ID:KNGPRiph
開発する人数やワークフローにもよるけど、平行な線は
沢山あるべきじゃないよ。マージしづらくなるからね。
0086デフォルトの名無しさん2014/04/18(金) 02:04:45.06ID:G95hrNw/
>>84
> 線が沢山集中した部分でチェックアウトするともの凄い速度で開発できたりとか
むしろそこは多量のブランチをマージしたところなのでものすごい速度が落ちてるとこじゃないかな
0087デフォルトの名無しさん2014/04/18(金) 10:26:06.59ID:TiuM1iK+
初心者ですけどリポジトリを作ったフォルダの中が管理対象になるんですよね?
でそのリポジトリを削除するとソースファイルまで削除されるんですが
もちろんブックマークだけ(sourcetreeで)の削除はできるのですが
間違ってハードディスク上のリポジトリを削除してしまったら大変です。
何か対策はあるのでしょうか?それともこういうものなのでしょうか
0088デフォルトの名無しさん2014/04/18(金) 10:28:30.25ID:V7HQhmWQ
そりゃそうだろう
リモートにあろうがローカルにしかなかろうがリポジトリ物理的に消したらなくなるわな
大事ならバックアップとっといたらいい
0089デフォルトの名無しさん2014/04/18(金) 10:30:51.17ID:l4m/ooPn
bitbucketあたりにアカウントとってそっちにプッシュしておくとか
0090デフォルトの名無しさん2014/04/18(金) 10:51:55.78ID:TiuM1iK+
ローカルのみで使おうと思ってたのですがリモートにも上げた方がよさそうですね
0091デフォルトの名無しさん2014/04/18(金) 11:00:45.77ID:KSddQ8SJ
Dropboxにリポジトリを作るやり方はここの先輩方はやってますか?
0092デフォルトの名無しさん2014/04/18(金) 11:01:59.07ID:V7HQhmWQ
>>41にそういう奴がいるな
0093デフォルトの名無しさん2014/04/19(土) 12:55:58.24ID:7PgX0mPg
>>84
gitkはgit log(というかgit rev-list)と同じ範囲指定が可能だから、
--allで表示が多すぎるなら表示範囲を適切に限定してやればよい。
特定のtopic(ここではmasterから分岐したとする)とmasterにだけ注目すればいいんなら
gitk master..topic (masterから分岐後のtopicのコミットのみ表示)
gitk master...topic (masterから分岐後のtopicのコミットとmasterにマージされたブランチを表示)
とか。範囲指定は複数回可能なので関係する範囲を好きなだけ指定すればよい。
0094デフォルトの名無しさん2014/04/20(日) 20:26:37.01ID:mILxVbg/
>>91
.zshrcとか.vimrcとかをつっこんだリポジトリはDropboxにbareで載せてる。
0095デフォルトの名無しさん2014/04/21(月) 13:00:54.05ID:ZKyIOHr8
gitignoreで
/*
/.*
このふたつを指定しているのをたまに見かけますが
はじめに/*ですべてのファイルを除外しているので/.*を書く意味は無いと思うんですが何故書くのですか?
0096デフォルトの名無しさん2014/04/21(月) 14:22:29.42ID:dtgq5rdV
ドットで始まるファイルは * のワイルドカードにひっかからない仕様になってる。
シェル由来だね。
0097デフォルトの名無しさん2014/04/21(月) 16:06:02.61ID:mYIG7FH4
なにそれバグだろ
クソだなgitって
0098デフォルトの名無しさん2014/04/21(月) 20:57:12.01ID:1sDt+ic8
無知発見
0099デフォルトの名無しさん2014/04/21(月) 21:13:29.40ID:fKV6ATCG
餌を与えないでください
0100デフォルトの名無しさん2014/04/21(月) 21:48:05.88ID:yaM3rCK5
gitは糞だからsubversionを使え
0101デフォルトの名無しさん2014/04/21(月) 22:43:41.18ID:KhXBvEFh
やだGitじゃないと

VSS、これ最悪でした。
チェックアウトされたままコンパイル通らない状態で担当者休み。どーすんの?
でもMSじゃないと駄目、OSSなんか信用できないとかで泣く泣く使う現場多数。

それに比べるとSubVersionかなりマシだけどオフラインな状態でコミットできない。
ちょっと痛い。
0102デフォルトの名無しさん2014/04/21(月) 23:08:04.07ID:/9iyZBJ2
バージョン管理はgitしか使ったことがない
SVNは何がなんやらサッパリわからないから使えない
0103デフォルトの名無しさん2014/04/21(月) 23:28:39.44ID:wk0llTNx
>>101
× SubVersion
○ Subversion
0104デフォルトの名無しさん2014/04/21(月) 23:37:15.06ID:vVBjDa2G
オフラインの状態でコミットできないとか言ってるけど
コミットしたところでローカルにあるだけだからオンラインで他の奴がお前のリポジトリに
アクセスできなきゃ何もかわらんだろアホか
0105デフォルトの名無しさん2014/04/21(月) 23:51:33.94ID:KhXBvEFh
例えばあなたが飛行機で移動中に10項目ぐらいの作業して
帰社してコミットする時にコメントに10項目だらだら書くの?

やーだー
0106デフォルトの名無しさん2014/04/22(火) 00:01:10.97ID:4JSOLbvH
移動中に仕事するようなワーカホリックになりたくないわ正直
0107デフォルトの名無しさん2014/04/22(火) 00:05:36.52ID:DheOpfOv
一例として挙げただけなのに。想像力無いなあ。
0108デフォルトの名無しさん2014/04/22(火) 00:32:53.01ID:ysn+k/fU
セキュリティ的なこと考えるとオフラインでソースにアクセスってあんまりないんだよね
0109デフォルトの名無しさん2014/04/22(火) 00:48:34.17ID:9W1A4/eN
>>97
いわゆるシェルは.(ドット)で始まるファイルは隠しファイルとしている
隠しファイルは ls *.conf とかで表示されない (.hoge.conf とか)
そんな時に rm *.conf して普段表示されてないファイルが消えるのは困る
だから * だけでは隠しファイルにマッチしないようになっている
ちなみに git が内部でどう処理してんのかは知らん
0110デフォルトの名無しさん2014/04/22(火) 13:52:48.51ID:+yEK9mtt
ふつーにfnmatchでは
0111デフォルトの名無しさん2014/04/23(水) 05:15:19.40ID:7ZWtOh9Z
commit A
commit B
commit C
commit D
commit E
commit F

と順番に作業して
あとから B から D をまとめて

commit A
commit b(B-D)
commit E
commit F

としたいときはどうすれば・・・
0112デフォルトの名無しさん2014/04/23(水) 05:24:18.61ID:kDpoyMyg
よう知らんけど

↓のsquashというやつで出来るんじゃないの?

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-%E6%AD%B4%E5%8F%B2%E3%81%AE%E6%9B%B8%E3%81%8D%E6%8F%9B%E3%81%88#コミットのまとめ

> # s, squash = use commit, but meld into previous commit
0113デフォルトの名無しさん2014/04/23(水) 07:20:48.07ID:fIp3qZsI
>>111
rebase -i
0114デフォルトの名無しさん2014/04/23(水) 09:40:59.20ID:T4x0zu0j
2.0って来月でる?
0115デフォルトの名無しさん2014/04/23(水) 20:35:59.48ID:7vo5B08Z
>>111と反対に、一つのコミットであるbを
B-Dに分割したい時どうしてる?
俺はrebase -i
0116デフォルトの名無しさん2014/04/23(水) 22:04:37.40ID:59LgjvrD
rebase -i はいろいろ便利だよな
ただ慣れないと指定にちょっと戸惑う
>>111みたいにB以下をいじりたい場合だと rebase -i A ってしなくちゃいけないんだよな
それと、まとめたり順番入れ替えるだけなら操作は簡単だけど、バラす場合はちょっと操作がややこしい
■ このスレッドは過去ログ倉庫に格納されています