프로그래머스 데브코스, 국비지원교육, 코딩부트캠프
🚩 프로그래머스 데브코스 웹 풀사이클 과정 1주차 DAY 5
이번주는 계속 Git에 대해서 공부했다. 프로젝트를 하며 Git을 쓴 경험이야 많지만 사실 그때그때 필요한 부분만 구글링하며 공부했기 때문에 제대로 된 지식 없이 사용하고 있었다. 이번주 강의를 들으며 이론을 공부하고 궁금한 내용을 스스로 찾아보는 과정을 통해 조금씩 Git에 대한 내용이 차근차근 순서대로 쌓여가는 것이 느껴졌다.
💡 Git으로 협업하기!
저번 시간에는 내 로컬에서 작업한 프로젝트를 Github의 저장소와 연동을 하는 git remote add 방식을 사용했다.
하지만 이렇게 연결하는 방식은 먼저 git init으로 저장소를 생성을 해야하기 때문에 어느정도 작업을 한 후 Git과 연동을 하는 게 아니라면 약간의 귀찮음을 감수해야한다.
Github에 올린 프로젝트를 새로운 작업 공간에서 수정하고 싶다면? 또 Git을 초기화하고 연동을 하는 것보다는 프로젝트를 내 작업 공간 내로 가져오는 게 더 편하지 않을까? 이럴 때 사용하는 게 바로 git clone이다! (물론 remote로 연동해도 상관 없다. 경험상 Git을 쓰다 보면 둘 다 자주 사용한다.)
git clone 경로
말 그대로 clone, 원격 저장소를 그대로 나의 작업 공간으로 복사를 하는 거다. git remote add 경로에서 사용했던 것처럼 Github에서 만든 레포지토리의 경로를 사용한다!
이렇게 저 초록색 부분의 Code를 누른다면 Github에서 친절하게 복사 붙여넣기 할 링크를 알려준다.
git remote -v 명령어로 확인해보니 성공적으로 clone이 된 것을 확인할 수 있다. 다만 주의할 점은 레포지토리를 먼저 생성한 이후 그 레포지토리 내에 clone을 한다면 레포지토리 속에 Git 저장소가 생성이 되니 조심하자! 이걸 방지하고 싶다면 그냥 vscode에서 새 창을 열자마자 clone을 해도 되고 아니면 그냥 remote로 연결해도 된다.
git pull origin main
본격적으로 협업을 한다면 하나의 프로젝트를 여러 명이 작업하게 된다. 가장 먼저 1.0 버전의 프로젝트를 내 작업 공간으로 가져와서 수정을 한다고 해보자. 내가 수정할 몫을 끝내고 단순히 push만 하면 어떻게 될까? 1.0 -> 1.1 -> 1.3 ... 이런 식으로 다른 사람들의 수정도 전부 이루어지는데 내 버전은 계속 1.0에만 머물러 있는 거다. 나도 다른 사람들이 수정한 프로젝트를 새로 가져오고, 또 그에 맞게 작업을 해야한다.
이럴 때 사용하는 것이 바로 git pull이다. 이름에서부터 알 수 있듯이, push를 이용해 Github에 올리고, pull을 이용해 Github의 프로젝트를 가져오는 거다!
아직 내 작업 공간에는 test.js만 존재하고 타인(혼자 할 때는 새 창으로)이 test2.js를 생성해 Github에 push 했다고 하자. 이렇게 되면 Github에서는 분명 test2.js가 존재하는데 내 작업공간은 test2.js가 없는, 즉 업데이트가 되지 않은 과거 버전인 거다. 이 수정된 버전을 맞추기 위해 git pull을 사용한다.
명령어를 사용하고 터미널을 보면 영어로 test2.js 파일 하나가 추가되었다고 한다. 실제로 작업 공간에도 바로 test2.js가 생성되는 것을 확인할 수 있다!
❓그럼 git clone이랑 git pull은 뭐가 다른 거지?
그렇다면 이런 의문점이 생길 수도 있다.
그럼
git clone이랑git pull은 뭐가 다른데요?
...그러게요?
라고 대답하면 안 된다!
이렇게 말은 하지만 사실 나도 머리로만 대충 이해하지 누군가를 완벽하게 이해하게 설명하지는 못했다. 그냥... 어... clone은 완전 받아오는 거고 pull은 업데이트 느낌으로... 이러고 있었다...
어떤 개념에 대해 모르는 사람도 이해갈 수 있도록 설명할 수 있어야 비로소 그 부분을 완전하게 이해했다고 말할 수 있는 거라고 개인적으로 생각한다.
git clone 경로git init
git remote add 경로
git pull origin main이 두 개는 사실 같은 기능을 하는 명령어다. git clone이 그냥 저 모든 기능을 포함하고 있는 거다.
git 폴더도 생성해주고, remote 경로 설정도 해주고, 프로젝트를 전부 가져온다. 실제로 git clone을 동작했을 때 해당 프로젝트의 레포지토리가 새롭게 생성된다.
git pull의 경우에는 프로젝트에 변경 사항이 생겼을 때 그 변경 사항을 가져와 내 로컬에 합친다고 볼 수 있겠다. clone과는 다르게 레포지토리를 새로 생성하지는 않는다.
git clone은 처음으로 프로젝트를 나의 로컬로 가져올 때 사용!
git pull은 프로젝트를 진행하면서 계속 최신 상태로 유지하고 싶을 때 사용!
많은 사람들은 보통 이런 식으로 사용하는 것 같다.
💡협업을 위한 브랜치!
Git에는 master/main이라는 하나의 브랜치가 기본적으로 존재한다. 나무로 예를 들자면 지지하는 기둥이라고 생각해도 무방할 듯싶다.
혼자서 개발을 할 때는 상관이 없지만 팀 프로젝트를 할 때 팀원들 각각 특정 기능을 맡아 개발을 하곤 한다.
팀원이 다섯 명이라고 할 때, 만약 다섯 명의 사람들이 모두 main 브랜치에서 작업을 하면 어떻게 될까? 물론 잘 진행이 될 수도 있다. 하지만 각자 맡은 개발 부분이 다르고, 팀원이 수정한 부분이 내가 수정한 부분과 겹치게 된다면 충돌이 발생하게 된다.
이를 방지하기 위해 우리는 새로운 브랜치를 생성해서 그 브랜치에서 작업을 하고, 최종적으로 master/main 브랜치에 합쳐주는 과정이 필요하다.
그림으로 예를 들자면 이런 식으로 작업을 하는 것이다. branch라는 이름대로 기둥에 여러 나뭇가지를 뻗어 나가게 된다. 이런 식으로 각자 브랜치를 만들어 해당 브랜치 내에서 코드를 작성하게 되면 충돌의 위험성도 적어지고(merge할 때 충돌이 자주 나긴 하지만) 프로젝트 관리에도 아주 효율적이다.
백문이 불여일견이라고 실습을 하며 브랜치를 직접 생성해보자.
git branch
: 현재 생성된 브랜치의 목록을 확인할 수 있는 명령어
현재 main 브랜치만 존재하기 때문에 해당 명령어를 입력하면 main 외에는 아무것도 뜨지 않는다.
git branch 브랜치명
: 내가 만들고 싶은 브랜치명을 함께 입력한다면 브랜치가 새로 생성이 된다.git branch로 확인한 결과 새로운 브랜치가 생성이 된 것을 확인할 수 있다. 하지만 아직 내가 있는 브랜치는 main인 것도 함께 확인할 수 있다.
git checkout 브랜치명
: 다른 브랜치로 이동하고 싶을 때 사용하는 명령어다. 이 명령어를 사용 후 우측을 보면 (main)이 (dev)으로 브랜치가 변경한 것을 확인할 수 있다!
git checkout -
: 이 명령어는 직전에 머물렀던 브랜치로 이동하는 명령어이다. 나는 이 전에 main 브랜치에 있었기 때문에 main 브랜치로 즉시 이동이 된다.
만약 내가 dev 브랜치에서 작업을 하고 커밋을 한 후(❗중요) main 브랜치로 돌아오게 된다면 dev 브랜치에 작업한 내용은 main 브랜치에 적용이 되어있지 않다. main 브랜치에서도 작업한 내용을 보고 싶다면 병합, 즉 merge라는 과정이 필요한데 아직 이 부분은 배우지 않았기에 다음에 설명하게 될 것 같다.
사실 협업을 하다 보면 브랜치를 정말 자주 사용하게 된다. 프로젝트 단위가 커질 수록 브랜치도 많아지기 때문에 브랜치를 병합하면서 이런 저런 충돌도 많이 생기고... 나도 실제 졸업 프로젝트를 하며 이 브랜치로 아주 골머리를 앓기도 했다.
이 외에도 다양한 명령어가 있지만 이건 강의를 들으며 다시 차근차근 공부해보자!
🍀 마치며
사실 원래 이 게시글은 금요일에 올라갔어야 했지만... 지독한 감기 몸살 이슈로 오늘에서야 겨우 올리게 되었다.
병원에 갔더니 대기 인원만 20명이었던... 감기도 독한 것 같고 특히 독감도 유행인 것 같으니 다들 독감 조심, 감기 조심하시길 바랍니다...
거의 하루종일 이 상태였음...😷
얼른 컨디션 챙기고 내일부터 다시 힘내자!!! 🤜🤛
