오늘부터 본격적으로 교육 과정을 소화했습니다. 오늘 주된 교육 내용은 Git과 버전 관리였구요. 강의 후반부에 멘토님과 그룹 스터디도 진행했습니다. 공부한 내용을 간략하게 정리하고 그룹 스터디 내용도 요약해보겠습니다.
버전 관리의 필요성
팀 단위로 보고서나 문서 작업을 진행하다 보면, 위 이미지처럼 여러 버전의 파일들이 생기기 마련입니다.
위 처럼 버전을 갱신하면서 하는 것 자체는 상관없는데, 저런 식으로 버전을 새롭게 내다 보면 큰 문제가 하나 생깁니다. 바로 용량이 너무 뻥튀기되는 것이죠.
그래서 프로그래밍을 할 때에도 버전 관리를 하는데, 너무 정직하게 하면 비효율이 발생합니다. 이를 해결하기 나온 것이 버전 관리 기술이고, 가장 대표적인 것이 Git입니다.
Git
버전 생성과 업로드의 이해
Git을 설치하고 나면, 최초로 1회 설정해야 하는 부분이 있습니다. 터미널 명령어로 실행하면 되고, 다음과 같은 명령어가 있습니다.
-
개행 문자 설정 : 줄바꿈 되는 문자를 처리하는 방식을 다룹니다. 운영 체제 마다 다른 방식을 사용합니다.
config 처럼 앞에 하이픈이 붙은 것들을 플래그라고 하는데, 이는 config의 하위 속성처럼 작용합니다. -
사용자 정보 등록: 버전 관리(Git)을 하기 위해 사용자 정보를 등록해야 합니다.
-
구성 사항 확인: config 명령어를 통해 설정한 내용들을 확인합니다.
설정이 끝났으면, 위 명령어를 통해 버전 관리를 시작합니다. 해당 디렉토리가 Git에 의해서 버전 관리 영향 아래 두겠다고 선언하는 명령어입니다.
해당 명령어를 입력하면 브랜치가 형성됩니다.
다음으로 변경 사항을 추적할 특정 파일을 지정하는 단계를 거쳐야 합니다. 어떤 파일의 변화를 추적할 것인지 명시하는 단계입니다.
위 이미지처럼 index.html이라고 명시했다면 index.html의 변경만 추적될 것이고, 아래처럼 .을 찍으면 전체 파일에 대한 추적을 실행합니다.
커밋(Commit)
$ git status버전 관리가 시작된 디렉토리는 위 명령어로 버전 관리 상태를 확인할 수 있습니다.
commit을 진행할 때에는 해당 명령어를 사용하면서 진행하면 더 정확하게 버전 관리 상황을 파악할 수 있습니다.
$ git add .
$ git commit -m "첫번째 commit!"앞서 언급한 git add . 를 입력하면 전체 파일이 버전 추적의 영역에 들어가게 됩니다.
그 후에 아래 commit이 포함된 명령어를 통해 실제로 commit을 진행하게 됩니다.
commit을 할 때에는 해당 commit에 대한 설명을 첨부할 때가 많은데, 이 때 사용하는 플래그가 -m입니다.
commit은 수정할 때마다 할 필요는 없고, 단지 지금까지의 변경 사항을 내가 관리하는 브랜치에 적용시키는 과정으로 이해할 수 있습니다.
브랜치(Branch)
$ git branch
$ git branch -aGit 브랜치와 관련된 명령어도 존재합니다.
git branch라는 명령어로 현재 프로젝트의 브랜치 상태를 확인할 수 있습니다.
git branch -a를 입력하면 원격 저장소의 브랜치 상황도 보여주는데, 로컬뿐 만 아니라 Github와 같은 원격 저장소를 사용중인 상황에서 사용할 수 있습니다.
$ git branch 브랜치명
$ git checkout 브랜치명
$ git branch -d 브랜치명새로운 브랜치를 만드는 것은 간단합니다. 그냥 git branch에 브랜치명을 추가로 입력해주면 됩니다.
git checkout 뒤에 브랜치명을 입력하면 해당 브랜치명의 브랜치로 이동하게 됩니다.
삭제는 git branch 뒤에 -d 플래그를 추가하고 브랜치명을 적어주면 되겠습니다.
Push와 브랜치 병합 (Pull Request)
$ git remote add origin 해당 저장소 주소
$ git push origin 브랜치명원격 저장소를 사용하는 경우에는, 커밋을 한 이후에 실제로 저장소에 push를 해주어야 저장소에 반영이 됩니다.
이 때 위 명령어를 사용해서 push하면 됩니다.
origin은 원격 저장소의 주소를 뜻합니다. 따라서 이전에 원격 저장소의 주소를 등록한 적이 없다면 git remote로 시작하는 명령어 뒤에 해당 저장소 주소를 붙여 최초로 push 하면 되겠습니다.
그 이후 부터는 아래 명령어로 브랜치명만 유의해서 push를 완료할 수 있습니다.
$ git remote add origin 해당 저장소 주소
$ git push origin 브랜치명
깃허브와 같은 원격 저장소를 쓰다 보면, Pull Request라는 기능을 찾을 수 있는데, 이것이 바로 브랜치를 원래 마스터 브랜치에 병합하는 방법입니다.
해당 기능을 사용하면, git 내부적으로 병합에 문제가 없는지 검사하고, 만약 병합이 가능하다면 Pull Request를 완료할 수 있습니다.
복제(Clone)과 되돌리기(Reset)
깃허브 레포지토리에는 다음과 같이 Clone을 할 수 있는 메뉴가 따로 마련되어 있습니다.
이미지에서 볼 수 있 듯이 여기에는 해당 레포지토리의 주소를 복사할 수 있게 되어 있는데, 이를 명령어와 조합해서 로컬 환경에 레포지토리를 복사할 수 있습니다.
$ git clone 저장소 주소다음과 같은 명령어를 입력하면 현재 터미널에 열려있는 경로에 레포지토리 전체가 복제됩니다.
$ git reset --hard HEAD~1Reset을 통해 변경 사항을 다시 되돌릴 수도 있습니다. 심각한 오류나 실수가 반영이 되었을 때 이를 통해 빨리 복구할 수 있겠죠?
--hard 플래그는 예외없이 전부 되돌리겠다는 의미입니다.
Head는 버전 관리 내에서 가장 최근의 변경 사항을 지칭하는 키워드입니다. 뒤에 따라오는 물결 표시 1은, 최신의 변경 사항에서 한 버전 뒤로 가겠다는 뜻이고요.
$ git reset --hard ORIG_HEAD뒤에 ORIG_HEAD를 입력하면, 이전의 HEAD로 다시 돌아갈 수 있게 해줍니다. 다만, 이 명령어는 방금 전 git 명령어의 결과만 롤백시켜주므로, 한참 지난 실수를 만회하기 위해 사용하는 건 불가능하겠습니다.
충돌(Conflict)와 로컬 병합
가끔씩 Pull Request를 진행하다 보면, 다음과 같이 병합이 불가능하다고 메시지가 뜨는 경우가 있습니다. 당연히 이 경우에는 병합을 진행할 수 없습니다.
버전의 내용이 현재 로컬 환경의 내용과 다르기 때문이 이러한 상황이 발생합니다.
$ git pull origin master이 상황에서 위 명령어를 통해 원래 마스터 브랜치의 내용을 불러 올 수 있습니다.
그러면 다음과 같은 형식으로 현재 변경 사항과 전달 받은 변경 사항을 알려줍니다.
여기서 HEAD는 우리의 로컬 환경의 변경 사항이고, 뒤 부분의 변경 사항은 우리의 커밋입니다.
(뒤에 붙은 문자열은 커밋의 아이디로 보면 됩니다.)
이러한 상황이 충돌(Conflict)이고, 이 중 어떤 것을 실제 원격 저장소에 저장할 지 결정해야 비로소 Pull Request(커밋)을 완료할 수 있습니다.
그런데 실제 프로젝트는 훨씬 복잡하기 때문에, 변경 사항을 캐치하는 것이 어려운 경우가 많은데 그런 경우에는 위 이미지에서 볼 수 있는 "변경 사항 비교"를 클릭해서 비교하는 것이 좋습니다.
원격 저장소 외에, 로컬 환경에서 병합을 진행할 수도 있습니다.
$ git merge 브랜치명해당 명령어는 입력한 브랜치명의 브랜치를 현재 HEAD가 주시하고 있는 브랜치로 병합해줍니다.
따라서 현재 HEAD가 마스터 브랜치를 향하고 있다면, 해당 명령어로 마스터 브랜치에 내가 정한 브랜치를 병합하게 됩니다.
멘토링 그룹 스터디
저희 멘토께서는 마이리얼트립에서 개발자로 재직중이신 박지윤 님이셨습니다.
간단한 자기 소개 및 목표 설정을 시작으로 멘토링을 시작하셨어요!
굉장히 긍정적으로 느낀 부분이 멘토님께서 아주 현실적으로 접근해주셨다는 점입니다.
두루뭉술하지 않게 취업, 혹은 희망 직군 등을 여쭤보시고 현실적인 조언을 많이 해주셨습니다.
오늘 멘토링 관련 조언이나 질답 내용은 다음 노션 링크에 정리해두었습니다.
