Gitでファイルを移動/名前変更してその履歴を維持することは可能ですか?


667

Gitのプロジェクトサブツリーの名前を変更/移動したい

/project/xyz

/components/xyz

プレーンを使用するgit mv project componentsと、のすべてのコミット履歴xyz projectが失われます。履歴が維持されるようにこれを移動する方法はありますか?



2
ファイルシステムを介してファイルを移動することをテストしただけであり、(intellijを介して)コミットした後、履歴を(intellijで)表示すると、履歴全体(別の場所にあったときの履歴を含む)を確認できます。私はintellijがそれを行うために特に特別なことを何もしていないと想定しているので、少なくとも履歴を追跡できることを知っておくと便利です。
BT

ディレクトリの名前変更を検出するときにGitが従うルールについては、以下の私の回答を
VonC '30

ここに答えを書きました。うまくいくといいですね。stackoverflow.com/questions/10828267/...
マフムトEFE

回答:


651

Gitはあなたが使用しそうかどうか、かなりコミットを使用して操作を持続するよりも、名前の変更を検出したgit mvか、mv問題ではありません。

このlogコマンドは、--follow名前変更操作の前に履歴を継続する引数を取ります。つまり、ヒューリスティックを使用して同様のコンテンツを検索します。

http://git-scm.com/docs/git-log

完全な履歴を検索するには、次のコマンドを使用します。

git log --follow ./path/to/file

63
これはパフォーマンスの問題だと思います。完全な履歴が必要ない場合は、コンテンツのスキャンに時間がかかります。最も簡単な方法は、エイリアスを設定してgit config alias.logf "log --follow"書き込むだけgit logf ./path/to/fileです。
Troels Thomsen、2010

13
@TroelsThomsen この電子メールからリンクされているLinus Torvalds氏によって、この答えを、それが伝えられるところではるかに強力な名前の変更などを追跡するよりもだから、それはGitリポジトリの意図的な設計上の選択だということを示している
エミル・ランドバーグ

127
この答えは少し誤解を招くものです。Gitは「名前の変更を検出」しますが、ゲームの非常に遅い段階です。問題は、Gitが名前の変更を確実に追跡する方法を尋ねることです。これを読んでいる人は、Gitが名前を自動的に検出してメモしていると簡単に推測できます。ありません。Gitは実際の名前変更を処理せず、代わりに何が起こったのかを理解しようとするマージ/ログツールがあります。Linusは、gitが正しい方法で名前を変更し、名前を明示的に追跡すべきではない理由について、誤っていますが猛烈な議論を持っています。だから、ここで立ち往生しています。
Chris Moschini、2014

29
重要:ディレクトリの名前を変更する場合(Javaパッケージの名前を変更するときなど)は、必ず2つのコミットを実行してください。1つ目は「git mv {old} {new}」コマンド、2つ目は、参照するすべてのJavaファイルの更新です変更されたパッケージディレクトリ。それ以外の場合、gitは--followパラメーターを使用しても、個々のファイルを追跡できません。
nn4l 2014年

44
Linusは間違いをほとんど起こさないでしょうが、これは間違いのようです。フォルダーの名前を変更するだけで、大規模なデルタがGitHubにアップロードされます。そのため、フォルダの名前を変更することに注意が必要ですが、プログラマにとってはかなり大きなストレートジャケットです。時々、私は何かの意味を再定義したり、物事の分類方法を変更したりする必要があります。Linus:「言い換えれば、私は正しいです。私は常に正しいですが、時には他の場合よりも正しいかもしれません。そして、「ファイルは重要ではない」と言ったとき、私は本当に本当に正しいです( tm)。」...私はそれについて疑問があります。
Gabe Halsmer、2015

94

ファイルの名前を変更して履歴をそのまま保持することは可能ですが、リポジトリの履歴全体でファイルの名前が変更されます。これはおそらく強迫的なgit-log-loversのためだけのものであり、以下を含むいくつかの深刻な影響があります。

  • 共有履歴を書き直すこともできます。これは、Gitを使用しているときに最も重要なことではありません。他の誰かがリポジトリのクローンを作成した場合は、これを行うことで破壊します。彼らは頭痛を避けるために再クローンしなければなりません。名前の変更が十分に重要な場合は問題ありませんが、慎重に検討する必要があります。つまり、オープンソースコミュニティ全体を混乱させる可能性があります。
  • リポジトリ履歴で以前の古い名前を使用してファイルを参照している場合は、以前のバージョンを事実上破壊しています。これを解決するには、もう少しフープジャンプを行う必要があります。それは不可能ではなく、退屈で、おそらくそれだけの価値はありません。

さて、あなたは私と一緒にいるので、あなたは完全に孤立したファイルの名前を変更するおそらく一人の開発者です。を使用してファイルを移動しましょうfilter-tree

ファイルoldをフォルダに移動dirして名前を付けると仮定しますnew

これはで行うことができますgit mv old dir/new && git add -u dir/newが、それは歴史を壊します。

代わりに:

git filter-branch --tree-filter 'if [ -f old ]; then mkdir dir && mv old dir/new; fi' HEAD

ブランチのすべてのコミットをやり直し、各反復のティックでコマンドを実行します。これを行うと、多くの問題が発生する可能性があります。私は通常、ファイルが存在するかどうかを確認し(そうでない場合、まだ移動する必要はありません)、必要な手順を実行して、好みに合わせてツリーをシューホーンします。ここで、ファイルへの参照を変更するために、ファイル全体をsedする場合があります。ノックアウト!:)

完了すると、ファイルが移動され、ログはそのまま残ります。あなたは忍者海賊のように感じます。

また; もちろん、mkdir dirは、ファイルを新しいフォルダーに移動する場合にのみ必要です。もしあなたのファイルが存在するよりも、歴史の中で前にこのフォルダの作成を避けることができます。


57
執念深いgit-log-loverとして、私はこれには行きません。それらの時点ではファイルには名前が付けられていなかったため、履歴は存在しない状況を反映しています。過去にどのようなテストが失敗するかは誰にもわかりません!以前のバージョンを壊すリスクは、ほとんどすべての場合において価値がありません。
Vincent

7
@Vincentあなたは完全に正しいです、そして私はこの解決策の不適当さが適切であることについて私ができる限り明確にしようとしました。また、この場合、「歴史」という言葉の2つの意味について話していると思います。両方に感謝します。
ØysteinSteimler

6
私はこれが必要になるかもしれない状況を見つけました。私が自分の個人のブランチで何かを開発したとしましょう。それを上流にマージしたいと思います。しかし、私はファイル名が適切ではないことを発見しました。そのため、私は個人のブランチ全体のためにそれを変更します。そうすれば、きちんとした適切な履歴を維持し、最初から正しい名前を付けることができます。
user2291758 2015年

3
@ user2291758それが私のユースケースです。これらのより強力なgitコマンドは危険ですが、何をしているのかわかっていても、非常に説得力のあるユースケースがないわけではありません。
philix

1
可能であれば--index-filter、ツリーをチェックアウトしてコミットするたびに戻す必要がないため、for renamesを使用するとはるかに高速になります。--index-filter各コミットインデックスに直接作用します。
Thomas Guyot-Sionnest 2017

87

番号。

短い答えはNOです。Gitでファイルの名前を変更して履歴を記憶することはできません。そしてそれは苦痛です。

噂でgit log --follow--find-copies-harderはうまくいくと思いますが、ファイルの内容に変更がなく、移動がで行われたとしても、私にはうまくいきませんgit mv

(当初、私はGitのを混同している可能性が一回の操作で、パッケージの名前を変更し、更新するためにEclipseを使用していました。しかし、それは行うには非常に一般的なものである。--follow場合にのみ動作するようには思えないmv行った後、さcommitmv遠くではありません。)

Linusは、個々のファイルを追跡する必要はなく、ソフトウェアプロジェクトの内容全体を全体的に理解することになっていると言います。残念ながら、私の小さな脳はそれを行うことができません。

Gitが動きを自動的に追跡するという発言を非常に多くの人々が無意識に繰り返してきたのは本当にうっとうしいことです。彼らは私の時間を無駄にしました。Gitはそのようなことをしません。設計上(!)Gitは動きをまったく追跡しません。

私の解決策は、ファイルの名前を元の場所に戻すことです。ソース管理に合わせてソフトウェアを変更します。Gitを使用すると、最初からそれを "git"する必要があるようです。

残念ながら、それはを使用しているように見えるEclipseを壊します--followgit log --follow複雑な名前変更履歴があるファイルの完全な履歴が表示されない場合がありますgit log。(何故かはわからない。)

(以前の作業に戻って再コミットする巧妙なハックがいくつかありますが、恐ろしいものです。GitHub -Gist:emiller / git-mv-with-historyを参照してください。)


2
私はあなたが正しいと信じています。私はphp-cs-fixerを使用してLaravel 5プロジェクトのソースを再フォーマットしようとしていましたが、名前空間句の大文字の使用を変更して、アプリフォルダーの小文字の値と一致させることを要求しています。ただし、名前空間(またはコンポーザーのオートロード)はCamelCaseでのみ機能します。フォルダーの大文字をAppに変更する必要がありますが、これにより変更が失われます。これは最も簡単な例ですが、gitヒューリスティックが最も単純な名前変更でさえ追跡できないことを示しています(--followと--find-copies-harderが例外ではなく、ルールである必要があります)。
ザックモリス

6
git -1、subversion +1
Cosmin

これはまだ本当ですか?これが今のところtfsを使用する理由の1つです。移動/名前変更されたファイルの履歴を保持することは、大規模なプロジェクトでは必須です。
セザール

@Cesar「履歴を記憶する」とは、「ログを表示するときに名前を変更する」(これは私たちが気にする必要がある唯一の便利なことです)を意味する場合、これは真実ではありませんでした!Gitは名前変更を「記録」しませんが、ツールはそれらを簡単に検出して、名前変更と移動を提示できます。「うまくいかない」場合は、使用しているツールを変更する必要があります。この機能を持つ素晴らしいGit GUIはたくさんあります。
Mohammad Dehghan

短い答えははいです。Gitの現在のバージョンは "git log --follow"もサポートしています。そして、私は@MohammadDehghanに同意する
insung

42
git log --follow [file]

名前を変更して履歴を表示します。


29
ファイルの変更を開始する前に、名前の変更だけをコミットする必要があるようです。(シェル内で)ファイルを移動してから変更すると、すべてのベットが無効になります。
ヨーヨー

22
@yoyo:gitは名前の変更を追跡しないため、名前を検出します。Aはgit mv基本的にgit rm && git add-M90/のようなオプションがあり--find-renames=90、ファイルが90%同一である場合にファイルの名前を変更すると見なします。
vdboor

22

私がやります:

git mv {old} {new}
git add -u {new}

3
-uは私には何もしないようですが、履歴を更新するためのものですか?
ジェレミー2013年

1
おそらく、-A代わりにの動作が必要ですか?繰り返しますが、こちらをご覧ください:git-scm.com/docs/git-add
James M. Greene

1
ファイルは追加されますが、履歴は更新されないため、「git log file name」は完全な履歴を表示します。--followオプションを引き続き使用した場合にのみ、完全な履歴が表示されます。
ジェレミー2013年

3
(git mvではなくmvを使用して)インクルードディレクトリを移動する複雑なリファクタリングを行い、名前を変更したファイル内の多くの#includeパスを変更しました。gitは、履歴を追跡するのに十分な類似性を見つけることができませんでした。しかし、git add -uは私が必要とするものでした。gitステータスが「名前が変更されました」を示すようになりました。
AndyJost 2013

1
SOには、の目的に対応する多くの質問がありますgit add -u。Gitのドキュメントは役に立たない傾向があり、私が見たい最後の場所です。これgit add -uが実際に表示されている投稿の1つです:stackoverflow.com/a/2117202
nobar 2017年

17

Gitのプロジェクトサブツリーの名前を変更/移動したい

/project/xyz

/ components / xyz

プレーンを使用するgit mv project componentsと、xyzプロジェクトのすべてのコミット履歴が失われます。

いいえ(8年後、Git 2.19、2018年第3四半期)。Gitがディレクトリ名の変更検出するためです。これはドキュメント化が進んでいます。

参照b00bf1cコミット1634688をコミット0661e49コミット4d34dffコミット983f464コミットc840e1aコミット9929430コミット(2018年6月27日に)、そしてd4e8062コミット5dacd4aコミットにより(2018年6月25日)をエリヤNewren( )newren
(合併によりJunio C浜野- gitster-0ce5a69コミットし、2018年7月24日)を

それは今で説明されていDocumentation/technical/directory-rename-detection.txtます:

例:

すべての場合にはx/ax/bおよびx/cに移動してきたz/az/bそしてz/c、それは可能性がありx/d、その間に追加もに移動したいz/dディレクトリ全体が「というヒント取ってx」に移動する「z」を。

ただし、次のような他の多くのケースがあります。

履歴x -> zの一方の名前は、もう一方は一部のファイルの名前をに変更 x/eするため、マージで推移的な名前変更を行う必要があります。

ディレクトリの名前変更の検出を簡略化するために、これらのルールはGitによって適用されます。

ディレクトリ名の変更の検出が適用される場合、いくつかの基本的なルール制限があります。

  1. 特定のディレクトリがマージの両側にまだ存在する場合、名前が変更されたとは見なされません。
  2. 名前を変更するファイルのサブセットにファイルまたはディレクトリがある場合(または相互に邪魔になる場合)は、それらの特定のサブパスのディレクトリの名前変更を「オフ」にし、ユーザーに競合を報告します。 。
  3. 履歴の反対側でディレクトリの名前を変更して、履歴の反対側で名前を変更した場合、暗黙的なディレクトリの名前変更については、履歴の反対側からの特定の名前変更を無視します(ただし、ユーザーに警告します)。

多くのテストを見ることができますがt/t6043-merge-rename-directories.sh、それはまたそれを指摘しています:

  • a)名前の変更によってディレクトリが他の2つ以上に分割される場合、最も多くの名前が変更されたディレクトリが「優先」されます。
  • b)パスがマージのいずれかの側で名前変更のソースである場合、パスのdirectory-rename-detectionを回避します。
  • c)履歴の反対側が名前の変更を行う側である場合にのみ、暗黙のディレクトリ名変更をディレクトリに適用します。

15

目的

  • 使用(からインスピレーションを得たSMARから借り、Exherbogit am
  • コピー/移動したファイルのコミット履歴を追加する
  • あるディレクトリから別のディレクトリへ
  • または、あるリポジトリから別のリポジトリへ

制限

  • タグとブランチは保持されません
  • パスのファイル名の変更(ディレクトリの名前変更)で履歴が削除される

概要

  1. を使用して履歴を電子メール形式で抽出する
    git log --pretty=email -p --reverse --full-index --binary
  2. ファイルツリーを再編成し、ファイル名を更新する
  3. を使用して新しい履歴を追加
    cat extracted-history | git am --committer-date-is-author-date

1.履歴をメール形式で抽出する

例:file3file4およびの履歴を抽出するfile5

my_repo
├── dirA
│   ├── file1
│   └── file2
├── dirB            ^
│   ├── subdir      | To be moved
│   │   ├── file3   | with history
│   │   └── file4   | 
│   └── file5       v
└── dirC
    ├── file6
    └── file7

目的地を設定/削除する

export historydir=/tmp/mail/dir       # Absolute path
rm -rf "$historydir"    # Caution when cleaning the folder

各ファイルの履歴をメール形式で抽出する

cd my_repo/dirB
find -name .git -prune -o -type d -o -exec bash -c 'mkdir -p "$historydir/${0%/*}" && git log --pretty=email -p --stat --reverse --full-index --binary -- "$0" > "$historydir/$0"' {} ';'

残念ながらオプション--followまたは--find-copies-harderと組み合わせることはできません--reverse。これが、ファイルの名前が変更されたとき(または親ディレクトリの名前が変更されたとき)に履歴が削除される理由です。

電子メール形式の一時的な履歴:

/tmp/mail/dir
    ├── subdir
    │   ├── file3
    │   └── file4
    └── file5

Dan Bonacheaは、最初のステップでgit log生成コマンドのループを反転させることをお勧めします。ファイルごとにgit logを1回実行するのではなく、コマンドラインにファイルのリストを指定して1回だけ実行し、単一の統合ログを生成します。この方法では、複数のファイルを変更するコミットは結果の単一のコミットのままであり、すべての新しいコミットは元の相対順序を維持します。(今は統合された)ログのファイル名を書き換える場合は、次の2番目のステップで変更が必要になることに注意してください。


2.ファイルツリーを再編成してファイル名を更新する

これら3つのファイルをこの別のリポジトリ(同じリポジトリにすることもできます)に移動するとします。

my_other_repo
├── dirF
│   ├── file55
│   └── file56
├── dirB              # New tree
│   ├── dirB1         # from subdir
│   │   ├── file33    # from file3
│   │   └── file44    # from file4
│   └── dirB2         # new dir
│        └── file5    # from file5
└── dirH
    └── file77

したがって、ファイルを再編成します。

cd /tmp/mail/dir
mkdir -p dirB/dirB1
mv subdir/file3 dirB/dirB1/file33
mv subdir/file4 dirB/dirB1/file44
mkdir -p dirB/dirB2
mv file5 dirB/dirB2

一時的な履歴は次のとおりです:

/tmp/mail/dir
    └── dirB
        ├── dirB1
        │   ├── file33
        │   └── file44
        └── dirB2
             └── file5

履歴内のファイル名も変更します。

cd "$historydir"
find * -type f -exec bash -c 'sed "/^diff --git a\|^--- a\|^+++ b/s:\( [ab]\)/[^ ]*:\1/$0:g" -i "$0"' {} ';'

3.新しい履歴を適用する

あなたの他のリポジトリは:

my_other_repo
├── dirF
│   ├── file55
│   └── file56
└── dirH
    └── file77

一時履歴ファイルからコミットを適用します。

cd my_other_repo
find "$historydir" -type f -exec cat {} + | git am --committer-date-is-author-date

--committer-date-is-author-date元のコミットのタイムスタンプを保持します(Dan Bonacheaのコメント)。

あなたの他のリポジトリは今です:

my_other_repo
├── dirF
│   ├── file55
│   └── file56
├── dirB
│   ├── dirB1
│   │   ├── file33
│   │   └── file44
│   └── dirB2
│        └── file5
└── dirH
    └── file77

git statusプッシュする準備ができているコミットの量を確認するために使用します:-)


追加のトリック:リポジトリ内で名前が変更されたファイルや移動されたファイルを確認する

名前が変更されたファイルを一覧表示するには:

find -name .git -prune -o -exec git log --pretty=tformat:'' --numstat --follow {} ';' | grep '=>'

その他のカスタマイズ:git logオプション--find-copies-harderまたはを使用してコマンドを完了することができます--reversecut -f3-完全なパターン '{。* =>。*}' を使用して最初の2つの列を削除することもできます。

find -name .git -prune -o -exec git log --pretty=tformat:'' --numstat --follow --find-copies-harder --reverse {} ';' | cut -f3- | grep '{.* => .*}'

4
注意:この手法は、2つ以上のファイルを変更するコミットを個別のフラグメント化されたコミットに分割し、さらにファイル名でソートすることによって順序をスクランブルします(そのため、元の1つのコミットのフラグメントが線形履歴に隣接して表示されません)。したがって、結果の履歴はファイルごとにのみ「正しい」ものです。複数のファイルを移動する場合、結果の履歴の新しいコミットのNONEは、元のリポジトリの履歴に存在していた移動されたファイルの一貫したスナップショットを表します。
Dan Bonachea

2
こんにちは@DanBonachea。興味深いフィードバックをありがとうございます。この手法を使用して、いくつかのファイルを含むいくつかのリポジトリを正常に移行しました(名前を変更したファイルやファイルをディレクトリ間で移動した場合でも)。この回答を変更するために何を提案しますか。この回答の上部に、この手法の制限を説明する警告バナーを追加する必要があると思いますか?乾杯
olibre

2
ステップ1でgit log generationコマンドのループを反転させることで問題を回避するために、この手法を採用しました。ファイルごとに1回git logを実行するのではなく、コマンドラインでファイルのリストを指定してgit logを1回だけ実行し、単一の統合ログを生成します。この方法では、2つ以上のファイルを変更するコミットは結果の単一のコミットのままであり、すべての新しいコミットは元の相対順序を維持します。(今は統合された)ログのファイル名を書き換える場合も、手順2で変更が必要になることに注意してください。また、git am --committer-date-is-author-dateを使用して、元のコミットタイムスタンプを保持しました。
Dan Bonachea

1
実験と共有をありがとうございます。他の読者のために、答えを少し更新しました。しかし、私はあなたの処理をテストするのに時間をかけました。コマンドラインの例を提供したい場合は、この回答を自由に編集してください。乾杯;)
olibre 2016

4

このマルチステッププロセスに従って、コードを親ディレクトリに移動し、履歴を保持しました。

ステップ0:保管のために「master」からブランチ「history」を作成しました

ステップ1:git-filter-repoツールを使用して履歴を書き換えます。以下のこのコマンドは、フォルダー 'FolderwithContentOfInterest'を1レベル上に移動し、関連するコミット履歴を変更しました

git filter-repo --path-rename ParentFolder/FolderwithContentOfInterest/:FolderwithContentOfInterest/ --force

ステップ2:この時までに、GitHubリポジトリはリモートリポジトリパスを失いました。リモート参照を追加

git remote add origin git@github.com:MyCompany/MyRepo.git

ステップ3:リポジトリーの情報をプルする

git pull

手順4:ローカルの失われたブランチを元のブランチに接続する

git branch --set-upstream-to=origin/history history

手順5:メッセージが表示された場合、フォルダー構造のマージの競合に対処する

ステップ6:プッシュ !!

git push

注:変更された履歴と移動されたフォルダーは、既にコミットされているようです。 enter code here

できました。コードは親/目的のディレクトリに移動し、履歴はそのまま残ります!


2

GitのコアであるGit配管は名前の変更を追跡しませんが、Gitログ「磁器」で表示する履歴は、必要に応じてそれらを検出できます。

指定git logされた-Mオプションを使用します。

git log -p -M

Gitの現在のバージョン。

これは、他のコマンドでgit diffも同様に機能します。

比較を多少厳密にするオプションがあります。同時にファイルに大幅な変更を加えずにファイルの名前を変更すると、Gitログや友人が名前の変更を検出しやすくなります。このため、あるコミットでファイルの名前を変更し、別のコミットでファイルを変更する人もいます。

Gitにファイルの名前が変更された場所を見つけるように頼むときはいつでも、CPUの使用にコストがかかるため、それを使用するかどうか、いつ使用するかはあなた次第です。

特定のリポジトリの名前変更検出を使用して常に履歴を報告したい場合は、以下を使用できます。

git config diff.renames 1

あるディレクトリから別のディレクトリに移動するファイル検出されます。次に例を示します。

commit c3ee8dfb01e357eba1ab18003be1490a46325992
Author: John S. Gruber <JohnSGruber@gmail.com>
Date:   Wed Feb 22 22:20:19 2017 -0500

    test rename again

diff --git a/yyy/power.py b/zzz/power.py
similarity index 100%
rename from yyy/power.py
rename to zzz/power.py

commit ae181377154eca800832087500c258a20c95d1c3
Author: John S. Gruber <JohnSGruber@gmail.com>
Date:   Wed Feb 22 22:19:17 2017 -0500

    rename test

diff --git a/power.py b/yyy/power.py
similarity index 100%
rename from power.py
rename to yyy/power.py

これは、だけでなく、diffを使用しているときはいつでも機能することに注意してくださいgit log。例えば:

$ git diff HEAD c3ee8df
diff --git a/power.py b/zzz/power.py
similarity index 100%
rename from power.py
rename to zzz/power.py

試用として、機能ブランチの1つのファイルに小さな変更を加えてコミットし、次にマスターブランチでファイルの名前を変更してコミットし、ファイルの別の部分に小さな変更を加えてコミットしました。機能ブランチに行ってマスターからマージすると、マージによりファイルの名前が変更され、変更がマージされました。これはマージからの出力です:

 $ git merge -v master
 Auto-merging single
 Merge made by the 'recursive' strategy.
  one => single | 4 ++++
  1 file changed, 4 insertions(+)
  rename one => single (67%)

その結果、ファイルの名前が変更され、両方のテキストが変更された作業ディレクトリができました。したがって、Gitは明示的に名前変更を追跡しないにもかかわらず、Gitが正しいことを行うことができます。

これは古い質問への回答が遅いため、他の回答はその時点のGitバージョンでは正しかった可能性があります。


1

まず、名前を変更するだけでスタンドアロンコミットを作成します。

次に、ファイルの内容に対する最終的な変更は、個別のコミットに入れられます。


1

ディレクトリまたはファイルの名前を変更するには(私は複雑なケースについてあまり知らないので、いくつかの注意事項があるかもしれません):

git filter-repo --path-rename OLD_NAME:NEW_NAME

それを言及しているファイルのディレクトリの名前を変更するには(コールバックを使用することは可能ですが、方法がわかりません):

git filter-repo --replace-text expressions.txt

expressions.txtのような行で満たされたファイルですliteral:OLD_NAME==>NEW_NAME(PythonのREを使用しregex:たり、グロブを使用したりすることが可能ですglob:)。

コミットのメッセージでディレクトリの名前を変更するには:

git-filter-repo --message-callback 'return message.replace(b"OLD_NAME", b"NEW_NAME")'

Pythonの正規表現もサポートされていますが、Pythonで手動で記述する必要があります。

リポジトリがリモートなしのオリジナルの場合、--force強制的に書き換えて追加する必要があります。(これを行う前に、リポジトリのバックアップを作成することをお勧めします。)

refを保持したくない場合(それらはGit GUIのブランチ履歴に表示されます)、を追加する必要があります--replace-refs delete-no-add


0

ファイル移動し、次のようにステージングするだけです

git add .

コミットする前に、ステータスを確認できます。

git status

それが表示されます:

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        renamed:    old-folder/file.txt -> new-folder/file.txt

Gitバージョン2.26.1でテストしました。

GitHubヘルプページから抽出。


-3

ファイルを移動させてから

git add -A

これにより、削除されたすべての新しいファイルがサテージング領域に配置されます。ここでgitはファイルが移動されたことを認識します。

git commit -m "my message"
git push

理由はわかりませんが、これでうまくいきます。


ここでの秘訣は、1文字を変更する必要がないことです。何かを変更してCtrl + Zを押しても、履歴は壊れます。その場合、SOを書き込んだ場合、ファイルを元に戻し、もう一度移動して、1つのadd-> commitを実行します。
Xelian 2017年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.