경험에 기반한 Git과 Github 사용법

git을 사용하기 시작한지 벌써 햇수로 3년째다. 계속 꾸준히 사용해 오긴 했지만 어떻게 사용하는지, 누군가가 가르쳐주는 것보단 경험적으로 얻는 것들이 더 많았던 것 같다.
특히 오픈소스에 기여할 때 가장 얻어가는 게 많았다. 개발 공부를 시작하는 친구와 개발을 하는 중인 나를 위해 git과 github 사용법을 한 번 정리해본다.

Git과 Github

Git은 변경사항을 추적하고, 협업 시 작업을 조율하기 위해 사용되는 분산 버전관리 시스템이다.

Github는 Git 저장소 호스팅을 지원하는 웹 서비스이다.

간단하게 말하면 협업 툴이다. 조별과제로 PPT를 만들어 본 사람이라면 이해할 것이다. 여러명이 한 파일을 수정하려면 한 사람의 수정이 끝난 후 해당 파일을 다시 저장해 수정한다. 만약 내가 저장해 수정하던 중, 누군가 자신의 수정 사항을 업로드하면 다시 수정된 파일을 다운받아 수정한다. 그러면 결국 '조별과제(1)(2)(1)(1)' 등의 파일명이 만들어지는 경우가 있다. 깃은 이런 과정을 수월하게 처리할 수 있게 돕는 버전관리 시스템이다.

branch

Git을 사용할 때 중요한 개념은 branch다. 개발을 혼자 하는 경우면 모르겠지만, 대부분의 개발은 협업으로 이뤄진다. 보통 파일을 편집해야 할 때, 백업본을 하나 만든 후 새 파일에서 작업하듯이, 이렇게 독립적으로 개발할 수 있게 돕는 것이 브랜치이다. 브랜치의 뜻은 나무의 '가지'다. 분리되는 지점을 일컫기도 한다. 소스코드를 하나의 tree라고 보면, 여기저기로 분산되어 작업한 후 하나의 프로그램을 이루는 것으로 그림을 그려보면 이해가 쉽다.

실무에서는 대개 dev 브랜치와 main (혹은 master) 브랜치를 사용하며, 급한 수정이나 레거시 코드를 들어내는 별도의 작업을 할 때 따로 브랜치를 땄다.

git 사용 흐름

깃의 작업 흐름을 살펴보자.

git add : 작업 디렉토리 내 변경된 내용을 스테이징 영역에 추가
git commit : 스테이징에 있는 파일을 버전으로 기록
git push : 원격 저장소(보통 Github Repository)에 코드 변경분을 업로드

기본적으로 이 과정으로 이루어진다.

Staging Area

스테이징 영역이 무엇인가도 짚고 넘어가야 한다.

깃에서 commit시에 3개 영역을 기반으로 작동한다.

Working Directory(작업 디렉토리): 소스를 작업 중인 프로젝트의 디렉토리
Staging Area: 커밋하기 전 git add 명령어로 추가한 파일들이 모여있는 공간
Repository: 커밋들을 모아놓은 저장소

비유 하자면 내 컴퓨터(local working directory)에서 작업한 ppt를 교수님(Repository)한테 보내기 전에 나에게 보내기(Staging Area)해놓은 느낌?

정확한 비유는 아니지만 Staging Area는 일종의 대기장소이다.

예제

깃허브 & 깃 실습을 해보자.

깃 설치

git downloads 이 링크에서 운영체제에 맞는 깃을 다운로드 해 설치한다. 기본 체크되어 있는 상태로 Next 버튼을 눌러준다.

설치는 이 블로그를 참고하면 좋을 듯. https://coding-factory.tistory.com/245

깃허브 Repository 생성

깃허브의 Repository 탭에 들어가, New 버튼을 누른다.

리포지토리 생성

나는 git-demo로 리포지토리를 이미 생성했다. 기본 설정에서 아무것도 건들이지 않고 아래 Create repository 버튼을 클릭하면

리포지토리 생성

이렇게 내 깃허브에 원격 저장소가 하나 만들어진다.

깃허브 원격 저장소

로컬 환경 세팅

window에서 깃 환경을 세팅해보자.

터미널이나 git bash 를 실행한 후, 프로젝트들을 모아놓을 폴더를 생성한다.

# make directory, 'git-demo' 폴더 생성
mkdir git-demo

프로젝트를 작업할 위치로 이동한다.

# change directory
cd git-demo

깃을 해당 폴더에서 초기화한다.

git init

# Initialized empty Git repository in [경로]/git-demo/.git/ 
# 위 메시지가 출력되면 성공

파일을 하나 생성한다.

echo "# git-demo" >> README.md

# md (markdown)문서로 README 파일 생성

여기까지 완료하고 탐색기에서 해당 폴더를 열어보면, 아마 이렇게 되어 있을 것이다.

파일 탐색기 확인

만약 '.git' 폴더가 보이지 않는다면 파일탐색기에서 숨김 항목을 볼 수 있도록 설정을 바꾼다.

파일 탐색기 숨김 파일 보기

Working Directory의 상태를 확인해보자.

git status

현재 폴더에 어떤 작업이 진행되고 있는지 터미널을 통해 확인할 수 있다. 지금은 아무 커밋도 하지 않았기 때문에 No commits yet 과 함께 추적관리되지 않는 파일 README.md가 있다고 출력된다.

git status

이제 README.md 파일을 스테이징 영역에 넣어보자.
아래 명령어 중 아무거나 입력해도 된다. 다만 all (*) 은 원치 않는 파일까지 넣게 되어버릴 위험이 있으니 주의한다.

# ignore 처리된 파일 제외하고 모두 git add
git add *
# 파일명과 경로가 모두 일치하는 것 git add
git add README.md
# 확장자가 .md 로 끝나는 모든 파일 git add
git add *.md

git status 명령어로 스테이징이 잘 되었는지 확인한다.

스테이징 확인

이제 커밋을 해보자. 커밋 시에는 -m 을 붙여 Commit Message를 작성해야 한다.

git commit -m "Initial commit"

git commit

한번 더 status를 확인해보자. 커밋할 것이 없다고 출력되면 제대로 커밋된 것이다.

커밋 후 status

브랜치 명을 'main'으로 변경하자. git은 기본 브랜치가 'master'로 생성된다. 브랜치명이 프로젝트에 큰 영향을 주는 것은 아니나, master-slave 등의 브랜치명이 현 시대에 적합하지 않다고 바라보아 main-sub 브랜치로 작성하는 것이 대세다.

자세히 알고 싶으면 Go의 공지와 Why GitHub renamed its master branch to main 블로그 게시글을 읽어보자.

# 브랜치명을 main으로 변경
git branch -M main

원격 저장소(remote)와 로컬 작업 디렉토리를 연결시켜주자. 깃허브에 있는 리포지토리에서 경로를 복사한다.

add remote origin

git remote add origin [복사한 경로 붙여넣기]

# git remote add origin https://github.com/Yeony99/git-demo.git

원격 저장소로 push 한다. 아마 첫 커밋은 이런 에러가 날 것이다. upstream이 없기 때문.

git push
# fatal: The current branch main has no upstream branch.
# To push the current branch and set the remote as upstream, use

#    git push --set-upstream origin main

깃에서 해결법을 제시해준다. 그대로 명령어를 입력한다.

git push --set-upstream origin main

깃허브 리포지토리를 확인해보자.

완료된 리포지토리

기본 사용법은 이렇게 끝!

Reference

Git