버전 관리에서 .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/184package-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.