Git 18
■ このスレッドは過去ログ倉庫に格納されています
ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。
Git - Fast Version Control System
http://git-scm.com/
◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/
◆前スレ
Git 16©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1502726047/
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured フライドポテトやポテトチップを指でつまんで食べてたら
指がもう油で git git あーめんど(amend)くさいからな、箸でつまむの gitの使い方は分かったけど、何をコミットすればいいの コミットってのはな、生半可な気持ちでできるもんじゃねぇんだよ
絶対に達成するという強い思いが必要なんだ >>10
コミットの時点ではいくらでもやり直し可能 >>9
ハロワしか書いたことなんですが、そんなのもコミットしたほうがいいですか
ブラキリしたほうがいい？ スクリプトからhttps urlをgit cloneしたいんだけど、この条件を満たせるパスワードの渡し方ってないのかな？
- 実行時にユーザー入力を求めない
- コマンドラインにパスワードが見えてしまわない
- ユーザー側の credential.helper 等の設定は変えない >>12
コード変更して動作がおかしくなってしまっても簡単に元に戻せるからコミットしたほうがいい >>14
expectとかパイプ使って渡したらどう。
スクリプトにもパスワードとか残したくないなら、
opensslでも使って一段階暗号化したら。 github使ってたらprivateでもmsには丸見えで、パクられる可能性ある？ パクられるかどうかはともかく、中身は見られると考えておくべき 企業が使いたがらないわけだ
うちの会社もシステム管理部がサービス提供してるからGitHubは使ったことないわ >>19
>>12 でハロワしか書いたことないと言ってるけどなにコミットしてるの？ >>14
ありがとう。
やっぱりgit自体には機能はなくて外部でどうにかする形になっちゃうか。 >>22
環境変数あたりに設定できないのかと思って調べたら無くて、その代わりにGIT_ASKPASSという環境変数の存在を知って
これ使えば環境変数に設定した情報でログインできるんじゃなね？と思って調べたらこんなのが有った
https://stackoverflow.com/questions/68344358/git-askpass-with-user-and-password
ホントに使えるかどうかは試していない スクリプトから動かすこと前提なのに、他のツールに依存するのが嫌なのかい？
bashなのかpsなのか分からないけど、問題はなんだろう。 >>23のシェルスクリプトの中から exec printf $PASSWORD とか exec echo $PASSWORD やるとコマンドラインにパスワード書くのと一緒かな？その辺も確認必要かも rebaseしろとか言うガイジ会社たまにあるよなｗ
こんな機能そもそも要らないだろｗ
強制プッシュも気持ち悪い rebase 無しで git 使うとか頭おかしい。
何のために git つかってるんだろう？ rebase -i
でsquashできるのは必要だろ rebaseにもいろいろあるけど -i が有用なのは間違いない
ある程度神経質な人でもマメにコミットする習慣を促進してくれる
実際に rebase -i を使うかどうかは無関係に コミットしておけばよかった、しなければよかった
これがなくなる
迷わずコミット等をすぐ実行すればいい
訂正したくなったらなんでも軌道修正できる
gitの中心的価値だと思う >>23
これだ！ありがとう。
でもGIT_ASKPASSに設定できるのはファイルだけでコマンドラインはダメなのか。
windows/linux両対応させようとするとちょっと面倒だな。
>>25
sh組み込みコマンドのechoを使う分には大丈夫そう。
仮にもし見えていたとしても一瞬なので問題はなさそうです。 rebase まともに使いこなせない奴は git 使えるとは認めん。svn でも使ってろ。 >>32
用途によってはこの辺も注意する必要ありそう
https://qiita.com/magicant/items/5c8346ce4781f0fe7dce
＞ Git のコンフィグで credential.helper が設定されていると GIT_ASKPASS 環境変数よりもそちらが優先される。
ユーザに使わせるのなら、ユーザがグローバルにcredential.helperを設定している可能性があるから、リポジトリ単位でcredential.helperを無効にするとかの必要があるかも >>34
credential.helperの設定がcacheの状態で試して問題なかったから、たぶんhelperの設定で
パスワードが要求されない場合はGIT_ASKPASSが使われないということじゃないかと思う。
とりあえずうちの使い方では問題なさそうだった。 mergeの代わりにrebaseするのは現実のワーキングツリーに存在したことのない状態のコミットを作り出すという点で最悪の詐称行為
push前に連続した自分のコミットをまとめる目的だけに使うならセーフ >>36
push の前にも何も、共有リポジトリを rebase するやつなんていないよ。
rebase は個人の作業リポジトリ >>37
リモートを取り込むときに可能ではあるけどするなと言っているんでしょう pull --rebase もその意味では問題ないな テストをする前か後か、公開する前か後かだけが重要
個人のローカルにおける正しき歴史的事実がどうだったかなんてどうでもいい rebase使ってるバカ結構いるんだなｗ
mergeだけで事足りるやろｗ
ツリーを一直線にしたいとかバカみたいな理由で使う奴がいるから笑えるｗ 前も君みたいな発言しているやつ居たな
問い詰めるとリベースの使い方理解する前に適当に弄って
元に戻せなくなってたアホだった 普段からやってる作業手順
1) 個人リポジトリに作業ブランチを切って試行錯誤。がんがんコミットする。
2) 完成したら機能ブランチを切って rebase
差分を統合したり分割したり順番を入れ替えたりゴミ履歴を取り除いたりコミット・メッセージを分かりやすく直したりする。
後から履歴を確認した時に何のため差分か分かるようにするのが最重要。
3) 綺麗になった機能ブランチを公開(push)して他の人にも確認・テストしてもらう。
4) 問題無さそうなら機能ブランチを現在の master の先頭に rebase して最終テスト
5) 機能ブランチを master に fast forward でマージ。
4) の rebase は機能や履歴によっては特別な意図があって rebase せずに 3way-merge することもあるけどレアケース。
2) の rebase はほぼ必須。一発で完璧なコミット作れるような単純変更以外は常に必要。 個人リポジトリにブランチ切る理由ってなんなの？
その個人リポジトリでどんな失敗してもリモートにはなんの影響もなんだし
ブランチを切る理由がわからん masterだけで作業するより便利だからじゃないかな えっと rebase どころか branch 使えないやつが湧いてきた件について。
一つ教えてやる。 git はブランチ切って損することはない。何か始める場合は常にブランチ切れ。 masterブランチだけで仕事が済むのは幸せなことだよ
頭使わなくてもいい簡単なコードしか書く必要がないか、非効率にダラダラコード書いても怒られないか、もしくはすごく優秀で完璧なコードをサクッと仕上げられるとか >>44
ローカルでブランチ切って少しずつコミットすれば、部分的に失敗しても成功した部分は救えるだろ。
実装中に他の実装・機能を試してみたくなっても、新しくブランチ切れば今までのコードの開発履歴を残しておけるだろ。 >>46
強いて言えばgot branchの結果がウザくなるから定期的に消すかcloneしなきゃならんことがデメリットかな ブランチむっちゃ作る
コミット1つ作るたびにブランチ1つ作る勢い >>49
clone するのは知らないけど、名前の付け方を工夫することで branch がたくさんになっても --sort とか <pattern> match (複雑なら grep でも) とかで何とかなるよ。
正しい名前になるように頻繁に名前変えてる。作業ブランチだと名前に日付入れたりもする。 >>48
それってソフトの設計の仕方間違えてない？
部分的な失敗が全体に影響を及ぼすなんてスパゲッティかよ >>53
言っている意味がわからない。
お前は複数の機能を実装するとき、機能ごとに分割して開発しないのかね？
あるいは開発途中にデバッグせざるを得なくなったとき、開発を保留してデバックしないのか？
複数の機能をごちゃごちゃに開発するほうがよほどスパゲティだろ。 今時納品先にsvnを指定されてめんどくせーって思ってたけどgit-svn使ってみたら便利だったわ
ローカルではgit、push先はsvnで快適に作業できるね >>54の理屈はもっともだけど、普通はそもそも複数の機能をローカルだけで一気に開発したりしないよ
それぞれブランチに分割できるんだったらその単位でpull requestを出して共有ブランチにマージしたらいい
そもそも長期間の巨大な変更をしないなら、一時的に開発途中でデバッグせざるを得ないようなケースはstashで十分 >それぞれブランチに分割できるんだったらその単位でpull requestを出して共有ブランチにマージしたらいい
仮にそれでできるとしても、人によってbranchの方が便利だと思うならそれを否定する理由もない。 >>55
dcommitするとツリー新しく作られるのがなー >>58
さっきdcommitしたけど新しいツリーできてないよ 「運用ルールとかどうでもいいから好きにやればいい 最後に動けば良い」
という意思を感じる >>56
pull request依存か。何らかのツールやホスティングサービスに頼る前提？
>そもそも長期間の巨大な変更をしないなら、一時的に開発途中でデバッグせざるを得ないようなケースはstashで十分
開発途中に一切コミットしないとか信じられん……
コミットに対する考えにマリアナ海溝よりも深い溝があるみたいだ。 >>55
gitのほうが面倒だろ
remoteが更新されたのが分からないし
１秒おきにfetch,diffするスクリプトを動かして、更新されたら関係者全員にラインしてるわ >>62
>>12でハロワしか書いたことないと言ってるけど、そんなレベルで更新が気になるの？ branch は機能ごとに切るもののと思い込んでるやつがいるな。
ローカルの branch は作業ごとに切るものだよ。
同じ機能でも複数の実装方法がある時に両方作って性能とかを比べてみたいとかあるだろ。
複数の作業が並行して走ることなんて普通だし、思いつきで試してみたくなることもある。
コミットの整理する時に整理前の試行錯誤とかを別に残しておくとかも普通の使い方。 >>62
1秒おきに更新が気になるとか、病院に行った方がいい
gitの方がはるかに便利だよ
>>64みたいな使い方はsvnでは出来ない >>64
思いつきで試してみたくなることなんてないよ
実際には設計が終わった時点でJOBは完了だろ
コーディングは設計とおりに行えば、いいだけだからコーダーは全く頭使わないのが普通 >>66
お前VSCodeスレでも同じこと書いてるだろ
最近TortoiseSVNをTortoiseGitに変えたメモ帳コーダーさん？ >>62
そういう用途にはhook pre-commitとか使わねえ？1秒おきとかCO2を増やした犯罪に近いな またこいつだったのか
こいつの言動には一貫して理解力の低さを感じる
svnも人の更新が勝手にローカルに降りてくるわけじゃないのにまだ分かってないのか
svnを使っていたときに更新コマンドを実行していたのと同じ契機でpullすればいい
svnはログ見たら最新分かるもん！だから最新常に見えてるってことでしょ？って感覚なんだろうが、それと同じ使い勝手がほしいならエイリアスなりショートカットなりで、ログを見る前にfetchする作業フローにすればいい お前の理解力の無さは神がかってんなー
その「更新コマンド」とやらを発行するのがいつかって話し
もちろん発行すれば、更新されているかどうかは分かる
svnの場合にはアイコンが変化するから、そのときが発行するタイミングだろ
gitは何時発行すればいいんだよ、
今ですか？ｗ アイコンが変化するｗｗｗ
一生 svn 使ってろ。お前には git はもったいない。 仕事で使ってない人はいいな
勝手に止めれるんだからなｗ 自分が今確認した範囲ではクラウド版のGitHubでもオンプレ版のGitLabでもメールやWebhooksでリポジトリの変更通知設定できるぞ まじめな話、新しい技術が理解できないんなら、それがお前の限界なので仕事辞めればいいと思うよ。そうすればお前の嫌いな git 使う必要はなくなる。
お前の同僚もみんな辞めて欲しいと思ってるよ。 アイコンが変化するってアイコンオーバーレイ機能の話でしょ？TortoiseGitでも同じ機能あった気がするけど Tortoiseのアイコン変化は他人が書き換えたことで起こるのではなく自分の書き換えで起こる
この違いすら説明しても理解しようとしない
度し難い >>75
ハロワ通いなんじゃないの？就職できたの？ >>59
あれ？まじか。
おれの環境の問題だったのか
毎度masterブランチ張り替えててダルいんだが。
dcommitするとremotes/git-svnっていうリモートブランチが、同じコミット内容で作られ直されるんだよ。
コミットメッセージが置き換えられて、svnの何番のリビジョンとして作ったっていうリンク(gitkでクリックするとhtmlブラウザが開く)が先頭につく。
なんか設定変えたりしてる？
おれはデフォルト設定のままで使ってて、
気になる点といえば、trunkレイアウトじゃないことだけだな。
ちなみにsvnでcommit(=push)しても作られ直されることはない。 そろそろ新しいソース管理のデファクトが出ないのだろうか
gitで十分だけど >>83
バイナリ差分に対応したのは欲しいね。git強化で十分だけど。 今初めてgitを使った共同開発してる。チームメンバーもあまり詳しい人いなくてみんなで手探り手探り
便利ではあるんだけど例えばこっちの環境では動くのにあっちでクローンしてきたら動かねぇぞとか結構細かいトラブルが頻発する
gitのベテランだとやっぱこういうトラブルって起きないもの？ばっちり運用体制整えればトラブルってなくなるのかな なにがどう動かないのか書いてないからさっぱり分からん 足りないのかクローン出来てないのか環境違うのか全くわからんね エスパーしてみる
Git固有の話ではなくVCSはおろか集団開発のノウハウすら怪しい状況なのかも
ignoreの使い方を理解してないから個人のローカルリソースへのフルパスがリポジトリに入ってるとか そういうトラブルを防ぐために運用体制を整えるわけで gitに限らず開発したプロジェクト一式が他の人の開発PCでもビルドできることぐらいは確認するよな？
ソース管理に不要なファイル(下のURL)に依存してたりするとそれも事故の原因だったりする
https://github.com/github/gitignore/blob/main/VisualStudio.gitignore >gitに限らず開発したプロジェクト一式が他の人の開発PCでもビルドできることぐらいは確認するよな？
と
>ソース管理に不要なファイル(下のURL)に依存してたりするとそれも事故の原因だったりする
>https://github.com/github/gitignore/blob/main/VisualStudio.gitignore
の関係性がよくわからんのだが
ビルドに必要なものはバージョン管理下におけっていうこと？ 中間生成物はリポジトリに置かずにignoreしろってことでしょ
そういえば初心者スレってないんだな
悩む初心者は結構いそうなもんだけど本でも読んでるんだろうか git使ってないとしてもソースコードを他人に渡したり納品したりするときにどうしてんのか考えて見ろってことよ ビルドに必要なものとReadmeとかの説明書は原則バージョン管理下置くことになる。
許される例外は社内で共通認識になってるライブラリぐらい
>>97
バージョン管理に必要なファイルは把握してるか？
ここに書いてるファイルはいらんのでバージョン管理から外すことになる
https://github.com/github/gitignore/blob/main/VisualStudio.gitignore
誰かが x64/Debug に必要なファイルを混ぜてないか？という話 ■ このスレッドは過去ログ倉庫に格納されています
