요약 - 2가지
1. fork
2. collaborate - (우리 채택)
방식
팀장 ; 팀장이 main 관리, merge 요청 확인 해주기
팀원 : 팀장한테 pull request 요청 보내기
상대 팀원들이 pull request 수락 받으면 다른 인원들도 pull이라는 것을 통해서 update 필요 - conflict 막는 최선의 방법
단계: commit - push - pull request - code review - merge - 다 함께 pull - 개인 branch에 merge 수행
https://docs.github.com/ko/desktop/contributing-and-collaborating-using-github-desktop
GitHub Desktop을 사용하여 기여 및 협업 - GitHub Docs
GitHub 또는 GitHub Enterprise의 원격 리포지토리에서 함께 작업
docs.github.com
- 협업 방식
- Fork와 Pull Request: 기여자가 원본 저장소를 Fork한 후에 수정 작업을 진행하고, 수정 내용을 원본 저장소로 Pull Request를 보내는 방식입니다. 이 방식은 오픈 소스 프로젝트에서 많이 사용됩니다. 원본 저장소의 소유자가 Pull Request를 검토하고, 변경 사항을 병합하는지 여부를 결정합니다.
- Branch와 Pull Request: 기여자가 원본 저장소의 별도 브랜치를 생성하여 수정 작업을 진행한 후, 해당 브랜치로 Pull Request를 보내는 방식입니다. 이 방식은 원본 저장소의 소유자와 협업하면서 변경 사항을 검토하고 통합할 수 있습니다.
- Collaborator: 원본 저장소의 소유자가 특정 사용자를 Collaborator로 추가하여 해당 저장소에 직접적인 접근 및 수정 권한을 부여하는 방식입니다. Collaborator는 원본 저장소에 직접 커밋하고 브랜치를 생성할 수 있으며, 협업을 진행할 수 있습니다.
- Shared Repository: 팀 또는 조직 내에서 여러 사용자가 같은 저장소를 공유하고, 해당 저장소에서 직접 작업을 수행하는 방식입니다. 이 방식에서는 사용자 간에 브랜치를 생성하거나 작업을 분리하여 협업하며, 변경 사항을 공유 저장소에 직접 푸시할 수 있습니다.
- Fork와 Pull Request: 기여자가 원본 저장소를 Fork한 후에 수정 작업을 진행하고, 수정 내용을 원본 저장소로 Pull Request를 보내는 방식입니다. 이 방식은 오픈 소스 프로젝트에서 많이 사용됩니다. 원본 저장소의 소유자가 Pull Request를 검토하고, 변경 사항을 병합하는지 여부를 결정합니다.
1. gitkhub Flow
협업은 2가지
1. folk
2. 공동 team 원 setting으로 추가하기
2. branch 보호
[GitHub] Branch Protection Rule 적용해 브랜치 보호하기
Branch를 보호하는 것이 중요한 이유 협업을 할 때 Rule이 없으면 각자 자신의 방식으로 일을 하게 되기 때문에 뒤죽박죽이 된다. 만약 인원이 적다면 별 문제가 되지 않지만, 실무에서는 적게는 3
kotlinworld.com
https://gardeny.tistory.com/19
GITHUB protected branch를 설정 해 보자
Protected Banch란? GITHUB 에서 어떤 브랜치를 어떤 행위에 대해서 보호하기 위한 조치이다. 예를 들어 우리의 소중한 마스터 브랜치는 언제나 잘 작동하는 올바른 코드가 올라가야 할 것이다. 이 원
gardeny.tistory.com
3. 요약
https://www.youtube.com/watch?v=IT41djAKUgg
추가적으로 아는 것
commit과 push의 차이점이 뭐야?
ChatGPT
commit과 push는 Git에서 서로 다른 개념을 나타냅니다.
commit: commit은 Git 저장소에 변경 사항을 기록하는 작업입니다. commit은 파일의 수정, 삭제, 추가 등의 변경사항을 스냅샷으로 기록하며, 해당 스냅샷은 고유한 해시 값으로 식별됩니다. commit을 통해 변경사항의 히스토리를 남기고, 프로젝트의 특정 시점의 상태를 저장할 수 있습니다.
push: push는 로컬 저장소의 commit들을 원격 저장소로 전송하는 작업입니다. push를 통해 로컬 저장소에 있는 commit들을 원격 저장소에 반영하고, 다른 개발자나 다른 장치에서도 해당 변경사항을 볼 수 있도록 합니다. push를 실행하면 로컬의 commit들이 원격 저장소로 업로드됩니다.
간단히 말하면, commit은 변경사항을 기록하고 히스토리를 관리하는 작업이며, push는 로컬의 commit들을 원격 저장소로 업로드하여 공유하는 작업입니다.
네, Git에서의 "로컬 저장소(Local Repository)"와 "Git 히스토리(Git History)를 저장하는 저장소"는 다른 개념입니다.
로컬 저장소는 개발자의 컴퓨터에 있는 Git 저장소를 말합니다. 로컬 저장소는 작업 디렉토리, 인덱스, 커밋 히스토리 등을 포함하고 있습니다. 로컬 저장소는 코드의 변경 사항을 추적하고 버전 관리하는 데 사용되며, 커밋을 생성하고 브랜치를 관리하는 등의 작업을 수행할 수 있습니다. 로컬 저장소는 원격 저장소와 독립적으로 존재하며, 개발자의 컴퓨터에서 작업을 진행할 때 변경 사항을 기록합니다.
반면에 Git 히스토리는 Git 저장소에 저장되는 커밋 히스토리를 의미합니다. Git 저장소는 로컬 저장소와 원격 저장소를 포함하며, 코드 변경 사항의 전체 기록을 관리합니다. Git 저장소에는 커밋, 브랜치, 태그 등의 정보가 포함되어 있습니다. Git 히스토리는 변경 사항의 연대기로서, 과거의 커밋부터 현재까지의 모든 커밋을 포함합니다. Git 히스토리는 Git 저장소를 복제할 때 함께 복제되며, 원격 저장소에 푸시되거나 원격 저장소에서 풀(pull)되는 등의 작업을 통해 동기화됩니다.
따라서, 로컬 저장소는 개발자의 컴퓨터에 있는 작업 공간이고, Git 히스토리는 Git 저장소에 저장된 커밋의 기록을 나타냅니다. 로컬 저장소는 독립적으로 작업하며, Git 히스토리는 변경 사항의 전체 기록을 관리하는 공유 저장소라고 볼 수 있습니다.
정확한 상황을 이해하기 위해서는 구체적인 상황과 조작 방법에 대한 정보가 필요합니다. 보통 GitHub에서 commit이 사라진다는 것은 다음과 같은 경우에 해당합니다:
- Force Push: 로컬 저장소에서 git push --force 명령을 사용하여 원격 저장소에 강제로 푸시한 경우, 기존의 커밋 히스토리는 덮어쓰여질 수 있습니다. 이 경우, 히스토리에서 이전 커밋은 보이지 않게 됩니다.
- 원격 저장소에서 커밋 삭제: 원격 저장소의 관리자 또는 권한이 있는 사용자가 특정 커밋을 원격 저장소에서 삭제한 경우, 해당 커밋은 GitHub에서는 더 이상 볼 수 없게 됩니다.
- 브랜치 삭제: 특정 브랜치를 삭제한 경우, 해당 브랜치에 속한 커밋들도 함께 삭제되기 때문에 GitHub에서는 해당 커밋들을 볼 수 없게 됩니다.
이외에도 GitHub에서 특정 커밋이 보이지 않는 상황은 다양한 이유가 있을 수 있으며, 이는 리포지토리의 설정, 액세스 권한, 특정 브랜치 또는 태그의 상태 등에 따라 달라질 수 있습니다. 따라서, 구체적인 상황과 조작 방법을 파악하여 더 정확한 답변을 제공할 수 있습니다.
네, 맞습니다. 예를 들어 a-b-c 커밋 히스토리가 있고 로컬에서 git push --force 명령을 사용하여 원격 저장소에 강제로 푸시한 경우, 새로운 커밋 d가 생성되고 브랜치는 d를 가리키게 됩니다. 그러나 원격 저장소의 히스토리에서는 c 커밋이 보이지 않게 되며, c 커밋에 접근하기 위해서는 c 커밋의 해시 값이나 기타 참조를 사용해야 합니다.
즉, 로컬 저장소에서의 히스토리는 변경되었지만, 원격 저장소의 히스토리는 갱신되어 이전 커밋이 보이지 않게 됩니다. 다만, 내부적으로는 c 커밋과 d 커밋이 모두 존재하고 있으며, 로컬에서는 이전 커밋에 접근할 수 있습니다.
맞습니다. git push --force 명령을 사용하여 원격 저장소에 강제로 푸시한 경우, 이전 커밋인 c는 원격 저장소의 히스토리에서 접근할 수 없게 됩니다. 원격 저장소에서는 최신 히스토리에만 접근할 수 있으며, 이전 커밋에 대한 정보는 보이지 않습니다. 따라서 원격 저장소에서는 c 커밋에 직접 접근하는 방식은 없습니다. c 커밋에 접근하기 위해서는 로컬 저장소에서 해당 커밋을 참조해야 합니다.
정확한 상황을 이해하기 위해서는 구체적인 상황과 조작 방법에 대한 정보가 필요합니다. 보통 GitHub에서 commit이 사라진다는 것은 다음과 같은 경우에 해당합니다:
- Force Push: 로컬 저장소에서 git push --force 명령을 사용하여 원격 저장소에 강제로 푸시한 경우, 기존의 커밋 히스토리는 덮어쓰여질 수 있습니다. 이 경우, 히스토리에서 이전 커밋은 보이지 않게 됩니다.
- 원격 저장소에서 커밋 삭제: 원격 저장소의 관리자 또는 권한이 있는 사용자가 특정 커밋을 원격 저장소에서 삭제한 경우, 해당 커밋은 GitHub에서는 더 이상 볼 수 없게 됩니다.
- 브랜치 삭제: 특정 브랜치를 삭제한 경우, 해당 브랜치에 속한 커밋들도 함께 삭제되기 때문에 GitHub에서는 해당 커밋들을 볼 수 없게 됩니다.
이외에도 GitHub에서 특정 커밋이 보이지 않는 상황은 다양한 이유가 있을 수 있으며, 이는 리포지토리의 설정, 액세스 권한, 특정 브랜치 또는 태그의 상태 등에 따라 달라질 수 있습니다. 따라서, 구체적인 상황과 조작 방법을 파악하여 더 정확한 답변을 제공할 수 있습니다.
네, 맞습니다. 예를 들어 a-b-c 커밋 히스토리가 있고 로컬에서 git push --force 명령을 사용하여 원격 저장소에 강제로 푸시한 경우, 새로운 커밋 d가 생성되고 브랜치는 d를 가리키게 됩니다. 그러나 원격 저장소의 히스토리에서는 c 커밋이 보이지 않게 되며, c 커밋에 접근하기 위해서는 c 커밋의 해시 값이나 기타 참조를 사용해야 합니다.
즉, 로컬 저장소에서의 히스토리는 변경되었지만, 원격 저장소의 히스토리는 갱신되어 이전 커밋이 보이지 않게 됩니다. 다만, 내부적으로는 c 커밋과 d 커밋이 모두 존재하고 있으며, 로컬에서는 이전 커밋에 접근할 수 있습니다.
맞습니다. git push --force 명령을 사용하여 원격 저장소에 강제로 푸시한 경우, 이전 커밋인 c는 원격 저장소의 히스토리에서 접근할 수 없게 됩니다. 원격 저장소에서는 최신 히스토리에만 접근할 수 있으며, 이전 커밋에 대한 정보는 보이지 않습니다. 따라서 원격 저장소에서는 c 커밋에 직접 접근하는 방식은 없습니다. c 커밋에 접근하기 위해서는 로컬 저장소에서 해당 커밋을 참조해야 합니다.