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

1. 수업 후기

 

• 강의 개수: 15개
• 총 강의시간: 2시간 42분
• 수업 목표:
• 1. 협업하기 위한 Git 기본 개념을 익힌다. - issue, branch, merge
• 2. 두 명 이상과 협업하는 Git 프로젝트를 만들 수 있다.
• 3. 기능별로 나누어 작업 내역을 남길 수 있다.

 

지난주에 이어서 Git 강의를 들었다. 정리하고 실습해보는 게 시간이 좀 걸려서 총 수강시간은 약 8시간정도 걸린 것 같다. 강의 막바지로 갈수록 이런저런 기능들에 익숙해져서 점차 자동으로 사용할 수 있게 되었다. branch와 merge는 이제 괜찮은 것 같다. 나중에 까먹어도 정리한 내용 보면 금방 기억나지 않을까. 지금은 조금 익숙해져 있는 상태다. 도구 사용방법을 배우는 것을 잊지 말아야지. 우선 손에 잘 익혀야 한다.

 

수업 중간마다 오시영 튜터님이 공부방법에 대해서 몇 가지 알려주시는데, 확실히 수업내용을 요약해서 손으로 쓰는 게 노트에 남아있어서 더 좋은 것 같다. 갑자기 뜬금없이 내 공부방법을 말해보자면 이렇다. 첫 단계는 강의를 듣지 않고, 강의노트만 보면서 수업내용을 정리한다. 이때, 실습도 전부 해보면서 최대한 이해를 하고 넘어가려 한다. 두 번째는 강의를 들으면서 다시 내용을 복습하고, 세 번째는 수업 후기를 쓰면서 한번 흩어본다. 이렇게 3단계로 끝난다. 나한테는 맞는 방법이라고 생각하는데 내가 적응해서 그런지 아니면 더 좋은 방법을 모르기 때문인지는 잘 모르겠다. 좀 더 공부하면서 적합한 방법으로 수정하면 될 것 같다.

 

오늘의 첫 단계는 대략 6시간이 걸렸다. 사실 오랫동안 한 작업을 붙잡고 있으면 집중력이 조금씩 흐트러져서 갈수록 늘어진 경향도 있다. 그래도 이 단계를 끝내면 한 고비를 넘길 수 있다. 튜터님이 강의에서 언급하셨던 것처럼 확실히 내가 모르기 때문에 막막한 느낌은 아마 낯설기 때문일 것이다. 위의 방법대로 공부하면, 이미 한 번 사이클을 돌고 다시 강의를 듣기 때문에 좀 더 수월하게 이해할 수 있었다. 문제는 수업내용을 정리하면서 강의 내용을 전체 타이핑하니까 나도 모르게 조금 외워버리게 되는데, 이걸 이해했다고 착각해서 막상 나중에 실습을 하게 되면 어떻게 해야 할지 시작점조차 모르는 경우다. 

 

그때 개념 지도를 그리면서 나만의 언어로 바꿔주는 단계를 거치면 좀 더 오랜 시간 기억할 수 있고 개념을 더 익숙하게 이해할 수 있는 것 같다. 사실 이 이야기를 하려고 했는데 너무 서론을 길게 쓴 것 같다. 지금 시간이 12월 30일 새벽 2시인데, 너무 졸려서 그런 듯하다. 조금 횡설수설한 감이 없지 않아 많다. 오늘(30일)도 7시간 뒤에 또다시 강의를 듣고 공부하고, 팀 프로젝트 관련해서 다시 복습하고, 기타 등등할 일이 많다. 어제도 수고했고 오늘도 화이팅~

 

결론: 현재 공부법이 암기 위주라 프로그래밍 공부에 적합한지 아리송했는데, 새로운 공부법을 알게 되어서 좋음.

 

2. 수업내용 정리

2-1. 협업 위한 Git 배우기!

01. 지난 시간 주요 개념 복습하기

 

• 2021.12.27 - [프로그래밍/스파르타코딩클럽] - [스파르타] 협업을 위한 Git 활용 기초 1주차 (완강)

 

02. 오늘 배울 것 - Git 협업 시나리오

 

• Git 협업할 때 사용되는 작업방식:
• 1. [Issue] 누가 이 작업을 할지 정한다.
• 2. [Branch] 각자 맡은 것을 알아서 작업함.
• 3. [Merge] 각자 작업을 프로젝트에 합칠 수 있게 공유함
• 4. [PR 후 Merge] 작업한 내용을 리뷰하고 최종적으로 프로젝트에 반영함.

 

2-2. 누가 이 작업할 거예요? - Issue 할당

01. issue 가 뭔가요? - 개념 탑재

 

• 1단계: 누가 이 작업 할지 정한다.
• issue(이슈): 프로젝트에서 해결해야하는 문제. 아래의 예시가 있음
• 버그(프로그램이 원하는대로 동작하지 않는 것)를 신고(Bug report, 버그 리포트)
• 기능 추가 등의 프로젝트 개선 제안 (enhancement)
• 위 문제들을 해결하기 위한 작업단위
• 사용예시: 1번 이슈 제가 처리할게요. 버그 이슈 등록할게요. 버튼이 눈에 잘 보이면 좋겠습니다. 이슈 등록.

 

• 이슈 트래커(issue Tracking Tool), 이슈 트래커(issue tracker): 이슈를 추적하며 관리하는 도구
• 예시: Github, Jira, Trello, YouTrack 등

 

02. issue 만들어보기 - 실습

 

• Github에서 issue 만들기
• 제목, 상세내용: 협업하는 사람도 잘 알아볼 수 있도록 적어라
• Assigness(담당자): 이슈를 작업하거나 연관된 사람들
• Labels: 이슈가 어떤 것인지 분류함. Github 기본 라벨을 사용하거나 사용자가 직접 만들 수 있음.
• Submit new issue 누르면 이슈 생성 완료!
• 이슈번호: 제목 옆에 있는 #숫자. repo 기준으로 1부터 생성됨.
• Close issue: 이슈를 남겨두는게 필요없거나 작업이 완료되면 이슈를 종료함. 이유 적어주기.
• Reopen: 종료된 이슈들 다시 열어주기
• 이슈 사용예시: 협업, 혼자 프로젝트할 때 체계적인 작업기록 관리, 오픈소스 프로젝트 논의하고 작업.

 

03. issue와 연관된 commit 만들기 - 실습

 

• commit 메시지 작성시, 관련 이슈 번호를 포함해서 알려줄 수 있음.

 

04. [배웠으면 써먹자] - issue 만들고 지워보기

 

• 이슈 종료(close), 열기(reopen), 추가 반복해보기

 

2-3. 각자 공간에서 작업하기 - Branch - 개념

 

01. 브랜치(Branch)가 뭔가요? - 개념 탑재

 

• 2단계: 각자 맡은 것을 작업함.
• 프로젝트마다 기본 브랜치가 설정되어 있음.
• 같은 브랜치에서 같은 파일을 작업하면 충돌날 수 있으므로 브랜치 나눠서 작업함.
• 나눠진 브랜치는 나중에 합칠 것임.
• 앞으로 우리는 기능별로 브랜치를 만들어 작업할 것임.

 

02. 브랜치를 나누어 작업하기 - 실습 설명

 

2-4. 각자 공간에서 작업하기 - Branch - 실습

01. issue와 브랜치 만들기

 

• 커밋되지 않은 작업내역 없어야 함. 충돌 일어날 수도 있음.
• 1. 새 이슈 만들기
• 2. 소스트리 히스토리에서 마지막 commit 우클릭하고 브랜치 생성함.
• 브랜치 이름: feature/이슈번호_관리쉬운이름, 항상 정해진 것은 아님.
• 소스트리에서는 브랜치명 안에 / 적어주면 마치 폴더처럼 보여줌.
• 체크아웃(checkout): 현재 작업하는 브랜치를 선택하는 것. 브랜치명 왼쪽에 O 표시됨.
• main: 로컬 repo의 main 브랜치
• feature/2_jjigae: 로컬 repo의 feature/2_jjigae 브랜치
• origin/main: origin(연결시켜준 원격 repo)으 main 브랜치
• origin/HEAD: 현재 작업중인 commit.origin(연결시켜준 원격 repo)의 최신 commit
• 신규 브랜치의 시작점: 기본적으로 갈라져 나온 브랜치(여기서는 main)의 최신 commit 부터임.

 

02. 브랜치에 commit 하기

 

• 작업 브랜치 = 체크아웃 브랜치인지 확인하기.
• 같은 방식으로 add, commit, push 하면 최신 커밋에 feature/2_jjigae 이름표 붙는다.

 

2-5. 각자 공간에서 작업하기 - Branch - 정리

01. 브랜치 삭제하기 - 에러 나면 참고!

 

• 브랜치 삭제하면 작업내역 즉, commit도 전부 삭제되는 것임.
• 브랜치 삭제하면 main 브랜치로 체크아웃되고, 파일도 해당 브랜치의 마지막 commit으로 상태가 변경됨.
• 히스토리에서 갈라져나오길 원하는 브랜치 우클릭해서 생성 후 삭제해보자.
• 브랜치 삭제할 때는 체크아웃 브랜치가 아니어야 함.
• 강제삭제 옵션: commit이 되거나 작업내역 있어도 무조건 삭제됨.

 

02. 중간 정리하기

 

• issue: 내가 할 작업, 기능추가, 버그 리포트 등 여러 방식으로 사용 가능함.
• 협업을 하기 위해서는? issue 만들어 누가 작업할지 정하고, 브랜치 만들어 작업할 공간을 나눔.
• 브랜치(branch): 특정 commit에서 갈라져나와 작업 가능. 우리는 기능별로 만들어서 작업하면 됨.
• 체크아웃(checkout): 작업할 브랜치로 변경하는 것. 체크아웃된 브랜치에만 commit 반영됨.

 

03. [배웠으면 써먹자] - 브랜치 실험하고 지우기

 

2-6. 작업 내용 합치기 - Merge(병합) - 개념

01. Merge(병합, 머지)가 뭐지? - 개념 탑재

 

• [3단계] 각자의 작업물을 프로젝트에 합친다.
• Merge(병합): 브랜치를 다른 브랜치에 합치는 것. 특정 브랜치의 commit들을 전부 반영하는 것임. (기본설정)
• 실제 프로젝트에서는 작업 내역을 모두 합칠 기준이 되는 브랜치를 정해두고 작업함. 우리는 main에 병합!
• 프로젝트마다 Branch 관리하는 방법이 조금씩 다름.
• flow(흐름): commit 하고 작업하는 방법을 통틀어 말함.
• 대표적인 예시: github-flow, gitlab-flow, git-flow
• 웹 프로젝트 개발은 주로 github-flow (클릭) 사용함. 우리가 실습하는 방법도 이와 유사함.

 

2-7. 작업 내용 합치기 - Merge(병합) - 실습

01. 브랜치 하나를 Merge(병합) 하기 - 실습

 

• 작업한 feature/2_jjigae 를 main 브랜치에 합치기.
• 1. commit 반영시킬 브랜치인 main으로 체크아웃함.
• 2. 병합 클릭해서 feature/2_jjigae의 가장 최신 commit(이름표 붙은 커밋)을 선택하고 확인 누름.
• 모든 경우에 merge 되는 commit 메시지는 자동으로 생성하는 옵션 넣기
• (병합 커밋에 있는 메시지들을 첨부하세요, 빠른 병합이 가능에도 새 커밋 생성)
• 3. merge도 작업내역이므로 commit 생성됨. → merge commit 으로 부름.
• 4. feature/2_jjigae 작업이 끝났으니 브랜치 삭제함. 그럼 병합 끝!

 

02. 여러 브랜치에 commit 하고 Merge(병합) 하기 - 실습

 

• 이슈 만들어 할당하는 작업은 생략했음.
• 그러나 실제 프로젝트에서는 언제나 이슈 먼저 만들고 논의 - 할당 후 작업함.
• feature/jeon 브랜치 - 김치전 요리법 업데이트 작업, feature/rice 브랜치 - 김치 볶음밥 업데이트 작업.
• 1. 작업 브랜치 2개 만들기
• main 브랜치로 체크아웃 하고, 히스토리에서 main 이름표가 붙은 최신 commit을 선택하고 브랜치 생성.
• 2. feature/rice 브랜치에 김치볶음밥 요리법 commit 하기
• 3. feature/jeon 브랜치에 김치전 요리법을 commit 하기
• 4. Merge 하기
• main 브랜치로 체크아웃하고 병합 눌러서 feature/jeon 이름표가 붙은 commit 선택하고 옵션 추가, 확인.
• 나머지도 같은 방식으로 병합함.
• 최종 완료되면 merge commit 나타난다.
• 5. 작업 끝난 branch 삭제함. 병합 끝!

 

2-8. 작업 내용 합치기 - Merge(병합) - 정리와 꿀팁

01. 중간 정리하기

 

• Merge(머지, 병합): 브랜치의 작업내역 commit들을 다른 branch로 반영(합치기)하는 것.
• 기본적으로 branch 단위로 merge 하게 됨. 
• 개발할 때는 기준이 되는 기본 브랜치를 정해놓고, 다른 브랜치들을 기본 브랜치에 병합함.
• 브랜치명은 프로젝트 관리를 위해 규칙을 가지고 작명하도록 함.
• 작업 완료된 브랜치는 나중에 브랜치 설정이 꼬이는 것을 방지하기 위해 삭제함.

 

02. [배웠으면 써먹자] - Merge 실험하기

 

• 브랜치 여러 개 있을 때는 Merge conflict(병합 충돌)을 막기 위해 다른 브랜치에서 다른 파일 수정.
• 다른 브랜치에서 같은 파일 수정하면 충돌 일어남.

 

03. [꿀팁] - 인터넷으로 추가 정보 얻기

 

2-9. 충돌 해결하기 - Merge conflict - 개념과 준비

01. Merge conflict - 개념 탑재

 

• 에러가 안 나는 것이 중요한게 아니라, 버그를 고칠 수 있는지가 더 중요함.
• 병합충돌(Merge conflict): 하나의 파일을 여러 브랜치에서 수정하고 하나의 브랜치에 병합할 때 발생.
• 이 때 git은 양 쪽에서 수정된 내용 중 어떤 것을 반영할지 확인하는 메시지를 준다.

<<<<<<< HEAD
{현재 브랜치의 다른 파일 내용}
=======
{충돌 나는 브랜치명 또는 commit에서의 다른 파일 내용}
>>>>>>> 충돌나는 브랜치명 또는 commmit 아이디

• merge conflict를 수정하려면, 어떤 내용을 반영할지 결정해서 수정하고 <<HEAD. ==, >> 브랜치명 삭제
• 그후 수정된 파일을 commit 하면 됨.

 

 

02. Merge conflict 일부러 내보고 고치기 - 실습 설명

 

• 서로 다른 브랜치에서 같은 파일을 수정해서 일부러 병합충돌 발생시키고 수정하기.
• feature/stock 브랜치 - 국물 내는 비법
• feature/jjigae_rtan 브랜치 - 김르탄 가문의 김치찌개 비법 추가

 

03. 각 브랜치에 작업하기 - 실습 준비

 

• 1. 작업할 브랜치 만들기: main에서 체크아웃한 뒤에, feature/stock, feature/jjigae_rtan
• 2. 같은 파일을 각 브랜치에 작업하고 commit 하기: feature/stock 2번, feature/jjigae_rtan 1번
• 다른 브랜치에서 변경된 내용에 영향 안 받고 jjigae.txt 파일을 수정했음.
• 밑에 이어서 진행됨.

 

2-10. 충돌 해결하기 - Merge conflict - 실습

01. Merge conflict 일부러 내보고 고치기

 

• 1. Merge 시도하기 - feature/stock
• 먼저, feature/stock 브랜치를 merge 함. main에 체크아웃하고 병합.
• 성공적으로 병합됨. 병합하려는 커밋 중 같은 파일을 수정한 내역이 없기 때문.
• feature/jjigae_rtan도 main 브랜치에 병합. 충돌병합 알림 메시지 등장함.

 

• 2. Merge conflict(머지 컨플릭트, 병합 충돌) 해결하기
• 히스토리의 충돌 파일을 더블클릭해서 파일에디터 띄움.
• === 을 기준으로 앞 부분이 현재 브랜치(main)의 파일 내용, 뒷 부분이 다른 브랜치의 해당 내용임.
• Git은 '<< HEAD, >>> 브랜치명' 이 파일에서 사라지면 충돌이 해결되었다고 판단함.

 

• 3. 충돌 수정하고 커밋하면 자동으로 커밋 메시지 작성됨. 충돌난 파일 위치도 나타남. 병합 끝!

2-11. 충돌 해결하기 - Merge conflict - 정리

01. 중간 정리하기

 

• 각 작업 브랜치에서 작업할 때는 다른 브랜치의 영향 안 받고 독립적으로 작업 가능. ex) jjigae.txt 수정
• 병합 충돌(Merge conflict): Merge 하는 과정에서 동일한 파일이 수정된 것이 발견되면 발생함.
• conflict 수정하려면 최종적으로 반영할 내역으로 수정한 후, merge commit 하면 됨.
• 완전 새로운 내용 추가하는 건 곤란하다! 작업 내역에도 안 남고 협업할 때 복잡해짐.
• 병합 충돌 해결한 다음에 새로운 커밋을 추가하는 방식으로 해결해라.
• 프로젝트 및 의사소통의 첫 걸음은 작업내역, 커밋내역 잘 관리하는 것임.

 

02. [배웠으면 써먹자] - merge conflict 고치기

 

2-12. 원격 repo와 Branch - 개념과 실습

01. 원격 repo의 Branch - 개념 탑재

 

• 로컬 repo와 원격 repo가 연결된 것은 사실 각각의 브랜치가 연결된 것과 같음.
• 따로 설정 안하면 기본적으로 로컬 repo 브랜치명과 동일한 원격 repo 브랜치명이 생성되어 Tracking 됨.
• 히스토리의 origin/main 은 원격 repo(origin)의 main 브랜치라는 뜻. (원격 repo 연결할 때 origin 작명함.)
• 로컬 repo(main)가 원격 repo(origin/main)을 Tracking 하는 것임.
• pull, push도 결국 특정 branch(tracking branch)의 commit을 연결된 branch로 가져오는 것임.

 

02. 원격 repo 브랜치와 로컬 repo 브랜치 연결 확인 - 실습

 

• 로컬 repo 브랜치가 원격 repo 브랜치를 tracking 하기 때문에 아직 원격 repo가 없어도 로컬 repo push 가능.
• main 붙어있는 커밋과 origin/main 붙은 커밋 위치가 서로 다름.
• push 하면 모두 같은 commit 에 위치함. 최신 commit 내역이 동일하게 변경된 것임.
• 지금까지는 로컬 repo 브랜치만을 이용해서 작업하고 병합했음.
• 그러나 실제 프로젝트에서는 로컬 repo 브랜치의 작업내역(커밋들)을 원격 repo 브랜치에 push 하면서 함.
• 실제 기능을 만드는 건 오랜 시간이 걸리는 일이므로.

 

03. 로컬 repo 브랜치 만들어 원격 repo 브랜치에 push - 실습

 

• 로컬 repo에 김치찜 요리법 생성하는 새로운 branch 생성하여 커밋 후, 원격 repo 브랜치 지정해 push 하기.
• 1. 로컬 repo에 feature/jjim 브랜치 생성
• 2. 프로젝트 폴더에 jjim.txt 파일 생성해서 내용 채우고 jjim 브랜치에 커밋.
• 3. 원격 repo의 새로운 branch에 push 하기

• 로컬 repo의 feature/jjim 브랜치가 원격 repo(origin)의 feature/jjim에 tracking 하겠다는 의미임.
• 원격 repo에 feature/jjim 없으면 자동으로 생성됨.
• 이름표를 2개 갖는다. feature/jjim, origin/feature/jjim
• 4. 원격 repo에 반영되었는지 Github 페이지에 접속해 확인함.

 

2-13. 원격 repo와 Branch - 정리와 꿀팁

01. 중간 정리하기

 

• tracking: 로컬 repo와 원격 repo의 특정 브랜치를 연결해주는 것.
• pull, push는 기본적으로 tracking 되고 있는 브랜치를 기준으로 commit 내역을 반영함.

 

02. [배웠으면 써먹자] - 로컬 repo 브랜치 작업내역 원격 repo에 push

 

1. 로컬 repo 브랜치 만들고 commit 해보기
2. 원격 repo에 해당 브랜치 push 해보기
3. 작업이 끝난 후에는 로컬 repo 브랜치 지우기

 

03. [꿀팁] - 더 나아지고 있는 우리

 

• 쉽다 → 일부러 에러 만들고 구글링, 나만의 실험 고안, 추가자료 읽고 실행, 깨달은 점 TIL에 작성.
• 어렵다 → 천천히 다시 해보기, 어려워 했던 점이 무엇인지 정리하기, 깨달은 점 TIL에 작성.

 

2-14. 2주차 배운 개념 지도 그리기

01. [배웠으면 써먹자] 2주차 배운 내용 그림으로 그려보기

 

• 키워드: 협업하기 위한 단계, issue, branch, merge, merge conflict, 원격 repo의 origin

 

02. 총 정리 개념

 

• 협업하기 위한 단계
• 1. [Issue] 누가 이 작업할 것인지 정하기
• 2. [Branch] 각자 맡은 것을 작업함.
• 3. [Merge] 각자 작업을 프로젝트에 합친다.
• 4. [PR 후 merge] (경우에 따라) 작업한 내용을 리뷰하고 최종적으로 프로젝트에 반영.

 

• issue: 내가 할 작업, 기능 추가, 버그 리포트 등 여러 방식으로 사용 가능
• 협업하기 위해 issue 만들어 누가 작업할지 정하고, 브랜치를 만들어 작업 공간을 나눔.

 

• 브랜치(branch): 특정 commit에서 갈라져 나와 작업할 수 있음. 우리는 기능별로 브랜치에 작업함.
• 체크아웃(checkout): 작업할 브랜치로 변경하는 것. 체크아웃된 브랜치에만 commit이 반영됨.

 

• Merge(머지, 병합): 브랜치의 작업내역 commit들을 다른 branch로 반영(합치기)는 것.
• 개발할 때는 기준이 되는 기본 브랜드를 정해놓고 해당 브랜치에 내용을 merge 함.
• 브랜치명은 규칙대로 작명하기. 작업 완료된 브랜치는 삭제하기.
• 각 브랜치에서 작업할 때는 독립적으로 진행 가능 - 이래서 병합 충돌이 발생하는 건가

 

• Merge conflict(병합 충돌): 병합하는 과정에서 동일한 파일이 수정된 것이 발견되면 발생함.

 

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

01. 내 TIL repository 업데이트 하기!

 

• 완료!