Git 12©5ch.io
レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん 転載ダメ©2ch.net
2015/03/23(月) 13:35:13.83ID:aBYp+bVsGit - 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 11
http://peace.2ch.net/test/read.cgi/tech/1416195050/
0002デフォルトの名無しさん
2015/03/23(月) 13:37:21.43ID:aBYp+bVsバージョン管理システムについて語るスレ10
http://peace.2ch.net/test/read.cgi/tech/1393147031/
CVS導入スレ〜 Rev.3
http://peace.2ch.net/test/read.cgi/tech/1113141518/
Subversion r15
http://peace.2ch.net/test/read.cgi/tech/1406967657/
【分散型バージョン管理】 Mercurial 2【hg】
http://peace.2ch.net/test/read.cgi/tech/1321109748/
【bzr】Bazaarでバージョン管理 Rev 4
http://peace.2ch.net/test/read.cgi/tech/1356521407/
OSSホスティング総合【SourceForge,GitHub,etc..】
http://peace.2ch.net/test/read.cgi/tech/1384821518/
◆関連スレ 別板
CVS 1.3 [UNIX板]
http://peace.2ch.net/test/read.cgi/unix/1093611448/
0003デフォルトの名無しさん
2015/03/23(月) 18:37:08.09ID:5dh1GAQdところで
diff.mnemonicprefix
ってなに？
0004デフォルトの名無しさん
2015/03/23(月) 19:15:42.59ID:y5y7OlJ2＞そうか、いくつものプロジェクトを任されないやつは気楽でいいな。
＞部下の手間やオペミスを気にしない立派な方は言うことが違うな。
お前と違って、部下全員の動きを一挙手一投足全部自分で
チェックアウトできるほど暇じゃないもんで・・・
>>前997
＞どのくらいの頻度でプロジェクトの新規立ち上げするの？
＞やっぱり1日1個くらいのペースでどんどん増えていくもの？
さすがにそんな増えないでしょ
3か月ペースの開発プロジェクトが60個、それぞれに平均5人いるとしても
300人のエンジニアを率いていることになるよ
そんな人が、部署のマネジメントもろくにしないでしこしこgitのプロジェクトを
起こしてるとか考えにくい
gitのプロジェクトを起こすのが仕事の間接部隊の人なら、まぁあるかも
しれないけど
0005デフォルトの名無しさん
2015/03/23(月) 20:50:21.09ID:BMVzdvQz997 デフォルトの名無しさん sage 2015/03/23(月) 12:14:29.10 ID:5dh1GAQd
うちの会社は半年に1個くらいしかプロジェクトないので
いつも手書きのメモ見ながら作ってるわ・・・
0006デフォルトの名無しさん
2015/03/23(月) 20:51:21.38ID:BMVzdvQz0007デフォルトの名無しさん
2015/03/23(月) 21:58:34.39ID:y5y7OlJ2あなたにとっての突っ込みどころが「半年にプロジェクトが1個」なのか「手書きのメモ」なのか分からないけど、
半年に1個のペース（しかも一個人の目に見えるとこ）でgitリポジトリ＝新規製品が1個立ち上がってるとしたら
結構早い気が
自分がパッケージ開発系にいるからそう思うだけで、スマホゲーみたいな「いつもの手順で何個も作る」みたいな
開発形式だと、そういうペースになるのだろうか
0008デフォルトの名無しさん
2015/03/23(月) 23:09:04.71ID:BMVzdvQz滅多にないなら、忘れないために自動化する。
頻繁にあるなら、手間をかけないために自動化する。
プロダクトとプロジェクトは別だよ。
同じっていうプロジェクトの分け方もあるとは思うけど、それはポリシーの話。
0009デフォルトの名無しさん
2015/03/24(火) 00:17:38.33ID:LMCtJA+5＞滅多にないなら、忘れないために自動化する。
滅多にやらないことに自動化＋自動化ツールの手順書作成は、さすがにコストかかりすぎると思う
＞プロダクトとプロジェクトは別だよ。
話のピントがずれてきてるな・・・自分と前997が気にしてるのは、プロダクトとプロジェクトの定義じゃなく、
新しいgitリポジトリを毎日作らなきゃならない職場って一体どんなだろうってことだ
0010デフォルトの名無しさん
2015/03/24(火) 01:00:24.03ID:AMK4q4iG普段GUI使ってる人にはわからないかもだけど、
5分もかからない。
スクリプトなら説明は要らないが、必要ならそのまま書き込める。
毎日なんて誰も言ってないだろ。
1週間でプロジェクトの立ち上げして、後は任せたとかなら割とある。
0011デフォルトの名無しさん
2015/03/24(火) 01:24:05.45ID:LMCtJA+5＞普段GUI使ってる人にはわからないかもだけど、
＞5分もかからない。
うーんそれって、「自動化したんじゃなくって既に自動化されてる」とか、
「5個位コマンドを打たなきゃならないのを1個にした」って話か・・・
＞1週間でプロジェクトの立ち上げして、後は任せたとかなら割とある。
最初のたった1週間しかいないプロジェクトで、一体あなたが何の役割を果たすのか疑問だ
親会社が子会社に要求仕様を丸投げして消えるような感じだろうか
そうだとすると、肩書きというか所属はエンジニアだけど実態は発注者だな
そういう立ち位置の人がgitのリポジトリを作る必要があるのかもよく分からなくなってきた
親会社のサーバーにリポジトリを作るから、親会社の人しかリポジトリを作れないとかだろうか
0012デフォルトの名無しさん
2015/03/24(火) 01:48:04.53ID:AMK4q4iGすまなかったな。
お前にとって、リポジトリを立てるというのが、とても難しいことだと言うのは、よくわかったよ。
理解できない人もいるんだな。
それしかやってないと言う思い込みをしてるのかな。
0013デフォルトの名無しさん
2015/03/24(火) 09:42:14.84ID:LMCtJA+5リポジトリを立てるのが簡単なのは、よく分かったよ
コマンドラインを何発か叩くだけなんでしょ？
問題は、何十プロジェクト（50人ちかく？）のまとめ役をやってて、
しかもプロジェクトを丸投げして開発管理をしないような人が、
なんでgitの管理は自分でやることにこだわるのか、ってことだ
・・・実際はまとめ役じゃなくて開発環境を整備する役で、そっちが
メインだからなのかもしれないが・・・
0014デフォルトの名無しさん
2015/03/24(火) 11:47:24.75ID:FrFlsYhdgitをきちんとスター型にするのって面倒くさくね？
0015デフォルトの名無しさん
2015/03/24(火) 12:55:00.90ID:LMCtJA+5それってネットワーク関係の話？
そういうときは、自部署の閉じたネットワークにgitサーバを立てるんじゃなくって、
社内どこからでも（場合によっては社外からも）接続可能な特別なgitサーバを
ネットワーク部門の人が用意してるから、そこにリポジトリ作成を「申請する」って
流れになると思う
0016デフォルトの名無しさん
2015/03/24(火) 13:00:03.66ID:jPXMtrDEあっても同じじゃん？そもそもでかいガタイの為にでかいRCSを「立てる」
必要がないってのがgit(系統)の売りだったんじゃ？
0017デフォルトの名無しさん
2015/03/24(火) 13:17:28.26ID:Z7mrPeroだから、中央リポジトリとコミッターが必要になる。
0018デフォルトの名無しさん
2015/03/24(火) 14:26:16.00ID:FrFlsYhddiff.mnemonicprefix ってなに？
sourceforgeでfetchしたときのオプションにあったんだけど
なにを意味するのかバヌアツ見てもよくわからない
0019デフォルトの名無しさん
2015/03/24(火) 14:57:15.56ID:jPXMtrDE> 違うmasterが二箇所にあればどちらが正しいか分からなくなるのもgitだから、
それは「運用の不手際」であってgitと全く関係ないじゃん？
0020デフォルトの名無しさん
2015/03/24(火) 15:15:37.69ID:LMCtJA+5違うmasterが2個あるのが「運用の不手際」であり、masterはただ1つでなければならないなら、
そのmasterは、プロジェクトに関わる全員から見える場所にないと困ると思うが・・・
0021デフォルトの名無しさん
2015/03/24(火) 16:19:57.62ID:AMK4q4iGお前が自分が知ってる形態しか理解できないのはよくわかったよ。
0022デフォルトの名無しさん
2015/03/24(火) 17:17:23.80ID:LMCtJA+5お前が自分が知ってる形態を説明しないから、理解できないんだよ。
0023デフォルトの名無しさん
2015/03/24(火) 19:47:13.61ID:NaTfFmmDそれはgit的には間違った解釈じゃないかな？(´･ω･｀)
グループマスタはグループ全員から見えてもいいと思うけどプロジェクトマスタの
更新権も全グループの全要員にないとダメという訳じゃないよね？(´･ω･｀)
グループリーダーだけがグループマスタをプロジェクトマスタに更新できる方が
組織的な運用としてはやりやすいと思うよ？(´･ω･｀)
0024デフォルトの名無しさん
2015/03/24(火) 19:55:25.10ID:AMK4q4iG0025デフォルトの名無しさん
2015/03/24(火) 20:29:10.23ID:LMCtJA+5リモートリポジトリがどこにあるべきかって話に
ブランチ戦略の話が混じってしまっている気がして、何とも答えにくい
0026デフォルトの名無しさん
2015/03/24(火) 20:33:49.43ID:NaTfFmmDいいんじゃないかな？(´･ω･｀)
0027デフォルトの名無しさん
2015/03/24(火) 20:48:23.99ID:sz/ymt1l一台gitlabサーバーを立てれば、
1. プロジェクトのリモートリポジトリ
2. そのプロジェクトをforkした個人のリモートリポジトリ
3. ローカルリポジトリ
って自然に三つのリポジトリをシンプルに使うことが出来るよ。
開発は、
3. ローカルリポジトリを修正
2. 個人のリモートリポジトリにpush
1. そこからプロジェクトのリモートリポジトリにマージ（ウェブから実行できる）
という流れが出来上がる。
0028デフォルトの名無しさん
2015/03/24(火) 20:55:16.60ID:LMCtJA+5自分も同意見だ
ただ、>>15→>>16の時点で、リモートリポジトリの話かmasterブランチの話か既に分かりにくくなってるんだな
20の「master」は、「リモートリポジトリ」のつもりで話していた
0029デフォルトの名無しさん
2015/03/24(火) 21:05:35.91ID:LMCtJA+5ソースコードが社外に置かれるgithubがお堅い企業で使われてるかは微妙だけど、
gitlabは商用でサポート受けれるし、githubを抜くとおそらく1番手で使われてるんじゃないか？
0030デフォルトの名無しさん
2015/03/24(火) 23:26:42.53ID:CRqFXs0Ttouch a; git add a; git commit "initial commit"
git checkout -b test
touch b; git add b; git commit "b"
touch c; git add c; git commit "c"
git checkout master
git merge dev --squah
git checkout test
touch d; git add d; git commit "d"
touch e; git add e; git commit "e"
git checkout master
git merge dev --squah
これでこういうメッセージが出ます。どうしてマージできないんですか？
>Squash commit -- not updating HEAD
>Automatic merge went well; stopped before committing as requested
0031デフォルトの名無しさん
2015/03/24(火) 23:27:52.62ID:CRqFXs0T0032デフォルトの名無しさん
2015/03/25(水) 10:38:07.54ID:DffMWI2Jhttps://gist.github.com/katzchang/4126092
0033デフォルトの名無しさん
2015/03/25(水) 12:53:22.29ID:7vrJVraDそれ書いたやつここに連れてくるか、
お前が代わりに反論してくれ。
まずrebaseはコミット履歴を綺麗にするためであって
コミット"グラフ"を綺麗にするものじゃない。
この時点でそれ書いたやつは勘違いしている。
そしてffマージ推奨みたいな感じだが、
"master"へのマージは--no-ffでやるのが常識
gitlabのウェブ管理画面からは--no-ffしか行えない。
（もちろんmasterじゃないところならffマージでも良い）
さらに言えば「開発中のブランチ」と「そのブランチがffマージされた未来のmaster」が
同じ内容になるからテストが安心できるというのはまあいいんだが、
途中のコミットの話が抜けてる。同じ内容になるからという理由だけなら
途中のコミットが汚なくてもいい（レビューが困難）でもいいって話になってしまう。
rebaseの目的はレビューを容易にすること。テストが安心っていうのはおまけでしかない。
0034デフォルトの名無しさん
2015/03/25(水) 12:58:04.22ID:IRTth2yB0035デフォルトの名無しさん
2015/03/25(水) 13:40:29.78ID:1QZDV4EMレビューっていうのは、プルリクエストが出された「ひとまとまりのコミット」に対して行われるものだ
その時にレビュアーは、その「ひとまとまりのコミット」が何のための修正かを把握しているはずである
※1つのプルリクエストに複数の目的の修正が入っているなら、そのプルリクエストが間違ってる
レビュアーが、その「ひとまとまりのコミット」が何のためなのかを分かっていれば、各コミットが
どれだけ細分化されていようと、（レビュアーは「ひとまとまりのコミット」で最終的にどうなったかだけを
チェックし、各コミットで何をしたかまでは追いかけない、という理由で）コードが合っているかの
チェックを阻害したりはしない
これで反論になってるだろうか
0036デフォルトの名無しさん
2015/03/25(水) 13:43:12.20ID:jY89TDAereword
fixup
squash
pick
で
editとexecは必要ないと思ってるんですがあなたたちは使いますか？
0037デフォルトの名無しさん
2015/03/25(水) 14:47:57.92ID:7WluZNwF0038デフォルトの名無しさん
2015/03/25(水) 15:04:11.83ID:8K+/BW9F0039デフォルトの名無しさん
2015/03/25(水) 15:17:55.54ID:7WluZNwFその開発ブランチからさらにブランチを作って、
そこにこまかくコミットしたものをリベースして開発ブランチにマージする
実装する機能単位でそれを繰り返す
0040デフォルトの名無しさん
2015/03/25(水) 15:38:52.70ID:8K+/BW9F0041デフォルトの名無しさん
2015/03/25(水) 19:19:14.80ID:5Dq5kMph0042デフォルトの名無しさん
2015/03/25(水) 19:31:03.19ID:7vrJVraD> ※1つのプルリクエストに複数の目的の修正が入っているなら、そのプルリクエストが間違ってる
一つのプルリクエストは、一つの機能だよ。
その機能は複数のコミットからなっている。
誰かが新しい機能のプルリクエストを出す所を考えて見ればわかるはず。
新しい機能を、プラグインみたいに簡単に追加できる場合ならいいが、
一般的には既存のコードを拡張可能なように修正して、
そこに機能追加を行う。
0043デフォルトの名無しさん
2015/03/25(水) 19:33:42.33ID:7vrJVraD> 途中のコミットがあろうがなかろうがレビューは困難にも容易にもならないよね？(´･ω･｀)
なるよ。
いきなり複数のファイルにまたがる1000行の修正を送られたって
何をしたいのかわからない。
一つ一つ説明が必要。それが一つのコミットになる。
0044デフォルトの名無しさん
2015/03/25(水) 20:00:32.67ID:1QZDV4EM（33で言ってた内容）
＞途中のコミットの話が抜けてる。同じ内容になるからという理由だけなら
＞途中のコミットが汚なくてもいい（レビューが困難）でもいいって話になってしまう。
＞rebaseの目的はレビューを容易にすること。
（43で言ってた内容）
＞いきなり複数のファイルにまたがる1000行の修正を送られたって
＞何をしたいのかわからない。
プルリクエスト1件を送るとき、コミットをまとめるべきと言ってたはずが、
コミットをまとめないべき、にすりかわっている。
あなたの意見どころかあなた自身が、反論に耐えうるものじゃないんじゃなかろうか
0045デフォルトの名無しさん
2015/03/25(水) 20:07:29.90ID:7vrJVraDReplace highlight.js with rouge-fork rugments
https://github.com/gitlabhq/gitlabhq/pull/8425/commits
どうやらこれは、highlight.js を rouge-fork rugments に入れ替える
プルリクエストのようだ。
これは一つのプロリクエストに三つのコミットが入っている。
1. テストの修正
2. ライブラリ入れ替え
3. 2以外の関連ライブラリバージョンアップ
これは一つのコミットにまとめてはいけない。なぜなら入れ替えを行った結果
既存のコードが動かなくなるかもしれないからだ。
最初にテストの修正を行っているのは、ライブラリの入れ替えの前と後の両方で同じテストが通るようにするためだろう。
入れ替え前に問題となるテストを修正し（もちろん入れ替え前にテストは通る）
入れ替えた後でもテストが通れば壊れていないことが確認できる。
そして1, 2, 3のそれぞれがわかれているから何を行ったのかレビューしやすい。
テストの修正とライブラリの入れ替えと関連ライブラリのバージョンアップが
一つのコミットになっていれば、いきなり複数の変更をこんなに変えて大丈夫か？ってなるだろう？
また逆に、この3つのコミットを分離して、一個ずつマージするという案もあるが、
それだと1のテストの修正は2の為にやるのだが、いきなり1.テストの修正という理由がわからない
プルリクエストが届くことになる。なぜ1が必要な理由が不明だし、もしかしたら2を直せば
1は不要になるかもしれない。
だからこの三つのコミットは独立していたら駄目だし、一つのコミットにしてもいけない。
それぞれのコミットがレビューしやすいように、無駄なコミットもない。
0046デフォルトの名無しさん
2015/03/25(水) 20:16:05.54ID:7vrJVraD> プルリクエスト1件を送るとき、コミットをまとめるべきと言ってたはずが、
> コミットをまとめないべき、にすりかわっている。
「綺麗に」まとめるということ。
汚いものをまとめろと言っただけで、
一つにまとめろとは言ってないない。
一つにまとめる・・・これはだめ。
まったくまとめない・・・これもだめ。
一つのプルリクエストは、1つ以上のコミットから成り立ち、
それぞれのコミットがレビューしやすいように
意味のある単位にまとめる。
0047デフォルトの名無しさん
2015/03/25(水) 20:17:13.12ID:1QZDV4EMあなた自体が説明に耐えうるものじゃないな・・・
自分の主張や情報を後出し後出しにして、ハイ反論どうぞ、なんて言われてもねぇ
そんなんじゃ、周りの人とまともな議論ができないだろう・・・
自分が推測するに、あなたは下請けに仕事を発注したことはあるが、
「チームで開発作業をしたことはあまりない」と感じられるんだが、実際どうだろうか？
まぁおそらくは、反論してくるだろうと思うが
0048デフォルトの名無しさん
2015/03/25(水) 20:20:44.43ID:7vrJVraD一つにまとめる・・・何も考えずに何でもかんでも一つにまとめるのはだめ。綺麗にまとめた結果一個になる場合は良い。
まったくまとめない・・・だめ。ただし最初からきれいな単位にまとまっているのであればそれで良い。
重要なのは一つのプルリクエストをレビューがしやすいように、
「意味がある単位で1個以上のコミットで綺麗にまとめる」ということ。
0049デフォルトの名無しさん
2015/03/25(水) 20:23:04.00ID:7vrJVraD反論も何も、お前は、
俺のことを「チームで開発作業をしたことはあまりない」と感じましたって
個人の感想を言ってるだけじゃんか。
えとさ、俺の言っている内容に対してレスしてくれない？
俺の言っている内容にコメントできないからって
「お前は○○だ。ばーか、ばーか。なにか言い返してみろよ」
と同等のレスをされて困るんだがね。
下らないレスはいらないから内容に対してコメントしろ。
お前が>>47で何か内容に対してコメントしたか？
0050デフォルトの名無しさん
2015/03/25(水) 20:32:17.06ID:7vrJVraD自分が「コミットをまとめる」って言ったと思って
レスしていたが、自分のレス読み返してみたが
「綺麗にする」とは書いてあるが
「まとめる」とは書いてないじゃないか？
おかしいな？
もしかして>>44のレスって単なる言いがかりか？
0051デフォルトの名無しさん
2015/03/25(水) 20:49:15.42ID:7vrJVraD>>32の用な無名な人が書いた駄文じゃなくて有名な人の意見
http://blog.marc-andre.ca/2014/02/05/why-i-wont-squash-my-commits/
http://qiita.com/gogotanaka/items/8c55f69120965b077737 (↑の翻訳)
> RubyのコミッターでもありRailsなどの多くのOSSで活躍されている
> Marc-Andre Lafortune さんのブログに面白い記事があったので筆を取りました.
> 各プロジェクトのコミッターらの素晴らしい仕事に対して失礼ながら、
> 私はコミットをまとめたいとは思わない. だから私にまとめろ言わないで欲しい.
> 例えば5つのコミットからなるpull requestがあったとして、もし私が何もミスをしてなければ、
> この5つのコミットはそれぞれ独立しているはずで、それらをわざわざまとめるべきでないと思っている.
※↑これはゴミコミットを残せって言ってるんじゃないよ。↓ ほらゴミコミットはキレにするべきと言ってる。
> 例えばこんな感じ
>
> ・素晴らしいfeatureを思いつき、手をつける
> ・しまったtypoしてた直さないと
> ・しまったバグを直さないと
> ・featureを仕上げる
>
> この様なcontributor達がもし、そのままのcommitをpull-requestに出して、
> それが受け入れられない（つまりマージされない）という事は当然の報いだとは思うが、
> 良い例がここ(https://github.com/sdsykes/fastimage/pull/27)にある.
> これは一つのbugを修正するためのpull-requestだが私は15つのコミットに分けた.
> それぞのリファクタ１つ１つはしかるべく順序で並んでおり、最後の１つだけがbugの修正それ自体なのだ.
なんだｗ 俺が探してこなくても、ここに書いてあったじゃないかｗ
0052デフォルトの名無しさん
2015/03/25(水) 20:58:15.28ID:2zE2JJLlそういう人は相手にせずスルーすべし
0053デフォルトの名無しさん
2015/03/25(水) 21:18:09.55ID:1QZDV4EM>>48に書いたことを、>>33のときに書いていれば反論を招かずに済んだ話だと思う
自分が言いたいのは、まさにこの一点
このスレをgitに例えれば、あなたは>>33におけるタイプミスの修正を>>51まで延々と
続けているということだ
0054デフォルトの名無しさん
2015/03/25(水) 21:21:46.19ID:7vrJVraDお前が読み間違っただけだろう？
それに俺がお前に言いたいのは
内容に対してレスしろってことだ。
お前の人間として品性がないって話をしている。
お前の反論がないんだから、俺の意見は正しくて
残るはお前の品性の問題しかないからな。
0055デフォルトの名無しさん
2015/03/25(水) 21:23:46.76ID:7vrJVraD俺は、コミットを綺麗にしろ言っただけで、
一つにまとめろとか言ってないからな。
そもそもまとめるという単語すら
>>33には書いてない。
勘違いしたのは、 ID:1QZDV4EM
0056デフォルトの名無しさん
2015/03/25(水) 21:25:18.08ID:0It7vtDM0057デフォルトの名無しさん
2015/03/25(水) 21:32:07.66ID:1QZDV4EM＞お前の人間として品性がないって話をしている。
違うだろう、今度はいつの間に「反論があるかないか」の話からすりかわったんだ
まぁでもお前がgitのスレでやりたいのは、反論があるかないかじゃなく、人を馬鹿にする方なんだろうが・・・
0058デフォルトの名無しさん
2015/03/25(水) 21:40:49.98ID:7vrJVraD人を馬鹿にしたのはお前だろう？
お前が読み間違っただけなのに、反論が〜とか言った挙句
> 自分が推測するに、あなたは下請けに仕事を発注したことはあるが、
> 「チームで開発作業をしたことはあまりない」と感じられるんだが、実際どうだろうか？
> まぁおそらくは、反論してくるだろうと思うが
こんな事言ったよな？
お前が何を考えてこんなレスをしたかあててやろうか？
1. 反論しない（俺が言い返さない）・・・やっぱりチーム開発したことないやつだったな。俺が言ったことは正しかった（優越感）
2. 反論する・・・俺が予想したとおり反論してきたか。俺が言ったことは正しかった（優越感）
どうだ？ あってるだろ？ どちらにしろ優越感を感じられれるなｗ （まあそれをばらしたから優越感を味わえないだろうがｗ）
そもそも、俺がどういうやつかなんて「お前の母ちゃん出ベソ」と同じで
証明しようがない問題だ。俺がなんと言おうが、お前が信じなければそれまでだからな。
それぐらいお前もわかっててやっただろ？
単にお前が優越感を得るためだけの意味が無いレス。
だからこんな下らないレスだと言った。
こういうレスを見たから俺は、お前は品性のないやつだと確定できて、
最後の挽回のチャンスとして、反論しろといったわけだが結局反論できなかったな。
はははｗ お前が>>57でレスしてくれたから、俺にこういう説明をするチャンスになったよ。ありがとなｗ
0059デフォルトの名無しさん
2015/03/25(水) 21:46:25.46ID:1QZDV4EMけっきょく、このスレで言った言わないの議論をするお前じゃなくて、今技術者をやってるお前ってどうなの？
なぜ軽くスルーできなかったのか？やっぱ、そこに問題があるから怒ったのか？そうだったら謝りたいが
0060デフォルトの名無しさん
2015/03/25(水) 21:49:20.02ID:7vrJVraDほらなｗ やっぱり品性がない。
人を馬鹿にする方向にしかレスが出来ない。
お前無意識にやってるだろ？
無意識で品性がないｗ
最初にそんなことやらずに、内容に対してレスする方向に
変えていれば、今頃は挽回できたかもしれないのにな。
哀れ。
0061デフォルトの名無しさん
2015/03/25(水) 21:53:44.04ID:1QZDV4EM第三者的には、>>58の時点でバカ2名のやり取りにしか見えないと思うぞ
0062デフォルトの名無しさん
2015/03/25(水) 22:21:34.29ID:2zE2JJLl五十歩百歩かもしれんが
百の方が五十の方を道連れにしようとすんなｗ
0063デフォルトの名無しさん
2015/03/25(水) 22:23:48.78ID:1QZDV4EMそうかもね、すまない
0064デフォルトの名無しさん
2015/03/25(水) 23:32:40.35ID:7vrJVraD勘違い君、かわいい（哀れ）
0065デフォルトの名無しさん
2015/03/26(木) 06:42:05.21ID:zxUHxD8M> 百の方は俺のことだろｗ
勘違い君、かわいい（哀れ）
0066デフォルトの名無しさん
2015/03/26(木) 07:47:28.35ID:IO0z/ZIB0067デフォルトの名無しさん
2015/03/26(木) 11:04:14.40ID:RWcMqhbhdiff.mnemonicprefix ってなんのオプションかわかる？
これをつけるとつけないとで何が変わるの？
0068デフォルトの名無しさん
2015/03/26(木) 11:45:31.23ID:7Tklw0eChttp://stackoverflow.com/questions/28017249/what-does-diff-mnemonicprefix-do
0069デフォルトの名無しさん
2015/03/26(木) 12:01:03.18ID:Z4IoHfg80070デフォルトの名無しさん
2015/03/26(木) 12:18:51.15ID:RWcMqhbhありがとう
diffしたときのファイル名になぜかついてた a/ とか b/ とかを
出さないようにするオプションなのね
0071デフォルトの名無しさん
2015/03/26(木) 20:54:55.68ID:bNJI23fgちょっと違うで
a/ とか b/ とかのプレフィックスを出さないようにするのは diff.noprefix
diff.mnemonicprefix は意味のあるプレフィックスを出力する
意味のある、というのは、どことどこの diff なのか、つまりインデックスなら i/、ワークツリーなら w/、という具合に出力する
0072デフォルトの名無しさん
2015/03/27(金) 15:17:35.69ID:NmkvbaYsありがとう。じゃあnoprefixの方使うようにするよ。
ところで、すでに運用してるgitをWEBから管理したくて
でもgitwebが使いづらいので乗り換えたいんだけど
gitlabをインストールしてみたいんだけど
これってそういう風には使えるものなのかな
0073デフォルトの名無しさん
2015/03/27(金) 17:14:19.11ID:wC2EsVxWgitlabはdbも使ってるし移行作業は必要になると思うよ
0074デフォルトの名無しさん
2015/03/27(金) 18:38:26.72ID:HpSv3zdu素直にインポートしたら。たいした手間でなし。
0075デフォルトの名無しさん
2015/03/27(金) 19:45:18.53ID:+T9VOHOm認証、通信の暗号化の可否はそれぞれどうですか？
0076デフォルトの名無しさん
2015/03/27(金) 21:37:55.61ID:9ALWzfda当たり前だけど、gitのリポジトリをpushするだけ。
gitlabのgit以外の機能（IssueとかMergeRequestとか）に、
データベースを使っているが、gitwebにはgit以外の機能ってほぼないだろ？
0077デフォルトの名無しさん
2015/03/27(金) 23:36:40.51ID:+T9VOHOmで、GitBucket上で、移行したコミットのコミット者を見ようとすると、
ユーザ名ではなくメールアドレスでユーザーの識別をしているように見えます
この識別方法はGitBucket固有ですか？
また、リモートリポジトリにpushした後の各コミットについて、
コミット者のメールアドレスを変更することは可能ですか？
0078デフォルトの名無しさん
2015/03/27(金) 23:54:27.14ID:Z8DJNpSP0079デフォルトの名無しさん
2015/03/28(土) 14:15:10.16ID:w2Z+yJkJhttps://github.com/git/git/releases/tag/v5.6.24
0080デフォルトの名無しさん
2015/03/28(土) 18:47:44.36ID:+R+DyebJこんなん初めて知った
diff結果のパスを引数に合わせて変える模様
$ git diff
i/foo.txt # indexの'i'
w/foo.txt # worktreeの'w'
008180
2015/03/28(土) 18:49:53.09ID:+R+DyebJ0082デフォルトの名無しさん
2015/03/29(日) 18:08:14.32ID:E72jh6+u0083デフォルトの名無しさん
2015/03/29(日) 19:10:29.25ID:GIfRQ9M60084デフォルトの名無しさん
2015/03/29(日) 21:45:52.31ID:SsUrZhnW補完すごいよね
addすべき対象をtabで一発で当ててきたときはビビったよ
0085デフォルトの名無しさん
2015/03/29(日) 22:04:26.44ID:vkiGWuNthttps://github.com/git/git/search?l=c&;q=add&utf8=✓
0086デフォルトの名無しさん
2015/03/30(月) 08:52:02.76ID:ebxMPih7そんなもの使ってない
0087デフォルトの名無しさん
2015/03/30(月) 10:57:03.31ID:QTBkdmd4そんなのディストリビューション次第じゃないの。
0088デフォルトの名無しさん
2015/03/30(月) 11:53:27.54ID:eSl2sveJなぜbashだけが優遇されるのか？
今使われてるのはzshだろ。
0089デフォルトの名無しさん
2015/03/30(月) 12:10:49.96ID:pDn2M2s4zsh なら、oh-my-zsh に git プラグインあるだろ。
0090デフォルトの名無しさん
2015/03/30(月) 13:24:21.18ID:pQkawj3/あー、普通にgitについてたよｗ
0091デフォルトの名無しさん
2015/03/30(月) 21:52:59.70ID:7jnhpj+r今zsh使ってる人って残ってるの？
みんなbashに戻ったとばかり思ってた
0092デフォルトの名無しさん
2015/03/31(火) 04:25:40.16ID:DVVpWgeR0093デフォルトの名無しさん
2015/03/31(火) 10:24:36.59ID:byVPP9+b使い方が分かる人しかいませんか？
便利なGitクライアントソフトとか、各種Gitサーバソフトの
使い方とか、そういうのを質問したかったらどこがオススメ
でしょうか？
0094デフォルトの名無しさん
2015/03/31(火) 10:48:52.86ID:jsR2iUWdここでいいと思うけど。もしかして >>77 かな？
GitBucketは使ったことないけど、
・gitは各コミットのauthorとcomitterそれぞれのnameとemailを記録してる。
・gitはユーザーを管理してない。ってか、分散システムだから管理しようがない。
・authorやcomitterの変更はできるけど、コミットID(ハッシュ値)も変わるので、変更というよりは履歴の書き換えになる。
0095デフォルトの名無しさん
2015/03/31(火) 12:02:22.73ID:DMT7op/Iそれgitに限定する意味あるの?
0096デフォルトの名無しさん
2015/03/31(火) 21:52:09.98ID:N1jW3NRegithub固有の話は専用スレがある
他はここでいいんじゃない？
0097デフォルトの名無しさん
2015/04/03(金) 00:52:20.92ID:bxWPklRz0098デフォルトの名無しさん
2015/04/03(金) 09:00:43.05ID:fygFc6bt税法的にもアウトですよ。コレ。
0099デフォルトの名無しさん
2015/04/03(金) 09:06:27.04ID:TGMPBffS0100デフォルトの名無しさん
2015/04/03(金) 11:50:44.23ID:uPiWXVNBこれでコンフリクトが出た場合はコミットされないのでgit merge --abortで元に戻せますよね
じゃあgit merge --no-commitってなんの意味があるんですか？
0101デフォルトの名無しさん
2015/04/03(金) 12:16:47.24ID:/qzMUQum0102１００
2015/04/03(金) 13:02:08.91ID:/gPIw7xIそうなると問題なくマージできる場合はコミットして当然だと思いますがおかしいですかね
0103１００
2015/04/03(金) 13:03:07.82ID:/gPIw7xI0104デフォルトの名無しさん
2015/04/03(金) 13:49:11.28ID:/qzMUQumコミットする余裕があってもいいんじゃね
0105デフォルトの名無しさん
2015/04/03(金) 20:25:53.13ID:pcIMeknY0106デフォルトの名無しさん
2015/04/03(金) 23:06:07.33ID:TGMPBffS理想としては全てのコミットは
テストに通れなければならない。
それはマージでも同じ話で、マージ前
マージ後、どちらもテストに通らなければならない。
起きる可能性は低いけれど、起こりえるのが
問題なくマージできたがテストには失敗するいうもの。
この時
1. (マージ前) テスト実行して問題ないことを確認。
2. (マージ後) テスト実行して問題発覚
3. git reset --hard HEAD^ でマージ前に戻す。
(rebaseだとマージに含まれる複数のコミットが分解されてしまうのでまずい）
4. git merge --no-commitでコミットせずにマージ
5. テスト実行して問題ないことを確認してからコミット
という流れで使うのではないだろうか？
0107デフォルトの名無しさん
2015/04/04(土) 00:01:59.62ID:qXtcXItO0108デフォルトの名無しさん
2015/04/04(土) 00:02:51.56ID:o7ivvLL/0109デフォルトの名無しさん
2015/04/04(土) 15:34:05.03ID:4aWMIGVn0110デフォルトの名無しさん
2015/04/05(日) 13:00:59.30ID:AGMqJGUT>> 106 が正しい。そういうマージコミットのことを evil マージという。
名前は悪そうだが、必要悪、といった感じだな。
0111デフォルトの名無しさん
2015/04/05(日) 14:07:33.73ID:Gn5PCEDnこのディレクトリは.gitignoreで除外されています
git pullをしたらdata/を汚さずに最新版にアップデートできるんですが
data/の中身を毎日zipでバックアップを取ってます
data/の中身をgithubとかdropboxにリポジトリ作るとか何でもいいのでgit pushで簡単にバックアップ取れるようにしたいんですが
どうしたらいいのか教えてください
0112デフォルトの名無しさん
2015/04/05(日) 14:40:52.20ID:OOK6R9Sygitはバックアップツールじゃない。
ソースコードのバージョン管理ツールだ。
gitというのは、ソースコードのバージョンに含まれる
機能を管理し、その機能を追加したり、削除したり
何が変わったか確認したり、バグを探したり
そういう事をするために使うツールだ。
コミット毎に内容に意味があって、そのコミットをうまく
活用できるためのツールがgitだ。
日付ごとのデータのバックアップなら別のツールを使いなさい。
0113111
2015/04/05(日) 15:39:11.36ID:Gn5PCEDn分かる方教えてください
0114デフォルトの名無しさん
2015/04/05(日) 15:49:35.25ID:KkKmAC5t0115デフォルトの名無しさん
2015/04/05(日) 17:38:56.13ID:lc+vonxV0116デフォルトの名無しさん
2015/04/05(日) 18:52:26.59ID:OOK6R9Sy間違いだよ。
素人は黙ってな。
0117デフォルトの名無しさん
2015/04/05(日) 20:05:27.42ID:/p4ZvisL0118デフォルトの名無しさん
2015/04/05(日) 22:45:55.43ID:vTKOQGSX老害をからかってちゃ後が面倒だぜ
0119デフォルトの名無しさん
2015/04/05(日) 23:02:46.40ID:JNGfMGjI0120デフォルトの名無しさん
2015/04/06(月) 07:57:53.43ID:/B7mQxeO不具合修正は別 commit にするし。
0121デフォルトの名無しさん
2015/04/06(月) 19:47:22.89ID:opDSS45mブランチAでリモートにpushしてプルリク
ブランチAの作業が残っている状態でブランチB作成
ブランチBで作業
ブランチAで追加コミットを修正してsquashしてリモートにpush -f
ブランチA
2015/4/6 19:00 9deflrm23dfggcfa6emlvfcg4a27ac8aca50fgf5475cg ← pick
2015/4/6 20:00 85jvoutvg9f003afgj54vklgkptkh585jvouft9ufjocjoxf ← squash
この状態でブランチBにしたら、squashしたはずのコミットがログに残っているんです・・・・。
どうしてなんでしょうか？
また、解決策としては、ブランチBでも同じようにsquashするしかないのでしょうか？
0122デフォルトの名無しさん
2015/04/06(月) 20:05:46.15ID:qFLwaw7j>どうしてなんでしょうか？
squashしたからブランチAとブランチBは異なる歴史になった
0123デフォルトの名無しさん
2015/04/06(月) 20:31:20.34ID:opDSS45m0124デフォルトの名無しさん
2015/04/07(火) 02:46:12.38ID:CzyUtHJJブランチBをrebaseすればいいんじゃねーの？
0125デフォルトの名無しさん
2015/04/07(火) 08:01:35.49ID:had6wKpc0126デフォルトの名無しさん
2015/04/07(火) 13:53:47.58ID:1qTlkWNC--ontoありのリベースで、リベースされるコミット群の先頭とリベースの基点のそれぞれを別個に指定する必要がある
0127デフォルトの名無しさん
2015/04/07(火) 13:54:59.96ID:xmsupUvw0128デフォルトの名無しさん
2015/04/07(火) 15:02:13.44ID:biFZC1fKひとりでやってても禁止するべきだ
0129デフォルトの名無しさん
2015/04/07(火) 15:20:32.75ID:1qTlkWNCgitは基本的な仕組みがシンプルだからコミットやブランチがどうやって管理されているかとか理解しやすい
逆にシンプルな故に、その仕組みを理解せずに使い方を覚えようとするととても難しく感じる
0130デフォルトの名無しさん
2015/04/07(火) 15:39:49.42ID:xmsupUvwそうそう、pull ―rebase は内部的に rebase ―onto をやってくれるんだよ
push -f はパスワードとか入れてはいけないものを入れてしまった時とか
リベースし続けているものを意図的に公開したいとか、そういう用途向けかな
共有リポジトリで push -f すると全員に pull ―rebase をお願いしたり、
クローン済みリポジトリを全部チェックする羽目になるのでなかなか大変
0131デフォルトの名無しさん
2015/04/07(火) 16:04:18.37ID:biFZC1fK0132デフォルトの名無しさん
2015/04/07(火) 19:08:37.15ID:had6wKpcありがとうございます。
勉強になりました
0133デフォルトの名無しさん
2015/04/07(火) 21:29:48.07ID:CzyUtHJJ> push -fはやるべきじゃない
> ひとりでやってても禁止するべきだ
またお前かｗ
問題ないって結論出ただろ。
過去レス嫁。
0134デフォルトの名無しさん
2015/04/08(水) 12:17:07.98ID:mhUDdxzX自分のところにもサーバにもコミットの履歴が残ってるんですよね？
サーバ側はともかく、自分のところにはコミットの履歴をあまり残したくないので
過去1か月分ほどを残してあとは削除したいんですが
どうしたらよいですか？
0135デフォルトの名無しさん
2015/04/08(水) 15:36:13.30ID:uhPXCuzkGitでは最新のコミットは過去のすべてのコミットの情報が存在しなければ意味を持たない構造になっている
0136デフォルトの名無しさん
2015/04/08(水) 16:20:42.00ID:mhUDdxzXマジか
bitcoinもびっくりの冗長性ですな
適当なタイミングで新規プロジェクトにするしかないのかな
0137デフォルトの名無しさん
2015/04/08(水) 16:25:51.16ID:uhPXCuzk新規プロジェクトにしなくてもリベースを使えば過去の歴史をまとめてしまうことができるよ
でもリベースしたら最新のファイルの状態が一緒でもコミットとしては別物だからね
0138デフォルトの名無しさん
2015/04/08(水) 16:41:12.55ID:xOKsYf2d0139デフォルトの名無しさん
2015/04/08(水) 17:04:19.20ID:Uu6WjhLvGCが実行されて未参照になったコミット（歴史書換など）は2週間で消えていく
ブランチ、タグ、リモート、reflog、今チェックアウトしているブランチを
全て削除してgit gc ―prune=nowを実行すれば空のリポジトリに戻るよ
0140デフォルトの名無しさん
2015/04/08(水) 17:54:43.99ID:uhPXCuzkhttp://qiita.com/usamik26/items/7bfa61b31344206077fb
こういう方法(shallow clone)もあるので、それで問題が無ければ使えばいい
0141デフォルトの名無しさん
2015/04/08(水) 18:02:21.54ID:mhUDdxzXローカルにも同じだけ履歴を持つ方が珍しいと思ってました
0142デフォルトの名無しさん
2015/04/08(水) 20:53:19.08ID:gn+rALV1珍しいっていうか、最近VCSは全てそうなんじゃないのかな？
説明しなくてもすぐに思いつくと思うけど、
ローカルに履歴全部を持ってないと都合が悪いからね。
例えば、ネットワークが切断されている状態では
ローカルに持ってない情報を参照できない。
いつバグが入ったか昔をさかのぼって調べるとか、
数年前まで遡って調べることはよくある話。
あと、ネットワークに繋がっていたとしても
いちいちネットワークアクセスしないといけないから
遅いという問題が有る。
デメリットとしては、ディスク容量を多く使用してしまうっていうのがあるけど
正しく使っていれば（つまりExcelファイルや生成済みのバイナリ等を入れない）
テキスト関連のファイルが主になるので、多いくても数十MB程度。
0143デフォルトの名無しさん
2015/04/09(木) 08:21:03.90ID:I6al/A0qネットワークから切断された状態で開発なんてしない
ネットワークは十分高速
バグがいつ作り込まれかを何年も遡って調べるんなんてめったにない
なら、別にローカルに持つ必要はないわな
ただ分散 VCS だとリポジトリをローカルに持つから履歴もローカルにあるってだけじゃね？
そもそもサーバーって言う概念がそぐわないし...
0144デフォルトの名無しさん
2015/04/09(木) 14:58:53.14ID:Y8qSNfSy中央にサーバがほしいんだよな
ローカルのログはローカル、全体のログは全体で
できればそれぞれ別個に管理したい
0145デフォルトの名無しさん
2015/04/09(木) 18:11:05.42ID:ASRAwZv5>>140のshallow cloneを使えよ
分散VCSを使いこなせない社畜にはお似合いだよ
0146デフォルトの名無しさん
2015/04/09(木) 21:06:04.36ID:2p1dJHe9ちったぁマシな反論の仕方覚えようぜ
（俺は）ネットワークから切断された状態で開発なんてしない
（俺の）ネットワークは十分高速
（俺は）バグがいつ作り込まれかを何年も遡って調べるんなんてめったにない
お前がどうするかじゃなくて、お前ではないある人が、
実際にこの問題にぶち当たるだろｗ
お前解決策は（俺が）頑張るっていう方法であって
ツールの話をしていない。
今はgitというツールの話をしてる。
gitがこの点でツールとして優れているのは間違いだろ。
0147デフォルトの名無しさん
2015/04/09(木) 21:07:03.42ID:2p1dJHe9> 中央にサーバがほしいんだよな
中央とローカルの両方に
リポジトリが有るのがgitだよ。
中央のサーバーしかないものより
優れている。
0148デフォルトの名無しさん
2015/04/09(木) 23:13:32.45ID:VwJ1oW5m0149デフォルトの名無しさん
2015/04/10(金) 11:00:44.87ID:vGbO0SDK0150デフォルトの名無しさん
2015/04/10(金) 11:11:00.15ID:VmzPrHvp0151デフォルトの名無しさん
2015/04/10(金) 11:13:09.89ID:vGbO0SDKやっぱ迷惑かな
pullとかpushとかmergeとか使う機会がない・・・
0152デフォルトの名無しさん
2015/04/10(金) 11:20:04.73ID:vGbO0SDKローカルで練習します
0153デフォルトの名無しさん
2015/04/10(金) 12:13:18.23ID:JdCgojns自分のアカウントでやる文には問題ないが
複垢でフォークしたりプルリクした時に赤BAN食らったことある
メールで俺はスパムじゃないって伝えれば凍結解除される場合もあるそうだが俺は解除されなかった
凍結された場合はサービスを利用することはできるが他人からは自分のアカウントが見えなくなる
アカウント一個で自分のリポジトリに対してプルリクして練習するのは問題ない
0154デフォルトの名無しさん
2015/04/10(金) 12:27:24.48ID:vGbO0SDKそんなペナルティがあるの？
完璧に廃案ですね
0155デフォルトの名無しさん
2015/04/10(金) 13:05:04.84ID:qlTKx4Z2サーバーのつもりのディレクトリにbareのcloneをつくる。
練習用ディレクトリでremote set-urlでサーバーのつもりディレクトリを設定。
pushなりpullなりで遊ぶ。
別のディレクトリにサーバーのつもりのリポジトリをclone。
pushなりpullなりで遊ぶ。
これで複数箇所からのアクセスの練習ができる。
0156デフォルトの名無しさん
2015/04/10(金) 19:39:02.96ID:vGbO0SDKそれいいね、やってみます
皆さんありがと
0157デフォルトの名無しさん
2015/04/10(金) 21:15:19.55ID:+vp4nrUW0158デフォルトの名無しさん
2015/04/10(金) 21:27:24.79ID:mOGWHCum>>144
ありがとう。でも
gitのバージョンが古いので、shallow cloneだとそのあと
サーバにpushできなくなっちゃうんだよね
0159デフォルトの名無しさん
2015/04/10(金) 22:08:37.43ID:e5/HDRWr仕事でどうしても欲しい機能があるのにバージョンを上げられないとかひどい職場だな
0160デフォルトの名無しさん
2015/04/10(金) 22:36:50.81ID:/m+5Da0Aお前がどんな環境にいるのか知らんが
> ネットワークから切断された状態
> もしくはネットワークが低速
な環境で開発してる奴がどんだけいるんだ？
> gitがこの点でツールとして優れているのは間違いだろ。
落ち着いて、その真っ赤な顔を何とかしろよｗ
0161デフォルトの名無しさん
2015/04/10(金) 23:46:33.56ID:ka156RZjさすがにLANは繋がってるよな
0162デフォルトの名無しさん
2015/04/11(土) 01:13:48.91ID:VeSSjpYXだから人の話をするなって
そんなのその人の立場で変わる。
あえて言えば、電波の悪い
スタバでドヤリングとかあるだろ。
論点をすり替えずにツールの話をしろ。
0163デフォルトの名無しさん
2015/04/11(土) 01:15:49.28ID:jprZbhPvネットワークから切断された状態ってのは
ある人には有るんだよ。
0164デフォルトの名無しさん
2015/04/11(土) 01:21:30.62ID:5CJjlwliなぜリポジトリを奇妙な状態で運用したいのか、
まで立ち戻って質問した方がヨサゲ
0165デフォルトの名無しさん
2015/04/11(土) 08:53:53.30ID:aih7mS+Y人じゃなくて環境だろ
そもそもネットワークとか言い出したのは >>142 だし
>>163 みたいな状況がよく引き合いに出されるけど、そんな状況滅多にないだろ
飛行機でさえ WiFi 使えたりするしな
0166デフォルトの名無しさん
2015/04/11(土) 11:28:04.71ID:jprZbhPvだからそんな状況がめったにないのは、
お前という人の話だろ。
お前ん中ではそうなんだろうなの話をしているだけって気づけよｗ
0167デフォルトの名無しさん
2015/04/11(土) 11:29:34.47ID:jprZbhPv3G経由でVPNでつないで、SVNでブランチ切り替えとか
したくないわけでｗ
0168デフォルトの名無しさん
2015/04/11(土) 11:48:01.05ID:LbK5Z9ys0169デフォルトの名無しさん
2015/04/11(土) 11:48:46.02ID:aih7mS+Y> お前ん中ではそうなんだろうなの話をしているだけって気づけよｗ
そのまま返すわ w
そもそも、今時な会社で社外で開発とか無職の発想としか思えん
0170デフォルトの名無しさん
2015/04/11(土) 11:53:57.86ID:aih7mS+Ygit はローカルにリポジトリ持ってるからネットワークに繋がってなくてもコミットできる
特定の場合に便利だが、社内だとほとんど意味ない
ネットワーク繋がないとほとんど仕事ならないから
0171デフォルトの名無しさん
2015/04/11(土) 12:05:11.81ID:LbK5Z9yssvnのコミットに相当するのはgitのpushでしょ
0172デフォルトの名無しさん
2015/04/11(土) 15:03:59.96ID:aih7mS+Y> svnのコミットに相当するのはgitのpushでしょ
そう言う言い方するなら、ネットワークが必要となる状況が違うってこと
svn はネットワークに繋がってないとほぼなにもできないから
0173デフォルトの名無しさん
2015/04/11(土) 15:43:26.04ID:ZDatv+YPmasterブランチでコミットしたファイルを修正したいんです。
いったんmasterブランチに戻ってcommit --amendした場合、どうやってその更新内容をtestブランチに取り込めばいいですか？
0174デフォルトの名無しさん
2015/04/11(土) 16:28:50.45ID:jprZbhPv> そもそも、今時な会社で社外で開発とか無職の発想としか思えん
これだけオープンソースがたくさんある時代に何いってんの？ｗ
え？ お前のコード、極秘なん？
お前ん中の世界は狭いですねｗ
0175デフォルトの名無しさん
2015/04/11(土) 16:35:25.60ID:E+mDe4Gomasterの更新をtestに取り込みたいのなら、普通はmergeするだろ
0176デフォルトの名無しさん
2015/04/11(土) 18:06:59.33ID:aih7mS+Yオープンソースがどう関係するのか知らんけど、仕事のソースをリポジトリごと社外に持ち出すとか普通ないだろ
社外秘って言う言葉も知らんようだし、マジで無職なのかもな w
0177デフォルトの名無しさん
2015/04/11(土) 18:53:07.92ID:vaK5h5cHGPLや趣味の開発と、普通の会社での開発は違うから、
自分が書いたコードが極秘になるのは良くあることかと
0178デフォルトの名無しさん
2015/04/11(土) 19:01:20.97ID:9epD2/0o仕事の持ち出しが自由だとしてもそれがメリットに感じるのは若い内だけだよ
年取ってきたらそんなスタイルで仕事に向き合ってもまずいい事は無い
プライベートと仕事はこれでもかって程に線を引いておいた方が
最終的な効率が上がったりもするし
0179デフォルトの名無しさん
2015/04/11(土) 19:29:20.47ID:RWhwDI1tつまり需要はあった。
今時とか傾向の話しても、需要がゼロになるわけじゃない。
嫌な人はsvnでも何でも勝手に使っとけという話。
0180デフォルトの名無しさん
2015/04/11(土) 21:19:45.95ID:aih7mS+Y> つまり需要はあった。
そんな需要がどれ程あるんだ？
って話なのは理解できてる？
0181デフォルトの名無しさん
2015/04/11(土) 21:28:56.04ID:4o2Mh2tFネットで偉そうにしなきゃ死んでしまう病気にでもかかってるんですか？
0182デフォルトの名無しさん
2015/04/11(土) 22:31:52.69ID:RWhwDI1tお前が無理矢理そういう無意味な話に持っていきたいのはわかった。
サードパーティ製だったのが根幹に含まれたものが普及したんだから、需要わかるだろ。
0183デフォルトの名無しさん
2015/04/11(土) 22:42:29.28ID:d2KPF5yqローカルにコミット履歴をあまりたくさん持ちたくない
現状普通にやってると、自分のワークにも過去のコミットが
全部入っちゃうのでなんとかしたい
0184デフォルトの名無しさん
2015/04/11(土) 22:50:41.60ID:vaK5h5cH180が言ってるのは、オープンソースとか趣味じゃなくて
社内で開発してる間はあまり需要がない、って話じゃないかと
0185デフォルトの名無しさん
2015/04/11(土) 23:12:28.79ID:RWhwDI1t企業でgitが普及してないと思うってこと?
うちは客先へも関係会社ともgitでやり取りしてるが。
0186デフォルトの名無しさん
2015/04/11(土) 23:20:28.85ID:vaK5h5cH客先にソースコードをやりとりするって、一体何をしてるの？
0187デフォルトの名無しさん
2015/04/11(土) 23:25:08.42ID:s5hHym/Z当時はネットワークがプアだったけど現在は違うだろ？
って話
git のローカルコミットを dis ってる訳じゃない
>>185 も同じ勘違いをしてる
0188デフォルトの名無しさん
2015/04/11(土) 23:27:25.03ID:s5hHym/Z受託だとソースごと納入はよくあるから、ソースのやり取りはあると思う
直接 git でやり取りするのはでかい会社だと珍しいと思うが
0189デフォルトの名無しさん
2015/04/11(土) 23:37:56.91ID:nYC3Hc//社内ネットワークが不安定になった時、こいつの作ったものは全部メチャクチャになっちゃうんだろうな
0190デフォルトの名無しさん
2015/04/11(土) 23:40:19.01ID:RWhwDI1tgitが普及する前でもネットワークがプアとか、よっぽど小さい企業の話じゃないの。
だがそれでもdiffのレスポンスはローカルとネットワークで大きく違う。
俺はローカルコミットの話はしてない。
>>186
開発。
0191デフォルトの名無しさん
2015/04/11(土) 23:52:41.38ID:vaK5h5cH客先っていうのユーザーじゃなくて親会社、自分が子会社、関係会社が孫会社だったら、
親会社にソースを渡すのはありそうですね
でも仮にそうなら、それは親会社が提供する社内ネットワークの範囲内だから、
185の状況は親会社が偶然gitを使ってたから185はgitの各種機能にありつけてるけど、
ネットワークが高速で安定してるだろうし別にSVNでも良かったっていう風にも見えるね
0192デフォルトの名無しさん
2015/04/11(土) 23:53:54.46ID:jjWEFxJy0193デフォルトの名無しさん
2015/04/11(土) 23:55:50.82ID:vaK5h5cH開発は分かるんだけど、客先がユーザーなら、自社製品のソースコードを公開してしまう意味が分からなくて・・・
どうして自社のソースコードをユーザーに公開しなきゃならない状況に置かれてるのかを知りたかった
0194デフォルトの名無しさん
2015/04/12(日) 00:09:45.89ID:zXiy4YdAこのスレに初めて書き込むけど、貴兄の会社の社内ネットワークってそんなに不安定なの？
うちの会社は国内海外の関連会社が社内ネットワークにつながってるけど、
トラブルなんて年に一度もおきないけど。
それから、社内ネットワークが不安定になったとして、何で作ったソフトがめちゃめちゃになるの？
0195デフォルトの名無しさん
2015/04/12(日) 00:13:27.21ID:nOXR22gF> ネットワークが不安定な状況になるわけがない
とは書いてないが、マジでネットがダウンしたらほとんど仕事にならないだろ
うちは電話も IP だし、社内システムはほとんど Web だし手も足もでなくなる
そもそも会社で開発してる奴は四六時中コーディングしてる訳じゃないから、コーディングだけできてもしょうがないしな
> 社内ネットワークが不安定になった時、こいつの作ったものは全部メチャクチャになっちゃうんだろうな
この発想が無職の発想 w
>>190
リーナスは Linux のソースコード規模に対しては遅いと考えていたみたいよ
0196デフォルトの名無しさん
2015/04/12(日) 00:19:15.46ID:nOXR22gF受託開発したことないの？
例えば銀行とかのシステムって銀行自体が開発してるんじゃなくて（実際は間に色々入るけど）、開発会社にこんなもの作ってくれって依頼するわけ
当然その銀行の専用品だし、開発費は銀行持だからソースコードも含めて銀行に納めるという契約形態があるってこと
0197デフォルトの名無しさん
2015/04/12(日) 00:51:27.53ID:eHprCcSu親会社が提供したgitのいちユーザだが管理者ではないといったところか
0198デフォルトの名無しさん
2015/04/12(日) 01:03:54.01ID:m18WDRtRお前らってIT企業を何社も転職して色々な現場を見てまわったの？
0199デフォルトの名無しさん
2015/04/12(日) 01:06:55.19ID:BQBr0rdt親会社ってなんの話だ？
受託って資本関係にない会社からの依頼（注文）もあるぞ（って言うか、うちだとその方が多い）
あと、受託した仕事の一部または全部を他の会社（いわゆる外注さん）に頼むこともあるし
0200デフォルトの名無しさん
2015/04/12(日) 01:10:51.77ID:bxSemNlo自分の会社以外にお客さん、外注さん、グループ会社とかの人と話したりするから
全部を知ってるという訳じゃないけど、環境という面だとそんなに突飛な環境ってあんまりないし
0201デフォルトの名無しさん
2015/04/12(日) 01:16:05.70ID:eHprCcSu親会社じゃなくて発注元って言うのが正しいんだろうが
言いたいことは変わらないから気にしないで
0202デフォルトの名無しさん
2015/04/12(日) 01:19:28.61ID:w/X68p6y同業者と情報交換したりしないのか?
>>197
提案して客に使わせる方が多いかな。
gitだと大体すんなりOKしてくれる。
そのどっちが上とかいう思考だから分散型に適応できないんじゃないか。
0203デフォルトの名無しさん
2015/04/12(日) 01:28:23.59ID:eHprCcSuお客さんとはユーザーじゃなく発注元だろうか
自分はインドの関連会社とアメリカの関連会社に出向して働いたことがあるが
環境は発注元の意向の影響を強く受けてた
自分がそこから動かずに話を聞いて回っても
おそらくみんな「実は発注元の意向」で揃ってしまうのでは
0204デフォルトの名無しさん
2015/04/12(日) 01:28:28.60ID:BQBr0rdt> そのどっちが上とかいう思考だから分散型に適応できないんじゃないか。
とか書きながら、
> 客に使わせる方が多いかな。
とか、上から目線で笑たわ
こんなアホが提案してきたら即出入り禁止にするわ
0205デフォルトの名無しさん
2015/04/12(日) 01:34:34.47ID:BQBr0rdtケースバイケースとしか言いようがない
環境は全て自社で成果物のみ納入もあるし
環境は自社だけど発注元とソースを共有してやるケースもあるし
請け負いと言いつつ、客先に入って客先の環境で開発とか、偽装だろそれってのもある（と聞いたことがある、と言っておこう w）
0207デフォルトの名無しさん
2015/04/12(日) 01:54:20.89ID:eHprCcSu確かに
学生か研究者が想像で話してるだけだろう
>>205
自分も似たようなシーンを見たことがある
関連会社さんと契約形態が変わるタイミングで特に面白いことになりやすい
0208デフォルトの名無しさん
2015/04/12(日) 01:57:45.56ID:4195b+YJ個人のプロジェクトとかでネットワークがない、もしくは
遅かったり不安定だったりする場合があるので
そういうい場合にgitが役に立つわけよ。
0209デフォルトの名無しさん
2015/04/12(日) 02:25:49.71ID:eHprCcSuそもそもこれは>>174から始まった「企業がgitを使う理由」が
イミフな方向に流れただけだから気にしないで
0210デフォルトの名無しさん
2015/04/12(日) 02:54:32.65ID:4195b+YJまあ企業もオープンソースの開発してますがね。
0211デフォルトの名無しさん
2015/04/12(日) 03:17:08.50ID:w/X68p6yプライドだけは高いんだなw
一番面倒なタイプだわ
0212デフォルトの名無しさん
2015/04/12(日) 06:29:26.07ID:RIZsoiA7ならばリベースだな
0213デフォルトの名無しさん
2015/04/12(日) 07:35:01.53ID:BQBr0rdtそう言う機会が全くないとは言わないけど、個人のネットワーク環境も改善してるからなあ
MVNO 使って 1,000円前後で移動中でもネットワークに接続できるようになるとは思わなかったよ
>>210
>>167 に会社のって書いてるから
>>211 と同一人物かどうかは知らんけど、両方とも今時の会社の開発環境をよく知らないんだと思う
0214デフォルトの名無しさん
2015/04/12(日) 08:30:26.39ID:OxabzWT0君相当レベル低い会社でしょ？基幹とか触れた事ないでしょ？数億円程度の案件で「俺って超デカイ事やってるんだぜ？」とか言ってるんでしょ？www
0215デフォルトの名無しさん
2015/04/12(日) 09:01:40.87ID:4195b+YJいやビックリした、年に一度もトラブらないからセキュリティの事を考えるのは無職なのかぁ〜。笑いとまらねぇww
無職がいっぱいですねｗｗｗ
0216デフォルトの名無しさん
2015/04/12(日) 09:04:42.03ID:4195b+YJ○○という技術を選んだために
ネットワークがないと使えませんでした。
俺のせいじゃない。○○が悪いんだ。
とかいっても、客はそんなこと関係ないわけで。
そこでgit使っていればよかっただろ？って客に言われでもしたら。
う、うるさい！俺はgitは使えないんだって声に出して言えないわけで。
世の中に優れたツールがあるのなら
それに移行するのも仕事のうち。
0217デフォルトの名無しさん
2015/04/12(日) 09:20:51.12ID:w/X68p6y重症だな
0218デフォルトの名無しさん
2015/04/12(日) 09:56:48.04ID:BQBr0rdt一生懸命考えたんだろうけど、アホみたいだからやめた方がいいよ
一年に一回程度のダウンに備えたシステムにするより、その場合にどう運用するかを考えた方がいい
あと、>>195 にも書かれてるがコーディングだけやってる訳じゃないから git だけ使えてもあまり意味ないし
>>217
同業者に聞いてみなよ w
大体似たようなもんだぞ
0219デフォルトの名無しさん
2015/04/12(日) 09:58:21.90ID:4195b+YJあのー。ノートパソコンでいつもと違う場所から
githubを触るってことは普通にあるんですが？
その時にブランチ切り替える程度で待たされるんじゃ
いらいらしますよね。
gitならブランチ切り替えはディレクトリ移動と
変わらない速度で行えます。
0220デフォルトの名無しさん
2015/04/12(日) 10:00:27.69ID:4195b+YJまた屁理屈に引っかかるところだった。
結局「俺は」問題ないっていう人の話をしていて、
ツールの良し悪しの話じゃなくなってるね。
ま、ツールじゃgitが優れていることを否定出来ないんで
必死で、俺は、俺は！ 俺はぁ！！！ なくても平気
っていう屁理屈でごまかしてるｗ
0221デフォルトの名無しさん
2015/04/12(日) 10:02:29.97ID:w/X68p6yではどんなのか書いてください。
エンタープライズでも組み込みでも使われているその環境とやらを。
0222デフォルトの名無しさん
2015/04/12(日) 10:11:32.03ID:OxabzWT00223デフォルトの名無しさん
2015/04/12(日) 10:45:13.86ID:BQBr0rdt> あのー。ノートパソコンでいつもと違う場所から
> githubを触るってことは普通にあるんですが？
で、そのノートパソコンは今時ネットに繋がってないの？ w
>>221
どのレベルで書けって言ってるんだ？
情シスの人間じゃないから基幹の構成とか聞かれても困るんだが...
>>222
はいはい、
ぼくにとってはすうおくえんのあんけんなんてたいしたことないんぞ
ってか w
0224デフォルトの名無しさん
2015/04/12(日) 12:06:37.95ID:eHprCcSuメーカー系の子会社で5年以上働いてる
>>202
大学のサークルっぽいベンチャーで働いてる
0225デフォルトの名無しさん
2015/04/12(日) 13:18:51.68ID:mwW7jAChそれより事の発端である>>134の動機が気になる
0226デフォルトの名無しさん
2015/04/12(日) 13:44:16.44ID:eHprCcSu＞そこでgit使っていればよかっただろ？って客に言われでもしたら。
＞う、うるさい！俺はgitは使えないんだって声に出して言えないわけで。
そこが違うな
発注元は「うちがSVNを使ってるんだからSVNを使え」と言うだけ
じゃあ>>202の話は一体なんなのかというと
「自分がいる研究室の教授にgitを提案した話」をしてるだけだろう
（話を膨らませ過ぎたせいでイミフなことになってはいるが・・・）
0227デフォルトの名無しさん
2015/04/12(日) 14:06:46.60ID:RIZsoiA7バージョン管理システムについて語るスレ10
http://peace.2ch.net/test/read.cgi/tech/1393147031/
0228デフォルトの名無しさん
2015/04/12(日) 14:27:58.18ID:4195b+YJ> で、そのノートパソコンは今時ネットに繋がってないの？ w
つながっていても遅いですよ？
ブランチ切り替えごときで
数秒も待たされるなんて
やってられないですからねｗ
0229デフォルトの名無しさん
2015/04/12(日) 14:30:13.71ID:BQBr0rdtそうなんだ、辛いね w
0230デフォルトの名無しさん
2015/04/12(日) 14:56:47.47ID:eHprCcSu趣味でやるなら我慢できなくても会社でやるなら我慢しなきゃならない事がある
って概念が>>228にはないのだろう
0231デフォルトの名無しさん
2015/04/12(日) 15:05:00.40ID:4195b+YJ根性があるって評価されるよ！（大爆笑）
早く仕事しろや
0232デフォルトの名無しさん
2015/04/12(日) 15:17:57.99ID:w/X68p6yどのレベルかわからないで、どこも環境一緒だとか言ったのか。
話にならないな。
0233デフォルトの名無しさん
2015/04/12(日) 15:20:36.24ID:w/X68p6y経験ない新人じゃ提案して改善とか恐れ多いもんな。
0234デフォルトの名無しさん
2015/04/12(日) 15:26:16.19ID:+Dwi8kJe0235デフォルトの名無しさん
2015/04/12(日) 15:26:42.33ID:BQBr0rdt別に git 使うなって話をしてる訳じゃないんだけどな w
0236デフォルトの名無しさん
2015/04/12(日) 16:00:55.68ID:BQBr0rdt> エンタープライズでも組み込みでも使われているその環境とやらを。
組み込みと言っても、いろんな種類があるから、単に環境説明しろとか言われても困るわ
まさか個々に説明しろとでも言うのか w
ただ、言えるのは今時特殊な場合を除いてネットワーク接続されてるのは当たり前ってこと
0237デフォルトの名無しさん
2015/04/12(日) 16:16:25.20ID:w/X68p6yいやどこでも一緒なんでしょ?
繋がってれば何でもできると思ってるのか。
セキュリティポリシーとか、各社違うと思うが。
0238デフォルトの名無しさん
2015/04/12(日) 16:41:41.04ID:BQBr0rdt> いやどこでも一緒なんでしょ?
誰がそんなこと言ってるんだ？
> 繋がってれば何でもできると思ってるのか。
権限さえあれば、開発者から開発に関係することはできるだろ
> セキュリティポリシーとか、各社違うと思うが。
で、開発に使えないセキュリティポリシーってなに？ w
0239デフォルトの名無しさん
2015/04/12(日) 17:00:52.93ID:4195b+YJはい。ネットワーク必須なものより、
ネットワークを使っても使わなくても出来るし、
ネットワークがどんなに早くても（サーバー側の処理もあるし）
ローカルディスクの速度にはかなわないので
gitの方が優れており快適に開発できるって話をしてます。
0240デフォルトの名無しさん
2015/04/12(日) 17:54:56.18ID:BQBr0rdtなるほど、関係ない話にわざわざ割り込んできてアホさらしてたってことね
了解した、後は勝手にやっててくれ w
0241デフォルトの名無しさん
2015/04/12(日) 17:58:37.01ID:4195b+YJさようなら。これで話は解決しました。
0242デフォルトの名無しさん
2015/04/12(日) 18:21:31.75ID:eHprCcSu>>202にしても>>241にしても「自分は下請けの一技術者の立場でありながら
発注元にソース納入方法を提案できるほどのスーパーエンジニアだという妄想」
を絡めながら話をするもんで話の流れがどうしてもこじれやすい
正直言ってこいつらを相手に実運用がどうこうの話をしたところで無駄だと思う
まともな会社に入れるように就職活動頑張ってくれとしか言いようがない
0243デフォルトの名無しさん
2015/04/12(日) 18:42:23.71ID:PnxXuVRGそれって、あんたの妄想ですよね？ｗ
それに世の中にはスーパーエンジニアがいるわけで、
自分が必要ないから、必要ないんだ！という主張は
個人環境の問題であって、世界が狭いとしか思えませんね。
0244デフォルトの名無しさん
2015/04/12(日) 18:48:44.72ID:O3Q2YdhU0245デフォルトの名無しさん
2015/04/12(日) 19:21:33.74ID:eHprCcSu国内メーカー系だと機密情報扱いのソースコードを社外サーバに置くのが無理だよな
課金スマホゲーを作って儲けたい小さいベンチャー企業とかだと使ってたりするのだろうか
0246デフォルトの名無しさん
2015/04/12(日) 19:41:13.93ID:8HUyaP1H0247デフォルトの名無しさん
2015/04/12(日) 20:21:44.96ID:PnxXuVRGgithubみればわかるんじゃないですか？
0248デフォルトの名無しさん
2015/04/12(日) 20:23:06.86ID:w/X68p6y> で、開発に使えないセキュリティポリシーってなに？ w
意味が不明です。
ポリシーに合わせて開発方法も変えるものではないの?
> 誰がそんなこと言ってるんだ？
218 デフォルトの名無しさん sage 2015/04/12(日) 09:56:48.04 ID:BQBr0rdt
>>217
同業者に聞いてみなよ w
大体似たようなもんだぞ
0249デフォルトの名無しさん
2015/04/12(日) 20:28:26.94ID:w/X68p6yスーパーエンジニアじゃなくても、顧客がIT系じゃない一般企業とかなら、サーバの選定とかから提案するよ。
0250デフォルトの名無しさん
2015/04/12(日) 20:44:27.70ID:eHprCcSu顧客が発注元じゃなくてIT系じゃないユーザなら
ソース管理ソフトの提案をする意味がなおさら分からん
0251デフォルトの名無しさん
2015/04/12(日) 21:04:58.26ID:w/X68p6yウェブ系やってるから、よくデザインは別のとこがやる。
そうでなくても、メンテを他の会社が請け負う可能性もあるし、数年後にまたうちが請け負うかもしれない。
履歴とはそういう時のためにあるんじゃないのか。
自分のためだけで、顧客のためという考えはないのかな。
0252デフォルトの名無しさん
2015/04/12(日) 21:23:43.78ID:BQBr0rdt> ポリシーに合わせて開発方法も変えるものではないの?
だから、その開発方法を変えないといけないポリシーってなに？
一時社外からのアクセス云々で会社間のやり取りでゴタゴタしたことあったけど、最近はそう言うところも整備されてるのが普通だし
会社によっては社外のクラウド使う/使わないの違いがあったりするけど、開発方法には影響しないようにしてるし
> 同業者に聞いてみなよ w
> 大体似たようなもんだぞ
（VxWorks + ARM の機器組み込みやってる会社同士とか、Windows のアプリケーション作ってる会社同士では）
大体似たようなもん
って言う話だぞ
そこまで説明しないとダメなの？
0253デフォルトの名無しさん
2015/04/12(日) 21:28:24.48ID:xjf6EDI60254デフォルトの名無しさん
2015/04/12(日) 21:43:40.95ID:eHprCcSuWeb業界だとそんな風になってんのね
自分は製品開発でソースコードはビジネスのコアになる機密情報だからそれを客に公開するっていう発想がなかった
Webだと作ったものは一社ごとの専用品で個別の規模は小さく発注元も他の発注先も技術が分かる人間は絡まない
ソースコードはユーザから（発注元からも客からも）ほとんど丸見え
ソースコードに技術的な秘密がない
万一gitのアカウントが割られて中を見られても損をするのは発注元だけ
そんな状況だったら自分からgitを提案するってのも確かにありうるな
0255デフォルトの名無しさん
2015/04/12(日) 22:07:30.29ID:PnxXuVRG> 万一gitのアカウントが割られて中を見られても損をするのは発注元だけ
gitじゃなくてgithubだろ
別にgit自体はオープンにしなくても使える。
0256デフォルトの名無しさん
2015/04/12(日) 22:15:46.94ID:eHprCcSugithubかどうかは>>251に直接聞きますか
個人的にはgithubだと思ってるが
>>254みたいなケースだと案件規模が小さすぎてそれぞれの客に
gitサーバを立ててもらうのが理にかなってないように感じられる
0257デフォルトの名無しさん
2015/04/12(日) 22:25:39.81ID:xjf6EDI60258デフォルトの名無しさん
2015/04/12(日) 22:36:59.55ID:w/X68p6y開発プラットフォームごとに違うってことね。
> 今時の会社の開発環境をよく知らないんだと思う
今時のプラットフォームはあなたの会社の一種類以外、話から除外されるってことね。やはりあなたの会社がスタンダードなんだね。
>>254
googleやfacebookでもスクリプト言語使われてると思うけどね。難読化しなきゃだね。
VPSとかsshかけてたりするから、破られたらgitでも何でも関係ないけどね。
話の発端に戻って、分散でないsvnだと安全になるの?
0259デフォルトの名無しさん
2015/04/12(日) 23:00:10.10ID:PnxXuVRGWindowsしか使えないという底辺クラスの技術力なのに
gitを導入しようとしているらしい。もちろんGUIで。
Linuxの導入は誰も使えないから認められないらしいｗ
世の中にはこういう底辺だって有るんですよ！
0260デフォルトの名無しさん
2015/04/12(日) 23:02:47.20ID:PnxXuVRG> 話の発端に戻って、分散でないsvnだと安全になるの?
なるわけがない。遅いくて過去の履歴が無かったりするとはいえ
ローカルPCにソースコード全部持ってきてるんだから
0261デフォルトの名無しさん
2015/04/12(日) 23:03:21.34ID:eHprCcSuスクリプト言語っていってもユーザに見えないサーバ側のスクリプトと
ユーザに見えるクライアント側のスクリプトじゃ話が違うだろうし
難読化したらあなたが言ってる「客のためを思ったソース公開」じゃ
なくなるな
＞話の発端に戻って、分散でないsvnだと安全になるの?
何を発端と言ってるか分からんが>>245ならgithubの話だな
言っても分からんとは思うが国内メーカーは自分が作る「製品」の
ソースコードはビジネスの核だとみなしている
それが自分たちの管理が届かない社外に置かれることを嫌がる傾向が強い
0262デフォルトの名無しさん
2015/04/12(日) 23:07:12.80ID:PnxXuVRGソースコードを置くわけですよ。
0263デフォルトの名無しさん
2015/04/12(日) 23:08:58.08ID:PnxXuVRG難読化じゃない。ファイルサイズを削減するために
単語を短く置き換えてるだけだ。
難読化というのは、無意味なコードを入れたりして
コードを理解づくらくすること。
0264デフォルトの名無しさん
2015/04/12(日) 23:13:11.50ID:eHprCcSuそうすると、今度はSVNでいいじゃんって話になる
その話が>>174からずっと続いている
0265デフォルトの名無しさん
2015/04/12(日) 23:17:45.05ID:PnxXuVRGは？ おかしくね。
svnでもgitでもどちらも
安全でも危険でもない。
これがここまでの結論だが？
安全か危険かで差は出ないんだからこの話は同じ。
別の理由でどちらが優れているかを語るべきだろ
0266デフォルトの名無しさん
2015/04/12(日) 23:25:58.07ID:w/X68p6y新規鯖でBTS連携が多いな。結局開発サーバ必要だし。
客によってgithubとか他の商用のもあったりするけど。
0267デフォルトの名無しさん
2015/04/12(日) 23:30:55.66ID:uj+lty2x本当に底辺だよね。
だってさ、
1. PCを用意
2. Linuxのインストール（インストーラーから）
3. gitlabのインストール (インストールパッケージが用意されてる）
4. gitlabにログイン
これだけで終わりなんだから。
もう難しいかどうかじゃない。
単に面倒だからやりたくないという
めんどくさがりなだけだよ。
0268デフォルトの名無しさん
2015/04/12(日) 23:32:31.69ID:eHprCcSu＞別の理由でどちらが優れているかを語るべきだろ
その必要は無い
gitがあるのにSVNとかを使い続ける理由は「乗り換えなくて済む」
「どうしてもgitに乗り換えなければならない理由がない」なんだから
じゃあgitの勝ちって言ってみたって結局gitは使われてない
gitを使わない経営者が頭悪いわけでもない
その状況を含めなければ比較のしようがないしそれは無理だろう
0269デフォルトの名無しさん
2015/04/12(日) 23:37:37.38ID:uj+lty2xあー、こりゃだめだ。負けるよ？
だって他の所は、最初っからgit使ってる。
優れたツールをさ。
優れたツールから「乗り換えなくて済む」人たちに
どうやって対抗するのさ？ｗ
まあ、定年まで生き延びればそれでいいって
考えなんだろうけどさ。
0270デフォルトの名無しさん
2015/04/12(日) 23:38:35.63ID:w/X68p6y> 別の理由でどちらが優れているかを語るべきだろ
その流れに進むのだと、>>227 だな。
わざわざgitスレに来て分散要らないと、適応できない人が言ってるだけ。
gitで中央管理するのは構わないと思うけど、本来の使い方でないので一手間増えるのが不満なんじゃないかな。
>>179 嫌な人はsvnでも何でも勝手に使っとけという話。
で終わりだと思うけど。
0271デフォルトの名無しさん
2015/04/12(日) 23:42:14.40ID:uj+lty2x> gitで中央管理するのは構わないと思うけど、本来の使い方でないので一手間増えるのが不満なんじゃないかな。
えー？ 何いってんの？ 中央管理は必要だし、
git使ってるプロジェクトのほぼ全て、
中央と呼ばれるところがあるじゃん。
公式リポジトリのことだよ。
お前全然わかってないよ。
0272デフォルトの名無しさん
2015/04/12(日) 23:50:17.52ID:w/X68p6yはいはい。
0273デフォルトの名無しさん
2015/04/12(日) 23:51:41.80ID:eHprCcSuデザインを別会社に発注するんならソース管理の責任は発注元もちだからサーバは客側に置かれるんだよね
客に○十万くらい払ってもらって社外公開用gitサーバを立てる感じか
小規模案件でも「一見して無駄金」を払ってくれたりするものなんだな
それを最終的にWebサーバに転用するから平気だってことなんだろうか・・・
>>269
つまりそれがベンチャーと国内メーカーの違い
国内メーカーもそれを分かってて使えない個人を淘汰するがそのスピードは遅い
ベンチャーだと労働組合がないしそもそも会社ごと淘汰されるのでスピードが速い
はじめはどの会社もベンチャーだった
生き残った会社は信頼性を持ち仕事の進め方もこなれてくるし良い人材も来るが
実は長く生きたこと自体が欠点だ
0274デフォルトの名無しさん
2015/04/12(日) 23:52:17.73ID:w/X68p6y0275デフォルトの名無しさん
2015/04/12(日) 23:57:32.09ID:w/X68p6yお前が専用サーバでないとgit運用できないのは良くわかったよ。
そして、サーバの選定できないことも。
0276デフォルトの名無しさん
2015/04/12(日) 23:58:15.67ID:eHprCcSu実際はそんな単純な「一手間」とかの話しじゃなくて
使えないおっちゃんにコミットは何かプッシュは何かを教育する事が困難
gitを使えないからって理由でクビにすることはできないし
0277デフォルトの名無しさん
2015/04/13(月) 00:00:16.82ID:qmARc52C何に切れてるのかさっぱり分からん
少なくとも自分は「製品開発」だからWebサーバの選定はしないしできない
0278デフォルトの名無しさん
2015/04/13(月) 00:04:23.76ID:zNUrQ3MRクビにするかどうかは、経営者の判断することなので知らん。
リーダーだった場合、使用しているツールを使えない技術者が来たからといって、ツールを変えるようなことはしない。閑職に追いやる程度。
git程度を使えない技術者は終わってると思うが。最低限な。
0279デフォルトの名無しさん
2015/04/13(月) 00:14:36.04ID:qmARc52Cgit程度を使えない技術者って、40を超えてくると時々見かけそうな
仕事ができて偉くなるオッサンはみんな過去の経験を活かした人材マネージメントの方に回ってしまうし
仕事ができなくて偉くならないオッサンは何も出来ない
仕事ができて偉くならずに担当者として先頭を突っ走るバリバリの技術者ってのはホント少ない
0280デフォルトの名無しさん
2015/04/13(月) 00:19:44.73ID:4JvI4/ec0281デフォルトの名無しさん
2015/04/13(月) 00:26:29.81ID:NT6jaiFf放置すりゃいいのに相手するから生きながらえる
0282デフォルトの名無しさん
2015/04/13(月) 01:06:13.44ID:zNUrQ3MRなぜ切れていると思い込んでるのかサッパリだ。
できないなら>>273は妄想ってことだな。
>>279
gitのリポジトリの構成を決めろとか言うわけではない。
決まったオペレーションができれば十分。最低限。
偏ってる企業だと1人1プロジェクトとかかも知れないけど、そんな老い先知れた企業のことは知らん。
0283デフォルトの名無しさん
2015/04/13(月) 01:25:41.23ID:l/TWvXzvパソコンにOS（Linux）のインストールも出来ない
素人がいるのも事実。
0284デフォルトの名無しさん
2015/04/13(月) 02:06:56.36ID:qmARc52C>>273は妄想じゃなくてあなたへの質問だったのだが急に答えるのをやめたから切れたのかと思った
漠然と否定するんじゃなくて訂正してもらえるとWeb系エンジニアの一つの実情を知れるので勉強になる
>>283
Linuxのカーネルを改造してる技術者がWordの蛍光ペンの付け方を知らないってことがあったので
自分ができることをそいつができないから「技術者として終わってる」というのは案外そうでもないと思ってる
0285デフォルトの名無しさん
2015/04/13(月) 03:19:23.81ID:zNUrQ3MR仮想とか使ってるとこは、設定するだけ。
性能は必要ないので、借りても月千円とか二千円で要件は満たせる。
これ以上はスレチ過ぎるのでどっか他で聞いて下さい。
知らないと出来ないは違うんじゃ。
0286デフォルトの名無しさん
2015/04/13(月) 06:05:45.95ID:Nl26Y8lL> 今時のプラットフォームはあなたの会社の一種類以外、話から除外されるってことね。やはりあなたの会社がスタンダードなんだね。
いったい何を言いたいのか全くわからんのだが w
0287デフォルトの名無しさん
2015/04/13(月) 06:46:15.23ID:NPPeHBbvLinuxのインストールなんて「知ってりゃできる」レベルだろ？
0288デフォルトの名無しさん
2015/04/13(月) 09:12:02.50ID:l/TWvXzvだが恐ろしいことに、出来ないという人がいるんだよ。
自称技術者なのにな。本当に可哀想。
0289デフォルトの名無しさん
2015/04/13(月) 10:33:40.14ID:qmARc52Cなるほどケタ違いに安かったんだ
だからあなたがやってるみたいな「極めて小規模案件」にも対応できるのか
スレチなのは確かだがこのスレはgitの製品機能だけじゃなく
gitの運用シーンとその背景（マネジメントやら業務の特性やら）がごちゃまぜに話されてるから
前からずーっとスレチだったという気がしないでもない
0290デフォルトの名無しさん
2015/04/13(月) 12:11:13.75ID:5Ev+MSHpあと今どきVPS知らない人とも話が通じないでしょ
0291デフォルトの名無しさん
2015/04/13(月) 18:06:10.53ID:zNUrQ3MRgitの最低限の操作なんて知ってりゃできるレベル。
しかし知るまでは、知ってりゃできるレベルか否かわからない。
それで自信の無い人は出来ないという。または使いたくないので、知ろうともしない。仕事は任せられない。
まっとうな技術者の知らないは、調べてやりますの意味。多少のサポートは必要かも知れないが、仕事を任せられる。
というか、コンピュータのオペレーションは全て知ってればできるレベル。
0292デフォルトの名無しさん
2015/04/13(月) 18:44:49.69ID:PFHUoot30293デフォルトの名無しさん
2015/04/13(月) 22:01:32.53ID:l/TWvXzvやってることは同じことの繰り返し。
技術力とはそれを間違いなく早く繰り返せる力のこと
知識に加え、長年の経験とセンスが必要とされる。
小学校でねこふんじゃったを引ける人がクラスに一人ぐらい
いたと思うけど、実はねこふんじゃったは難しい曲らしい。
だからといってその子は凄いわけじゃなく、
ねこふんじゃったしか弾けないという。
何がいいたいかというと、難しいものでも定型化してそれだけをやるなら比較的簡単にできる。
だけど、応用ができないんじゃ技術力があるとは言えないんじゃないかな。
コンピュータのオペレーションだって、今までに起きたことがない
問題が起きた時に対応できて初めて一人前だと思うよ。
0294デフォルトの名無しさん
2015/04/13(月) 22:06:53.81ID:U9cAqNzb0295デフォルトの名無しさん
2015/04/13(月) 22:10:28.26ID:l/TWvXzvクラスに一人ぐらいいたと思うけど、実はねこふんじゃったは難しい曲らしい。だからといってその子は凄いわけじゃなく、ねこふんじゃったしか弾けないという。何がいいたいかというと、難しいものでも定型化
してそれだけをやるなら比較的簡単にできる。だけど、応用ができないんじゃ技術力があるとは言えないんじゃないかな。コンピュータのオペレーションだって、今までに起きたことがない問題が起きた時に対応できて初めて一人前だと思うよ。
0296デフォルトの名無しさん
2015/04/13(月) 22:35:09.37ID:/JCb38ulかなり単純で簡単な曲
0297デフォルトの名無しさん
2015/04/14(火) 00:11:29.45ID:Mnpx95ZS単にピアノの鍵盤と五線譜の相性が悪いことの問題
0298デフォルトの名無しさん
2015/04/14(火) 00:18:39.20ID:6fsUN43G引き継いで全体像を知らなければ苦労しそうだがそれは能力とあまり関係ないこと
0299デフォルトの名無しさん
2015/04/14(火) 01:35:10.67ID:wfCHFEB4git自体の設計や、リポジトリ設計、オペレーションマニュアルを作ること。
0300デフォルトの名無しさん
2015/04/14(火) 02:10:05.32ID:UqXDsIMl楽譜にしてもスカスカだし難しくはないと思うが
♭6個が難しく見えるってこと？
つまりgitも慣れてない人には難しく見えるって話か
0301デフォルトの名無しさん
2015/04/14(火) 07:30:46.14ID:hU+kLzALGitHub使ってるぽい企業みつけた
http://paiza.jp/job_offers/386
0302デフォルトの名無しさん
2015/04/14(火) 07:41:08.44ID:hU+kLzALhttp://paiza.jp/job_offers/554
0303デフォルトの名無しさん
2015/04/14(火) 07:52:07.35ID:ewVl24pp> ♭6個が難しく見えるってこと？
個人的には嬰ヘ長調(♯6個)の方が好き
0304デフォルトの名無しさん
2015/04/14(火) 10:40:27.73ID:CfmpsTw9初心者の意見だけど
0305デフォルトの名無しさん
2015/04/14(火) 20:02:42.34ID:oXtat876> コマンドなんて1回正しい手順覚えたらそれ繰り返すだけだしな
そういえば、教えられたコマンドを
メモ帳に書いて、それをひたすらコピペしている奴がいたな。
こういう時は、これ、
こういう時は、あれ、
その姿を見ていなければ、git使えているように見えるが、
何も理解していないという。
0306デフォルトの名無しさん
2015/04/14(火) 20:43:04.53ID:Q5r7cjjP0307デフォルトの名無しさん
2015/04/14(火) 20:58:47.86ID:ftm3iiW30308デフォルトの名無しさん
2015/04/14(火) 21:25:14.74ID:Q5r7cjjP入門時の流行等で使うシステムが決まる。
0309デフォルトの名無しさん
2015/04/14(火) 21:49:07.84ID:oXtat876subversionよりも圧倒的に速い。
0310デフォルトの名無しさん
2015/04/14(火) 21:54:22.43ID:oXtat876ピアノと一緒って話だろ？
鍵盤を叩くのはだれでもできることだが、
それを使って素晴らしい音楽を演奏するのは難しい。
gitのコマンドを叩くのは簡単だが、
それを使ってソフトウェア開発を
効率よくするのは難しい。
だから効率上がらないよとか言ってる人がいるわけよ。
0311デフォルトの名無しさん
2015/04/14(火) 23:34:02.72ID:wnoVepzTこいつ最高にアホ
0312デフォルトの名無しさん
2015/04/15(水) 20:27:20.03ID:GB/eL5ft0313デフォルトの名無しさん
2015/04/15(水) 20:38:14.05ID:6MF6OERw0314デフォルトの名無しさん
2015/04/15(水) 21:49:51.24ID:1RecYAvvどうせやるのはpushするだけなんだから。
現在コンフリクトが起きないようにする運用方法を模索中。
他の人が触れないようにロックができればいいんだけどな。
0315デフォルトの名無しさん
2015/04/15(水) 22:18:49.86ID:V2WyrPfJ0316デフォルトの名無しさん
2015/04/16(木) 01:28:27.36ID:Mp5pFy+1誰にも触れないようにネットワークから切り離せ
0317デフォルトの名無しさん
2015/04/16(木) 02:09:02.52ID:hUjU3Ohl0318デフォルトの名無しさん
2015/04/16(木) 09:11:33.22ID:bLWn78BUメインっていうか中央やね。
基本的にコマンドをたくさん使うところがメインなので
ローカルがgitということはgitがメインとなる。
そして最後のmasterブランチの代わりにsvnを使う。
その場合svnは単なるストレージ的な扱いになる
0319デフォルトの名無しさん
2015/04/20(月) 13:47:48.51ID:RwDqOFG9masterで.gitignoreを変更したんですが
masterの変更を開発ブランチに取り入れる方法を教えてください
開発ブランチでgit merge masterってやってもこんなメッセージがでました
addしてコミットしないとだめなんですか？開発ブランチからmasterにmergeするときはこんなメッセージ出ません
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: .gitignore
no changes added to commit (use "git add" and/or "git commit -a")
0320デフォルトの名無しさん
2015/04/21(火) 11:04:43.23ID:gKd17Ylm面倒臭いなgit
0321デフォルトの名無しさん
2015/04/21(火) 11:12:45.44ID:umXZ7BSe昨日、Cygwin新しくしてnoaclの設定忘れて作業始めちゃって酷い目にあった
git自体の設定でパーミッションの変更を無視するようにできるらしいけど、
その場合は新規ファイルのパーミッションはどうなるのかな
0322デフォルトの名無しさん
2015/04/21(火) 14:20:11.36ID:Z/Go+19e0323デフォルトの名無しさん
2015/04/21(火) 15:25:00.67ID:umXZ7BSeUnix系ならみたままのパーミッションで登録されるので安心
0324デフォルトの名無しさん
2015/04/21(火) 16:21:04.26ID:5PzRDxP4記録されるのは実行権限だけだよ。
実行権限をリポジトリに入れないと
困るのは言うまでもない。
0325デフォルトの名無しさん
2015/04/21(火) 16:21:44.23ID:5PzRDxP4> Windowsはとんでもないパーミッションでレポジトリにファイル登録しちゃったりすることがあるのが心配なの
登録されるのは実行権限だけだよ。
> Unix系ならみたままのパーミッションで登録されるので安心
登録されるのは実行権限だけだよ。
0326デフォルトの名無しさん
2015/04/21(火) 16:28:14.13ID:umXZ7BSe755とか644とかこれ実際には実行権限だけしか登録されないってこと？
0327デフォルトの名無しさん
2015/04/21(火) 16:46:16.84ID:5PzRDxP4は？ スクリプトファイルは
実行現原付きのソースコードだが？
0328デフォルトの名無しさん
2015/04/21(火) 16:48:49.11ID:Ys0gBcPs((((((；ﾟДﾟ))))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
0329デフォルトの名無しさん
2015/04/21(火) 16:50:25.56ID:5PzRDxP4つけたりつけなかったりする必要があるから
実行権限をリポジトリに入れる必要があるんだろ。
0330デフォルトの名無しさん
2015/04/21(火) 16:53:11.58ID:Ys0gBcPs理由が理解できないよ？(´･ω･｀)
0331デフォルトの名無しさん
2015/04/21(火) 16:54:39.89ID:5PzRDxP4CGIアップロードしてから、全部のファイルのパーミッションを
設定してから使うウェブアプリかよｗ
0332デフォルトの名無しさん
2015/04/21(火) 16:55:32.36ID:umXZ7BSeなるほどソースファイルは644で、スクリプトファイルは755で登録されればいいわけだな
Unix系の場合にはファイルのパーミッションの値に準じて登録されてると思うんだけど、
Windowsの場合にはどういう仕組みになってるんだ？
昨日Cygwinでソースファイルが755で登録されちゃってとても困ったんだが
0333デフォルトの名無しさん
2015/04/21(火) 16:58:21.33ID:5PzRDxP4なんでもきくな
0334デフォルトの名無しさん
2015/04/21(火) 17:01:42.91ID:umXZ7BSehttp://fourxz.hatenablog.com/entry/2013/12/13/003317
IntelliJ + cygwin の特殊な例だったんだな
おれの場合にはIntelliJの設定じゃなくてCygwin側のfatabでACLを無効にして対処した
こんなのpro git読んでもわかんねえよ
0335デフォルトの名無しさん
2015/04/21(火) 17:03:55.25ID:umXZ7BSe0336デフォルトの名無しさん
2015/04/21(火) 17:05:33.91ID:Ys0gBcPsいってることが前時代的なんで理解し難いけど？(´･ω･｀)
アップロードもインストールの一部だと考えれば、インストールスクリプトで
パーミッションを弄るよ？おいらならね？(´･ω･｀)
0337デフォルトの名無しさん
2015/04/21(火) 18:03:03.48ID:5PzRDxP4理解能力がないやつだなｗ
コンパイルしなくてすぐに実行できるのが
スクリプト言語のいいところなのに、
なんでそんな準備をしないといけないんだって話だよ。
cloneしてローカルで動かすとか思いつかないのか？
0338デフォルトの名無しさん
2015/04/21(火) 18:04:31.50ID:5PzRDxP4どうせサーバーにアップロードも
今どきFTPでアップロードして
パーミション設定とかしか思いつかないんだろうけど、
git使っていれば、git cloneしてハイおしまい。
なんだよ。
0339デフォルトの名無しさん
2015/04/21(火) 23:04:14.84ID:nTfDDlXC0340デフォルトの名無しさん
2015/04/22(水) 08:24:45.00ID:dTAen5CNそのインストールスクリプトは…
0341デフォルトの名無しさん
2015/04/22(水) 09:46:39.29ID:ZhuC/XHhパーミッションを変えるスクリプトをつけるに決まってるだろ
0342デフォルトの名無しさん
2015/04/22(水) 09:50:29.82ID:iit3/b2j0343デフォルトの名無しさん
2015/04/22(水) 10:07:21.92ID:gnynNjp+スクリプトファイルを入れておくと思うよ？(´･ω･｀)
0344デフォルトの名無しさん
2015/04/22(水) 11:07:07.29ID:ZhuC/XHh自分一人で作業することしか考えてないだろ。
って言われたらその場でまた言い逃れを考えて書き込むだけだから書くだけ無駄かｗ
0345デフォルトの名無しさん
2015/04/22(水) 11:40:56.36ID:sdnJBf1eその実行権限をそのままリポジトリに入れられないとなると、
ファイルに実行権限ついているというのに
それと同じ情報を別ファイルにまとめないといけない。
つまり情報が二重になってしまっている。
ローカルでテストコードを実行した時
（実行権限が付いているから）テストが成功するのに、
他のマシンでcloneしたらテストコードが失敗する。
実行権限情報が間違っていたからだ。
つまりアプリの信頼性にも関わってくる。
0346デフォルトの名無しさん
2015/04/22(水) 11:41:34.93ID:gnynNjp+0347デフォルトの名無しさん
2015/04/22(水) 11:43:31.12ID:gnynNjp+0348デフォルトの名無しさん
2015/04/22(水) 11:46:20.25ID:sdnJBf1eそりゃ、テストコードでスクリプトを実行している
コードに決まってるじゃんｗ
っていうかビルド自体が失敗するし
git のリポジトリ見てみな。
実行権限ついてるだろ？
それ全部外してmakeしてみな。
0349デフォルトの名無しさん
2015/04/22(水) 11:52:36.40ID:sdnJBf1ereadme関係ないからな。
実行権限という情報を二重に持つことがだめだって話。
ファイルについてる情報を
わざわざreadmeにコピペするんなよ。
素人かよｗ
0350デフォルトの名無しさん
2015/04/22(水) 13:38:15.27ID:xj2mf7xJinstall -m で指定するのが当たり前
つまらん揚げ足取りでスレ汚すなよ
0351デフォルトの名無しさん
2015/04/22(水) 18:07:06.97ID:sdnJBf1e今は実行権限の話。
umaskはファイル新規作成の時の話。
当たり前だが、cloneしたときの実行権限には関係ない話。
ちょっと無理やりすぎな屁理屈だったかなｗ
0352デフォルトの名無しさん
2015/04/22(水) 21:08:01.41ID:3b9p/BsFコミット対象が選択されていません とか出るんだけど
コミット対象ってなんのことですか？
0353デフォルトの名無しさん
2015/04/23(木) 10:35:30.48ID:DTt/WaGx絞りこみ対象を変えるかブランチ選ぶかしてみては
0354デフォルトの名無しさん
2015/04/23(木) 11:47:46.40ID:RLLS8SFj> コミット対象ってなんのことですか？
こうなるから、GUIを先に使うのはだめだと思うわ。
GUIはわかりやすいんだよ。わかりやすいから逆に
見て直感的にわかるようなこと"以外"の
知識を知らないまま使えてしまう。
デザイナとかも使ってもらうために、GUIはあっていいと思うが
ゲームみたいにチュートリアルをこなさないと
すすめないようにするべきなんだろうな。
0355デフォルトの名無しさん
2015/04/23(木) 12:40:46.69ID:0IqaduwO攻略しなきゃならんようなもんだと最初から使われないよ
0356デフォルトの名無しさん
2015/04/23(木) 12:52:17.15ID:zERGLrhN0357デフォルトの名無しさん
2015/04/23(木) 18:18:36.41ID:RLLS8SFjゲームは攻略するものだが
使われてるぞ？
0358デフォルトの名無しさん
2015/04/23(木) 21:28:23.11ID:xe4GpqoAけっきょくコミット対象とはなんでしょうか
今使ってるmasterブランチのことでしょうか
0359デフォルトの名無しさん
2015/04/23(木) 21:33:48.98ID:xe4GpqoAありがとうございます。すみません見落としていました。
絞り込んだ結果、ファイルが選択されていない状態のことでした。
なぜコミット対象が選択されていないというメッセージなのかは
不明ですが、GUIのメッセージが不適切なだけかもしれぬ。
0360デフォルトの名無しさん
2015/04/24(金) 07:42:40.59ID:7qXJwKGvいやいや、マリオの最初見てみ
よわっちいくりぼーでジャンプを覚える
その先でまたくりぼー出てきて思わずジャンプしたら上のブロックから隠しスターが出てくるとか
むちゃくちゃ良くできてるチュートリアルだから
0361デフォルトの名無しさん
2015/04/27(月) 10:14:34.47ID:gbrpzYAVcvs2gitを使ってみたが、$Id$ $Revision$ $Date$などCVS keywordがうまく変換されない。
gitで新たに管理するソースは、gitでは非推奨のkeywordを使わないルールにするつもり。
しかし過去にcvsでコミットしたソースは、diffで差分が出ないように、そのリビジョンにおけるCVSキーワード展開した形で見せたい。無理だろうか？
0362361
2015/04/27(月) 12:36:48.36ID:gbrpzYAV解決した。
--use-cvs を使った上で、--auto-propsで_keyword_handling=expandedを指定するのが正規の手順らしいが、うまくいかない。
cvs2svn-trunkのソースdvcs_common.pyの108行目をexpandedに書き換えたらうまく行った。
ツール開発者の意図した方法でないが、うまくいったからこれで良いや。
0363デフォルトの名無しさん
2015/04/27(月) 20:45:56.16ID:vTVPlfs5じゃーそのチュートリアルを作って見せてくれや
0364デフォルトの名無しさん
2015/04/27(月) 21:14:43.51ID:tqDCJ6PW0365デフォルトの名無しさん
2015/04/27(月) 21:34:24.12ID:3pJIw6k3金出せよ、まさかただとか言わないよな
>>364
論点ずらしのつもりだろ
低能がよくやる
0366デフォルトの名無しさん
2015/04/29(水) 07:34:19.84ID:rLCyhFbm0367デフォルトの名無しさん
2015/04/29(水) 09:15:46.10ID:g6CBhBxf（もしチュートリアルがあってもそんな）攻略が必要もの（git）は使われない
いやマリオの最初はチュートリアルになっている（が皆が使って遊んでいる）
じゃあチュートリアル作って
金出せばやるよ
前半すでに会話が成り立っていない
0368デフォルトの名無しさん
2015/04/29(水) 09:17:15.92ID:MPDoLmFP自己紹介は要りませんよ
0369デフォルトの名無しさん
2015/04/29(水) 09:59:33.54ID:MxyhIMrUコミットグラフ表示しながら課題解いていったり出来てよく出来てる
0370デフォルトの名無しさん
2015/05/02(土) 18:02:57.19ID:86QaeJl2乗り換えようと思っています。
なにか良いGUIツールありますか？
0371デフォルトの名無しさん
2015/05/02(土) 18:42:46.54ID:bdhWq9VE0372デフォルトの名無しさん
2015/05/03(日) 13:49:31.79ID:du+Vke+vlearnGitBranchingってやつかな？
あれは良かった
ヤリたい事や結果をイメージできるようになった
0373デフォルトの名無しさん
2015/05/04(月) 23:58:46.35ID:Oo1Eb5uXなんで「gitは使うのが簡単、使えないやつはバカ」って思っちゃうんだろうな
まあ自分が使えるからだろうが
0374デフォルトの名無しさん
2015/05/05(火) 00:25:20.05ID:8OQq3apA難しいんじゃなくて慣れだからだよ。
自転車と一緒。
0375デフォルトの名無しさん
2015/05/05(火) 02:15:41.04ID:JZAyWxcqだとしたら、勘違いって怖いな
0376デフォルトの名無しさん
2015/05/05(火) 02:57:58.30ID:8OQq3apA馬鹿なんだよ。
0377デフォルトの名無しさん
2015/05/05(火) 09:59:06.82ID:O/Hk2+s10378デフォルトの名無しさん
2015/05/05(火) 10:30:34.62ID:aqs5IwHgなかなか理解に至らないね
0379デフォルトの名無しさん
2015/05/05(火) 21:56:29.24ID:49b6mSTtどっちもGUIから操作していたからか理解は早かった
0380デフォルトの名無しさん
2015/05/06(水) 02:36:46.48ID:jAvlL/Ieの間違えかな。
0381デフォルトの名無しさん
2015/05/06(水) 02:47:12.60ID:M8LrA/ZFgitを理解するっていうことは、
コミットログを思うとおりに修正できるということ。
0382デフォルトの名無しさん
2015/05/06(水) 10:58:49.04ID:II8rx/Qjそんなオレオレ定義書かれてもなぁ
0383デフォルトの名無しさん
2015/05/06(水) 11:08:24.15ID:ctlCJDEk0384デフォルトの名無しさん
2015/05/06(水) 11:49:51.00ID:II8rx/Qj通りすがりの女の子見て、かわいいって言ってるのと同レベル
他の人にはあまり役に立たない情報
0385デフォルトの名無しさん
2015/05/06(水) 11:52:04.16ID:ctlCJDEk0386デフォルトの名無しさん
2015/05/06(水) 12:24:19.92ID:II8rx/Qjそれを役立たせられるかどうかは君次第
0387デフォルトの名無しさん
2015/05/06(水) 13:50:54.04ID:qde5blL80388デフォルトの名無しさん
2015/05/06(水) 16:05:05.62ID:ctlCJDEk0389デフォルトの名無しさん
2015/05/06(水) 16:46:24.47ID:i5GOg3P9頓珍漢すぎだろ w
0390デフォルトの名無しさん
2015/05/06(水) 17:06:15.08ID:LywkhDvigitは簡単に使うには機能が分割され過ぎてる。
0391デフォルトの名無しさん
2015/05/06(水) 17:17:46.21ID:Iqww/TfGそれが必要ないならCVSのままでいいってこと
無理してgitに移ることはない
0392デフォルトの名無しさん
2015/05/06(水) 17:28:27.94ID:ctlCJDEkそれは以前のものに何かが足りなくて
その足りないものが必要だったから。
つまりgitにしかないものを使いこなすことが
gitを使いこなすことであり、
対応表で対応付けられないものこそ
gitを使いこなしているといえる機能なんだよ
0393デフォルトの名無しさん
2015/05/06(水) 17:43:32.97ID:c5uD7uUcBitKeeperがライセンス絡みでLinuxの開発に使えなくなったので
代わりになるものを仕方なく開発したのです
0394デフォルトの名無しさん
2015/05/06(水) 18:01:40.24ID:ctlCJDEk既存のものに足りない機能があったから。
だから新しく開発し、足りない機能を搭載した。
つまりgitにしかないものを使いこなすことが
gitを使いこなすことであり、
対応表で対応付けられないものこそ
gitを使いこなしているといえる機能なんだよ
0395デフォルトの名無しさん
2015/05/06(水) 18:27:49.31ID:2otn6PY70396デフォルトの名無しさん
2015/05/06(水) 18:31:53.76ID:ctlCJDEk0397デフォルトの名無しさん
2015/05/06(水) 18:50:33.64ID:2otn6PY7終了
0398デフォルトの名無しさん
2015/05/06(水) 19:03:55.00ID:ctlCJDEk論理的に考えるとそうなるの？
負け犬の遠吠えに見える。
0399デフォルトの名無しさん
2015/05/06(水) 19:06:14.56ID:ctlCJDEkこれほっといてあげたほうが良い事例だ。
荒らしにレスするのも荒らしらしいね。
0400デフォルトの名無しさん
2015/05/06(水) 20:05:39.36ID:qde5blL8ttps://kotobank.jp/ejword/git
0401デフォルトの名無しさん
2015/05/06(水) 20:28:47.97ID:vpS3Kk/90402デフォルトの名無しさん
2015/05/06(水) 20:38:29.67ID:ctlCJDEkこっちのほうがわかりやすい
http://ja.wikipedia.org/wiki/Git#.E5.90.8D.E5.89.8D.E3.81.AE.E7.94.B1.E6.9D.A5
名前の由来[編集]
リーナス・トーバルズによれば[26]、
“ 僕は自己中心的な奴だから、自分のプロジェクトには自分にちなんだ名前を付けるようにしているんだ。最初はLinuxで、今度はgitだ。 ”
英語のスラングとして、gitには「バカ」「間抜け」といった類の意味がある。この自虐ネタはもちろん皮肉で、
これはリーナスがLinuxの名前を決める際に自身の名前にちなんだ名前を付けるよう強要されたことから来ている。(Linux#名前の由来を参照)
0403デフォルトの名無しさん
2015/05/06(水) 21:17:00.33ID:qde5blL8わざわざ自己紹介しなくても・・・ｗ
0404デフォルトの名無しさん
2015/05/07(木) 00:34:12.47ID:bUwhy5PJ>>386の洞察力はかなりのもんだ
0405デフォルトの名無しさん
2015/05/07(木) 00:47:11.22ID:Z2wm6bTM熱く語るようなものじゃない
いまどきgit使わないのは「メモ帳でもプログラム書けますよ」と同じようなレベル
0406デフォルトの名無しさん
2015/05/07(木) 03:51:35.72ID:NXZBxN2Sそれで自分の意見は？
他人にあーだこーだいってるんだから
俺ならこうだっていう意見ぐらいあるよな？
0407デフォルトの名無しさん
2015/05/07(木) 03:52:09.72ID:NXZBxN2S>>403-404
0408デフォルトの名無しさん
2015/05/07(木) 07:44:40.13ID:boZKLFPs>>389
もう少しまともな意見が言えるようになったらまたおいで
0409デフォルトの名無しさん
2015/05/07(木) 08:48:51.64ID:NXZBxN2S図星なんだな
0410デフォルトの名無しさん
2015/05/07(木) 09:28:18.61ID:SJ9cQ9MA変なダメージ入るわ
0411デフォルトの名無しさん
2015/05/07(木) 10:32:48.57ID:3s/cPLTB個人同士で開発するときにはgit超便利だけど
0412デフォルトの名無しさん
2015/05/07(木) 18:23:51.20ID:/fyjA82q俺は、総務にバージョン管理を、役員にMSプロジェクトを、それなりに真剣に薦めた事があったが、何も実行されなかった。
0413デフォルトの名無しさん
2015/05/07(木) 21:06:06.49ID:K4zbhPtLどのレスに反論しろって言ってるんだ？
0414デフォルトの名無しさん
2015/05/07(木) 23:49:15.84ID:NXZBxN2Sレスするなら反論しろってこと
>>403、>>404、>>408、あたりだね。
レスしてるってことは、何か言いたいことがあるってこと。
でも、その言いたいことが何も書いてない。
「どのレスに対する反論しろ」っていう話じゃなくて
レスするなら、自分の意見を書きなさいってこと。
0415デフォルトの名無しさん
2015/05/07(木) 23:50:08.72ID:NXZBxN2S賛成でもいいよ。
どちらにしろ、自分の意見が書いていないレスは
ゴミ同然だろう？
0416デフォルトの名無しさん
2015/05/08(金) 00:00:17.12ID:ZHeXF73S0417デフォルトの名無しさん
2015/05/08(金) 00:05:38.96ID:SsabnSp5言いたいことは、「お前はマヌケだな」ってことじゃないのか？ｗ
0418デフォルトの名無しさん
2015/05/08(金) 00:24:24.90ID:k44MRK8xそういう話をしているの。
0419デフォルトの名無しさん
2015/05/08(金) 00:36:25.10ID:SsabnSp50420デフォルトの名無しさん
2015/05/08(金) 00:54:02.88ID:k44MRK8xカッコつきで引用してみて。
0421デフォルトの名無しさん
2015/05/08(金) 00:56:53.00ID:P0RHYnr30422デフォルトの名無しさん
2015/05/08(金) 01:02:15.84ID:SsabnSp50423デフォルトの名無しさん
2015/05/08(金) 01:04:13.32ID:k44MRK8x何も言い返してこないのね。
最近こんな奴が多いね。
ま、言い返してこないなら、
願ったり叶ったりだけど。
じゃ、次。
0424デフォルトの名無しさん
2015/05/08(金) 01:04:34.82ID:ZHeXF73S0425デフォルトの名無しさん
2015/05/08(金) 01:10:04.42ID:k44MRK8x幼稚じゃなければちゃんと会話のキャッチボールができるはず。
0426デフォルトの名無しさん
2015/05/08(金) 01:11:40.05ID:dtfwKzs4excelのブックやあるいはVBなどのプロジェクトをフォルダ単位で…とかって出来るんですか？
ソースコード管理というとなんかテキストで保存みたいに聞えるんですが
バージョン管理触ったことがないんで、ちょっとお聞きしたいです
0427デフォルトの名無しさん
2015/05/08(金) 01:24:17.86ID:k44MRK8x取り出す方法（つまりdiff）ができないとだめ。
excelはそれが出来ないので無理。（正確に言うと意味が無い）
VBは一部にバイナリデータがあったと思うが、大部分はテキストなので可能。
（バイナリデータは保存することしかできないが）
勘違いしてはいけないのは、バージョン管理ツールは
バージョンを管理するものであって、
バックアップをするためのものじゃないってこと。
バージョンを管理するというのは、バージョンとバージョンの機能の差を抜き出したり、
その抜き出したものを開発中の別のバージョンに適用したりそういったことをする。
特殊な形式のバイナリが標準化されれば、バージョン管理できるかもしれないが
現時点ではテキストファイルしかバージョン管理できない。
excelなんかはバージョン管理（差分を抜き出すなど）する意味が無いので
別のバックアップツールを使った方がいい。
0428デフォルトの名無しさん
2015/05/08(金) 01:27:36.31ID:dtfwKzs40429デフォルトの名無しさん
2015/05/08(金) 02:06:08.07ID:ZHeXF73Sそれでも使うのは構成管理用か管理上ソースと不可分であるときくらい
事務用でも月次年次確定データや契約書決裁書等重要書類が紛失変更されないようロックするには都合がいい
バックアップファイルの管理とバックアップツールの保守が不要になる
タイムマシンしたいなら無駄無駄無駄普通にバックアップソフト使え
0430デフォルトの名無しさん
2015/05/08(金) 07:14:07.27ID:IAWQ0LFr> バージョンを管理するというのは、バージョンとバージョンの機能の差を抜き出したり、
> その抜き出したものを開発中の別のバージョンに適用したりそういったことをする。
幼稚なオレオレ定義乙
>>426
単純に最新版管理したいとか、たまに過去バージョンを取り出したりしたいだけなら Subversion の方がいい
Excel ってことはたぶん Windows だろうから TortoiseSVN インストールすればほぼ GUI で使えるし
詳しく知りたいなら続きはこちらで
Subversion r15
http://peace.2ch.net/test/read.cgi/tech/1406967657/
0431デフォルトの名無しさん
2015/05/08(金) 09:22:21.26ID:samEA3DJ0432デフォルトの名無しさん
2015/05/08(金) 09:44:23.49ID:SsabnSp5＞幼稚な奴がいるんでしょ？
それがお前だな
0433デフォルトの名無しさん
2015/05/08(金) 11:34:00.00ID:Yhmm5THUTIME MACHINE はよく知らんからわからんけど Windows バックアップとかとは別物
一時間の間に 10回変更したら 10回バックアップとる訳じゃないでしょ
0434デフォルトの名無しさん
2015/05/08(金) 11:41:31.10ID:samEA3DJバックアップだって自分でトリガひける
0435デフォルトの名無しさん
2015/05/08(金) 12:19:48.40ID:Yhmm5THU0436デフォルトの名無しさん
2015/05/08(金) 12:55:19.05ID:SsabnSp50437デフォルトの名無しさん
2015/05/08(金) 19:41:28.50ID:dtfwKzs4426です。Subversionってのを調べてみます。情報多謝m(_ _)m
0438デフォルトの名無しさん
2015/05/08(金) 20:05:19.99ID:9kJl+Khzこまかくpushするほうがよい
たとえば足し算の結果を表す機能と引き算の結果を表す機能を作るとしたら２つのコミットを作れば良い
この２つを１つのログにまとめるべきではないのだ
何でもかんでも１つにまとめるのがかっこいいという間違った思想を持った人間がいるので困った。
0439デフォルトの名無しさん
2015/05/08(金) 20:18:03.21ID:ZHeXF73Sよくそれでコード書いてるな
目的ごとにブランチ切ってコミットあたり1ハンクだけで済むようにするのがベストプラクティスだ
0440デフォルトの名無しさん
2015/05/09(土) 00:45:24.25ID:oI9IuS7a> バグを埋め込んでしまった場合、コミットをまとめるとリーディング量が増えるからまとめないほうがよいという結論に達した
具体例かける？
書けるはずだよね。書いて。
0441デフォルトの名無しさん
2015/05/09(土) 00:56:47.31ID:bOQm//LK0442デフォルトの名無しさん
2015/05/09(土) 00:58:05.96ID:oI9IuS7a0443デフォルトの名無しさん
2015/05/09(土) 13:31:25.76ID:MqwqSntJ戻る時ってgit reflogで最新の履歴を確認してgit reset HEAD@{n}しました
こういうやり方であってますか？
0444デフォルトの名無しさん
2015/05/09(土) 13:38:29.58ID:P/ABm+5N0445デフォルトの名無しさん
2015/05/09(土) 13:38:44.30ID:8PoBBRDQ0446デフォルトの名無しさん
2015/05/09(土) 13:41:01.09ID:oI9IuS7atigコマンドを使う。
0447443
2015/05/09(土) 19:11:08.54ID:hILIDw1ntigも調べてみます
0448デフォルトの名無しさん
2015/05/12(火) 16:17:37.50ID:pNASC22d元のブランチに戻りたいのですがこのままだとできません
git reset --hard HEADとかgit checkout .とかして更新をなかったことにできません。
元のブランチに戻るためには更新されてない状態に戻す必要があると思うんですがどうやるのですか？
0449デフォルトの名無しさん
2015/05/12(火) 16:23:44.14ID:KgdwQEvt今度からは、修正したいときは新しくブランチを作ってからやるんだよ
git checkout -b edit_branch head^^
で、修正するも捨てるも良し
0450デフォルトの名無しさん
2015/05/14(木) 08:09:17.45ID:aOO0/Ibj0451デフォルトの名無しさん
2015/05/14(木) 08:11:21.04ID:aOO0/Ibj0452デフォルトの名無しさん
2015/05/14(木) 08:43:10.59ID:U5lm4ek90453デフォルトの名無しさん
2015/05/14(木) 12:28:03.63ID:dw1HaLxu*
!*.txt
!data/
data/.*
!data/*.txt
mkdir data
touch data/a.txt
touch data/.b.txt
git init
git add .
これでdata/.b.txtもインデックスに追加されてしまいます
.gitignoreでどういうふうに指定したら.から始まるファイルを除外できますか？
0454デフォルトの名無しさん
2015/05/14(木) 12:59:28.26ID:7ksZOIpVdata/*.txtにdata/.b.txtがマッチするのはちょっと妙に感じるかもしれないけど
data下の.ではじまるファイルを全部除外したいなら、
ルールの!data/*.txtとdata/.*の順番を入れ替えればいいのかな
0455デフォルトの名無しさん
2015/05/15(金) 11:59:16.15ID:XocOnm+Lブランチを削除してもレビューやコメントを残す方法は何かないでしょうか？
0456デフォルトの名無しさん
2015/05/15(金) 20:00:20.09ID:p2cJvo/x0457デフォルトの名無しさん
2015/05/16(土) 01:25:17.31ID:+UC07Y5Wgithubは知らないけど、gitlab（最新版）なら
ちゃんと残る。
正確にはコメントやレビューはマージリクエスト（githubのプルリク相当）に書かないとダメ。
ブランチ（コミット）に対してのコメントであれば見れなくなる。（今は残ってる気もするけど）
0458デフォルトの名無しさん
2015/05/16(土) 17:17:39.54ID:AD3UxZEYありがとうございます。Gitlabを使ってるのでバージョン上げてみます。オフィシャルブログの更新内容をみてもそれらしき更新がなくダメだと思ってました。
0459デフォルトの名無しさん
2015/05/16(土) 23:14:20.75ID:waTp+O7jgitlabの話でよかったんだなｗ
自分もコメント消えるのが問題だったが、最近消えなくなったなーって
思うだけでどうなっているのかよくわからないから、ついでに動作を少し検証してみた。
* マージリクエスト(以降MRと書く）にコメント(1)を付ける。
* MRのDiscussionにコメント(1)が表示される。
* MRのChangesからコメント(2)を付ける
* MRのDiscussionにコメント(2)が表示される。
* MRのCommitsからたどったコミット番号(A)のソースコードにコメント(3)をする
* 同コミットの下からコメント(4)をする。
* MRのDiscussionにコメント(3)(4)が表示される。
* Discussionから(2)(3)(4)にReplyする。
* Discussion と共に、コメントを書いた元の場所にもReplyが表示されている。
ここまでは消したりしてないので、ごく普通にコメントが表示されている。
当たり前ではあるんだけど変更した行以外にはコメントつけられないな。
たまに周りにも修正すべき所があってコメントしたくなるんだけど。
0460デフォルトの名無しさん
2015/05/16(土) 23:15:03.07ID:waTp+O7jつまり、コミット番号(A)がMRから消えてなくなる。
* MRに書いたコメント(1)は当然残っている。
* Changesに書いたコメント(2)はMRに残っているが、outdated diffということで
折りたたまれているので注意。Showをクリックすれば見れる。
* 消えたコミット番号(A)に書いたコメント(3)(4)は、MRからは消えている。
ただしコミットを表示すれば見ることはできる。
MR作成後にpushしたコミットなら自動的に、MRに記録されるようになっているが
最初にpushしたコミットは残らない。（Dashboardあたりで確認可能）
ではAccept Merge Requestしてブランチ削除してみる。
（当たり前だがマージしたMRを見ることは可能）
この状態はgit push --forceしたのと同じ状態。
特にコメントすることもないかな。
結論としてはMRにコメントを残したいならば、
MRかもしくはそのChangesに書く。（たぶん昔からこの挙動）
MRに含まれるコミットにコメントした場合、
そのコミットが消えると行方不明になることがある。
行方不明になるだけで残ってはいるので、コミットに
辿り着くことができれば見ることは可能。
なので、コミットにコメントしてしまった時は
MRからたどり着けるようにリンクを張っておけば良い。
0461デフォルトの名無しさん
2015/05/16(土) 23:20:45.79ID:waTp+O7j昔から変わってないと思うんだけど、それはそれとして
MR自体が見やすくなっているので、バージョンをあげるのはありだと思う。
例えばgit push --forceした時とかにpushしたコミット番号が
MRに記録されるようになったのは最近の機能。
できれば最初のコミット番号もMRに記録されて欲しいんだが。
Dashboardとかから調べられるけどさ。
gitlabは昔（と言っても一年前程度）はいかにもgithubの
クローンってUIだったけど、UIが変わってgithubとは別の
同種のソフトって感じで良くなったと思うよ。
機能的にもgithubに全然劣ってないしね。
もちろんオープンソースでコミュニティ重視ならgithubになるんだけど、
クローズドならgitlabで十二分に使えると思う。
0462デフォルトの名無しさん
2015/05/17(日) 19:28:04.61ID:ImkX2Hg51
2
3
4
↓古い
1のコミットを3のコミットに含める事について。
これってコンフリクトを起こす可能性があるのであんまりやらないほうがいいと思うんです。
合体させるならコミットを飛ばさなず1,2,3を合体したほうがいい気がするんです。
ここの先輩方はよくやりますか？
0463デフォルトの名無しさん
2015/05/18(月) 02:18:29.93ID:/pjdhzEdお前には無理なら止めといた方がいいが。
0464デフォルトの名無しさん
2015/05/18(月) 08:12:32.67ID:ezOKhhiH「あまりやらないほうがいいと思う」のは前提として
「コンフリクトを起こす可能性がある」からだよね？
まず一つ。コンフリクトは起きても問題ない。直せばいいだけ
もう一つ。コミットが小さく分かれていれば、コンフリクトが起きる可能性は少なくなる。
この2点がある。
どうもコンフリクトを怖いもの。起きたら世界の破滅みたいに思っている人がいるみたいだけど
ぜんぜん違う。起きるのは当たり前のことだし、他人が作ったものならまだしも
自分が作っているものなら、どうすればいいかなんてすぐにわかる。
そしてコンフリクトが起きるのはなぜかという話。それはコードが単一責任原則を
満たしていないから簡単にいえば、修正すべきコードがあちこちに分散しており
ようするにコードが汚いから。
コンフリクトは起きたら直せばいいだけだが、
面倒くさいから、起きないほうが楽というのは確か
各コミット（そこでいう1, 2, 3, 4）がそれぞれ小さい修正になっており、
それぞれがちゃんと意味がある単位で分かれていれば、そうそうコンフリクトは起きない。
0465デフォルトの名無しさん
2015/05/18(月) 08:28:44.00ID:ezOKhhiHという質問の答は、含めるべきことであれば含める。
そうしないと逆にコンフリクトが多くなるから。
何故かと言うと、1と3をまとめたい＝意味がある単位で考えてまとめるべきこと。
単一責任の原則を満たしており、意味がある単位で小さいコミットというものは、
多くの場合同じ箇所の修正になる。「1と3は同じ箇所の修正」っていうことを覚えておいてね。
そして例えば新しくコードを書いている途中で、既存のバグが見つかったとする。
新しいコードはバグを直さなければ正しく動かない。
だから先にバグを修正するために、5というコミットが必要になったとする。
（どうでもいいが1〜4数値は新しい方を大きくしてくれｗ）
そうすると5のコミットの続きからに、1〜4をrebaseしなければならない。
その時に3でコンフリクトが発生すると3を直したあと1でもコンフリクトが起きるだろう。
なぜなら、同じ箇所を修正しているから。
さらにむずかしいのは、最終的には1が終わった形にしないといけないわけだけど
3のコンフリクトをどう解決するか？って問題がある。
3の時点で1が終わった形にするわけには行かないんだよ。
3で発生したコンフリクトを直したあとに、1の修正を行うわけだから。
どう直せばいいかわからないものが多数発生する。
これがコンフリクト怖い病になる原因だねｗ
だからコンフリクトが起きる頻度を少なくするためにも、
1. 各コミットは小さい修正にしておく
2. 意味的にまとめるべきコミットはまとめておく
これを徹底することで、最終的にコンフリクトが起きにくくなる。
0466デフォルトの名無しさん
2015/05/18(月) 09:10:31.18ID:ezOKhhiHコンフリクトっていうのは同じ場所の修正がかぶると
発生するっていうのを意識しておいた方がいい。
あたりまえだと思うけど、じゃあどうすればいいかまで考えているだろうか？
他人とのコンフリクトは、単純に同じ箇所を修正したときだが、
自分自身とのコンフリクト、rebaseでよく起きるね。（下手だと）
こっちもコンフリクトが起きる原因は同じ箇所の修正だからなんだ。
もし同じ箇所の修正がなければ、rebaseしてコミットの順番を
入れ替えたりしてもコンフリクトは発生しない。
じゃあ同じ箇所の修正はいつ発生するか？ それはこういうの
* Aという修正をコミットした
* Bという修正をした
* Aという修正にバグが見つかったので修正した
* Aに機能が足りなかったから追加した
* Aの変数名でタイポしていた
こういうのを放置したまま、作業し続けていざmasterにマージする段階で
コンフリクトが起きてrebaseしなきゃならないってなった場合に
多くのコンフリクトが発生して、大変なことになる。
こういうのは随時rebaseしておくことが重要。
バグとかタイポとかさっさとまとめておく。
* Aとい修正をコミットした
* Bという修正をコミットした
こういうふうコミットを意味がある単位で小さくまとめておけば、
コンフリクトの回数は減るし、直すのも単純になる。
0467デフォルトの名無しさん
2015/05/19(火) 08:43:08.91ID:ETXaESJa自分なら、普通は避けるな。
でも理由は、ソースの修正箇所がコンフリクトするからじゃないよ。
1->2->3の順にコミットして、1と3をまとめたら、2->1+3になるわけだよね？
このとき、2が1無しでも正しく動作するか分からないからね。
もし、2と1+3を別々のコミットとして履歴に残すなら、どっちのコミットでも
正しく動作することを担保したい。
でも、コミットをまとめるためだけに、（自動テスト環境があったとしても）
2だけのテストをまたやり直すのを避けたい。
だけどそれも、プロジェクトごとのgitの運用ルールによるかもしれない。
コンパイルエラーになるコミットがリモートリポジトリにあるのは構わないとか、
過去のコミットが動かなくなるのは構わないとかのルールになってるなら、
好きなようにまとめるかもしれない。
0468デフォルトの名無しさん
2015/05/19(火) 10:17:56.67ID:S02ugk9h0469デフォルトの名無しさん
2015/05/19(火) 11:07:38.39ID:0hZF5IeJ> このとき、2が1無しでも正しく動作するか分からないからね。
1+3のテストだけやればよくね？ 2がテストに通らなくても、
自動テストがあるならすぐにわかるし、最悪テストに通らないときだけやらなければいい。
もし自動テストがなければ、2がテストに通らなくても
「調べようがないので、通らないことがわからない=通っているのと一緒。」 ←重要
それにさ、コミットが多かったら、正しく動くことを担保するのは大変だよ。
* Aが正しく動くことを確認
* Bが正しく動くことを確認
* Cが正しく動くことを確認
* Dが正しく動くことを確認
というつもりだったが、たいていバグはあとから見つかるんで、
あとからAが正しく動いていなかった！と判明したらどうする？
* Aが正しく動かない
* Bが正しく動かない
* Cが正しく動かない
* Dが正しく動かない
* Eで修正
君は、どのコミットでも、正しく動くことを担保したいといったが
A〜Dは全部正しく動かないことが担保されたわけだｗ
EをAに混ぜ込めば直すことができるが、それをしないならば、A〜Dのコミットは正しく動かないままだよ。
A〜Dは正しく動かないが、でもその時はテストコードがなかったから分からないわけだよね。
それって、つまり「重要」って書いた所と同じ状態なんだが。
過去のコミットが動かないのは構わないというルールなら、そのまま放置でいいかもしれんが（笑）
0470デフォルトの名無しさん
2015/05/19(火) 12:47:36.82ID:0hZF5IeJコミットのやり方？
普通にgit addでコミット対象を選んで
git commitでコミットするだけだけど？
コミットの順番を入れ替える話？
それならgit rebase -iだよ。
0471デフォルトの名無しさん
2015/05/19(火) 14:21:12.63ID:oDPa6Z2Vバグの話じゃないでしょ
0472デフォルトの名無しさん
2015/05/19(火) 17:37:58.03ID:0hZF5IeJバグの話ではこうなるよね？
つまりこれは「正しく動かないがテストコードがないから自動テストには通る」
という状態をどう考えてるかって話なんだよ。
俺はそれは自動テストに通るってことでいいじゃないかって言っている。
これがいやなら、前のコミットに混ぜて修正するしか無いわけだよ。
で、俺は 前のコミットに混ぜても自動テストに通るなら
それでいいじゃないかとも言ってる。
ちなみに俺は特に大きな理由がない限り、テストケースも含めて
前のコミットに混ぜて、全てのコミットを正しく動くようにしている。
皮肉なことに>>467が言ってる
> どっちのコミットでも正しく動作することを担保したい。
を実践出来てるのはこのやり方なんだ。
0473デフォルトの名無しさん
2015/05/19(火) 17:38:54.11ID:0hZF5IeJ○（自動）テストコードも含めて
0474デフォルトの名無しさん
2015/05/19(火) 21:49:21.81ID:ez1Du3hqコンパイルと自動テストに通るかどうか、わざわざ確認するか？
ってことだな。
確認するなら、影響する各コミットでわざわざそれを確認するのは
面倒くさい、というデメリットが発生する。
確認しないなら、古いコミットは（コミットした当時は通ってたであろう）
コンパイルと自動テストはもう通らないかもしれない、というデメリットが
発生する。
そのデメリットを避けるために、「間をとばしたコミットまとめはしない」
のが>>467だね。
>>472が結局どうしたいのかについては知らない。
0475デフォルトの名無しさん
2015/05/19(火) 23:00:23.53ID:aRRI5SvPgit init
touch a; git add a; git commit -m "add a"
touch b; git add b; git commit -m "add b"
touch c; git add c; git commit -m "add c"
"add c"のログを"add a"に加えたいんですがgit rebase -iでどうやるんでしょうか？
pick 07d5e6a a
pick f550031 b
pick 5d295c0 c
このpickをどう書き換えたらbを飛ばしてaにまとめられるのかわかりません
pick 07d5e6a a
pick f550031 b
fixup 5d295c0 c
これだとbにまとまってしまいました
どうやるのか教えてください
0476デフォルトの名無しさん
2015/05/20(水) 00:37:31.29ID:NtQ54Cc0そんな全部なんていらんし、途中からでいいんだけど
どうしたらいいの？
0477デフォルトの名無しさん
2015/05/20(水) 01:04:01.37ID:jSvt41UGpick 07d5e6a a
fixup 5d295c0 c
pick f550031 b
エディタで順番を入れ替える。
0478デフォルトの名無しさん
2015/05/20(水) 01:50:27.49ID:TO++lAfhできました
これは便利ですね
これでログを今よりも綺麗に出来ました
0479デフォルトの名無しさん
2015/05/20(水) 09:25:54.36ID:v+0+7waM>>140
0480デフォルトの名無しさん
2015/05/20(水) 12:05:48.01ID:qzEPJuINあー、なんかわかってきた。なんでコンパイルも自動テストの実行も何も考えずに出来る作業なのにそれが面倒なんだ？
たかだか数回だろう？と思ったが、なるほど、あんたブランチに含まれるコミット数が多いんだわ。
コミットが何十個にもなってるでしょ？それはコミットをまとめないからだよ。
それから一度に変更（マージ）する内容が多すぎだろうね。
これはもう仕事のやりかた、作業の進め方のレベルの話だね。
まともなレビューが行われているかどうか不安になるな。
まず自動テストをしているならば、その内容をテストしたのは明らかなわけで、
何をレビューするかというと書いてあるテストとコードが正しいか漏れがないかだよ。
人力テストをしてもらうんわけじゃない。
つまりコード見て理解できる程度の量でないといけない。それも短い時間でね。
修正内容がバラバラで、順番も修正箇所もごちゃまぜな大量のコミットを一個ずつ見るのは不可能だし
全部まとめて見ると一度に大量のコードを見ないといけなくなるから大変。
レビューアに負担をかけるようなコードはだめだよ。
あと一連の機能を全部まとめてレビューしてもらってるでしょ？
細かい機能毎にわけないとだめだよ。リファクタリングならリファクタリングだけでマージ
モジュールの追加なら（テストコードも含めて）モジュールだけのマージ
それらをいっぺんにレビューするよりも、分けたほうがレビューアの負担は減るのはわかるよね？
君はいっぺんに全部やろうとするから、コミットまとめたり入れ替えた時の時の再テストが
大変とかいう話になってるが、俺の場合は、細かく分けてマージ可能な最小単位に分割するから、
一つの作業ブランチに含まれるコミットは数個しかない。
君、悪循環に陥ってるよ。コミットをまとめないから、マージできる単位に分割できない。
分割できないから一つのブランチの内容が多くのコミットになる。コミットが多いから並び替えたら
コンパイル・テストが通るか不安になる。面倒くさい。だからコミットをまとめないって。
0481デフォルトの名無しさん
2015/05/20(水) 12:10:17.30ID:qzEPJuIN一連の機能を作っている時にリファクタリングやモジュールの追加は
絶対に発生する。ミスも発生する。
一連の機能をいっぺんに全部レビューするのはすごく大変だから
小さく分けた方がいい。
ならば一連の機能をリファクタリングだけのブランチ
機能追加だけのブランチ等にわけて、出来た所からマージした方がいいが、
コミットを入れ替えたりまとめたりしないで、どうやってそれを実現するの？
0482デフォルトの名無しさん
2015/05/20(水) 16:22:35.29ID:NtQ54Cc0を繰り返すならコミット量は自然に増えるよね
0483デフォルトの名無しさん
2015/05/20(水) 16:38:52.05ID:qzEPJuINこんな感じにすればいいよ。別にコミットは実際の作業順に合わせる要はない。
* ちょっと書く
* テスト
* ちょっと書く
* テスト
↓ 並び替え（これが失敗することはまずない）
* ちょっと書く
* ちょっと書く
* テスト
* テスト
↓ まとめる（これが失敗することもまずない）
* ちょっと書く
* テスト
この作業を随時やっていく。
・・・つづく
0484483のつづき
2015/05/20(水) 16:47:02.59ID:qzEPJuINそれは内容によって変わる。
コミットを（まとめるべき内容なら）まとめながら作業するのは一緒だが
リファクタリングの時は「ちょっと書く」と「テスト」はまとめない。
* テスト
* ちょっと書く（リファクタリング）
最終的にこうなる。なぜならリファクタリングしても動作は変わらないはずなので、
コードを書いた前と後で全く同じテストが通るから。
それを確認するためにも、リファクタリング前に（テストが不足している場合は）
テストを書いておき、そしてリファクタリングを行う。
またコミットを入れ替えることを前提にすると「後からテスト駆動」が実現できる。
理想としてはテストを先にやるのがテスト駆動なのだが、現実には後からミスが見つかったりして
コードを書いてからテストを追加することが多い。
実際の作業ではコードを書いてからテストを書いたとしても、そしてそれらが
コード書いてテスト、コード書いてテストって繰り返していたとしても、
テストだけまとめて1つ目のコミット。リファクタリングして2つ目のコミットの形にできる。
これでレビューする人は、問題なくリファクタリングできたことを確認できるわけ。
もちろん仕様変更や機能追加などであれば、テストコードと修正を
分ける意味が無いし、一つにするべきなのでまとめる。
0485デフォルトの名無しさん
2015/05/20(水) 16:59:43.68ID:NtQ54Cc0ローカルでのコミットはどんどん細かく、プッシュの粒度はテスト通ってから
という方針でやってたんだけど、gitはそういうのに向かないんですね
0486デフォルトの名無しさん
2015/05/20(水) 17:01:43.80ID:NtQ54Cc0じゃあ俺のgitの使い方は間違っているのか
0487デフォルトの名無しさん
2015/05/20(水) 17:03:34.98ID:NtQ54Cc0かつ テスト用ブランチでどんどこ適当なコードを書きなぐれるのか？
みんなそこまでやってたの？ すげーな
0488デフォルトの名無しさん
2015/05/20(水) 17:07:28.79ID:qzEPJuINなんで？ 意味がある単位で小さくすればいいよ。
でも意味がないのに分割する必要はない。
（ローカルでの作業中に）
例えば、関数名これでいいかな・・・コミット
やっぱり、関数名こっちにしよう・・・コミット
いやいや、やっぱり戻そう・・・コミット
ってタイポしてたよ修正・・・コミット
これってコミットを細かく分けたかったわけじゃない。
作業上の都合でコミットがわかれてしまっただけ。
こういう意味が無いコミットはまとめるべき。もちろん
別々の修正であれば、どんどん細かく分けた方がいい。
細かく分けておくと並び替えや分離がしやすくなるよ。
修正しているうちにコミットがたくさんになって、これ一度に
レビューするの無理だろと思ったら、抜き出して別のブランチにするとかね。
でももし意味が無いコミットに分かれていたら、逆に抜き出すの難しくなるからね。
重要なのは、意味がある単位で小さいコミットに分けておくこと。分ける意味が無いものはまとめること。
これがコミットをうまく管理するコツだよ。
0489デフォルトの名無しさん
2015/05/20(水) 17:15:41.65ID:qzEPJuIN> みんなそこまでやってたの？ すげーな
git歴は2年ぐらいかな？
最初は当然できなかったよｗ
ただレビュー可能なコードの重要性はわかっていたから、
subversion使っている時、こんな行き当たりばったりの修正履歴じゃ
レビューできないだろっていう認識はあった。
（計画的にやれって思うかもしれないが、ミスや漏れどうしても発生する）
gitを使ってからはどうすればレビューしやすくなるか？を
考えてコミットを作るようにしていたよ。
（ちなみにどちらかと言うと俺はレビュー依頼する側じゃなてレビューする方だけどね）
0490デフォルトの名無しさん
2015/05/20(水) 17:18:24.50ID:zo5n24wvそのケースで実際にコンフリクトが発生する場合は
2 の粒度がでかすぎるってのがよくあるパターンなので、
2 を分割して 4←3+2a+1←2b という形になるようにしている
0491デフォルトの名無しさん
2015/05/20(水) 21:06:38.40ID:vVwXnjIW>あー、なんかわかってきた。なんでコンパイルも自動テストの実行も何も考えずに出来る作業なのにそれが面倒なんだ？
>たかだか数回だろう？と思ったが、なるほど、あんたブランチに含まれるコミット数が多いんだわ。
コンパイルと自動テストが数秒で終わるなら、この理論が成り立つな。
たぶん>>480の場合は、例えば分野が小さなWebサイトの開発とかで、
そもそもの開発規模や自動テストの規模が少ないとか、昔のコミットや
昔の挙動を残しておいても問題調査の役に立つことが少ないとか、そういう
特徴があるんだろう。
0492デフォルトの名無しさん
2015/05/20(水) 22:00:00.11ID:qzEPJuIN数秒で終わらないのが困るのなら、大量にあるコミットが
ある状態で、rebaseとかどうするのさ？
数秒で終わらないなら、逆にコミット減らすべきだろ。
矛盾してるぞｗ
あと中間ファイルが残ってるはずだから、
適切にソースコードが分割されて依存関係が少ないなら
一つ一つのコミットの修正が僅かなはずなので
コンパイルにそんなに時間がかかるはずがない。
0493デフォルトの名無しさん
2015/05/20(水) 22:05:10.63ID:qzEPJuIN> 問題調査の役に立つことが少ないとか
これも逆に不要なコミットは消すべきだよね。
何か勘違いしてる（他の人にされそう）だから
念の為に言っておくけど、俺が言ってるのは、
本来一つであるべきコミットは一つにするって話で
何でもかんでもまとめろって話じゃない。
だから当然、昔のコミットは残ってる。
調査に使うよ。git bisectで二分探索で。
でだ、この時大量にコミットがあるとその分探索の回数増えるわけで、
コンパイルと自動テストが数秒で終わらないとしたら大変だよなぁ？
問題調査のためにも無駄なコミット減らしたほうがいいって結論になるぜ？
0494デフォルトの名無しさん
2015/05/20(水) 22:19:59.27ID:MjY1jVeQ＞数秒で終わらないのが困るのなら、大量にあるコミットが
＞ある状態で、rebaseとかどうするのさ？
だから、「間を飛ばしたコミットまとめをしない」って言ってるんじゃないのか？
A→B→C→Dの順にコミットされてるなら、連続したBCやBCDをまとめるのは
コンパイルや自動テストに問題ないから。
0495デフォルトの名無しさん
2015/05/20(水) 22:30:23.27ID:qzEPJuINrebaseって二つの複数の意味があるから気をつけないといけないなｗ
master(1)
＼A→B→C→D
で開発をはじめてさ、他の人のマージが先に加わった時、
master(1) → master(2)
＼A→B→C→D
master(2)からの開発にrebaseするという話。
master(1) → master(2)
＼A→B→C→D
この時、A〜Dまですべてが書き換わるわけだから、
コンパイルと自動テストをするわけでしょ？
時間がかかるのならなおのこと、まとめておいたほうがいいでしょ。
master(1) → master(2)
＼AC→B→D
もしかしてこのタイプのrebaseも禁止してるのかな？
なんか下手なコミットのせいで、時間が掛かるから便利なものを
封印せざるを得ない状態を作っているようにしか見えない。
0496デフォルトの名無しさん
2015/05/20(水) 22:49:40.28ID:MjY1jVeQなんでfeatureブランチの各コミットを直接masterにつなごうとするのかがよく分からない
このケースだと、AC、B、Dがそれぞれ別ブランチになってないのが問題なのでは？
0497デフォルトの名無しさん
2015/05/20(水) 22:50:55.88ID:qzEPJuINと思った理由もかいておく。
A, B, C, D が同じ箇所の修正（前のコミットのやり直し）をして
本来一つであるべきものが分かれていたとする。
そしてmaster(2)にrebaesしたときにAでコンフリクトが発生したとする
master(1) → master(2)
＼A→B→C→D
そうすると、B, C, D も同じ箇所の修正だから
必然的に、BでもCでもDでもコンフリクトが発生するわけよ。
わー、大変だ。コンフリクトだ。しかもこれさっき直したじゃないか？
コンフリクトわけわからん。わー。ってなってるはず。
同じ箇所の修正を一つにまとめておけば、コンフリクトの修正も一回だけだよ。
関連あるコミットをまとめておかないから、コンフリクトが沢山発生する。
時間かかるし正しく修正できたわからんからrebaseしない方がいい！ってなってると思う。
コミットが沢山にわかれている → コンフリクトが沢山発生する → そうなるからrebase禁止 と
考えているのだろうが、本当の原因はコミットが沢山にわかれていて、それが意味もない順番でごちゃごちゃ並んでることだから。
関連あるコミットは随時まとめておく。順番も適切な順番になおしておく。そうしておけばコンフリクトの発生は少ない。
コミットの数も少なくなるし、だからrebaseしてもコンパイルにも自動テストに時間はかからなくなる。
コミットは意味がある形で最小限に抑えられているから、レビューも楽になる。
後から問題の調査をするときも、存在理由がわからない大量の謎コミットを見る必要もなくなる。
gitの機能を最大限使うことが出来るわけよ。
ってもう何回も言ってるねｗ 毎回長文でｗ
0498デフォルトの名無しさん
2015/05/20(水) 22:54:58.15ID:qzEPJuIN> その場合、[A→B→C→D]をまとめたものをmaster(3)にすればいいと思うのだが
その場合ってどの場合？
一人で開発してるんじゃないんだよ。
自分が開発をし始めた時からコードは変わっているから
これをmaster(3)になんか出来ない。
他人の仕事を消してしまうじゃないか。
他人の仕事と自分の仕事を合わせてないと行けないんだよ。
コンフリクトが起きようと起きまいとね。
コミットが沢山あればあるだけ、全てのコミットが
正しく動くか再テストをする必要がある。
0499デフォルトの名無しさん
2015/05/20(水) 22:58:20.56ID:MjY1jVeQ＞master(1) → master(2)
＞ ＼AC→B→D
これを許してるってことは、rebase後にACとBのコンパイル確認と自動テストをチームの義務としてない、
最新のDが自動テストに通ればよい、と暗黙のうちに言っているような気がするのだが…。
これが許されるチームなら、各メンバーが自由にコミットをまとめても、たしかに問題ないな。
0500デフォルトの名無しさん
2015/05/20(水) 23:01:15.60ID:qzEPJuIN> このケースだと、AC、B、Dがそれぞれ別ブランチになってないのが問題なのでは？
別ブランチにできるかどうかは内容次第だね。
コミットとしては一つ一つ取り込めたとしても
機能としては一つ一つでは完成しないこともある。
で、俺は一連の作業中に、先にマージ可能なものができたら、
別ブランチに抜き取って先にマージした方がいいとも書いた。
そのためにも、コミットをそのまま放置するのではなく
関連があるものはまとめていくようにって言ってるんだよ。
関連あるコミットがバラバラだったら、別のブランチに抜き出すのは大変だからね。
それもあって、そのケースでAとCをまとめたんだよ。
つまり最初のAとCが関係ある内容ならまとめますか？の質問の
答えはまとめた方がいいってこと。
で、これやるとコンフリクトが〜とかいって、まとめない方がいい
並び替えないほうがいいって言ってる人がいるわけよ。
0501デフォルトの名無しさん
2015/05/20(水) 23:05:27.02ID:qzEPJuIN> これを許してるってことは、rebase後にACとBのコンパイル確認と自動テストをチームの義務としてない、
> 最新のDが自動テストに通ればよい、と暗黙のうちに言っているような気がするのだが…。
話がループしているがｗ
rebase後にACとBのコンパイルと自動テストをスレばいいだけだろう？
そんなのすぐに終わる。たった2回（ACとB）じゃないか？
すぐに終わらないのは、コミットがたくさんあるからだよ。
そりゃコミットが10個も20個もあれば、10回20回もコンパイルと自動テストをしなきゃならんだろうさ。
コミットがたくさんあるために、rebaseを許さない状況になってしまっている。
rebaseってさ、gitの基本じゃん？
チュートリアルの最初のほうで出てくる作業だよ。
許されるも何もこれは普通にやるべきことだよ。
ね？ 下手なコミットのせいで普通にやることがやれない状況になってしまっている。
コミットがたくさんあるために、rebase（master(2)への付け替え）を
封印してしまってるでしょ？
0502デフォルトの名無しさん
2015/05/20(水) 23:19:51.82ID:MjY1jVeQAとCをまとめますか？の回答には「そう思う」だが、
AとBとDをまとめて一つのブランチにして、その一本のブランチの上でAとBとDの開発作業をしますか？の回答には「そう思わない」だな。
AとBとDはブランチを分けるな。
もしブランチを分けとけば、レビュー前？Push前？にAのバグに気付いても、AとCのコミットは連続してるだろうからな。
逆に、レビュー後？Push後？に問題に気付いたなら、自分の負けを認めてバグ修正のコミットを残す。
一方、後になって「コミットが連続しない、AとBとDをブランチに分けておけば良かった〜」なんてなるようなら、自分の腕のなさを呪ってブランチを切りなおす？？？かな。
0503デフォルトの名無しさん
2015/05/20(水) 23:21:45.30ID:MjY1jVeQ＞そんなのすぐに終わる。たった2回（ACとB）じゃないか？
「そんなのすぐに終わる」って前提があるから、話がかみ合わないんだと思うが…ｗ
0504デフォルトの名無しさん
2015/05/20(水) 23:28:53.73ID:qzEPJuIN> AとBとDはブランチを分けるな。
分けたいなら後で分ければよくね？
作業用ブランチなんだからそれはどっちでもいい話だと思うが。
AとBとDがお互い前のコミットに依存している場合、
最初にブランチを分けておくと、ごちゃごちゃしてくると思うが。
Aを作ったはいいけれど本当にこれでいいかは、そのAを使う
Bを作らないとはっきりしないことだってあるしさ。
残念ながら人間はミスを犯すんで、どうしても後からバグを発見する。
後から修正をするものだよ。
一つのブランチで作業しておいて、ある程度納得がいったら別ブランチに
抜き出せばいいと思うけど。コミットが整理されていれば簡単な作業だし。
それとレビューは間違いを見つけるものだから、修正が入るのはあたりまえだよ。
レビュー中はまだ作業中段階。作業中のごみコミットを残したままマージする必要はないよ。
一連のレビューが終わったら整理すればいいだけの話。整理し終わってそこで完成。
0505デフォルトの名無しさん
2015/05/20(水) 23:30:22.13ID:qzEPJuIN> 「そんなのすぐに終わる」って前提があるから、話がかみ合わないんだと思うが…ｗ
そんなのすぐに終わらないって前提がおかしいんだよ。
だって開発中に何度もコミットしてるじゃん？
その段階でコンパイルと自動テストしてるじゃん？
コミットがたくさんあるのなら、その分だけやってるわけじゃん
開発中にすぐに終わらない作業を何回もやってるのか？
まずそれを解決した方がいいぞｗ
0506デフォルトの名無しさん
2015/05/20(水) 23:35:21.24ID:qzEPJuINなぜなら、コミットの前後で修正されるファイルは少しだから
該当ファイル以外のオブジェクトファイルはそのまま使えるわけで
差分のみのコンパイルしかしないはずだから。
そして自動テストは作業中は関連のあるところだけテストすれば良い。
で、最終段階（もう変更がないと思った時点）で全部やればいいんだよ。
最後にブランチ内の全コミットをテストするのか！という疑問に対しては
だからぁ、コミット数が多いから大変なんじゃねぇかそれ。という話。
関連あるものはまとめろ。先にマージできるのは別ブランチに分けろ。
コミットは小さく分けろ。だが無駄なコミットはまとめろ。
0507デフォルトの名無しさん
2015/05/20(水) 23:39:45.06ID:MjY1jVeQ自動テストのテストケースの中には「アプリケーションの再起動」が含まれていることもあるかもしれない。
例えばWebサイトの開発とかでは、そういうのほとんどないだろうし、ぶっちゃけ過去より今が大事なのかもしれない。
（過去の状態が「Webサイトの純然たる作りかけ」とかだったら、そのスナップショットを完全に残すことに価値はないだろうし）
だから、全部のケースで使えるやり方ではないと思うが、否定する気はないよ。
その方が、短期的な効率は出るだろうしさ。
0508デフォルトの名無しさん
2015/05/20(水) 23:56:43.98ID:/feEo/hsgitのブランチって使いづらくね？
0509デフォルトの名無しさん
2015/05/21(木) 00:28:17.62ID:0lqSGmSkfix_numberブランチを作って"fix number value"ってログを書いてコミットしました
その後はプッシュする前に最新の情報を取得するべきって聞いたのでgit pullしました
そしたら
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details
git pull <remote> <branch>
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream-to=origin/<branch> fix_number_value
ってでました
これってリポート上のmasterブランチを指定したらいいんでしょうか？
実践で誰かと一緒に開発したことがないので怖くてどうしたらいいのかわかりません
ご教示おねぎあします
0510デフォルトの名無しさん
2015/05/21(木) 00:41:14.37ID:/NlBmKMh俺もそう思ってた
でもわかった、gitのブランチにはブランチモデルが必要なんだ
自由になんでも出来すぎるからブランチモデルで制約を付ける
「A successful Git branching model」てのを見つけて、
git-flowを使うようになってからだいぶまとまりが出来てきた
その後で他にもいくつかブランチモデルがあることも知った
今はブロジェクトの初めに
git-flowを使って「A successful Git branching model」をベースにやります。変更点はこれこれ。
みたいに宣言することにしてる。
だからお願い。VisualStudioにもgit-flow付けて、Microsoftさん。
0511デフォルトの名無しさん
2015/05/21(木) 11:22:31.08ID:PvdFF4ayなんか引っかかるねｗ
短期的じゃなくて長期的な効率が出てる。
ヘッダを書き換えれば多くのソースファイルに影響する話なら知ってる。
そうならないためのやり方があるのは知ってるかい？
ビルド依存を回避するような作り方をするんだよ。
あんたのやり方だと普段の開発から時間かかってしょうがないでしょ？
ちょっと修正するたびにビルドに多く時間がかかってるはずだよね。
それはもはやgitとは関係ない話だよ。
それからウェブの開発ではないって思ってるかもしれないけど、
今はウェブの開発でもビルド行う。
> だから、全部のケースで使えるやり方ではないと思うが、否定する気はないよ。
> その方が、短期的な効率は出るだろうしさ。
なんか、俺が知らないと思ってそういうこと言っているような雰囲気だが
俺知ってるからね？ ウェブだけじゃなくてビルドが必要な開発も。
0512デフォルトの名無しさん
2015/05/21(木) 11:33:41.78ID:PvdFF4ay最近の若いもんは〜みたいな発言になってるからだ。
言葉の節々に、ウェブ開発をしてるもんは〜とか
テストしてるわけがないはずだ〜とか
過去はどうでもいいと思ってるはずだ〜とか
まともな自分の想像ばかり言ってる。
0513デフォルトの名無しさん
2015/05/21(木) 11:34:23.74ID:PvdFF4ay× まともな自分の想像ばかり言ってる。
○ 的はずれな自分の想像ばかり言ってる。
0514デフォルトの名無しさん
2015/05/21(木) 11:55:03.21ID:PvdFF4ayこれに関してはだから何なんだ？といいたい。
（ごみ）コミットがたくさんあって、コミット毎に全部
アプリケーションの再起動を行っているのか？
だとしたら、テスト効率が極めて悪い。
10個のコミットがあって、それぞれのテストに
1時間かかるとしたら10時間じゃないか？
俺ならまずおおむね十分だと思われるテストだけを行って
コミットを減らしてからテストするね。5個に減らせば5時間で済む。
コミットしてテストした後で、さっきのコミットに混ぜるべきコードをコミットしてテストしたら
さっきテストした時間は無駄になるじゃないか。
後から修正が入るかもしれないような不安定な所のテストに時間はかけない。もう修正は入らないなって
思った時にちゃんとテストをする。コミットを減らしてテストしたらテスト時間も減る。
git以前にテストのやり方そのものを見なおしたほうがいいよ。
効率を考えないで流れ作業をこなしているかのような開発になってる。
0515デフォルトの名無しさん
2015/05/21(木) 12:05:21.48ID:PvdFF4ay> ブランチってほんとにみんな使ってる？
> gitのブランチって使いづらくね？
一人で開発してるとか？
使いづらいかどうかは置いといて
使わないと、複数人で並行して開発できないよ。
使いづらいと思ったことはないな。
最初の頃は苦労したけど、それはgitのブランチのせいではなくて
自分の技術力不足だってわかっていたし。
作者のリーナスがどうしても必要だって思って作った道具であり
gitの機能も必要だと思っているからこそ作ってるわけだしさ。
もっといい案があるというなら別だけど、わかってないのに
リーナスが作ったものに、ケチつけるなんてだいそれたことなんか出来んってｗ
わかった今ならよく出来てるって思うよ。
0516デフォルトの名無しさん
2015/05/21(木) 22:28:03.52ID:fr6zPWaF0517デフォルトの名無しさん
2015/05/22(金) 00:01:21.71ID:6DaqA/5uリーナスだろうと関係ないよ
リーナスには使いやすいものでも
俺には使いにくいってのは普通にあるよ
0518デフォルトの名無しさん
2015/05/22(金) 22:43:05.39ID:SSdLqWaE俺は一人開発だけど、master と daily の二つの branch を使っているよ。git 使い始
めの一年ぐらいは master だけだったけど。
master の commit/merge は version 番号より少し細かい粒度で行っている。daily
branch は bug/issue tracking の粒度より少し細かいぐらいで commit している。とい
うより、daily branch の commit message の殆どは bug/issue 番号に紐付けている。
Version 番号の粒度の履歴に bug tracking 粒度の履歴を残したくない。
ちなみに bug/issue tracking はソースとは別ディレクトリのテキスト・ファイルで
git 管理している。
>>508 gitのブランチって使いづらくね？
Time stamp が checkout 時刻に強制変更されてしまうのが使いにくいと感ずる。make
compile 時の便利さは分かるが、ファイルの time stamp 自体は重要な属性だから。俺
が git を作ったならば、time stamp を commit 時の時刻にするオプションを絶対設け
ていた。
実際には commit 時刻に変更する script を書いてあるけれど、殆ど使っていないの実
情だ。その script が必要になるのは master 側だけだから。そして その master 側で
push するときには、time stamp など構っていれらない状態が殆どだという実情なのが
情けない。
0519デフォルトの名無しさん
2015/05/23(土) 16:05:57.79ID:4OfmjrZC途中経過の整合性が合わなくなるのが許されたり、
途中経過の整合性を合わせるためのテストやり直しが許されることがあるんだな
pushした修正がバグってたからって、pushしたもんをリベースで打ち消すのはご法度と思っていたが
プロジェクトの大きさによってはそれもあり得るということか
0520デフォルトの名無しさん
2015/05/23(土) 17:21:41.69ID:x743ZDZ30521デフォルトの名無しさん
2015/05/23(土) 17:24:16.06ID:x743ZDZ3push後のリベースが許されるブランチを運用出来るように、プロジェクトをサブプロジェクトに分割したほうがgitを有用に使えるってことなのかもね。
0522デフォルトの名無しさん
2015/05/24(日) 00:38:55.87ID:NuukhrjTサブプロジェクトどころか、一人プロジェクトだな
0523デフォルトの名無しさん
2015/05/24(日) 10:38:28.38ID:GI5iGoR+gitだと特に、ブランチの運用によって前提が大きく変わる。
GitHub flowならチケット1つにつき1つ（1バグにつき1つ）ブランチができるから、
それぞれのブランチの寿命は数分〜長くとも数日程度であって、その間はブランチ上では基本1人でしか変更しない。
だからpushしたブランチをrebaseしてもまったく問題ない。
むしろレビューで指摘されたようなtypoや微修正が残ってると後で見にくい。積極的にrebaseを使ってほしい
0524デフォルトの名無しさん
2015/05/24(日) 11:16:37.86ID:VWanxcqXん〜と、前提が大ブランチになってるとそうかもしれないけど
Gitの得意技は作業単位で小さなブランチを山ほど作れる所にあるから
得意技を積極的に使った方がお得な気がするな
うちのチームは去年強制的にsvnからgitに移行してからコミット数もブランチ数も20倍くらいに増えた
その代わり、細かくコミットしろ、作業単位でブランチを分けろ
って、半年くらいは口うるさく言い続ける必要があったけどね
レビューの時にコミットツリー図を見ながら
ここはこういう意図で、こういう風にブランチを分けて欲しかった、とか
ややこしいコンフリクトが生じた時に
どういう手順ならマージが簡単だったかとか
具体的に教えたり、みんなで考えたりした
新しい文化を根付かせるのは大変だよ、いつでもさ
0525デフォルトの名無しさん
2015/05/24(日) 14:14:44.04ID:J9ZjzLe3branch を push する意味が理解できん。数分から数日しか存在しないブランチを何処
に push するの？
レビューアーの git に同じブランチを設けてリモート・ブランチにしているの？
0526デフォルトの名無しさん
2015/05/24(日) 15:41:15.45ID:1k2HbjOC0527デフォルトの名無しさん
2015/05/24(日) 19:35:16.30ID:LHzJ6dIN今コミットしたログの後にそのリモートのログが来てしまいました
git rebase -iで今コミットしたログを最新にしたいので順番を書き換えたいんですがリモートのログが表示されません。ローカルのログしか表示されません
git rebase -i HEAD^^^^^^みたいに^を増やしても出てきません
これってどうしたらいいんでしょうか？
0528デフォルトの名無しさん
2015/05/24(日) 19:41:30.07ID:Ewhf1zLwとなると、やはり 本体はSVNで、ローカルはgitで
別に管理したほうが全体が幸せになりそうだな
0529デフォルトの名無しさん
2015/05/24(日) 19:50:34.06ID:Jl9gFOkM共有ブランチ上でrebaseするんだったら、ブランチの生存期間を超えて共有ブランチ上で修正を続けているように見えるな
0530デフォルトの名無しさん
2015/05/24(日) 20:03:35.12ID:Jl9gFOkMこの人の場合、バグを修正したというコミットをmastarに残したくないのに、SVNだとコミットを後から修正できないのが不満だ
（それがレビューの邪魔？）というのが、gitを使っている一番の理由だろう
0531デフォルトの名無しさん
2015/05/24(日) 21:34:38.73ID:VWanxcqXそれはいい解の一つだと思う。特に移行期には。
うちも、svnから一気にgitに移行するか、git-svnを使うか結構悩んだ。
でも最後は俺がsvnとgitの両方を使うのが面倒くさいという判断で一気にgitに移行する方を選んだ。
当時の対象プロジェクトがちょうど区切り良く、
過去ログを捨てて一気に乗り換えることができるタイミンングだったのと、
フロアをまたがっているとはいえ、同じビルの中にチームの全員がいるので、なんかあったら顔を合わせて相談できる状態だったから決断できた。
最初はトラブル続出で、「判断間違えたかな？」と内心悩んでいたけど
結局馴染んでくればgitの方が扱いやすくなってきたよ。
しばらくして、VisualStudioがgit標準対応した時は「よっしゃ！」ってなった。
（でも日本語変だよマイクロソフトのgit）
0532デフォルトの名無しさん
2015/05/24(日) 22:05:23.23ID:VWanxcqXおれ>>524な
「この人の場合」が俺のことなのか、ほかの人なのか読み取れなかったんだけど、
俺がgit使ってる（使わせてる）理由の一番大きい所は
「間違えてリポジトリ壊しても俺が直してやる。安心してどんどんブランチ作れ！細かくコミットしまくれ！」って言える所だな。
俺の場合、バグとか間違ったコミットとかも積極的に残しておくことを推奨している。
レビューもそのままで特に問題は無かったな。
でも、「間違えても大丈夫」という安心感がないとみんなブランチ活用してくれないんだよ。
特に問題だったのは（svn使っていた頃の話ね）
何ヶ月もたってから、コードのここの部分て、修正入っているんだけど、意図がわからない、当時の担当者はもう居ない。何て事がよくあった。
svnだと、ブランチ＆マージとかコミットとかは結構大事（おおごと）で
みんな、自分の手元で完全に書き終わってからしかコミットしてくれなかった。
ブランチ＆マージはリーダーだけがやる仕事みたいな感じだったし。
そうなると、ログ上いっぺんにあっちこっち修正が入っている中で、特定個所の意図を読み取るのがものすごく難しくて困ったんだ。
今は「マージ操作間違えても俺が直してやる。
安心して、”変数名を書き換える”様な小さな修正でも各自でブランチ作って作業してくれ。」って言える。
これだけでも後から意図を読み取るのは随分楽になったよ。
0533デフォルトの名無しさん
2015/05/24(日) 22:19:55.92ID:mdHWC0Am一つのブランチに押しこんでるからじゃないの
機能まるまる追加とかなら経過をコミットで分けたほうがわかりやすいというのはわからんし
>>529
閉じたブランチ使わないでバグフィクス用のブランチで修正するのが筋だろう
>>527
リセットでヘッド戻して新しくブランチ切ってそっちにコミットして元のブランチに更新取り込んで新しいブランチをマージ
次から最初からブランチ切っとけばこんなことで困らん
0534デフォルトの名無しさん
2015/05/25(月) 03:10:39.76ID:WhsXE+Ib個人でブランチ作ってコミットしたあと、どうすればいいの？
そのブランチを本家に取り込ませるの？
0535デフォルトの名無しさん
2015/05/25(月) 05:59:36.31ID:/VFybrtgこれ大事よね
master に
0536デフォルトの名無しさん
2015/05/25(月) 06:01:10.35ID:/VFybrtg> でも、「間違えても大丈夫」という安心感がないとみんなブランチ活用してくれないんだよ。
これ大事よね
master に wip と fix typo が積み重なってた時は流石に萎えたけど
0537デフォルトの名無しさん
2015/05/25(月) 08:14:58.07ID:y6DNlXTS＞master に wip と fix typo が積み重なってた時は流石に萎えたけど
そういうのを、それがmasterにあろうと自分でリベースして消すのがその人のやり方なんだろう
0538523
2015/05/25(月) 09:19:23.83ID:E69UDjHE> >>523 だからpushしたブランチをrebaseしてもまったく問題ない。
>
> branch を push する意味が理解できん。数分から数日しか存在しないブランチを何処
> に push するの？
>
> レビューアーの git に同じブランチを設けてリモート・ブランチにしているの？
自分が作成・変更したブランチをpushする先はclone元のリポジトリの同名ブランチ。
典型的にはGitHub(GitLab)上には共有リポジトリがひとつしか存在しない。そのリポジトリはForkしない。ひとつのリポジトリのなかでブランチを使ってPull Request(Merge Request)する
0539デフォルトの名無しさん
2015/05/25(月) 13:36:42.28ID:XuKAmWn9まずその辺から説明してくれないとgitの運用方式に自由度が有り過ぎて話が噛み合わん
0540デフォルトの名無しさん
2015/05/25(月) 13:49:29.09ID:XuKAmWn9あんたがやりたいことはrebase本来の一番基本的な使い方で、rebase -iで自分で直接順番操作する必要は無い
検索すりゃ方法わかると思うので調べてみてくれ
0541デフォルトの名無しさん
2015/05/25(月) 22:51:38.00ID:o/eCAQPj書き換え前のコミットををベースにしている人への配慮が必要そうだな
各作業者に「共有ブランチ上のコミットを書き換えたいから、各自のブランチをリベース
してください」って頼んで回れる環境が必要だ
0542212
2015/05/25(月) 23:42:12.33ID:fVXVPz7Eアンインストール作業が苦痛なんですよ
makeだけでアンインストールさせてくださいよ
0543538
2015/05/26(火) 00:30:58.55ID:VHuDuKFu> 中央リポジトリにみんながpushしまくる方式で運用してるのか、Pull Request方式で運用してるのか、
> まずその辺から説明してくれないとgitの運用方式に自由度が有り過ぎて話が噛み合わん
中央リポジトリにみんながpushしまくって、中央リポジトリのTopicブランチ(各人がpushしたブランチ)から同じ中央リポジトリのmasterに向けてPull Requestする。
これが GitHub flow な。
元が「 >>522 Pushしたブランチは書き換えてはならん」への反論だから、
そうでない運用もごく一般的、という主張をしたということ。
0544デフォルトの名無しさん
2015/05/26(火) 08:35:26.55ID:n+9g7Zguこれじゃ>>522への反論になってないっていうか、>>522が言ってることそのままだな
0545デフォルトの名無しさん
2015/05/26(火) 17:27:09.33ID:sKFLbSMMそうだよ。だから、それができる範囲なら共有ブランチでもリベースして良いんだよ。
0546デフォルトの名無しさん
2015/05/26(火) 17:39:03.82ID:sKFLbSMM個人用ブランチは作成者だけが見るわけじゃないから>>522とは違うな。
>>522は、ブランチを公開することと、一部の人間がそのブランチに依存することと、不特定多数の人間が依存することの区別がついてないんじゃないか？
単に極論言って煽ってるだけかもしれないけどね。
0547デフォルトの名無しさん
2015/05/26(火) 18:06:24.50ID:2IsijlAj規約任せかツールかスクリプトか
0548デフォルトの名無しさん
2015/05/26(火) 18:23:29.30ID:O0gIeBts0549デフォルトの名無しさん
2015/05/26(火) 20:10:30.68ID:qT5tL8rR一回オプション総ざらいしてみよう
0550デフォルトの名無しさん
2015/05/26(火) 22:07:42.46ID:1ouiCH4Fで、>>519が言ってる「プロジェクトの規模が小さい場合には
それができる」って話につながってくるのか…。
0551デフォルトの名無しさん
2015/05/26(火) 23:55:53.54ID:2IsijlAjそれブランチごとじゃなくて一律だからアクセス制限にはならないぞ
0552デフォルトの名無しさん
2015/05/27(水) 12:17:18.05ID:98FdFg1Vhttps://github.com/git/git/releases/tag/v2.4.2
0553デフォルトの名無しさん
2015/05/31(日) 20:55:03.14ID:2hiQrePQa.txtをHEAD@{12}のa.txtの内容にしたいんです
git reset HEAD@{12} a.txtじゃ戻りませんでした
0554デフォルトの名無しさん
2015/05/31(日) 21:23:55.63ID:q0XD6tk+0555デフォルトの名無しさん
2015/06/01(月) 22:34:02.79ID:6w2KJtLOgit add -A
このaddを取り消したいんですがgit reset HEADをやると
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
ってでます
git add -Aで変更をインデックスに追加されているわけだからHEADを指定したらリセットできると思ったんですが何で出来ないんですか？
0556デフォルトの名無しさん
2015/06/01(月) 22:37:39.31ID:wXX1PCBE0557デフォルトの名無しさん
2015/06/01(月) 22:37:41.39ID:60FC1uF10558デフォルトの名無しさん
2015/06/01(月) 22:43:38.24ID:wXX1PCBEぐぐると git rm --cached が使えるみたいだな
0559デフォルトの名無しさん
2015/06/02(火) 10:41:16.23ID:2Bq+WaXR例えばデータベースの文字コードの設定の修正と、スタイルシートを変更した2点の場合
一緒にまとめたほうがいいんでしょうか？
0560デフォルトの名無しさん
2015/06/02(火) 22:36:32.71ID:ENh0ws/u0561デフォルトの名無しさん
2015/06/02(火) 22:37:29.49ID:dwjHRJAm0562デフォルトの名無しさん
2015/06/02(火) 22:37:35.29ID:H1H2VilBその二つならまとめない。
もし、データベースの文字コードを変更したことによりスタイルシートの変更が必要になったのであればぎりぎりまとめてもいい。
0563デフォルトの名無しさん
2015/06/03(水) 01:22:55.03ID:knJmPdD6そういうgit運用の話は、「管理者の意見に従うべき」
個人用or自分が管理者なら、好きなようにやっていい。
0564デフォルトの名無しさん
2015/06/03(水) 01:42:10.75ID:3kJPkUc2少しは助言してやれよ
0565デフォルトの名無しさん
2015/06/03(水) 03:55:40.59ID:cOL0IOxC色々試して自分が一番しっくりする形を探すか
最も採用されていると思えるやり方というのを見出してそれを選択するか
有名どころのオープンソースプロジェクトの方針を色々と見てくるといい
0566デフォルトの名無しさん
2015/06/03(水) 05:32:16.44ID:5OGKD7dqでも優先されるべきはそのリポジトリの管理方針なのは間違いない
0567デフォルトの名無しさん
2015/06/03(水) 10:17:17.28ID:qaWpPbOFうちはmultimail使ってるがなんかしっくり来ない
0568デフォルトの名無しさん
2015/06/04(木) 01:27:40.14ID:FZpfA7xpお前はどうやってるんだよ
0569デフォルトの名無しさん
2015/06/04(木) 10:38:54.51ID:ixdJmRIHその時はコミットをまとめろって言われたからソースコードのバージョン毎にコミットを全部まとめたよ
一体まとめろ！まとめるな！のこのスレの意見を統一してもらわないと俺みたいな初心者が無駄な道を通ることになる
1. initial commit
---- ここから -----
2. save
3. type
4. ○○実装
5.save
6.○○実装
7.typo
8.ファイル追加
----- ここまでまとめる -------
tagで1.0って付ける
0570デフォルトの名無しさん
2015/06/04(木) 10:43:29.77ID:lUVfOohh具体的にそのやりとは何スレ目だよ
0571デフォルトの名無しさん
2015/06/04(木) 10:47:48.34ID:w41Ky1ux「まとめろ」「まとめるな」で意見を統一するのは難しいと思うけど(そもそも状況によってどっちが良いかかわるだろうから)、
どういうときはまとめたほうがよい
どういうときはまとめないほうがよい
というガイドラインのようなものならある程度意見はまとまってきそうだね
0572デフォルトの名無しさん
2015/06/04(木) 13:46:30.21ID:7Y8AXPNC要するに、二つのコミットがあった時に、これが二つに分かれてる必要はあるだろうか？と考えればいい
0573デフォルトの名無しさん
2015/06/04(木) 13:49:14.71ID:5FZxl5co0574デフォルトの名無しさん
2015/06/04(木) 16:11:36.89ID:a/IZmogkgit 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が自動的に面倒見てくれてるんですか？
0575デフォルトの名無しさん
2015/06/04(木) 20:10:10.65ID:lUVfOohhrebaseで並び替えるのはコミットの変更差分(自分の前のコミットとの差分)ってことかな
>>574のrebaseによって、"modified a"コミットのa.txtを変更したという差分だけが"add b.txt"コミットより前の歴史へ移動するので、
"modified a"コミットにbは存在しなくなる
rebase -iでコンフリクトは起こる
例えば>>574の"add a"と"modified a"コミットの順番を逆にしたりすれば
0576デフォルトの名無しさん
2015/06/04(木) 20:23:21.52ID:69dFu2L0正直「そこの管理者の意見に従ってまとめろ」「同僚たちと同じようにまとめろ」って回答しかないな
0577デフォルトの名無しさん
2015/06/04(木) 20:46:29.00ID:b+4KVUcq大きくても機能ごとにはコミット分ける
でその間はプロジェクトごとに方針あれば何でも
0578デフォルトの名無しさん
2015/06/06(土) 22:34:59.14ID:4eOWDqlW俺がルールを決めなきゃいけない時だな
0579デフォルトの名無しさん
2015/06/06(土) 22:35:56.50ID:yk/a5xMgお前、マージ使ってないだろ？
まず前提として「一つのプロジェクトを複数の人が平行で開発している」という
個人プロジェクト以外のごく普通のプロジェクトの話なんだよ。
よくある間違いが、小さい規模の例だけで考えて、
それがそのまま大きな開発にも適用できちゃうって考えること。
君はその間違いはまってる。
（俺が知ってる）小さい規模ではこれでうまくいくんだ。ではなくて
大きな規模になった時それでうまくいくのか？を考えた方がいい。
適切なやり方というのは、規模によって変わるんだから。
0580デフォルトの名無しさん
2015/06/06(土) 22:41:32.51ID:yk/a5xMg問題は1コミットを後から見直すかどうかだよな。
後から見なおさないのであれば、どんなに意味不明な修正でも
同じ所を試行錯誤したコミットでも、何百行あるコミットでも
何十個もあるコミットでも、そのコミットを見ないのであればどうでもいい
でもあとからそのコミットを見るのであれば
修正内容が明確にわかるコミットが必要最低限あった方がいい。
あとからそのコミットを見るかどうかだよ。
もちろん俺はよく見る。
仕事でもその修正が適切であるかを見たり、
オープンソースとかでもある修正内容を見たり
だからコミットは分かりやすくなっていたほうがいいと考える。
0581デフォルトの名無しさん
2015/06/06(土) 22:46:03.75ID:yk/a5xMg> というガイドラインのようなものならある程度意見はまとまってきそうだね
コミットをまとめる or まとめないのが目的じゃないからね。
コミットを綺麗にするのが目的。
当然の話だけどガイドラインには理由が必要だろうね。
まとめる理由が。（もしまとめないのであれば、まとめない理由も）
コミットをまとめたりまとめなかったりして、綺麗にする理由は
簡単にいえば、後からコミットを見た時にわかりやすいように
するためなんだが、もっと細かい理由って必要だろうか？
0582デフォルトの名無しさん
2015/06/06(土) 22:54:18.21ID:yk/a5xMg・一つのコミットで複数の修正を行わない
理由 後からそのコミットを見た時何を修正したのかがわからなくなるから
・一つの修正を複数のコミットにわけない（分かれていればまとめる）
理由 後からそのコミットを見た時何を修正したのかがわからなくなるから
例外 リリースしてしまったコミットはまとめることは出来ない。
いま気づいたが、この「リリース」っていう概念が重要だな。
どの時点でリリースになるのかはそれぞれだろうが
master、もしくは共有ブランチににマージされた時点がリリースだと考える。
と考えると、やはり>>569の例ははマージ機能を使ってない時点で
一人で開発している場合にのみ通じる例だから、例としてふさわしくないんだよ。
0583デフォルトの名無しさん
2015/06/06(土) 23:00:59.08ID:OBriYrAJ0584デフォルトの名無しさん
2015/06/07(日) 00:12:36.70ID:5CuOmznLまとめる とか まとめない とかどちらか一方じゃない
どちらもやって、綺麗にしておけ。
0585デフォルトの名無しさん
2015/06/07(日) 02:04:34.40ID:VSY66R2E>>541と>>545のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」
って運用ルールでgitを使っている人がいたりするので、抽象的なガイドラインは決めるだけ
無駄ではないか
それを議論したって、自分がブチ上げたガイドラインを弁護し、他人がブチ上げたガイド
ラインの言葉尻を捕まえてロンパするだけの、言葉遊びの世界に入っていってしまう
0586デフォルトの名無しさん
2015/06/07(日) 02:08:39.07ID:VSY66R2Eそういう時は、「なんでgitなんか使わなきゃならないのか」に立ち戻るべきだと思う
0587デフォルトの名無しさん
2015/06/07(日) 02:48:23.33ID:5CuOmznL> >>541と>>545のやりとりにあるように、「共有ブランチにpushしたコミットすら編集してよい」
いないだろｗ
あぁ、なんで共有ブランチにpushしたコミットは
編集したらだめなのかを書いていなかったね。
物事は単純で、他人の役に立つことをしましょう、
他人の迷惑になることはうやめましょう。これだけだよ。
コミットは他人が見ることを考えれば、そして他人は何故見るのかを考えれば
コミットを綺麗にしておけば可読性が高くなって読む人の負担が減る。
これは他人の役に立つこと。
そして共有ブランチを修正したらだめというのは、他の人も
その共有ブランチから派生して修正しているので、その派生元が変わると
今まで参照していたものが履歴を残さずに変わるわけで何が起こったのかわからなくなるから。
これは他人の迷惑になること。
このように俺のガイドラインにはちゃんと理由がある。
反対のガイドラインを作りたいなら、その理由をいうことだけ。
でないと俺の意見に対抗できない
0588デフォルトの名無しさん
2015/06/07(日) 02:52:10.94ID:5CuOmznL俺が言ってる共有ブランチっていうのは、
他の人がそのブランチから作業をする、
または他の人がそのブランチにマージすると
という目的で作られたブランチのこと。
つまり他の人が参照しているだけならば
共有ブランチとは言わない。
参照しているだけならば、そのブランチが変わっても
他の人の作業のじゃまにはならないからね
0589デフォルトの名無しさん
2015/06/07(日) 02:54:19.37ID:5CuOmznLしっかりと書いたガイドラインを、俺以外に出すのまってま〜すｗ
0590デフォルトの名無しさん
2015/06/07(日) 10:11:47.35ID:V49LqTdE＞いないだろｗ
いや、>>541が「共有ブランチ上のコミットを書き換えるんだとしたら」と言ったのに対して
>>545が「そうだよ」と返しているので、いること自体は確かなようだ
545に対して、あなたがどうロンパするかは別に知らないが
0591デフォルトの名無しさん
2015/06/07(日) 10:31:51.05ID:V49LqTdE全部のコミットをひとつにまとめて周りから怒られなかったなら、
それは正しいまとめ方だったと思うんだけどね
0592デフォルトの名無しさん
2015/06/07(日) 12:19:13.74ID:5CuOmznL> 545に対して、あなたがどうロンパするかは別に知らないが
論破？ 何故そうするかの理由がないのだから、
まずその理由を言うのが先だろうｗ
0593デフォルトの名無しさん
2015/06/07(日) 12:20:45.23ID:5CuOmznL> 全部のコミットをひとつにまとめて周りから怒られなかったなら、
周りの人間がコードを見るということを知らないだけかもしれない。
スキルが低くてソースコード管理ツールすら知らない人もいるのだから。
だからそれは全く参考にならないな。
理由だよ理由。
俺は何故そうするかの理由を書いた。
この俺を論破する理由をかける奴はいないのか？ｗ
0594デフォルトの名無しさん
2015/06/07(日) 12:21:31.63ID:yxti539q0595デフォルトの名無しさん
2015/06/07(日) 12:52:14.95ID:V49LqTdE>>594
運用スレを建てても、荒らしがそこに移動するかどうかは別問題だと思う
0596デフォルトの名無しさん
2015/06/07(日) 13:04:07.08ID:yxti539q0597デフォルトの名無しさん
2015/06/07(日) 13:08:53.36ID:V49LqTdEなるほどそうかもしれないね
そういう意味だと、既存だとここあたりが適切なのかな
バージョン管理システムについて語るスレ10
http://peace.2ch.net/test/read.cgi/tech/1393147031/
0598デフォルトの名無しさん
2015/06/07(日) 13:12:32.75ID:5CuOmznL> 結局は>>585の言ったとおりになるという、悲しい現実
大丈夫。
俺が言った「ガイドラインを言う時は理由も明確書くこと」
のおかげで、今のところガイドラインは俺が言った一つしかでてない。
0599デフォルトの名無しさん
2015/06/07(日) 13:17:04.64ID:yxti539qここでされてるの横断的でない個別的な内容だからスレチ
0600デフォルトの名無しさん
2015/06/07(日) 13:18:47.22ID:V49LqTdEそっか、じゃあ新スレがいるか・・・
0601デフォルトの名無しさん
2015/06/07(日) 13:23:17.32ID:V49LqTdE＞今のところガイドラインは俺が言った一つしかでてない。
そりゃ出ないでしょ
誰も関わりたくないんだから
0602デフォルトの名無しさん
2015/06/07(日) 13:26:15.60ID:5CuOmznLスレ立てておいたよ。
Gitをより良くするための運用ガイドライン作成スレ [転載禁止](c)2ch.net
http://peace.2ch.net/test/read.cgi/tech/1433650988/
>>601
> 誰も関わりたくないんだから
関わりたくないのが理由っていうのはおかしな話だな（笑）
言い返せない時に汎用的に使えそうな言い訳だ。
0603デフォルトの名無しさん
2015/06/07(日) 13:31:19.54ID:V49LqTdEありがとう
じゃあここから先は、ここで運用系の話をするのはスレ違いってことで、
あとはそっちでやってもらおう
0604デフォルトの名無しさん
2015/06/07(日) 13:42:31.68ID:yxti539qタイトルを単にGit運用スレにできないあたり自己顕示欲あふれるスレタイですね
0605デフォルトの名無しさん
2015/06/07(日) 15:41:57.12ID:D5MO+jlJ0606デフォルトの名無しさん
2015/06/07(日) 18:26:22.23ID:5CuOmznL0607デフォルトの名無しさん
2015/06/07(日) 18:53:47.38ID:V49LqTdE荒らしが自分で建てたスレなんだから、そうなるのはしょうがない
運用の話はそっちでやってもらいましょう
0608デフォルトの名無しさん
2015/06/07(日) 19:53:48.87ID:yxti539q期待してますよ
0609デフォルトの名無しさん
2015/06/07(日) 20:06:44.60ID:5CuOmznLはい当然です。 Gitの運用方法に関するレスは全部向こうに移動します。
みなさんも協力してくださいね。
逆に運用以外の雑多な内容はこっちに移動しますよ。
0610デフォルトの名無しさん
2015/06/07(日) 21:10:56.78ID:V49LqTdEおみごと
0611連続書込しすぎなのでID変えます
2015/06/07(日) 21:22:11.43ID:rs3gN1uEどれだけのレスが残るか期待ですｗ
ぜーんぶかっさらっていきますよーｗ
0612デフォルトの名無しさん
2015/06/07(日) 21:49:02.86ID:HSoSL4U1バグトラッキングツールでおすすめのはある？
mantisってもう人気無い？
0613デフォルトの名無しさん
2015/06/07(日) 21:52:12.28ID:V49LqTdEまたは、ツールの質問に答えられる人なんて初めからいなかったのかがハッキリするな
どっちにしても平和になってよかった
0614デフォルトの名無しさん
2015/06/07(日) 21:57:36.23ID:/P0faz6I画面上でどういう操作をすればいいんでしょうか？
0615デフォルトの名無しさん
2015/06/07(日) 22:03:03.72ID:rs3gN1uE0616デフォルトの名無しさん
2015/06/07(日) 22:13:31.59ID:rs3gN1uEよめ
◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
0617デフォルトの名無しさん
2015/06/07(日) 22:14:24.04ID:rs3gN1uEなんか良いツール無いですか？
0619デフォルトの名無しさん
2015/06/07(日) 22:16:39.42ID:UKZkpptuそんなのIDEの機能に頼るより、そのコミットを修正するコミットを作った後に
コマンドラインからrebase -iで順番入れ替えてsquashしたほうが簡単じゃないか？
0620デフォルトの名無しさん
2015/06/07(日) 22:17:04.27ID:/P0faz6I目次にどこにもEgitの話が出てないんですけど、どこに載ってるんですか？
0621デフォルトの名無しさん
2015/06/07(日) 22:18:17.74ID:/P0faz6IEclipse上で開発してるので、自分はEgitの方が楽です
0622デフォルトの名無しさん
2015/06/07(日) 22:41:10.16ID:UKZkpptuおれが使ってるのはIntelliJ IDEAだけど、Git関連は全部GUIでやるよりコマンドラインも併用したほうがいろいろ楽
ちなみにIntelliJ IDEAではrebase -iもGUIで出来るんで試しにやってみたけど、
思ったほどじゃないけどちょっと面倒
EGitもEGit rebaseでぐぐれば手順説明がいろいろ見つかるな
一応できるみたいだよ
Rebase Interactiveとかあるらしい
0623デフォルトの名無しさん
2015/06/07(日) 22:44:07.71ID:/P0faz6Iで、そのやり方を知りたいわけです
0624デフォルトの名無しさん
2015/06/07(日) 22:44:51.36ID:rs3gN1uEいやいや違う。Egitの方が楽というのは言い訳だ。
楽というのは事実だろう。だがそれはCLIで
gitを使えないことの理由にはなっていない。
はっきり言おう。君はCLIでgitを使えないだけだ。
それはEgitが楽という事実とは無関係だ。
CLIでgitを使えるようになったほうがいいよ。
そうすればEgit＋CLIのコマンドで検索すれば簡単に見つかる。
>>618で訂正したが、やっぱり君が読むべきものはPro Gitだ。
GUIツールの機能はCLIを使える知識がなければ理解できないだろう。
いくつか使ってみたが、どれもいきなりCLIのコマンド相当のものがメニューにあるから
初めて使う人は「この機能なにをするものなんだ？」ってなるだろう。
で、CLIのコマンドを知らない人でも簡単に理解できるGUIツール無い？
プログラマーではないウェブデザイナー（HTMLとかCSSを書く人）にも
使ってほしいと考えてるんだけど。
0625デフォルトの名無しさん
2015/06/07(日) 22:46:34.98ID:UKZkpptuだからEclipseで普通にコミットを作ってRebase Interactiveしろよ
amendは知ってるんだから普通にコミットを作るのはできるんだろ？
0626デフォルトの名無しさん
2015/06/07(日) 22:49:18.28ID:/P0faz6Iコミットは作れるんですが、Egit上での対話的リベースの使い方が分からないんですよね・・・
0627デフォルトの名無しさん
2015/06/07(日) 22:51:21.60ID:UKZkpptuヒストリーのコミットで右クリックすりゃRebase interactiveがあるらしいぞ
0628デフォルトの名無しさん
2015/06/07(日) 22:52:20.19ID:/P0faz6Iそこまでは分かるんですが、そのあとの操作の仕方が・・・
0629デフォルトの名無しさん
2015/06/07(日) 23:03:17.96ID:rs3gN1uEバージョン管理ツールをGUIにしても使いにくいのは
ソースコードを管理するということの意味がわからないからだろうな。
例えばペイントソフトは、そのツールを使う前から
絵を書いたことがある。それと同じことをツールを使ってやるだけ
でもソースコードを管理ツールは、そのツールを使う前にそのツールと同じことをやっていない。
ソースコードを修正している人であっても、ソースコードを管理していない。
（※バックアップはソースコードの管理じゃない）
だからそれをGUIにしたところで、何をするのかわけがわからない機能ばかりで
使い方がわからない。（もしくはバックアップという間違った用途に使うだけ）
ふぅ。そういうことを知らないし、知る必要が少ないウェブデザイナーに
どうやって使いやすい環境を提示できるだろうか。
0630デフォルトの名無しさん
2015/06/07(日) 23:03:38.86ID:UKZkpptuその様子だと直前じゃないコミットを修正するって行為がどういう意味を持つか理解できてないだろ？
Gitに慣れるまではおとなしく新しいコミットで修正しとけ
0631デフォルトの名無しさん
2015/06/07(日) 23:07:11.82ID:/P0faz6Iそうじゃなくて、それをしたくないから、Egitでのやり方を知りたいわけです
0632デフォルトの名無しさん
2015/06/07(日) 23:10:20.71ID:UKZkpptuEGit使おうがコマンドラインでやろうが、途中のコミットを修正するってことは単純な行為じゃないんだよ
コンフリクトが発生する可能性があるの理解してる？
0633デフォルトの名無しさん
2015/06/07(日) 23:15:59.04ID:rs3gN1uE当たり前のことを言うけどさ、プログラマっていうのは技術者だよ？
技術者と何故呼ばれるかというと、それは技術がなければできないことが
できるから技術者なんだよ。
今君が言っていることは「技術者になりたくない」って言っているのと
同じことだってわかってる？ 楽とか大変とかじゃない。
技術をつけること事拒否することは、技術者になりたくないと言ってるのと同じ。
CLIでgitの使い方を学ぶのが技術をつけるのに一番の近道なんだよ。
別にGUIが楽なら普段はGUIを使っていい。でも技術自体はちゃんとつけておけ。
0634デフォルトの名無しさん
2015/06/07(日) 23:16:28.99ID:/P0faz6Iできるなら、ここ以外でツールの話を分かりそうな人がいる場所を教えてくれるとうれしいですが
0635デフォルトの名無しさん
2015/06/07(日) 23:17:36.07ID:rs3gN1uEなんならまたスレ立てようか？
「git関連のGUIツールの使い方を教えて下さい」っていうスレ
0636デフォルトの名無しさん
2015/06/07(日) 23:18:36.91ID:/P0faz6I（・・・っていうか、むしろこの状況ならそっちの方が知りたいです）
0637デフォルトの名無しさん
2015/06/07(日) 23:21:41.41ID:rs3gN1uE難しいのかがわかった。
普通CLIが難しい理由は「コマンドを覚えないといけないから」で
その「コマンドを覚える必要がないから」GUIは簡単なんだ。
でもソースコードの管理ツールの場合、コマンドを覚えることよりも
そのコマンドで何が出来るか、何をするかがわからないから難しい。
ボタンひとつでコマンドを呼び出せても、そこから何をすればいいか
わからないんだよね。この人のように。
0638デフォルトの名無しさん
2015/06/07(日) 23:23:55.02ID:/P0faz6Iっていうか、ここがgit関連のツールの使い方を聞ける場所になったんじゃないんですか？
>>612さんのように、CUIじゃない質問をしてる人もいますし、ここでGUIだけ絞る必要もない気がしますが・・・
0639デフォルトの名無しさん
2015/06/07(日) 23:31:22.51ID:1F5PzSNl最低限英語できるならstackoverflow.com、機械翻訳でも多分他の人が適当に質問自体修正してくれる
ja.stackoverflowでもいいけど回答くる確率は落ちる
0640デフォルトの名無しさん
2015/06/07(日) 23:34:31.78ID:rs3gN1uE聞くのは構わないが答えるとは限らないｗ
質問したところで>>612さんのように放置される。
このスレからgitフローのような運用に関する話が
分離しただけで、ここがなにかに変わったわけじゃない。
0641デフォルトの名無しさん
2015/06/07(日) 23:37:00.95ID:/P0faz6I自分の場合は、GUIが簡単でCLIが難しいからじゃなくて、
Eclipse上でそのまま操作できるのが楽だから、なんですよね
あなたがEgitを知らなくて、自分はEgitのことを知りたいので、
分からないなら「分からない」って言ってくれて全然かまいません
>>639
なるほど、そっちの方が良い人がそろってそうですね
英語にはさほど抵抗ないですし、そっちで質問してみます
ありがとうございました
0642デフォルトの名無しさん
2015/06/07(日) 23:39:46.62ID:rs3gN1uEこんな感じでどんどん減らしていくので、4649！
0643デフォルトの名無しさん
2015/06/07(日) 23:43:59.53ID:UKZkpptuほらよ
http://another.maple4ever.net/archives/2060/
このブログの後半の「コミットを改変する場合」な
0644デフォルトの名無しさん
2015/06/08(月) 08:05:44.37ID:USedaFhj0645デフォルトの名無しさん
2015/06/08(月) 08:53:59.64ID:Q2pvFPhj0646デフォルトの名無しさん
2015/06/08(月) 11:32:29.03ID:AXPER4TO併用が無難だよ
0647デフォルトの名無しさん
2015/06/08(月) 11:48:08.05ID:I6Rw7h/u0648デフォルトの名無しさん
2015/06/08(月) 12:15:16.89ID:obzwvKmsプルダウンメニューでブランチを替えて、
ファイルを編集したら未コミットのリストがリアルタイムで追随、
マージはブランチのドラッグアンドドロップで一発、
プッシュはsyncボタンで一発。
でもたまによくあるCLIの作業からは逃れられないけど
0649デフォルトの名無しさん
2015/06/08(月) 13:31:33.83ID:AXPER4TOブランチのブラウズもGUIのを使う
ここらへんは非CLIでやることのメリットを感じるね
0650１０人に１人はカルトか外国人
2015/06/08(月) 14:46:48.11ID:KHrLNVN4・沢山の人が偏った意見を一貫して支持する
偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法
・不利な質問をさせなくしたり、不利な質問には答えない、スルーする
誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法
偏った思想や考え方に染まっていたり、常識が通じない人間は、頭が悪いフリをしているカルト工作員の可能性が高い
靖国参拝、皇族、国旗国歌、神社神道を嫌うカルト
10人に一人はカルトか外国人
「ガスライティング」で検索を！
0651デフォルトの名無しさん
2015/06/08(月) 20:44:04.47ID:BwIK9Ub/自分でサーバー立てるか、どっかのサービス利用するかで回答が変わってくるな
0652デフォルトの名無しさん
2015/06/08(月) 20:51:15.26ID:xf2QCU7pここはgitのスレです。
gitではない話はスレ違いです。
0653デフォルトの名無しさん
2015/06/08(月) 21:50:53.55ID:I6Rw7h/u親玉のサーバをLinuxで自前で立ててあります
今は3人くらいでpushしてる
0654デフォルトの名無しさん
2015/06/09(火) 00:40:12.96ID:LoeafuSM既にホスティング環境があって、同じサーバーにbts立てられるっていうことならredmineかな。
ただ、redmineは設定に躓くとちょっとめんどい。うまくいけばbts部分はかなり高機能だし、プラグインで色々拡張もできる。
ホスティング環境も移れるなら、gitbucket (https://github.com/takezoe/gitbucket )とか手軽でいいかもしれない。
javaとtomcatが用意できれば始められるし、それでいてgitホスティングとかpullrequest、issue連携とかの機能は揃ってる。
ただ、gitbucketはbtsとしては高機能とは言えないので、凝ったことしようとすると不満が出るかもしれない。
0655デフォルトの名無しさん
2015/06/09(火) 09:04:20.23ID:QNGnbMWJものすごく使いやすい。設定はほぼ不要。
redmineはBTSとしてはいいが、ソースコードを
快適に修正するための機能がない。
具体的に言えば「プロジェクトをフォークして、個人用の
フォークプロジェクトで行った修正をマージする」といった
極めて重要な機能がない。
あとBTSはもう古いね。今はITS。
BTSだとITSとして使えるようにカスタマイズしないといけないから
初期状態で使いにくい（そして初心者は使いにくいことに気づかないまま
使いにくいものを使い続けてしまうよ）
0656デフォルトの名無しさん
2015/06/09(火) 21:00:02.32ID:mCgHqgj4確かに高機能だし、本格的に始めたいならいいよね、gitlab。
0657デフォルトの名無しさん
2015/06/09(火) 21:14:19.30ID:gDccibNxいっかいインストールしたけど
使い方がわからなくてあきらめたんだよな
もう一度頑張るか
0658デフォルトの名無しさん
2015/06/10(水) 01:07:42.05ID:7XQM9Exq今は公式リポジトリが出来たよ。
普通にapt-get, yumでインストールも
アップデートもできるようになった。
>>657
BTSはMantisをちょっと触っただけだけど考え方が違う。
BTSだともぐらたたきゲームのようにバグが湧いてきて
それを「通報がありました」「バグを確認しました」
「誰かにアサインしました」「修正しました」「リリースしました」
のように随時状況を報告しながらバグを退治。
他の人がそのステータスを確認するっていうフローが想定されている。
そのフローが準備されているからバグ退治の流れはそれに乗っかればいいが
アプリ開発（新機能追加など）はやりにくい。
gitlabだと（githubもそうだが）逐一状況を伝える事はしない。
ラベル機能とかで出来なくはないが、BTSではないのでバグ退治のフローはない。
代わりにあるのがアプリ開発のためのIssueでバグを含めた課題全般を取り扱う
リリース済みでバグが次から次へと発覚して、それを急いで直さなきゃ。みたいな状況ならBTSの方がいいかもしれないね。
ITSはもう少し安定していて、マイルストーンを決めてそこまでに対応するという感じ。
もちろん急ぐ奴はすぐリリースしても良いけどね。
フローの話になったから、こっちのほうが良かったかｗ
Gitをより良くするための運用ガイドライン作成スレ [転載禁止](c)2ch.net
http://peace.2ch.net/test/read.cgi/tech/1433650988/
0659デフォルトの名無しさん
2015/06/10(水) 22:15:34.72ID:rQ07tGpqhttp://codebreak.com/ja/
0660デフォルトの名無しさん
2015/06/10(水) 23:21:39.44ID:19Nfo0Ba0661デフォルトの名無しさん
2015/06/10(水) 23:38:29.29ID:EBTmmvru日本の法律下にある他人の鯖にソースコードを預けたくないな
0662デフォルトの名無しさん
2015/06/11(木) 05:00:08.95ID:QpuB/nCQ0663デフォルトの名無しさん
2015/06/11(木) 06:29:11.47ID:6Kqx+wy+0664デフォルトの名無しさん
2015/06/11(木) 06:32:27.10ID:6Kqx+wy+>>569 ってだれかとおもった
0665デフォルトの名無しさん
2015/06/11(木) 06:40:44.25ID:6Kqx+wy+最後の２行について言うと
それはGUIとしての完成度が低いと言う見方もあるな
馬鹿なデザイナーでも使えるようにする必要があるかどうかは知らん
>>633
その通り
0666デフォルトの名無しさん
2015/06/11(木) 08:05:33.95ID:bgrkp9n0難しい手順を覚えるのは技術のうちに入らない。
それは単にプロトコルに習熟しただけ。
例えばENIACプログラミングを今更やる奴は殆ど居ない。
本質的な結果を出す為の過程を単純化した方法を作り出すのが技術。
テクノロジーの語源からも明らか。
0667デフォルトの名無しさん
2015/06/11(木) 08:12:02.69ID:IhjRP6Evcliはシェルと組み合わせれば半自動で色々できるから好き。
0668デフォルトの名無しさん
2015/06/11(木) 19:58:54.95ID:pGn6KOhY> ソースコードや個人情報等の情報およびその投稿に関する禁止事項
> 3.ソースコードに、自己または第三者の連絡先を記載または暗示すること
> その他一般的な禁止事項
> 4.本システムを通じて入手した情報を、複製、販売、出版、その他私的利用の範囲を超えて使用する行為
ライセンス文もまともに書けず仮に公開したとしても使用には強い制限がかかる
誰がこんなバカな規約書いたんだよ
0669デフォルトの名無しさん
2015/06/11(木) 20:52:13.58ID:0L5sgKmI0670デフォルトの名無しさん
2015/06/11(木) 21:10:32.77ID:d4+JHvzb0671デフォルトの名無しさん
2015/06/11(木) 21:49:51.01ID:QpuB/nCQ島国根性丸出しのジャップ猿が退化させてやんの
死ねよもう
0672デフォルトの名無しさん
2015/06/11(木) 21:56:58.54ID:jxx/4OCHgitlabがある
https://about.gitlab.com/gitlab-com/
Unlimited repositories
Unlimited private collaborators
Unlimited disk space*
Completely free, no credit card required
0673デフォルトの名無しさん
2015/06/11(木) 22:05:30.61ID:0L5sgKmIありがとうございます！見てみます！
0674デフォルトの名無しさん
2015/06/11(木) 23:21:46.83ID:lwbpITef> 難しい手順を覚えるのは技術のうちに入らない。
なにドヤ顔で嘘ついてるのさｗ
手順覚えるだけでも運転技術だし
飛行機の操縦も船の操縦も手術も手順覚えるだけだから
技術じゃねーってことになるな
0675デフォルトの名無しさん
2015/06/11(木) 23:34:12.67ID:YENRiAY6飛行機も船も手術も知識があるうえで感覚も必要なもんだから誰でも同じにはならんわな
0676デフォルトの名無しさん
2015/06/11(木) 23:36:23.68ID:lwbpITefは？ ハンドルを右に切れば
右に曲がりますが？
0677デフォルトの名無しさん
2015/06/11(木) 23:37:09.16ID:MEVqNqhj0678デフォルトの名無しさん
2015/06/11(木) 23:37:32.79ID:lwbpITefgitも知識があるうえで感覚も必要なもんだから誰でも同じにはならんわなｗ
コミットの内容も、コミットの順番も人それぞれ違ったものになる。
0679デフォルトの名無しさん
2015/06/11(木) 23:38:20.68ID:lwbpITefワロタｗ うまいね
あいつにはgit技術があるって聞いてgitの手順覚えてるだけかよって思う奴は少ないわな
なるほど、gitの手順だけ知っていて
それを技術があるって思い込んでる奴だったのか！
0680デフォルトの名無しさん
2015/06/11(木) 23:40:40.14ID:VCTHLF0Pどいういう風にブランチとコミットを
組み立てていくか、それがgitを使うということ。
その技術次第で、過去の修正の内容が分かりやすくなったり
ごちゃごちゃで意味不明になったりする。
きれいなコミットだとrevertしたり、cherry-pickも簡単なんだが、
だめなやつがやると使えないコミットだらけになるもんな。
0681デフォルトの名無しさん
2015/06/11(木) 23:41:01.81ID:OzhCdhwcですが社内のプログラマが同じバージョンのものを使うようにしたいため
Gitのサーバを構築して、GitHubのを社内にコピーしてプログラマは
社内のGitサーバから落してもらうようにしたいのですが、このような
使い方はできるのでしょうか？
用語が分からないので上手く説明できませんが、もしできる場合は具体的に
どのようにすればばよいのでしょうか。
0682デフォルトの名無しさん
2015/06/11(木) 23:42:44.09ID:VCTHLF0Pgithubで公開されているものを使うってだけなら、
submoduleを使えばいいだけ。
特定のバージョン（コミット）を指定して参照することができる
0683デフォルトの名無しさん
2015/06/11(木) 23:42:53.47ID:bgrkp9n0先人が作り上げた技術に「習熟」する事と、改善等を加える事との区別ぐらい付けよう。
0684デフォルトの名無しさん
2015/06/11(木) 23:45:06.84ID:VCTHLF0P飛行機だってマニュアルがあって
先人が作り上げた技術を
「習熟」するだけですが？
なにか言う前に矛盾しないか
少し考えてから発言しようよｗ
0685デフォルトの名無しさん
2015/06/11(木) 23:51:54.22ID:bgrkp9n0「習熟しただけ」のパイロットもどきが事故起こすんだよなあ。
まあ、プログラム言語の文法覚えた「だけ」の奴には難しかったか。
0686デフォルトの名無しさん
2015/06/11(木) 23:54:53.44ID:VCTHLF0P> 「習熟しただけ」のパイロットもどきが事故起こすんだよなあ。
だからなんなんでしょうか？ｗ
「習熟しただけ」のパイロットもどきが事故起こすが
「習熟した」以上の技術をつけたのパイロットは事故を起こさない
「習熟しただけ」のgitつかいもどきが、くそきたないコミットを作るが
「習熟した」以上の技術をつけたのgitつかいはきれいなコミットを作る。
あれあれ？ 同じことですねｗ
0687デフォルトの名無しさん
2015/06/12(金) 04:30:47.16ID:XoMzVDAf定石から外れたことをするとどうなるかまで知ってる人と
定石通りのことしか出来なくて定石から外されると負ける（前者なら普通勝てる）タイプの人が居るね
0688デフォルトの名無しさん
2015/06/12(金) 05:33:48.07ID:KE10iP2h0689デフォルトの名無しさん
2015/06/12(金) 07:55:39.88ID:DpgRw3ep見苦しいから、その辺にしとけ。
>飛行機だってマニュアルがあって
>先人が作り上げた技術を
>「習熟」するだけですが？
こういう甘い発想の奴は困るんだよなあ・・・
0690デフォルトの名無しさん
2015/06/12(金) 08:28:50.68ID:K1SJqQ2pgit 使うような人はそのマニュアルを作るような立場の人が多いんだが
0691デフォルトの名無しさん
2015/06/12(金) 08:41:22.54ID:UHhWvxxEわかる
このスレ「管理者の方針に従えばいい」
俺「俺がその管理者なんだよ〜。どうやってルール決めればいいかわかんねーよ」
0692デフォルトの名無しさん
2015/06/12(金) 09:11:20.96ID:uZJNyCxRhttp://hissi.org/read.php/tech/20150611/VkNUSExGMFA.html
http://hissi.org/read.php/tech/20150611/SUdTbEt3Wnk.html
http://hissi.org/read.php/tech/20150612/MGtLbjJuSjU.html
http://hissi.org/read.php/tech/20150612/dzVHdW5NWTY.html
0693デフォルトの名無しさん
2015/06/12(金) 19:21:58.70ID:w9SfTIdr適切な対応を選択し、実行する
これは操作方法だけじゃ無理だよ
0694デフォルトの名無しさん
2015/06/12(金) 19:48:06.43ID:OQHJwW6BGitにアップロードするためのツールとしてTortoiseGitを使っているのですが、
最初にアップロードする(プッシュする)のはいいとして、
ローカルの中身を更新した際、プッシュしてもオンライン上で全く同じ状態にはならず困っています。
具体的には、オンライン上で「ファイルA・ファイルB」、ローカル上で「ファイルA・ファイルC」とあった場合、
プッシュするとオンライン上で「ファイルA・ファイルB・ファイルC」となって、ファイルBが削除されないのです。
いちいちブラウザ上で手動で削除するのが面倒なのですが、何か上手い方法はあるのでしょうか。
また、各種Gitツールを使わず、ブラウザからレポジトリに直接ファイルをアップロードすることはできるのでしょうか？
0695デフォルトの名無しさん
2015/06/12(金) 20:10:35.67ID:AMVc4lNO> ファイルBが削除されないのです
TortoiseGit のメニューから削除してないんじゃない？
> ブラウザからレポジトリに直接ファイルをアップロード
サービスの提供者に聞いてどうぞ
0696デフォルトの名無しさん
2015/06/13(土) 01:44:19.98ID:2XvJk2DZえとさぁ、見苦しいよ。
人のコメントを引用して、
そのことについて、何が間違ってるかを
何一つ書かないで、言い返した気になるのは。
0697デフォルトの名無しさん
2015/06/13(土) 01:47:39.52ID:2XvJk2DZ> 俺「俺がその管理者なんだよ〜。どうやってルール決めればいいかわかんねーよ」
社内に詳しい人がいないなら、社外の知識を利用すればいいのでは？
最近はオープンソースでgitでどういうコミットをしているのか
見ればすぐにわかるし、資料も多いし、２ちゃんねるでもこっちのスレで詳しくやってるよ。
Gitをより良くするための運用ガイドライン作成スレ [転載禁止](c)2ch.net
http://peace.2ch.net/test/read.cgi/tech/1433650988/
0698デフォルトの名無しさん
2015/06/13(土) 01:50:44.54ID:2XvJk2DZ> 外部の刻々と変わる環境に対して、
それはわかる。単にコマンドを覚えるだけじゃなく
gitの外部の環境＝ソースコードに応じて
適切な順番と内容で対応を変更して実行する。
これはコマンドを覚えるだけじゃ出来ないからね。
それは他の人のコードのブランチをレビューしていて
痛いほどよくわかってる。コマンドを使うことは出来る
だけどあるべき姿のものを作れない。
0699デフォルトの名無しさん
2015/06/15(月) 00:59:50.94ID:PH3D3/9J0700デフォルトの名無しさん
2015/06/15(月) 11:20:49.71ID:ZM3mWJtN0701デフォルトの名無しさん
2015/06/15(月) 11:37:12.53ID:HDA/Cn6G0702デフォルトの名無しさん
2015/06/16(火) 00:13:48.85ID:7C1PfN58ありがとうございます。
submoduleでいけました。
0703デフォルトの名無しさん
2015/06/16(火) 01:55:47.83ID:LRuQsu+J>>701
懐かしい。
チャーリー浜かよw
0704デフォルトの名無しさん
2015/06/16(火) 13:15:18.31ID:AmmNKqz/これどういうことですか？
同じ文字列が削除されて追加されているコミットってどうやって作るんですか？これ何の意味があるんですか？
0705デフォルトの名無しさん
2015/06/16(火) 13:16:28.66ID:TZUCxsD30706デフォルトの名無しさん
2015/06/16(火) 13:28:36.36ID:dzgBqGJj行末のスペース無くなってるだけとか
TABがスペースに置き換わっただけとか
たまによくある
0707デフォルトの名無しさん
2015/06/16(火) 21:45:33.41ID:gqnH2dL30708704
2015/06/17(水) 00:09:44.91ID:zdNvSItr0709デフォルトの名無しさん
2015/06/17(水) 19:22:19.83ID:Uu1OTzajhttps://github.com/git/git/releases/tag/v2.4.4
0710デフォルトの名無しさん
2015/06/18(木) 00:27:48.54ID:7B4eGBDbそのサイトでGitHubのアカウントを登録してGitHubから引っ張ってくるんですが、
登録さえしてしまえば普通にcloneで取ってこれます。
それをsubmoduleで使いたいんですがローカルリポジトリに追加してコミット、
自分のサーバのリポジトリにプッシュしても、他の人が使えません。
自分自身も一度ローカルを消して、自分のサーバからクローンしようとしても
エラーになってしまいます。
このような場合はどうすればよいでしょうか?
0711デフォルトの名無しさん
2015/06/18(木) 00:33:40.72ID:vn28fqVfまずこの意味がわからない
＞GitHubのアカウントを登録してGitHubから引っ張ってくる
具体的に何やってるの？
0712デフォルトの名無しさん
2015/06/18(木) 01:25:52.57ID:X9wRJKf5submoduleのリポジトリも含めて皆がcloneできる場所において、
submoduleの参照先を変えないとだめかもしれない。
0713デフォルトの名無しさん
2015/06/18(木) 19:53:58.42ID:lbH07egD.gitmodulesの示す先がローカルのパスか、その別サイトにログインできないとcloneできないとか
そんなんじゃね？
0714デフォルトの名無しさん
2015/06/18(木) 20:20:22.80ID:lbH07egDgithubを監視するようなサイトが幾つかあるけど、そんな中にミラーを提供する奴もあったかもしれない
(うろ覚えでオセロか何かそんな名前のサイトがあった気がするけど今見たら消えてるな・・・)
そういうのを使ってるんだろう
と、エスパーしてみた
0715デフォルトの名無しさん
2015/06/21(日) 16:52:03.91ID:YPeQCGDm別の最新の更新内容をpushしようとしたら
pullしろっていわれたのでpullしたらコンフリクトしました
こういうときってどうやってコンフリクト起こさずにログを修正したらよかったんですか？
0716デフォルトの名無しさん
2015/06/21(日) 17:00:11.07ID:RKAD3ekVあんたのレベルだとpush済みのタイポをrebaseで直してpushしようとしたらダメだ
多少歴史が汚くなるとしてもタイポも新しいコミットとしてpushすべき
0717デフォルトの名無しさん
2015/06/21(日) 18:17:52.76ID:0NmNrFCo>>712
>>713
>>714
どうもすいません。ちょっとてんぱり気味でした。
>>713のおっしゃる通りです。
ただユーザー名とパスワードを書くのは引けるので調べたところ
GitGubでトークンというのを作って.gitmodulesに書き込む事で
うまくいきました。
0718デフォルトの名無しさん
2015/06/21(日) 18:55:06.03ID:/gMpDjZs0719デフォルトの名無しさん
2015/06/22(月) 02:49:01.15ID:j9mWyPD+>>716は無視していい（笑） おそらく>>716自体がやり方をわかっていない。
>>716自信がが説明できるレベルにないのを「あんたのレベル」という言葉でごまかしてるｗ
おそらく答えとしては「push時に--forceをつけろ。」だろうけど
以下、ちゃんとした解説
------------------
どれをどこにpullしたのかよくわからんが、まず「みんなで共有しているブランチ」と
「自分専用のブランチ」と分けて考える。
「みんなで共有しているブランチ」の代表例はmasterだな。他に次バージョン用のブランチなどがある
「自分専用のブランチ」はトピックブランチと呼ばれたりする。
自分専用のブランチは、その名の通り自分専用なのだから勝手に更新されることとはない。
みんなで共有しているブランチは誰かが勝手に更新する。
みんなで共有しているブランチは、そのブランチに対して直接修正してはいけない。
必ず共有ブランチから自分専用のブランチを作って作業をする。終わったら共有ブランチにマージする。
自分専用のブランチは自分専用なのだから好きにrebaseしてよい
自分専用でも他の人が見ることはある。だけどそれは見てるだけなので何も問題ない
ここまでは前提知識として
続く
0720デフォルトの名無しさん
2015/06/22(月) 02:50:06.54ID:j9mWyPD+pullする必要があるのは共有ブランチの場合だけ。なぜなら自分専用であれば
自分しか更新しないから、サーバー側がローカルよりも新しくなることはなく
pullする必要がない。
そして共有ブランチであれば、そこを調節更新することはないのでpullが失敗することはない
失敗したら間違って共有ブランチをローカルで更新してしまったとうこと。
その場合は（他のブランチにリネームしたりしてバックアップを取ってから）
共有ブランチは適当に巻き戻したり消して取り直せばいい
じゃあ何故pushした時にpullしろと言われたのか？
それは単にサーバーにpushされているのと、
自分がpushした内容（の歴史）が食い違っていたからなだけ。
gitはブランチが共有ブランチなのか自分専用のブランチなのかの区別は
できないから無いから食い違いをサーバー側が更新されたからだと解釈した。
でもそれが自分専用のブランチであれば、
ローカルにあるブランチが正しいので単にgit push --forceをすれば良い。
自分専用のブランチなのだから、git push --forceしたとしても
誰にも迷惑はかからない。
0721デフォルトの名無しさん
2015/06/22(月) 03:00:25.50ID:j9mWyPD+理屈上は>>720に書いたとおりで間違いないのだけど、
人間はミスするもので、間違ってローカルでmasterを修正して
それをgit push --forceしてしまうなどということが起こりかねない。
中途半端にしか理解できてない人がmasterにpushできない？
あれぇ〜？ --forceしてみよう。とかやってめちゃくちゃにして、
その経験（？）を悪い方向に活かして、○○は禁止
（理由：なんでそうなるのか俺には理解できんから）とか
言い出してgitを使えない・不便な道具に、変えてしまう愚か者が少なからずいる。
だから早いうちにgithubやgitlabを取り入れた方がいい。
gitlab（無料だよ）だと、masterに対してのpush --forceを禁止して
ウェブ画面に限定出来たり（デフォルトでそうなってる）と便利。
「共有のブランチ」と「自分専用のブランチ」を明確に区別するために
プロジェクトのリポジトリから、自分専用のリポジトリへforkを行ってから開発するから
ブランチがたくさん出来て、どれがなんのブランチなのかわからなくなることもない。
0722デフォルトの名無しさん
2015/06/22(月) 04:12:25.25ID:6fsOI3Rmpush --forceの乱発で他人のコミットを上書きしまくってプロジェクトを混乱に陥れるのであった…
0723デフォルトの名無しさん
2015/06/22(月) 05:17:00.13ID:mEuvJOmbgit push --force 推奨
0724デフォルトの名無しさん
2015/06/22(月) 06:18:54.34ID:j9mWyPD+0725デフォルトの名無しさん
2015/06/22(月) 08:17:21.67ID:Jo3Uu3lv0726デフォルトの名無しさん
2015/06/22(月) 09:57:48.30ID:PyoyBJGz>なんだかよくわからないけどgit push --forceでいいのかぁ〜と理解し
これは別にID:j9mWyPD+悪く無いだろ……
0727デフォルトの名無しさん
2015/06/22(月) 10:01:38.28ID:PyoyBJGzどう丁寧に教えようがリスクは当然有ると考えるべき(戻せるだけマシ)
だったら丁寧に教えてあげた方が後から文句言われる筋合いを無くせるという利点も……
0728ID:j9mWyPD+
2015/06/22(月) 10:09:04.83ID:6W+IUVUvプロ（俺）の目の前で、アマチュアが初心者に
「お前にはまだわからんだろうがな〜」と
言い出したように感じたものでｗ
アマチュアが、pushした物の歴史改ざんしたらいけないんだぜーとか
push --forceはだめなんだぜーとか言ってるのを見るとねぇ（苦笑）
そういう書き込みには、決まってなぜだめなのかといった理由が書いていない。
自分がわかってないからさ。
理由を考えれば、どういう場合にはだめで、どういう場合ならいいかが
わかるはずなんだが、一部の人間は何も考えたくないからか、
状況など考えずに、良いか駄目かのわかりやすいルールを求める。
そういう人間にはならないようにしような。
0729デフォルトの名無しさん
2015/06/22(月) 10:16:31.40ID:nboh/a200730デフォルトの名無しさん
2015/06/22(月) 10:30:46.58ID:6W+IUVUvフェールセーフというのは間違って操作しても「安全」という意味だ。
英語：セーフ＝安全
お前が言うべきなのは、フールプルーフな。
英語：フール＝馬鹿
gitにおけるフールプルーフはreflogだろうな。
これによってコミットが消えることはない。
間違って操作してもgitなら複数の場所にコピーがあるから
これもフールプルーフといえよう。
push --forceしても別に壊れるわけじゃない。混乱が発生して困るだけだ。
もちろんそういう問題が発生するのは、みんなで共有しているブランチだけであって
だから自分専用であれば誰も困らないんだからやっていいという話をしてる。
>>729
お前は何がいいたいのだ？
0731デフォルトの名無しさん
2015/06/22(月) 10:52:29.70ID:kJni3XZO0732デフォルトの名無しさん
2015/06/22(月) 11:00:33.51ID:Jo3Uu3lv勝手にforkして作業してたら
主が勝手に（自由に）pushして
forkした側が混乱して困ってこれまた勝手にクレームを付ける
誰宛てのアンカも無いレスに対して >>730 がやってることはまさにそれ
0733デフォルトの名無しさん
2015/06/22(月) 12:16:35.13ID:a9m1vXpghttp://peace.2ch.net/test/read.cgi/tech/1433650988/
0734デフォルトの名無しさん
2015/06/22(月) 17:40:26.27ID:PyoyBJGz0735デフォルトの名無しさん
2015/06/22(月) 18:04:38.52ID:6W+IUVUv落ち着こうｗ
あんたが言っている問題（？）
それはフォークなど関係なく発生することだ。
複数人で開発したら、一人が開発中に
もう一人が修正した。という話をしているだけだな。
0736デフォルトの名無しさん
2015/06/22(月) 19:50:24.16ID:ScRlfOQU0737デフォルトの名無しさん
2015/06/22(月) 20:27:08.06ID:O6QpuzQlAがトピックブランチ作成
Aがトピックブランチ上でコミットXを作成してpush
Bがトピックブランチ作成
Bがトピックブランチ上でコミットYを作成してpush、トピックブランチ破棄
Aがトピックブランチ上でタイポ直したコミットX'をrebaseで作成してpush --force
コミットYは上書きされてしまうわけだが、これ誰も気がつかずコミットYがGCされちゃうことあるんだよ？
0738デフォルトの名無しさん
2015/06/22(月) 22:41:32.22ID:mEuvJOmbo されちゃう
0739デフォルトの名無しさん
2015/06/22(月) 22:47:27.01ID:O6QpuzQl0740デフォルトの名無しさん
2015/06/22(月) 23:36:10.08ID:a9m1vXpgAとBのトピックブランチが同じ名前ならBのpushのときに失敗するだろ。
その場合はトピックブランチを共有してるのだから、push -fしてはいけないのは当たり前
0741デフォルトの名無しさん
2015/06/23(火) 00:36:04.38ID:UdZmnE2/>>740の言うとおり。共有しているブランチは
push --forceしたらだめだと書いた。ちゃんと判断して使え。
ミスしたらという話をするならば
masterを消すことだって出来てしまう。
だからgitlabを使えと言ってるんだよ。gitはソースコードの管理をするためのもので
ユーザーの管理、つまり誰が何をやっていいかダメかっていうのは管理してない。
--forceが問題なのではなくて、gitだけでやろうとしているのが問題
ユーザーの管理がしたいのならGitサーバーを使う。それはGit Proにも書いている。
https://git-scm.com/book/ja/v1/Git-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC
俺のおすすめはgitlab。Git Pro 2nd Editionの方に翻訳されてるな。
https://git-scm.com/book/ja/v2/Git%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC-GitLab
フォークして自分のプロジェクトで作業するならば、
メインのプロジェクトには共有ブランチだけ、
自分のプロジェクトには自分専用のブランチだけになる。
共有ブランチはプロテクト等をかけることで、
push --forceできなくすることもできる。
0742デフォルトの名無しさん
2015/06/23(火) 00:45:05.79ID:4795aBmW他の奴の作業コピーから復元できるかもだし
0743デフォルトの名無しさん
2015/06/23(火) 01:19:15.14ID:UdZmnE2/本人が書いたコードは残ってるんだよね。
0744デフォルトの名無しさん
2015/06/23(火) 16:29:38.65ID:LQfp6JsA宵越しのコードは持たねぇのが粋ってもんよ
0745デフォルトの名無しさん
2015/06/23(火) 20:22:25.05ID:CqiNTuO00746デフォルトの名無しさん
2015/06/23(火) 20:57:22.50ID:Yra6/pdrてめえ、コミットする前にコード消しやがって、何が粋だよ
0747デフォルトの名無しさん
2015/06/23(火) 22:28:58.60ID:SktsG5/mいつでも逢えたらロマンチックじゃないじゃない。
0748デフォルトの名無しさん
2015/06/24(水) 08:57:50.31ID:NHniIMjV江戸っ子は気が短けーんでい
0749デフォルトの名無しさん
2015/06/24(水) 22:23:29.89ID:ix5XSndEテストしたりコミットしたりほどのもんじゃないんだよ。
オレなんか、急ぐときなんざ エディタで保存する前に
消しちまうんだ
0750デフォルトの名無しさん
2015/06/26(金) 11:47:16.43ID:Q1kb1EVfTotal 9 (delta 5), reused 0 (delta 0)
って表示されたんですが9と5ってなんですか？
0751デフォルトの名無しさん
2015/06/28(日) 11:33:24.51ID:5m9gZHLmある特定のファイルの実行属性だけ無視しない
という設定をしたいんだけど、どうすればいい！？
0752デフォルトの名無しさん
2015/06/28(日) 11:47:33.27ID:VLu09OArLinux使えば良い。
0753デフォルトの名無しさん
2015/06/28(日) 13:44:26.56ID:5m9gZHLmLinux使ってるんだけど、どうすればいい・・・
0754デフォルトの名無しさん
2015/06/28(日) 14:04:26.07ID:lxz6gjyn0755デフォルトの名無しさん
2015/06/28(日) 15:26:50.01ID:5m9gZHLmいちおうわかりやすく説明しなおすと、
chmodをすると、gitは属性の変更を検知するでしょ？
それを本当に実行するファイル以外では無視したいの。
たとえば、 bin というフォルダにあるファイルの
実行属性があやまって変更されたら検知してほしいけど
doc というフォルダのファイルをうっかり属性変更しても
そんなのは無視してほしいんですよ
0756デフォルトの名無しさん
2015/06/28(日) 15:36:00.06ID:YBvq0FDq確かにもうすこし具体的に何がしたいか書かないとレスつかないだろうね
0757デフォルトの名無しさん
2015/06/28(日) 16:49:31.94ID:uJqfu/82全部のファイルに実行権ついててうざっ…とはなるな
0758デフォルトの名無しさん
2015/06/28(日) 17:03:24.02ID:WJabjmO6cygwinなら/etc/fstabで/cygdriveをnoaclに設定しとけばその手の煩わしい手間の必要はたぶん無い
msysgitとかだと同じことできなかったりする？
0759デフォルトの名無しさん
2015/06/28(日) 18:27:03.56ID:uJqfu/82Windows->(Samba)->Linuxにコピーして
Linuxでgit addした時の話ね
msysgitなら実行権を無視するのでそういう事にはならないよ
0760デフォルトの名無しさん
2015/06/28(日) 18:39:52.16ID:lxz6gjyn0761デフォルトの名無しさん
2015/06/28(日) 20:07:20.93ID:WJabjmO6それはsamba側の設定でcreate maskを0644にしちゃえばいいと思うんけど、
そういうわけには行かない使い方をしてるのかな？
0762デフォルトの名無しさん
2015/06/28(日) 20:25:52.15ID:uJqfu/82自分配下のものならそれでいいんだけど、
個人用のLinux PCとか、IT管理部門が許可しなかったりと
なかなか統一できないのよね…。
質問の件は git config core.filemode false で
実行権限無効化するくらいしか思いつかないな
gitattributesでできるんかな？
0763デフォルトの名無しさん
2015/06/28(日) 20:28:07.89ID:5m9gZHLm実行権限無視の設定にしてる。
でもこれだと、ほんとに実行するファイルの実行権限が落ちていた時に
気付かないので、できればやめたい
0764750
2015/06/28(日) 20:31:54.95ID:/nFQf9C+0765デフォルトの名無しさん
2015/06/28(日) 20:44:04.23ID:WJabjmO6http://stackoverflow.com/questions/21476167/when-i-do-git-push-what-do-the-statistics-mean-total-delta-etc
0766デフォルトの名無しさん
2015/06/28(日) 22:55:49.53ID:im5DcXMUプリコミットフィルターでコミットを拒絶するか
ポストコミットフックで実行権を強制的に書き換えるか
やりかた？知らん。
0767デフォルトの名無しさん
2015/06/29(月) 16:18:10.01ID:rbxhDT3n背景色を変更したり文字の色を指定する方法をおしえてください
0768デフォルトの名無しさん
2015/06/29(月) 17:14:42.93ID:k+90EXgh0769デフォルトの名無しさん
2015/06/30(火) 09:22:56.54ID:TGfi4m1bコミットしたことを破棄したいんだけど
どうしたらいいの？
ファイルの内容は戻したくない
0770デフォルトの名無しさん
2015/06/30(火) 09:39:02.37ID:4wEdMli5git reset HEAD^
0771デフォルトの名無しさん
2015/07/04(土) 13:39:17.57ID:YKtPOMLDそして変更履歴を一覧として出力(差分のみ)して作業指示書のようにすることはできますか？
0772デフォルトの名無しさん
2015/07/06(月) 07:01:20.85ID:p0+3cdhD0773デフォルトの名無しさん
2015/07/06(月) 11:19:13.00ID:jgWjPX/O編集したのを元に戻すつもりで破棄を選んだら
ファイルを消されたよ
実行したgitコマンドのログも見れないし
0774デフォルトの名無しさん
2015/07/06(月) 12:24:05.59ID:IqUlle/j0775デフォルトの名無しさん
2015/07/07(火) 07:05:33.80ID:NpIL7uvL人間を機械のように扱わないとあかん案件か。
0776デフォルトの名無しさん
2015/07/07(火) 10:56:27.88ID:L2fl7GI9Excelでいつの間にか更新されてて、取り込まれてないよ！っつーのをなくしたいんですわ
0777デフォルトの名無しさん
2015/07/07(火) 23:01:07.32ID:JwFwNWWF0778デフォルトの名無しさん
2015/07/07(火) 23:25:04.32ID:y1gFbJO10779デフォルトの名無しさん
2015/07/08(水) 01:45:10.53ID:uot9w4rY0780デフォルトの名無しさん
2015/07/08(水) 02:11:28.13ID:uBhtmoLkバックエンドにGitを使ったWikiで何か良いものはないのかな？
0781デフォルトの名無しさん
2015/07/08(水) 04:28:24.61ID:L2Tv4EJxgitlab
0782デフォルトの名無しさん
2015/07/08(水) 19:28:18.03ID:ribTz8l0エクセルをgitで管理すると捗るよ
0783デフォルトの名無しさん
2015/07/08(水) 23:28:04.19ID:PLuP1x0a差分機能のないexcel自身を使ってなぜか差分表示を行ってしまう
wordファイルはword自身の機能を使って差分表示
SourceTreeはWinMargeの呼び出しが標準たな？
tortoiseGitには負けるけどそこそこ使える
コマンドラインではdocx2txtが定番なのかな？これってexcel対応してたっけ？
0784デフォルトの名無しさん
2015/07/10(金) 00:13:15.31ID:Ud/4MC5Kこれぞ開発者のツールって感じ
0785デフォルトの名無しさん
2015/07/10(金) 03:42:11.87ID:/JprfCCX> エクセルをgitで管理すると捗るよ
前にやってた（知らない所で勝手にやってた）ことあるけど
データ容量増えすぎでいらいらするようになったよｗ
差分で記録できないからね。
画像とか含まれていると、数MB単位で増え続ける。
0786デフォルトの名無しさん
2015/07/10(金) 04:02:17.76ID:27W+BsF0やらんでも予想出来るのが賢者
0787デフォルトの名無しさん
2015/07/10(金) 08:38:00.86ID:xDEEK6200788デフォルトの名無しさん
2015/07/10(金) 09:26:19.80ID:JycZhxcBそれなら通じる
0789デフォルトの名無しさん
2015/07/12(日) 14:24:46.34ID:9keGjwZfコミット時にはしないけど、git gcの時に似ているファイル同士は連結圧縮してくれる
0790デフォルトの名無しさん
2015/07/13(月) 17:46:21.87ID:t6CAZDWGどうしよう
0791デフォルトの名無しさん
2015/07/13(月) 17:49:20.78ID:t6CAZDWG不思議なこともあるもんだ。
0792デフォルトの名無しさん
2015/07/14(火) 01:33:04.33ID:vBESeRtHで、どういう運用すればいいのかよくわからん。
まず、バージョン1とかマイルストーンでブランチを切った方がいい？で、そこから機能でブランチを切ってく感じ？
0793デフォルトの名無しさん
2015/07/14(火) 06:39:52.42ID:lsljdDda0794デフォルトの名無しさん
2015/07/14(火) 10:23:57.14ID:pNaF7lhjまずブランチなんか無視して使い方を覚えるんだ
0795デフォルトの名無しさん
2015/07/14(火) 11:24:20.22ID:OwkWHpBsこのスレはgitであのコマンドってなに？とか
git周辺のソフトって何が有る？とか
そういうことを聞くスレだよ。
主に初心者向け
gitの運用の仕方はこっち
Gitをより良くするための運用ガイドライン作成スレ [転載禁止](c)2ch.net
http://peace.2ch.net/test/read.cgi/tech/1433650988/
0796デフォルトの名無しさん
2015/07/14(火) 12:53:22.36ID:G0PBqp91どう見ても初心者だろ
0797デフォルトの名無しさん
2015/07/14(火) 13:07:53.62ID:VxoBFrok運用のことを考え出したら初心者じゃない。
コマンドなんてあとから覚えりゃいいんだよ。
運用があって、それに必要なものを作ったのが
gitなんだから。
0798デフォルトの名無しさん
2015/07/14(火) 13:20:00.15ID:G0PBqp91でないと、話が通じない。
ある程度使って、具体的に困ったところが出てきたら、運用スレで聞けば良い。
ただしあっちは関係無い話に脱線しがちだから、良いとこ取りした方が良いよ。
0799デフォルトの名無しさん
2015/07/15(水) 23:09:43.18ID:a+rEGmf6なので、これから更新する内容は「○○機能を実装」ってことでそれをプロジェクトルートのテキストファイルにメモ書きしてました。
しかし、コミットするときに毎回メモを見るのを忘れてしまいます。
再帰にコミットログを書いとくとかなんかtodoみたいなコマンドってありませんか？
0800デフォルトの名無しさん
2015/07/15(水) 23:10:19.62ID:a+rEGmf6☓再帰にコミットログ
○先にコミットログ
0801デフォルトの名無しさん
2015/07/15(水) 23:21:39.17ID:YpeXwOwK> それをプロジェクトルートのテキストファイルにメモ書きしてました。
いますぐそのようなアホなことを辞めましょう。
0802デフォルトの名無しさん
2015/07/15(水) 23:22:13.29ID:VsrdjrWKあらかじめ用意しておくから忘れるんだ
0803デフォルトの名無しさん
2015/07/15(水) 23:44:52.69ID:DsRhlYqBよっぽどコミットを溜めるのか、
コミットのコメントが適当すぎるのか
もうバージョン管理以前の問題な気が
アナログだけど付箋にメモしてディスプレイに貼れば？
左がこれからやること、上部が今やってる事、右が終わった事、
いや右は要らんかな？
0804デフォルトの名無しさん
2015/07/16(木) 00:52:26.73ID:Ye9E1FJD自分が差分を見て理解できないコードをコミットしちゃダメだよ
0805デフォルトの名無しさん
2015/07/16(木) 02:04:46.85ID:C5QhjRoF0806デフォルトの名無しさん
2015/07/16(木) 04:35:55.01ID:MREKRM2C差分ってたまに直観的じゃない出力することが良くある
0807デフォルトの名無しさん
2015/07/16(木) 07:52:03.14ID:SnFgv9L80808デフォルトの名無しさん
2015/07/16(木) 08:04:35.28ID:SnFgv9L8githubとかRedmineとかticket/issue管理ツールと併用するのが一番だけど、1人で使うのだと構築するのが大変かもね。
メモをgit管理されていれば、メモの差分もgit diffで出るよね。なので、commitする前に必ずgit diffしていればメモを見るのを忘れることはないはず。
このやり方をする/しないにかかわらず、commitする前にgit diffをするのは大事だから習慣付けるべきだよ。
0809デフォルトの名無しさん
2015/07/16(木) 09:31:42.39ID:NYNU6iM60810デフォルトの名無しさん
2015/07/16(木) 12:26:35.31ID:WO54leEHコンパイル出来ないものをコミットするメリットは？
0811デフォルトの名無しさん
2015/07/16(木) 12:32:11.52ID:DSiPnBiQビルド管理の目的以外でバージョンコントロールしてはいけないという理由はない。
0812デフォルトの名無しさん
2015/07/16(木) 13:02:02.47ID:Q/SdAAm+ソフトウェアのバージョンを管理する以外につかっても
意味が無いということだ。
0813デフォルトの名無しさん
2015/07/16(木) 13:39:11.99ID:Ye9E1FJDそんなんじゃgitを使う意味が無い
0814デフォルトの名無しさん
2015/07/16(木) 14:56:22.79ID:SnFgv9L8Gitをより良くするための運用ガイドライン作成スレ [転載禁止]©2ch.net
http://peace.2ch.net/test/read.cgi/tech/1433650988/
0815デフォルトの名無しさん
2015/07/16(木) 15:16:59.28ID:FDPV8gUSある機能を実装するのに、差分の出し方としての段階があると思うけどそういう単位でやるの？
面倒じゃない？
0816デフォルトの名無しさん
2015/07/16(木) 15:29:22.25ID:cQ0wrBTO何をやってたか忘れない
別途メモ管理不要
revertできる
0817デフォルトの名無しさん
2015/07/16(木) 16:59:52.48ID:XEPlidkJ0818デフォルトの名無しさん
2015/07/16(木) 19:11:52.83ID:BQ1LfMZh> 先に再帰にコミットログを書いとく
どうしてもと言うなら
git commit --allow-empty -m "○○する予定"
touch a; git add a;
git commit --amend -m "○○してやったぜ"
0819デフォルトの名無しさん
2015/07/16(木) 19:13:56.91ID:sUV1QtUUコミットコメントの内容は、コーディングする前に決めておく。
つまり、これから何をプログラムするのかをまず決める。
その後、コメント通りにプラグラムできたら完了、コミットする。
下記のページの Write preemptive comments でも推賞されている。
https://arialdomartini.wordpress.com/2012/09/03/pre-emptive-commit-comments/
こうすれば、何で更新したのか、と悩むことはなくなる。
0820デフォルトの名無しさん
2015/07/16(木) 19:24:57.63ID:sUV1QtUU「○○機能を実装」というのがデカすぎるから、
メモを見なきゃ把握できなくなるんだよ。
で、メモを見るのを忘れて困ったことになる。
これを改善しないと、git に君が望む機能（ツール）があったとしても、
全く役に立たなくなる。
更新内容の粒度はもっともっと小さくしなきゃだめだ。
10分かそこらでプログラムできる程度の大きさにしてみな。
そうすれば、メモを見る必要すらなくなる。
0821デフォルトの名無しさん
2015/07/16(木) 20:38:56.88ID:IhY29Rvn1.あれやこれや編集して、時々変更が失なわれないようにファイルに保存
2.目的の変更が完了したところで、バックアップを作成しておく
VCSの時代の人
1. 以前と同じ
2. リポジトリにコミット
DVCSの時代の人
1.編集中の変更は基本自動保存。昔のファイル保存するような感覚でローカルリポジトリにコミット。
2.目的の変更が完了したところで、履歴をまとめてリモートリポジトリにプッシュ。
この運用方法のポイントは
ファイルは自動保存すること。
ローカルコミットにはまとまった意味など不要。
単に編集量や、経過時間のチェックポイントとしてコミットする。
このコミットコメントは、いい加減なメモや、あるいはコメントなしでもよい。
0822デフォルトの名無しさん
2015/07/17(金) 00:55:21.98ID:6Y2ZhytJファイルへの保存についてはまったく気にする必要がない
ソースの編集画面でHEAD内容と差分のある行の左端に常に印がつく
その印をクリックすると編集前の内容がポップアップで表示されて、行を編集前の状態に戻すとかこのポップアップから操作できる
ソースの編集画面からファイル単位のコミットとかできるし、--amend指定なんかもワンタッチ
HEADと差分あるファイルの一覧を表示してる窓からまとめて全部コミットとかもできる
これで行単位のコミットとかできたら完璧なんだけどそれは無いみたい
IDEを起動したままコマンドラインでgit add -pしてcommitしてもIDE側でほぼ完璧に追従してくれるのでまあなんとかなってる
0823デフォルトの名無しさん
2015/07/17(金) 04:20:41.08ID:OfiHmkDl差分を1つ1つみなきゃいけないゴミコード打つなよ
0824デフォルトの名無しさん
2015/07/17(金) 05:57:36.41ID:JRoNxi4Vor
パーツごとにリポジトリを分けて開発し、全てのパーツをサブモジュールとしてリポジトリ内に持つリポジトリで開発をする
どっちがいい
0825デフォルトの名無しさん
2015/07/17(金) 13:27:11.26ID:2DUlvwkLそんなことをやってるプロジェクトがありますか？って話だ。
0826デフォルトの名無しさん
2015/07/17(金) 20:25:59.09ID:zMQ3zlsL0827デフォルトの名無しさん
2015/07/17(金) 20:45:24.33ID:3x9AOrGucalendar.php
この２つのファイルを編集してまだaddをしてない状態なんですが
index.phpだけ編集しなかったことにして前回のコミットした時の内容のままにして、
calendar.phpだけコミットしたいんですが
どうやってindex.phpを更新してなかったことに出来ますか？
0828デフォルトの名無しさん
2015/07/17(金) 22:56:30.48ID:muZ+fGR1Indexの変更を手元に残しておきたければcalenderだけaddしてcommit
0829デフォルトの名無しさん
2015/07/18(土) 17:46:21.84ID:GcYCq0Aw今回チャット機能つきのアプリを制作しているのですが、ネイティブコード、サーバーサイド(php)、データベース(MySQL)を同時に管理するのは無理(もしくはかなり難しい)ですよね？
ネイティブコードとサーバーサイドはsource treeで管理するとして、
データベースの情報はコミット毎になんらかの方法で全テーブル情報をログ出力して、それをメモ代わりに置いておく…ということくらいしか思いつかないんですけど、どうでしょうか。
サーバー連携が必要なアプリって、みなさんどうやってGitで管理してるんでしょうか…
0830デフォルトの名無しさん
2015/07/18(土) 20:15:32.34ID:5OYZKZ4eコミットごとのテーブル情報って、何を管理しようとしてるんだか。
0831デフォルトの名無しさん
2015/07/18(土) 21:05:27.99ID:Xl228nsEスキーマ更新のSQLのみバージョン管理、
DBのバックアップは別にダンプしてアーカイブだろうな。
0832デフォルトの名無しさん
2015/07/19(日) 06:20:36.38ID:KkAp073Hデータの中身は管理対象外、データベースのバックアップの問題
ソフトが対応するデータベースのインターフェースと言う意味では
クエリー処理のプロシージャをDB側で組んでおくのが一番簡単だけど
どうしてもというならDBをゼロから構築するスクリプトなりバッチなりを書いて
それをGitで管理せておく
なんにしろデータベースとアクセスアプリは分離しておくのが大切
0833デフォルトの名無しさん
2015/07/19(日) 06:48:36.12ID:EU0ROg42git bisect で特定したければ
DB のバックアップも git 管理に入れる必要がある
0834デフォルトの名無しさん
2015/07/19(日) 07:28:28.07ID:KkAp073Hなるほどそういう考え方もあるか
0835デフォルトの名無しさん
2015/07/19(日) 09:06:48.58ID:wG1rbxp8bisectするにしても、バグを再現できる同じデータを使わなければ見つかるもんも見つからなくなると思うが。
0836デフォルトの名無しさん
2015/07/19(日) 09:12:53.24ID:I0iNBGYL0837デフォルトの名無しさん
2015/07/19(日) 12:04:49.68ID:Npxm1YBjそのためにコミットごとにデータもダンプするんじゃないのか？
再現ももちろんデータ書き換えでテスト実行
0838デフォルトの名無しさん
2015/07/19(日) 12:48:59.20ID:wG1rbxp8ためのものだと思っていたが。
テストデータもcommit時点のものを使うとすればその時点で既にbadだったということになるが、
そういう運用していたらbisect役に立たないんじゃね？
もちろん、bisectを使うつもりがなければビルドが通らないcommitするのも自由だと思うんで
それは別の話として。
0839デフォルトの名無しさん
2015/07/19(日) 12:59:24.27ID:3NrA4A7J> そのためにコミットごとにデータもダンプするんじゃないのか？
データは0の状態から、テストコードを書くんだよ。
テストコードの中でデータをリストアする
普通はフィクスチャっていうけどな。
当たり前だが実データまるまるダンプしてリストアなんてしない。
そんなことをやったら効率よくテストがかけない。
テスト全体が一つのデータに依存してしまうからね。
正しいテストとは、テスト対象（ファイル単位等）の
テストに必要なデータだけを入れてテストする。
だからテスト実行前にはデータを全て削除する。
データベース全体をダンプするなんてことはしない。
0840デフォルトの名無しさん
2015/07/19(日) 13:06:34.44ID:I0iNBGYL0841デフォルトの名無しさん
2015/07/19(日) 14:22:36.05ID:4suFbVBW0842デフォルトの名無しさん
2015/07/22(水) 10:52:31.65ID:phbUY/16git branch -b my_topic_branch
とした後でいくつかcommit後、「my_topic_branch作成直後〜さっきのcommitまで」をrebaseしたいとき、
git rebase -i ***
の***には、何と指定すればいいですか？
0843デフォルトの名無しさん
2015/07/22(水) 12:19:49.68ID:EiNSX7P40844デフォルトの名無しさん
2015/07/22(水) 13:10:35.36ID:phbUY/16$ git rebase -i
usage: git-rebase [-i] [options] [--] <upstream> [<branch>]
or: git-rebase [-i] (--continue | --abort | --skip)
ちなみに、今はcommitの数を数えて、HEAD~~~~~~とかしてます。
0845デフォルトの名無しさん
2015/07/22(水) 13:17:41.56ID:EiNSX7P40846デフォルトの名無しさん
2015/07/22(水) 13:54:39.00ID:phbUY/16おお、それでいけました。
ありがとう。
0847デフォルトの名無しさん
2015/07/22(水) 16:41:20.44ID:zBOMfGM9たぶん>>842が期待してる動作にはならんぞ
0848デフォルトの名無しさん
2015/07/22(水) 17:25:54.55ID:EiNSX7P4じゃあ、
git rebase -i `git merge-base develop HEAD`
ってのが、あったけど、素直にgit logして分岐点のcommit idを調べた方がはやいかもね。
別のブランチとの分岐点を起点に rebase -i する git エイリアス
http://qiita.com/uasi/items/70d4358c3c70c64f4261
0849デフォルトの名無しさん
2015/07/22(水) 18:24:49.47ID:phbUY/16なるほど、topic branchを複数作って作業するときまずいわけですね。
>>848
merge-baseのこと知らなかったので、もう少し調べてみます。
0850デフォルトの名無しさん
2015/07/27(月) 15:06:20.98ID:+ejnTFZv公開版のHTMLと公開を控えたHTMLがあって、これをgitで管理しようかと考えているのですが
公開版（Master）、確認用（Blanch）とした場合、Blanchは確認環境（HTTPアクセス）として機能させることはできるのでしょうか
0851デフォルトの名無しさん
2015/07/27(月) 15:24:49.11ID:aZg91AP9何をどうしたいのかもうちっと具体的に説明しないと
ツッコミようがないぞ？
0852デフォルトの名無しさん
2015/07/27(月) 15:45:36.34ID:biNPOZMHmasterブランチはどうやって確認環境として機能させるつもりなの？
0853デフォルトの名無しさん
2015/07/27(月) 15:47:39.18ID:+ejnTFZv説明不足ですみません！
たとえば
http://example.com/public/
この「public」内のコンテンツをgitで管理するとして
「public150727」という名前で「public」のブランチの更新版を作ったときに、ブランチ「public150727」の内容を確認環境としてブラウザで閲覧する方法はないものかと思いまして質問しました。
もっと砕いた言い方をしますと、gitと使えない環境の人にブランチ「public150727」の内容をブラウザで見てもらうことはできるのでしょうか。
0854デフォルトの名無しさん
2015/07/27(月) 15:50:15.95ID:+ejnTFZvそうですね、勝手な思い込みで公開版をマスターという前提で書いていました
特に公開中のバージョンがマスターであるこだわりはありません
失礼しました！
0855デフォルトの名無しさん
2015/07/27(月) 15:56:55.58ID:T5zoWN7L0856デフォルトの名無しさん
2015/07/27(月) 16:03:28.50ID:+ejnTFZv「public150727」をpushするということですね！
0857デフォルトの名無しさん
2015/07/27(月) 16:16:20.09ID:T5zoWN7L> 「public150727」をpushするということですね！
違う。そういうレイヤーの話じゃない。
「更新されたmasterブランチ」を「http://example.com/public/でアクセスできるようにする手順」だ。
0858デフォルトの名無しさん
2015/07/27(月) 16:23:58.54ID:ybeDhwD5ローカルサーバーで見るではだめなの？
りぽじとりを２つ分けて
それぞれ別々でステージングサーバーにでぷろい環境にするとか
0859デフォルトの名無しさん
2015/07/27(月) 16:50:45.48ID:+ejnTFZv理解が浅くてすみません
自分の知識ですとブランチごとにURLを割り当てるように読み取れるのですが、おそらくそういうお話ではなさそうなのでもっと勉強します！
>>858
やっぱりステージングサーバーで確認→本番環境にPUSHするのが安心ですね
皆さんありがとうございました！
0860デフォルトの名無しさん
2015/07/27(月) 16:52:44.86ID:T5zoWN7L0861デフォルトの名無しさん
2015/07/27(月) 17:03:36.01ID:+ejnTFZvよかったら>>857に書いていただいた手順の概要、もしくは参考のURLを教えていただけませんでしょうか
0862デフォルトの名無しさん
2015/07/27(月) 17:17:59.43ID:T5zoWN7L> よかったら>>857に書いていただいた手順
いやいや、それは俺らにはわからんよ。
その手順がわかりさえすれば、それと同じ手順でできるだろってこと。
ローカルのmasterを変更して、それをサーバにpushしたら、http://example.com/public/の内容が更新されるんだろ？
その仕組みは一体誰が構築したんだ？
0863デフォルトの名無しさん
2015/07/27(月) 17:18:41.69ID:aippD/Jn0864デフォルトの名無しさん
2015/07/27(月) 17:21:38.69ID:T5zoWN7Lうわ、その発想はなかったわ。
0865デフォルトの名無しさん
2015/07/27(月) 17:27:25.72ID:JJPg7kwZ来月からアルバイトなんですけど
clone,log,reflog,reset,branch,push checkout,commit,add,rm,mvはしってます
0866デフォルトの名無しさん
2015/07/27(月) 18:21:27.18ID:bJ8mI018git --help
0867デフォルトの名無しさん
2015/07/27(月) 21:16:18.54ID:v7fIr+ePPush to deploy の改善 2.3.0 で入ってるし .git を不可視にしとけば個人サイトくらいなら問題ないんじゃない？
0868デフォルトの名無しさん
2015/07/27(月) 22:46:51.50ID:aZg91AP9やつぱりまだわからないや
やりたいのは次のどっち？
1)
公開webページとかのhtmlその他諸々をgitで管理して
どっかのブランチにコミットすると自動的に公開webページになるようにしたい
さらに、公開前の事前確認用のページも用意したい
2)
なんかプログラム開発中のソースコードとかをgitで管理しておいて
みんなにレビューしてもらうためにwebページで閲覧できるようにしたい
0869デフォルトの名無しさん
2015/07/27(月) 22:48:07.44ID:u9s58J+yB:プッシュすればいいんですね
A:そういうレイヤーの問題じゃない
B:ではどういう手順で？
A:それはわからん、プッシュすればできるだろ
なんとなくこのスレの闇を垣間見たような気がするぜ
0870デフォルトの名無しさん
2015/07/27(月) 23:00:40.37ID:aZg91AP9俺だったらポストフックスクリプト書こうとするな
特定のブランチにコミットされたら対応するディレクトリにexportするようなやつ
gitに付属のフックスクリプトのサンプルに似たようなことやるのがあったと思うから調べてみ
手抜きバージョンなら
事前確認用のディレクトリにクローンしておいて
1分おきとかでpullかけるようにcronをセットしちゃう
こんなあたりでいかが？
0871デフォルトの名無しさん
2015/07/28(火) 13:25:37.42ID:3O5DcyiAあとは heroku なにかに push して確認すればいいんじゃない?
0872デフォルトの名無しさん
2015/07/28(火) 16:06:24.66ID:iS6umbvthttps://github.com/git/git/releases/tag/v2.4.7
https://github.com/git/git/releases/tag/v2.5.0
0873デフォルトの名無しさん
2015/07/28(火) 23:54:34.28ID:Z/s3EayVmv index.php sub/list.php
git add .
git commit -m "backup"
コミットした後に
rename index.php => sub/list.php (74%)
って表示されたんですがこれってindex.phpをgit mvで移動したのと同じことですか？
ato
74%って何を表してるんですか？
0874デフォルトの名無しさん
2015/07/29(水) 00:17:46.73ID:j0BJwxBzgitは移動を記録していないので、ファイルの一致率から移動を推測している。
0875デフォルトの名無しさん
2015/07/29(水) 09:32:05.34ID:bPiFDPfpよそ様の記事だがこんな感じだよ、hook script
< http://qiita.com/fnobi/items/98bd5d1c83c010842733 >
ぜひバルスしてくれたまえ
0876デフォルトの名無しさん
2015/07/29(水) 15:20:03.83ID:YsMaiv/S.gitignoreをどう書いたらいいかわからない
hoge/piyo ←無視しない
hoge/fuga/ ←無視する
hoge/foo/ ←無視する
hoge/bar ←無視する
たとえばこんな感じで、今は fuga,foo,bar を毎度列挙してるけど
今後フォルダがどんどこ増えるとするとちょっと嫌な気分になる
0877デフォルトの名無しさん
2015/07/29(水) 16:33:49.47ID:bPiFDPfp0878デフォルトの名無しさん
2015/07/29(水) 16:38:56.52ID:bPiFDPfpHow to rebuild from update hook
で検索してみ
kernel.orgでのドキュメント自動公開用のフックスクリプトが解説付きで買いてあるよ
あなたの場合はこれよりは簡単なはず
0879デフォルトの名無しさん
2015/07/29(水) 17:01:12.31ID:1zEW+9y+0880デフォルトの名無しさん
2015/07/29(水) 19:54:41.79ID:syqOZkA4「Git 2.5」がリリース
http://osdn.jp/magazine/15/07/30/044700
0881デフォルトの名無しさん
2015/07/30(木) 01:34:27.13ID:6b1uCZJv0882デフォルトの名無しさん
2015/07/31(金) 08:21:08.61ID:Uyj1+FiM編集してから1週間以上コミットせずに放置してあるファイルを
一覧で出力するようなスクリプトかツールあったら教えて下さい
雑多なスクリプトをgitで管理していて安定したらコミットしようかなーと思っていて
そのまま忘れて半年放置のようなファイルを検出したいのですが
0883デフォルトの名無しさん
2015/07/31(金) 08:36:32.35ID:709JoO300884デフォルトの名無しさん
2015/07/31(金) 09:00:48.29ID:u6UInjxJ> 雑多なスクリプトをgitで管理していて安定したらコミットしようかなーと思っていて
svnじゃないんだから、コミットしろよｗ
svnと違ってコミット＝サーバーに送信 ではない。
そこがsvnのだめなところであり、gitの優れたところなんだよね。
gitなら安定しなくてもコミットできる。
もしバグが見つかれば修正してrebaseしてまとめてしまえばいい。
だから意味がある単位でコミットしていって、
あとでまとめて安定したと思ったらサーバー（共有リポジトリ）にpushすればいい。
（work in progress的なやりかたなら、作りかけでもpushするのもあり）
そこからレビューをうけてOKになったらmasterにマージする。
「安定したらコミット」という発想をやめないといけない
その発想だとどうしても一回のマージのコードが多くなりすぎる。
小さく機能毎にコミット、gitではそれができる。
0885デフォルトの名無しさん
2015/07/31(金) 09:30:41.27ID:709JoO300886デフォルトの名無しさん
2015/07/31(金) 09:51:16.96ID:02j0y00V0887デフォルトの名無しさん
2015/07/31(金) 10:08:59.48ID:VSZ3MRZUそもそもスクリプトはコンパイラしないし
0888デフォルトの名無しさん
2015/07/31(金) 10:23:03.17ID:5Be3R/210889デフォルトの名無しさん
2015/07/31(金) 12:30:24.06ID:Q/Fv6mzV0890デフォルトの名無しさん
2015/07/31(金) 12:32:31.44ID:02j0y00V0891デフォルトの名無しさん
2015/07/31(金) 13:05:45.97ID:5Be3R/21ひょっとして、etckeeperが求めるものだったりする？
0892デフォルトの名無しさん
2015/07/31(金) 14:59:02.99ID:Pi4vilvwここの一番最後に
＞次からはGitを使ってGitそのものをアップデートできます：
って書いてあるんですが
これってmakeとかしなくてもgit pullしただけで新しいバージョンのGitが使えるようになるってことですか？
0893デフォルトの名無しさん
2015/07/31(金) 15:49:47.76ID:5Be3R/21ならない。
0894デフォルトの名無しさん
2015/07/31(金) 15:51:07.09ID:R58DjZqgインストールしたGitを使ってGitのソースをアップデートできるって意味だな
当然ソースをアップデートしたあとmakeは自分でやる
0895デフォルトの名無しさん
2015/08/01(土) 05:22:16.40ID:fbUoNrmE> コンパイルできないものもコミットしていいですか？
他人に渡さないならば何の問題もない。
svnとか使ってると、この自分だけが触れる
コミットという概念がわからんのだろうな。
0896デフォルトの名無しさん
2015/08/01(土) 05:24:32.97ID:fbUoNrmE> 毎朝コミットで良いよ
なんで1日の区切りでコミットしてるんだよｗ
作業の区切りでコミットしろよ。
大抵の場合、1日に数回コミットするもんだ
0897デフォルトの名無しさん
2015/08/01(土) 05:32:58.26ID:fbUoNrmE> 「意味がある単位」でコンパイルできないものという発想が良くわからない。
コードとして意味がある単位だと、コンパイルできないことはないはずだね。
だけど、作業として見るとコンパイルできないけどコミットすることはあり得る。
例えば何かの修正をする時、設計Aの方法で実装するか、
設計Bの方法で実装するか悩んでたとする。
悩んで出てもわからないのでざっくりと作って検証することにする。
設計Aである程度作って、設計Bである程度作る。
そういった場合に、コンパイルできない状態でコミットすることはあるだろう。
もちろんこれはマージするときには、コンパイルできる意味がある単位に直すのは
当たり前だけど、作業中であればコンパイルできない単位でコミットすることはある
これがsvnだと即サーバーにpushされて周りに迷惑をかけたりすることがあるけど、
gitだと自分だけのコミットにしておけばいいので、中途半端なコードでも
バンバンコミットできる。というかgitならコミットしていいんだよ。
そのためにあるのがrebaseという機能なんだから。
0898デフォルトの名無しさん
2015/08/01(土) 06:00:09.26ID:Fq14Oy7Qもうgitに追従する気は無いってことか
0899デフォルトの名無しさん
2015/08/01(土) 06:17:46.92ID:fbUoNrmE俺はwindowsだとcygwinを使ってるよ。
色々他を試したが結局cygwinに戻ってきた。
昔と違ってマシンスペックが上がったから
たいして重さを感じないしね。
zshも使えるし。
0900デフォルトの名無しさん
2015/08/01(土) 07:37:18.72ID:O3MfLUJMv2系はこれ？
使ったこと無いけど
http://git-for-windows.github.io/
0901デフォルトの名無しさん
2015/08/01(土) 11:19:27.66ID:BlX74pFFあるある
俺も「筋が悪そうだからこのブランチは放棄」ってコメント付けてコミットした事は何度かある
0902デフォルトの名無しさん
2015/08/01(土) 14:26:03.50ID:fbUoNrmEとある修正をしていて、コードを書いていると
うぉい、ここバグってるじゃねーか
（そのせいでとある修正がちゃんとできない）
一旦コミットしておいて、
先にバグの修正をコミットして、
んで戻ってくる。
こういった時に中途半端な状態でコミットする。
戻ったあとはバグ修正状態からの変更ににrebaseする。
このようにgitの素晴らしさっていうのは、
ファイルの管理やバックアップではなく、
実際の開発で起こることに対応するための機能なんだよ。
履歴管理ツールではなく、開発ツール。
そう認識しないといけない。
0903デフォルトの名無しさん
2015/08/01(土) 21:25:30.14ID:fuLtc72jrebaseしたくないので、同じようなことを
rebaseしないでやる方法も教えてください。
おねがいします。
0904デフォルトの名無しさん
2015/08/01(土) 21:30:36.62ID:cZ9y3hcR「rebaseしたくない」ではなく
「馬鹿だからrebaseを使える能力がない」の
間違いだろ？
「したくない」ではなく「できない」
自分に嘘をついてはいけない。
0905デフォルトの名無しさん
2015/08/01(土) 21:39:52.86ID:Co43fSsi0906デフォルトの名無しさん
2015/08/01(土) 22:52:16.85ID:cZ9y3hcR目的のために作られた専用のものがあるのであれば
それを使えばいい。
それが必要だから作られたわけなんだから。
0907デフォルトの名無しさん
2015/08/01(土) 23:12:53.23ID:h+APIw5aでもほぼrebase -iだな。
0908デフォルトの名無しさん
2015/08/01(土) 23:18:37.12ID:Co43fSsiそして、それがあるから使うというのは適切な使い方ではない。
それは道具に使われてると言うんだから。
0909デフォルトの名無しさん
2015/08/01(土) 23:31:46.83ID:fuLtc72jrebaseという思想が好きじゃないんです。
それはそれとして、rebaseを使わないと出来ないことなのですか？
0910デフォルトの名無しさん
2015/08/01(土) 23:49:08.71ID:RZc3oG0T0911デフォルトの名無しさん
2015/08/02(日) 00:01:19.35ID:ID0TD3H50912デフォルトの名無しさん
2015/08/02(日) 00:09:46.39ID:KQ3UQl73どこかの宗派の戒律を受け入れたほうが楽、と言うのはあるな
俺はgit-flow派
0913デフォルトの名無しさん
2015/08/02(日) 00:12:00.18ID:uoA7o0bf> それはそれとして、rebaseを使わないと出来ないことなのですか？
？
rebaseを使うとやりたい事が簡単にできるんだよ。
やりたい事＝思想。
rebaseを使わなくても、同じことをするのであれば
rebaseの思想は正しいということとなんだが。
0914デフォルトの名無しさん
2015/08/02(日) 00:15:40.65ID:gKbzhWvd0915デフォルトの名無しさん
2015/08/02(日) 00:37:19.06ID:eV4xuuQq-> rebase開始位置に指定したコミットは変らない -> HEADのファイルは変化しない
分岐した元ブランチとの関係をFF状態にするためのrebase
-> rebase開始位置に指定したコミットが別のコミットになる -> HEADのファイルが変化する
良く知らない人はrebaseっていうと後者しか思い浮かばなくて
mergeすればいいじゃんとか言い出す
0916デフォルトの名無しさん
2015/08/02(日) 07:51:47.64ID:zAkA6wkzrebaseの思想とかｗ馬鹿はこれだから怖い
0917デフォルトの名無しさん
2015/08/02(日) 08:42:49.05ID:gKbzhWvdrebase以外で目的を達成することができることがある != すべてrebase以外で実現できる
0918デフォルトの名無しさん
2015/08/02(日) 09:00:44.24ID:dTRZmQiN0919デフォルトの名無しさん
2015/08/02(日) 13:19:25.28ID:5pxTtzkh世間のレベルに合わせてるんだよ。
あと、rebaseは名前が嫌い。
0920デフォルトの名無しさん
2015/08/02(日) 13:30:22.74ID:RcysspGc0921デフォルトの名無しさん
2015/08/02(日) 20:18:22.98ID:HQ+xGyu0どうやればいいのか教えてください
0922デフォルトの名無しさん
2015/08/02(日) 21:02:00.58ID:j05l/s8s> rebaseでしかできないことがあるのは当たり前。
rebaseでしかできないことなんてない。
全ては効率の問題。
その他の方法でもやれるが、
効率が凄く悪くなる。
例えて言うのなら、東京から大阪まで徒歩でも行ける。
車でしか行けないわけじゃない。それと同じ。
ある目的のためにrebaseという手段が作られた。
rebaseは目的ではない。目的を最速で達成するための
手段なのだ。使わない理由がない。
0923デフォルトの名無しさん
2015/08/02(日) 22:07:56.09ID:zAkA6wkzrebaseしなければいけないこともない
ではなぜrebaseするのか？
これは哲学的であり、そしてかなり難しい問題のようにみえる
しかし、実は我々はその答を既に知っているのだ
その答とは
そこにrebaseがあるからだ
0924デフォルトの名無しさん
2015/08/02(日) 22:13:02.07ID:j05l/s8sLinusがね。必要だと思ったから作った。
0925デフォルトの名無しさん
2015/08/02(日) 22:51:23.25ID:sASJ2DPaきっとそうだろう
でも俺はLinusじゃない
0926デフォルトの名無しさん
2015/08/02(日) 22:54:55.58ID:I5g9+RU+0927デフォルトの名無しさん
2015/08/02(日) 23:04:48.44ID:sASJ2DPaつまりだ、Linusのために作られた道具を
俺ごときが使いこなせるわけがない
ということだ
0928デフォルトの名無しさん
2015/08/03(月) 08:13:34.83ID:6s/iApNK全く問題はない
0929デフォルトの名無しさん
2015/08/03(月) 17:13:09.03ID:CE59HNJ8> 一旦コミットしておいて、
> 先にバグの修正をコミットして、
> んで戻ってくる。
stashしろよ。
0930デフォルトの名無しさん
2015/08/03(月) 20:22:26.69ID:OzQ4PZKSやってるよ？
コミットしてないファイルがあるとrebaseできないからね。
stashしても作業中のファイルを一旦対比してから、
その後で修正してrebaseする。
0931デフォルトの名無しさん
2015/08/03(月) 20:35:53.78ID:nTSIXxVaコミット済みのコミットにマージするの？
0932デフォルトの名無しさん
2015/08/03(月) 20:40:24.64ID:6s/iApNK0933デフォルトの名無しさん
2015/08/03(月) 20:43:36.27ID:OzQ4PZKS不要でしょうなぁｗ
タイポしたことがない人、手を揚げて！
閻魔様の前に連れて行ってあげる♪
0934デフォルトの名無しさん
2015/08/03(月) 20:57:28.47ID:DLpcuCaGrebaseがあるから差分管理編集ツールとでも呼ぶべき別次元のツールになった
0935デフォルトの名無しさん
2015/08/03(月) 21:01:48.03ID:Po35HDPOまだコミットしないで様子を見よう。とかやってしまうんだよね。
そうすると小さくコミットすることが難しくなってしまう。
0936デフォルトの名無しさん
2015/08/03(月) 21:20:26.33ID:6s/iApNK0937デフォルトの名無しさん
2015/08/03(月) 23:17:22.87ID:nTU4lW67rebaseはブランチの分岐点を変更する機能
gitより前にclearcaseなどで実装されていてgit固有の機能という訳ではない
rebaseにコミットの編集・結合・取捨選択する機能を追加して
より柔軟にコミットを直せるようにしたのがgitかな
0938デフォルトの名無しさん
2015/08/04(火) 02:11:14.86ID:pFxIT8vhリリースしてないもののバグを
なんで痕跡残さないといけないんだ？
0939デフォルトの名無しさん
2015/08/04(火) 08:51:51.90ID:1pDlaOkO成果物の途中経過を次元の狭間に葬り去る古のno-commiterとの血で血を洗う闘争の幕開けであった
0940デフォルトの名無しさん
2015/08/04(火) 09:07:24.48ID:LaebqzUeリリースしてないコードも全部だ。
0941デフォルトの名無しさん
2015/08/04(火) 09:35:03.57ID:ioOBuo8Gあ、改竄派が勝てば、そもそも争いはなかった事になって、年代記には残らないね
え？言葉が悪い？
では修正的歴史観と呼び直しましょう。
0942デフォルトの名無しさん
2015/08/04(火) 10:08:20.01ID:rYHf65xq> >>929
> やってるよ？
は？stashせずにコミットしてんだろ？
0943デフォルトの名無しさん
2015/08/04(火) 14:23:44.57ID:jQzRldfCとりあえずバックアップ代わりのコミットと
コンパイル通ったコミットとガッツリテスト済みのコミットと
それぞれ記録したいけど、ログをみるとき
全部出てしまうのはうっとおしい
（ガッツリテストとおったログだけみたい）
0944デフォルトの名無しさん
2015/08/04(火) 14:36:08.82ID:rYHf65xqそれぞれ何かキーワードを決めて、ログ表示するときに絞り込めばいい。
0945デフォルトの名無しさん
2015/08/04(火) 14:52:01.94ID:wN0qaZCYそれぞれブランチをつくればいいと思う
0946デフォルトの名無しさん
2015/08/04(火) 15:01:54.07ID:KT0L8boWホテルとかで家に変えるときチェックアウトしますよね？
そうすると部屋空いてるから、だれでもチェックインできるようになるんですか？
0947デフォルトの名無しさん
2015/08/04(火) 15:56:53.06ID:jQzRldfC今はそうやってる
>>945
それ前やってたけど、今どのブランチにいるかうっかり忘れるんだよね
0948デフォルトの名無しさん
2015/08/04(火) 18:13:17.56ID:rYHf65xq> それ前やってたけど、今どのブランチにいるかうっかり忘れるんだよね
bashだったら、git-prompt.shを使うといい。
プロンプトを
[username@ dirname] (issue-2701-add-hoge-api *) $
みたいにできる。
ついでにgit-completion.bashもインストールすれば、gitコマンドやbranch名をTabで補完できるようになる。
0949デフォルトの名無しさん
2015/08/04(火) 20:39:05.58ID:LaebqzUe普通に日本語でコメント書けばいい。
> ログをみるとき全部出てしまうのはうっとおしい
ブランチに含まれるコミットが多すぎるってことさ。
いろんなプロジェクトのマージコミット見てみ。
マージコミットの内容＝ブランチの内容なわけだが、
ブランチに含まれるコミットは数個しか無い。
>>947
> それ前やってたけど、今どのブランチにいるかうっかり忘れるんだよね
>>948がいっている通り。
それはさすがにgitを使いこなせてない。
gitというかシェルに近い話だが。
初心者のうちは、なにか使いにくいと思ったら
自分の使い方が間違ってるのではないかって
考えることが重要だよ。
0950デフォルトの名無しさん
2015/08/05(水) 16:11:14.67ID:qTT2Q3HY0951デフォルトの名無しさん
2015/08/05(水) 22:03:19.51ID:Y8QWrwSI0952デフォルトの名無しさん
2015/08/06(木) 12:24:17.98ID:YnB06pEs0953デフォルトの名無しさん
2015/08/07(金) 21:38:28.11ID:VjeH+b7c代替GUIでお勧めはある？
0954デフォルトの名無しさん
2015/08/07(金) 21:50:49.99ID:TJyjY+1J皆さんはどのへんに不満があるのでしょう？
0955デフォルトの名無しさん
2015/08/07(金) 22:38:51.48ID:zZgheHLRコミットとブランチ編集はGUIでやってrebaseはCLIでやってる
0956デフォルトの名無しさん
2015/08/08(土) 02:18:48.55ID:hvTU1eUOとくに目立つのは
・日本語入力がたまにできなくなる
・日本語がたまに文字化けする
の2点かなぁ
0957デフォルトの名無しさん
2015/08/08(土) 19:03:43.84ID:eLygs58n0958デフォルトの名無しさん
2015/08/08(土) 21:12:25.04ID:hvTU1eUO0959デフォルトの名無しさん
2015/08/08(土) 21:21:49.39ID:vBlQRCao0960デフォルトの名無しさん
2015/08/08(土) 23:20:35.51ID:BQYw/0/m0961デフォルトの名無しさん
2015/08/08(土) 23:27:16.33ID:m5zrYZQl>>959
英語圏はとりあえず違うかな？
0962デフォルトの名無しさん
2015/08/08(土) 23:32:51.12ID:A+ZgS5tiASCIIがShiftJISのサブセットだと大体そんな感じかな？
有名な円化するくらいで
0963デフォルトの名無しさん
2015/08/08(土) 23:33:39.68ID:PKfIE09hｶｷﾞﾓ ｶｴｼﾀﾉ〜
∧_∧
(*ﾟー^)
／つ￥ つ
｜*/;≡|@＼
￣(/ Ｕ￣
￣￣￣￣￣￣￣￣￣￣
ﾁｬｰﾝｯｯ ｳｫｰｯ ｼｨｰｰｯ
`∧∧ ∧∧∧∧ ∧∧
( ) ) ) )
0964デフォルトの名無しさん
2015/08/09(日) 00:06:42.83ID:SZxZe4hfSJISなわけはないがフランスやロシアや中国の人のソースもたまに化けてるの見る
https://en.wikipedia.org/wiki/Windows_code_page
0965デフォルトの名無しさん
2015/08/09(日) 01:38:16.85ID:un4R4gw1MSのVisualStudio2015でシフトJISじゃコンパイル失敗するからなんか設定してねってあったぞ
WindowsでもソースコードのデフォルトはもうUTF-8なんだよ
0966デフォルトの名無しさん
2015/08/09(日) 16:53:09.64ID:zMNscprH0967デフォルトの名無しさん
2015/08/09(日) 17:04:53.01ID:un4R4gw1ぐぐるとC#の話が一番上にでてくるがなｗ
0968デフォルトの名無しさん
2015/08/09(日) 17:21:44.28ID:DsvXgH80いちいち変更しなくて済むようになったんならありがたいが。
0969デフォルトの名無しさん
2015/08/09(日) 17:25:29.84ID:doZuGkX/たぶん2010あたりから
0970デフォルトの名無しさん
2015/08/09(日) 17:43:56.94ID:zMNscprH0971デフォルトの名無しさん
2015/08/09(日) 17:48:54.67ID:TarQJqGzVisual Studio 2013 Community ではシフト JIS ですけど？
0972デフォルトの名無しさん
2015/08/09(日) 21:40:02.06ID:MwH/TAN+0973デフォルトの名無しさん
2015/08/10(月) 05:15:36.78ID:joKVIITR0974デフォルトの名無しさん
2015/08/10(月) 08:39:31.31ID:woEY2l+Mもうほとんどやる気ないでしょ
この部分だけでいいからソース開示して有志に改造させて欲しいわ
0975デフォルトの名無しさん
2015/08/10(月) 09:29:36.92ID:Y9npztmjだけど git for windows だったかなんかについてくる UTF-8 対応の cmd.exe っぽいのは結構使える
0976デフォルトの名無しさん
2015/08/10(月) 09:37:10.95ID:7mEm0oAX0977デフォルトの名無しさん
2015/08/10(月) 10:58:28.36ID:lE/gCziLGUIだけでは心もとないのもたしか
0978デフォルトの名無しさん
2015/08/10(月) 15:32:34.36ID:iHuYT/si自動化とか簡単だし、それをgitで管理できるから
0979デフォルトの名無しさん
2015/08/10(月) 17:41:57.41ID:24CTSkEb0980デフォルトの名無しさん
2015/08/10(月) 18:43:19.26ID:wnxGShdH0981デフォルトの名無しさん
2015/08/10(月) 20:12:09.12ID:Mkjl0645フックの名前を教えてください
0982デフォルトの名無しさん
2015/08/10(月) 20:12:45.22ID:Mkjl06450983デフォルトの名無しさん
2015/08/11(火) 06:26:57.50ID:/JNKK5gi新しい更新がマージされたのを契機に処理をしたいなら post-merge になりそうだけど、
リモートからコミットがfetchされてそれがマージされたのかどうかは自分で判断しないといけないんじゃないかな
レス数が950を超えています。1000を超えると書き込みができなくなります。