작업 공간 도구

외부 편집기

Git 클라이언트는 코드를 읽는 곳이지, 고치는 곳인 경우는 드물어요. diff에서 문제를 발견한 순간과 편집기에서 그 줄에 커서를 두는 순간 사이에는 파일 검색과 스크롤이 놓여 있어요 — 매번요.

Gitcito에 편집기를 한 번 지정해 두면 그 틈이 사라져요. 파일 화면이나 blame 화면 에서 줄을 오른쪽 클릭하면 바로 그 줄에서 열려요.

편집기 고르기

설정 → 일반 → 외부 편집기. 드롭다운에는 Gitcito가 이 컴퓨터에서 찾아낸 편집기가 나열돼요 — 먼저 각 편집기의 명령을 찾고, macOS에서는 그다음 /Applications 와 ~/Applications 의 애플리케이션 번들을 찾아요. 이 검색은 설정을 열 때마다 실행되므로, 5분 전에 설치한 편집기도 재시작 없이 나타나요.

기본으로 인식하는 것들:

편집기 찾는 명령
Visual Studio Code code, code-insiders
Cursor cursor
Windsurf windsurf
Zed zed
Sublime Text subl
JetBrains IDE idea, webstorm, pycharm, rustrover, goland, clion, rider, phpstorm
Xcode xed

알아 둘 만한 한계

줄로 바로 이동하려면 편집기의 아이콘이 아니라 명령이 필요해요. macOS의 .app 번들은 open 을 통해 실행되는데, open 은 경로만 받고 그 외에는 아무것도 받지 않아요 — 그래서 번들로만 발견된 편집기는 파일을 맨 위에서 열고, Gitcito는 아닌 척하는 대신 드롭다운 아래에 그 사실을 알려 줘요.

해결책은 편집기 쪽에 있어요. VS Code의 Shell Command: Install 'code' command in PATH, Sublime의 subl 심볼릭 링크, JetBrains의 Toolbox → Settings → Shell scripts 같은 것들이요. 명령이 생기고 나서 편집기를 다시 고르면 줄 이동이 작동해요.

동작이 나타나는 곳

화면 무엇이 열리나
저장소 탭, 사이드바 저장소, 상태 표시줄 저장소 폴더
파일 트리, 커밋 파일, 스태시 파일, 커밋 작성기 그 파일
파일 트리의 행 끝 아이콘 그 파일을, 클릭 한 번으로
파일 화면에서 줄 오른쪽 클릭 그 파일을, 그 줄에서
blame 화면에서 줄 오른쪽 클릭 그 파일을, 그 줄에서
파일 트리의 .xcodeproj 등 패키지 해당 패키지를, 그것을 담당하는 앱에서

줄 단위 동작은 줄 번호가 여전히 의미를 갖는 곳에서만 나타나요. 예전 커밋 시점의 파일이나, 이전 리비전으로 되감은 blame은 디스크에 있는 내용과 더 이상 맞지 않는 줄을 갖고 있어요. 그래서 Gitcito는 엉뚱한 곳으로 보내는 대신 그런 자리에서는 이동을 제안하지 않아요.

Xcode 프로젝트와 그 밖의 패키지

MyApp.xcodeproj는 디렉터리입니다. Git도 알고 파일 트리도 알고 있었습니다 — 그게 거슬리기 시작하기 전까지는. 펼쳐서 project.pbxproj, project.xcworkspace, 그리고 xcuserdata 아래 개발자별 폴더를 찾는 일은, 어차피 손으로 편집할 생각이 없던 것에 대한 클릭 세 번의 소음입니다.

이제 이들은 패키지 아이콘으로 표시되고 행을 클릭하면 패키지가 열립니다 — Finder에서 더블클릭할 때와 같습니다. 화살표는 그대로 있으니, project.pbxproj가 정말 필요한 그 한 번 — 거의 언제나 병합 충돌입니다 — 은 예전처럼 안으로 들어가면 됩니다.

인식하는 것: .xcodeproj, .xcworkspace, .xcframework, .framework, .app, .appex, .dSYM, .playground, .xcuserdatad.

의도적으로 인식하지 않는 것: .xcassets와 .lproj. 이들도 패키지지만 안의 파일을 실제로 편집하기 때문에, 접어 버리면 얻는 것보다 잃는 것이 큽니다.

한계

패키지는 편집기가 아니라 시스템이 엽니다. 텍스트 편집기에 .xcodeproj를 넘기면 property list가 든 폴더로 열리는데, 클릭한 사람이 원한 건 그게 아닙니다. 그래서 Gitcito는 OS가 연결해 둔 프로그램에 넘깁니다. Xcode가 설치된 Mac이라면 Xcode죠. 편집기 설정은 그대로이며 일반 파일에는 계속 적용됩니다.

이것은 파일 시스템 플래그가 아니라 이름 규약입니다. Gitcito는 확장자를 보므로 우연히 notes.app이라고 이름 지은 디렉터리도 접히고, 이들이 평범한 폴더인 Linux나 Windows에서는 클릭하면 IDE 대신 파일 관리자가 열립니다.

나만의 명령

표에 없는 것이라면 사용자 지정 명령을 고르세요 — 래퍼 스크립트, 원격 개발 실행기, 직접 만든 심 스크립트로 띄우는 터미널 편집기 같은 것들이요.

항목 뜻
명령 실행할 실행 파일. 셸을 거치지 않으므로 &&, 파이프, 글로브는 쓸 수 없어요.
이름 메뉴 항목에서 부를 이름.
파일용 인자 argv 템플릿, 예: -g {path}:{line}:{col}
폴더용 인자 argv 템플릿, 보통은 {path} 하나

템플릿은 공백으로 나뉘고 각 토큰은 한 번만 치환돼요 — 공백이 든 경로도 하나의 인자로 남고, 그 뒤로 다시 파싱되지 않으므로 파일 이름이 문법으로 변할 일은 결코 없어요. 자리 표시자는 네 개예요. {path}, {line}, {col}, {repo}.

값이 없는 자리 표시자는 자기 플래그까지 함께 데리고 사라져요. --line {line} {path} 를 줄 번호 없이 실행하면 경로만 남고, 파일 이름을 자기 인자로 삼켜 버릴 덩그러니 남은 --line 은 생기지 않아요. 템플릿에 {line} 이 없다면 Gitcito가 그 편집기에 대해서는 줄 단위 동작을 제공하지 않는다는 뜻일 뿐이에요.

이것이 아닌 것

이것은 "다음으로 열기" 앱 설정이 아니에요. 그쪽은 시스템 선택기를 띄우고 무엇이든 — 이미지, PDF, Finder의 폴더 — 여는 앱 하나를 기억해 둬요. 둘 중에서는 편집기가 더 구체적인 쪽이라, 둘 다 설정돼 있으면 파일 트리의 행 끝 아이콘은 편집기가 가져가요. 오른쪽 클릭 메뉴에는 둘 다 남아 있어요.

Gitcito가 스스로 편집기를 띄우는 일은 없고, Gitcito를 닫아도 편집기는 닫히지 않아요. 편집기는 독립된 프로세스로, 분리된 채 시작되니까요.

GitHub에서 이 번역 개선하기