- 1 名前：デフォルトの名無しさん [2012/10/14(日) 01:10:12.86 ]
- ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
git-scm.com/
◆前スレ
Git 4
toro.2ch.net/test/read.cgi/tech/1329234309/
◆関連サイト
Pro Git - Table of Contents
progit.org/book/ja/
Git入門
www8.atwiki.jp/git_jp/
- 86 名前：デフォルトの名無しさん mailto:sage [2012/10/15(月) 23:15:00.27 ]
- >>84
マスターかどうかの区別は無いけどbareかどうかの区別はある
ワーキングツリーのある作業用リポジトリとは別に
個人サーバーにbareリポジトリを置くのならpushしあえるし、
そうじゃなければpullしあうのはOKだがpushしあうのはややこしい
- 87 名前：デフォルトの名無しさん [2012/10/15(月) 23:29:36.98 ]
- >>86
なるほど、とりあえずどっかにbareレポジトリってのがあったほうがいいのですね
bareレポジトリについて勉強します
ありがとうございます
- 88 名前：デフォルトの名無しさん mailto:sage [2012/10/15(月) 23:53:57.03 ]
- >>84
--sharedにしてないとpushした時に、権限で怒られないっけ。どんなシステムとアカウントでやってるか知らないけど。
pullなら書き込むのは自分だからいいんじゃない。
- 89 名前：デフォルトの名無しさん mailto:sage [2012/10/15(月) 23:55:54.03 ]
- >>87
git init --bare --share
のことだと思うよ。
- 90 名前：デフォルトの名無しさん mailto:sage [2012/10/15(月) 23:59:49.12 ]
- 各人が自分用のbareリポジトリを置いてそこにpushして、
相手のbareリポジトリからpullしあうのが簡単だと思うけどどうなのかね
- 91 名前：デフォルトの名無しさん mailto:sage [2012/10/16(火) 00:26:27.42 ]
- チームメンバーが好きにbareリポジトリ作れるサーバーが一つあると便利よね。
- 92 名前：デフォルトの名無しさん mailto:sage [2012/10/16(火) 11:15:47.53 ]
- >>91
つ bitbucket
- 93 名前：デフォルトの名無しさん mailto:sage [2012/10/16(火) 18:26:37.14 ]
- >>58
差分を読むんだよ
- 94 名前：デフォルトの名無しさん [2012/10/16(火) 18:45:00.10 ]
- >>93
差分はどうやって読むのですか？TortoiseGitがウンコなんですけど。
- 95 名前：デフォルトの名無しさん mailto:sage [2012/10/16(火) 20:05:38.47 ]
- >>92
フリーソフトならいいけど、業務用のファイルを入れるのは無理だなぁ
- 96 名前：デフォルトの名無しさん mailto:sage [2012/10/16(火) 20:39:44.48 ]
- >>94
GUIしか使えない低能はsvn使ってるべき
マジで
- 97 名前：デフォルトの名無しさん [2012/10/16(火) 21:04:52.03 ]
- GitHubにてprivateレポジトリを使って、
4人でコードを書く予定です。
この場合、プランは4人ともMicroなんでしょうか？
それとも一人だけMicroを契約しておけばよいのでしょうか？
すみませんが、教えていただけると助かります。
- 98 名前：デフォルトの名無しさん mailto:sage [2012/10/16(火) 21:30:24.20 ]
- >>94
書いてあるのが読めんのにやってるんかい？
ログはピンきりだからね、読めなくても、何とかなるんだよ
- 99 名前：デフォルトの名無しさん mailto:sage [2012/10/16(火) 22:17:21.94 ]
- ターミナルでプロジェクトのgitいじってる時に、
現在地/...../...../目的ファイル
なんかをいじりたい時って、効率良くいじれる方法ないですか？
vi 現在地/...../....../目的ファイル ってするのは結構面倒なんです
- 100 名前：デフォルトの名無しさん mailto:sage [2012/10/16(火) 22:28:16.66 ]
- >>99
cd 現在地/...../...../
- 101 名前：デフォルトの名無しさん mailto:sage [2012/10/16(火) 22:47:21.98 ]
- 目的のファイルの位置毎にターミナル開いてみたら
- 102 名前：デフォルトの名無しさん mailto:sage [2012/10/16(火) 22:52:41.41 ]
- viが面倒ならemacsを使えばいいじゃない
- 103 名前：デフォルトの名無しさん mailto:sage [2012/10/16(火) 22:54:12.91 ]
- 馬鹿には無理
- 104 名前：デフォルトの名無しさん mailto:sage [2012/10/16(火) 22:54:54.47 ]
- find . -name hoge|xargs editor
emacs開きっぱなしだから、最初以外は近くのバッファから辿るけど。
- 105 名前：デフォルトの名無しさん mailto:sage [2012/10/16(火) 23:38:01.32 ]
- >>99
~/.gitconfig に
[alias]
vi = "!f() { vi "$(git ls-files "\\*$1\\*" | head -10)"; }; f"
って書いて
$ git vi 目的ファイル
- 106 名前：デフォルトの名無しさん mailto:sage [2012/10/16(火) 23:52:44.79 ]
- >>105
目的ファイルのファイル名全部入力するの面倒じゃんｗ
zsh辺りなら、リポジトリ内の目的ファイルの頭何文字か入力すれば、
リポジトリ全体から探して途中のディレクトリを補間してくれるとかできないのかね？
まあ俺はemacsのdiredに頼りっぱなしだから使わないがｗ
- 107 名前：デフォルトの名無しさん mailto:sage [2012/10/17(水) 00:25:00.99 ]
- >>106
$ git lv 的ファイ
でもいけるよ
- 108 名前：107 mailto:sage [2012/10/17(水) 00:27:30.81 ]
- >>107
s/lv/vi/
- 109 名前：デフォルトの名無しさん mailto:sage [2012/10/17(水) 00:33:28.94 ]
- >>107-108
どこまで入力したら目的のファイルを一発で開けるかわかりにくいじゃないｗ
まあでも、全部入力しても同じファイル名が複数ある可能性もあるのか
viならいっぱい開いてから:nとかで選べばいいしね
- 110 名前：デフォルトの名無しさん mailto:sage [2012/10/17(水) 01:35:29.58 ]
- >>105
おお、これは面白いな！自分のにも入れとこう。
- 111 名前：デフォルトの名無しさん mailto:sage [2012/10/17(水) 02:04:58.95 ]
- だからそれがめんどいんだって
current/1/2/object1
current/1/3/object2
current/4/5/object3
とかなってたらややこいだろ
- 112 名前：デフォルトの名無しさん mailto:sage [2012/10/17(水) 02:09:42.96 ]
- あすまん 100までしかみてなかったわ
- 113 名前：デフォルトの名無しさん mailto:sage [2012/10/17(水) 02:11:22.65 ]
- >>106
Vimのctrlp.vimなら…おっと、スレチなのでこの辺で。
ttp://toro.2ch.net/test/read.cgi/unix/1342368545/
- 114 名前：デフォルトの名無しさん mailto:sage [2012/10/17(水) 02:15:14.38 ]
- >>111
その場合だと>>105の使うならばそれぞれ、
git vi 2/o
git vi 3/o
git vi 5/o
で開けるなｗ
- 115 名前：デフォルトの名無しさん mailto:sage [2012/10/17(水) 14:11:42.17 ]
- >>97
ひとりだけ契約して、あとはcontributerとして登録すればよいです。
- 116 名前：デフォルトの名無しさん [2012/10/19(金) 02:12:22.90 ]
- リファクタリングに対するコミットってどうやってますか？
一般的にリファクタリングはミスが起きないように
一歩づつ変更すると思います。
fooをbarに変更、
barのメソッドをスーパークラスに移動
引数の順番を変更。
引数をオブジェクトに変更
etc
この一連のリファクタリング作業を一回のコミットで行うと、
変更点が多すぎてレビューが大変になると思います。
しかし一つづつのコミットに分けるのも多すぎな気がします。
できれば、一連の操作を1つのコミットの中で
動画のように再生可能な形でコミットできればと思うのですが。
- 117 名前：デフォルトの名無しさん mailto:sage [2012/10/19(金) 05:35:03.08 ]
- 一つづつコミットしておいて、
レビューが終わったらrebaseしたらいいじゃん
- 118 名前：デフォルトの名無しさん mailto:sage [2012/10/19(金) 06:46:33.39 ]
- 一つづつのコミットが多すぎ？なぜ？
各変更点はなるべく小さいほうが、Regressionが見つけやすいんじゃね
- 119 名前：デフォルトの名無しさん mailto:sage [2012/10/19(金) 09:25:12.66 ]
- rebaseってそういうときに使うのか？違うだろ？
- 120 名前：デフォルトの名無しさん mailto:sage [2012/10/19(金) 09:52:05.58 ]
- rebaseはいろんなことに使える
自分のコミットをFast-forward状態にするためのrebaseはもちろん便利だけど、
ベースを変更しないrebaseでのコミットの整理も便利だよ
コミットをまとめたり逆にコミットをばらしたりさらにはコミットの順番を入れ替えたりとか
- 121 名前：デフォルトの名無しさん mailto:sage [2012/10/19(金) 10:02:12.78 ]
- >>116
リファクタリング用にブランチ切って最終的にmerge --no-ff
- 122 名前：デフォルトの名無しさん mailto:sage [2012/10/19(金) 10:05:50.75 ]
- うちはレビューのためにわざわざ分割する事はないけど、
レビュー後 merge --squash か rebase -i は使うな。
レビュー反映のコミットも追加されるしね。
|
 |
