[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2ch.scのread.cgiへ]
Update time : 12/19 22:47 / Filesize : 316 KB / Number-of Response : 998
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Git 12



1 名前:デフォルトの名無しさん mailto:ageteoff [2015/03/23(月) 13:35:13.83 ID:aBYp+bVs.net]
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

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

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

◆前スレ
Git 11
peace.2ch.net/test/read.cgi/tech/1416195050/

560 名前:デフォルトの名無しさん mailto:sage [2015/05/27(水) 12:17:18.05 ID:98FdFg1V.net]
Git 2.4.2
https://github.com/git/git/releases/tag/v2.4.2

561 名前:デフォルトの名無しさん mailto:sage [2015/05/31(日) 20:55:03.14 ID:2hiQrePQ.net]
特定のファイルを特定の履歴に戻すのはどうやるんでしょうか?
a.txtをHEAD@{12}のa.txtの内容にしたいんです
git reset HEAD@{12} a.txtじゃ戻りませんでした

562 名前:デフォルトの名無しさん mailto:sage [2015/05/31(日) 21:23:55.63 ID:q0XD6tk+.net]
checkoutせよ

563 名前:デフォルトの名無しさん mailto:sage [2015/06/01(月) 22:34:02.79 ID:6w2KJtLO.net]
git init
git add -A
このaddを取り消したいんですがgit reset HEADをやると
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
ってでます
git add -Aで変更をインデックスに追加されているわけだからHEADを指定したらリセットできると思ったんですが何で出来ないんですか?

564 名前:デフォルトの名無しさん mailto:sage [2015/06/01(月) 22:37:39.31 ID:wXX1PCBE.net]
まだHEADに相当するコミットが存在しないから

565 名前:デフォルトの名無しさん mailto:sage [2015/06/01(月) 22:37:41.39 ID:60FC1uF1.net]
1回もコミットしてないとか?

566 名前:デフォルトの名無しさん mailto:sage [2015/06/01(月) 22:43:38.24 ID:wXX1PCBE.net]
おれはそんなとき.gitをざっくり消したりしてたが、
ぐぐると git rm --cached が使えるみたいだな

567 名前:デフォルトの名無しさん mailto:sage [2015/06/02(火) 10:41:16.23 ID:2Bq+WaXR.net]
git rebaseでどこまでまとめるべきなのかわかりません
例えばデータベースの文字コードの設定の修正と、スタイルシートを変更した2点の場合
一緒にまとめたほうがいいんでしょうか?

568 名前:デフォルトの名無しさん mailto:sage [2015/06/02(火) 22:36:32.71 ID:ENh0ws/u.net]
Windows版のバージョンは上がらんのかえ



569 名前:デフォルトの名無しさん mailto:sage [2015/06/02(火) 22:37:29.49 ID:dwjHRJAm.net]
自分でコンパイルしろよ

570 名前:デフォルトの名無しさん mailto:sage [2015/06/02(火) 22:37:35.29 ID:H1H2VilB.net]
>>563
その二つならまとめない。

もし、データベースの文字コードを変更したことによりスタイルシートの変更が必要になったのであればぎりぎりまとめてもいい。

571 名前:デフォルトの名無しさん mailto:sage [2015/06/03(水) 01:22:55.03 ID:knJmPdD6.net]
>>563
そういうgit運用の話は、「管理者の意見に従うべき」

個人用or自分が管理者なら、好きなようにやっていい。

572 名前:デフォルトの名無しさん mailto:sage [2015/06/03(水) 01:42:10.75 ID:3kJPkUc2.net]
>>567
少しは助言してやれよ

573 名前:デフォルトの名無しさん mailto:sage [2015/06/03(水) 03:55:40.59 ID:cOL0IOxC.net]
どのやり方が良いかなんて決まっているわけじゃない
色々試して自分が一番しっくりする形を探すか
最も採用されていると思えるやり方というのを見出してそれを選択するか
有名どころのオープンソースプロジェクトの方針を色々と見てくるといい

574 名前:デフォルトの名無しさん mailto:sage [2015/06/03(水) 05:32:16.44 ID:5OGKD7dq.net]
俺がまとめる基準はそのまとめたコミットに判り易いひとつのタイトルをつけられるかどうかあたり
でも優先されるべきはそのリポジトリの管理方針なのは間違いない

575 名前:デフォルトの名無しさん mailto:sage [2015/06/03(水) 10:17:17.28 ID:qaWpPbOF.net]
ところでpost commit mail送るのに何使ってる?

うちはmultimail使ってるがなんかしっくり来ない

576 名前:デフォルトの名無しさん mailto:sage [2015/06/04(木) 01:27:40.14 ID:FZpfA7xp.net]
>>569
お前はどうやってるんだよ

577 名前:デフォルトの名無しさん mailto:sage [2015/06/04(木) 10:38:54.51 ID:ixdJmRIH.net]
俺は初心者の頃にここでコミットをまとめるなって言ってこのスレを炎上させた初心者+だけどさ
その時はコミットをまとめろって言われたからソースコードのバージョン毎にコミットを全部まとめたよ
一体まとめろ!まとめるな!のこのスレの意見を統一してもらわないと俺みたいな初心者が無駄な道を通ることになる

1. initial commit
---- ここから -----
2. save
3. type
4. ○○実装
5.save
6.○○実装
7.typo
8.ファイル追加
----- ここまでまとめる -------
tagで1.0って付ける

578 名前:デフォルトの名無しさん mailto:sage [2015/06/04(木) 10:43:29.77 ID:lUVfOohh.net]
バージョン毎にまとめろとか誰も言ってないだろ
具体的にそのやりとは何スレ目だよ



579 名前:デフォルトの名無しさん mailto:sage [2015/06/04(木) 10:47:48.34 ID:w41Ky1ux.net]
>>573
「まとめろ」「まとめるな」で意見を統一するのは難しいと思うけど(そもそも状況によってどっちが良いかかわるだろうから)、
どういうときはまとめたほうがよい
どういうときはまとめないほうがよい
というガイドラインのようなものならある程度意見はまとまってきそうだね

580 名前:デフォルトの名無しさん mailto:sage [2015/06/04(木) 13:46:30.21 ID:7Y8AXPNC.net]
後から分離したくならないものはまとめる
要するに、二つのコミットがあった時に、これが二つに分かれてる必要はあるだろうか?と考えればいい

581 名前:デフォルトの名無しさん mailto:sage [2015/06/04(木) 13:49:14.71 ID:5FZxl5co.net]
そうして全てのコミットはひとつになった

582 名前:デフォルトの名無しさん mailto:sage [2015/06/04(木) 16:11:36.89 ID:a/IZmogk.net]
コミットを入れ替えるときにコンフリクトって起きないんですか?
git init
touch README.md
git add README.md
git commit -m "Initial commit"
echo 1 > a.txt
git add a.txt
git commit -m "add a.txt"
echo b1 > b.txt
git add b.txt
git commit -m "add b.txt"
echo a1 > a.txt
git add a.txt
git commit -m "modified a.txt"
git rebase -i HEAD^^^
以下のように並べ替え
pick 06da9a6 add a
pick 2c80b8f modified a
pick 7a6a277 add b
git checkout HEAD^
lsするとbファイルがありません
"modified a"のコミットにはbはないことになるんですか?gitが自動的に面倒見てくれてるんですか?

583 名前:デフォルトの名無しさん mailto:sage [2015/06/04(木) 20:10:10.65 ID:lUVfOohh.net]
Gitでは各コミットがその時点での全ファイルの状態を持ってるけど、
rebaseで並び替えるのはコミットの変更差分(自分の前のコミットとの差分)ってことかな

>>578のrebaseによって、"modified a"コミットのa.txtを変更したという差分だけが"add b.txt"コミットより前の歴史へ移動するので、
"modified a"コミットにbは存在しなくなる

rebase -iでコンフリクトは起こる
例えば>>578の"add a"と"modified a"コミットの順番を逆にしたりすれば

584 名前:デフォルトの名無しさん mailto:sage [2015/06/04(木) 20:23:21.52 ID:69dFu2L0.net]
>>573
正直「そこの管理者の意見に従ってまとめろ」「同僚たちと同じようにまとめろ」って回答しかないな

585 名前:デフォルトの名無しさん mailto:sage [2015/06/04(木) 20:46:29.00 ID:b+4KVUcq.net]
少なくともどの時点でもコンパイル通るようにコミットまとめる
大きくても機能ごとにはコミット分ける
でその間はプロジェクトごとに方針あれば何でも

586 名前:デフォルトの名無しさん mailto:sage [2015/06/06(土) 22:34:59.14 ID:4eOWDqlW.net]
問題は俺自身に経験がないのに
俺がルールを決めなきゃいけない時だな

587 名前:デフォルトの名無しさん mailto:sage [2015/06/06(土) 22:35:56.50 ID:yk/a ]
[ここ壊れてます]

588 名前:5xMg.net mailto: >>573
お前、マージ使ってないだろ?

まず前提として「一つのプロジェクトを複数の人が平行で開発している」という
個人プロジェクト以外のごく普通のプロジェクトの話なんだよ。

よくある間違いが、小さい規模の例だけで考えて、
それがそのまま大きな開発にも適用できちゃうって考えること。
君はその間違いはまってる。

(俺が知ってる)小さい規模ではこれでうまくいくんだ。ではなくて
大きな規模になった時それでうまくいくのか?を考えた方がいい。

適切なやり方というのは、規模によって変わるんだから。
[]
[ここ壊れてます]



589 名前:デフォルトの名無しさん mailto:sage [2015/06/06(土) 22:41:32.51 ID:yk/a5xMg.net]
>>581
問題は1コミットを後から見直すかどうかだよな。

後から見なおさないのであれば、どんなに意味不明な修正でも
同じ所を試行錯誤したコミットでも、何百行あるコミットでも
何十個もあるコミットでも、そのコミットを見ないのであればどうでもいい

でもあとからそのコミットを見るのであれば
修正内容が明確にわかるコミットが必要最低限あった方がいい。

あとからそのコミットを見るかどうかだよ。
もちろん俺はよく見る。
仕事でもその修正が適切であるかを見たり、
オープンソースとかでもある修正内容を見たり
だからコミットは分かりやすくなっていたほうがいいと考える。

590 名前:デフォルトの名無しさん mailto:sage [2015/06/06(土) 22:46:03.75 ID:yk/a5xMg.net]
>>575
> というガイドラインのようなものならある程度意見はまとまってきそうだね

コミットをまとめる or まとめないのが目的じゃないからね。
コミットを綺麗にするのが目的。

当然の話だけどガイドラインには理由が必要だろうね。
まとめる理由が。(もしまとめないのであれば、まとめない理由も)

コミットをまとめたりまとめなかったりして、綺麗にする理由は
簡単にいえば、後からコミットを見た時にわかりやすいように
するためなんだが、もっと細かい理由って必要だろうか?

591 名前:デフォルトの名無しさん mailto:sage [2015/06/06(土) 22:54:18.21 ID:yk/a5xMg.net]
少しだけガイドライン考えてみた


・一つのコミットで複数の修正を行わない
理由 後からそのコミットを見た時何を修正したのかがわからなくなるから

・一つの修正を複数のコミットにわけない(分かれていればまとめる)
理由 後からそのコミットを見た時何を修正したのかがわからなくなるから
例外 リリースしてしまったコミットはまとめることは出来ない。


いま気づいたが、この「リリース」っていう概念が重要だな。
どの時点でリリースになるのかはそれぞれだろうが
master、もしくは共有ブランチににマージされた時点がリリースだと考える。


と考えると、やはり>>573の例ははマージ機能を使ってない時点で
一人で開発している場合にのみ通じる例だから、例としてふさわしくないんだよ。

592 名前:デフォルトの名無しさん mailto:sage [2015/06/06(土) 23:00:59.08 ID:OBriYrAJ.net]
3行で

593 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 00:12:36.70 ID:5CuOmznL.net]
あとから見てわかるようにコミットを綺麗にしておけ
まとめる とか まとめない とかどちらか一方じゃない
どちらもやって、綺麗にしておけ。

594 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 02:04:34.40 ID:VSY66R2E.net]
一つのコミットに入れる一つor複数の修正って、何単位で一つと呼ぶのかって話もあるし、

>>545>>549のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」
って運用ルールでgitを使っている人がいたりするので、抽象的なガイドラインは決めるだけ
無駄ではないか

それを議論したって、自分がブチ上げたガイドラインを弁護し、他人がブチ上げたガイド
ラインの言葉尻を捕まえてロンパするだけの、言葉遊びの世界に入っていってしまう

595 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 02:08:39.07 ID:VSY66R2E.net]
>>582
そういう時は、「なんでgitなんか使わなきゃならないのか」に立ち戻るべきだと思う

596 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 02:48:23.33 ID:5CuOmznL.net]
>>589
> >>545>>549のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」

いないだろw

あぁ、なんで共有ブランチにpushしたコミットは
編集したらだめなのかを書いていなかったね。

物事は単純で、他人の役に立つことをしましょう、
他人の迷惑になることはうやめましょう。これだけだよ。

コミットは他人が見ることを考えれば、そして他人は何故見るのかを考えれば
コミットを綺麗にしておけば可読性が高くなって読む人の負担が減る。
これは他人の役に立つこと。

そして共有ブランチを修正したらだめというのは、他の人も
その共有ブランチから派生して修正しているので、その派生元が変わると
今まで参照していたものが履歴を残さずに変わるわけで何が起こったのかわからなくなるから。
これは他人の迷惑になること。

このように俺のガイドラインにはちゃんと理由がある。
反対のガイドラインを作りたいなら、その理由をいうことだけ。
でないと俺の意見に対抗できない

597 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 02:52:10.94 ID:5CuOmznL.net]
念の為に俺が言ってる「共有ブランチ」の定義を書いておくわ。

俺が言ってる共有ブランチっていうのは、
他の人がそのブランチから作業をする、
または他の人がそのブランチにマージすると
という目的で作られたブランチのこと。

つまり他の人が参照しているだけならば
共有ブランチとは言わない。
参照しているだけならば、そのブランチが変わっても
他の人の作業のじゃまにはならないからね

598 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 02:54:19.37 ID:5CuOmznL.net]
ということで、何故そうするのか、どんなメリットがあるのかを
しっかりと書いたガイドラインを、俺以外に出すのまってま〜すw



599 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 10:11:47.35 ID:V49LqTdE.net]
>>591
>いないだろw

いや、>>545が「共有ブランチ上のコミットを書き換えるんだとしたら」と言ったのに対して
>>549が「そうだよ」と返しているので、いること自体は確かなようだ

545に対して、あなたがどうロンパするかは別に知らないが

600 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 10:31:51.05 ID:V49LqTdE.net]
>>583-584
全部のコミットをひとつにまとめて周りから怒られなかったなら、
それは正しいまとめ方だったと思うんだけどね

601 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 12:19:13.74 ID:5CuOmznL.net]
>>594

> 545に対して、あなたがどうロンパするかは別に知らないが

論破? 何故そうするかの理由がないのだから、
まずその理由を言うのが先だろうw

602 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 12:20:45.23 ID:5CuOmznL.net]
>>595
> 全部のコミットをひとつにまとめて周りから怒られなかったなら、

周りの人間がコードを見るということを知らないだけかもしれない。
スキルが低くてソースコード管理ツールすら知らない人もいるのだから。

だからそれは全く参考にならないな。


理由だよ理由。

俺は何故そうするかの理由を書いた。
この俺を論破する理由をかける奴はいないのか?w

603 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 12:21:31.63 ID:yxti539q.net]
誰か運用スレ立ててくれない

604 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 12:52:14.95 ID:V49LqTdE.net]
結局は>>589の言ったとおりになるという、悲しい現実

>>598
運用スレを建てても、荒らしがそこに移動するかどうかは別問題だと思う

605 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:04:07.08 ID:yxti539q.net]
運用スレ行けと言えるようになるだけ幾分マシかと

606 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:08:53.36 ID:V49LqTdE.net]
>>600
なるほどそうかもしれないね
そういう意味だと、既存だとここあたりが適切なのかな

バージョン管理システムについて語るスレ10
peace.2ch.net/test/read.cgi/tech/1393147031/

607 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:12:32.75 ID:5CuOmznL.net]
>>599
> 結局は>>589の言ったとおりになるという、悲しい現実

大丈夫。

俺が言った「ガイドラインを言う時は理由も明確書くこと」
のおかげで、今のところガイドラインは俺が言った一つしかでてない。

608 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:17:04.64 ID:yxti539q.net]
>>601
ここでされてるの横断的でない個別的な内容だからスレチ



609 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:18:47.22 ID:V49LqTdE.net]
>>603
そっか、じゃあ新スレがいるか・・・

610 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:23:17.32 ID:V49LqTdE.net]
>>602
>今のところガイドラインは俺が言った一つしかでてない。

そりゃ出ないでしょ
誰も関わりたくないんだから

611 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:26:15.60 ID:5CuOmznL.net]
>>604
スレ立てておいたよ。

Gitをより良くするための運用ガイドライン作成スレ [転載禁止](c)2ch.net
peace.2ch.net/test/read.cgi/tech/1433650988/


>>605
> 誰も関わりたくないんだから
関わりたくないのが理由っていうのはおかしな話だな(笑)

言い返せない時に汎用的に使えそうな言い訳だ。

612 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:31:19.54 ID:V49LqTdE.net]
>>606
ありがとう
じゃあここから先は、ここで運用系の話をするのはスレ違いってことで、
あとはそっちでやってもらおう

613 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 13:42:31.68 ID:yxti539q.net]
>>606
タイトルを単にGit運用スレにできないあたり自己顕示欲あふれるスレタイですね

614 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 15:41:57.12 ID:D5MO+jlJ.net]
立てたら立てたで文句言う奴 w

615 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 16:06:00.04 ID:D+Qsqenv6]
はじめまして。 質問させてください。

とあるリポジトリに以下のようなブランチがあります。
・master 特に進んでない
・masterから作成したブランチA 最初のほうだけ開発
・ブランチAから作成したブランチB あらかた開発
・ブランチBから作成したブランチC テストコード開発

masterとAは他人が作ったもので、
私はそれを引き継ぐ形でBで開発していました。
そこからCでテストコードを作ることになり、
一応終わったのでBにプルリクを出したところ少しのやり取りののちマージされました。
そのあとで不具合に気がついたのでまたコミットをしたいのですが、
この時`git checkout`でBに移動してから行うべきでしょうか?
それともそのまま行ってもよいのでしょうか?

CがマージされたBに続く形にしたいのですが、
Bで`git status`すると"Aより104コミット進んでいるから`git push`使って公開して"というような英文があり、
同様にCで行うと"Bより16コミット進んでいるから`git push`使って公開して"というような英文があるので、
言われたとおりにpushしたらコミットはどうなるのでしょう?
Cを作るときにpush漏れはないですし、Cがマージされた時も同様にないのですが。

616 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 18:26:22.23 ID:5CuOmznL.net]
いるいるw

617 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 18:53:47.38 ID:V49LqTdE.net]
>>608
荒らしが自分で建てたスレなんだから、そうなるのはしょうがない
運用の話はそっちでやってもらいましょう

618 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 19:53:48.87 ID:yxti539q.net]
自分で立てたスレなんだからもちろん自分は引っ越して誘導もするんですよね
期待してますよ



619 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 20:06:44.60 ID:5CuOmznL.net]
>>613
はい当然です。 Gitの運用方法に関するレスは全部向こうに移動します。
みなさんも協力してくださいね。

逆に運用以外の雑多な内容はこっちに移動しますよ。

620 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 21:10:56.78 ID:V49LqTdE.net]
>>613
おみごと

621 名前:連続書込しすぎなのでID変えます mailto:sage [2015/06/07(日) 21:22:11.43 ID:rs3gN1uE.net]
このスレから運用に関することをなくしたら
どれだけのレスが残るか期待ですw

ぜーんぶかっさらっていきますよーw

622 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 21:49:02.86 ID:HSoSL4U1.net]
git とうまく組み合わせられるような
バグトラッキングツールでおすすめのはある?
mantisってもう人気無い?

623 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 21:52:12.28 ID:V49LqTdE.net]
これでツールの質問ができるようになるのか、
または、ツールの質問に答えられる人なんて初めからいなかったのかがハッキリするな

どっちにしても平和になってよかった

624 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 21:57:36.23 ID:/P0faz6I.net]
Egitで、amendじゃなくてもっと過去のコミットを編集するには
画面上でどういう操作をすればいいんでしょうか?

625 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:03:03.72 ID:rs3gN1uE.net]
githubの使い方を教えて下さい。

626 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:13:31.59 ID:rs3gN1uE.net]
>>619
よめ

◆関連サイト
Pro Git - Table of Contents
git-scm.com/book/ja

627 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:14:24.04 ID:rs3gN1uE.net]
WindowsでGUIでgitを使いたいです。
なんか良いツール無いですか?

628 名前:616 mailto:sage [2015/06/07(日) 22:16:23.46 ID:rs3gN1uE.net]
>>619
すまんすまん。EGitっていう名前のツールがあるのか。
ならこのスレだ。



629 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:16:39.42 ID:UKZkpptu.net]
>>619
そんなのIDEの機能に頼るより、そのコミットを修正するコミットを作った後に
コマンドラインからrebase -iで順番入れ替えてsquashしたほうが簡単じゃないか?

630 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:17:04.27 ID:/P0faz6I.net]
>>621
目次にどこにもEgitの話が出てないんですけど、どこに載ってるんですか?

631 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:18:17.74 ID:/P0faz6I.net]
>>624
Eclipse上で開発してるので、自分はEgitの方が楽です

632 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:41:10.16 ID:UKZkpptu.net]
>>626
おれが使ってるのはIntelliJ IDEAだけど、Git関連は全部GUIでやるよりコマンドラインも併用したほうがいろいろ楽
ちなみにIntelliJ IDEAではrebase -iもGUIで出来るんで試しにやってみたけど、
思ったほどじゃないけどちょっと面倒

EGitもEGit rebaseでぐぐれば手順説明がいろいろ見つかるな
一応できるみたいだよ
Rebase Interactiveとかあるらしい

633 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:44:07.71 ID:/P0faz6I.net]
>>627
で、そのやり方を知りたいわけです

634 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:44:51.36 ID:rs3gN1uE.net]
>>626
いやいや違う。Egitの方が楽というのは言い訳だ。
楽というのは事実だろう。だがそれはCLIで
gitを使えないことの理由にはなっていない。

はっきり言おう。君はCLIでgitを使えないだけだ。
それはEgitが楽という事実とは無関係だ。

CLIでgitを使えるようになったほうがいいよ。
そうすればEgit+CLIのコマンドで検索すれば簡単に見つかる。

>>623で訂正したが、やっぱり君が読むべきものはPro Gitだ。
GUIツールの機能はCLIを使える知識がなければ理解できないだろう。
いくつか使ってみたが、どれもいきなりCLIのコマンド相当のものがメニューにあるから
初めて使う人は「この機能なにをするものなんだ?」ってなるだろう。

で、CLIのコマンドを知らない人でも簡単に理解できるGUIツール無い?
プログラマーではないウェブデザイナー(HTMLとかCSSを書く人)にも
使ってほしいと考えてるんだけど。

635 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:46:34.98 ID:UKZkpptu.net]
>>628
だからEclipseで普通にコミットを作ってRebase Interactiveしろよ
amendは知ってるんだから普通にコミットを作るのはできるんだろ?

636 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:49:18.28 ID:/P0faz6I.net]
>>630
コミットは作れるんですが、Egit上での対話的リベースの使い方が分からないんですよね・・・

637 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:51:21.60 ID:UKZkpptu.net]
>>631
ヒストリーのコミットで右クリックすりゃRebase interactiveがあるらしいぞ

638 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 22:52:20.19 ID:/P0faz6I.net]
>>632
そこまでは分かるんですが、そのあとの操作の仕方が・・・



639 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:03:17.96 ID:rs3gN1uE.net]
たいていのツールはGUIはCLIの使い方を知らなくても使えるものなんだが、
バージョン管理ツールをGUIにしても使いにくいのは
ソースコードを管理するということの意味がわからないからだろうな。

例えばペイントソフトは、そのツールを使う前から
絵を書いたことがある。それと同じことをツールを使ってやるだけ

でもソースコードを管理ツールは、そのツールを使う前にそのツールと同じことをやっていない。
ソースコードを修正している人であっても、ソースコードを管理していない。
(※バックアップはソースコードの管理じゃない)

だからそれをGUIにしたところで、何をするのかわけがわからない機能ばかりで
使い方がわからない。(もしくはバックアップという間違った用途に使うだけ)

ふぅ。そういうことを知らないし、知る必要が少ないウェブデザイナーに
どうやって使いやすい環境を提示できるだろうか。

640 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:03:38.86 ID:UKZkpptu.net]
>>633
その様子だと直前じゃないコミットを修正するって行為がどういう意味を持つか理解できてないだろ?
Gitに慣れるまではおとなしく新しいコミットで修正しとけ

641 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:07:11.82 ID:/P0faz6I.net]
>>635
そうじゃなくて、それをしたくないから、Egitでのやり方を知りたいわけです

642 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:10:20.71 ID:UKZkpptu.net]
>>636
EGit使おうがコマンドラインでやろうが、途中のコミットを修正するってことは単純な行為じゃないんだよ
コンフリクトが発生する可能性があるの理解してる?

643 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:15:59.04 ID:rs3gN1uE.net]
>>636
当たり前のことを言うけどさ、プログラマっていうのは技術者だよ?
技術者と何故呼ばれるかというと、それは技術がなければできないことが
できるから技術者なんだよ。

今君が言っていることは「技術者になりたくない」って言っているのと
同じことだってわかってる? 楽とか大変とかじゃない。
技術をつけること事拒否することは、技術者になりたくないと言ってるのと同じ。

CLIでgitの使い方を学ぶのが技術をつけるのに一番の近道なんだよ。
別にGUIが楽なら普段はGUIを使っていい。でも技術自体はちゃんとつけておけ。

644 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:16:28.99 ID:/P0faz6I.net]
個人的には、分からないなら「分からない」で全然かまいません
できるなら、ここ以外でツールの話を分かりそうな人がいる場所を教えてくれるとうれしいですが

645 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:17:36.07 ID:rs3gN1uE.net]
>>639
なんならまたスレ立てようか?

「git関連のGUIツールの使い方を教えて下さい」っていうスレ

646 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:18:36.91 ID:/P0faz6I.net]
もちろん、2chである必要は全然ないです
(・・・っていうか、むしろこの状況ならそっちの方が知りたいです)

647 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:21:41.41 ID:rs3gN1uE.net]
あ、もう一つgitのGUIツールがなぜCLI使えない人にとって
難しいのかがわかった。

普通CLIが難しい理由は「コマンドを覚えないといけないから」で
その「コマンドを覚える必要がないから」GUIは簡単なんだ。

でもソースコードの管理ツールの場合、コマンドを覚えることよりも
そのコマンドで何が出来るか、何をするかがわからないから難しい。

ボタンひとつでコマンドを呼び出せても、そこから何をすればいいか
わからないんだよね。この人のように。

648 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:23:55.02 ID:/P0faz6I.net]
>>640
っていうか、ここがgit関連のツールの使い方を聞ける場所になったんじゃないんですか?
>>617さんのように、CUIじゃない質問をしてる人もいますし、ここでGUIだけ絞る必要もない気がしますが・・・



649 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:31:22.51 ID:1F5PzSNl.net]
>>641
最低限英語できるならstackoverflow.com、機械翻訳でも多分他の人が適当に質問自体修正してくれる
ja.stackoverflowでもいいけど回答くる確率は落ちる

650 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:34:31.78 ID:rs3gN1uE.net]
>>643
聞くのは構わないが答えるとは限らないw
質問したところで>>617さんのように放置される。

このスレからgitフローのような運用に関する話が
分離しただけで、ここがなにかに変わったわけじゃない。

651 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:37:00.95 ID:/P0faz6I.net]
>>642
自分の場合は、GUIが簡単でCLIが難しいからじゃなくて、
Eclipse上でそのまま操作できるのが楽だから、なんですよね

あなたがEgitを知らなくて、自分はEgitのことを知りたいので、
分からないなら「分からない」って言ってくれて全然かまいません

>>644
なるほど、そっちの方が良い人がそろってそうですね
英語にはさほど抵抗ないですし、そっちで質問してみます
ありがとうございました

652 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:39:46.62 ID:rs3gN1uE.net]
よし、これでこのスレでツールの話をする奴が消えたw

こんな感じでどんどん減らしていくので、4649!

653 名前:デフォルトの名無しさん mailto:sage [2015/06/07(日) 23:43:59.53 ID:UKZkpptu.net]
>>646
ほらよ
another.maple4ever.net/archives/2060/
このブログの後半の「コミットを改変する場合」な

654 名前:デフォルトの名無しさん mailto:sage [2015/06/08(月) 08:05:44.37 ID:USedaFhj.net]
なにこの CLI で git 使える俺スゲー君 w

655 名前:デフォルトの名無しさん mailto:sage [2015/06/08(月) 08:53:59.64 ID:Q2pvFPhj.net]
CLIじゃないと、まともに使えないという方が多いんじゃないか。

656 名前:デフォルトの名無しさん mailto:sage [2015/06/08(月) 11:32:29.03 ID:AXPER4TO.net]
GUIで全部やるのは難し過ぎる
併用が無難だよ

657 名前:デフォルトの名無しさん mailto:sage [2015/06/08(月) 11:48:08.05 ID:I6Rw7h/u.net]
gitと親和性の高いBTSでお勧めを教えて

658 名前:デフォルトの名無しさん [2015/06/08(月) 12:15:16.89 ID:obzwvKms.net]
もうgithub for windowsで満足
プルダウンメニューでブランチを替えて、
ファイルを編集したら未コミットのリストがリアルタイムで追随、
マージはブランチのドラッグアンドドロップで一発、
プッシュはsyncボタンで一発。

でもたまによくあるCLIの作業からは逃れられないけど



659 名前:デフォルトの名無しさん mailto:sage [2015/06/08(月) 13:31:33.83 ID:AXPER4TO.net]
ファイル編集、HEADとの差分確認、コミットの流れはIDEやエディタに統合されたのを使う
ブランチのブラウズもGUIのを使う
ここらへんは非CLIでやることのメリットを感じるね

660 名前:10人に1人はカルトか外国人 [2015/06/08(月) 14:46:48.11 ID:KHrLNVN4.net]
●マインドコントロールの手法●

・沢山の人が偏った意見を一貫して支持する
 偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法

・不利な質問をさせなくしたり、不利な質問には答えない、スルーする
 誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法

偏った思想や考え方に染まっていたり、常識が通じない人間は、頭が悪いフリをしているカルト工作員の可能性が高い

靖国参拝、皇族、国旗国歌、神社神道を嫌うカルト

10人に一人はカルトか外国人

「ガスライティング」で検索を!






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧](;´∀`)<316KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef