협업2)오픈소스PR + 팀원PR + issue로 PR

📜 제목으로 보기

여러가지 Pull Request 날려보기

여러가지 Pull Request 날려보기

Reference

노팀원 fork PR(팀원-PR받기만/ 타인(나)-Fork후 수정용브랜치로 push하여 타인의 PR)

앞에서 PR = 팀원1(주인):수정용브랜치 -> 팀원2:collaborator이며 리뷰만
- PR(주인-수정용브랜치 / 팀원-리뷰만) 실습
  - 로컬 : git_seminar
  - 원격 : CS100_Git in is3js
    - 협동자: is3js
소샬코딩의 PR
- 오픈소스 레포(is3js) : py
  - 주인 혹은 collaborator임.
- 기여하고 싶은사람(is2js, 나): py(fork)
  - 팀원이 아닌 이상 일단 fork한다
  - 팀원이 아니더라도 clone후 로컬에서 topic branch를 따서 작업한다.
  - fork레포(내꺼)에 commit, push한다
  - 팀원이 아니지만, fork레포 - topic branch의 변동사항을 push로 PR한다.

팀원아니더라도 fork-clone-topic따서 작업한 뒤 -> (merge하지않고) commit, push

나는 오픈소스의 collaborator가 아니므로 오픈소스(py)를 fork한다.

작업을 하려면 일단 clone부터해서 local에 가지고 온다.

 ❯ git clone https://github.com/is2js/py.git .❯ code .

git 설정을 한번 확인해준다.

  ❯ git config --list

  remote.origin.url=https://github.com/is2js/py.gitremote.origin.fetch=+refs/heads/*:refs/remotes/origin/*branch.main.remote=originbranch.main.merge=refs/heads/main

fork를 해온 상태는 main브랜치이다. 새로운 topic 브랜치 work를 따서 작업 -> commit -> work를 push까지해보자.
- 브랜치 클릭 -> +새 분기 만들기 > work
- main에 merge하는게 아니라 topic branch를 commit -> push해야 팀원아닌데도 PR을 날릴 준비를 할 수 있다.
  - 명령어로 할 거면
    git push origin [topic branch명]
fork한 내 레포라도 topic branch가 merge없이 push되었으면 PR로 인식된다.
- 내 개인소스 수정: merge –no-ff -> main commit -> push
  - PR : no merge -> topic commit -> topic push
- 원본레포인 is3js/py는 미동도 없고, fork한 내 레포 is2js/py에만 PR이 들어온다.

topic push로 만든 `Fork레포 PR`클릭시 `원본레포(baserepo) PR`을 유도: 전제-main(master)는 변화없이 topicbr만 변화! cf) Fork레포(headrepo)로 merge도 가능함.

일단 기본적으로
- fork한 내 레포(head repo) : is2js/py에서
- 원본 레포(base repo) : is3js/py로 PR를 보내는 것을 기본적으로 수행하려 한다.
- fork레포에서 PR버튼 눌렀는데, 이미 원본레포(is3js/py)로 이동되어있다.

base repo를 수정하면, fork-main <- fork-topic 도 가능한가보다.
Create pull request해보자.
- 원본레포에다가 날리는 것이다.
- 원본레포에서 보면 PR이 불들어와있다.
fork레포는 PR에 아무 표시도 안된다.

원본레포 팀원은, 팀원X-Fork-topic-PR 날린 것을 commit을 직접 확인하여 request chagnge하거나 approve해준다.

PR 확인후 해당 topic branch의 커밋까지 찾아들어간다.
코멘트를 날릴 땐, +드래그해서 많이 날릴 수 있음.
최종적으로는 우측 상단의 review changes > approve까지 해야하지 merge된다.
최종승인하면 원본의 기본branch인 main으로 알아서 merge된다.

팀원이 아니더라도 PR(merge)후 delete branch가 원칙: 로컬에서 로컬+fork 2개다 해줌.

로컬에서 내 fork레포 및 내 로컬레포의 topic branch를 삭제해준다.
- main으로 바꾸고, 삭제
```
  ❯ git branch -a❯ git checkout main❯ git branch -d work
```

로컬topic 삭제 -> remote(fork레포)도 자동삭제 반영시키기: git remote update –prune

로컬에 topic branch가 삭제된 상태에서 git remote update --prune을 사용하여 로컬에 맞춰서 branch삭제 시킨다.
```
 ❯ git remote update --prune
```
안되서 나는 git push origin :remote_br
```
 git push origin :work
```

참고) origin과 upstream

레퍼런스: https://pers0n4.io/github-remote-repository-and-upstream/

Upstream & Downstream

GitHub에서 repo를 생성하고 나면 다들 origin이라는 용어를 보셨을 겁니다. clone했을 때는 origin이 자동으로 등록돼있고, init했을 때는 git remote add origin ...으로 origin을 직접 등록하라고 안내하죠. 여기서 말하는 origin이 깃허브에 존재하는 repository 즉, remote를 뜻하는 단어입니다. 다만 remote에 origin이라는 이름을 붙인 것뿐이랍니다.

upstream과 downstream은 상대적인 개념이라 origin과 local을 기준으로 생각하면 origin이 upstream, local이 downstream이 됩니다. 그 이유는 push와 pull을 기준으로 생각했을 때 origin으로부터 local로 흐르는 관계가 형성되기 때문입니다.

local에서 origin으로 push한다
origin에서 local로 pull한다

만약 CLI로 push를 해보셨다면 git push -u origin main3이라는 명령어를 입력했을 텐데, 여기서 -u 옵션이 --set-upstream 옵션의 줄임으로 upstream을 설정한다는 뜻입니다. upstream을 한 번 설정하고 나면 다음부터는 git push 또는 git pull이라고 명령어만 입력해도 자동으로 origin의 main 브랜치로부터 push와 pull을 진행하는 이유가 upstream 옵션을 통해 해당 브랜치에서 upstream과 downstream 관계가 설정됐기 때문이죠.

Fork

GitHub에서 오픈소스 프로젝트에 기여한다거나, 협업을 진행할 때 fork를 이용하게 됩니다. fork는 다른 사람의 repository를 내 소유의 repository로 복사하는 일이죠. 따라서 원래 소유자의 remote repository와 내가 fork한 remote repository 사이에도 upstream과 downstream이라는 관계가 형성된답니다. 그래서 보통 원래 소유자의 remote를 말할 때 upstream, 내가 포크한 remote를 말할 때 origin이라는 용어를 사용하곤 합니다.

노팀원이지만 [원본repo(오픈소스)] -> fork레포 및 local레포를 최신형으로 유지 by local에서 upstream으로 등록하여 upstream(원본레포) -> origin(fork레포), upstream -> local 통로뚫고 가져오기: git remote add upstream [url] -> git fetch upstream ->[fork레포 ]merge버튼 + [local]git merge upstream/main

상황
- 갑자기 오픈소스 author가 원본repo -> main을 변경했다면?
  - 나한테(fork레포, local레포)의 main도 수정된 내용이 들어와야한다.
- 기존 local repo에서 -> fork repo를 origin 이라 별칭했음
  - local repo에서 -> 원본repo를 upstream으로 별칭 등록 및 원본repo - fork repo를 연결
- git fetch: origin to local
  - git fetch upstream: 원본repo(upstream) to fork repo(origin)으로 업데이트 내용 받아오기
  - git merge upstream/main으로 원본repo(upstream) to local repo(local)로 업데이트 내용 받아오기
my) 원본repo를 노팀원이 upstream으로 local에서 등록하면
- upstream -> fork
- upstream -> local
  - 업데이트가 가능하다.
관련 명령어

참고) upstream 삭제

참고 블로그

  git remote -v
        
  git remote rm upstream
        
  git remote -v

local에서 원본repo를 upstream으로 등록한다.

 ❯ git remote add upstream https://github.com/is3js/py.git

git fetch upstream명령어로 upstream의 최신정보를 origin이 받을 수 있도록 업데이트해온다.(아직 받진 X)

 ❯ git fetch upstream
    
 remote: Enumerating objects: 8, done.
 remote: Counting objects: 100% (8/8), done.
 remote: Compressing objects: 100% (3/3), done.
 remote: Total 5 (delta 2), reused 4 (delta 2), pack-reused 0
 Unpacking objects: 100% (5/5), done.
 From https://github.com/is3js/py
  * [new branch]      main       -> upstream/main

origin(fork repo)에 가보면, Fetch해왔다고 뜬다.

fork repo에 들어가 git fetch upstream정보를 이용해 최종 merge시킨다. by Fetch upsteam> Fetch and merge 버튼

local에서는 git merge upstream/main명령어를 이용해 upstream정보를 가져온다.

왠지 origin을 pull해서 업데이트 해도될것같긴한데… 따로 upstream -> local로 받는다?

 ❯ git merge upstream/main
    
 Updating 476f70b..f7dd8e8
 Fast-forward
  .gitignore | 11 ++++++++++-
  rb.py      |  3 +++
  2 files changed, 13 insertions(+), 1 deletion(-)

참고) 만약 merge가 conflict나면

  git merge upstream/master  --allow-unrelated-histories

앞으로 계속

 ❯ git fetch upstream
    
 # fork repo가서 merge 버튼
    
 # local에서 merge
 ❯ git merge upstream/main

팀작업1: 내부팀원 (not 오픈소스) 초대 및 작업하기

내부 소스( not 오픈소스)라고 가정한다.
관련 명령어

팀리더(is3js)가 팀원(is2js)초대 : github-settings-manage acess-add people(invite collaborator)

초대받은 사람은 등록 email로만 초대를 받음.
- push권한이 있다고 한다. = 글쓰기 기능이 있다.

팀원은 초대되었다면,`fork`(-> clone -> topic -> PR)할 필요가 없이 `clone`(->push)or(->topic-> review=팀원PR)만 한다. 팀원이라면 바로 local->팀repo에 바로 push가 가능

팀원은 초대되었다면,fork(-> clone -> topic -> PR)할 필요가 없이 clone(->topic->push or review=팀원PR)
```
 ❯ mkdir team_py❯ cd team_py❯ git clone https://github.com/is3js/py.git .
```
해당 폴더로 이동후 수정하고 commit -> push까지해보자.
- 원래는 topic ->
```
 code .# main에서 바로 # 파일수정# add commit ->push
```
팀원이라면, 팀repo에 바로 push가 된다.

팀작업2: 내부팀원의 clone (local)에서 topic push로 PR권유 -> topic push한 사람만 PR요청 가능 -> 타 팀원review받기 (review안받을거면 main push했음)

topic push한 작업팀원만, 자신에게 PR권유를 확인 및 요청할 수 있다.

팀원은 fork필요없이 local clone후 main push해도 되지만, review를 받기 위해 topic push로 PR한다
1. user-login topic branch 생성
```
 git checkout -b user-login
```
2. login.py 생성 후 작업
3. add, commit, (topic branch) push
**팀원repo에 들어가도 **
- topic branch를 보낸 사람이 아니면.. PR권유가 안뜬다.
  - is3js(타팀원)
    - PR권유는 topic br push한 사람 자신에게만 보인다.
    - branch로는 보여도, PR은 타팀원이 결정안함.
  - is2js( topic br push한 작업 팀원)
topic br push를 pull request한다.
- 메세지에 코드리뷰 부탁한다고 남기자.

타팀원은 PR 불-> commit 메세지-> commit 클릭 -> 코드 리뷰

author가 아니더라도 모든 팀원들이 확인할 수 있게 ** **PR에 불이 들어와있다.
Merge를 누르기 전에 메세지에 달려있는 커밋까지 직접들어가서 코드를 살펴보자.
code line에서 +를 드래그해서 코드 리뷰를 해준다.
거절을 의미하는 코드 리뷰를 해주자.
- 코드리뷰한 것 바로 밑에 Reply도 달 수 있으니 확인하면된다.
- 코드 리뷰를 데면 우측에 Finish your review(1)가 뜬다. 클릭해서 리뷰를 끝내자.
코드 리뷰를 달면, 자동으로 작업 팀원에게 email도 보내준다.

(topic push ->PR했던) 작업 팀원은 확인해서 1) Reply + 2) local에서 추가작업 -> 3) topic br PUSH -> 4) 자동 PR timeline에 추가

거절성 코드리뷰에 대해 대답을 해주고
PR 날렸던 topic br로 다시 돌아와서
- 추가 작업을 함.
```
  ❯ git checkout user-login
```
다시 한번 topic br push하면, 추가 PR을 안날려도 자동으로 PR 타임라인에 추가된다.

타팀원의 2번째 review부터는 [작업팀원의 추가push]가 자동으로 PR timelien에 추가된다.

타팀원 화면에서는 작업팀원의 추가작업한 커밋 위에 View changes가 떠있다.
- 작업팀원이 커밋할 때
- 타팀원(리뷰팀원)화면

승인은 LGTM(looks good to me)

코드 리뷰를 다시 한번 남기고
finish your review에서 approve를 선택해주면 끝난다. 이 때 멘트는 LGMT를 많이 쓴다.

approval이 떴다면, 작업팀원이 merge PR해도 된다. 아무나 팀원이면 다된다. merge후에는 delete (topic) branch -> local code 최신화(git pull) -> local의 topic branch는 직접 삭제()

approve 확인되면
작업한 팀원이라도 merge시킬 수 있다.
작업이 끝난 topic branch를 삭제하라고 뜬다. 삭제한다.
로컬의 main 코드를 최신화하기 위해 main branch로 와서 git pull로 코드 최신화한다.
```
 ❯ git checkout main
```

로컬의 topic branch도 직접 삭제한다.

 ❯ git branch -d user-login
 Deleted branch user-login (was b7bde3a).

cf) 혹시 delete branch 안해서 서버에 남아있다면?

local branch 수동 삭제
remote 동기화로 삭제
```
 git remote update --prune
```

팀작업3: issue(개선기록) 와 PR(팀원1(주인)-수정용브랜치push PR / 팀원2-리뷰만) 실습

로컬 : git_seminar
원격 : CS100_Git in is2js
- 협동자: is3js

로컬 readme생성후 -> 원격 빈레포에 push로 시작. 1번째 가이드: …or create a new repository on the command line(init, readme push)

로컬에서, 빈 레포 생성시 주어지는 가이드1 번째인 …or create a new repository on the command line를 따라치기
```
 echo "# CS100_Git" >> README.md
 git init
 git add README.md
 git commit -m "first commit"
 git branch -M main
 git remote add origin https://github.com/is2js/CS100_Git.git
 git push -u origin main
```
- 아직 git init안한 상태에서
  - readme.md를 먼저 만들고,, 시작하네

원격레포에 issue생성: issue는 TODO list 역할이나 논의사항 정리용

원격레포의 issue 탭 > new issue 클릭
- readme.md 파일을 좀 더 구체적으로 작성해주라고 issue 생성하기
issue 오른쪽 사이드바에 보이는 Assignees를 클릭하여, issue해결자 10명 중 1명으로 나를 등록한다.

issue 해결 전에, collaborator 추가 (상대방은 메일로만 초대받음)

settings > manage access > add people
- is2js(tingstyle1@gmail.com, 현재) -> (시크릿창) is3js 계정 추가
  - is3js(is2js@naver.com)계정은 깃허브알림 없이 메일로만 초대장이 옴

로컬에서 생성 후 파일 수정하기: git checkout -b [생성후전환될 브랜치]수정용>

로컬(is2js)에서 feature/readMe 라는 파일 수정용 브랜치를 생성하자
```
 ❯ git checkout -b feature/readMeSwitched to a new branch 'feature/readMe'>glg # git log(HEAD -> feature/readMe, origin/main, main)
```
- branch 변경 후 git log를 확인하니 HEAD가 브랜치를 잘 따라오고 있다.

파일 수정후에는 add전 gitt diff로 어느부분 수정되어있는지 확인

 ❯ git diffdiff --git a/README.md b/README.mdindex 1743ce5..a6cac92 100644--- a/README.md+++ b/README.md@@ -1 +1,3 @@ # CS100_Git++This is CS100\ No newline at end of file

add - status - commit 단계를 거친다.
```
 ❯ git add README.md❯ git status
```

(PR날릴 브랜치는)순수 git commit후 메세지 작성되는 부분에 [- issue #번호] 삽입하여, 해당issue에 커밋 걸어주기

git commit만 입력하기
```
 > git commit
```
commit 메세지 작성 에디터에서 - issue #1의 관련된 issue 번호를 기입해주기
```
 ADD more description in README- issue #1
```
나중에 저렇게 삽입한 커밋속 issue #1지정 부분은 PR속에서 issue를 연결해준다.
- **즉, issue에 대한 하여 PR(팀원검토)시에는 `#번호`를 커밋메세지에 넣어두자.**수정용브랜치로>

원격레포에 없는 지만, push해주면 <알아서생성+PR권유>수정용브랜치>

로컬에서 원격레포로 수정용 브랜치를 push

 ❯ git push origin feature/readMeCounting objects: 3, done.Writing objects: 100% (3/3), 289 bytes | 289.00 KiB/s, done.Total 3 (delta 0), reused 0 (delta 0)remote: remote: Create a pull request for 'feature/readMe' on GitHub by visiting:remote:      https://github.com/is2js/CS100_Git/pull/new/feature/readMeremote: To https://github.com/is2js/CS100_Git.git * [new branch]      feature/readMe -> feature/readMe

github에 가보면,
- 새로운 브랜치 생성 확인: 로컬에서 수정용브랜치를 push해서 자동으로 생성한 것
- 현재는 main우주만 보여주고 있음. 수정한 평행우주는 브랜치를 선택해서 들어가야 보임

혼자는merge지만, PR은 를 팀원(collaborator)들에게 확인요청이니 메세지 한번더!수정용브랜치>

혼자 작업했다면,
- 로컬에서 수정용브랜치 -> main브랜치 merge하면 끝
여러명 작업시 merge대신
- 로컬에서 수정용 브랜치생성후 파일 수정
- 원격레포에 push하여 수정용브랜치 생성
- 합치기전에 PR과정을 전시하여 팀원들에게 확인받기

Compare & pull request 클릭
PR은 팀원확인요청이다. 로컬 커밋메세지가 default로 적혀있는데, 커밋메세지에 PR메세지로서 추가로 적어준다.
아래와 같이 커밋메세지 따로에, PR메세지가 덮어서 보인다.

PR을 검수할 팀원에게 review요청하기(수정용브랜치를 merge해도될지)

PR메세지 우측에 Reviewers가 있다. 여길 선택해서, PR review를 요청하자.

is3js(팀원)계정을 시크릿창으로 들어가보자.
- 레포 > Pull request > 해당PR까지 클릭하고 가야지 Review요청한 것이 보인다. (호버해도 보이긴하네)

리뷰요청받은 뒤 Add your review는 lineByline으로 피드백 주는 것

add your review 클릭
플러스버튼으로 피드백을 주면되는데 드래그로 여러라인에 대한 피드백을 줄 수 도 있다.

리뷰요청시 피드백(라인별코멘트)과 별개로, 칼을 뽑아야함: Approve(merge) or Request changes(다시push해)

코멘트를 다 남겼으면, 우측 상단에 Finish you review로 칼을 뽑아야한다.
- 이 경우 수정이 좀 더 필요하다고 하여 승인거절한다.내용없이 Reqeust changes 클릭
내가 남긴 코멘트의 위치 및 승인거절=변화요구의 메세지를 확인한다.

[로컬] review내용인 1) 라인별코멘트에 [대한 대답reply] & 2) 변화요구에 대한 [에서 수정후 다시 push]로컬>

라인별 코멘트에 대한 대답
리뷰어에 의한 Changes requested는 feature/readMe에 푸싱함으로써 커밋을 추가하라고 뜬다.
- reviewer에 의한 request changes는 <수정용 브랜치로 추가 커밋하면 다시 검토>를 말하는 것이다.
1. 다시 로컬 해당 브랜치로 와서
2. 요구대로 새롭게 작성후 push까지 해준다.
```
 # 파일 수정# add전 git gtatusgit status#git add 파일명git add README.mdgit commitgit loggit push origin feature/readMe
```

PR은 의 단위라서 아직 merge안됬다면, 해당브랜치는 이어지며 가서 확인한다.수정용브랜치>

git push origin feature/readMe를 통해 push했으면, 아직 해당 PR상황에서 커밋이 추가된다.
- main에서는 추가 PR 안내가 없음.
  - 수정용 브랜치에서는 평행우주의 내용은 변화되었음.
- reviewer에 의해 request changes는 <수정용브랜치로 추가 커밋하면 다시 검토>를 말하는 것이다.
  - 즉, 검토하고 있던 PR상황으로 다시 직접들어가보면, 추가 push를 확인할 수 있게 됨.
**의 추가push후**에는 되면 **또다시 review 요청해야한다.**수정용>

또다시 PR(수정용브랜치 merge검토)에 대한 review요청을 받음. -> LGTM approve해주기

역시 해당 PR까지 클릭해서 들어와야 보인다.
- add your review
  - 라인별 코멘트 -> 생략
  - LGTM(Loos Good To me)와 함께 Approve

review가 approve해야 드디어 merge가 뜬다. 동시에

우측의 Delete branch를 눌러 수정용브랜치를 삭제해주자.
PR탭은 Merged로 해결됨.

[issue탭]에서도 Merged가 뜸. -> [PR->merged]의 해결된 issue를 닫기

issue작성 후
- 수정용브랜치 생성
- PR를 위해 커밋
  - 커밋시 issue번호를 #번호형태로 커밋메세지 속에 남기면 issue탭에서도 표기가 된다.
수정용브랜치 push -> PR 생성 -> review -> merged로 해결되었으면 issue도 닫아야한다.
1. 메세지로 닫는다 알리기
2. Close issue를 눌러서 해당 issue를 닫는다.

[로컬]에서 default [main]브랜치로 옮겨와, PR->merged된 프로젝트 정보를 git pull로 내려받아서, 로컬에서도 통합 및 브랜치삭제가 반영되도록 한다.

삭제당한 feature/readme<수정용브랜치>가 아닌 default main브랜치로 옮겨와서 git pull받는다.

❯ git checkout main
❯ git fetch
❯ git pull # git pull origin main 으로 정확하게 표시하면 upstream설정이 안뜬다.
# 그러나 한번만 업스트림하면 되므로 그냥 해준다.
❯ git branch --set-upstream-to=origin/main main
Branch 'main' set up to track remote branch 'main' from 'origin'.
❯ git fetch
❯ git pull

Updating 99ce761..1ed16b7
Fast-forward
 README.md | 4 ++++
 1 file changed, 4 insertions(+)