버전 관리에서 .emacs 및 .emacs.d를 유지할 때 어떻게해야합니까?


66

많은 사람들처럼, 나는 버전 관리 저장소를 통해 많은 도트 파일을 관리합니다 (Mercurial on Bitbucket, 개인 경우). 새 시스템을 설정하거나 다른 시스템간에 구성을 전파 할 때 편리합니다.

그래서 자연스럽게 내 추가 .emacs하고 .emacs.d이 설정에.

그런 다음 파이썬 저장소에서 파일을 생략하는 것처럼 일부 패키지를 설치하고에 추가 *.elc했습니다 ..hgignore*.pyc

추적하지 말아야 할 다른 것들이 있습니까 (예 : 환경에 따라 다르며 다른 플랫폼에 복제 될 때 유용하지 / 정확하지 않은 생성 된 파일)? (저는 데스크탑에서 Linux 및 OS X를 사용하고 서버에서 FreeBSD를 사용합니다.)

이런 종류의 공유를보다 가치있게 만드는 데 일반적으로 사용되는 설정 트릭이 있습니까? 쉘 파일 설정을 사용하여 분기별로 개별 파일을 체리 픽 선택하는 좋은 방법을 찾고 있습니다.


참고로 아래 언급 한 내용에도 불구하고 모든 컴퓨터에서 동일한 emacs 버전을 사용하는 경우 Elpa 디렉토리를 동기화하는 것이 좋습니다.
— Malabarba

제외하지 마십시오 *.elc. stackoverflow.com/a/24539894/324105
— phils

답변:


37

직장과 집에 각각 다른 두 대의 컴퓨터를 사용하기 때문에 Emacs 구성을 Github에 저장합니다.

소스 컨트롤에 넣지 않은 것에 대한 목록은 다음과 같습니다.

환경 설정.

예를 들어, 내 Emacs는 다른 컴퓨터에서 시작할 때 다른 조직 파일을 엽니 다. 이 설정을 소스 제어에 적용하지 않으려 고합니다.

(require 'local nil t)이 설정을로드 하는 데 사용 하지만 커밋하지 마십시오 local.el.

패키지 관리자가 관리하는 패키지

패키지 관리자가 패키지를 관리하는 경우 해당 패키지를 소스 제어에 넣지 않는 것이 좋습니다. 때문에 :

  1. 모든 업데이트 후에 커밋해야합니다.
  2. 다른 곳에 저장되어있는 중요한 파일을 놓치면 다른 컴퓨터에서 제대로 동기화 할 수 없습니다.

커밋 패키지 대신 패키지 관리자가 인식 한 메커니즘 을 커밋하는 것이 좋습니다 .

예를 들어 Cask 를 사용 하여 세 번째 패키지를 관리하므로 원하는 지정된 패키지가 포함 된 cask 파일 만 커밋합니다.

package.el이전에 사용하면 구성에서 패키지가 설치 / 업데이트되어야하는지 확인하므로 패키지가 커밋되지 않습니다.

그러나 패키지 리포지토리에없는 일부 패키지가 있습니다.이 경우와 같이 소스 컨트롤에 커밋합니다 site-lisp.

패키지로 생성 된 모든 파일

예를 들어, 모든 자동 저장, 백업 파일, tramp, eshell, recentf,도 custom.el. 이 파일들을에 넣었 ~/.emacs/.gen으므로이 디렉토리를 무시해도됩니다.

자주 변경되지만 동기화되어야하는 파일

에 의해 사용되는 개인 사전 파일 aspell,에 의해 사용되는 파일 데이터베이스 elfeed,이 경우 Dropbox를 사용하여 다른 컴퓨터간에 동기화합니다. 그래서 나는 커밋하는 것을 잊지 않을 것입니다.


2
Cask에 대한 요점은 Windows가 아닌 Cask를 지원하는 컴퓨터에서만 작동하는 한 괜찮습니다.
— T. Verron

전체 패키지를 저장하지 않는 것이 좋습니다. 패키지 관리자가 작업을 수행하게하십시오.
— Rangi Lin

@ T.Verron 나는 Cygwin에서에 술통 작업을 할 수 있었다, 그러나 그것은 나에게 준 몇 가지 문제. BTW, 나는 지금 Emacs Prelude 를 사용하고 있으며,이 prelude-require-packages기능이 가난한 사람의 통처럼 작동 한다는 것을 알았습니다 (Windows에서도 작업 할 수 있다는 이점이 있음).
— rsenna

cygwin cask은 w32 emacs와 함께 작동합니까? 이 동작을 에뮬레이트하는 매크로와 관련하여 emacs.stackexchange.com/a/410/184 에 package-install언급 된 내장 기능 도 도움이 될 수 있습니다.
— T. Verron

2
@JorgeArayaNavarro 서로 다른 머신에서 동일하다면 커밋하는 것이 좋습니다. :) 그러나 그것은 내 경우가 아닙니다. 또한 자동으로 편집되기 때문에 언젠가 커밋하는 것을 잊어 버렸기 때문에 custom.el소스 컨트롤에 넣지 않습니다 .
— Rangi Lin

8

@ rangi-lin 메모와 같이 생성 된 항목이 저장소에 없는지 확인하고 다른 파일과 도트 파일을 공유하는 경우 관련 보안 항목 (예 : 비밀번호 및 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

8

tl; dr

  • .emacs.d/init.el대신에 사용.emacs
  • 당신 수 있도록 .gitignore화이트리스트를
  • 패키지 관리자를 사용하십시오

.emacs.d / init.el

이 설정을 사용하면 git 에 넣을 수 있기 때문에 .emacs.d/init.el대신에 사용 합니다 . 데이 당신 자식 저장소에 대한 심볼릭 링크를 만들거나 홈 디렉토리에서 자식의 repo를 할 수 있습니다. 를 사용 하면 모든 것이 해결됩니다..emacs.emacs.d~/.emacs.emacs.d

.gitignore

내 .gitignore는 기본 블랙리스트 대신 화이트리스트입니다.

*

!.gitignore
!init.el

이 구성을 사용하면 필요하지 않은 것 대신 실제로 필요한 것에 집중할 수 있습니다. .emacs.d소스 코드 저장소와는 다릅니다. 즉, 코드가 상주 할뿐만 아니라 다른 모든 자동 생성 또는 임시 파일도 존재합니다. 어떻게 될지 잘 모릅니다. 따라서 " 기본적으로 모두 무시하고 관심있는 파일 추가 "가 더 나은 전략 인 IMO입니다.

BTW, 나는 init.el다중 파일 체계를 사용하는 대신 대부분의 구성을에 유지 합니다. 그 이유는 큰 파일을 사용하여 a) 원하는 표준 구성 과 같은 표준 도구를 사용 occur하거나 isearch-forward원하는 구성으로 이동할 수 outshine있기 때문입니다.init.el org-cycle.gitignore

패키지 관리자

모든 시스템에서 Emacs 버전 및 / 또는 패키지 버전을 동기화해야하는 특별한 요구가 없다면 패키지를 git에 두지 마십시오. Package.el괜찮습니다. use-package또한 괜찮습니다. 통이 좋다. 패키지 관리자를 선택하고 구성 파일 만 커밋하고 패키지 자체는 커밋하지 마십시오.

즉. 제가 생각할 수있는 특별한 요구 사항 중 하나는 개발 및 배포라는 두 개의 시스템을 갖는 것이며 정확히 동일한 Emacs 구성을 가져야합니다.


init.el파일이 너무 커지지 않는 한 모든 파일 을 한 파일에 보관 하십시오. Emacs는 큰 파일을 다루는 데 좋지 않으며, 얼마 후에 큰 파일을 편집 할 때 크롤링을 시작합니다 init.el. 설정을 여러 파일로 분할 할 때의 또 다른 이점은 git에서 더 잘 재생된다는 것입니다. 특정 상황에서 단일 파일의 변경 사항을 병합 충돌로 간주 할 수는 있지만 변경 사항이 별도의 파일에있는 경우는 아닙니다. 마지막으로, init 파일의 큰 덩어리보다 단 하나의 요구 사항 만 주석 처리하는 것이 훨씬 쉽습니다.
— izkon

6

내 .hgignore에 다음과 같은 것들이 있습니다.

  • 이맥스 서버 파일
  • recentf 파일 : 한 시스템의 파일 경로가 다른 시스템에서 의미가 없습니다.
  • elpa / melpa 디렉토리 : init 파일을 사용하여 필요한 패키지를 자동으로 설치하고 풀 / 푸시 시간을 저장하십시오.

init를 다른 사람과 공유하려면 저장 파일 모드로 작성된 것과 같은 히스토리 파일을 제거하는 것이 좋습니다. 그 외에도 나는 이것에 특별한 트릭이 없다고 생각합니다. 버전 코드 프로젝트를 위해 따르는 모든 지침은 여기에서도 잘 작동합니다.


3

시간이 지남에 따라 패키지에는 많은 것들이 추가 ~/.emacs되고 결국 내 패키지에 하나씩 추가됩니다 .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

1

사용하는 패키지 / 기능에 따라 다르므로 까다로울 수 있습니다. 예를 들어, dired-immage를 사용하는 경우 Vamsi에서 언급 한 파일 외에도 축소판을 캐시 할 디렉토리가 생성됩니다. .elc 파일도 무시하고 싶을 것입니다.


1

내 .emacs.d를 게시하지만 개인 변경 사항 (암호 등)과 함께 하위 저장소를 사용합니다. 다른 사람이 복제 할 수 있도록 기본 분기는 자리 표시 자 하위 리포지토리를 가리키고 모든 컴퓨터에는 자체 명명 된 분기가 있습니다.

기계 사이를 병합 할 때 먼저 graft새로운 변경 사항을 default지점으로 가져온 다음 default지점을 다른 작업장 지점으로 병합합니다 .

예를 들어, 간단한 사용법 안내서와 함께 readme를 포함하여 bitbucket 에서 .emacs.d 를 찾을 수 있습니다 .

이 설정에 조직 모드 병합 드라이버 를 추가 할 수 있습니다 .


1

여러 번 반복 한 후에는 버전 제어가 코드를 공유하고 변경 내용을 추적하는 데 유용하지만 컴퓨터간에 빠르게 변경되는 구성을 동기화하는 데 적합한 솔루션은 아니라고 판단했습니다. 그 이유는 여러 가지가 있다는 것입니다 해야 동기화 및 안 버전 제어에있을가. 몇 가지 예 :

  1. .elc파일 (구성 변경이있을 때 다시 컴파일하는 것은 번거로운 일이며 오래된 elc파일의 버그 는 종종 디버깅하기가 어렵습니다).
  2. 전체 elpa디렉토리 (버전 고정이 표준이 될 때까지 자동으로 재 구축 할 수는 없습니다).
  3. eshell기록 및 gnus파일 과 같은 자동 생성 파일
  4. 비밀번호 및 API 키와 같은 개인 정보

크로스 플랫폼 문제는 목록에 포함되어 있지 않습니다. 여러 운영 체제에서 작동하는 하나의 구성을 사용하는 것이 좋습니다.) 동기화 솔루션으로 git을 사용하는 대신 코드 추적 솔루션으로 만 사용합니다. Dropbox를 사용하여 동기화합니다. 이렇게하면 버전 관리에 있어서는 안되는 모든 성가신 파일이 처리됩니다.

나는 않습니다 , 그러나 내 보관 용 구성이 어떤 이유에서 사라지면 내 구성이 소스에서 rebuildable 수있는의 목표를 가지고, 그래서 나는 모든 설치된 패키지와 이것 저것 소스의 추적합니다. 내 개인 정보는 git 하위 모듈에도 저장됩니다. 그러나 일상적인 동기화의 경우 git은 훌륭한 솔루션이 아닙니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.