git의 시초를 파헤쳐 보았다.. 그리고 깃 push하기

나는 이전 회사에서 터미널로 깃 관리를 하지 않았었다. 깃 크라켄을 사용했기 때문에 간단한 마우스 클릭만으로 깃 관리를 했었다.

캠프에 와서는 오로지 터미널로만 깃허브와 파일 관리를 해야했다. 터미널 사용법은 부족한 부분이었기 때문에 연습을 위해 단순히 폴더를 열거나 들어가는 것도 계속 터미널을 사용했다.

 

이제 조금 익숙해진 터미널 사용법과 깃 개념을 함께 묶어 정리해 본다.

 

git의 시작

깃을 검색해보면 모두 "분산형 버전 관리 시스템"이라고 한다. 그렇군..

사실 이런 개념 정의보다 좀 더 재미있을 것 같은 깃의 역사를 찾아봤다. 

 

깃의 시초는 리누스 토르발즈에서 시작된다. 참고로 리누스 토르발즈는 리눅스 운영체제를 개발한 사람으로 대단한 개발자이자 직설적이고 거침없기로 유명하다고 한다. 이 리누스 토르발즈는 원래 BitKeeper라는 버전관리시스템을 사용했다고 한다. 하지만 오픈소스를 지향하는 리누스 토르발스는 리눅스에 맞는 Git이라는 오픈소스 버전관리시스템을 만들었고 현재까지 이 Git은 가장 널리 쓰이고 있다. 

Git의 어원 또한 찾아봤지만 별 뜻이 없는 것 같다. 리누스 토르발즈의 성격대로 마음대로 지은 것 이라고 한다. 참 유쾌한 개발자다.

 

Git Hub

깃허브는 Git을 사용한 협업의 불편함을 해소하기 탄생한 플랫폼이다. Git만으로 프로젝트 협업하기에는 한계가 있었고 GitHub는 개발자들을 이어줄 플랫폼 역할을 하며 이러한 문제를 해결해준다. 레파지토리를 통해 서로 코드를 업로드하고 합칠 수 있다. 또한 현재의 깃허브는 정말 다양한 기능이 있다. 저장소, 호스팅, 커뮤니티, 블로그, 코드를 작성해주는 AI 서비스까지 제공한다고 한다.

깃허브는 나 또한 아직 잘 다루지 못해 차후 더 자세하게 포스팅해볼 예정이다.

 

 

터미널로 Git push하기

기본적인 깃 커밋 및 푸시 메세지를 정리해 본다. 사실 몇번 해보면 다 외워지는 명령어지만  메모장처럼 남겨둔다.

아래는 로컬 작업 폴더와 깃허브 레포지토리가 준비된 이후의 단계이며 loca(내 컴퓨터)l에서 remote(깃허브)로 push하는 과정이다.

 

1. git init

우선 로컬 작업 폴더에 .git 파일을 심어줘야 한다. 터미널의 현재 폴더 위치를 꼭꼭 잘 확인해야 한다. 아니면 깃이 꼬이고 만다ㅠ

git init

git init 명령어를 실행하면 다음과 같이 숨긴 폴더로 .git이 생성된다.

숨긴파일을 보는 단축키는 맥북 기준으로 커맨트+시프트+ . 이다

 

2. git status

git status

다음으로 깃 스테이터스를 통해 작업했던 파일을 확인한다.

deleted나 modified에 있는 파일은 깃이 추적한 수정 파일이다.

Untracked Files는 깃이 추적하지 못한 파일로 방금 추가한 파일이거나 ignore되어야할 파일들이다. Untracked Flied사용하지 않는다면 git clean 명령어를 사용하면 된다. 현재는 필요한 파일로 다음 단계로 넘어가면 된다.

 

3. git add

업로드할 수정 파일을 체크했다면 스테이징 영역으로 넘기는 역할을 하는 git add를 사용하면 된다.

git add .

위 명령어를 입력하면 모든 파일이 스테이징 단계로 넘어간다. 일부 파일만 업로드하고 싶다면 git add 후 파일 경로를 입력하면 된다.

 

 

4. git commit

git commit -m "댓글 등록 기능 개발"

git add 후 status를 확인하면 최종적으로 커밋할 파일을 확인할 수 있다. 그 후 git commit 명령어를 통해 커밋하면 된다.

 

 

5. git push

git push origin master

커밋 했다면 푸시를 통해 깃허브에 최종적으로 업로드해주면 된다. 참고로 commit은 저장소에 변경 사항을 로컬 저장소에 기록하는 개념이고 push는 변경 사항을 원격 저장소에 기록하는 과정이라고 한다. origin 부분은 내 레포지토리를 뜻하고 master는 브랜치명을 뜻한다. 

 

 

위의 과정을 거치면 잔디도 심기고 깃허브에 업로드도 된다. 협업 시에는 코드리뷰, PR, 머지 등의 과정을 거쳐서 작업물이 하나로 합쳐진다. 이제는 깃허브를 터미널로 사용하는 것에 조금 익숙해졌다. 아직 협업은 없어 커밋을 되돌리고 브랜치를 옮겨다니는 작업까진 못했지만 그것 또한 사용하다보면 익숙해지지 않을까 싶다. 깃허브 협업은 코드 작성하는 것보다 중요하다고 한다. 제대로 이해하지 못하고 하면 작업 파일이 날라가거나 팀에 피해를 줄 수도 있다고 하니까.. 각 명령어의 작동 방식을 잘 이해하는 것도 중요할 것 같다.

 

 

참고 자료

- 위키백과