6

現在の作業コピーのすべてをステージング解除したいのですが、今後編集するすべてのファイルとハンクを自動的にステージングします。

たとえば、私が取り組んでいるプロジェクトでは、他のほとんどの人とは異なるバージョンの CocoaPods を使用しています。CocoaPods を壊すことなく、CocoaPods と互換性があるように構成ファイルの構成をアップグレードしたいと考えています。これを行う最も簡単な方法は、プル リクエストに新しい構成を含めないことですが、それではビルドできません。構成を編集した後に隠してから変更を適用すると、ポップすると構成は修正されますが、変更が取り消されるため、スタッシュとポップは機能しません。

これを修正するにはどうすればよいですか?

4

2 に答える 2

3

1 つの方法は、ローカルでのみ表示されるように構成ファイルを変更することです。
ただし、そのレポの他のユーザーには見えない方法で。

これらの変更が適切に定義されている場合 (および のすべての場所ではない場合) 、チェックアウト時にその構成ファイルの適切なコンテンツを生成するために、コンテンツ フィルター ドライバーyour.config.fileを検討できます。

  • 宣言your.config.file内のファイルに関連付けられたスマッジ スクリプトを追加します。.gitattributes

    your.config.file filter=filterconfig

（ローカルリポジトリのルートフォルダーでファイルを編集または作成し、.gitattributesその中に上記の行を追加します。そのファイルを追加、コミット、およびプッシュできます。他のユーザーには影響しません）。

にじみ
(「 Git のカスタマイズ - Git 属性」の画像、「Pro Git book」の画像)

cd /path/to/your/local/cloned/repo
git config filter.filterconfig.smudge 'update_config'
git config filter.filterconfig.clean 'restore_config'

update_configおよびスクリプトは、ローカルのrestore_configどこにでも配置できます$PATH(これらは mingw git bash によって実行されるため、Windows を使用している場合でも bash にあります)。

update_configスクリプトは次のようになります。

  • 設定ファイルの最初のコピーを作成し、
  • その変更を構成ファイルに挿入します。

そうgit pullすれば、作業ツリーの更新をトリガーする は、必要なローカル変更を含む構成ファイルの内容を自動的に再生成します。

また、restore_configスクリプトは、git によって呼び出されるたびに、保存されたファイルのコピーを復元します (たとえば、 agit statusまたは aによってトリガーさgit diffれます)。

cat saved_copy

そうすれば、gitに関する限り、構成ファイルは決して変更されないように見えます。

于 2016-04-16T19:56:00.993 に答える
2

私が使用してきた戦略は、2 つのブランチを使用することです。1 つはパブリックなブランチで、もう 1 つはマシンから離れず、構成の変更を含むブランチです。

開発を行うときは、プライベート ブランチをチェックアウトしますが、コミットはしません。変更に満足したら、それらを隠し、パブリック ブランチをチェックアウトしgit stash pop、 を実行して、結果をコミットします。その後、プライベート ブランチに戻り、新しいコミットをマージします。結果の履歴は次のようになります。

*   (HEAD->private) merge
|\
| * (public) commit 3
* | merge
|\|
| * commit 2
* | a change in your local configuration
* | merge
|\|
| * commit 1
* | some private configuration changes
 \|
  * some base commit

ここで、ブランチの履歴をグラフにすると、次のpublicようになります。

* (public) commit 3
* commit 2
* commit 1
* some base commit

ご覧のとおり、構成に対するローカルの変更に依存するパブリック コミットはなく、パブリック ヒストリーを構成変更からクリーンに保ちます。ただし、構成の変更は完全にバージョン管理されているため、任意のマージ コミットに戻ってビルドできることを確認できます。

もちろん、これの代償は、ブランチを絶えず変更する手間です。そのため、このような構造はできる限り避けますが、状況によっては役立つ場合があります。

于 2016-04-16T20:02:48.880 に答える