소스 제어하에 있으면 안되는 것은 무엇입니까?
(대부분의 경우) 소스 제어하에 있으면 안되는 파일 및 / 또는 디렉토리에 대해 다소 완전한 목록을 갖는 것이 좋습니다. 무엇을 배제해야한다고 생각하십니까?
지금까지 제안 :
일반적으로
- 민감한 정보 (암호, 개인 키 등)가있는 구성 파일
- Thumbs.db, .DS_Store 및 desktop.ini
- 편집기 백업 : * ~ (emacs)
- 생성 된 파일 (예 : DoxyGen 출력)
씨#
- 큰 상자\*
- obj \ *
- * .exe
비주얼 스튜디오
- * .suo
- * .ncb
- *.사용자
- * .aps
- * .cachefile
- *.지원
- _UpgradeReport_Files
자바
- *.수업
식
모르겠습니다. 이것이 제가 지금 찾고있는 것입니다. :-)
파이썬
- * .pyc
임시 파일 -. *. sw? -* ~
생성되는 모든 것. XML에서 생성 된 바이너리, 바이트 코드, 코드 / 문서.
내 댓글 작성자에서 제외 :
- 코드 문서 (doxygen, javadoc, pydoc 등)를 포함하여 빌드에서 생성 된 모든 것
그러나 포함 :
- 당신이 소스를하지 않아도 3 자 라이브러리 또는 구축하지 않습니다.
FWIW, 매우 큰 프로젝트를 위해 작업 할 때 ClearCase 아래에 다음이 있습니다.
- 모든 원본 코드
- Qt 소스 및 빌드 된 디버그 / 릴리스
- (끔찍하게 구식) 사양
우리는 소프트웨어를위한 모듈을 구축하지 않았습니다. 완전한 바이너리는 최신 업데이트와 함께 2 주마다 배포됩니다.
같은 자신의 파일 브라우저에 의해 생성 된 OS의 특정 파일 Thumbs.db및.DS_Store
다른 Visual Studio 일반 파일 / 폴더는 다음과 같습니다.
*.cachefile
*.backup
_UpgradeReport_Files
예를 들어 내 거북이 전역 무시 패턴은 다음과 같습니다.
bin obj *.suo *.user *.cachefile *.backup _UpgradeReport_Files
빌드 된 파일은 체크인하지 않아야합니다.
마찬가지로 코리 D가 있다 고 말했다 생성되는 것도, 빌드 프로세스와 개발 환경에 의해 생성 된 좋은 후보입니다 특별히 아무것도. 예를 들면 :
- 바이너리 및 설치 프로그램
- 바이트 코드 및 아카이브
- XML 및 코드에서 생성 된 문서
- 템플릿 및 코드 생성기에 의해 생성 된 코드
- IDE 설정 파일
- IDE 또는 편집기에서 생성 된 백업 파일
위의 일부 예외는 다음과 같습니다.
- 이미지 및 비디오
- 타사 라이브러리
- 팀별 IDE 설정 파일
제 3 자 라이브러리를 가져 가십시오. 제공해야하거나 빌드가 제 3 자 라이브러리에 의존하는 경우, 특히 소스가없는 경우이를 소스 제어하에 두는 것이 합리적이지 않습니다. 또한 일부 소스 제어 시스템은 바이너리 Blob을 저장하는 데 그다지 효율적이지 않으며 해당 파일에 대한 시스템 차이 도구를 활용할 수 없을 수도 있습니다.
Paul 은 또한 생성 된 파일에 대해 훌륭한 댓글을 작성하고 있으며 그의 답변을 확인해야합니다 .
기본적으로 개발자가 필요한 정확한 도구의 정확한 버전을 가질 수 있다고 합리적으로 기대할 수없는 경우 생성 된 파일을 버전 제어에 넣는 경우가 있습니다.
궁극적으로 모든 것을 말 했으므로 사례별로 소스 제어하에 놓은 것을 고려해야합니다. 그 아래에 무엇을, 무엇을 넣지 말아야할지에 대한 엄격한 목록을 정의하는 것은 일부 사람들에게만 효과가있을 것이며 아마도 그렇게 오래 지속될 것입니다. 물론 소스 제어에 더 많은 파일을 추가할수록 작업 복사본을 업데이트하는 데 더 오래 걸립니다.
IDE, 빌드 프로세스 또는 바이너리 실행 프로세스에서 생성 할 수있는 모든 것.
나는 문제에 다른 방식으로 접근 할 것입니다. 소스 제어에 어떤 것이 포함 되어야 합니까? 다음과 같은 파일 만 소스 제어해야합니다.
- (업데이트 기록이 필요하거나 빌드 외부에서 생성되었지만 빌드, 설치 또는 미디어의 일부 임) 및
- 제어하는 빌드 프로세스에 의해 생성 될 수 없습니다.
- 제품을 빌드하는 모든 사용자에게 공통 (사용자 구성 없음)
The list includes things like:
- source files
- make, project, and solution files
- other build tool configuration files (not user related)
- 3rd party libraries
- pre-built files that go on the media like PDFs & documents
- documentation
- images, videos, sounds
- description files like WSDL, XSL
Sometimes a build output can be a build input. For example, an obfuscation rename file may be an output and an input to keep the same renaming scheme. In this case, use the checked-in file as the build input and put the output in a different file. After the build, check out the input file and copy the output file into it and check it in.
The problem with using an exclusion list is that you will never know all the right exclusions and might end up source controlling something that shouldn't be source controlled.
An exception:
4 or 5 different answers have said that generated files should not go under source control. Thats not quite true.
Files generated by specialist tools may belong in source control, especially if particular versions of those tools are necessary.
Examples:
- parsers generated by bison/yacc/antlr,
- autotools files such as configure or Makefile.in, created by autoconf, automake, libtool etc,
- translation or localization files,
- files may be generated by expensive tools, and it might be cheaper to only install them on a few machines.
Basically, if you can't reasonably expect a developer to have the exact version of the exact tool they need, there is a case for putting the generated files in version control.
This exception is discussed by the svn guys in their best practices talk.
Temp files from editors.
.*.sw?
*~
etc.
desktop.ini is another windows file I've seen sneak in.
Config files that contain passwords or any other sensitive information.
Actual config files such a web.config in asp.net because people can have different settings. Usually the way I handle this is by having a web.config.template that is on SVN. People get it, make the changes they want and rename it as web.config.
Aside from this and what you said, be careful of sensitive files containing passwords (for instance).
Avoid all the annoying files generated by Windows (thumb) or Mac OS (.ds_store)
*.bak produced by WinMerge.
additionally:
Visual Studio
- *.ncb
The best way I've found to think about it is as follows:
Pretend you've got a brand-new, store-bought computer. You install the OS and updates; you install all your development tools including the source control client; you create an empty directory to be the root of your local sources; you do a "get latest" or whatever your source control system calls it to fetch out clean copies of the release you want to build; you then run the build (fetched from source control), and everything builds.
This thought process tells you why certain files have to be in source control: all of those necessary for the build to work on a clean system. This includes .designer.cs files, the outputs of T4 templates, and any other artifact that the build will not create.
Temp files, config for anything other than global development and sensitive information
Things that don't go into source control come in 3 classes
- Things totally unrelated to the project (obviously)
- Things that can be found on installation media, and are never changed (eg: 3rd-party APIs).
- Things that can be mechanically generated, via your build process, from things that are in source control (or from things in class 2).
Whatever the language :
- cache files
- generally, imported files should not either (like images uploaded by users, on a web application)
- temporary files ; even the ones generated by your OS (like thumbs.db under windows) or IDE
- config files with passwords ? Depends on who has access to the repository
And for those who don't know about it : svn:ignore is great!
If you have a runtime environment for your code (e.g. dependency libraries, specific compiler versions etc.) do not put the packages into the source control. My approach is brutal, but effective. I commit a makefile, whose role is to downloads (via wget) the stuff, unpack it, and build my runtime environment.
I have a particular .c file that does not go in source control.
The rule is nothing in source control that is generated during the build process.
The only known exception is if a tool requires an older version of itself to build (bootstrap problem). In that case you will need a known good bootstrap copy in source control so you can build from blank.
Going out on a limb here, but I believe that if you use task lists in Visual Studio, they are kept in the .suo file. This may not be a reason to keep them in source control, but it is a reason to keep a backup somewhere, just in case...
A lot of time has passed since this question was asked, and I think a lot of the answers, while relevant, don't have hard details on .gitignore on a per language or IDE level.
Github came out with a very useful, community collaborated list of .gitignore files for all sorts of projects and IDEs that is worth taking a look.
Here's a link to that git repo: https://github.com/github/gitignore
To answer the question, here are the related examples for:
- C# -> see Visual Studio
- Visual Studio
- Java
- Eclipse
- Python
There are also OS-specific .gitignore files. Following:
So, assuming you're running Windows and using Eclipse, you can just concatenate Eclipse.gitignore and Windows.gitignore to a .gitignore file in the top level directory of your project. Very nifty stuff.
Don't forget to add the .gitignore to your repo and commit it!
Chances are, your IDE already handles this for you. Visual Studio does anyway.
And for the .gitignore files, If you see any files or patterns missing in a particular .gitignore, you can open a PR on that file with the proposed change. Take a look at the commit and pull request trackers for ideas.
I am always using www.gitignore.io to generate a proper one .ignore file.
Opinion: everything can be in source control, if you need to, unless it brings significant repository overhead such as frequently changing or large blobs.
3rd party binaries, hard-to-generate (in terms of time) generated files to speed up your deployment process, all are ok.
The main purpose of source control is to match one coherent system state to a revision number. If it would be possible, I'd freeze the entire universe with the code - build tools and the target operating system.
참고URL : https://stackoverflow.com/questions/1273921/what-should-not-be-under-source-control
'development' 카테고리의 다른 글
| New-WebAppPool을 사용할 때 .NET Framework 버전을 어떻게 설정합니까? (0) | 2020.12.08 |
|---|---|
| NUnit으로 app.config 파일 단위 테스트 (0) | 2020.12.07 |
| C #에서 log4net 로그 파일 가져 오기 (0) | 2020.12.07 |
| Rails에서 사용자 지정 유효성 검사 메서드 호출 (0) | 2020.12.07 |
| C ++의 꼬리 재귀 (0) | 2020.12.07 |