프로그래밍 기초_Git_Github_4

____________________________________________________________________________________________________________

 

 

3주차

 

 

 

1. 협업을 위한 작업 관리 스킬을 익힙니다- PR과 commit 되돌리기, 임시 저장
2. 협업하기 좋은 사람이 되기 위해 기본 협업 매너를 익힙니다.
3. Github 으로 다른 사람과 소통합니다 - 내 포트폴리오, 오픈소스

 

 

 

__________________________________________

 

3-1 3주차 오늘 배울 것

 

 

 

첫 번째로 들어가기에 앞서, 1, 2주차 동안 배운 개념들을 다시금 복습해보자. 협업을 위한 기초 지식들이야.

 

——

 

<협업할 때의 프로세스의 큰 맥락>

 

1단계. 누가 이 작업 할 것인지 정한다. - Issue 

2단계. 각자 맡은 것을 작업한다. - Branch 

3단계. 각자 작업을 프로젝트에 합친다. - merge 

(경우에 따라). 작업한 내용을 리뷰하고 최종적으로 프로젝트에 반영한다. - PR 후 merge

 

 

 

<키워드들>

 

issue 는 내가 할 작업, 기능 추가, 버그 리포트 등 여러 방식으로 사용할 수 있어.

 

협업을 하기 위해 issue 를 만들어 누가 작업할지 정하고, 브랜치를 만들어 작업할 공간을 나눠야 해.

 

— 등등. 이하는 교제 노션 참조. —

——

 

 

 

——

< 3주차 동안 배울 것들 >

 

협업 과정에서 내 작업을 반영해달라 요청하는 PR과 commit 을 되돌리고 임시로 저장하는 방법을 배워보겠어.

=> 주요 키워드 : PR, 

Commit 되돌리기 - amend, revert, reset , 

작업내역 임시 저장 - stash

 

 

Git 을 이용해 협업하는 과정에서 지켜야 할 매너들. 

좋은 작업 내역을 남기기 위해 commit 단위 관리, 메시지 작성과 다른 사람에게 프로젝트 소개하는 방법을 알아보자.

=> 주요 키워드 : 

commit 메시지 컨벤션, 

gitignore, README

 

 

개발자들은 진짜 개발 정보를 어떻게 찾을까. Github 에서 내가 참고하기 좋은 코드, 기술 트렌드 정보를 얻는 방법을 알아보고,

오픈소스에 대해서도 집고 넘어가자.

=> 주요 키워드 : 

github exprore , 

오픈소스(open source)

 

 

마치 포트폴리오를 작성하듯, git 으로 개발자인 나를 나타내보자. Github 에서 profile, 프로젝트 소개, 개발 블로그를 작성하는 방법을 알아보자.

=> 주요 키워드.: github profile , repo 소개 , github page

——

 

 

 

 

 

 

 

__________________________________________

 

3-2 내 작업을 반영해 주시겠어요? PR 01

 

 

 

PR 이란?

=> 작업내역을 프로젝트에 반영하는 것이 아니라 충분히 리뷰받고 최종적으로 프로젝트에 반영하는 단계.

3단계 대신 사용한다고 생각하면 편해.

 

——

1단계. 누가 이 작업 할 것인지 정한다. - Issue 

2단계. 각자 맡은 것을 작업한다. - Branch 

3단계. 각자 작업을 프로젝트에 합친다. - merge 

👉 (경우에 따라). 작업한 내용을 리뷰하고 최종적으로 프로젝트에 반영한다. - PR 후 merge

——

 

 

——

< Pull Request > 

 

PR(Pull Request, 풀리퀘스트) 는 내 작업내역을 바로 merge 하지 않고, 

참여하고 있는 프로젝트에 내 작업(branch)를 merge해달라고 요청(Request) 를 먼저 보내는 것.

=> 즉, 프로젝트의 퀄리티를 유지하기 위해 merge를 가려서 받는다는 거지.

=> 작업한 내용에 대해 코드 리뷰를 하거나 같이 토론하면서 개선시킬 수도 있어.

프로젝트 기준에 맞지 않는다면 PR 은 거부(reject) 될 수도 있으니 주의.

 

 

  0. 저번 2주차 마지막 수업에서 < feature/jjim > 를 원격 저장소에 무사히 push 했다면, PR이 생성되어 있을 거야.

1. 브랜치 선택 아이콘을 클릭해서 main이 아닌 < feature/jjim > 브랜치를 선택하고, Pull request 버튼 클릭. 
2. 세부 사항을 작성하고 base 로 삼을, 즉 merge 할 브랜치를 잡아 준 후 create pull request
3. 그 후 pull request 탭에 새롭게 생성된 pr 을 클릭해 들어간 후 피드백 과정을 거치고 나서 Merge Pull Request 를 하면

최종적으로 main 브랜치에 merge가 됨.

1. 마지막으로, 원격 저장소의 최신 기록을 내 로캘 저장소에도 pull 로 반영해주기.

=> sourcetree를 켜서 페치(fetch) 를 눌러줘. 

pull은 commit 내역을 가져와서 로컬 branch 에 commit 을 합친다면, fetch 는 연결되어있는 원격 repo 의 commit 내역을 가져만 와.

원격 repo 의 commit 내역을 합치지 않고 보기만 할때 주로 사용.

 

Pull 과 다르게 fetch 는 임시적으로 원격 저장소에 무엇이 더 추가적으로 커밋이 달려 있는지는 보기만 하는 것이고, 실재로 내 로컬 저장소에

반영이 된 상태인 것은 아냐.

 

1. 이제 로컬 저장소에서 main 브랜치로 체크 아웃 한 후,

상단 “풀” 아이콘을 클릭하고 위쪽의 세 항목을 체크한 후 확인 누르기.

 

1. 이렇게 pull 을 받아온 후 커밋을 생성한 뒤, 다시 push 를 해주자.

그리고 사용하지 않는 브랜치는 (즉, 모든 사항을 무사히 main 브랜치에 반영해서 더이상 쓸 일이 없는 브랜치) 삭제 해주자.

——

 

 

 

 

 

 

 

 

__________________________________________

 

3-3 내 작업을 반영해 주시겠어요? PR 02

 

 

다른 repo 에 PR 하기 - fork 개념탑재

 

 

ork(포크) 는 원본 소스코드를 복사해서 새로운 독립적인 소프트웨어로 개발하는 것을 이야기 해.

마치 어떤 문서를 복사해서 그 위에 내가 원하는대로 수정해서 사용하는 것과 비슷하다고.

 

 

다른 repo에서 PR 하기 => 이것도 fork를 하고 나서 이후 과정은 같은 repo에서 PR하기 와 비슷.

단, 여기서는 내가 merge 할 권한이 없으므로 repo 관리자의 merge pull request (PR merge하기) 를 기다려야 해.

* 여기 실습에서는 PR하는 것까지만.

 

 

——

 

1. 먼저 fork 할 원본 저장소에 접속.

=> 실습에서는 https://github.com/siyoungoh/kimchi-recipe-os

1. Issues 탭에 댓글을 달아보자. 실재로는 해당 이슈가 나에게 할당되었음을 확인하고 작업해야 하겠지만.
2. 그런 다음 해당 원격 저장소의 우측 상단에 있는 fork 클릭.
3. 이제 내 원격 저장소의 목록에서 fork 해 온 원격 저장소를 확인할 수 있어.

 

1. Fork 해 온 원격 저장소에는 당연히 내가 마음대로 push할 수 있는 권한이 없어.

따라서 clone 으로 작업물을 내 로컬 환경에 가져온 뒤 PR 을 보내.

 

1. fork 해 온 원격 저장소의 Code 버튼 클릭 -> 링크를 복사. 

소스트리 기본창의 상단 새로 만들기 -> URL에서 복제 -> 원본 URL에 복사 경로 붙여넣기.

 

1. Clone 해 온 원격 저장소의 워크 스페이스에 접속, 히스토리의 최상단 커밋에 우클릭, 새 브랜치 생성.

내가 작업할 브랜치를 만드는 거야.

 

1. 만든 브랜치에서의 작업이 끝나면, 해당 브랜치를 push 해보자. 원격 경로는 애당초 fork->clone 으로 가져온 것이기에 자동으로 설정되어 있어.
2. 실재로 fork 해서 등록한 원격 레포에 들어가 보면 pr 이 등록되어 있어.

 

——

 

 

 

 

 

 

__________________________________________

 

3-4 최신 커밋 고치기.

 

 

 

사람이다보니 commit 을 실수할 때가 있어. 때문에 commit 을 되돌리는 방법들에 대해 알아놔야 해.

중요한 것이, 이 커밋 되돌리기는 다른 사람들과 함께 작업하는 저장소일 경우 다른 사람들에게도 영향을 미칠 수 있어.

따라서 기본적으로는 나만 작업하는 내 개인적인 branch 를 대상으로만 커밋 되돌리기를 한다, 라고 생각해야 해.

그렇기 때문에 우리는 항상 브랜치 단위로 풀 푸쉬를 하는 것이고, PR을 날리는 거야.

 

 

 

< amend > 

 

최신의 commit을 수정하는 것을 amend(어맨드,고치기) 라고 해.

Amend 는 가장 최신의 commit 만을 고칠 수 있어.

 

 

 

Kimchi-recipe 깃 프로젝트 선택해서 실습 작업해보자.

 

——

< push 전 amend - 실습 >

 

1. < tutorial/back-to-the-future > 브랜치 만들기.
2. < tutorial/back-to-the-future > 브랜치 체크아웃 후, 아무 파일이나 2개 변경 사항 발생시키기.
3. 파일 상태에서 commit 을 할 건데, 두개 다 가 아니라 한 파일만 커밋.

 

2개의 파일 의 변경 사항을 한 번에 commit 해야 하는데, 실수로 하나만 커밋한 상황. 이제 직전의 commit 을 수정해보자.

 

1. ‘파일 상태’ 탭 창 상태에서 커밋 메세지 란에 커서를 두면, 메세지 란의 우측 상단에 ‘커밋 옵션’ 이 있어.

옵션 중 “마지막 커밋 수정” 을 클릭.

1. 마지막 커밋 수정을 누르면 마지막 커밋의 메세지가 메세지란에 떠. 이 상태에서 미처 커밋하지 못했던 다른 하나의 파일도 체크하고,

메세지도 알아볼 수 있게 수정하거나 해서 “커밋” 클릭.

1. “주의 - 이력 변경” 이라는 알림창이 발생. 여기서 “확인” 을 누르면, 실제로 마지막 커밋의 내용이 변경되서 다시 저장.

 

——

 

 

 

——

< push 후 amend - 실습 >

 

=> push 후에도 push 한 commit 을 되돌릴 수 있어.

강제로 commit 을 덮어씌우는 것과 같은데, 이걸 force push(강제 푸시) 라고 한다고.

 

 

1. < tutorial/back-to-the-future >  브랜치를 원격 저장소에 push.

=> 실재로 원격 저장소에 브랜치가 추가되고, merge 하고 싶으면 리퀘스트 넣으라면서 PULL request 도 활성화.

 

1. 이미 푸쉬한 커밋을 수정하려면 ‘강제 push’ 라는 걸 사용해야 해. 헌데 이게 워낙 위험한 기능이다보니 숨겨져 있어.

 

소스트리 기본창 설정 (소스트리 기본창 활성화 시 상단 메뉴바에서 sourcetree 선택, 설정) -> 

preferred language 언어를 영어로. -> 소스트리 재실행 -> 상단 메뉴바에서 소스트리 -> 프리퍼런스(설정) -> 

상단 메뉴 아이콘 중 최우측 advanced -> “ Allow force push “  체크. 이게 강제 푸쉬. -> 다시 설정에서 언어를 한국어로 변경.

-> 종료 후 다시 kimchi-recipe 프로젝트 들어가 보면 상단의 필드 중 “ 원격 브랜치 표시 “ 라는 게 생겼을 거야.

 

 

1. 파일 상태 -> 커밋 메세지 -> 커밋 옵션, 마지막 커밋 수정 선택 -> 메세지만 수정하고 커밋 확인.
2. 다시 해당 브랜치가 체크아웃 된 상태에서 push 를 해보자. 추가 수정을 발생시킨 점 이외에는 1번 상황과 같아.

 

1. ‘푸시’ 아이콘을 클릭하고 < tutorial/back-to-the-future >  브랜치를 푸쉬하려고 하는데, 푸시를 누르면 뜨는 모달창의 아래쪽에

“강제 푸시” 가 생겨 있어. 이걸 체크하고 확인. 그러면 경고창 뜨는데, 확인. 그럼 강제 푸쉬가 실행.

——

 

 

 

 

 

 

 

__________________________________________

 

3-5 commit 되돌리기 - revert, reset

 

 

앞서 배운 amend 는 가장 최신의 commit 만 되돌릴 수 있고, 어떤 부분을 되돌렸는지도 알 수 없어.

그에 반해, 어떤 내용을 되돌렸는지 새로운 commit을 남기는 것을 revert(리버트) 라고 해.

또한 revert 는 최신 커밋 뿐 아니라 그 이전의 commit 들도 되돌릴 수 있어.

 

——

< revert 첫 실습 >

 

1. Commit 을 되돌리고 싶은 브랜치로 체크아웃. < tutorial/back-to-the-future >
2. 히스토리에서 내가 되돌리기를 원하는 시점의 커밋 우클릭 -> 커밋 되돌리기
3. 해당 실습에서는 amend 테스트 용으로 commit 했던 항목을 우클릭해서 되돌리기.

=> 이렇게 하니 해당 커밋을 하기 전 상태로 파일들이 되돌아 갔어.

——

 

 

그런 다음, 우선 여기까지 < tutorial/back-to-the-future > 작업한 것들 push 한 번 해주자.

다음으로, 이번에는 reset 이란 걸 해보자.

 

 

——

옛날 작업 내역으로 되돌리고 싶어요 - < reset(리셋) >

 

reset (리셋)은 commit 했던 작업내역을 말 그대로 리셋시키는 것.

‘기억이 리셋되었다' 가 '기억이 없다'는 말인 것 처럼. 

과거로 돌아가서 새로운 삶을 사는 것처럼 reset 이후에 작업내역은 없어진 commit 기록과 관계가 없음.

 

 

1. < tutorial/back-to-the-future > 체크 아웃.
2. 두 개의 텍스트 파일에 내용을 추가로 기입
3. 두 개를 따로 따로 하나씩 커밋.
4. 히스토리에서 첫 번째 커밋 사항에 우클릭 -> “초기화” 클릭. 사용 모드는 mixed.

=> revert 는 해당 커밋을 실행하기 전의 상태로 돌아가지만, reset 은 해당 커밋까지만 반영된 순간으로 돌아가.

1. 우리가 mixed 라는 걸 사용했기 때문에 작업 내역은 남아있어. 따라서 두 번째로 발생했던 변경 사항이 파일 상태에 그대로 남아있어.

 

1. 이후에 다시 두 번째 변경 사항을 다시 커밋 해보면, 리셋 전에 커밋했던 히스토리는 사라지고 리셋 후에 다시 커밋한 히스토리만 남아있어.

 

1. 다시, 첫 번째 커밋 사항에서 우클릭하고 “초기화” -> 사용모드 ‘hard’ 선택. 이건 작업 사항도 다 되돌려버리는 거야.

=> 이러면 첫 번째 커밋 사항만 히스토리에 남고, 두 번째 커밋은 히스토리도, 변경 사항도 다 날아가. 아주 무서운 기능이지.

——

마지막의 하드 리셋은 ‘강제 푸쉬’ 로 원격 저장소에 올려야 해. 그래야 리셋된 사항이 강제로 반영되겠지.

 

 

 

 

 

 

 

 

__________________________________________

 

3-6 변경사항 임시 보관하기 - stash

 

 

stash(스태시) 는 숨겨두거나 넣어둔다는 뜻.

프로젝트의 변경사항을 임시적으로 보관해둘 때 사용해.

예를 들면, 다른 branch 로 체크아웃 하는 경우 현재 branch 의 변경사항이 사라지게 되겠지? 아직 작업 중이라서 commit 하지 않고 

변경사항만 보관해두고 싶을 수 있겠지. 이 때 commit 대신 stash 를 사용.

=> 다른 일을 하기 위해서 잠시 물건을 올려 둔 선반과 마찬가지.

 

 

 

1. < tutorial/back-to-the-future > 체크 아웃.
2. 임시적으로 작업 내역 만들기. 변경 사항 하나 만들어.
3. 급하게 main 브랜치로 와서 작업해달라 요구가 들어왔다 가정.
4. 히스토리에서 현재 변경 사항이 한창 일어나고 있다는 의미의 ‘uncommitted changes’ 를 선택하고 상단 아이콘 중 ‘스태시’ 클릭.
5. 스태시의 내용을 입력해주고 확인을 누르면, ‘uncommitted changes’ 는 사라지고 완료된 commit 들만 보이는 상태가 되.

=> 실재로 변경 사항이 발생한 파일의 작업 내역도 사라져 있어.

git이 작업 내역 자체를 잘라내서 따로 보관해 둔 거야.

이 상태에서 main 이나 다른 브랜치로 체크아웃해서 원하는 작업을 할 수 있는거지.

 

1. < tutorial/back-to-the-future > 로 다시 체크 아웃
2. 왼쪽 카테고리 중 아래에 ‘치워두기’ 라는 아이콘이 있어. 해당 카테고리를 펼쳐 보면 아까 stash 로 저장해 둔 사항이 남아있어.
3. 해당 사항을 우클릭 -> 스태시 적용.  다시 되돌린 뒤에는 딱히 더는 필요없다는 스태시 삭제.
4. ‘파일 상태’ 에 가보면, 스태시에 일시적으로 저장해 두었던 변경 사항이 되돌아 와 있음을 확인할 수 있어.

 

 

 

 

 

 

 

 

__________________________________________

 

3-7 작업으로 의사소통 하기

 

 

 

commit 으로 소통하기 - commit 메시지, 단위.

=> commit 메세지에도 작성하는 규칙, 즉 프로토콜이 있어. 우리는 이를 ‘컨벤션’ 이라고 표현해.

조직마다, 회사마다 조금씩 다를 수 있어. 

 

 

——

— commit 메시지 템플릿 적용하기 —

 

1. 소스트리 키고 맥 화면 상단의 메뉴바에서 설정 -> 상단 메뉴 ‘커밋’ 아이콘 선택 -> 코드 스니펫에서 다운받은 템플릿 txt 가져오기

-> 이후 설정창 끄고 변경 사항 add 후 commit 할 때 보면 설정해 두었던 양식이 commit 메세지 창에 작성되어 있을거야.

——

 

가장 중요한 것은, “이 작업을 왜 하는가, 무엇을 하는 건가” 라는 것. 

프로그래밍이란 것은 결국 문제 해결의 과정이고, 그 과정에서 협업자들과의 커뮤니케이션이 중요한 거야.

 

 

 

 

 

 

 

__________________________________________

 

3-8 코드 리뷰로 서로에게 피드백 주기.

 

 

 

코드 리뷰란?

=> 주로 PR 한 내역에서 댓글을 달면서 리뷰를 남기는 방식을 많이들 시행하긴 해.

 

 

코드리뷰를 하는 이유!

 

 

Google 코드 리뷰 가이드 문서

=>. https://google.github.io/eng-practices/review/

 

 

 

 

 

 

 

 

 

__________________________________________

 

3-9 Git 프로젝트 관리 - gitignore

 

 

 

.gitignore 란.

 

——

보안상 다른 사람과 공유하면 안되는 내용(비밀번호, API key 등)들은 전체 공개할 수 없어.

또한, 내 컴퓨터에만 해당되는 설정들은 협업하는 다른 사람에게는 똑같이 적용되지 않을 수 있어.

각 컴퓨터마다 설정이 다른데 내 설정파일까지 Git 에 올리면 다른 사람의 설정과 충돌이 날 수 있어.

 

그럼 이런 파일들은 어떻게 관리하면 좋을까?

 

공유하거나 공개되면 안되는 파일들은 공개된 repo 즉, 공개 Github repo 에 올라가면 안될테니, 

Git 이 마치 이런 파일들을 없는 것처럼 무시하게 하는 설정이 바로 .gitignore 

 

파일명을 .gitignore 로 만들고 여기에 Git 이 무시해야할 파일 또는 폴더이름을 적어주면 오케이. 그리고 나서 내 프로젝트의 최상위 폴더에 저장하면 끝!

——

 

 

——

1. Git init 이 설치된 깃 프로젝트에서 touch .gitignore   로 파일 생성. 확장자는 명시하지 마.

=> 예제의 경우, kimchi-recipe 라는 폴더 안에 .git 도 .gitignore 도 다 숨김파일로 존재.

1. < main > 브랜치 체크아웃 상태에서, 현재는 ‘파일 상태’ 에 .gitignore 만 추가된 상태.
2. 이 상태에서 프로젝트 안에 test.txt 파일 생성.
3. 이러면 소스트리의 워크 스페이스 - 파일 상태에는 .gitignore 와 test.txt 두 개가 보일텐데, test.txt 를 보이지 않게 할거야.
4. .gitignore 에 들어가서 (참고로, 깃 이그노어는 항상 프로젝트의 최상위에 위치해야 해)

test.txt 라고 적고 저장. 이는 “해당 파일은 커밋에 포함시키지 않겠다” 라는 뜻.

1. 이제 소스트리 워크스페이스에 가면, “파일 상태” 탭에 “test.txt” 가 사라져 있어.

=> 실제로 test.txt 는 존재하지만, git은 이 파일은 인식하지 못해. 물론 .gitignore 를 수정해주면 다시 인식할 수 있게 되겠지.

——

 

 

 

— 실제 개발 환경처럼 gitignore 세팅하기 —

=> 실제 개발 환경에서는 프로그래밍 언어와 선택한 기술의 특성에 따라 설정 파일들이 많아.

이 설정 파일은 올리면 다른 사람의 설정이 꼬여서 귀찮아 질 수 있겠지.

그래서 이런 설정 파일들을 gitignore 에 편하게 적기 위해 설정을 검색할 수 있는 사이트가 있어.

=> https://gitignore.io

 

 

 

 

 

 

 

 

__________________________________________

 

3-10 Git 프로젝트 관리 - README

 

 

프로젝트 안내 적기 - README.md

 

README 는 한국어로 나를 읽어주세요 정도. 프로젝트나 소프트웨어 사용할 때 먼저 읽어야하는 정보를 적어두는 파일.

Github 프로젝트에서도 README.md 를 만들어 프로젝트 안내글을 적어둔다고. 

프로젝트의 어마어마하게 많은 파일들을 하나하나씩 다 읽어볼 수는 없으니 꼭 이런 안내 파일이 있는게 좋겠지?

 

 

 

https://github.com/ohahohah/readme-template

=> 교재에서 제공하는 readme 마크다운(참고로 md 는 마크다운의 약자) 양식.

해당 원격 저장소의 README.md 파일을 클릭하고 내용 섹션의 우측 상단 ‘raw’ 를 클릭하면 실제 내용물 열람 가능.

이걸 복붙해서 써도 괜찮아.

 

 

마크다운이란.

——

markdown 은 서식이 적용된 텍스트 파일.

보통 텍스트 편집기로도 사용할 수 있지만, markdown 문법을 제공하는 편집기를 사용하면 서식이 어떻게 적용되는지 한 눈에 볼 수 있어.

=> 깃허브에는 기본적으로 마크다운 언어를 해석해주는 프로그램이 탑재되어 있다고.

——

 

 

——

< 실습 >

 

전제로서, 처음 원격 저장소를 만들 때 “Add a README file” 을 체크하던지, 이미 만들어져 있는 저장소의 Code 탭 -> README 만들기 하던지

 

원격 저장소에서 README 를 열람한 다음 수정을 할 수 있어.

——