DAY 08 | git을 가볍게 살펴 보자

FOSS 분산 버전 관리 시스템, git. 컴퓨터공학과를 졸업했다면 누구나 건드려 보았을 그것. 나 또한 대학교 3학년 때 GitHub 계정을 처음 만들며 사용해 보았다. 사실 컴퓨터공학과 학생치고는 상당히 늦은 편이었다. 팀 프로젝트에서 몇 번 써보긴 했지만 대부분은 개인 작업 백업용으로 사용하여 협업 도구로 사용해 본 경험은 거의 없다. Jenkins나 Sonarqube 같은 것도 같이 사용하며 이것저것 해봤던 것 같은데 그것도 이미 오래 전 기억이다.

누군가와 함께 작업해 본 지 한참 되었다 보니 confilct가 어쩌고 merge가 어쩌고 하는 것들은 어렴풋하게 남아 있다. 몇 번 다시 써보면 익숙해질 듯. 그래서 오늘 수업은 가볍게 들으며 기억 저편의 지식들을 되짚어 보는 시간을 갖기로 했다. 대체로 Git Cheat Sheet 보면서 사용하면 무리 없이 사용할 수 있을 것 같긴 하지만.

깊이 있는 공부를 원한다면 생활코딩을 추천하시더라.

git이란 무엇인가

git은 Linux의 창시자 리누스 토발즈가...하는 내용으로 시작하며 공부했던 학생 때의 기억이 스멀스멀 기어 올라온다. git의 주요 목적은 버전 관리, 백업 및 복구, 협업이다. 버전 관리가 핵심인데 개인 개발자는 백업 및 복구 목적으로 많이 사용한다고. 협업은 GitHub이 나오면서 크게 발전했다는 모양이다.

누군가의 질문으로 살펴본 버전 관리와 형상 관리

구분	버전 관리 (Version Control)	형상 관리 (Configuration Management)
개념	소스 코드 파일의 변화를 기록하고 관리함	소프트웨어 생명주기 전체의 산출물을 통제함
범위	하위 개념 (형상관리의 기술적 수단)	상위 개념 (프로젝트 관리 방법론)
주요 대상	소스 코드, 리소스 파일, 텍스트 문서 등	요구사항 정의서, 설계서, 테스트 시나리오, 소스 코드, 빌드 파일, 매뉴얼 등
핵심 목적	개발자 간의 코드 충돌 방지 및 이력 추적	제품의 품질 보증 및 변경 승인 절차 통제
수행 주체	주로 개발자	개발자, QA, 프로젝트 매니저(PM), 고객, 형상관리자(CCB)

git은 자동으로 버전을 만들지 않는다. 기록하고자 할 때마다 Commit을 해 주어야 한다.

git 명령어 살펴보기

[주요 Git 명령어]

명령어	의미
git init	현 위치를 git repository로 만든다. (woriking directory; untracked files)
git add	working directory에 있는 파일의 변경사항을 stage에 올려 tracked file로 만든다.
git status	working directory 및 stage에 있는 디렉토리/파일 목록을 출력한다.
git commit	현재 stage에 존재하는 변경사항을 모아 버전 기록을 한다.
git log	지금까지의 commit 내역을 확인한다.
git remote add	commit을 push/pull 할 remote repository를 등록한다.
git push	local repository의 commit을 remote repository로 내보낸다.
git pull	remote repository의 commit을 local repository로 불러온다.
git fetch	remote repository의 commit을 local repository로 가져오되, 바로 합치진 않고 별도 branch에 불러온다.
git merge	Fetch한 branch와의 conflict를 해결하여 병합한다.

git init 은 프로젝트 루트에서 해 주어야 한다. Dart 프로젝트는 항상 프로젝트 루트에 pubspec.yaml 파일이 있으므로 이 파일이 있는 위치에서 수행하면 된다. git reopository에는 관리용 .git 디렉토리가 생성된다. 존재하지 않을 경우 .gitignore 파일도 함께 생성된다. tracking 하지 않을 대상을 명시해 놓는 파일이다.

git add 뒤에 디렉토리/파일 경로를 붙이면 해당 디렉토리/파일의 현재 상태가 Stage로 올라간다. git add . 하면 현재 디렉토리와 그 하위 모든 디렉토리/파일의 현재 상태가 Stage에 올라가고,git add --all 하면 프로젝트 내 모든 디렉토리/파일의 현재 상태가 Stage에 올라간다. 프로젝트 루트에서 실행하면 이 둘이 동일하지만, 하위 디렉토리에서 실행하면 git add . 는 상위 디렉토리에 있는 건 담지 못한다.

git status 했을 때 Changes to be committed: 에 뜨는 녀석들이 Stage에 있는 것이며 Untracked files: 에 있는 녀석들이 Working Directory에 있는 것이다. Commit까지 완료되어 Local Repository에 있는 녀석은 이 목록에 뜨지 않는다.

git commit 에는 -m 옵션을 사용하여 description message를 남겨야 한다. 나는 문서를 수정했을 땐 "docs: description" 와 같이 작성하고 기능을 추가했을 땐 "feat: description" 와 같이 작성한다. 그리고 특별한 일 없으면 -S 옵션을 사용하여 GPG 서명도 추가한다.

git log 로 그 동안의 Commit 내역을 확인할 때, 구체적인 Commit 시점을 파악해야 하는 게 아니라면 나는 보통 --oneline 옵션을 함께 사용하는 편이다. 어떻게 흘러갔는지 가볍게 훑어보는 용이다.

remote repository는 어느 것이든 쓸 수 있지만 보통은 GitHub, GitLab, BitBucket 등의 서비스를 이용한다. GitHub이 압도적 1위라고. 난 이걸 셋 다 써본 적 있던 것 같은데 어느 프로젝트에서였더라. 문득 궁금해져서 살펴 보니 GitLab은 Inkscape 문서 오탈자 제보하고 한국어 번역할 때 써 봤군. BitBucket은 계정이 만들어져 있긴 했는데 뭔가 들어있진 않아서 잘 기억나진 않는다.

하여간 git remote add REMOTE_NAME REMOTE_URL 형태로 등록한 remote repository는 git remote -v 명령어를 통해 확인할 수 있다. 특별한 일 없으면 가장 대표적으로 사용되는 원격 저장소 별칭은 origin 으로 한다. 보통은 GitHub 저장소 하나만 사용하며 그것을 origin 으로 사용한다.

git push REMOTE_NAME BRANCH_NAME 명령어를 사용하면 해당 remote repository의 해당 branch에 그 동안의 commit이 올라간다. -u 옵션을 사용하면 해당 branch를 upstream으로 설정할 수 있다. upstream으로 설정된 remote repository에 push/pull 할 땐 이름을 생략하고 git push 및 git pull 만으로 수행할 수 있다.

conflict가 발생하지 않을 상황에서는 git pull 로 충분하지만 여러 사람과 작업을 할 경우에는 git fetch 후 git merge 를 해야 할 수 있다. conflict를 대처하는 방법까지는 우리 수업에서는 다루지 않는다. 팀 프로젝트를 할 땐 종종 마주쳤던 것 같다.

실습은 생략하고,

진행하다 더 좋은 무언가가 떠올라 기존의 것을 엎게 되더라도 일단 프로젝트를 시작해 보기로 했다. 가칭 NF 라고 하겠다. Figma로 autolayout 다루고 등등 하는 건 익숙한 편이니까 wireframe 잡는 것도 조금 찾아보면 할 수 있겠지. (위의 git 관련 이미지도 Figma에서 autolayout 기반으로 그린 거다.)

wireframe을 잡는 데 도움이 되는 Figma plugin으로는 Wireframe이 있는 모양이다. 이를 활용하여 제작된 템플릿들도 많이 공유되어 있는 모양이고.

일단 기획을 좀 더 구체화하고 어떻게 구성되어 있어야 할지 생각하며 wireframe 작업을 해 보기로 했다. 완벽하게 해내려고 하기 보다는 할 수 있겠는 만큼 작업하고 나중에 보완하는, 약간은 spiral한 방식으로 진행될 것 같기도 하고.