일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 우아한테크코스
- 코드잇 JavaScript 프론트엔드 개발자
- 길벗
- 코드잇 Python 풀스택 개발자
- 개발자
- 오블완
- solved.ac
- fixed
- 수행 시간
- 개발자취업
- 7기
- 스트릭
- Til
- 백준
- 코드잇
- 리뷰어
- 99클럽
- cout.precision
- 파이썬
- 소수점 출력
- 항해99
- 프리코스
- 코드잇 강의
- 백준 1000문제
- 백준 문제 출제
- 코딩테스트준비
- timeval
- 백준 스트릭
- 우테코
- 티스토리챌린지
- Today
- Total
BE THE DEVELOPER
10월 16일 (1) : Git을 제대로 알고 이용하자 (1) 본문
오늘은 실제로 레포지토리를 만들고 컨벤션에 대해 배우는 작업을 해보려 한다.
Git과 GitHub 다시 파헤치기
평소에 나는 깃허브에서 레포지토리를 만들고, 로컬 환경으로 가져올 때 아래와 같은 순서로 진행한다.
- GitHub에서 레포지토리 생성 및 .git 형식의 링크 복사
- 바탕화면의 새 폴더를 만들고, 해당 폴더 경로로 VS Code 실행
- 터미널에 git clone <복사한 레포지토리 링크> . 입력 </aside>
위와 같은 순서로 진행하면 사실 별 무리없이 진행할 수 있고, 실제로 틀린 방법이 아니다. 하지만 이 방법만을 계속 이용하다보니 git init을 이용하여 깃 저장소를 만드는 방법을 까먹게 되었다.
물론 사용에 문제가 있는건 아니지만, 평소에 Git에 대한 개념이 파편적이라고 생각해왔기에 이참에 다시 하나하나 테스트해보며 정리하려 한다.
git init과 git remote
git clone을 이용하는 건 git init과 git remote를 한꺼번에 진행하는 명령어로 알고 있다. 우선 명령어를 진행하기 전에 실제로 레포지토리를 포크해와서 VS Code까지 가져오는 작업을 했다.
git init 작업을 하면, 폴더 내에 .git 폴더가 생긴다.
적혀있다시피 .git 폴더가 생긴걸 볼 수 있다. 그렇다면 이 .git 폴더가 하는 역할은 무엇일까?
검색해본 결과… “Git이 버전 관리를 하기 위한 메타 정보가 담겨있으며, 구체적으로 어떤 내용인지는 Git을 사용할 때 크게 중요하지 않습니다.”라는 블로그 글을 보게 됐다.
하지만 이 디렉토리를 지우게 되면 해당 Git 저장소의 모든 변경 이력이 소실되고 일반 저장소로 들어온다는 내용까지 확인했다.
출처: https://www.daleseo.com/git-init/
git remote 작업을 통해, 로컬 레포지토리와 원격 레포지토리를 연결할 수 있다.
git remote add <원격 저장소 이름> <원격 저장소 URL>
위 명령어를 통해 내가 GitHub 내에 생성한 레포지토리와 로컬 레포지토리를 연결할수 있다. 하지만 여기서 의문이 드는건 “원격 저장소 이름”이라는게 어떤 걸 의미하는 건지 모르겠다. 그래서 git clone을 이용했던 다른 레포지토리에서는 어떤 이름으로 저장됐는지를 확인해봤다.
여기서 확인해본 결과 origin이라는 이름으로 저장된걸 알수 있다. 즉, git clone 명령어는 아래와 같은 명령어와 같다는 걸 알 수 있었다.
git init
git remote add origin <원격 저장소 URL>
origin이 의미하는 건 결국 로컬 레포지토리 입장에서, 원격 레포지토리에 붙이는 별명 같은 거라는 사실을 알게 되었다. 평소에 origin이 도대체 뭔지 몰랐었는데 이 부분을 알게 되었다.
git clone은 한 가지 작업을 더 해준다.
하지만 위 작업까지 했을 때 git clone과의 차이가 하나 있다. git clone을 하면 레포지토리에 있던 파일들이 그대로 들어오는데, 지금 아직 내 로컬 환경에는 아무 파일도 들어와있지 않다.
즉, 파일을 땡겨오는 작업을 따로 진행해줘야 한다. (이쯤되면 git clone이 정말 편한 명령어였다는 생각이 든다.)
git pull과 git fetch
git pull은 git fetch보다 복잡한 작업이다.
내가 기억하기로는 git pull과 git fetch 모두 파일을 땡겨오는 역할을 할 수 있던걸로 기억한다. 하지만 둘의 명확한 기능이 뭔지 정확히 몰라서 한번 알아보기로 했다. 일단 평소에는 git pull을 자주 사용하긴 했다.
우선 구글링을 통해 찾아본 내용은 아래와 같다. 출처: https://kkh1902.tistory.com/152
git pull <원격 저장소 이름> <원격 저장소 브랜치>
원격 저장소에 있는 변경 사항을 그대로 로컬 저장소에 옮겨와 자동으로 합쳐줌.
기본적으로 git pull해서 땡겨올 수도 있고, git pull origin main처럼 모두 입력해서 땡겨올 수도 있음.
git fetch
원격 저장소에 있는 변경 사항을 가져오기만 하고, 합쳐주지는 않음.
(다른 사람이 수정한 부분을 확인하고 가져올 수 있다는 장점이 있음.) 명령어도 pull과 동일할듯.
따라서 이번에는 git fetch를 통해서 가져오고, 합치는 작업도 해보려 한다. GitHub 사이트가 아닌 직접 merge하는 과정을 해본 적이 없기에 약간 두렵긴 하지만, 우리에겐 구글링이 있으니까 할 수 있을듯.
git fetch를 하면 새로운 브랜치가 생긴다.
git fetch를 이용해봤는데, 아무런 변화가 일어나지 않고 한줄의 메시지만 떴다. 적어도 좌측 패널에 커밋할게 있다고 뜰 줄 알았는데… 아무런 반응이 없길래 git fetch를 이용할 경우 어떻게 할 수 있는지 또 알아봤다.
출처: https://velog.io/@devp1023/GIT-Fetch
- git fetch를 이용하면 원격 저장소의 변경사항을 FETCH_HEAD에 가져오게 됨.
- 따라서 git merge FETCH_HEAD를 입력해야 현재 브랜치에 병합할 수 있음. </aside>
대충 FETCH_HEAD라는 브랜치가 새로 생기게 되었고, 이 브랜치에 변경사항이 저장되어 있기에 이 내용을 main에 병합하면 되는 거라 이해하고 실행해봤다.
음… 잘못 이해한듯 하다. 하지만 찾아보니 저 오류는 브랜치명을 잘못 입력했을 때 나온다고 한다. 따라서 브랜치명이 FETCH_HEAD가 아니거나, fetch 작업에서 문제가 있었다는 생각이 든다.
도대체 뭐가 잘못된건지 모르겠지만 git pull을 해서 결국 해결하기는 했다. 아무래도 맨처음에 git fetch 과정에서 main까지 입력한게 화근이 된 듯 했다. FETCH_HEAD로 checkout도 해봤지만 이상한 브랜치명으로 이동한걸로 보아, FETCH_HEAD에 변경 사항이 들어갔던건 맞는듯하다.
대충 어떻게든 복사에 성공했다! 사실 Git에 대해서 파헤쳐본김에 git commit과 git push에 대해서도 조금더 알아보고 싶은데, 오늘 내용이 너무 길어졌으니 나중에 적는 걸로 해야겠다.
까먹기 전에 내 아이디로 된 브랜치로 만들고, checkout하고 마무리해야겠다.
'일기장 > 우아한테크코스 7기' 카테고리의 다른 글
10월 19일: 문제 정의하고 README.md 작성하기 (1) | 2024.11.02 |
---|---|
10월 18일: 주어진 라이브러리를 분석하고 코드 짜기 (0) | 2024.11.01 |
10월 17일: 코드의 목표 설정 및 실제 코드 작성하기 (0) | 2024.10.31 |
10월 16일 (2): JS 컨벤션에 조금 더 익숙해져보자 (1) | 2024.10.30 |
10월 15일: 우테코 서비스 둘러보기, 목표 설정하기 (9) | 2024.10.29 |