프로그래밍 기초_Git_Github_2

 

____________________________________________________________________________________________________________

 

 

2주차

 

 

이번주 목표 : 

 

협업하기 위한 Git 기본 개념을 익힌다 - issue, branch, merge

두 명 이상과 협업하는 Git 프로젝트를 만들 수 있다.

기능별로 나누어 작업내역을 남길 수 있다.

 

 

 

 

 

 

__________________________________________

 

2-1 협업 위한 Git 배우기

 

 

 

협업하는 과정에서 팀원들이 서로 다른 파일들을 수정해서 새롭게 commit 을 push 했다면 딱히 문제는 없어.

헌데 항상 프로젝트라는 게 초기 기획대로만 흘러가지는 않는 법.

하다 보면 서로 동일한 파일을 다르게 수정하게 되는 경우도 생길 테고, 설령 완성했다 하더라도 추후에 수정하거나 기능을 추가해야 하는 경우도 발생해.

그런 과정에서 ‘충돌’ 이 일어나게 되는데, 

프로세스 적으로 이를 사전에 최대한 틀어막을 수 있는 방법과, 충돌이 발생했을 시 어떻게 대처해야 하는지 등을 2주차에서 배워볼거야.

 

 

 

 

 

 

 

 

 

__________________________________________

 

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

 

 

 

issue란?

 

——

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

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

3단계. 각자 작업을 프로젝트에 합친다. - merge    * 정확히는 branch 의 commit 을 merge 한다.

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

——

 

 

프로젝트에서 이슈란, 프로젝트에서 해결해야 하는 문제를 지칭한다.

예를 들면, 사용자가 ‘이런 기능이 잘 안되요’ 라던지, 누군가가 ‘이런 기능도 있었으면 좋겠어요’ 라던지.

이런 해결해야 할 문제들을 이슈라고 불러.

즉 이슈란 해결해야 할 작업 단위인 것이지.

 

 

——

• 개발자들은 이렇게 이슈라는 말을 사용하죠!

——

=> Github 외에도 많이 쓰이는 이슈 관리를 할 수 있는 도구는 Jira, Trello, YouTrack 등이 있어.

이런 도구를 이슈를 추적(tracking)하면서 관리할 수 있다고 해서 이슈 트래커(issue tracker) 또는 

이슈 추적도구(Issue Tracking Tool, 이슈 트래킹 툴) 라고 부른다고.

 

 

 

——

그럼, 실재로 issue 를 만들어서 이를 트랙킹하여 해결해보자.

 

1. 깃허브의 내 원격 저장소에 들어가서 상단 탭 중 ‘issues’ 클릭해서 들어가보기.

 

1. 우측에 “New issue” 초록색 버튼 클릭해서 이슈 만들어보자.

 

——

 

 

Issue 가 원격 저장소에 등장했다면, 실재로 이와 관련된 Commit 을 만들어서 push 해 볼 수 있겠지?

이 과정에서 해당 commit 이 어떤 이슈와 연관된 것인지, 구체적으로 어떤 변화를 주었는지 commit 메세지에 적어주면 더 좋겠지?

 

이슈에 맞춰서 파일을 수정했어.

=> 내 실습의 경우 이슈는 < 김치찌개 요리법 - 육수로 만들기 #1 > 였고, *** #1 이 숫자는 내가 적지 않아도 깃허브가 알아서 매겨줘.

이에 따라 jjigae.txt 를 수정했어.

워크 스페이스 ‘파일 상태’ 가 개선되고, 체크박스에 체크를 함으로서 git add 라는 행위를 실행.

commit 메세지에는 < 김치찌개 육수 요리법 추가 #1 > 라고 남길거야. 해당 commit 이 어떤 이슈를 다룬 것인지 명시해 준 거야.

이후 push.

워크 스페이스의 history 에도 가장 최근 main 에 commit 한 버전과 origin/main 에 commit 된 버전이 동일해 졌음이 나타나 있어.

 

 

이렇게 하고 원격 저장소의 issue 란에 들어가 보잖아?

깃허브가 자동으로 ‘이슈에 관한 commit 이 새롭게 push 되었다’ 라고 인식을 해.

어떻게? Commit 메세지에 < 김치찌개 육수 요리법 추가 #1 > 라고 입력을 했잖아. #num 이게 해당 이슈에 관한 내용이라고 인식하는거야.

 

 

 

 

 

 

 

__________________________________________

 

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

 

 

 

Branch 란.

=> 2-2 에서 ‘이슈’ 를 정했잖아? 그럼 다음 단계인 ‘각자 맡은 것을 작업한다’ 라는 단계로 넘어가는데,

여기서 ‘branch’ 라는 개념이 필요해 져.

branch 는 협업하는 팀원들 각자가 독립적으로 작업하는 공간이야.

 

프로젝트에는 여러 기능들이 담겨 있어. 따라서 기능별로 commit 을 잘 나누기 위해서 branch 를 사용해.

 

 

 

 

 

 

 

__________________________________________

 

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

 

 

 

Issue 와 branch 만들기.

** branch, 즉 나뭇가지를 뻣기 전에는 왠만하면 commit 을 모두 완료해 주는 것이 좋아.

나중에 브렌치끼리 병합할 때 충돌이 일어날 수 있어서.

 

 

1. 먼저 이슈부터 만들자.

 

=> 원격 저장소에 이슈 남기기. 이슈 타이틀은 < 김치찌개 요리법을 두부 김치찌개 요리법으로 변경 >

이렇게 입력하면 < 김치찌개 요리법을 두부 김치찌개 요리법으로 변경 #2 > 라고 깃허브가 자동으로 넘버링을 매겨 줘.

 

1. 이슈와 연관된 작업을 할 수 있는 공간, branch 를 만들어보자.

 

=> 워크 스페이스 - 히스토리에서 내가 원하는 시점의 commit (일반적으로는 현재 commit 중에서 가장 최근 것 이겠지?) 에

마우스를 가져다 대고 우클릭, ‘브렌치’ 클릭.

“새 브랜치” 라는 모달창이 나와.

새 브랜치 명은 < feature/2_jjigae > 라고 명시. 보통 기능 추가인 경우 feature 라고 앞에 많이 들 붙인다고.

커밋은 명시된 커밋, 새 브랜치 체크아웃 다 체크. 그리고 브랜치 생성 버튼 클릭.

 

이렇게 하면 히스토리의 가장 최근에 적용된 commit 에 ‘feature/2_jjigae’, ‘origin/main’, ‘main’ 태그가 3개 붙어있는 것을 확인 가능.

각 태그들이 의미하는 공간에서의 가장 최근 commit 이 이것이다, 라는 걸 표현해주고 있는거야.

 

추가로, 워크 스페이스의 왼쪽 카테고리 중 ‘브랜치’ 에 

feature 라는, 마치 폴더 마냥 생긴 아이콘 안에 ‘2_jjigae’ 브랜치가 생성되어 있음을 확인할 수 있어.

현재로서는 feature/2_jjigae 와 main 이렇게 2개의 브랜치가 있는데, 해당 브랜치를 더블 클릭하면 git checkout 이 발생.

즉, 더블 클릭 함으로서 현재 접속 중인 브랜치를 선택할 수 있어.

 

 

 

< 2_jjigae > 브랜치 선택.

2_jjigae 에 새로운 commit 을 넣어보자.

 

 

——

jjigae.txt 내용 수정. 파일 상태에서 체크박스 체크(add) 해준 뒤 commit 메세지 적고 commit.

이후 워크 스페이스의 히스토리 가보면, 성공적으로 작업 공간이 분리되었고 feature/2_jjigae 브랜치에만 새로운 commit 이 반영되었음을 확인할 수 있어.

 

그렇다면, 한 번 더 jjigae.txt 의 내용을 수정 및 추가.

파일 상태 상으로 새로운 변경이 일어났음을 확인 가능하고, commit 해보기.

 

히스토리를 확인하면 새 commit 이 생겼고, 오직 feature/2_jjigae 태그만이 가장 위의 commit 에 달려 있음을 알 수 있어.

Main 과 origin/main 태그는 계속해서 그대로 있고.

 

——

 

 

 

 

 

 

 

__________________________________________

 

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

 

 

 

배운 것들을 정리해보기 전에, 맘껏 실험해 보기 위해서 브랜치를 삭제하는 법에 대해서 알아보자.

=> 브랜치를 삭제한 다는 것은, 그 브랜치에서 작업했던 commit 들이 다 사라진다는 의미! 그러니까 신중히!

 

——

< 브랜치 삭제 실험해보기>

 

1. Git checkout main. Main 브랜치를 더블클릭 해서 선택.
2. 히스토리 -> main 브랜치가 위치한 commit 에서 우클릭 후 새 브랜치 생성. 이름은 delete_test. 브랜치 생성과 동시에 checkout 체크박스 체크.
3. Jeon.txt 수정해보기. 맘대로.
4. delete_test 브랜치가 선택된 상태에서 새롭게 commit.

 

이렇게 하면 총 main / 2_jjigae / delete_test  총 세 개의 브랜치가 존재하고 있어.

히스토리에서도  그래프를 통해서 이를 시각적으로 판별할 수 있지.

 

delete_test 브랜치를 삭제해볼 거야.

=> 브랜치가 삭제된다는 것은, 해당 브랜치에서 행해진 commit 도 날아간다는 것.

이는 즉, 버전 수정 사항도 사라져서 git 프로젝트 내부의 파일들이 브랜치 생성 이전의 모습으로 돌아간다는 소리야.

 

브랜치를 삭제해줄 때에는, 다른 브랜치로 checkout 한 상태에서 해줘야 해.

이 경우 main 브랜치를 선택한 상태에서 delete_test 브랜치를 삭제해볼 거야.

 

워크 스페이스 좌측 브랜치에서 < delete_test > 우클릭, 삭제 클릭.

삭제 직후 히스토리에서도 commit 이 사라졌음을 확인할 수 있어.

 

Jeon.txt. 파일도 delete_test 브랜치에서 commit 하기 전의 모습으로 되돌아 갔어.

——

 

 

——

— 브랜치 중간 정리 —

 

• issue 는 내가 할 작업, 기능 추가, 버그 리포트 등 여러 방식으로 사용할 수 있음.
• 협업을 하기 위해 issue 를 만들어 누가 작업할지 정하고, 브랜치를 만들어 작업할 공간을 나눈다.
• 브랜치(branch)는 특정 commit 에서 갈라져나와 작업할 수 있습니다. 우리는 기능별로 이름을 만들어주어 브랜치에 작업해 준다.
• 작업할 브랜치로 바꾸는 것을 체크아웃(checkout)이라고 합니다. 체크아웃된 브랜치에만 commit 이 반영.

——

 

 

 

 

 

 

 

__________________________________________

 

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

 

 

 

Merge(머지, 병합)란?

=> 협업자들이 branch 를 나눠서 각자 작업을 완수한 뒤 이걸 하나의 프로젝트에 합치는 것을 의미.

Merge(병합) 는 브랜치를 다른 브랜치에 합치는 것. 

즉, 특정 브랜치의 commit 들을 다른 브랜치의 commit 내역에 모두 반영하는 거야.

기본적인 설정은 해당 브랜치의 모든 commit 을 모두 다 반영한다고 생각하면 좋을 듯?

 

 

실제 현업에서는 ‘우리는 main 브랜치를 기준으로 두고 다른 브랜치들을 합쳐 나갈거야’ 라고 사전에 정하고 개발을 시작한다고.

또, 사용자에게 배포하기 위한 브랜치도 있고… 그렇게 브랜치를 기준으로 두고 작업해 나간다고.

 

——

***

프로젝트마다 Branch 관리하는 방법이 조금씩 다릅니다. 

commit하고 작업하는 방법을 통틀어 flow(흐름) 라고 합니다. 

대표적으로 github-flow, gitlab-flow, git-flow 가 있습니다.

 

Flow 에 대한 정보는 교재 노션 참조

—

 

 

 

 

 

 

 

__________________________________________

 

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

 

 

 

작업한 feature/2_jjigae 를 main 브랜치에 합쳐 볼거야.

 

 

 

우선 별도의 두 개의 브랜치를 합치기 위해서는, 합쳐진 뒤 주축으로 삼을 브랜치를 선택해 놔야 해.

내 경우 main 브랜치.

 

1. main 브랜치를 checkout 한 상태에서 워크 스페이스 상단의 ‘병합’ 아이콘 클릭.
2. “현재 분기에 병합할 커밋을 선택하세요” 하면서 그래프와 브랜치 가지를 보여주는데,

나는 main 브랜치에 ‘feature/2_jjigae” 브랜치를 합칠 거라서, feature/2_jjigae 태그가 붙은 commit 을 선택해 줘.

이럴 경우 feature/2_jjigae 으로 분기해서 여태껏 쌓여 왔던 모든 commit 들이 병합에 포함 돼.

1. 아랫쪽 옵션은 ‘즉시 커밋’, ‘병합 커밋에 있는 메시지 첨부’, ‘빠른 병합이 가능해도 새 커밋 생성’

위쪽의 세 개를 모두 체크.

1. 그리고 확인.

 

이렇게 main 브랜치에 feature/2_jjigae 브랜치를 더하니, 히스토리에도 그 모습이 그래프로 바로 나타나.

Main 태그가 feature/2_jjigae 태그 위로 앞서 나가며 여태까지의 feature/2_jjigae 를 모두 포함하게 되었어.

** origin/main 은 여전히 병합 전의 commit 에 머물러 있어. 당연해. Push 를 안했으니.

 

feature/2_jjigae 를 main 에 다 반영했으니, 이제는 브랜치를 삭제해주자.

Main 브랜치를 checkout 한 상태에서 2_jjigae 우클릭 -> 삭제 -> 강제 삭제.

** feature/2_jjigae 태그가 히스토리에서 사라짐.

 

 

 

 

 

— 여러 브랜치에 commit 하고 merge(병합) 하기 실습 —

*** 실제 프로젝트에서는 가장 먼저 ‘이슈’ 를 만들고 그 이슈에 맞춰서 기능을 구현하지만, 지금은 연습 위주니까 이슈 제작은 스킵.

 

1. Main 브랜치의 가장 최신 commit 에서 브랜치를 2개 생성.

각각 < feature/jeon > , <feature/rice>

이런 식으로 위계 질서를 알아보기 편하게 만들어 주면 나중에 관리하기도 편해.

 

1. 먼저 < feature/rice > 브랜치를 체크아웃 한 뒤, commit 을 발생시켜.

 

1. < feature/jeon > 브랜치를 체크아웃 한 뒤, commit 을 발생시켜

 

1. 이제 merge 차례야. < feature/jeon >  먼저 병합. 그 전에, main 브랜치를 checkout 해주고.

 

1. 이어서 < feature/rice > 도 병합.

 

1. 작업 끝난 branch 인 두 개는 삭제. Jjigae 때 처럼, 워크 스페이스 좌측의 브랜치 카테고리에서 해당 브랜치 우클릭 -> 삭제.

=> 물론, main 브랜치를 체크아웃 한 상태에서.

 

 

 

 

 

 

 

 

__________________________________________

 

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

 

 

merge(병합) 중간 정리, 실험해보기, 그리고 꿀팁.

 

 

보통 개발할 때는 기준이 되는 main 브랜치를 정해두고 다른 브랜치들에서 임시 작업을 한 다음에 main 으로 merge 해주는 게 보통.

브랜치의 이름들은 Feature/jjigae 처럼 일정한 패턴을 지닌 편이 정리도 편하고 한 눈에 알아보기도 쉬워.

또한, 작업이 완료되면 작업한 브랜치는 보통 삭제해 주는 편. 나중에 브랜치 설정이 꼬이는 것을 방지할 수 있다고.

 

팁은 구글링 검색 관련. 교제 노션 참조.

 

 

 

 

 

 

 

 

__________________________________________

 

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

 

 

Merge conflict, 즉 브랜치와 브랜치의 병합 과정에서 일어나는 충돌.

 

이상적으로 생각한다면, 충돌은 발생하지 않는 게 가장 좋겠지. 허나 그럴 순 없어. 사실 일상적인 문제야.

충돌은, 즉 에러는 발생할 수 밖에 없어. 왜? 버그는 항상 존재 하거든.

중요한 것은 버그, 에러, 충돌 등이 발생했을 때 어떻게 보다 더 나은 방식으로 해결할 수 있느냐가 중요한 것이야.

 

 

하나의 파일을 여러 브랜치에서 수정하고 하나의 branch에 merge 하려고 할 때 merge conflict(병합 충돌) 가 발생해.

양 쪽에서 동일한 파트에 다른 수정 사항이 발생했는데, 어떤 내용을 반영해야 할지 몰라서 git 이 아마 나에게 물어볼거야. 뭐를 선택해야 하는가 라고.

Git 은 우선 자동으로 양 쪽을 다 합친 다음에, 충돌이 일어나는 부분을 보여주고는 어느 쪽 내용을 반영하면 좋겠니? 라고 메세지를 던지며 물어봐.

 

——

<<<<<<< HEAD 

{현재 브랜치의 다른 파일 내용} 

======= 

{충돌나는 브랜치명 또는 commit에서의 다른 파일 내용} 

>>>>>>> 충돌나는 브랜치명 또는 commmit 아이디

 

 

===>

 

이 merge confilct 를 고치려면,

1. 내가 원하는 대로 파일을 수정하고(어떤 내용을 반영할지 결정)
2. <<<<<<< HEAD , ======= , >>>>>>> 충돌나는 브랜치명 또는 commmit 아이디 를 지우면 됨.

 

이렇게 하면 git이 해결됬다고 인식할거야.

그리고서는 수정된 파일을 다시 commit 해주면, 뭐 문제 없는거지.

 

——

 

 

 

——

< 충돌을 경험해 보기 위한 준비 >

 

1. Main 브랜치 체크아웃 한 상태에서 < feature/stock >, < feature/jjigae_rtan >두 개의 브랜치를

main 의 가장 최신 commit 에서 생성해주기.

1. < feature/stock > 브랜치를 체크아웃하고, jjigae.txt에서 변경사항 발생시키기. 그리고 commit
2. < feature/stock > 에서 한 번 더 변경 사항 발생시키고 commit 해보기. 걍 해보는 거.
3. 이번에는 <feature/jjigae_rtan> 브랜치에 체크아웃 하고, 변경 사항을 발생시킨 후 commit 해보기.

** 브랜치가 바뀌며 stock 에서 commit 했던 사항들이 사라졌으니, 당연히 main 브랜치 시점의, 즉 수정하기 전으로 되돌아 간 상태.

 

이제 양 브랜치에서 동일한 파일을 다르게 commit 한 상태가 됐어.

 

 

 

 

 

 

 

__________________________________________

 

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

 

 

2-9 에서 브랜치를 2개 만들었고, 각 브랜치가 동일한 파일을 다르게 수정했어.

 

 

 

 

——

< merge 시도 >

 

1. Main 브랜치를 체크아웃 한 상태에서, 먼저 < feature/stock > 브랜치를 merge 해줘.
2. 다음으로, < feature/jjigae_rtan > 브랜치를 merge.

=> 직후, “ 충돌 병합 “ 이라는 알림창이 발생해. 

1. 알림창의 ‘확인’ 을 누르고 워크 스페이스의 ‘파일 상태’ 탭에 가보면, 대기 중인 파일에 ! 마크를 단 사항이 하나 떠 있어.

해당 파일 사항을 더블 클릭 해보면( 이 경우 jjigae.txt ) 실재로 해당 파일이 열려.

1. 파일에 충돌 사항이 발생한 구역을 실제로 표기해 주고 있어.

HEAD 란은 내가 현재 선택한 브랜치의 내용 (main 브랜치), 아래쪽은 병합을 시도한 브랜치의 사항이야.

1. <<<<<< ====== >>>>>>> 이렇게 충돌 구역이 나와 있는데, 해당 구역을 내가 원하는대로 수정하면 되는거야.
2. 내가 원하는 대로 수정한 후, 저장. 변경 사항이 발생했기에 ‘파일 상태’ 에 새로운 변경 사항이 떠.
3. 이 상태에서 워크 스페이스 - 파일 상태 란의 commit 메세지에 커서를 이동시켜 보면 git 이 알아서 메세지를 입력해 줘.

어느 파일에서 충돌이 발생했고, 이를 해결하기 위한 commit 을 하는거다, 라고.

 

 

****** 중요한 점!!!!!! *******

Merge 과정에서 충돌이 발생했는데, 단순히 어느 쪽의 브랜치의 내용으로 정할 것이냐 뿐 아니라 추가적으로 수정을 하고 싶다면?

우선 한쪽 브랜치의 내용을 선택하고 commit 을 한 다음에, 다시 새롭게 수정 사항을 발생시키고 commit 을 해야 해.

뭔 소리냐, 협업 중이면 팀원들이 commit 내용을 봤을 때 

“ 아, 여기서 충돌이 발생해서 어느 한 쪽의 브랜치의 내용을 선택한 거구나 “

라고 이해를 해야 하니까.

충돌 해결과 동시에 새로운 수정 사항, 추가 사항을 입력하고 commit 을 해버리면, 나중에 구분하기 좀 힘들어질 수도 있어.

또한, 프로젝트 관리할 때에도 작업 내역을 세부적으로 나누고 구분해서 단계를 만들어 두는 편이 더욱 명시적이고 깔끔해.

 

 

1. 이어서, 병합 충돌 구역에서 어느 한 쪽을 선택하고 수정한 뒤 commit 메세지도 자동으로 완성된 상태라면, commit 을 시도.
2. 무사히 commit 이 생성이 되었고, branch 들도 합쳐졌고, 오류도 없어.
3. 마지막으로 merge 한 브랜치들은 삭제해 주는 편이 더 깔끔하겠지?

——

 

 

 

 

 

 

 

__________________________________________

 

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

 

 

각 브랜치에서는 서로에게 간섭받지 않고 원하는 대로 새로운 commit 들을 할 수 있었어.

헌데 이를 기준되는 브랜치인 main 에 merge 를 시도하자 충돌 사항이 발생했지.

다행이도 git 은 어떤 파일의 어떤 부분에서 서로 다른 내용이 충돌을 발생 시켰는지 알려주고 있고,

우리는 이 충돌 구역을 수정해주면 되는거야. 수정하고 다시 commit 해주면 main 의 최신 commit 에서는 아무런 문제도 없는거지.

 

여러 파일에서 충돌이 발생할 수 있지만, 원리는 같아. 각 파일 마다 어느 쪽의 브랜치 내용을 선택할지, 내가 정하면 되는거야.

단, 충돌 수정과 새로운 내용 추가를 하나의 commit 에서 같이 하는 것은 좀 난감해.

우선은 충돌 수정만 하고서 commit 한 뒤, 그 다음에 내가 새롭게 추가하고 싶은 내용을 추가하고 또 commit 하면 돼.

작업을 단계적으로 분리하자는 거지. 알기 쉽게.

 

작업 내용, commit 내용 단계적으로, 구체적으로 잘 관리하는 거? 의사소통의 기본이야.

 

 

 

 

 

 

 

 

__________________________________________

 

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

 

 

원격 저장소와 로컬 저장소는 로컬 측의 트랙킹으로 인해 원격으로 연결되어 있어.

정확히 말하자면, 이는 로컬 저장소의 브랜치와 원격 저장소의 브랜치가 연결된 것과 같아.

 

따로 설정을 해주지 않으면 기본적으로 로컬 repo의 브랜치명와 같게 원격 repo의 브랜치명이 생성되어 tracking 될거야.

 

즉, pull 과 push 는 결국 특정 branch(tracking branch) 에 있는 commit 을 여기와 연결되어있는 branch에 가져오는 것.

트랙킹 단위가 브랜치 단위인거지. 

 

 

——

 

원격 저장소 브랜치와 로컬 저장소 브랜치의 연결을 확인하기 위한 실습을 해보자.

 

현 시점에서 소스트리 워크 스페이스의 히스토리를 확인해 보면, 최신 commit 이 로컬 저장소 브랜치 main 하나야.

그리고 아래쪽에 origin/main, 즉 가장 최근에 워크 스페이스에서 원격 저장소로 push 된 commit 의 버전이 해당 commit 임을 나타내 주고 있어.

이 시점에서 두 commit 은 12단계 차이야.

=> 워크 스페이스에서 설정 -> 원격에서 GitHub 의 특정 저장소를 SSH 주소 추적으로 트랙킹을 해줬잖아. 

즉, main 과 origin/main 은 연결되어 있기 때문에, ‘~~개 앞’ 이라는 commit 버전 차이를 바로 보여줄 수 있는거야.

 

1. Main 브랜치를 체크아웃
2. Push 아이콘 클릭.

=> 만약 < feature/stock >, < feature/jjigae_rtan > 브랜치를 아직 삭제하지 않았다면,

두 브랜치도 main 브랜치와 함께 push 가능 목록에 등장해. 이는 push/pull 의 단위 기준이 브랜치임을 명시해주는 부분.

1. 이번에는 main 브랜치만 push 해볼거야. Main 만 체크. 그리고 확인 클릭.

 

이렇게 하면, 히스토리에서 < origin/main> 브랜치의 태그가 맨 위로 올라와 Main 브랜치 태그와 동일한 commit 에 자리 잡아 있음을 알 수 있어.

 

——

 

 

 

 

 

지금까지는 작업을 로컬 repo 브랜치만을 사용해서 작업을 완료하고 merge 했어.

하지만 기능을 만드는 건 시간이 오래 걸릴 수 있지.

실제 프로젝트에서는 로컬 repo 의 작업 branch 의 작업내역(commit 들)을 원격 repo branch 에 push 해 저장해두면서 작업하는 경우도 있다고.

 

——

< 기능을 만들던 도중에 백업을 위해서 깃허브에 push 하는 경우 >

 

위에서는 main 에 모든 브랜치들을 병합시켜서 main 하나만 push 했지만, 이번에는 아직 작업 도중이라

Main 브랜치에 병합이 되지 않은 브랜치를 그대로 push 해볼거야.

 

  0. 우선 main 을 제외한 브랜치들은 이미 모두 병합시킨 상태일 테니 모두 삭제해주자. 당연히 삭제 대상이 아닌 다른 브랜치를 체크아웃 한 상태에서.

1. 로컬 저장소에 < feature/jjim > 브랜치 생성. 위치는 main 의 가장 최근 commit. 참고로, main 브랜치를 체크아웃 한 상태에서.
2. < feature/jjim > 체크아웃 한 후, 워크 스페이스의 ‘파인더에서 보기’ 클릭 후 git 프로젝트 폴더에 입장.
3. Kimchi-recipe 폴더 안에 새로운 파일, < jjim.txt > 생성.
4. 소스트리 워크 스페이스 ‘파일 상태’ 에서 새롭게 생성한 텍스트 체크 후 commit 메세지 작성하고 확인.

 

히스토리에 가면 < feature/jjim > 브랜치에 새로운 commit 이 올라가 있음을 확인 가능.

 

이 상태에서, 원격 저장소에 새로운 브랜치 < feature/jjim > 를 push 해보자.

1. < feature/jjim > 체크아웃 된 상태인지 확인.
2. Push 목록에서 < feature/jjim > 브랜치만 체크. 푸시 실행

 

이러면 히스토리에서 origin/feature/jjim 태그가 < feature/jjim > 태그와 함께 자리잡은 것을 확인할 수 있어.

그 아래에는 origin/main 태그, main 태그가 함께 있지.

 

 

 

이 상태에서 원격 저장소, 즉 github 에 가서 어떻게 변했는지 확인해보자.

 

1. 깃허브의 msdou46/kimchi-recipe 입장.
2. Code, issue, pull requests… 가로로 나열되어 있는 카테고리 바로 아래에 꼭짓점이 살짝 둥글고 가로로 긴 버튼에 < main > 이라고 적혀있을거야.

이 버튼은 현재 원격 저장소에 적용되어 있는 브랜치들의 목록을 보여주는 버튼인데, 이 버튼을 누르고 나오는 목록 중에 < feature/jjim > 를 선택하면,

< feature/jjim > 브랜치의 현 상태와 커밋들을 확인할 수 있어.

1. 실제로, 브랜치를 선택하게 해주는 버튼 바로 오른쪽에도 현재 깃허브에 몇 개의 브랜치가 적용되어 있는지 바로 확인할 수 있어. 현재는 2개.

 

< feature/jjim > 브랜치를 선택해보면, 바로 아래에 This branch is 1 commit ahead of main.  <= 라고 나와있어.

해당 브랜치는 main 브랜치보다 1개 커밋만큼 앞서 있다, 라는 뜻.

 

 

 

——

추가.

 

 

Github 페이지에 compare & pull request 버튼이 눈에 띄네요! 

Pull Request(PR)에 대해서는 다음 시간에 배웁니다! 

 

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

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

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

👉 (경우에 따라). 작업한 내용을 리뷰하고 최종적으로 프로젝트에 반영한다. - PR 후 merge.  이게 풀 리퀘 부분인듯?

——

 

 

 

 

 

 

 

 

__________________________________________

 

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

 

 

 

——

tracking 한다는 것은 로컬 repo와 원격 repo의 특정 브랜치를 연결해주는 것

 

push와 pull 은 기본적으로 tracking(추적)되고 있는 브랜치를 기준으로 commit 내역을 반영

——