개인 관리의 경우 푸시를 하든 안 하든 상관이 없습니다. 어쨌든 구성 파일을 거의 변경하지 않는데, push 한 번씩 push 큰 차이는 없습니다.
그러나 다른 사람이 관련되어 있거나 push 여러 환경에 있을 수 있는 경우 push 구성 파일은 불필요한 충돌을 가져올 수 있습니다. 이때 구성 파일 이름이 다음과 같다고 가정하여 기본 구성 파일을 push 사용할 수 있습니다. config 이후 프로젝트를 처음 푸시할 때 먼저 config에 gitignore를 추가하고, config_example이 완료된 후 push도 기본 설정 정보가 담긴 config_example 파일을 푸시하세요. gitignore에 추가되었습니다.
이제 제가 귀하의 프로젝트에 참여할 것이라고 가정하시면 먼저 귀하의 프로젝트를 clone하고, config_example 파일pull을 다운로드한 후 먼저 사본을 만들고 이름을 config으로 바꾸겠습니다. , 파일에는 이미 기본 구성 정보가 있으므로 개발 환경에 맞게 약간만 변경하면 됩니다. 그런 다음 두 파일을 모두 gitignore에 추가하므로 push을 사용할 때 그렇지 않습니다. 영향을 받는 원격 창고에 손상을 입힐 수 있습니다.
이는 실제로 저희 팀이 자체 git 서버에서 사용하는 관리 방법인데, 원칙은 비슷해야 한다고 생각하는데, 도움이 되셨으면 좋겠습니다.
이러한 파일은 실제로 로컬 사용 환경과 관련되어 있으며 다른 사람이 Eclipse를 사용하지 않을 수 있으므로 업로드하지 마십시오. 그리고 정보 자체는 프로젝트와 아무런 관련이 없습니다. 좋은 접근 방식은 maven과 같은 도구를 사용하여 프로젝트를 관리한 다음 모든 사람이 로컬에서 깨끗한 코드를 체크아웃하고 IDE로 가져오는 데 필요한 파일을 생성하는 것입니다.
개인 관리의 경우 푸시를 하든 안 하든 상관이 없습니다. 어쨌든 구성 파일을 거의 변경하지 않는데,
push
한 번씩push
큰 차이는 없습니다.그러나 다른 사람이 관련되어 있거나
push
여러 환경에 있을 수 있는 경우push
구성 파일은 불필요한 충돌을 가져올 수 있습니다. 이때 구성 파일 이름이 다음과 같다고 가정하여 기본 구성 파일을push
사용할 수 있습니다.config
이후 프로젝트를 처음 푸시할 때 먼저config
에gitignore
를 추가하고,config_example
이 완료된 후push
도 기본 설정 정보가 담긴config_example
파일을 푸시하세요.gitignore
에 추가되었습니다.이제 제가 귀하의 프로젝트에 참여할 것이라고 가정하시면 먼저 귀하의 프로젝트를
clone
하고,config_example
파일pull
을 다운로드한 후 먼저 사본을 만들고 이름을config
으로 바꾸겠습니다. , 파일에는 이미 기본 구성 정보가 있으므로 개발 환경에 맞게 약간만 변경하면 됩니다. 그런 다음 두 파일을 모두gitignore
에 추가하므로push
을 사용할 때 그렇지 않습니다. 영향을 받는 원격 창고에 손상을 입힐 수 있습니다.이는 실제로 저희 팀이 자체
git
서버에서 사용하는 관리 방법인데, 원칙은 비슷해야 한다고 생각하는데, 도움이 되셨으면 좋겠습니다.제 경험상 둘 다 하지 마세요. Maven을 사용하여 코드를 관리하는 경우 pom.xml을 그대로 두세요.
.gitignore 사용에 대해서는 자세히 설명하지 않겠습니다. 프로젝트의 구성 파일은 일반적으로 버전 제어에 추가해야 하는지 여부를 알려줍니다. 예를 들어 이 Android의 속성 파일에 있습니다. 프로젝트, 댓글 내용:
그래서는 안 됩니다. 계속해서 원격 Git 서버에 푸시하면 동료들이 목을 졸라버릴 것이라고 사람들이 말했습니다~
이러한 파일은 실제로 로컬 사용 환경과 관련되어 있으며 다른 사람이 Eclipse를 사용하지 않을 수 있으므로 업로드하지 마십시오. 그리고 정보 자체는 프로젝트와 아무런 관련이 없습니다. 좋은 접근 방식은 maven과 같은 도구를 사용하여 프로젝트를 관리한 다음 모든 사람이 로컬에서 깨끗한 코드를 체크아웃하고 IDE로 가져오는 데 필요한 파일을 생성하는 것입니다.
며칠 전 블로그 게시물을 봤습니다. Git 코드 저장소에 구성 파일을 넣지 마세요