Git 18

2022/04/23(土) 03:25:45.27

ソースコード管理を行う分散型バージョン管理システム、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

2022/04/23(土) 08:13:23.56

おまえら最近 --rebase しましたか?

2022/04/23(土) 09:22:19.05

え、しないの？

2022/04/23(土) 09:52:06.94

フライドポテトやポテトチップを指でつまんで食べてたら
指がもう油で git git

2022/04/23(土) 10:18:44.85

>>4
結果にコミット

2022/04/23(土) 12:44:39.83

デブまっしぐら

2022/04/23(土) 14:43:52.42

あーめんど(amend)くさいからな、箸でつまむの

2022/04/23(土) 15:37:09.71

gitの使い方は分かったけど、何をコミットすればいいの

2022/04/23(土) 15:47:19.70

>>8
ソースコード

2022/04/23(土) 15:55:15.89

コミットってのはな、生半可な気持ちでできるもんじゃねぇんだよ
絶対に達成するという強い思いが必要なんだ

2022/04/23(土) 15:56:25.46

>>10
コミットの時点ではいくらでもやり直し可能

2022/04/23(土) 16:24:29.44

>>9
ハロワしか書いたことなんですが、そんなのもコミットしたほうがいいですか
ブラキリしたほうがいい？

2022/04/23(土) 17:02:57.94

>>10
グッと来たぜww

2022/04/23(土) 17:04:59.81

スクリプトからhttps urlをgit cloneしたいんだけど、この条件を満たせるパスワードの渡し方ってないのかな？

- 実行時にユーザー入力を求めない
- コマンドラインにパスワードが見えてしまわない
- ユーザー側の credential.helper 等の設定は変えない

2022/04/23(土) 17:28:11.65

>>12
コード変更して動作がおかしくなってしまっても簡単に元に戻せるからコミットしたほうがいい

2022/04/23(土) 23:26:04.71

>>14
expectとかパイプ使って渡したらどう。
スクリプトにもパスワードとか残したくないなら、
opensslでも使って一段階暗号化したら。

2022/04/23(土) 23:31:26.38

github使ってたらprivateでもmsには丸見えで、パクられる可能性ある？

2022/04/23(土) 23:44:14.33

パクられるかどうかはともかく、中身は見られると考えておくべき

2022/04/24(日) 00:26:48.98

企業が使いたがらないわけだ
うちの会社もシステム管理部がサービス提供してるからGitHubは使ったことないわ

2022/04/24(日) 00:55:07.22

>>17
Enterprise Server

2022/04/24(日) 03:12:40.44

>>19
>>12 でハロワしか書いたことないと言ってるけどなにコミットしてるの？

2022/04/24(日) 09:55:32.12

>>14
ありがとう。
やっぱりgit自体には機能はなくて外部でどうにかする形になっちゃうか。

2022/04/24(日) 12:12:10.16

>>22
環境変数あたりに設定できないのかと思って調べたら無くて、その代わりにGIT_ASKPASSという環境変数の存在を知って
これ使えば環境変数に設定した情報でログインできるんじゃなね？と思って調べたらこんなのが有った
https://stackoverflow.com/questions/68344358/git-askpass-with-user-and-password
ホントに使えるかどうかは試していない

2022/04/24(日) 12:12:59.03

スクリプトから動かすこと前提なのに、他のツールに依存するのが嫌なのかい？
bashなのかpsなのか分からないけど、問題はなんだろう。

2022/04/24(日) 12:28:59.01

>>23のシェルスクリプトの中から exec printf $PASSWORD とか exec echo $PASSWORD やるとコマンドラインにパスワード書くのと一緒かな？その辺も確認必要かも

2022/04/24(日) 12:40:22.27

rebaseしろとか言うガイジ会社たまにあるよなｗ
こんな機能そもそも要らないだろｗ
強制プッシュも気持ち悪い

2022/04/24(日) 13:03:46.08

rebase 無しで git 使うとか頭おかしい。
何のために git つかってるんだろう？

2022/04/24(日) 13:25:41.34

改竄するためではないのは確かだな

2022/04/24(日) 13:36:37.53

rebase -i
でsquashできるのは必要だろ

2022/04/24(日) 14:01:12.35

rebaseにもいろいろあるけど -i が有用なのは間違いない
ある程度神経質な人でもマメにコミットする習慣を促進してくれる
実際に rebase -i を使うかどうかは無関係に

2022/04/24(日) 14:05:13.87

コミットしておけばよかった、しなければよかった
これがなくなる
迷わずコミット等をすぐ実行すればいい
訂正したくなったらなんでも軌道修正できる
gitの中心的価値だと思う

2022/04/24(日) 14:27:53.64

>>23
これだ！ありがとう。
でもGIT_ASKPASSに設定できるのはファイルだけでコマンドラインはダメなのか。
windows/linux両対応させようとするとちょっと面倒だな。

>>25
sh組み込みコマンドのechoを使う分には大丈夫そう。
仮にもし見えていたとしても一瞬なので問題はなさそうです。

2022/04/24(日) 14:51:45.39

rebase まともに使いこなせない奴は git 使えるとは認めん。svn でも使ってろ。

2022/04/24(日) 15:52:21.96

>>32
用途によってはこの辺も注意する必要ありそう
https://qiita.com/magicant/items/5c8346ce4781f0fe7dce
＞ Git のコンフィグで credential.helper が設定されていると GIT_ASKPASS 環境変数よりもそちらが優先される。
ユーザに使わせるのなら、ユーザがグローバルにcredential.helperを設定している可能性があるから、リポジトリ単位でcredential.helperを無効にするとかの必要があるかも

2022/04/24(日) 16:13:17.46

>>34
credential.helperの設定がcacheの状態で試して問題なかったから、たぶんhelperの設定で
パスワードが要求されない場合はGIT_ASKPASSが使われないということじゃないかと思う。
とりあえずうちの使い方では問題なさそうだった。

2022/04/24(日) 18:06:18.83

mergeの代わりにrebaseするのは現実のワーキングツリーに存在したことのない状態のコミットを作り出すという点で最悪の詐称行為
push前に連続した自分のコミットをまとめる目的だけに使うならセーフ

2022/04/24(日) 18:23:59.78

>>36
push の前にも何も、共有リポジトリを rebase するやつなんていないよ。
rebase は個人の作業リポジトリ

2022/04/24(日) 18:30:19.12

>>37
リモートを取り込むときに可能ではあるけどするなと言っているんでしょう

2022/04/24(日) 18:32:15.63

pull --rebase もその意味では問題ないな

2022/04/24(日) 18:33:32.50

テストをする前か後か、公開する前か後かだけが重要
個人のローカルにおける正しき歴史的事実がどうだったかなんてどうでもいい

2022/04/24(日) 20:27:20.91

rebase使ってるバカ結構いるんだなｗ
mergeだけで事足りるやろｗ
ツリーを一直線にしたいとかバカみたいな理由で使う奴がいるから笑えるｗ

2022/04/24(日) 21:41:06.35

前も君みたいな発言しているやつ居たな
問い詰めるとリベースの使い方理解する前に適当に弄って
元に戻せなくなってたアホだった

2022/04/24(日) 22:19:43.05

普段からやってる作業手順
1) 個人リポジトリに作業ブランチを切って試行錯誤。がんがんコミットする。
2) 完成したら機能ブランチを切って rebase
差分を統合したり分割したり順番を入れ替えたりゴミ履歴を取り除いたりコミット・メッセージを分かりやすく直したりする。
後から履歴を確認した時に何のため差分か分かるようにするのが最重要。
3) 綺麗になった機能ブランチを公開(push)して他の人にも確認・テストしてもらう。
4) 問題無さそうなら機能ブランチを現在の master の先頭に rebase して最終テスト
5) 機能ブランチを master に fast forward でマージ。

4) の rebase は機能や履歴によっては特別な意図があって rebase せずに 3way-merge することもあるけどレアケース。
2) の rebase はほぼ必須。一発で完璧なコミット作れるような単純変更以外は常に必要。

2022/04/24(日) 22:22:11.60

個人リポジトリにブランチ切る理由ってなんなの？
その個人リポジトリでどんな失敗してもリモートにはなんの影響もなんだし
ブランチを切る理由がわからん

2022/04/24(日) 23:29:01.99

masterだけで作業するより便利だからじゃないかな

2022/04/25(月) 00:04:59.31

えっと rebase どころか branch 使えないやつが湧いてきた件について。
一つ教えてやる。 git はブランチ切って損することはない。何か始める場合は常にブランチ切れ。

2022/04/25(月) 00:52:07.65

masterブランチだけで仕事が済むのは幸せなことだよ
頭使わなくてもいい簡単なコードしか書く必要がないか、非効率にダラダラコード書いても怒られないか、もしくはすごく優秀で完璧なコードをサクッと仕上げられるとか

2022/04/25(月) 08:24:37.40

>>44
ローカルでブランチ切って少しずつコミットすれば、部分的に失敗しても成功した部分は救えるだろ。
実装中に他の実装・機能を試してみたくなっても、新しくブランチ切れば今までのコードの開発履歴を残しておけるだろ。

2022/04/26(火) 12:11:17.62

>>46
強いて言えばgot branchの結果がウザくなるから定期的に消すかcloneしなきゃならんことがデメリットかな

2022/04/26(火) 12:13:42.26

I got you

2022/04/26(火) 14:17:38.70

ブランチむっちゃ作る
コミット1つ作るたびにブランチ1つ作る勢い

2022/04/26(火) 15:22:50.57

>>49
clone するのは知らないけど、名前の付け方を工夫することで branch がたくさんになっても --sort とか <pattern> match (複雑なら grep でも) とかで何とかなるよ。
正しい名前になるように頻繁に名前変えてる。作業ブランチだと名前に日付入れたりもする。

2022/04/26(火) 20:32:55.60

>>48
それってソフトの設計の仕方間違えてない？
部分的な失敗が全体に影響を及ぼすなんてスパゲッティかよ