Git 협업 _ github

1. fork

1.1. 흐름

1. owner가 project 생성
2. coworker가 github site에서 fork 수행
3. coworker가 작업 수행 후, 자신의 git에 .add -> commit -> push까지 한 후, pull request 수행
4. owner는 pull request 확인 후 issue를 남기거나 merge 수행
5. 원격 저장소에서 변경이 일어났으므로 

 

 

 

•  fork
  • github의 기능
  • 복사본을 가진다.
  • 그래서 실제 소스코드의 내용이 변경 될 시, fork를 update할 필요가 있다.
• 단계
  1. fork 후 clone 하기
     
     
  2. 내가 local에서 수정
     
     
  3. parent source code에 변경 수락 요청하기 : 내가 수정한거 가져 가죠!! - pull
     • 방법 : 내 git-hub repository에 가서 new pull request click만 하면 됨
     • 이전 chapter2의 branch간의 비교 대신에 fork 된 저장소와 비교하는 기능을 사용
       
       
• pull을 바로 허락하기전에 아래의 과정을 거쳐서 문제점을 파악해야한다. 
  1. pull request 받기: 팀원이 pull request을 보내면, 해당 변경 사항을 복제하여 로컬 환경에 가져옵니다.
     
     
  2. 로컬에서 테스트: 가져온 변경 사항을 로컬 환경에서 실행하여 코드의 정상 동작 여부를 확인합니다. 테스트 케이스를 실행하고 예상된 결과가 나오는지 확인합니다.
     
     
  3. 코드 리뷰: 변경 사항을 코드 리뷰하여 문제점을 확인하고, 수정이 필요한 부분을 지적합니다. 리뷰 과정에서 팀원과 의견을 공유하고, 코드 품질을 향상시킬 수 있는 조언을 제공합니다.
     
     
  4. 수정 요청: 문제점이 발견되면, pull 요청한 팀원에게 문제점을 알리고 수정을 요청합니다. 필요한 수정이 이루어질 때까지 계속하여 의사소통하며 협업합니다.
     
     
  5. 최종 허용: 문제점이 해결되고 코드가 정상 동작함이 확인되면, 해당 pull 요청을 허용합니다. 수정된 코드가 원본 저장소에 통합되고, 변경 사항이 반영됩니다.
• 내가 수락을 한다.

 

 

 

origin을 놓아두고 서브로 repository를 많이 구성해두어야할 것 같다

• 진짜 source code
  1. 오류가 없는 완벽한 코드 - 2 || 3 이 정상작동 된다고 어느정도 판단 된 경우 바로 업로드말고 백엔드 개발자가 동일 chapter 수행후 이게 잘 동작시 pull 수행
  2. 우선 여기서 업데이트하도록 - 사람들이 여기에 pull 하도록
  3. 사람들이 여기에 pull 하도록- 예비용 (2번보다 한 템포 느리게 2번이 터지면 3번으로 갈아탈수있도록)

 

2. Collaborate

 

2. branch

• master -> sub
• sub -> master
  
  
• conflict : master와 sub 둘다 동일 위치 수정시 발생 -> 선택하면 된다.
  • sub나 master에서 동일 라인을 수정하고 각각 push까지 했을 때는 문제가 발생하지 않는다.
  • 하지만 merge할 경우에 conflict가 터진다. 

• conflict 해결 방법
  • 해당 이미지에서 vsc code로 넘어가기
  • compare 후에 원하는 것 선택
  • 이후 merge 수행
  • 변경 선택 안된 branch도 다시 merge 해줘야 동일 적용이 완성된다.

 

conflict로 인한 충돌은 완벽히 피할 수 없는 건가??

 

충돌을 완전히 피할 수는 없습니다. 여러 사람이 동시에 작업하고 있거나 원본 저장소에서 변경 사항이 발생할 경우 충돌이 발생할 수 있습니다. 이는 분산 버전 관리 시스템인 Git의 특성상 일어날 수 있는 현상입니다.
소스 코드 충돌을 완전히 피하는 것은 어렵지만 충돌을 최소화하고 충돌이 발생했을 때 빠르게 해결할 수 있는 방법들이 있습니다. 아래는 충돌을 최소화하고 관리하는 몇 가지 방법입니다
작은 단위로 작업하기: 큰 변경 사항을 한 번에 처리하는 대신 작은 단위로 작업하고 커밋하는 것이 좋습니다. 이렇게 하면 다른 개발자들과의 충돌 가능성이 줄어듭니다.
주기적으로 업스트림 변경사항 가져오기: 원본 저장소의 변경 사항을 주기적으로 가져와서 fork된 저장소를 업데이트하는 것이 좋습니다. 이를 통해 최신 변경 사항을 따라갈 수 있고, 충돌을 더 빨리 감지하고 해결할 수 있습니다.
충돌 해결 전략: 충돌이 발생했을 때는 충돌 해결 도구를 사용하여 충돌을 해결하는 전략을 선택해야 합니다. Git은 충돌을 해결하기 위한 도구들을 제공하며, 이를 통해 충돌을 분석하고 수정할 수 있습니다.
협업과 의사소통: 만약 여러 개발자가 동시에 작업하고 있다면, 충돌을 방지하기 위해 서로의 작업에 대해 의사소통하고 협력하는 것이 중요합니다. 작업 일정을 조율하거나 작업 범위를 분리하는 등의 조치를 취할 수 있습니다.
충돌은 분산 버전 관리 시스템에서 흔히 발생하는 문제이지만, 위의 방법들을 사용하면 충돌을 최소화하고 효과적으로 관리할 수 있습니다.

 

 

3. 협업하기

•  

 

• 이미지로 보기

개인 화면

 

 

 

코드 주인 화면

 

pull 요청까지 완료한 fork는 이제 필요없으므로 삭제해도 됨

 

 

코드 주인은 fork 할 수 없기 때문에 해당 git repository를 그대로 사용해야한다.

 

• 코드 주인이 수정사항을 적용한 경우
  
  • 개인의 githubDesktop에 branch를 보면 upstream/master라는 브랜치가 존재 - 이게 현재 주인의 branch이다. - 이런식으로 연결된다.
  • 그래서 주인 변경사항을 update하려면 개인의 github desktop의 상단 fetch origin을 누르게 되면  자연스럽게 upStream의 변경사항을 읽고 업데이트를 수행한다.
  • 그리고 branch에서 merge를 누르면 자연스럽게 자기걸로 넘어간다.
    
    정리
    
    
  • 1. fetch
  • 2. current branch -> merge
  • 3. push

 

 

4. 이슈

• 프로젝트가 해야 하는데 아직 하지 않은 일이나, 사람들이 발견한 문제나 버그 같은 것을 기록하는 것
• 오픈 소스에서 작업할 때 보거나 테스터들이 문제를 찾아서 이슈를 적을 때 볼 수 있다.
• 혼자서 일하거나 작은 회사의 경우 issue를 쓴다.
  ex) 이런 이슈를 해결해서 이런 pull request를 수행했어
  label 또한 존재한다. -> 해결하면 close g한다.
• mileston이 있는데 goal 같은 것을 의미한다. - 이슈를 각각 만들고 이슈를 닫을 때(=해결)마다 마일스톤에 가까워진다고 알 수 있다.

 

 

5. 동료랑 협업하기 - 새로 찾은 방법

• 같이 할 repository의 settings
• 좌측 배너의 collaborators -> 협업할 동료 초대

 

 

• 협업할 인원을 초대한 후 해당 인원들이 pull- request 할 때 branch 보호 목적으로 merge를 제한하는 과정이 필요하다.
• 좌측 베너의 Branches에 들어가서 rule을 생성한다.

 

 

6. 협업 큰 흐름

• conflict 방지를 위해서 항상 update 후 공지를 해서 상대방이 업데이트 후, 자기 작업을 수행하도록한다.
  
  
• fetch: orgin으로부터 값을 받아오는 것인데 local branch에서는 update 작업이 적용이 안되고 main branch만 update 된다.
• pull: fetch와 유사한데 local까지 update 시켜준다.
  -> 상단tab의 repository -> pull (command + shift + p)
•  

 

 

 

• pull & push 설명

https://sskl660.tistory.com/78

GitHub Desktop(Pull, Push)

 

 

6. 코드 리뷰

https://joyful-development.tistory.com/14

[GitHub] 아직 코드리뷰가 익숙하지 않은 분들을 위한... 코드리뷰는 어떻게 해야할까? (+ GitHub에서

 

코드 리뷰 참고 블로그 - best

https://devlog-wjdrbs96.tistory.com/231

[Github] Pull Request를 통해 코드리뷰(Code Review)하는 법

 

약간 심화

https://velog.io/@soyeon207/%EB%98%91%EB%98%91%ED%95%98%EA%B2%8C-PR%EC%9D%84-%ED%86%B5%ED%95%B4-%EC%BD%94%EB%93%9C%EB%A6%AC%EB%B7%B0-%ED%95%98%EA%B8%B0

똑똑하게 PR을 통해 코드리뷰 하기

 

 

 

7. 조원들이 할 것

• commit - push 
• pull request
  • 상단) 병합할 branch <- 병합될 branch
  • 하단) PR message
  • 우측 베너) Reviewers, Assignees - pr review 해 줄 팀원 지정 / 현재 PR 작업의 담당자 지정 (일단 2개 다 내 이름으로 하면 될듯 함)
    
    - review 하는 사람들 한테 나중에 
  • Comment : 승인과 무관하게 일반적인 커멘트를 할 때 선택한다.
  • Approve : Comment와 다르게 리뷰어가 승인을 하는 것으로, 머지해도 괜찮다는 의견을 보내는 것이다.
  • Request changes : 말 그대로 변경을 요청하는 것으로, 승인을 거부하는 것을 뜻한다.
• pull
• merge