part 1.
공용 리포지토리를 Fork 하기
- 해당 리포지토리에 접속 후 우측 상단 fork 아이콘 클릭

- create fork 클릭

- fork 완료

part 2.
Fork 한 리포지토리를 프로젝트와 연동하기(이클립스)
- 이클립스의 Window ▶ Show View ▶ Other 메뉴를 선택합니다.

- Git ▶ Git Repositories 메뉴를 선택하고, Open 버튼을 클릭합니다.

- Git Repositories 탭에서 Clone a Git Repository 아이콘을 클릭
또는 우클릭 ▶ Clone a Git Repository 메뉴를 선택합니다.

- github에서 fork한 내 레포지토리(Repository) 주소를 복사합니다. (깃허브 레포지토리 우측 상단 code)

- 복사한 레포지토리(Repository) 주소를 URI란에 붙여 넣고, github 사용자 정보를 입력한 후 Next 버튼을 클릭합니다.

- develop 브랜치 선택

- Directory란에 github의 원격 저장소와 연결할 로컬 저장소 경로를 입력하고 Finish 버튼을 클릭합니다.

- clone이 되면, Git Repositories 탭에 github의 원격 저장소가 정상적으로 연동됩니다.

- Git Repositories 탭에서 내려받을 프로젝트를 선택하고 우클릭 ▶ Import Maven Projects 메뉴를 선택합니다.

- Import source 경로를 확인하고, Finish 버튼을 클릭합니다.

part 3.
프로젝트 작성 후 자신의 리포지토리에 Commit&Push 하기
- 이클립스 우측 상단 git 아이콘 클릭

-
좌측 git repository 창에서 push 할 프로젝트 선택
-
git staging 탭에서 변경한 파일 staged changes 창으로 이동
-
commit message 작성 후 commit and push 버튼 클릭

- ⛔ 주의사항
자신이 작업한 파일만 커밋하도록 한다.
이클립스의 경우 .gitignore가 적용 안되는 버그가 종종 있다.
++ 버튼을 누를 경우 전부 옮겨가므로 유의
part 4.
자신의 리포지토리의 변경 사항을 공용 리포지토리에 풀 리퀘스트 하기
- 공용 리포지토리로 들어가서 Pull Request 탭을 선택

- New Pull Request 버튼 클릭

- compare across forks 를 누르면 자신의 리포지토리를 비교할 수 있다
왼쪽에는 풀 리퀘스트를 요청할 리포지토리와 브랜치를 선택하고
오른쪽은 내 리포지토리와 브랜치를 선택

- ⛔ 브랜치를 정확히 선택하도록 한다.
master, develop 등 중요한 브랜치의 경우 함부로 merge 하면 안된다.
- 풀 리퀘스트 요청을 보내는 이유를 작성하고 create pull request 버튼을 클릭

part 5.
Fork 한 리포지토리와 원본 리포지토리 동기화 하기
로컬 저장소에 원본(Upstream) 저장소 등록
-
먼저 git을 설치해야 한다.
https://git-scm.com/downloads
-
프로젝트가 있는 경로에 우클릭을 눌러서 git bash를 실행한다.


$ git remote -v
- 위 명령어를 입력해 로컬 저장소와 연결된 원격저장소를 확인한다.

$ git remote add upstream [원격 저장소 주소]
-
원격 저장소를 등록하기 위해 위 명령어를 입력해준다.
보통 fork에서 원본 저장소의 이름은 upstream을 사용한다.
-
변경사항을 원본 저장소에 Commit & Push 해준다.
-
변경사항을 업데이트 해 주기 전에 다른 사람이 수정한 내용이 있다면
confilct(충돌) 오류가 뜨므로 최신화를 먼저 해준다.
$ git fetch upstream
- 그래도 conflict 오류가 뜬다면 수작업으로 수정해준 후 Commit & Push를 진행한다.
참고 블로그 : https://velog.io/@jisubin12/Github-%EC%99%B8%EB%B6%80%EC%A0%80%EC%9E%A5%EC%86%8C-fork-pull-request-%EB%8F%99%EA%B8%B0%ED%99%94-%ED%95%98%EA%B8%B0
브랜치 전략

- master : 언제든 배포 가능한 상태
- develop : 각각의 기능을 merge 했을 때 오류가 없는 상태
- feature/"기능이름" : 기능별로 구분해 놓은 브랜치, 작업 완료 시 보통 삭제
- hot-pix : 급하게 발생한 오류를 고치는데 사용하는 브랜치
github에서 제공하는 branch rule 을 이용해서 develop 이나 master 같은 중요 브랜치는
특정 인원 수 이상이 풀리퀘스트 요청을 받아들여야 merge 가능하게 설정할 수 있음
커밋, 머지 규칙
-
공용 리포지토리에 풀리퀘스트 요청을 할 때에는 누군가가 먼저 푸쉬를 했는지
확인하고 커밋해야 함
-
누군가 먼저 푸쉬를 했다면 pull 해서 최신화 후 commit&push를 해야 함