Git 16©2ch.net

2017/08/15(火) 00:54:07.61

ソースコード管理を行う分散型バージョン管理システム、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 14
http://echo.2ch.net/test/read.cgi/tech/1457412803/
Git 15
http://mevius.2ch.net/test/read.cgi/tech/1486239735/

VIPQ2_EXTDAT: checked:vvvvvv:1000:512:----: EXT was configured

2020/06/02(火) 02:44:05.47

Git v2.27.0

2020/06/05(金) 18:12:43.55

基本的なことでしたらすみません
マージしてpushしようとしたら、既にリモートのブランチが更新されてた場合ってどう対応してますか？

2020/06/05(金) 19:30:22.23

>>956
fetchして、ブランチを全部表示すると、
自分のブランチとリモートブランチが枝分かれしてるから、
そのリモートブランチを持ってきて、自分のブランチにマージしてからコンフリクトを解消、改めてプッシュしたらいいのでは

それか、自分のブランチをリベースするか
（リモートブランチの先端に自分のブランチの変更をすべてチェリーピックするのと同等）

2020/06/05(金) 21:46:42.14

>>957
自分も前者のやり方で対応してたのですが、
マージ先のブランチを更新する人が多く、pushするタイミングが難しくて質問してみました

リベースはやったことないので調べてみます

2020/06/05(金) 23:50:12.63

pullしてそのままpushするだけでいいよ
履歴を綺麗に保ちたいならgit pull -rebase
時間のかかる大規模なマージのときは事前にコミュニケーションをとって不幸な競合をなるべく回避するように根回し
ひとつのブランチに対してコミットする人が多すぎるならブランチ運用の設計がまずいかもと相談する

2020/06/06(土) 00:10:37.80

その状況だと、リベースとマージは同じだと思うよ。
pushするときに毎度マージが発生するのは仕方ないかもしれないけど、
それをマージしおわってpushしたらもう更新されてたっていうのなら、運用見直したほうがいいと思う。
調停する人置くとかしないとならんかな

2020/06/13(土) 02:42:46.35

Masterって言葉は差別的らしい。

こういう流れを受けて、git 本体のMLでも議論されてる。
Rename offensive terminology (master)
https://public-inbox.org/git/bef39243-806f-7c4a-c3d1-f3500ec377be@iee.email/T/#t
というスレで議論されてる

うーん

2020/06/13(土) 09:41:05.39

主人も婦人も夫人も差別語だな
フェミ厨の出番だぞがんがれ

2020/06/13(土) 10:14:31.26

Masterさんを迫害するな差別主義者どもめ

2020/06/13(土) 11:06:15.43

メタリカのアルバム「Master Of Puppets」の邦題が「メタル・マスター」というのは、どう考えてもおかしい。

2020/06/13(土) 14:28:58.70

BLMの飛び火だろうか
ATA規格のmaster vs slaveが避けられるのはわかる
masterのあるじとしての語義は宜しくないんだろう
でもmaster copyのような原本としての語義までケチをつけるのはどうなのか
Master Yodaのような達人や先生の語義は言わずもがな

>>962
mistressも同じだからフェミ云々はお門違いだろ

2020/06/15(月) 12:44:57.78

Masterを「原版」not主人の意味に定義すりゃ終わる話だな。
手間かけて修正するほどの話じゃない。

言い出しっぺはパッチ出したのかな？

2020/06/16(火) 06:59:51.19

ＳＪＷにはうんざりする

2020/06/18(木) 12:37:36.15

デフォルトのブランチ名の上書きのためのパッチがMLで議論されてる。
パッチの作者はMSの人だと思う

[PATCH 0/9] Allow overriding the default name of the default branch
https://public-inbox.org/git/xmqqd05xtp2g.fsf@gitster.c.googlers.com/T/#t

2020/06/18(木) 21:11:41.87

Github、人種差別を連想させるコーディング用語の見直しへ
https://www.gizmodo.jp/2020/06/github-to-remove-master-and-slave-coding-terms-widely-s.html

米GizmodoがGithub広報に確認したところ｢3つの変化を起こすため、Gitプロジェクトや他のバージョン管理ベンダーと共に積極的に取り組んでいます｣と詳細を明かしています。それによると3つの変化とは次の通り。

(1) 新規リポジトリでデフォルトのブランチ名を‘master’から変更する
(2) すべての新規リポジトリで、自分のデフォルトのブランチ名を簡単に選択できるようにする
(3) 既存リポジトリでデフォルトのブランチ名を変更する方法について、ユーザー向けのガイダンスやツールをリリースする

今回、見直されている用語は長い間批判されていましたが、GithubのほかPythonも非攻撃的な用語への切り替えに着手していること、
さらにGitlabが最初のイテレーションに取り組んでいて、ユーザーが自分のデフォルトのブランチ名を選択できるように動いていることを明かしています。

2020/06/18(木) 21:52:02.54

git自体も差別じゃないんか

2020/06/18(木) 22:03:59.70

せめてエイリアスにしてくれ
こんなくだらない理由で改修とかバカバカしすぎる

2020/06/18(木) 22:14:47.60

gitのブランチ名はmastet以外に好きに変えられるからいいとしても、デファクトスタンダードな用語をいまさら変えるなんて混乱が起きそうだ
これからmasterブランチのことをなんて呼んだらいいんだろう

2020/06/18(木) 22:42:45.63

「メインブランチ」でいいじゃん。

2020/06/18(木) 23:00:37.99

>>969
githubの話は別のスレでやってくれ

2020/06/21(日) 16:17:31.25

>>973
パワハラでsubmoduleから提訴されるんですね

2020/06/22(月) 20:58:33.95

Git15周年 - GitHubとGitLabに聞く
https://www.infoq.com/jp/news/2020/06/git-fifteen-anniversary-qa/

2020/07/10(金) 22:57:13.05

Git v2.28.0-rc0

2020/07/20(月) 14:46:39.24

rebase -i でコミット整理してる時、面倒なコンフリクトが大量に発生したら皆さんどうしてますか？
やっぱり手動で逐一解決しますかね？

2020/07/20(月) 15:07:06.59

>>978
rebase中止して、conflict解消したcommitして全部sqash

2020/07/28(火) 12:37:17.72

Git v2.28.0

2020/07/28(火) 18:56:12.85

macOSの brew が鬼のような速さでgit更新に対応してた。

2020/07/28(火) 19:40:29.57

git公式がポリコレ機能アピールしててワロタｗｗｗｗｗ
もうこの世界オワタｗｗｗｗｗ

2020/07/29(水) 08:40:04.95

https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.28.0.txt

The name of the primary branch in existing repositories, and the default name used for the first branch in newly created repositories, is made configurable,
so that we can eventually wean ourselves off of the hardcoded 'master'.

2020/07/29(水) 09:54:08.36

M$が関わると碌なことにならない

2020/07/29(水) 14:17:27.85

git本体にMSの魔の手が及んだ訳では無いだろ

2020/07/29(水) 15:20:23.29

gitとGitHubを混同してる人結構いるもんね

2020/07/29(水) 15:52:46.53

Highlights from Git 2.28
https://github.blog/2020-07-27-highlights-from-git-2-28/

筆頭にポリコレ機能が…

2020/07/29(水) 16:34:47.09

git ～地図にない場所～

2020/09/01(火) 20:03:54.91

コミット＆プッシュしたとき
ローカルリポジトリ更新されて
リモートリポジトリでコンフリクトでエラーが出て止まったときって
プルしようにもローカルリポジトリでエラー出て
プッシュはもちろんできなくて
作業フォルダは>>>>>>>>>>文字列で
やられちゃってるじゃないですか？

一旦リモートリポジトリの全部とって
手動でマージしたいんですけど
なんとか前の状態に綺麗に戻せませんでしょうか？

2020/09/01(火) 20:18:32.24

git checkout .

2020/09/01(火) 21:44:57.95

>>990
あ、やっぱりそのブランチは死んだと見るべきってことですね
回答ありがとうございました

2020/09/01(火) 22:42:19.89

>>991
ブランチは死んでない、なぜならコミットしてるのだからそこまでは戻せる
pull(リモートとのmergeのこと)にconflictして失敗したのだから、ダメになったのは作業コピー

2020/09/01(火) 23:46:31.27

作業フォルダが>>>>>でやられてるという理解がまず変じゃない？
Gitが分かりやすく競合位置をマーキングしてくれてるだけの一般的な状態
そこから生でテキストを編集するのが怖いならGUIのツールを使えばいい
これができないと常に競合に怯えることになる

2020/09/01(火) 23:46:54.44

ソース全体に無駄にフォーマッタをかけてしまって大量に競合した等、訳あってマージを取り消したいなら
git merge --abort
でマージ前に戻る
綺麗にpullしたいならさらに
git reset --hard HEAD^
でコミット前に戻してからpullして手動マージ

2020/09/01(火) 23:51:13.46

マージコミットを作ってもいいなら
git checkout --theirs .
でリモートのファイル内容になる
git checkout .
だとローカルが優先されるんじゃないかな、間違ってたらすまん
どちらにしてもマージの仕組みを理解していない人がこれやると不味いミスをやらかすかも

2020/09/02(水) 02:12:44.16

>>994
それって亀Gitやsourcetreeだとどういう操作になりますか？

2020/09/02(水) 09:25:07.81

>>996
亀ならログを開いてマージ直前かコミット前のコミットを選んでリセット
リセットするときhardを選ぶ

2020/09/02(水) 09:32:01.17

不馴れならhardでマージ前に戻してからmixedでコミット直前の状態に戻して、自分がコミットしたときの編集内容をアナクロな手段で待避しておいた方が安心かもな

2020/09/02(水) 10:43:21.75

>>997
ありがとうございます

①pushで失敗したときのローカルリポジトリのソースをエクスポートで退避
②リセットhard
③一応プル
④①を手作業でマージ
⑤commit＆push

って感じでやってみます!
今度コンフリクトしたら

2020/09/02(水) 12:21:58.30

次
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 1114日 11時間 27分 51秒