バージョン管理で.emacsおよび.emacs.dを保持する場合、何をすべきか、すべきではありませんか？

多くの人々と同様に、私は多くのドットファイルをバージョン管理リポジトリ（Bitbucket上のMercurial、私の場合はプライベート）を介して管理しています。これは、新しいマシンをセットアップしたり、異なるマシン間で構成を伝播したりするときに便利です。

だから、当然、私は私のコメントを追加.emacsして.emacs.d、このセットアップに。

次に、いくつかのパッケージをインストールし、Pythonリポジトリからファイルを省略したように、に追加*.elcしました。.hgignore*.pyc

私が追跡するべきではない他のもの、たとえば、環境固有であり、別のプラットフォームにクローンを作成したときに役に立たない/正しくない生成ファイルはありますか？（デスクトップではLinuxとOS Xを使用し、サーバーではFreeBSDを使用しています。）

この種の共有をより価値のあるものにするために一般的に使用されるセットアップのトリックはありますか？シェルファイルのセットアップでは、たとえばブランチ間で個々のファイルをチェリーピックするための良い方法を探しています。

Emacsの設定をGithubに保存するのは、職場と自宅の2台の異なるコンピューターを使用しているためです。

以下は、ソース管理に入れないものについてのリストです。

環境指定のセットアップ。

たとえば、私のEmacsは異なるマシンで起動時に異なるorgファイルを開きます。これらの設定をソース管理にコミットする必要はありません。

(require 'local nil t)これらの設定をロードするために使用しますが、コミットすることはありませんlocal.el。

パッケージマネージャーによって管理されるパッケージ

パッケージがパッケージマネージャーによって管理されている場合、それらのパッケージをソース管理に入れないことをお勧めします。なぜなら：

1. 更新のたびにコミットする必要があります。
2. 他の場所に保存されている重要なファイルを見逃す可能性があり、異なるコンピューター間で適切に同期できなくなります。

パッケージをコミットする代わりに、パッケージマネージャーが認識したメカニズムをコミットすることをお勧めします。

たとえば、Caskを使用して3番目のパッケージを管理するため、指定したパッケージを含むcaskファイルのみをコミットします。

package.el前に使用するとき、私の構成はパッケージがインストールされているか、更新する必要があるかどうかを確認するため、パッケージはコミットされません。

ただし、パッケージリポジトリに存在しないパッケージがいくつかあります。この場合は、などのソース管理にコミットしsite-lispます。

パッケージによって生成されたすべてのファイル

たとえば、すべての自動保存、バックアップファイル、tramp、eshell、recentf、でもcustom.el。これらのファイルをに入れた~/.emacs/.genので、このディレクトリを無視できます。

頻繁に変更されるが、同期が必要なファイル

などで使用される個人辞書ファイルなど、などで使用されるaspellファイルデータベースelfeedこれらの場合、Dropboxを使用して異なるコンピューター間で同期します。だから私はコミットすることを忘れないでしょう。

生成されたもの（@ rangi-lin notesなど）がレポにないことを確認してください。他のユーザーとドットファイルを共有している場合は、関連するセキュリティ（パスワードやAPIキーなど）もありません。後で、カスタマイズを次のように別のファイルに分割しました。

(setq custom-file (concat dotfiles-dir "custom.el"))
(load custom-file 'noerror)

時々setq、上記のスニペットの前に「安全な」カスタマイズを大きなステートメントに移動します。

私の.gitignoreファイルは次のようになります。

/.org-id-locations
/ac-comphist.dat
/auto-save-list
/custom.el
/elpa/*
/image-dired/
/oauth2.plstore
/session.*
/tramp
/url/
/var/
*.elc

tl; dr

• .emacs.d/init.el代わりに使用する.emacs
• あなた.gitignoreのホワイトリストを作ります
• パッケージマネージャーを使用する

.emacs.d / init.el

このセットアップではgitの下に置くことができるため、.emacs.d/init.el代わりに使用し.emacsます.emacs.d。これ~/.emacsにより、gitリポジトリへのシンボリックリンクを作成したり、ホームディレクトリにgitリポジトリを作成したりできます。を使用すると.emacs.d、すべてが解決されます。

.gitignore

私の.gitignoreは、デフォルトのブラックリストではなくホワイトリストです。

*

!.gitignore
!init.el

この構成により、不要なものではなく、本当に必要なものに集中することができます。 .emacs.dソースコードリポジトリとは異なります。つまり、コードが存在するだけでなく、他のすべての自動生成ファイルまたは一時ファイルもそこに保存されます。あなたは本当に何が入るかわからないので、「デフォルトですべてを無視し、気にするファイルを追加する」のがより良い戦略、IMOです。

ところで、init.elマルチファイルスキームを使用する代わりに、ほとんどの設定をに保存します。その理由は、大きなファイルを使用すると、a）のような標準ツールを使用したり、希望する構成に移動しoccurたりisearch-forward、b）-ableを使用outshineしたりinit.el org-cycle、c）.gitignore常に変更したりできなくなるためです。

パッケージマネージャー

すべてのシステムでEmacsバージョンまたはパッケージバージョンを同期する特別なニーズがない限り、パッケージをgitの下に置かないでください。 Package.el結構です。 use-packageでも大丈夫です。カスクはいいです。パッケージマネージャーを選択し、構成ファイルのみをコミットし、パッケージ自体はコミットしません。

すなわち。私が考えることができる特別なニーズの1つは、開発と展開の2つのシステムを持ち、それらがまったく同じEmacs構成を持たなければならないことです。

.hgignoreには次のものがあります

• emacsサーバーファイル
• recentfファイル：あるマシン上のファイルパスは別のマシンでは意味がありません
• elpa / melpaディレクトリ：initファイルを使用して、必要なパッケージを自動的にインストールし、プル/プッシュ時間を節約します。

initを他のユーザーと共有する場合は、savehistモードで作成された履歴ファイルなどの履歴ファイルを削除することを検討してください。それとは別に、これには特別なトリックはないと思います。コードプロジェクトのバージョン管理に関して従うガイドラインは、ここでもうまく機能します。

時間の経過とともにパッケージは多くのものを追加し、~/.emacs最終的に私のパッケージにそれらを1つずつ追加することになります.gitignore。また、private.elパスワード、マシン固有のコードなどが含まれていますが、追跡できません。

これは私が今持っているものです。

# Gitignore file

# Remove backup files
*#
*.
*.elc
*~
.#*

# Emacs packages
elpa/
var/

#  Emacs tmp files & Misc
/.mc-lists.el
/.DS_Store
/.emacs.desktop
/.emacs.desktop.lock
/.watsonresults
/ac-comphist.dat
/auto-save-list
/eshell/history
/eshell/lastdir
/newsticker/feeds/
/snippets/
/tramp
/url/cookies
/.python-environments/
/ido.last
/places
/private.el
/games/
/bookmarks
/projectile-bookmarks.eld
/projectile.cache

使用するパッケージ/機能に依存するため、注意が必要です。Vamsiで言及されているファイルのほかに、たとえば、dired-immageを使用する場合、サムネイルをキャッシュするためのディレクトリがそこに作成されます。.elcファイルも無視したいでしょう。

.emacs.dを公開しますが、プライベートな変更（パスワードなど）でサブリポジトリを使用します。他の人がクローンを作成できるように、デフォルトのブランチはプレースホルダーのサブリポジトリを指し、すべてのマシンには独自の名前付きブランチがあります。

マシン間でマージする場合、最初graftに新しい変更をdefaultブランチに追加し、次にdefaultブランチを他の職場ブランチにマージします。

例として、私の.emacs.d をbitbucketで見つけることができます。これには、短い使用ガイドが記載されたreadmeが含まれます。

組織モードのマージドライバーをこのセットアップに追加することもできます。

数回の反復の後、コードの共有と変更の追跡にはバージョン管理は優れていますが、急速に変化する構成をコンピューター間で同期するための優れたソリューションではないと判断しました。その理由は、多くのものがあるということであるべきで同期さとはならない、バージョン管理であることを。いくつかの例：

1. .elcファイル（構成の変更があった場合に再コンパイルするのは大きな面倒であり、古いelcファイルのバグはデバッグするのが面倒です）。
2. elpaディレクトリ全体（およびバージョン固定が標準になるまで、ディレクトリの自動再構築は信頼性が十分ではありません）。
3. eshell履歴やgnusファイルなどの自動生成されたファイル。
4. パスワードやAPIキーなどの個人情報。

（クロスプラットフォームの問題はリストに含まれていないことに注意してください。複数のオペレーティングシステムで機能する1つの構成があれば問題ありません。）同期ソリューションとしてgitを使用する代わりに、コード追跡ソリューションとしてのみ使用しますDropboxを使用して同期します。そうすれば、バージョン管理下にあるべきではないすべての迷惑なファイルが処理されます。

私はない、しかし、私のDropboxの設定が何らかの理由で消えたので、私はすべてのインストール済みパッケージを追跡し、その他もろもろソースであれば、私の設定は、ソースからrebuildableも持つという目標を持っています。私の個人情報もgitサブモジュールに保存されます。しかし、日々の同期には、gitは優れたソリューションではありません。