[過去ﾛｸﾞ] Git 16©2ch.net (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
53: (ﾜｯﾁｮｲ 46db-o7xi [153.203.255.36]) 2017/09/17(日)15:58:25.17 ID:nfmsAfUe0(1) AAS
俺は gitk --all 見ながら操作はコマンドだな。
176: (ｽﾌﾟﾌﾟ Sdf2-szy9 [49.96.19.35]) 2018/01/27(土)16:19:47.17 ID:R/dV78Std(1) AAS
他人が読めない糞コード書くからやり直しさせられてるんだな
gitが品質向上に役立ってることが分かりました
279: (ﾄﾞｺｸﾞﾛ MM11-4oWc [110.233.246.88]) 2018/06/27(水)14:49:54.17 ID:HDQcbBITM(2/2) AAS
無駄な機能使って悦に浸りたいだけか
309(1): (ｽﾌﾟﾌﾟ Sd03-wHw+ [49.98.75.13]) 2018/06/30(土)19:44:02.17 ID:HeGiQgTKd(1) AAS
>>308
何を？
489: (ﾜｯﾁｮｲ 52bc-g3SB [123.198.62.37]) 2018/09/09(日)19:28:30.17 ID:MfNlARvD0(1) AAS
>>482
まあ、それでもいいと思ってる。
492(1): (ﾜｯﾁｮｲ d2d2-JH7f [27.139.3.34]) 2018/09/10(月)02:14:11.17 ID:U+kFg4Kd0(1) AAS
Girのマージでロジックが変わってしまうパターンってなんかある？
VSSロックは官公庁の開発では割とアリだなと思ったよ
577: (ﾜｯﾁｮｲ 1d01-H2Om [60.114.11.177]) 2019/02/13(水)02:30:48.17 ID:ID+kUm5P0(1) AAS
1人だとrebase -iの嵐
641: (ﾜｯﾁｮｲ d7f0-1u0g [220.213.58.220]) 2019/04/03(水)07:04:24.17 ID:QKAgpFa00(1) AAS
git flowならreleaseブランチを作ろうよ
8/1顧客テストの機能をdevelopにマージしたいけど前の機能がまだmasterにマージできていないので無理、という状況を避けられる
リリースのタイミングが多少変わった程度でブランチ設計を見直さずに済む
722: (ﾜｯﾁｮｲ 3969-Xoj2 [180.36.244.135]) 2019/06/08(土)08:15:28.17 ID:6fTN99E40(1) AAS
Git v2.22.0
837(1): (ﾜｯﾁｮｲ 2b63-QS5Z [114.164.202.189]) 2019/11/24(日)12:50:33.17 ID:gnIUHiL60(1/4) AAS
githubでプルリクをマージする人ってプルリクを送った側と受け取った側とでどちらが良いんでしょうか
個人的にはプルリクって、もしこの修正が問題なければ取り込んでくださいって意味だから
受け取った側が承認してマージまでするのが自然な形だと思うんですが、
なぜか今の職場ではプルリクを送った側が自分でマージするルールになっています
私がおかしいのでしょうか
878: (ﾜｯﾁｮｲ 555f-vhPX [14.9.147.224]) 2020/01/27(月)22:52:01.17 ID:eRzXcwZO0(1) AAS
patch
924: (ｵｲｺﾗﾐﾈｵ MM13-vLrg [103.84.127.57]) 2020/03/13(金)14:46:24.17 ID:60Tos3d2M(1) AAS
CUIおじさんとORM嫌いおじさんとstaticおじさんて同じ人？
998: (ﾜｯﾁｮｲ 059f-cia9 [118.109.112.224]) 2020/09/02(水)09:32:01.17 ID:RfITVUZj0(2/2) AAS
不馴れならhardでマージ前に戻してからmixedでコミット直前の状態に戻して、自分がコミットしたときの編集内容をアナクロな手段で待避しておいた方が安心かもな
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.033s