105(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 2514-H0Ic) [sage] 2022/11/12(土) 09:30:46.94 ID:Cj/ueztB0(1/9) AAS
>>98
> Gitはパッチ適用ツールであって、本当に、パッチ書く側のサポートが全くない。
パッチ適用ツールはpatchコマンドっていうんだよ
gitはそれ以上のサポートがたくさんある
これ以上何がほしいいっていうんだよｗ

106(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 2514-H0Ic) [sage] 2022/11/12(土) 09:31:53.24 ID:Cj/ueztB0(2/9) AAS
>>103
> 俺だったら、branchなんて、各ディレクトリにそのままマッピングする。
同じ名前のブランチが複数あることを想定してないね
ちょっと失格かな。

119(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 4bbb-tcgO) [sage] 2022/11/12(土) 11:59:07.72 ID:zxvXZjfz0(3/14) AAS
>>111
アホでやんの。マニュアル斜め読みしただけで実際に使用してないので本質が見えてないな
rebase する前に新しいブランチ切ってやれば
rebase前とrebase後の両方残せるという基礎の基礎すら理解できてないのか
普通はそうやって使うんだよ。マージも一緒。
ブランチが軽量で好きなだけ切れるので情報残したい数だけブランチを切ればいいだけだよ
rebase --keep-base みたいな使い方もあるけど基本が理解できてないやつは混乱するだけだろうな

124(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 4bbb-tcgO) [sage] 2022/11/12(土) 12:15:51.67 ID:zxvXZjfz0(5/14) AAS
>>122
必要なものには後で探せるように名前をつけておく。
名前のないものはいらないものなので掃除の時に捨てる。
基本中の基本すら理解できないの？

477(1): デフォルトの名無しさん (ﾜｯﾁｮｲ e9e6-+ld4) [sage] 2023/03/31(金) 09:11:50.51 ID:2bhkq+Nl0(1/3) AAS
>>475-476
一つの機能追加やバグ修正を、複数人で対応するようなケースなんですが、
こういう場合も一人一人ブランチを切って作業するものなんですか？
そうなると、ブランチでフェッチやプルが必要なケースってなくなってしまいそうですが。

515(8): デフォルトの名無しさん (ﾜｯﾁｮｲ 1610-Z+mA) [sage] 2023/05/07(日) 02:53:34.47 ID:9zTyX7Ss0(1/2) AAS
2点質問があります。もし詳しい人がいましたらご教授いただけると幸いです。

【自己紹介・置かれている状況】
私はGitが全くわかっていない人間です。業務もITとは無関係です。
私の部署はワードやエクセルで書類を作成したり、電話対応を行うのが主な業務です。
pythonやphpなど、プログラミング言語を使った業務は皆無です（エクセルで若干関数を扱う程度）。
現在、別部署やコンサル会社から「git使いましょう」とアドバイスを受けている状況です。

【質問】
1）エクセルやワードが使えるだけの人（高齢者や短時間勤務の主婦もいます）でもGitは扱えますでしょうか？
2）PCやタブレットが50台くらいあるのですが、環境設定は大変でしょうか？作業者は私になるそうです。

【余談】
「サル先生のGit入門」や「Gitの良さが分からない？ ちょっとそこに座れ」という記事は読みました。
専門用語が多く、理解できていません...

よろしくお願いいたします。

618(2): デフォルトの名無しさん (ﾜｯﾁｮｲ ad5f-ZZXD) [sage] 2023/06/24(土) 14:16:38.34 ID:Q2+vfe6G0(1) AAS
>>587
ありがとう。最後のorigin省略するなっていうのは、originを描き損ねるとローカルリポジトリの該当ブランチからマージされてしまうことになるから ということだよね？

checkoutは必要ないとのことだけど、
現在masterブランチにcheckoutしている場合、
git pull origin A
だと、ワーキングツリーには変化なし。
もちろんmasterブランチの中身(ソースコードなど)にも変化なし …であってる？

718(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 7f7b-gGH9) [sage] 2023/07/03(月) 22:14:54.54 ID:FSxNRnfK0(2/2) AAS
>>711
それなら「糞コードでも受け入れるのがバザール戦略だ」と開き直るべきで、発狂してるのは矛盾してるだろ。
ただ>>39なら、「(表面的であれ)動く限りコードの質は問わない」でもないんだろ。

>>716
それを言ってるんだけどね。
複数回reviewで落とすのが見えてたら、最初から「こうしてくれ」と明確に指示しておくべきだし、
そうしてないなら「先に言えよ糞が」とキレられて当然だろ。
お前らのエアプ感が酷いが、仮にエアプであったとしても、この辺は分かると思うのだけど。
後輩や部下を虐めるのが仕事ではないし。

reviewで落とせば改善する、という感覚がおかしい。落としただけでは何も改善しない。
改善させる為には、どこをどう変更しろ、その理由は云々、と説明する必要があって、
なら最初から説明しとけば一発目のreviewで通るし一番早い。
これが理解出来てないお前らの話は、まるで現実感がないんだよ。

だから複数のreviewが、或いはreviewが必要なこと自体がマネジメント不足とも言えて、
相手の技量を知ってる上で(用意周到に)振ってるのだからそいつが全力出してればおｋ、
reviewなんて仕事を振る段階で全部終了してる、というのが究極のマネジメントだ、とも言えるわけ。
> 実際には担当がガシガシ変更して、そのままリリースされてることなんてザラ。 (>>697)
ってのが果たしてそうか？はあるにしても、全くナンセンスというわけでもない。
少なくとも、難易度が高い仕事を技量の高い奴に振る程度の事はどこでもやってるし、
これが正しく嵌ればこうなるし。

そして実際reviewを機能させるのは難しい。
現実的にはGitのように回覧しただけで出来てるつもりになってる馬鹿が大半だと思うよ。
全員の技量が揃っていれば機能するが、そんな職場は基本的にないし。
ただOSSの場合は上記の究極のマネジメントは出来ないので、reviewでrejectを使うしかないのも事実。

743(2): デフォルトの名無しさん (ﾜｯﾁｮｲ ab7b-SLZP) [sage] 2023/08/17(木) 08:31:55.84 ID:zl6mWfwu0(1/4) AAS
>>742
gitを使えば全てが解決して幸せになれると信じるgit統一教信者乙

そりゃお前がsvnのブランチモデルを活用出来ないだけ
git使うだけでリリースが1ヶ月早められるのなら、みんなgit使ってるよ
連中にとってメリットがないからgitを使わないだけという事実をきちんと受け止めた方がいい

そもそも俺はブランチで効率が上がるのはマネジメント不足なだけで本末転倒だとも思うが
(巻き戻し《≒ブランチの破棄》が行われない限りブランチで効率が上がることはないと思ってる
逆に言えばマネジメントがまともに出来ないレベルの連中でもそこそこの開発効率を得られる点ではブランチは有効だが、
会社の場合は既に有能か無能か分かってる連中に仕事を配分するから、そこまで酷くなることはない)

伝わらないかもしれないが、「最終的に『必ず』マージすると分かっている作業なら、
最初からマージした状態で作業を進めていった方が理論的な効率は高い」ということ
つまり、形式としてはsvnの方がgitより理論効率は高いことになる
(実際に出来るかどうかはまた別だが)

多分な、(オープンソース等)ある程度rejectする前提ならgitのように気軽にブランチ丸ごと捨てられる構造が便利だが、
(プロプライエタリ等)最終的に全員のコードをマージする前提で仕事配分してたら、svnでも、ブランチ無くても、大して問題ないって事だと思う