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/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秒