Git 15©2ch.net

2017/02/05(日) 05:22:15.65

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - Fast Version Control System
http://git-scm.com/

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

◆前スレ
Git 13
http://echo.2ch.net/test/read.cgi/tech/1439563364/
Git 14
http://echo.2ch.net/test/read.cgi/tech/1457412803/

VIPQ2_EXTDAT: default:vvv:1000:512:----: EXT was configured

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 11:38:22.96

>>8
なるほどと思ったが
cherry-pickは操作後の動作が保証できない
mergeなら操作後の動作が保証できる。完全ではないがcherry-pickよりまし
なのでmergeのほうが優れている

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 15:36:17.78

>>10
masterブランチにcommitしまくるからそうなる
最初に開発ブランチ作れ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 17:10:20.00

>>12
あっ、そういうのはいいんで、rebaseを含めブランチの履歴を整理する分かりやすいワークフローがあったら教えて下さい

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 19:40:31.54

最強の整理整頓術はそもそもモノを増やさないことだってのは全く間違ってないと思う
ブランチ整理って何がしたいのか分からんけど、successful git branching modelでも参考にしたらええんちゃうの

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 22:22:54.22

>>11
> cherry-pickは操作後の動作が保証できない

何を言ってるんだ？
cherry-pickはあるコミットを持ってくるというだけの機能で
cherry-pickしたあとの動作なんて最初から何も保証してないんだが

保証できないんじゃなくて、保証してない
だからrebaseして、そのcherry-pickしたコミットが正しく動くようにするんだよ

ちなみに、そもそもなんでcherry-pickして動かなくなるのかといえば
こまめなrebaseをしてないから。例えばコミットに対する修正を別コミットに
していたりするとそうなる。こまめにrebaseして意味のある単位にコミットを
修正していれば他人が読んだときのレビューも楽になるし、再利用もしやすくなる

> mergeなら操作後の動作が保証できる

mergeはブランチ全てをマージするものであってそもそも使うべきところが違う。
ブランチの中の1コミットだけを抜き取りたいときにmergeではできない
（できないからmergeの方が劣ってるとでも？ｗ）

使い方が違うだけの話でどちらかが優れているとか劣っているとかいう話じゃない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 22:48:05.72

>>13
> あっ、そういうのはいいんで、rebaseを含めブランチの履歴を整理する分かりやすいワークフローがあったら教えて下さい

簡単に言えば、こまめなコミット、こまめなrebaseだよ
有名なオープンソースソフト（例git）のコミットログを眺めてみればいい
あれが目標とすべきコミット

眺めてみればいいといったが、コミットログっていうのは読むものなんだよ。
後から読むこともあるしレビューのときに読むこともある。だから可読性が必要

じゃあコミットの可読性はどうやればあげられるかというと
意味がある単位で小さくまとまめること

例えば試行錯誤した形跡を表しているようなコミットを持ってこられたって
ここバグってる？すぐあとのコミットで修正されてるやーんとなって時間を無駄に費やするだけ
かと言って複数のコミットを全部まとめてしまったら量が多くなりすぎる

では意味がある単位で小さくまとめる（＝ワークフロー）にはどうするかとうと
まず開発中は小さくコミットしていく。大きな単位でコミットしてしまうと後で分けるのが大変になるから。
そして開発中はこまめにrebaseする。他の人にとって知りたいのは結果であって過程じゃない。
プルリク出すときには、最初から間違いなく作業しましたよっていう状態にして置かなければいけない。

rebaseが下手な人はコミットも大きくなって、いろんな修正を混ぜてしまう。
そういうことをするからrebaseするとコンフリクトまで起きてしまう。
コミットを小さくしていれば驚くほど簡単にrebaseができてしまう。
だからこまめなrebaseも苦にならない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/08(水) 23:13:58.04

最初から意味がある単位で小さくまとめるのが理想だけど、
後からブランチの履歴を整理する手段も色々ある。

gitでアレを元に戻す108の方法
http://labs.timedia.co.jp/2011/08/git-undo-999.html
Gitでやらかした時に使える19個の奥義
http://qiita.com/muran001/items/dea2bbbaea1260098051

**デフォルトの名無しさん** (ｱｳｱｳｶｰ) · 2017/02/09(木) 08:27:12.93

git(hub)-flow

**デフォルトの名無しさん** (ｴｰｲﾓ) · 2017/02/13(月) 10:17:21.25

git mvしないでmvしちゃったんですけどgit addしたらrename扱いになってました
絶対にgit mvしなくてもgit画面どう見てくれるから問題ないってことですか？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/13(月) 10:39:40.22

>>19
中身を書き換える前ならわりと追ってくれる
どこまで追ってくれるか試すと楽しいぞ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/13(月) 15:13:09.61

改行コード変わるだけで別ファイルになるけどな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/17(金) 09:56:23.44

毎日仕事が終わったら、その日作ったソースコードを
gitサーバーにコミットして帰宅する俺。

**デフォルトの名無しさん** (ﾜｲﾓﾏｰ) · 2017/02/18(土) 01:13:13.92

コミットして帰ると次の日休んだ時にビルドが通らないと呼び出し喰らうパターンだな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/18(土) 01:21:39.27

>>22
プッシュじゃなくて？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/18(土) 01:58:54.36

>>24
ごめん、プッシュね。

マネジャーの人が俺らの作業をチェックしたいらしくて、
毎日帰るときにみんなプッシュしてから帰宅する。
svn時代と変わらない。

2017/02/18(土) 02:04:19.48

細かくコミットしていくことを心掛けたいが、気付くとコミットを忘れて突っ走ってしまう
そんな馬鹿野郎におすすめのツールとか運用とかないですか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/18(土) 03:06:20.95

>>26
突っ走った後にgit add -p 使って複数のコミットを作る

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/18(土) 11:33:38.07

>>26
一定時間ごとに自動でコミット、プッシュするスクリプトがあったと思う

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/18(土) 13:22:21.19

>>28
そんなことするぐらいなら、
一定時間ごとに「コミットしろよ」って通知出すほうが良いわなｗ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/19(日) 22:56:47.13

cron 書けとしか言いようがない。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/22(水) 00:19:55.01

エディタに自動保存機能なけりゃ編集内容はメモリ上にしかないからどのみち死ぬ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/22(水) 15:40:38.57

>>31
数分おきにエディタに :wq! を送るスクリプトを作ろう

**デフォルトの名無しさん** (JP) · 2017/02/22(水) 15:45:05.02

意味のある区切りじゃない自動保存などゴミ

**デフォルトの名無しさん** (ｱｳｱｳｶｰ) · 2017/02/22(水) 16:51:00.38

そもそもコミットは成果毎に行うのであって細かくすればいいというものではない

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/22(水) 19:13:30.90

プレーンテキストとかワープロとかならともかく、ソースコードだったらコンパイルするためにどんどん保存してるんだから自動保存ってそこまで必要性高いものでもなくない？

2017/02/22(水) 19:54:40.37

コミットと保存の話が混ざって混沌としてきてる

**デフォルトの名無しさん** (ｱｳｱｳｶｰ) · 2017/02/22(水) 20:45:47.20

個人開発なら単なる履歴残しに使ってもいいがチームの場合はそれじゃ困るんだよね

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/23(木) 01:11:00.83

ショートカットキーctrl+Sで保存は便利でよく使う
履歴残し程度なら同様にショートカットキーで保存とコミットができるようにエディタにスクリプト組み込めばＯＫ
初回ショートカットキーで一時作業用ブランチを切らせて
一通り終わったなら別のショートカットキーでsquashなりでまとめてからコミットメッセージ入力窓でも出してから本来の作業用ブランチにFFマージさせればおｋ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/23(木) 10:00:04.78

>>37
チームの場合はgitは個人で自由に使わせておいて
チーム側では集約にsvnを使うよね

2017/02/23(木) 16:27:13.03

>>39
ない

svnで運用された頭が痛くなるような履歴をgitに取り込むことはよくある

2017/02/23(木) 20:55:38.64

チーム毎にgit使って、各チームの成果をインテグした時にsvn使う事はある
個人でgit、チームでsvnって構成はgitの美味しさの大部分を潰してるように見えるけど、想定してる規模が分からんし何とも言えんか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/24(金) 14:06:29.60

SHA1の衝突がGoogleによって公開、gitにも言及
https://shattered.it/

それに対するLinusの見解
http://marc.info/?l=git&;m=148787047422954

**デフォルトの名無しさん** (JP) · 2017/02/24(金) 14:11:42.95

hashの衝突は元から想定済っしょ
そもそも5桁でちぎって管理()してるんだし

2017/02/24(金) 15:11:29.62

想定はしてないでしょ、無理矢理衝突させたらリポジトリ壊れたって書いてるし
http://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/24(金) 16:02:16.98

>>43
5桁でちぎって管理ってなんのこと？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/25(土) 10:54:33.01

v2.12.0

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/25(土) 11:32:01.15

>>46
何か面白い機能追加された？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/27(月) 04:28:34.00

Linusの公式コメント
https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/02/27(月) 13:29:26.47

SHA1衝突なんか怖かねーぜバーカ！
ってこと？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/01(水) 00:08:39.88

ファイル数が20万～30万個あるプロジェクトをgitで管理できる？
git statusすると20万～30万の全部のファイルの更新日チェックするの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/01(水) 01:39:05.95

gitで管理できなかったら、他の何を使っても出来ないと思うｗ
管理せずにファイル置いとくだけならできるだろうけど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/01(水) 05:02:00.38

>>51
きも

**デフォルトの名無しさん** (ｵｯﾍﾟｹ) · 2017/03/01(水) 12:18:24.07

俺も思った

**デフォルトの名無しさん** (ｱｳｱｳｶｰ) · 2017/03/01(水) 12:52:10.72

>>50
それくらいなら全然大丈夫だよー

**デフォルトの名無しさん** (JP) · 2017/03/02(木) 19:24:50.56

>>50
人間よりは速い

**デフォルトの名無しさん** (ｽﾌﾟﾌﾟ) · 2017/03/02(木) 23:03:10.15

gitを使うのが目的になってる奴がいるな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/02(木) 23:06:07.56

gitを使うのが目的じゃないけど結果的にgitを使ってるな

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/02(木) 23:30:35.54

gitを使ってるカッコいい俺

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/02(木) 23:31:43.91

普通じゃ？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/02(木) 23:36:40.95

gitの使い方を覚えられないおっさんも世の中には居るんだ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/02(木) 23:42:40.19

使える人が使わないなら、それはいいんだよ。

能力不足で使えない（＝無能すぎる）
会社のしがらみで使えない（＝かわいそう）

あと使って見てないやつもダメだな

**デフォルトの名無しさん** (ｽﾌﾟｯｯ) · 2017/03/03(金) 11:58:15.68

Gitが使えない外注イラネ

**デフォルトの名無しさん** (JP) · 2017/03/03(金) 12:30:04.87

篩に使うのはありか

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/03(金) 21:00:59.00

なんでもいいから自分のソースくらい自分でコミットしろ。

**デフォルトの名無しさん** (ｽﾌﾟﾌﾟ) · 2017/03/03(金) 21:35:27.51

本当になんでもいいの？

2017/03/03(金) 23:39:23.71

masterにコミットしていいの？

2017/03/04(土) 00:19:50.00

結果にコミットしていいの？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 00:59:09.29

面倒臭いのでだいたい
git add .
git commit --amend -m "hoge"

で済ましてる
一通り終わったらgit commit --amendでコミットメッセージちゃんと書く
squashしなくてよい方法だよ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 03:38:59.15

Git - 高度なマージ手法
https://git-scm.com/book/ja/v2/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-%E9%AB%98%E5%BA%A6%E3%81%AA%E3%83%9E%E3%83%BC%E3%82%B8%E6%89%8B%E6%B3%95

これいいね

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 11:03:44.63

git merge --abort
git rebase --abort

これいいよな。

svnとかだとやらかしてしまって中途半端な状態になって
これどうすりゃいいんだよってなってしまうけど、
gitだとたいてい--abortすればリセットできる

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 14:23:44.15

AにコミットしてA'
A'にコミットしてA''
になってるとき
A'をBに名前変えて
A->A''と
A->Bに分けることはできますか？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 15:02:21.59

git checkout 好きなコミットID

ブランチ名なんて最新のコミットに名前つけてるだけであって
コミットIDで全て参照できる

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 17:15:35.10

A->A''の方にはB(A')が無かったことにしたいのですが

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 17:34:49.80

説明がわかりにくすぎだろw
pushしてればrevertで
してなければrebase -iで

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/04(土) 21:55:14.48

cherrypickでA''からAにパッチ当てりゃいいだけじゃね？

**デフォルトの名無しさん** (ｽﾌﾟｯｯ) · 2017/03/04(土) 22:05:36.70

>>71
git branch B A'
をする
git rebase A -i
でA'の行を消す

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/06(月) 23:20:15.96

ディレクトリやファイルをマージするだけの作業だが、あまりに大量&1日あたりの作業時間があまり取れないため、1ヶ月ぐらいかかる見込み

こう言う場合って作業完了してからまとめてコミットすべき？
それともキリのいいところでコミットすべき？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/06(月) 23:34:33.58

適当にコミットしていって後で纏めたくなったらrebase -iすればいいんじゃね

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/07(火) 15:02:30.70

rebaseは甘え。使ってはいけない。

**デフォルトの名無しさん** (ﾄﾞｺｸﾞﾛ) · 2017/03/07(火) 18:29:12.37

せっかくローカルにあるんだし、どんどんコミットしたら？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/07(火) 19:25:45.74

rebase使っても実は隠しコマンドのrerebase使えばまた元に戻るから大丈夫

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/07(火) 20:49:12.26

rerebaseだと!?

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/07(火) 20:55:44.46

rebase怖いならブランチ切るなりタグつけるなりしてからrebaseすりゃいいじゃん
rebaseしたってコミットそのものが世界からすぐに消えるわけじゃないんだし

**デフォルトの名無しさん** (ｴｰｲﾓ) · 2017/03/07(火) 22:48:44.65

git cloneで特定のタグから最新のコミットまでの範囲を取得する方法を教えてください

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/08(水) 00:28:53.24

> rebase怖いならブランチ切るなりタグつけるなりして

そのブランチやタグを作るのが面倒なバージョン管理ツールがありまして、
そのせいでブランチやタグを切るのが嫌なんですよ。

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/08(水) 01:12:08.47

知らんがな

**デフォルトの名無しさん** (ﾄﾞｺｸﾞﾛ) · 2017/03/08(水) 08:51:03.76

ローカルだけブランチ作ればいいだろ。他のツールはスレ違い。

**デフォルトの名無しさん** (ｴｰｲﾓ) · 2017/03/08(水) 18:56:28.23

(1)git checkout -b hoge コミットID1 でhogeブランチを作る
(2)masterブランチに戻る
(3)git branch -D hoge でhogeブランチを削除する
(4)git checkout -b hoge コミットID2 で異なるコミットのhogeブランチを作る

hogeブランチでは何かを編集したりするわけではないので
hogeブランチにいたまま別のコミットIDでhogeブランチを上書き？する方法ありませんか？
masterブランチに戻ってからhogeブランチを作りなおして新たに作るのが面倒くさいので

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/08(水) 19:57:59.67

git reset --hard コミットID2

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/09(木) 06:48:45.74

>>88
コミットIDでcheckoutすりゃいいだけじゃね

(1)git checkout コミットID1
(2)git checkout コミットID2

**デフォルトの名無しさん** (ｽﾌﾟｯｯ) · 2017/03/09(木) 08:26:50.81

>>88
git reset --hardは、ブランチの付け先を簡単に操作できてしまうから、使う前にreflogの見方を覚えておくこと

**デフォルトの名無しさん** (ﾄﾞｺｸﾞﾛ) · 2017/03/09(木) 08:37:37.52

>>82
リ・リ・リベース
アホデミー賞を総なめ

**デフォルトの名無しさん** (ｴｰｲﾓ) · 2017/03/09(木) 10:28:24.13

resetは困ります。。。。
checkoutでどうにかやる方法はないということでしょうか？

**88=93** (ｴｰｲﾓ) · 2017/03/09(木) 10:29:17.80

ブランチは１個しか作りたくないんです

**デフォルトの名無しさん** (ｽﾌﾟｯｯ) · 2017/03/09(木) 12:31:57.97

>>93
じゃあ>>90で良いんじゃないの？
コミットは出来ないけど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/09(木) 13:13:36.94

>>88
git checkout hoge
git merge <commit>

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/09(木) 13:42:24.50

>>93
なんでreset困るの？ブランチ消してる時点で同じことだと思うけど
resetしたってコミットが消えるわけじゃないよ

**88=93** (ｴｰｲﾓ) · 2017/03/09(木) 22:57:50.27

git checkout -b hoge
git reset --hard コミットid1
git reset --hard HEAD@{1}
masterブランチには何の影響もないですね
最新のコミットに戻るときにreflogで位置を確認するのが面倒くさそうです
これも覚えておきます

>>96
mergeだと古いコミットに戻ろうとした時にAlready up-to-date.って表示されてしまいました

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/09(木) 23:15:12.39

hogeにはすでにコミット1やコミット2が含まれてる場合もあって
その場合はそれ以降のコミットを捨てた状態にしたいってことなの！？
用途が謎

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 03:45:25.28

>>98
ブランチは1個しか作りたくない理由がわからないから、それだったらID1とID2に別のブランチを付けたら良いんじゃない？って思っちゃうんだけど
何で作りたくないんですか？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 04:41:26.50

>>90のやり方がスルーされるからやりたいことと違うんだろうなあ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 14:48:19.74

タグの代わりなんじゃ？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 21:15:08.71

みんなってさ、ステージングしているファイルから行単位とかでコミットしたり
する機能使ってる？

俺はファイル単位でしかコミットとかしないんだけどさ、そもそもステージング
してるところから行単位でまた編集するようなもんだから、テスト通るかわからなく
なるわけだし、あんまり積極的に使うもんじゃないよね。

あとdiffの結果画面の見方が今ひとつ苦手w

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 21:48:11.92

>>103
使わんなー

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 21:51:35.65

>>103
細かいけど、行単位でステージングする機能、じゃなくて、ステージングした段階から行単位でコミットする機能ってある？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 22:13:50.48

git add -p のこと？
ならすげー使うけど

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 22:28:17.98

git add -pの存在がsvnからの移行を決定づけた

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 22:51:42.82

俺もよく使うな。

gitの便利さっていうのは現実的な問題を解決してることにあると思っていて、
理想は最初に計画を立てて間違えることなく作業をすることだけど
現実にはいろんな細かい修正を忘れたり分けるべき修正を一緒にやってしまったりするでしょ？

そういう時に俺は、いま修正している中で、特定の部分だけgit add -pつかって
一つのコミットにして、あとの分は別コミットにして、
テストは後から書いてrebaseしてまとめるとかやるよ。

他の人が理解・レビューしやすい並びのコミットと、
実際の開発順っていうのは必ずしも一致しないからさ

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/10(金) 23:30:38.30

git add -pなら使う。行単位でステージングする機能、だよね？

**デフォルトの名無しさん** (ﾜｯﾁｮｲ) · 2017/03/11(土) 06:24:50.89

>>108
SVN 使いだけどこの機能とローカルコミットはマジで欲しい

**デフォルトの名無しさん** (JP) · 2017/03/11(土) 10:36:14.71

>>110
gitに乗り換えても良いんですよ？