디렉토리에있는 확장자의 모든 파일을 gitignore

답변:

123

절대로 그것을 시도,하지만 git help ignore당신이를 넣으면 제안 .gitignore과 *.js에서 /public/static, 당신이 원하는 것을 할 것입니다.

참고 : 아래에서 Joeys의 답변도 확인하십시오. 특정 하위 디렉토리의 파일을 무시하려면 로컬 .gitignore가 올바른 솔루션입니다 (지역성이 좋습니다). 그러나 전체 리포지토리에 동일한 패턴을 적용해야하는 경우 ** 솔루션이 더 좋습니다.

— ptyx
소스
19
최상의 솔루션은 필요하지 않습니다. 잠재적으로 사람들은 파일이 무시되는 이유를 찾기 위해 다른 .gitignore 파일을 파헤쳐 야합니다. 일부는이 모든 정보를 repo 루트 디렉토리에 저장된 하나의 .gitignore 파일에 저장하는 것을 선호합니다.
— haren
1
@ haren 유일한 해결책은 아닙니다. Joey의 답변도 확실히 유효합니다. 가장 적합한 것을 선택하십시오. 디렉토리에 대한 로컬 규칙은 해당 디렉토리에 있어야하며 전역 규칙은 전역이어야한다고 주장합니다. (또한이 답변은 고대이며 ** 당시에는 지원되지 않았다고 생각합니다).
— ptyx
211

**구문은 설명서 에 따라 git버전 1.8.2.1별로 지원되는 것으로 보입니다 .

**전체 경로 이름과 일치하는 패턴에서 두 개의 연속 별표 ( " ")는 특별한 의미를 가질 수 있습니다.

  • **슬래시가 앞에 오는 " "는 모든 디렉토리에서 일치 함을 의미합니다. 예를 들어, " **/foo" foo는 패턴 " foo" 과 동일한 위치에있는 파일 또는 디렉토리 " "와 일치합니다 . " **/foo/bar"는 " "디렉토리 bar바로 아래에있는 파일 또는 디렉토리 " "와 일치합니다 foo.

  • 후행 " /**"은 내부의 모든 항목과 일치합니다. 예를 들어, " abc/**"는 파일 abc의 위치를 ​​기준으로 디렉토리 " " 내의 모든 파일을 .gitignore깊이가 무한대로 일치시킵니다 .

  • 슬래시 다음에 두 개의 연속 별표가 오면 슬래시는 0 개 이상의 디렉토리와 일치합니다. 예를 들어 " a/**/b"는 " a/b", " a/x/b", " a/x/y/b"등과 일치 합니다.

  • 다른 별표는 유효하지 않은 것으로 간주됩니다.

— 조이호 어
소스
1
차이 무엇 xxx/**과 xxx/?
— thuzhf
9
xxx/**내부의 모든 파일과 디렉토리를 대상으로하는 xxx반면 디렉토리를 직접 xxx/대상으로합니다 xxx. 와 패턴을 부정 할 때 중요한 정말로 단지 !로 "그것은 할 수 없습니다 해당 파일의 상위 디렉토리를 제외하면 파일을 재-있습니다.", 사용 그래서 xxx/*또는 xxx/**경우에 필요하다.
— joeyhoer
4
.meta로 끝나는 모든 파일은 git에서 무시해야합니다. 어떻게 작동합니까? **.js?
— 블랙
"다른 연속 된 별표는 유효하지 않은 것으로 간주됩니다." 모두 합산
— imrok
68

업데이트 : @Joey의 대답을 살펴보십시오 : Git **은 패턴 의 구문을 지원합니다 . 두 방법 모두 잘 작동합니다.

gitignore (5) 매뉴얼 페이지 상태 :

경로와 동일한 디렉토리 또는 상위 디렉토리의 .gitignore 파일에서 읽은 패턴은 상위 레벨 파일 (작업 트리의 최상위 레벨까지)의 패턴이 디렉토리까지 하위 레벨 파일의 패턴으로 대체됩니다. 파일을 포함합니다.

이는 .gitignore리포지토리의 특정 디렉토리 에있는 파일 의 패턴 이 해당 디렉토리 와 모든 하위 디렉토리에 영향 을 미친다는 것을 의미 합니다 .

제공 한 패턴

/public/static/**/*.js

(올바르게 언급했듯이) **구문이 Git에서 사용되지 않기 때문에 옳지 않습니다. 또한 선행 /은 해당 패턴을 경로 이름의 시작 부분에 고정합니다. (따라서 /public/static/*.js일치 /public/static/foo.js하지는 않습니다 /public/static/foo/bar.js .) 행간 /을 제거해 도 public/static/foo.jsand 같은 경로를 사용할 수 없습니다 foo/public/static/bar.js. 편집 : 선행 슬래시를 제거해도 작동하지 않습니다-패턴에 여전히 슬래시가 포함되어 있기 때문에 Git은 평범한 비 재귀 셸 글로브로 처리합니다 ( @Joey Hoer에게 감사드립니다 ).

@ptyx가 제안했듯이 파일을 만들고이 <repo>/public/static/.gitignore패턴 만 포함하면됩니다.

*.js

Leading이 없으므로 /경로의 어느 부분에서나 일치하며 해당 패턴은 /public/static디렉토리 및 해당 서브 디렉토리의 파일에만 적용됩니다 .

— 아담 샤프
소스
2
"최고의 제거 특히 부분 - 이것은 완전히 사실이 아니다 /처럼 경로를 일치 중 하나가 작동하지 않습니다 public/static/foo.js와 foo/public/static/bar.js." 거짓입니다. 문서에 인용하기 위해 "패턴에 슬래시 (/)가 포함되어 있지 않은 경우, Git은 패턴을 쉘 glob 패턴으로 취급하고 .gitignore 파일의 위치를 ​​기준으로 경로 이름과 일치하는지 확인합니다 (작업 트리의 최상위 레벨에 상대적 .gitignore 파일이 아님) " foo/public/static/bar.js패턴에가 포함되어 있기 때문에 일치하지 않습니다 /.
— joeyhoer
@JoeyHoer 팁 덕분에 그에 따라 답변을 업데이트했습니다.
— Adam Sharp
9

추적되지 않은 파일을 무시하려면 .git / info / exclude로 이동하십시오. 제외는 무시 된 확장자 또는 파일 목록이있는 파일입니다.

— 티아고 라모스
소스
2
이것은 .gitignore처럼 (물론 커밋 된 후) 저장소의 다른 복제본으로 이어지지 않습니다.
— jpmc26
3

가장 간단한 해결책은 사용하는 것 find입니다. .gitignore하위 디렉토리에 여러 번 매달려 있는 것을 좋아하지 않으며 고유 한 최상위 레벨을 관리하는 것을 선호합니다 .gitignore. 이렇게하려면 찾은 파일을에 추가하면됩니다 .gitignore. 그것이 /public/static/당신의 프로젝트 / 자식이라고 가정하면 다음과 같은 것을 사용할 것입니다 :

find . -type f -name *.js | cut -c 3- >> .gitignore

./git이 어떤 파일을 피해야하는지 이해하려면 시작 부분 을 잘라내 는 것이 종종 필요 하다는 것을 알았습니다 . 따라서 cut -c 3-.

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