41일차(1)/GitHub : 외부 저장소에서 Fork-Clone 하기 / Pull Request 사용법

41일차(1)/GitHub : 외부 저장소에서 Fork-Clone 하기 / Pull Request 사용법

 

 

*깃허브에서 클론하는 방법 2가지
- 전체 클론하기
- fork 해서 내 깃허브로 가져온 후-클론

 

* 2번째 방법인 My Github로 fork(copy) 하기
- 단순 복사하는 것이라고 보면 된다.
- 포크한 후 My Local Computer 로 클론
- 내 저장소에 내 것으로 만들어놓은 후에 포크하는 것!
(원본 저장소가 업데이트되어도 자동 업데이트되지 않는다. fork한 시점까지만 복사되어 그대로 유지된다.)
- 그 이후 원래 깃허브에서 커밋한다 해도 내 깃허브에 있는 저장소는 달라지지 않는다.

 

 

 

- 포크한 시점의 커밋까지만 내 깃허브로 가져온다.

- 복제본만 갖고 있는 것이므로, 원본 저장소에서 커밋해도 내 깃허브에 추가로 커밋되지 않는다.

 

 

- 하나의 로컬저장소에서 remote 저장소가 2곳이 될 수 있다.

- 1번은 포크된 저장소, 2번은 원본의 기원이 되는 저장소, 3번은 로컬 저장소이다!

 

- 만약 2에서 commit 된 내용을 1에도 적용하고 싶다면

  2->3 으로 받아와서, 3->1로 push가 이루어져야 한다.

 

 

- 보통 2번을 upstream, 1을 origin (클론하면 자동으로 origin으로 잡힌다) 이라고 한다.

- 이 경우 pull하는 저장소와 push하는 저장소가 다른 것!

 

- 우측상단 포크 버튼 클릭

 

- 포크한 후 내 깃허브에 해당 폴더(저장소)가 들어와 있는 것을 볼 수 있다.

- 클론에서 저장소 위치를 복사!

 

- git bash로 새 저장소 지정하여 가져오기

 

- 해당 폴더가 추가되었다!

 

- 하지만 이클립스는 현재 이 저장소의 존재를 모른다.

  이클립스에서 클론한 것이 아니기 때문에!

 

- 이클립스에 깃 저장소를 인지시킨 다음에 import 한다.

 

- 이클립스의 git 환경에서 이미 존재하는 저장소를 가져오는 버튼 사용!

 

- 또는 우클릭-Add a Git Repository 할 수도 있다.

 

 

- 해당 폴더를 선택해준다. 그러면 저장소를 인식함!

 

 

- 이클립스에서 저장소를 인식하는 것과 import해오는 것은 별개이다.

- 저장소를 등록해도 따로 import 해줘야한다.

 

- Working tree 에서 import projects 한다.

 

- 처음에 파일을 import해오면 오류가 난다.

- 깃허브 업로드시 .gitignore로 제외된 파일이 있기 때문! 현재 PC 설정에 맞게 수정해주어야 한다.

 

- properties 로 들어가서 수정해준다.

 

 

- Project facets에서 사용하고 있는 PC의 개발 환경에 맞춰서 세팅해준다.

 

- Dynamic Web Module 체크

- Java 버전 17로 수정

- runtime에서 tomcat 9.0 서버 설정

 

- 이렇게 해도 오류가 발생하는경우, lib에 jar파일이 들어있지 않아서일 수 있다.

- jar파일을 WEB-INF의 lib 안에 복사해서 넣어주기!

 

- table.sql에서 필요한 테이블 정보를 복사해서 테이블 생성해두기

 

 

- 만약 clone 받아서 수정하고 싶은 내용이 있을 경우,
내가 따로 브랜치를 만들어서 내 깃허브에 푸쉬한 다음에 원본 저장소에 알림을 보낼 수 있다.
- 이것을 pull request라고 한다.

 

---

 

 

 

- 현재 저장소는 4군데이다

- origin/master는 외부 저장소를 트래킹하는 브랜치이다.(github)

 

 

- 내가 fork해간 이후에 다른 저장소에서 새로운 커밋을 한 상황인데,

 이 경우에는 이걸 내 깃허브로 가져올 수는 없다.

 

 

- 먼저 내 local repo로 내려받은 후에 내 깃허브로 다시 옮겨야한다.

- 나의 로컬 저장소에 oki 저장소를 remote 저장소로 등록해서 pull(fetch+merge)한다.

 

- 내 저장소로 포크한 후에는 원본 저장소에서 커밋해도 수정사항이 더 업데이트되지 않는다.

 

- 추가 커밋을 받으려면 내 로컬 저장소에 oki 저장소를 등록해야 한다.

 

 

- git remote -v : 내 저장소 나열하기

- 포크된 저장소를 origin으로 인식하고 있다.

 

- 기원이 되는 (원본)저장소는 이름을 upstream으로 짓는다.

 

- 이클립스에서 저장소 추가하는 법!!

 

 

- upstream이라고 이름을 저장하고, push가 아니라 fetch로 바꾸어준다.

 

- change를 누르면 복사되어 있던 주소 링크가 URI 로 자동으로 들어가진다.

 

- save 하면 된다.

 

- 새 remote 저장소가 생겨있다

- upstream은 fetch할 용도. 새로운 커밋을 받아오는 용도이다!

 

 

- 열어보면 fetch가 있다.

 

- fetch 된것을 확인가능.

 

- remote tracking이 세개가 생겨났다.

- 현재 master에 있는데, 지금 upstream의 master가 한칸 앞서 있는 상태

 

 

- upstream의 master 브랜치를 merge한다.

 

- master 는 upstream의 위치로 올라갔고, origin/master는 하나 뒤처져 있다.

 

- 익스플로러 창에서 push to origin 해주면 된다.

- 로컬 저장소의 master가 commit만 되고 깃허브로 push되지 않았을 때,

 깃허브의 origin/master가 뒤처져 있는 상황! 이럴때 깃허브로 push해준다.

 

- push해주면 origin/master 등 모든 저장소의 master가 같은 위치에 있다~

 

 

- 나중에 팀 프로젝트를 하게되면 조장이 만들어놓은 틀을 fork해가서 사용하면 된다

- 조장이 올린 파일을 내 저장소에서 pull-push해서 사용

 

 

---

 

- clone 해온 작업을 수정하게 될 경우, 새 브랜치 생성 (feature/index_design)

- 내 저장소에서 새로운 커밋을 하고나서 원본 저장소에 어떻게 수정된 사항을 전달해야 하는가?

 

→ 내 깃허브에 push하고나서, Pull Request(PR)을 보낼 수 있다.

 

- 새 브랜치에서 깃허브로 push하기

 

compare & pull request

- 내 깃허브에 들어가보면 새로운 버튼이 생겨있다!

 

 

- 수정사항에 대한 메시지를 남기면서 원본 저장소에 전달할 수 있다.

- 원본 저장소에서 해당 내용을 받아서 내용을 확인하고, 필요시 merge할 수 있다.

 

 

- 원본 저장소 입장에서는 메시지가 도착해 있고, Pull Request라는 새로운 버튼이 생겨 있다.

 

- 충돌하는 것이 없기때문에 쉽게 Merge할 수 있다는 뜻!

- 충돌(conflict)이 있다면 추가적인 작업 이 필요하다. (merge commit이라든가..)

 

- 원본 저장소에서 받아서 merge하면 merge되었다고 나온다.

 

- 원본에서 merge하면 나는 master branch로 이동해서 (checkout),

 

- upstream의 master가 현재 최신 버전이 되었기 때문에 이것을 pull 받으면 된다.

 

- master에서 upstream을 fetch해서 가져오는것!

 

- upstream에서 pull 완료된 모습이다.

- 최종적으로 merge 되었으면 더 이상 필요가 없기 때문에 feature/index_design 브랜치는 삭제하면 된다.

 

- upstream으로부터 pull해오면 내 저장소(github)에 다시 push해야 하는 것이 생겨난다.

- 이클립스에서 push to origin 하면 완료된다....

 

 

*Pull Request 참고 링크 : https://chanhuiseok.github.io/posts/git-3/

 

- 실제 작업은 Pull request보다는 Merge request에 가깝다. 내 작업물을 merge 해주세요~ 라는 뜻!

- 오픈소스 프로젝트들이 이렇게 많이 진행된다.

 fork해간 후에 수정 → 원본에 PR보내기 → 원본에서 받아들여서 merge하기

 

---

 

** Pull Request 를 하는 팀 프로젝트의 작업 순서를 기억하기!

 

- 원본 저장소(upstream)에서 내 깃허브로 fork, clone해서 내 컴퓨터(local)로 import

→ 내 local repo 에서 수정하기

→ 수정사항을 commit하고 내 깃허브 저장소에 push 하기

→ 깃허브에서 원본 저장소에 pull request 요청

→ 원본 저장소에서 받아서 수정을 확인하고 merge하기

→ 내 local에서 master 브랜치로 checkout 해서, 원본 저장소의 최신버전을 pull (다시 내려받기)

→ 수정된 내용을 확인하고, 내 github에 push하기