Git 17

**デフォルトの名無しさん** · 2020/09/02(水) 12:18:30.39

ソースコード管理を行う分散型バージョン管理システム、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 15
http://mevius.2ch.net/test/read.cgi/tech/1486239735/
Git 16©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1502726047/
-
VIPQ2_EXTDAT: checked:vvvvvv:1000:512:----: EXT was configured

**デフォルトの名無しさん** · 2021/08/21(土) 01:22:27.49

リポジトリのすべてのコミット履歴から特定の文字列を削除したいんですが良い方法無いですか？
filter-branchするしかないでしょうか？

**739** · 2021/08/21(土) 02:28:12.51

すみません
filter-branchでやりました

**デフォルトの名無しさん** · 2021/08/21(土) 03:02:27.50

20ファイルぐらいあるんですが今、filter-branchで1つずつ削除しています
たぶん土日潰れそうです

**デフォルトの名無しさん** · 2021/08/21(土) 20:58:05.05

>>30
去年のレスで申し訳ないけど
VSCodeやxcodeだと、git statusで差分があるファイルの色を変えたり表示を絞り込んだり出来るじゃん
ちまちまコミットしているとそれが出来なくなる(コミットする度に差分が無くなって特別扱いされるファイルが減る)
のが困るんだけど、どうにかなりませんか

**デフォルトの名無しさん** · 2021/08/22(日) 00:44:29.78

任意のコミット間で差分表示すればいいじゃん

**デフォルトの名無しさん** · 2021/08/22(日) 09:04:18.34

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2021/08/24(火) 01:56:30.85

739ですがBFG使ったら一発で出来ました

**デフォルトの名無しさん** · 2021/08/24(火) 17:06:56.87

BFGて何やと思ったらこんなツールあんのか

**デフォルトの名無しさん** · 2021/08/25(水) 09:15:45.93

BFG便利でしたよ

bfg replace-text password.txt myproject.git
でpassword.txtに指定されている文字列を置き換えできました

git grep $(git rev-list --all)
しても問題の文字列は綺麗になってました

**デフォルトの名無しさん** · 2021/09/06(月) 15:09:21.27

そろそろCVSからGitに移行しようとしています。

CVSからのリポジトリの移行の方法としてググってみたところ、cvs2git というのと、 git cvsimport ってのがあることが分かりました。
ところがcvs2gitはダウンロードしようとしてもサイトがもう閉鎖(?)されているようで入手できません。
cvsimportにしても、git-cvs の導入が必要で、自分の環境ではGitに合わせて2.27が必要そうなんだけど、やっぱり入手先が見つかりません。

誰かご存じの方いれば教えてください！
当方の環境とは、CentOS8にGit2.27.0を入れています。

**デフォルトの名無しさん** · 2021/09/07(火) 08:38:42.77

>>748
gitには今の最新のソースからリポジトリを一から作って
過去の変更履歴を参照したければcvsから見る、って運用ではダメなの？

**デフォルトの名無しさん** · 2021/09/07(火) 09:42:25.03

cvs→svn→gitの順番で変換するとか

**デフォルトの名無しさん** · 2021/09/07(火) 11:05:48.63

特定のバージョンが必要なら一旦それ入れれば良いだけだろ
要は変換できる環境で変換してしまえばできたものを持ってくればそれで良いんだから

**デフォルトの名無しさん** · 2021/09/07(火) 12:40:17.05

おお、皆さんコメントありがとうございます。

>>749

CVSを無くすことが目的の一つでもあるんです。
で、変更履歴が見れることも必要です。

>>750

SVN経由ですか。
できるなら避けたいですが、ちょっと調べてみます。

>>751

その通りなんですが、CVSからの移行をサブシステムごとに行うので、それなりの期間（多分1年以上）変換できる環境を維持する必要があるんです。

いろいろありがとうございました。
全ての要件を満たしてというのは難しそうですね。
いただいた意見を参考にもうちょっと検討します。

**デフォルトの名無しさん** · 2021/09/08(水) 12:26:53.74

git cloneする時にsshのurl指定でBranchまで指定する事って出来るの？
-bとか使わないで

**デフォルトの名無しさん** · 2021/09/11(土) 03:42:20.13

>>753
それ出来ないと思う
海外サイトで@でブランチ指定とか/でブランチ指定とかでやれるって書いてあるサイトも見つけたけど
実際やって見ても全然上手くいかねぇ

**デフォルトの名無しさん** · 2021/09/12(日) 00:33:12.39

ガチでない用途、雑多スクリプト集とかは平気で半年コミットしてないのとかあるんですけど
ローカルディレクトリをスキャンして最終編集日 - 最終コミット日の数字が多い順に表示して
いい加減コミットするか編集内容破棄するかしろと警告してくれるツールとかないですか

**デフォルトの名無しさん** · 2021/09/12(日) 06:50:28.66

面白いｗ

gitを使わずにディレクトリコピーでバージョン管理
https://mevius.5ch.net/test/read.cgi/tech/1631002816/

**デフォルトの名無しさん** · 2021/09/13(月) 17:58:18.08

リモートのHEADをリモートのdevelopを参照させるようにしたいのですがやり方がさっぱりわかりません。
とても単純なことのように思えるのですがどの方法でやってもSourceTreeなどでクローンするとmaster参照してて困ってます。
origin/HEAD -> origin/master
教えてくださいお願いいたします。

**デフォルトの名無しさん** · 2021/09/13(月) 18:04:15.74

こうなってます
.git]$ ls
COMMIT_EDITMSG HEAD branches description index logs packed-refs
FETCH_HEAD ORIG_HEAD config hooks info objects refs

というか僕何か勘違いしてるかも。
要はSourceTreeでクローンしたとき最新のコミットをHEADが参照してほしいのです。
そうしないと上に登ってってチェックアウトしないとだから。

**デフォルトの名無しさん** · 2021/09/13(月) 19:13:06.94

https://stackoverflow.com/questions/3301956/git-correct-way-to-change-active-branch-in-a-bare-repository

リモート側を変える

**デフォルトの名無しさん** · 2021/09/17(金) 17:13:11.77

未だにgit cloneで直接特定コミットのクローンが出来ないのはなぜだ
https://stackoverflow.com/questions/31278902/how-to-shallow-clone-a-specific-commit-with-depth-1

**デフォルトの名無しさん** · 2021/09/17(金) 17:22:01.88

クローンに特定コミットもへったくれも無いだろ

**デフォルトの名無しさん** · 2021/09/17(金) 18:11:47.26

shallow clone（--depth 1）で特定コミットの指定な

git cloneにdepth指定はできるが
同時に指定できるのはタグやブランチ名だけで
SHA1で過去のコミット一つだけみたいな指定はできない

なぜかgit fetchではSHA1指定とdepthの組み合わせが出来るらしい
解せぬ

**デフォルトの名無しさん** · 2021/09/22(水) 21:09:14.14

>>99
番号割り振ればできるだろ、知恵を絞れよ
何のために頭付いてるんだ、大学生にもなってなんだその頭の悪さは
gitのせいか、gitのせいでそんなに頭の悪い人間になってしまったんだな
ようし、gitを禁止します

**デフォルトの名無しさん** · 2021/10/06(水) 17:21:18.09

ブランチ切り忘れてコミットしまくったあとに
過去にさかのぼってブランチを作成して
全部そこで作業していたことにしたいんだけど
どうしたらいいかな？

**デフォルトの名無しさん** · 2021/10/06(水) 17:24:42.54

今いる場所でブランチを作成
元のブランチはリセット

**デフォルトの名無しさん** · 2021/10/06(水) 17:30:20.63

間違ってコミットしまくったブランチをまだpushしてないなら
コミットしまくった最後のコミットで新しいブランチ作って
間違ってコミットしまくったブランチの方を「git reset --hard origin/間違ったブランチ」とかすれば良いだろ？

**デフォルトの名無しさん** · 2021/10/06(水) 17:30:33.39

かぶったわ

**デフォルトの名無しさん** · 2021/10/10(日) 11:13:28.32

git bashでlsの実行結果が文字化けしたらコレ
export LANG=$(locale -uU)

**デフォルトの名無しさん** · 2021/10/12(火) 02:46:28.00

echo "export LANG=$(locale -uU)" > %USERPROFILE%\.bashrc

**デフォルトの名無しさん** · 2021/10/12(火) 08:42:22.48

おいおいおい
.bashrc消して平気なの？

**デフォルトの名無しさん** · 2021/10/14(木) 13:19:16.57

知っている方いたら教えてください。

CVSからGitに移行しようとしてます。
開発にはEclipseを使っていて、今はEclipseのプラグインでCVSと連携しています。
Git用にはEGitというプラグインが必要ということはググってわかりました。
EclipseでEGitを使う場合ローカルPCにGitの導入は別途必要ですか？

ネットで見た例だと、EGitで直接GitHubのリポジトリを指定してたんだけど、EGitを使えばリモートのリポジトリに直接アクセスすることになって、ローカルにリポジトリは作らない（なので、Gitの導入は不要）という理解であってますか？

事前に試せる環境がないため、経験者のかたがいれば教えてもらいたいです。

**デフォルトの名無しさん** · 2021/10/14(木) 14:14:33.36

>>771
gitはローカルリポジトリでコミットしてからリモートリポジトリにプッシュする二段階の仕組みなので、ローカルにgit「クライアント」は必要。（gitクライアントにローカルリポジトリを操作する機能が存在する）

**デフォルトの名無しさん** · 2021/10/14(木) 14:23:38.11

>>772
ちょっと補足。
Egitは使ったこと無いからは詳しく無いけど、解説とか見るとEgit+eclipseで一通りのgit操作はできるみたい。ただ、gitの仕組みとして（通常の利用方法だと）必ずローカルリポジトリを使うので、ローカルリポジトリ無しでリモートリポジトリを直接操作することはできない。

逆に、gitはリモートリポジトリ無しでローカルリポジトリのみの運用というのができるから、まずはそれで色々と試したら？

**デフォルトの名無しさん** · 2021/10/14(木) 14:26:08.18

>>771
Eclipseを使ったことはないが、こんなのを見つけた

https://www.casleyconsulting.co.jp/blog/engineer/223/
>EGit は Java の Git 実装である JGit を使って動きますので、別途 Git のコマンドラインツールなどを入れる必要はありません。

https://wiki.eclipse.org/EGit/FAQ
>What are the main differences between original Git and JGit(EGit)?

**デフォルトの名無しさん** · 2021/10/14(木) 14:36:06.90

Git v2.33.1

**デフォルトの名無しさん** · 2021/10/14(木) 14:37:15.68

>>771
egitは現在のeclipseに含まれています。
別途PCにgitのインストールは不要です。

**デフォルトの名無しさん** · 2021/10/14(木) 14:58:54.76

>>772,773,774,775,776

ああ、こんなすぐに親切なレスがいっぱい！！

> ローカルリポジトリ無しでリモートリポジトリを直接操作することはできない。
そうですよね。だからGit本体も必要じゃないかと思ってたんです。

>EGit は Java の Git 実装である JGit を使って動きますので、別途 Git のコマンドラインツールなどを入れる必要はありません。

Gitそのものではないけど、Gitと同じ動きをするJGitが使われているという事ですかね。
それでEclipse+Git関連の記事でもGitのインストールについて特に触れる必要がないと。

で、今時のElipseならEGitもついてくるんですね。Pleiadesのサイト見ましたが、確かにEGitもパッケージされてますね。

JGitでググってみたら紹介してくれたwikipedia以外にも日本語で紹介/解説しているサイトがいろいあるみたいなので、まずはそちらで勉強してみます。

モヤっとしてたのがスッキリしました。

またここで追加質問しちゃうかもしれませんがよろしくお願いします。

**デフォルトの名無しさん** · 2021/10/14(木) 23:57:06.50

どういたしまして！！！！
全部俺

**デフォルトの名無しさん** · 2021/10/17(日) 09:58:04.13

個人で開発してる場合に、subversionと比較してGitのほうが優れていることってどんなことがありますか？
Git使ってみてるんですが、ローカルリポジトリとリモートリポジトリに別れてるのが面倒くさく感じてしまうんです。

**デフォルトの名無しさん** · 2021/10/17(日) 10:38:37.55

ローカルリポジトリだけで出来る

**デフォルトの名無しさん** · 2021/10/17(日) 13:11:42.80

svnはマージがアホ

**デフォルトの名無しさん** · 2021/10/17(日) 13:55:53.46

個人でやってるならリモートリポジトリを使う必要ないよ
別の場所にバックアップしたいときだけ稀にプッシュしておいてもいいかな程度
Gitはブランチ開発が圧倒的に便利
次バージョンの開発をしながら、ヤバいバグを見つけたらスイッチして現行リリースにパッチを当てるなんて作業がやりやすい
コミット等の操作を間違えたときの復元方法も充実してるからガンガンコミットするスタイルが身についてロスがない
あまりにも小規模な開発しかしてないならGitに移行したところで便利さに気付かないかもね

**デフォルトの名無しさん** · 2021/10/17(日) 14:17:13.86

svnはもう使わなくなってから何年も立つけど、ローカルブランチ作るのに全コピーが発生する問題は改善されたん？
gitは瞬間的にローカルブランチ作れることが、当時、最大のメリットだと個人的には感じてたけど

**デフォルトの名無しさん** · 2021/10/17(日) 14:18:42.77

あ、ローカルって書いちゃったけどリモートも同様

**デフォルトの名無しさん** · 2021/10/17(日) 15:15:03.36

svnも物理コピーしてるわけじゃなくポインタをコピーしてるだけだからそこは別にデメリットではないと思う

**デフォルトの名無しさん** · 2021/10/17(日) 15:26:46.35

じゃあそこは改善されたんだね

**デフォルトの名無しさん** · 2021/10/17(日) 15:29:30.74

ローカルで何でもできるのとrebaseできるのが大きいな。

**デフォルトの名無しさん** · 2021/10/17(日) 16:36:16.01

svnのコピーは最初からそういう設計思想だよ
強いて言うならCVSに対しての改善点
https://subversion.apache.org/features.html

**デフォルトの名無しさん** · 2021/10/20(水) 03:48:00.82

--filter=blob:noneでcloneしたレポで久しぶりにpullすると

remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (1/1), 334 bytes | 334.00 KiB/s, done.
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (1/1), 413 bytes | 413.00 KiB/s, done.

が延々続く
.git/configのpromiser=trueとpartialclonefilter=blob:noneを消すと秒で終わる
これは仕様？

**デフォルトの名無しさん** · 2021/10/31(日) 11:33:48.76

Git v2.34.0-rc0

**デフォルトの名無しさん** · 2021/11/04(木) 09:59:24.05

Git v2.34.0-rc1

**デフォルトの名無しさん** · 2021/11/07(日) 11:40:46.01

MSに握られたくないなら、cvs か svn

**デフォルトの名無しさん** · 2021/11/07(日) 11:42:30.89

>>792
git使うとmsに握られるというのが意味不明なんだが

**デフォルトの名無しさん** · 2021/11/07(日) 12:37:05.54

gitとgithubの区別がつかない人がMSアレルギーをこじらせている姿はもう見飽きた
情報のアップデートをできずに屈折した持論を垂れ流すから老害の部類かな

**デフォルトの名無しさん** · 2021/11/08(月) 21:23:48.94

それはもはやチテキショウ害なのでは

**デフォルトの名無しさん** · 2021/11/11(木) 10:05:05.74

わろす

**デフォルトの名無しさん** · 2021/11/16(火) 08:19:16.49

Git v2.34.0

**デフォルトの名無しさん** · 2021/11/25(木) 08:42:00.93

Git v2.34.1

**デフォルトの名無しさん** · 2021/11/25(木) 12:21:37.68

すぐキレるLinusも若手から老害と言われてるんだろうな。

**デフォルトの名無しさん** · 2021/11/27(土) 18:33:16.18

プライベートなリポジトリをローカルにcloneしようとしたら
重いファイル（15MB程度）だけ弾かれる・・どうして・・
ちなみに学習済みの.h5ファイル
何か制限緩和するような手続きしないといけないのかな
（ただ、google経由だと全部cloneできた）
全然わからん・・

**デフォルトの名無しさん** · 2021/11/30(火) 21:35:19.46

10年程昔からの自作のフリーウェアを git で公開しようとしているんだけど
あまり昔の version はもう環境が変わっていて動かない
動くものだけを公開した方が良いのかな
それとも最新のものだけにした方がいいですか

**デフォルトの名無しさん** · 2021/11/30(火) 21:59:48.42

好きにしろ

**デフォルトの名無しさん** · 2021/11/30(火) 22:33:45.81

わかりました
どうも

**デフォルトの名無しさん** · 2021/12/09(木) 01:56:53.52

gitの変更履歴より細かい単位で変更を戻したいとき、うまい方法はありますかね。
例えば一つのファイルの中で3つの関数を変更してコミットした後、1つの関数だけ
元に戻したくなった場合などに。

**デフォルトの名無しさん** · 2021/12/09(木) 06:55:22.90

>>804
その関数を変更した後にコミット

**デフォルトの名無しさん** · 2021/12/09(木) 07:23:14.89

>>804
git rebase

1
2
3 ← ここで止める
4
5

1
2
3.1
3.2
3.3 ← こんな感じにコミット

git rebase --continue でリベース完了

あと慣れたら 2つの関数だけコミットして、
1つは戻ればいい

**デフォルトの名無しさん** · 2021/12/09(木) 08:05:36.93

>>804
pushする前ならcommit amend して修正してからrebase。
push後なら新たにcommit。

**デフォルトの名無しさん** · 2021/12/09(木) 08:13:38.11

あめんどは、あ、めんどう～だ、なぁ～

**デフォルトの名無しさん** · 2021/12/09(木) 08:15:15.22

求めてるのはadd -pじゃないのかな

**デフォルトの名無しさん** · 2021/12/09(木) 08:22:24.08

>>807
わかりづらいな……試してないけど
…56 3関数commit abc……master
　　ここをchechout -b mod

…56 3関数commit abc……master
[mod:2関数commit]
元に戻してcommit amend

…56 3関数commit abc……
mod abc……[master]
masterをchechoutしてmodにrebase

ただし、コミットを他人と共有済みなら混乱の元なので禁止。

**デフォルトの名無しさん** · 2021/12/09(木) 08:58:11.54

>>804
履歴改変をするわけじゃないんだよね？それならば、
git revert -n でindexに三つの関数の修正を打ち消す修正を持ってきて、git reset -p でindexの余分な修正を取り除いて、git commit

**804** · 2021/12/09(木) 09:39:57.87

どうも>>804です。プッシュはしてませんのでアメンドないしリセットとしてやり直すことは
可能です（よね?）

なんというか、作業方法なども含めてキレイ&楽にやる方法はどんな感じかなと。
例えばそもそも論だと、最初からこういう場合に備えてコミットを関数1個毎とか細かくしておく?
アメンドないしリセットしてやり直す場合も、どうやって変更を用意しようかなと... もう一回
同じ変更を入力したくはないし危険... とかなんとか。

**デフォルトの名無しさん** · 2021/12/09(木) 10:00:49.33

>>812
だから何をしたいのかはっきりしろ
pushしてないのは分かった
pushしてないローカルな履歴を改変したいのか？
pushしてないローカルな履歴に関数の修整を無効化するコミットを追加したいのか？

**デフォルトの名無しさん** · 2021/12/09(木) 10:05:24.50

>>812
変更の用意はrevert -nとreset -pでいいだろ
この2つを使えば自分でコードを入力する必要は無い

**デフォルトの名無しさん** · 2021/12/09(木) 11:35:29.86

>>812
だから>>806だって
rebaseで過去の歴史の途中に戻って
そこでコミットを分けるなりして
再び歴史を再生する

**デフォルトの名無しさん** · 2021/12/09(木) 11:36:08.99

正確には git rebase -i な

**デフォルトの名無しさん** · 2021/12/09(木) 13:53:35.69

もう面倒くさいから一か所もどしましたってコミットしたらいいやん

**デフォルトの名無しさん** · 2021/12/09(木) 14:15:33.20

rebaseは悪い文化

**デフォルトの名無しさん** · 2021/12/09(木) 14:50:31.70

>>818
必要なのは結果だけ
お前が試行錯誤した後なんかどうでもいい

**デフォルトの名無しさん** · 2021/12/09(木) 14:51:34.29

>>817
そのコミットを簡単に作る方法が知りたいのだと思う

**デフォルトの名無しさん** · 2021/12/09(木) 15:05:38.49

>>820
Winmergeをdiffツールに設定して
git windiff HEAD^^^
で戻してcommitだな俺なら

**デフォルトの名無しさん** · 2021/12/09(木) 15:28:07.01

>>812
そもそも論の部分に回答すると、意思決定の基本は発生率とコストを掛け合わせた期待値次第
いちいち細分化しすぎてもYAGNIの法則で言われるような無駄が多くなるだけ
でも後から部分的に採用する可能性もそれなりにあるのであれば分けてコミットしておくことでコストを抑えられる可能性が増す

**デフォルトの名無しさん** · 2021/12/09(木) 18:55:14.96

>>812
そもそも論で言うなら、追加・修正する機能ごとにブランチを切って、完成したブランチを別々にコミットすればいい。gitはブランチが軽量という強みもあるし。

機能をマージするときにコンフリクトを修正する面倒くささはあるけど、見通しは良くなる。

**デフォルトの名無しさん** · 2021/12/09(木) 20:50:07.62

コミットの粒度の話じゃないの？

**デフォルトの名無しさん** · 2021/12/09(木) 22:51:55.36

追えてないけど、どれか。
・そもそもコミットきれいにしても結局使わないから作り直さない
・頻繁にコンパイル？して頻繁にコミットしておく
・もう最初から作り直せよ派: git reset $(git merge-base origin/master) → 気に入るコミット作っていく。
・ツールに関数単位で切り出させて、差分をうまいことやる。VisualStudioならこのメソッドをクラス化、みたいなやつがあったような。それ以外は知らん。

**デフォルトの名無しさん** · 2021/12/09(木) 23:49:30.01

コミットをセーブ機能だと思うからだめなんだよ
袋だと思え袋
コードを書くたびに適切な袋に入れろ

**デフォルトの名無しさん** · 2021/12/10(金) 11:49:29.41

>>825
・追加機能ごとにブランチ切る
も追加で。

**デフォルトの名無しさん** · 2021/12/10(金) 15:18:37.19

最近では、機能ブランチは問題を先送りにしているだけだという批判もある
機能ブランチはすぐにリリースして消せ、作りかけならフィーチャートグルで蓋をしろというスタイルもあるぞ
それは一理あって、実際複数のチームでそれぞれフィーチャーブランチを担当してリリース時に一気にマージするスタイルの大規模サービス開発やってたときには
マージの失敗でトラブルが起こることは日常茶飯事だったね

**デフォルトの名無しさん** · 2021/12/11(土) 00:15:15.28

それは機能ブランチが悪って話じゃなくて、機能ブランチをやたらと長期間分離しておくのが悪って話じゃね
何事もトレードオフだから機能がでかいならイテレーションを小さく取るし、リリースギリギリまでマージしなければ泣きを見るので頃合いを見て合流してテスト始める
互いに影響し合う部分についてはコミュニケーション取りつつ適宜ソースをやり取りしろというのがGitの指針だったと思うし

**デフォルトの名無しさん** · 2022/01/12(水) 10:21:41.75

Git v2.35.0-rc0

**デフォルトの名無しさん** · 2022/01/12(水) 19:57:57.27

こういうコミットをしてたとして

$ git log --oneline

commit_id_5 やっぱり××を復活させる(2021/05/01)
commit_id_4 □□を修正(2021/04/01)
commit_id_3 ××を削除(2021/03/01)
commit_id_2 △△を修正(2021/02/01)
commit_id_1 〇〇を修正(2021/01/01)

「commit_id_3 と commit_id_5 を消して、コミットログをきれいにした状態でリモートブランチにpushする」というようなことは可能ですか？
こういう場合にgit rebaseが使われるんですかね？

**デフォルトの名無しさん** · 2022/01/12(水) 21:08:30.47

>>831
はい。そうです。

**デフォルトの名無しさん** · 2022/01/12(水) 21:16:41.65

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

てか真上に同じような質問ありましたね…

**デフォルトの名無しさん** · 2022/01/15(土) 22:30:31.28

Git v2.35.0-rc1

**デフォルトの名無しさん** · 2022/01/16(日) 00:47:01.30

>>831
俺は作りながら片付ける

作ってる途中で、この修正はこのコミットに含めよう
などと考えならが小さくコミットし
適度なタイミングでrebaseする

**デフォルトの名無しさん** · 2022/01/17(月) 06:52:31.08

>>831
別ブランチでcommitして、masterにまとめてmergeしてpushする、って方法もあるよ
これだとrebaseは不要

**デフォルトの名無しさん** · 2022/01/23(日) 09:44:11.74

gitもcvs,svnと同じ運命をたどるだろう
私の企業は次世代バージョン管理システムfossilに切り替えました

**デフォルトの名無しさん** · 2022/01/24(月) 13:46:51.63

化石？