[스파르타] 협업을 위한 Git 활용 기초 3주차 (완강)

1. 수업 후기

 

• 강의 개수: 15개
• 총 강의시간: 3시간 18분
• 수업 목표:
• 1. 협업을 위한 작업 관리 스킬을 익힌다. - PR과 commit 되돌리기, 임시 저장
• 2. 협업하기 좋은 사람이 되기 위해 기본 협업 매너를 익힌다.
• 3. Github으로 다른 사람과 소통한다. - 내 포트폴리오, 오픈소스

 

드디어 Git 강의 완강! 2주차까지 듣고서 중간에 팀 프로젝트가 있어서 거의 일주일 동안 듣지 못했다. 여기 강의에서는 Sourcetree를 이용해서 했는데, 실제 팀 프로젝트에서는 Pycharm의 터미널을 이용했기 때문에 일주일동안 소스 트리는 사용하지 않았다. 그래도 핵심 개념은 동일하니, 소스 트리로 배우면 GUI이므로 좀 더 직관적으로 이해할 수 있어서 좋았다. 아무것도 모른 상태에서 터미널을 쓰면 약간 끼워 붙이는 방식이다. 저번에 됐으니까 그 패턴을 그대로 외워서 적용했던 느낌. 

 

실제로 팀 프로젝트 진행하면서 각자의 코드를 커밋하고 푸시하면서 충돌도 엄청 발생했다. 특히 app.py 파일을 각자 수정하고 올리다보니, 하루에 최소 한 번씩은 충돌이 일어났던 것 같다. 사실 버전 관리 툴보다는 협업 기능을 더 많이 썼다. 난감했던 상황은 Pull을 할 때 현재 작업으로 커밋이나 스태시, 되돌리기 등을 하라는 경고창이었다. 커밋을 하기엔 너무 미완성된 코드가 많았고, 스태시랑 되돌리기는 무슨 기능인지 몰라서 인터넷에 찾아봤지만 함부로 누를 수는 없었다. 나뿐만 아니라 다른 팀원들도 마찬가지였는지, 우리는 각자 푸시할 때 자신의 화면을 공유해서 팀원들 전체가 그 과정을 지켜보곤 했다. 가끔씩은 모두가 사고 발생의 목격자가 되었다. 그럼 또 다른 팀원이 도와줘서 되살리고, 어쩔 때는 로컬 파일들을 전부 날리고 도저히 수정할 수 없어서 다시 클론했다. 푸시할 때는 단톡방에 이제 푸시합니다! 하고 올려서 충돌을 막으려 했다. 

 

이렇게 첫 번째 팀 프로젝트에서 Git을 사용해봤는데 신기했다. 협업하고 바로 눈에 보이는 결과물이 나온다는 것도 새로웠다. 이번 강의에서는 소스트리로 사용해서 터미널 사용법은 더 연습해야겠지만, 개념은 이해했으니 다음 팀 프로젝트 시작 전까지 관련 명령어를 공부해야겠다.

 

 

2. 수업내용 정리

3-1. 3주차 오늘 배울 것

01. 지난 시간 주요 개념 복습하기 - 협업 위한 기초 개념!

 

• 2021.12.29 - [분류 전체보기] - [스파르타] 협업을 위한 Git 활용 기초 2주차 (완강)

 

02. 오늘 배울 것 - 모두를 위한 Git

 

• 1. 협업을 위한 작업(commit) 관리
• 주요 키워드: PR, commit 되돌리기(amend, revert, reset), 작업내역 임시 저장(stash)
• 2. Git 프로젝트 관리 - 협업 매너
• 주요 키워드: commit 메시지 컨벤션, gitignore, README
• 3. 오픈소스로 정보 탐색하고 함께 즐기기
• 주요 키워드: github exprore, 오픈소스(open source)
• 4. Github으로 개발자인 나를 나타내자 - 포트폴리오
• 주요 키워드: github profile, repo 소개, github page

 

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

01. PR이 무엇인가요? - 개념 탑재

 

• 누가 할래? (Issue) - 각자 작업하기 (Branch) - 각 작업물 병합 (Merge) - 리뷰 후 병합(PR)
• PR(Pull Request, 풀리퀘스트): 내 작업(Branch)을 바로 병합하지 않고 요청(Request) 먼저 보내는 것.
• 프로젝트 품질을 관리하는 회사나 오픈소스에서는 PR 후 merge 하는 과정을 거친다.
• 실전 사용회화:
• (오픈 소스에서) 프로젝트 제안 사항이 있으시면 PR 날려주세요.
• (회사에서) OO씨, PR 날려주세요. 코드 리뷰 해드릴게요.

 

02. 같은 repo에 PR하기 실습

 

• 우리가 해야될 작업: PR(병합 전 merge 해도 될지 물어보고 하는 것)
• 자신의 Github에 접속 - Pull request - Create pull request - Merge Pull Request - (로컬) Fetch
• base: merge를 할 브랜치. main 따로 선택 안했다면 자동으로 해당 repo의 기본 브랜치 보임. 우린 main.
• compare: base에 합치고 싶은 브랜치
• Create pull request: PR 생성하기. 브랜치 단위로 병합함.
• 그 다음 로컬 repo로 fetch(페치) 후 pull 해오면 끝!
• pull: commit 내역을 가져와서 로컬 branch에 commit 을 합치는 것.
• fetch: 연결되어있는 원격 repo의 commit 내역을 가져만 온다. 원격 repo commit 내역 합치지 않고 보기만.
• 정리하자면 원격 repo에서 pr 후 merge 해서 그걸 로컬 repo에 pull 했음.

 

03. PR을 위한 중요한 습관! branch의 삭제 타이밍

 

• 왜 PR이 완료된 후에 로컬 repo branch를 삭제해야하나?
• merge 거절 당하거나, 승인 받는다해도 merge conflict 방지하려면 추가적인 commit 필요함.
• 언제나 내가 수정할 수 있는 원격 repo에서 작업할 수 있는 것이 아님. → 다음 강의에서 fork 배움
• 수정은 로컬 repo 브랜치에서 하고, push 하는 것을 기본으로 생각하기.
• PR 완료하기 전까진 PR 요청을 한 로컬 브랜치 삭제 금지!

 

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

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

 

• fork(포크, 일종의 프로젝트 복사): 원본 소스코드를 복사해서 새로운 독립적인 소프트웨어로 개발하는 것.
• repo 사용권한이 다른 사람에게 있어도 프로젝트 제안할 수 있음. 복사해서 내 공간으로 가져오기.
• 오픈소스 기여할 때는 fork 해 온 후 clone 해서, PR 함. 그치만 PR을 받는 것은 관리자의 권한임.

 

02. 다른 repo에 PR하기 - 실습

 

• issue가 나에게 할당되었는지 확인하고 댓글 달기 - repo fork 해서 가져오기 - 소스트리로 fork 한 repo clone 하기 - 브랜치 만들고 안의 파일 수정해서 커밋하기 (커밋메시지에 issue 번호 달아주기, 작업내역 관리 위해서) - 원격 repo에 브랜치 push 하기 - github repo로 이동해서 PR하기 (메시지에 issue 번호 꼭 달아주기)
• PR 후 피드백 주고받는 과정은 협업하는 사람들과의 의사소통임.
• 코드 리뷰(code review): 작업물을 피드백을 수용하고 토의하면서 만들어나가는 것.

 

03. [배웠으면 써먹자] - PR 해보기

 

• 완료~

 

04. 중간 정리하기

 

• PR(Pull Request, 풀리퀘스트): 내 작업내역 바로 병합 안하고 프로젝트에 내 작업(branch) 병합해달라고 요청.
• Issue - Branch - Merge - Pull Request 후 Merge
• PR 완료되기 전까지는 PR 요청을 한 로컬 branch 삭제 금지. 
• ∵ 추가 commit 하려면 로컬 branch에서 commit 후 원격 push 해서 변경된 내용을 반영하기 때문.
• fork(포크): 원본 소스코드를 복사해서 새로운 독립적인 소프트웨어로 개발하는 것.
• 내가 merge 할 권한이 없으므로 PR merge를 기다리는 것임. 거부당할 수도 있음.

 

3-4. 최신 commit 고치기 - amend

01. 최신 commit 고치기 amend(어맨드) - 개념 탑재

 

• 대부분 되돌리기 작업은 함께 협업하는 사람들에게 영향을 미칠 수 있음.
• 기본적으로 나만 작업하는 특정 branch 하나에만 적용한다고 생각하기.
• amend(어맨드, 고치기): 가장 최신의 commit 만 수정할 수 있음
• commit 메시지에 오타가 났거나 파일을 까먹고 add(staging)하는 경우 사용.

 

02. push 전 amend - 실습

 

• commit 하고 앗 맞다! 되돌리려면 소스트리 - 커밋옵션 - 마지막 커밋 수정

 

03. push 후 amend - 실습

 

• 꼭 나만 사용하는 branch 에서만 작업해야 함. 안 그러면 다른 사람 작업내역이 엉망진창 됨.
• 그러면 다른 사람들은 기존 작업하던 프로젝트 지우고 새롭게 프로젝트 clone 해야 함.
• force push(강제푸시): push 후에 push 한 commit을 되돌리는 것. 강제로 커밋 덮어씌우는 것임.
• 파일 수정하고 커밋, 푸시 끝내고 원격 repo에서 확인 - 소스트리 도구 - 옵션 - 강제푸시 가능 설정 - amend 해서 커밋 메시지 수정 - 강제푸시 옵션 선택하고 푸시
• 일반적인 push 할 때는 강제푸시 체크 풀려있는지 꼭 확인.

 

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

01. commit 이 변경되었다는 것을 알리면서 되돌리기 - revert(리버트)

 

• amend: 가장 최신의 커밋만 되돌릴 수 있음. 어떤 걸 되돌렸는지 알 수 없음.
• revert: 이전의 커밋도 되돌릴 수 있고, 작업 내역도 기록으로 남겨짐.
• 커밋 되돌리기 클릭하면 끝. 
• 주의할 점: revert 되어 만들어진 커밋은 다시 revert 가능. 그치만 없어진 파일로 revert 하면 오류 발생.
• branch가 갈라져나온 커밋을 branch 갈라지기 전의 다른 커밋으로 revert 하려면 추가적인 옵션 필요.

 

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

 

• reset(리셋): 커밋했던 작업내역을 말 그래도 리셋시킴. 과거로 돌아가서 새 삶을 사는 것처럼.
• 3가지 모드가 있음.
• soft(소프트): 커밋들 되돌리고 변경된 파일 작업내역은 보존해서 파일 변경사항으로 보여줌. add 되지 않음.
• mixex(믹스드): 소프트와 같지만 변경사항은 add 된 상태로 보임.
• hard(하드): 커밋 되돌리고 그동안 작업한 것들도 다 없애버림. 작업내역 복원 불가능.
• 히스토리 남기지 않고 변경하는 것이므로 강제 푸시해야 함. 안 그러면 변경내역 이력 남음.
• 파일 변경사항 만들고 커밋 - 우클릭, 이 커밋까지 현재 브랜치를 초기화 - 모드 선택

 

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

01. 잠시만요, 이따 작업할게요. 변경사항 임시 보관하기 - stash(스태시)

 

• stash: 프로젝트 변경사항을 임시적으로 보관할 때 사용.
• 다른 브랜치로 체크아웃하게 되면 현재 브랜치의 변경사항이 사라지게 됨.
• 아직 작업중이라서 commit 하지 않고 변경사항만 보관하고 싶을 때 사용함.
• stash 클릭 - 메시지 입력 (나중에 어떤 내용을 임시보관했는지 알 수 있도록 메시지 잘 적기)
• 임시 보관 내용 꺼내려면 스태시 적용 클릭, 삭제하려면 스태시 삭제 클릭
• commit 한 적 없는 파일이면 stash 안해도 됨. Git이 아직 추적하지 않고 있는 파일이기 때문. 새 파일.
• stash 는 여러 변경사항을 임시 저장할 수 있음.
• 그치만 같은 파일 여러 번 stash 하면, 내가 수정한 내역이 흩어져 있어서 작업내용이 날아갈수도.
• 어떤 변경사항 stash 저장했는지 파악하고, 되도록 이전 stash 에서 편집하던 파일을 불러와서 작업하는 습관.

 

02. 중간 정리하기

 

• commit 되돌리는 법, 임시저장하는 법 배움.
• commit 되돌리는 작업은 꼭 나만 사용하는 branch에서 진행하기. 다른 사람 작업내역 엉망될수도 있음.
• amend(어맨드, 고치기): 가장 최신의 commit만 수정하는 것.
• revert(리버트): 이전의 커밋을 되돌릴 수 있고, 변경된 내용을 기록으로 남길 수 있음.
• reset(리셋): 작업내역을 말 그대로 리셋시키는 것.
• stash(스태시): 프로젝트의 변경사항을 임시적으로 보관해둘 때 사용함.

 

03. [배웠으면 써먹자] - commit 되돌리기 실험

 

• 완료~

 

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

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

 

• 커밋 메시지 컨벤션 (commit message convention): 커밋 메시지 작성규칙
• 컨벤션 (convention): 프로그래밍 세계에서 서로 조직에서 합의한 규칙
• 커밋 메시지 단위: 기능, issue 단위 등
• 규칙을 꼭 지켜야한다! 이런 게 아니라, 프로젝트와 협업을 잘하기 위한 의사소통일 뿐.

 

• 좋은 커밋 메시지, 단위로 작성할 때의 결과:
• 어떤 작업을 했는지 commit history (commit log)만 보고 알 수 있음.
• 버그를 찾을 때와 코드 고치기 쉬움
• 다른 사람이 코드 리뷰할 때 편함

 

02. commit 메시지 템플릿 적용하기

 

• sourcetree mac 에서만 제공하는 기능임.
• 키워드: 생성, 수정, 추가, 고치기, 문서화, 스타일, 테스트
• 왜, 무엇을 포함하기
• 제목은 80자 이내로, 긴 내용은 줄 바꿈하고 본문에서.

 

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

01. 코드 리뷰(code review)가 뭘까요?

 

• 코드리뷰를 하는 이유:
• 코드의 품질 높이기.
• 다른 사람의 눈으로 버그를 빠르게 발견할 수 있음
• 서로의 지식을 나누면서 더 나은 방안을 찾아낼 수 있음.

 

• 조직별로 코드 리뷰하는 스타일이나 분위기가 조금씩 다름. 라이브로 리뷰하는 곳도 있음.
• 코드리뷰를 받는 것도, 하는 것도 도움이 되므로 팀원을 구해서 해봐라.

 

02. Github 이용한 코드 리뷰

 

• Git, Github 사용하면 서로 피드백 주고 받으면서 하는 코드리뷰가 간단해짐.
• 각자의 작업공간이 분리되어 있어, 코드 리뷰 후 수정도 쉽고
• Github PR 페이지를 통해 댓글로 리뷰를 주고 받을 수도 있음.

 

03. [배웠으면 써먹자] - PR과 셀프 코드 리뷰

 

• 완료~

 

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

01. git에서 제외시키기 - .gitignore - 개념 탑재

 

• .gitignore: Git이 파일들을 없는 것처럼 무시하게 하는 설정. 공개 Github repo에 올라가면 안되는 것들.
• 보안상 중요한 정보들(비밀번호, API key 등), 설정파일(다른 사람 설정파일과 충돌날 수 있음)
• 파일명을 .gitignore로 만들고 여기에 Git이 무시해야할 파일, 폴더명을 적기. 프로젝트 최상위 폴더에 저장.
• 폴더명/ : 폴더 전체가 무시됨.
• 폴더명/파일: 폴더 안의 파일만 무시됨.

 

02. gitignore 적용하기 - 실습

 

• 완료~

 

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

 

• 프로그래밍 언어, 선택한 기술 특성에 따라 설정파일들 존재함.
• 이 설정파일도 올리면 다른 사람 설정이 꼬여서 귀찮아질 수도 있음.
• gitignore에 편하게 적기 위해서 소개하는 사이트: http://gitignore.io/

gitignore.io

• 내가 프로젝트에 사용하는 언어를 적고, gitignore 에 복붙해주면 끝!

 

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

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

 

• README.md: 프로그램이나 소프트웨어 사용시 먼저 읽어야하는 정보를 적어두는 파일.
• 서식이 적용될 수 있게 markdown(마크다운, md)라는 형식의 파일로 작성함.

 

02. markdown(마크다운) - 개념탑재

 

• markdown: 서식이 적용된 텍스트 파일
• github 페이지에서는 markdown 문법을 지원함.

 

03. markdown 빠르게 배우기 - 실습

 

• # 크기조절
• * 글머리 기호
• 1. 순서주기
• **굵은 글씨**
• *이탤릭체*
• [하이퍼링크](홈페이지 주소)
• 
• ``` 코드블럭 ```

 

04. kimchi-recipe 프로젝트 안내하기 - 실습

 

• 완료~

 

05 [배웠으면 써먹자] - kimchi-recipe 프로젝트 안내 업데이트

 

• 완료~

 

3-11. Github에서 정보 얻기 - 개발자의 SNS

01. 개발자의 구독과 좋아요 - 문제 해결을 위한 정보 탐색

 

• 좋은 프로젝트의 요소:
• 1. 해당 기술 또는 프로그래밍 언어를 잘 사용하고 있고 → 공식 문서, 튜토리얼, 개발 프로젝트
• 2. 다른 사람들에게 유용한 프로젝트 → 많은 사람들에게 반응이 좋고 널리 쓰이는 프로젝트

 

• Github의 Trending User: https://github.com/trending/developers

GitHub: Where the world builds software

• 어떤 프로젝트에 관심 가지는지, 누구와 네트워크를 맺고 있는지 (같은 프로젝트 협업, Follow)
• 한국 오픈소스 활동 랭킹: http://rankedin.kr/users

 

 

02. 다른 사람은 코드 어떻게 짤까? - 프로젝트 탐색하기

 

• 1. Github 검색하기 기능
• In this repository: 프로젝트 내에서 함수명, 관련 정보 찾을 때 유용. 특정 기술 관련 내용일 경우.
• In this user: 현재 접속된 repo 소유주 프로젝트 중에서 검색하기. 
• All Github: 기술명으로 검색하면 공식자료를 같이 보여줌.
• 2. repo 탐색하기
• 공식기술 repo: 해당 기술에 대해 가장 이해도가 높은 사람이 작성하므로, 그 기술을 가장 잘 사용한 코드임.
• 버그 같은 경우 공식 repo 가장 먼저 issue report가 되고 토의하므로 유용하게 사용 가능.
• README.md: Key Feature (주요 기능과 장점), Installation(설치방법), 프로젝트 튜토리얼 정보, Documentation(공식 문서 또는 문서의 위치), Contriution(해당 기술에 대해 기여하는 방법)
• star: 좋아요 watch: 구독하기

 

03. Github에서 기술 트렌드를 알 수 있다?

 

• Github explore 탭

 

04. [배웠으면 써먹자] - 내가 관심있는 프로젝트 소식 받아보기

 

• 완료~

 

3-12. 다른 프로젝트에 참여하고 싶어요 - 오픈소스

01. 오픈 소스는 공짜다? - 성당과 시장

 

• Git: Linux(운영체제의 일종)으로 개발할 때 협업하는 툴 만듦.
• 오픈소스(Open source): 누구나 프로젝트를 사용, 수정, 배포할 수 있는 프로젝트를 의미함.
• 무료가 아니라 사용권한(라이센스)가 따로 있음. 많이 사용되는 라이센스는 Apache License, GNI, MIT 등.

 

02. 좋아하는 책의 저자 되기? - 오픈소스 기여(contribution)란

 

• 오픈소스는 contribution(기여)로 발전했음. 우리도 contributor(기여자)가 될 수 있음.
• 프로젝트 bug report 하기 - 동작하지 않는 것을 issue에 적기
• 버그 리포트하는 issue에 해결 답변 달기 
• 기술 문서화 - 오타, 서식 수정, 기술을 설명하는 문서 작성에 참여
• 번역하기 - 주로 영어를 한글로 번역하는 프로젝트 많음.
• 기타 프로젝트가 필요로 하는 모든 것.
• help wanted(누구 도와주세요!). good first issue(처음 기여하기 좋은 이슈)

 

03. 나도 오픈소스에 기여하려면

 

• CONTRIBUTION.md: 오픈소스 프로젝트에 컨트리뷰션하는 방법 문서
• fork - issue 에 작업지원 - PR - PR 리뷰 - 리뷰 사항에 대한 수정 작업 - PR 승인 후 merge / 또는 거부
• 스프린트(sprint): 각 기술마다 전 세계적으로 자신들의 프로젝트에 기여하는 날! 이라고 집중 기여하는 것.
• 프로젝트 상관없이 여러 프로젝트에 오픈소스 컨트리뷰션 같이 하는 행사들:
• 스프린트 서울: https://sprintseoul.org/
• 파이콘 한국 스프린트: http://blog.pycon.kr/2017/07/11/tutorial-and-sprint/
• 헥토버페스트: https://hacktoberfest.digitalocean.com/

 

04. [배웠으면 써먹자] 앞으로 기여하고 싶은 오픈소스를 골라보자

 

• 컨트리뷰터에 도전하는 사람들을 위한 프로젝트: https://github.com/showcases/great-for-new-contributors

 

3-13. Github으로 나를 드러내자

01. Github 프로필 소개 - 제가 어떤 개발을 하고 있냐면요

 

• 생략!

 

02. Github 페이지 만들기 - 포트폴리오 페이지 만들기!

 

• Github repo로 페이지 만들기: repo 이름을 github_name.github.io 로 하면 blog 생성 완료!
• 페이지 주소: https://githubusername.github.io

 

03. Github 프로젝트 소개 업그레이드 - 어떤 프로젝트냐면

 

• 프로젝트 오른쪽 about에서 태그 설정 가능함.

 

04. [배웠으면 써먹자] - Github 내 profile 페이지 설정하기

 

• 완료!

 

3-14. 총 정리 가봅시다!

01. 그동안 뭘 배웠는지 큰 그림 같이 그리기!

 

• 1주차. 나를 위한 Git! : 내 프로젝트를 위해 Git을 바로 쓸 수 있었다.
• 핵심키워드: 버전관리, commit, pull, push, TIL

 

• 2주차: 같이 하기 위한 Git! : 협업하기 위한 기초 개념을 배웠다.
• 핵심키워드: Issue, branch, merge

 

• 3주차: 모두의 Git! : Git으로 의사소통하는 방법과 Github으로 만날 수 있는 새로운 세계를 만나봄.
• 1. 협업을 위한 작업(commit) 관리
• 주요키워드: PR, commit 되돌리기 - amend, revert, reset, 작업내역 임시저장 - stash
• 2. Git 프로젝트 관리 - 협업 매너
• 주요키워드: commit 메시지 컨벤션, gitignore, README
• 3. 오픈소스로 정보 탐색하고 함께 즐기기: 개발자스럽게 진짜 개발정보를 찾는 방법
• 주요키워드: github explore, 오픈소스(open source)
• 4. Github으로 개발자인 나를 나타내자 - 포트폴리오
• 개발자들 명함과 이력서에 Github 주소가 들어가는 이유! 
• 주요키워드: github profile, repo 소개, github page

 

02. 1주차 총 정리

 

• 버전관리: 변경되는 프로젝트 상태정보를 알고 있다는 것. Git은 가장 널리 쓰이는 버전관리 도구 중 하나.
• git 초기화(git initialize): 컴퓨터에 있는 프로젝트를 git이 관리하는 프로젝트로 만들기
• commit: 현재 프로젝트 상태를 찰칵 저장하는 것. 누가, 언제, 프로젝트 변경 내용. 커밋 메시지 남김
• add(staging): commit에 반영할 파일을 선택하는 것.
• commit history: commit 한 순서대로 리스트. 작업내역.
• repo: 내 컴퓨터에 저장되어 있는 Git 저장소(로컬 repo), 다른 곳의 접속 공간에 저장된 것(원격 repo)
• Tracking(추적): 로컬 repo branch와 원격 repo branch를 연결한다.
• push: 로컬 repo branch의 commit 들을 원격 repo branch 에 반영하기
• pull: 원격 repo branch의 commit 들을 로컬 repo branch 에 반영하기
• push, pull은 기본적으로 tracking 되고 있는 브랜치를 기준으로 커밋 내역을 반영함.
• clone: 원격 repo 를 내 컴퓨터에 가져와서 초기 repo 세팅하는 것
• 초심자 꿀패턴: pull(원격, 로컬 repo 상태 동등하게) - commit(작업내용 저장) - push(원격에 반영)

 

03. 2주차 총 정리

 

• Issue - Branch - Merge - PR Merge
• Issue: 내가 할 작업, 기능 추가, 버그 리포트 등 여러가지 방식으로 사용 가능
• 협업하기 위해 Issue 를 만들어 누가 작업할지 정하고, 브랜치 만들어 작업할 공간을 나눔.
• Branch: 특정 커밋에서 갈라져나와 작업할 수 있음. 우리는 기능별로 이름을 만들어주어 브랜치에 작업함.
• Checkout: 작업할 브랜치로 바꾸는 것. 체크아웃한 브랜치에만 커밋이 반영됨.
• Merge: 브랜치의 작업내역 커밋들을 다른 브랜치로 반영하는 것.
• 작업이 완료되면 작업한 브랜치는 보통 삭제함. 나중에 브랜치 설정이 꼬이는 것을 방지할 수 있음.
• Merge conflict: Merge 과정에서 동일한 부분이 수정된 게 발견되면 병합 충돌이 발생함.

 

04. 3주차 총 정리

 

• PR: 작업내역을 바로 병합하지 않고 충분히 리뷰받고 최종적으로 프로젝트에 반영하는 단계.
• amend: 최신의 commit을 수정하는 것. 가장 최신의 커밋만 수정 가능.
• revert: 이전 커밋들도 되돌리고 기록도 남김.
• reset: 작업내역을 말 그대로 리셋 시킴.
• stash: 프로젝트의 변경사항을 임시적으로 보관할 때 사용.
• commit message convention: 커밋 메시지 작성하는 규칙
• convention: 프로그래밍 세계에서 합의한 규칙
• .gitignore: 파일들을 없는 것처럼 무시하게 하는 설정
• open source: 누구나 프로젝트를 사용, 수정, 배포할 수 있는 프로젝트
• contribution: 프로젝트에 기여하며 발전시키는 것.

 

05. 앞으로 어떻게 Git 더 잘 써먹을 수 있을까요?

 

• 1. Git 개념과 사용법이 궁금하다면 공식 책 보기: https://git-scm.com/book/ko/v2
• 2. Git 명령줄(CLI, Command Line Interface)로 사용해보기
• 터미널에서 명령어로 컴퓨터에게 명령을 내려 실행시키고 컴퓨터에게 메시지를 받는 것.
• 우리는 소스트리에서 클릭클릭해서(이렇게 사용하는 것을 GUI라고 함) 사용함.
• 간단하게 보는 Git CLI 명령어: https://rogerdudler.github.io/git-guide/index.ko.html

git - 간편 안내서 - 어렵지 않아요!

• 3. 내가 사용하는 개발 도구(IDE)에서 Git 사용하기
• vscode, Pycharm, Intelij 같은 개발 도구들에서 Git 사용 가능. 소스트리 사용했던 것처럼.
• Pycharm에서 버전관리도구 사용하기: https://www.youtube.com/watch?v=jFnYQbUZQlA

 

3-15. 3주차 끝 & 숙제 설명

01. 내 TIL repository 업데이트 하기

 

• 완료~