📌 사용계기

깃헙에서 같은 형식의 이슈를 자주 발행하거나 형식을 공통화 시킬 때를 위해 이슈 템플릿을 만들어 쓸 수 있는데

혼자 공부할때도 형식을 통일시켜 깔끔하게 써보기 위해 적용하려고 한다.

📍 적용과정

1. github > setting

2. general에서 화면을 내리면 features 구간이 있는데 여기서 set up templates를 누른다.

3. Custom template를 선택

4. 그러면 아래처럼 나오는데 Preview and edit을 클릭

5. 아래처럼 화면이 펼쳐지고 연필을 클릭해 수정하면 된다.

6. 예시)

7. 모두 수정했으면 Propose changes를 클릭

8. 템플릿 업데이트에 대한 Commit 메세지를 결정하여 commit해준다.  

9. 그러면 이슈를 발생할 때마다 이런 화면이 나와서 템플릿을 선택할 수 있게 되고

10. 템플릿이 적용된다!

끝!

뭔가 실수를 했다면 Commit을 돌려 과거의 상태로 돌아가면 된다. 그러나 주의해야 할 것이 있다.

* Commit 되돌리기 주의할 점 

여러명이 작업하는 브랜치의 commit을 되돌리면 다른 사람의 commit 히스토리도 바뀌어버리게 된다. 

하지만 실시간으로 사람들이 업데이트 하기 힘들고, 이미 잘못된 commit을 기반으로 작업에 들어갔을 수도 있다.

그러면 다른 사람의 작업 commit history가 다 엉키게 된다. 

따라서 commit을 되돌기는 작업은 나만 작성하는 특정한 브랜치에 딱 하나에만 적용해야 된다. 

amend란? 

가장 최근 commit 고칠 수 있다. 

amend 실습 (push 전)

1. 실습할 브랜치를 생성하고

수정 파일을 2개 만들고  그 중 하나 커밋을 하나 추가한다.

2. 커밋 옵션에서 마지막 커밋 정정을 클릭

3. 올리지 않은 수정사항을 add해서 마지막 커밋에 대한 수정을 한다.

+? 근데 수정은 이렇게 안올린 거에 대해서만 올릴수 있나 이미 올린걸 내릴 순 없나?

4. 보면 변경되어진 커밋에 2가지 파일이 add되게 수정된걸 확인가능

amend 실습 (push 후)

push후 amend하는건 강제 푸시로 진행하는데 이건 강제로 덮어버리는거라 꼭 나만 사용하는 브랜치에만 적용하자

0. 강제 푸시는 기본 설정상 막혀 있기 때문에 도구 > 옵션 에서 가능하도록 설정해야 한다.

1. 푸시한 커밋 메시지를 수정하기 위해 커밋 옵션 > 마지막 커밋 정정을 눌러 마지막 커밋을 불러온다.

2. 메시지를 수정하고 커밋

3. 강제 푸시 옵션을 선택해 푸시를 해본다. 

* 협업을 위한 작업(commit)관리

- 협업에서 자주 일어나는 시나리오 상상하며 내 작업을 반영해달라고 요청하는 PR과 commit을 되돌리고 임시로 저장하는 방법 배우기

PR (Pull Request)이란?

자신의 작업내역을 바로 merge하지 않고, 프로젝트에 내 작업(branch)를 merge해달라고 요청하는 것을 말한다.

실전 사용 회화 :

* (오픈소스에서) 프로젝트 제안 사항이 있으면 PR 날려주세요.

* (회사에서) OO씨, PR 날려주세요. 코드 리뷰해드릴게요.

PR 실습

1. merge하려는 branch로 들어가 다음과 같은 버튼을 누른다 

2. 창이 바뀌면서 상단에 표시되는 것을 보면 3가지를 확인 할 수 있다.

① 합쳐질 브랜치    ② 합칠 브랜치  ③ Merge 가능여부

그리고 무엇을 추가했는지와 적절한 메시지 혹은 양식에 맞게 써서 풀리퀘스트를 생성한다.

3. PR을 날리면 아래와 같이 커뮤니티 기능을 사용할 수 있으며 PR이 생성된 상태에서  merge 전까지 추가된 commit도 이 대화에 나타난다

4. merge pull request를 눌러 merge한다

(conflict가 존재하면 다른 메세지가 뜬다) 

5. 바로 이 영역이 바뀌며 merge 메세지를  입력할 수 있게 된다. 

메세지 확인하고 버튼 클릭

6. 아래와 같이 보라색으로 바뀌며 해당 브랜치를 지울건지 묻는다. 

이 자리에 생기는 restore 버튼으로 다시 살릴수도 있다. 

7. 소스트리로 와서 패치를 누르면 리모트 내용이 보여진다 (마치 새로고침처럼)

pull처럼 로컬에 반영하는게 아님

8. 깃헙에서 main으로 merge했으니 main에 적용하기 위해 main에 checkout한다.

현재 로컬 브랜치는 원격 브랜치보다 3개 뒤쳐저있다. 

pull로 당겨오면 

합쳐진 것을 확인 할 수 있으며 origin/main 네임택 부분은 PR 때문에 생긴건데 이것도 푸쉬해주고 나면 

이렇게 네임택이 나란히 따라오게 된다. 

9. 사용을 다한 브랜치는 지워준다. 

내 작업을 다른 리포지토리에 PR을 날리는 실습

fork (포크)란?) 

repo의 사용권한이 다른사람에게 있을때 (ex. 오픈소스) 프로젝트 제안할 때는 일단 프로젝트의 내용을 내 공간으로 가져와야하는데 fork란 원본 소스코드를 복사해 새로운 독립적인 소프트웨어로 개발하는 것을 말한다.

이름 왜 포크가 되었냐 하면 하나의 길에서 여러갈래로 나오기 때문이다. 우리가 사용하는 포크처럼 말이다. 

내가 주인이 아닌 다른 repo에 PR을 하려면 fork(포크, 일종의 프로젝트 복사)가 필요하다. 

실습) 

1. PR날릴 repo에 참여의사 댓글을 단다 

2. 포크 버튼을 누른다. 

3. 포크를 생성한다

4.  나의 리포지토리에 포크를 생성되면 앞에 포크 표시와 바로 아래에 어디서 포크를 해왔는지 알수 있다. 

5. 이 repo를 clone해 온 다음 거기서 작업을 하고 push를 한 다음 PR을 날리는 단계로 진행된다. 

이제 repo를 clone하는 것 부터 시작해보자. 

6. 작업할 브랜치를 생성한다.  (브랜치명 : 기능/이슈번호_특징

    작업을 수정하고 커밋한 후에 푸쉬까지 진행한다 

7. 포크된 github repo로 돌아가 PR을 날린다 

8. PR 날리는 것은 끝났다. 액세스 권한이 없기때문에 평가를 기다리거나 머지되는 것을 기다리면 된다.  

원격 repo와 branch 

tracking 이야기를 하면서 사실 이건 branch tracking이라고 해야한다는 말씀을 하셨는데

그 말 그대로 원격 repo와 로컬 repo의 연결은 사실 repo자체 끼리 연결보다는 로컬 repo의  브랜치와 원격 repo의 브랜치가 연결된 것이다. (따라서 브랜치 단위의 연결인 것이다)

branch tracking 실습

1. 일단 히스토리를 보면 로컬 main 브랜치가 원격 브랜치인 origin/main 보다 17개의 커밋이 앞서고 있는 걸 볼 수 있다.

일단 이 표시가 나오는 거 자체가 main이 origin/main을 tracking하고 있다는 증거가 된다.

서로 연결된것 끼리의 차이를 보여주기 때문이다. 

2. 푸시를 해준다

3. 원격 브랜치가 따라온 모습을 확인할 수 있다. 

새로운 원격 리포 브랜치에 tracking 실습

1. 브랜치를 생성해 커밋을 해준다.

2. 새로 연결할 브랜치에 checkout 한 상태인지 확인하고 바로 푸시를 누른다.

    일단 체크하면 로컬 브랜치와 동일한 이름이 작성된다. 변경을 원한다면 원하는 이름으로 바꿔 쓰면 된다.  

3. origin에 새로운 브랜치가 생성되어 네임택이 달린걸 확인 할 수 있다. 

깃헙에서도 아래와 같이 두군데서 브랜치가 늘어난 걸 확인가능! (노란 compare & pull request는 3주차에서!)