블로그 포스팅을 시작하고, 코드 관리를 위해 깃허브를 처음 설치하고 처음으로 깃허브 명령어를 사용해보기 시작했다. 처음에는 복잡한 명령어를 사용해 컨트롤하기보다는 직접 리포지토리생성해서 업로드하는게 더 쉽지 않을까 대수롭지 않게 생각했지만, 코드 작성 후 리포지토리 끌어와 바로 업로드 할 수 있게 되니 확실히 편하다 싶었다.
조금 더 깃허브에 적응해 능숙해질 필요가 있다고 여겨 최근 배운 깃허브 기초 명령어들과 깃허브 웹페이지 인터페이스들을 정리해두려고 한다. 기본 명령어는 요즘 수강 중인 개발 유튜버 '제로초'님의 영상을 시청해 익혔다.
https://youtu.be/cEg9hiZax8U?si=94UhKBr_29P7Ma-Z
위 영상 시리즈만 쭉 정주행해도 당장 깃허브를 활용하는 것에 별 문제가 없어진다. (하루만에 들을 수 있는 분량이다.)
깃허브를 연결하기 위해서는 한 가지 필수 프로그램과 한 가지 보조 프로그램이 필요하다. 보조 프로그램은 Git 관리를 더 수월하게 해주는 역할로, 꼭 설치할 필요가 없긴 하다.
1. 깃 설치하기
- 필수 프로그램 : 깃
https://git-scm.com/download/win
위 사이트에 접속해 본인 컴퓨터 사양에 맞는 Git을 다운받는다. 요즘은 다 64bit 컴퓨터이므로 64-bit Git for Windows Setup. 옵션을 받으면 될 것이다. 설치 파일을 실행해 쭉 next를 클릭해 설치를 완료해준다.
- 보조 프로그램 : 포크
깃 관리를 가시적으로 확인할 수 있게 해주는 프로그램이다. 유사한 프로그램이 다양하게 있는 모양이지만 나는 제로초님이 추천해주신 대로 Fork 를 사용해보기로 했다.
마찬가지로 설치파일을 실행해 컴퓨터 원하는 위치에 설치해준다.
깃이 잘 설치되었는 지 확인하려면 편집기 cmd 창에서 [ git -v ] 를 입력해주면 된다. 설치한 깃 버전이 잘 출력되면 무사히 설치된 것이다.
설치 완료하면, 프로그램을 실행해 위와 같은 인터페이스로 도움을 받을 수 있다. 현재 내가 개발 중인 브랜치의 커밋들을 확인할 수 있고, 두 개 이상으로 나뉜 브랜치가 어느 시점에 합쳐졌는지, 몇 개의 브랜치가 독립적으로 나뉘어있는 지 등의 정보도 시각적으로 확인할 수 있다. 오른쪽에서 두 번째 여섯자리의 문자열은 커밋ID로, GIT 명령어 중에 해당 ID를 통해 원하는 시점으로 되돌아갈 수 있는 기능이 있다.
깃허브 웹에서 끌어온 커밋 정보도 확인할 수 있다.
2. 내 로컬 프로젝트에 깃 연결하기
깃허브에 내 코드를 올릴 수 있는 저장소 한 칸 한 칸을 리포지토리(Repository)라고 부른다. 국내에서는 레퍼지토리, 레포지토리 등등 다양한 발음으로 불리고 있는 모양이라, 어떤 발음이 튀어나와도 뜻하는 바는 전부 위 개념의 리포지토리(Repository)다.
로컬 프로젝트에 깃을 연결해 웹 리포지토리에 백업해보고, 반대로 웹 리포지토리에 저장되어있는 프로젝트를 로컬로 불러오는 작업도 해보겠다. 쉽게 풀어쓰면 웹 저장소에 백업해놨다가 후에 수정을 위해 도로 가져오는 과정이다.
우선 나는 로컬에서 코드들을 관리할 프로젝트 폴더, 'GitTest'를 생성했다. 사용 중인 편집기는 Visual Studio Code 이다. 폴더 안에 test.js 파일을 새로 생성해 짧은 코드를 작성해보았다. 또한 다들 일반적으로는 npm으로 노드 패키지들을 설치해 사용할 것이기 때문에 그런 환경까지 간단하게 조성해보았다.
1) GIT 에게 프로젝트 관리 시작 명령하기 & 관리 제외 리소스 지정하기
목표는 프로젝트 폴더 내의 리소스들을 깃헙 웹 리포지토리에 올려놓는 것이다. 하지만 위 파일 리스트 중 node_modules 폴더의 파일들은 너무 양이 많을 뿐더러, 버전과 패키지명 등의 중요한 정보들은 이미 pakage.json과 pakage-lock.json 파일에 기록되어 있다.
때문에 보통 깃허브 리포리토지에 업로드할 때는, node_modules 폴더는 제외 한 채 대신 package와 package-lock 파일을 올리는 편이다.
제외하는 방법은 간단하다. 프로젝트 폴더 내에 .gitignore 파일을 새로 생성해 그 안에 git 관리에서 제외할 폴더 및 파일명들을 적어주면 된다. 아래 사진 처럼 하면 된다.
이제 '이 폴더의 파일들을 깃으로 관리하겠습니다.' 라는 뜻의 명령어를 입력해 관리를 시작해준다. 편집기 명령어창(cmd창)에 [ git init ] 를 입력한다.
그러면 위 사진 처럼 git이 관리를 시작한 폴더들에 색깔이 입혀진다. 하지만 .gitignore 폴더는 관리에서 제외되어 회색빛이 들어와있는 것을 확인할 수 있다.
참고로 모든 깃 관리 정보는 프로젝트 폴더 내에 '.git'이라는 이름의 숨김 폴더에 저장되어 있다. 해당 폴더를 삭제하면 모든 깃 관리 정보가 사라지니 그 존재만 인지한 채로 웬만해서는 건들지 말자.
명령어 창에 [ git status ] 를 입력해본다. 파일들의 관리 상태를 확인할 수 있는 명령어이다.
프로젝트의 파일들이 붉은색으로 표시되어있다. Untracked file 이라고 불리는 상태로, 커밋할 준비가 덜 된 파일이라는 뜻이다.
2) 깃 커밋 준비하기
깃 환경에서의 코드는 커밋에 도달하기까지 대략 세 단계의 과정을 거친다.
(1) Untracted 단계 : 파일들을 수정 중인 상태. (붉은 글씨)
(2) Unstage 단계 : 파일 수정을 완료해, 커밋 준비가 완료된 상태 (초록 글씨)
(3) Commit 단계 : 커밋 완료한 상태 (status에 보여지지 않음)
Unstage 단계가 되어도 다시 수정사항이 발생하면 자동으로 Untracted 단계로 바뀐다. Unstage는 '파일 수정 중'과 '커밋'의 중간 단계로, 나는 주로 수정진행도가 커밋을 할 정도로는 너무 양이 적고, 그렇다고 그대로 두기에는 찝찝할 때 틈틈히 Unstage 상태로 바꿔둔다.
Unstage 상태로 바꾸는 명령어는 [ git add <파일명> ] 이다. 파일명을 입력해 개별 파일 별로 상태를 변경할 수도 있지만, 파일명 자리에 [ * ] 를 입력하면 모든 파일들을 한 번에 상태변경 할 수 있다.
[ git add * ] 을 입력해 모든 파일을 Unstage 상태로 바꾼 후 다시한번 status를 찍어본다.
무사히 모든 파일들이 add 되었다.
Commit을 하기 위해서는 모든 파일들이 Unstage 단계이어야 한다. commit 명령어는 그냥 commit이다.[ git commit ] 명령어를 실행하면 커밋 메시지를 남기는 단계로 넘어가는데, 이 단계 컨트롤이 조금 귀찮다.
때문에 나는 commit 명령어와 함께 메시지를 입력할 수 있는 옵션을 주로 사용한다.
[ git commit -m "메시지 내용 입력" ]
나는 위 명령어로 커밋해보겠다.
shortlog 명령어는 커밋 로그를 간단하게 확인할 수 있게 해준다. 네 개의 파일이 모두 무사히 커밋 완료된 상태를 확인할 수 있다.
위 메시지 머리에 쓴 'TEST :' 라는 태그는 보편적으로 사용되는 커밋 메시지 규칙이다. 뭐든지 규칙을 적용해 기록을 남겨두면 내 코드를 보는 미래의 나에게도 협업자에게게도 큰 가독성을 안겨주는 법이다. 이 규칙도 아래에 간단하게 정리해둔다. 더 자세한 규칙을 알고 싶으신 분은 따로 검색해보시길....
- FEAT : 새로운 기능 추가
- FIX : 버그 수정
- DOCS : 문서 수정
- STYLE : 코드 포매팅, 스타일 수정과 세미콜론 누락 등 Syntax 수정 관련
- REFACTOR : 코드 리팩토링
- TEST : 코드 테스트
- PERT : 성능 개선 관련 수정
- CHORE : 그 외 자잘한 수정
위 단계까지 진행했으면, 이제 내 리소스들을 깃헙 웹 리포지토리에 올릴 준비가 모두 끝났다.
3) 웹 깃허브 리포지토리 주소 가져오기 & 로컬 메인 Branch명 변경하기
웹 리포지토리에 프로젝트를 백업하기 위해서는, 먼저 로컬 깃 환경으로 웹 리포지토리의 주소를 가져와야 한다. 웹 리포지토리 주소를 가져오는 명령어는 'remote add' 이다.
[ git remote add <변수명> <리포지토리 주소> ]
→ [ git remote add origin https://github.com/내 깃허브 이름/연결할 리포지토리 이름 ]
리포지토리 주소는 웹에서 리포지토리 접속했을 때의 주소창 링크이기도 하다. origin은 git에서 리포지토리 주소를 저장할 변수라고 생각하면 이해하기 쉽다. (일반적으로 origin 으로 사용한다.)
가져온 리포지토리 주소는 아래 두 가지 방법으로 확인할 수 있다. 단순히 'remote'명령어만 입력하면 주소를 저장한 변수명이, 'remote get-url <변수명>' 명령어를 입력하면 변수에 저장된 리포지토리 주소를 확인할 수 있다.
이제 리포지토리에 내 코드를 올릴 수 있는 준비물이 모두 모였다. 하지만 마지막으로 한 가지 더 체크해두면 좋을 사항이 있다. [ git branch ] 명령어를 입력하면 현재 내가 로컬에서 작업 중인 브랜치 명을 확인할 수 있다.
아무런 세팅을 하지 않았다면 초기 브랜치 명은 'master' 이다. 하지만 웹 깃허브에서 생성되는 기본 브랜치 명은 'main'이다. 아래 이미지에서 노란색으로 표시한 부분이다. 원래는 웹 깃헙에서도 'master'라는 이름을 사용했지만 과거 노예제 시절 때의 'master' 이미지를 연상시킨다는 이유로 'main' 으로 변경됐다는 모양이다.
로컬은 'master', 웹 깃헙은 'main'인 현재 상태로 코드를 백업하면 내 코드가 main 브랜치에 저장되지 않고 master 브랜치가 하나 더 생성되어 저장된다. 이를 해결해주기 위해 로컬 깃 설정에서 현재 브랜치명을 main으로 변경해주면, 웹 깃헙에도 main 브랜치에 깔끔하게 저장된다.
브랜치 이름을 바꾸는 명령은 branch 명령어에 -m 옵션을 덧붙이면 된다.
[ git branch -m <바꿀 이름> ] → [ git branch -m main ]
이후 다시 'git branch' 를 통해 브랜치명을 확인해보면, 정상적으로 'main'으로 변경된 모습을 확인할 수 있다.
4) 내 코드 웹 깃허브 리포지토리에 백업하기 + 'failed to push some refs to ~' 오류
이제 진짜로 내 코드를 웹 깃허브에 올려보자. 로컬 깃에서 웹 리포지토리로 커밋하는 명령어는 'push' 이고, 반대로 백업한 코드를 끌어오는 명령어는 'pull' 이다.
[ git push <리포지토리 경로 변수명> <로컬에서 작업 중인 브랜치명> ]
→ [ git push origin main ]
백업 명령이 정상적으로 수행되면 위와 같은 메시지가 표시되며 웹 깃헙 리포지토리에 내 코드들이 업로드된다.
이렇게 파일들이 무사히 보여지면 성공이다.
+) 웹 깃허브 리포지토리 생성 시 README.md 파일을 만들었을 경우 발생하는 오류
로컬 콘솔에서 'git push ~' 명령어를 수행했을 경우 아래와 같은 오류 메시지가 발생하는 경우가 있다. 사실 이미 hint 라고 적힌 노란 글씨에서 오류가 발생하는 이유를 전부 알려주고 있다.
웹 깃허브에서 새로운 리포지토리 생성 시, README 파일을 자동으로 추가하는 옵션이 있다. 이 옵션에 체크했을 경우 리포지토리에는 README.me 파일이 자동으로 만들어진다.
하지만 내가 로컬에서 작업 중인 프로젝트 폴더에는 README.me 파일이 포함되어있지 않다. 로컬 깃 정보에도 README 파일을 생성했다는 기록이 없다. 이 불일치 때문에 깃에서는 사용자가 코드를 엉뚱한 리포지토리에 덮어씌우려는게 아닌가 우려한다. 만약 실수로 로컬 깃에 다른 리포지토리의 주소를 가져왔거나, 내가 작업하지 않는 사이 협업자가 웹 깃헙의 코드를 수정해놓은 상태라면, 내 코드를 그대로 백업 시키는 것은 너무나 위험한 짓이다.
그렇기에 깃에서는 웹 리포지토리와 로컬 프로젝트 폴더 간에 부자연스러운 불일치가 발생할 경우 위의 경고 메시지처럼 해당 사실을 알려주며 백업을 거부한다.
그리고 pull 명령어를 이용해 먼저 리포지토리에서 코드를 끌어온 후, 기존 로컬 코드와 merge를 하든 수정을 하든 해서 다시 push해달라고 요청한다. 그런 내용의 오류 메시지다.
5) 웹 깃허브 리포지토리에 백업한 코드 로컬로 가져오기
마지막으로 리포지토리에서 백업한 코드를 끌어와보겠다. 이미 언급했듯이 백업한 코드를 가져오는 명령어는 'pull' 이다.
[ git pull <주소 변수> <브랜치명> ] → [ git pull origin main ]
main 브랜치로 origin 주소의 코드들을 가져오겠다는 의미의 명령이다. 해당 명령을 실행시키면 웹 리포지토리의 코드들이 내 로컬 프로젝트 안으로 들어온다.
혹시 로컬 프로젝트의 리소스들과 가져오는 리소스 간에 차이가 있다면 이 또한 깃에서 알려주고, 끌어온 코드를 적용할 것인지, 기존 코드를 적용할 것인지 선택할 수 있게 해준다.
여기까지가 로컬 프로젝트와 웹 깃허브 리포지토리를 연결하는 과정이다. 이 과정에서 사용된 명령어 외에도, 깃에는 사용자가 프로젝트 소스를 효율적으로 관리할 수 있게 해주는 다양한 명령어들을 지원하고 있다. 다음 포스팅에서는 보다 다양한 명령어들과 웹 깃허브 인터페이스를 공부한 후 정리해두려고 한다.
- END.