[Step 1 - Week 7] 깃&깃허브 완전 정복 chapter 1

카테고리 없음

[Step 1 - Week 7] 깃&깃허브 완전 정복 chapter 1

ramin0119 2025. 5. 23. 16:21

728x90

"출처: 스파르타 코딩 클럽 사이트의 카카오테크 캠퍼스 3기 수업 내용"을 기반으로 적은 내용입니다.

별도 출처가 적힌 사진을 제외한 사진은 스파르타 코딩 클럽 사이트의 카카오테크 캠퍼스 3기 수업 내용을 기반하였음을 알립니다.

Chapter 1

다양한 버전 관리 툴과 특징들 ( 기업별로 필요한 비즈니즈가 달라 존재)

Gitlab

Github 다음으로 코드를 저장하는 원격 저장소 기준 가장 많이 사용하고 있는 Gitlab!

거의 대부분의 기능은 Github에서 언급할 기능들과 사용성이나 브라우저 화면 상 동작은 비슷하다고 볼 수 있다.

But, 큰 차이점 중 하나는 각 기업에서만 접근할 수 있는 격리된 네트워크 환경에서 구성할 수 있는 설치 파일 등을 제공하는 점이다.

따라서, 매출 규모가 좀 작은 스타트업에서는 초기에 시작할 때 Github을 많이 사용하고, 일정 규모 이상이 넘어가면 그 때부터는 자체 네트워크에서 구성할 수 있는 Gitlab 서비스를 사용한다.

Gerrit

위의 Gitlab과 마찬가지로 각 회사 별로 자체 네트워크에서 구축할 수 있는 코드 저장소이다.

But, 큰 차이점은 첫번째로 구글에서 개발하고 관리한다는 점이고, 두번째는 사용자가 작성한 코드를 다른 협업하는 사람들과 합칠 때, “매우 엄격한” 코드 리뷰 기능을 제공하고 있다는 점이다.

ex) 여러분이 작성한 코드를 리뷰를 해주는 팀장님 내지 코드 품질을 깐깐하게 따지는 팀원이 있다면 그 분의 승인과 더불어 한 명 이상의 프로젝트 구성원이 함께 승인해주지 않으면 코드를 프로젝트에 합칠 수 없다.

BitBucket

MS 계열인 아틀라시안이라는 곳에서 개발하고 배포하는 “유료” 솔루션이다.

일반적으로 작성하는 코드는 프로젝트 단위로 작성한다. 그래서 프로젝트에서 “OO 기능 개발”, “OO 버그 수정” 등으로 업무가 나눠지는데, 이 때 이 나눠지는 단위를 관리하는 애플리케이션을 “Jira” 라고 한다.

특정 프로젝트 관리 플랫폼과의 밀접한 사용 연관성을 고려했을 때, BitBucket이라는 도구를 사용하기도 한다.

다만, 워낙 많은 사용자가 github이나 gitlab 등을 사용하고 있기에 다른 코드 저장소 플랫폼도 연동될 수 있게 지원해주고 있다.

분산형 버전 관리 이해하기

Git의 기본 - 분산형 버전 관리 시스템

우리가 앞으로 사용할 Git은 분산형 버전 관리 시스템이라는 시스템 구조를 골자로 하고 있다.

즉, 우리는 Git을 사용하는 시점부터 "중앙에서 관리하고 있던 모든 이력을 가진 저장소 전체를 복사하여 사용자의 컴퓨터로 가져와 사용"하는 것을 의미한다.

로컬이나 중앙에 존재하는 하나의 서버에서 코드를 가져와 사용하는 것이 아니다!!!

변경 이력과 같은 히스토리는 그냥 중앙에서 보면 되지 않나요? 왜 분산형인가요?

한 달 내내 걸쳐 작성한 코드 중에서 분명히 어려운 내용의 코드도 있을 것이고, 이 내용들에 대해서는 여러분이 기록한 댓글이나 주의 사항, 또는 어떻게 해결했는지에 대한 기록이 있을 것이다.

그런데 이 기록을 매번 중앙에 들어가서 조회를 해야 한다거나, 최악의 경우 중앙에서 관리하고 있는 서버가 죽는다면?

그런 상황을 피하고자 모든 환경에서 코드 변경 이력 등을 포함해 가져와야 하는 이유가 분산형 관리 시스템에 포함된다.

프로젝트 저장소에 문제가 있더라도 언제든지 백업이 되도록!!!

필수 프로그램 설치

✅ Google Chrome
✅ Git
✅ (Window) Git bash
✅ VS Code

VS Code에서 도움이 될 만한 Extension 설치하기

Git Graph

Git으로 열심히 작업하다보면 만들어지는 커밋 기록이나 버전 등을 Github으로 이동하지 않고 그래프 형태로 직관적으로 확인할 수 있다.

Git Lens

코드의 특정 단락, 라인등에 커밋 관련 정보를 회색으로 보여주는 것을 확인할 수 있으며, 어떤 사용자가 어떤 메세지로 커밋했는지 알 수 있다.

Git History

특정 파일의 커밋 히스토리를 보고싶을때 사용할 수 있고, 파일을 열어서 화면 오른쪽 파일 이름을 오른쪽 클릭해서 Open File History를 선택해 Git으로 기록된 히스토리를 조회할 수 있다.

Git 용어 설명하기

working tree
staging area
local directory (.git directory)

git의 작업 흐름을 시각적으로 나타내는 구조도는 다음과 같다.

Working Tree

Working Directory, Staging Area, .git directory(=local 저장소) 3개 영역을 아우르는 것을 Working Tree라고 부른다.

Git이 원격 저장소로 업로드하기 위해 추적(관리)하는 파일과 추적하지 않는 파일을 구분하고, 추적하는 파일들의 상태를 구분짓는 영역을 말한다.

우리가 원격 저장소에 코드를 올리기 전까지 사용자의 컴퓨터에서 발생하는 모든 작업이 이 Working Tree라는 곳에서 이루어진다.

Working Directory

우리가 실제로 소스코드를 작성하고 편집하는 영역으로, 아직 Git으로 변경사항을 기록하기 전 단계이다.

해당 경로에서 우리가 Git으로 기록할 파일과 그렇지 않은 파일들을 구분하고, 지정해줄 수 있다.

Stage Area

Working Directory에서 우리가 Git으로 추적할 파일과 그렇지 않는 파일들을 선택할 수 있다고 했다.

이 중에 우리가 추적할 파일들에 대해서 가상의 저장 공간에 기록한다. 이 가상의 Stage Area가 가상의 공간이다.

잠시 머무르는 공간이라고 이해해도 될 것 같다.

보통 보통 사용자가 작업 기록을 구분해서 구성하고 싶거나, 보안적인 이슈로 인해 원격 저장소로 올려야할 파일과 그렇지 않은 파일을 구분할 목적으로 사용한다.

Local Directory (= .git directory)

Stage Area에 기록된 코드들은 이제 원격 저장소로 저장하기 위해 그 다음 단계인 local repo 또는 .git directory에 기록된다.

이 때 commit이 이루어진다.

git 명령을 사용하면서 자주 언급되는 command

commit
snapshot
head
branch
merge

git commit

우리가 stage area에서 원격 저장소로 들어가기 전 저장한 결과 값은 commit이라는 작업으로 이루어진다.

그리고 그 결과 값이 .git directory에 기록된다.

git을 사용하는 관점으로 풀어보면 아래 이미지에서 붉은 박스에 해당 하는 것들이 모두 commit에 의해 만들어진 결과 값이다!

흔히 숫자와 영문이 조합되어 있는 Hash라는 암호화된 값으로 기록되고, 우리가 commit을 수행하면 이것보다 좀 더 긴 형태의 값이 출력되는데 보통 앞자리 5개를 축약해서 표현하기도 한다.

즉, commit이라는 작업이 이루어지지 않으면 원격 저장소로 코드를 업로드할 수 없다.

snapshot

commit을 설명할 때, “원격 저장소로 업로드 전 마지막 저장 결과”라고 설명 했던 부분에 포커싱을 해서 설명하자면, 이 저장하는 방식을 스냅샷이라고 한다.

스냅샷은 특정 시점의 프로젝트 소스 코드의 특정 버전을 의미하고, commit은 코드가 바뀔 때마다 변경 사항을 기록하므로, 마치 그 시점의 사진을 촬영하듯이 저장하는 방식이다.

그래서 코드에 뭔가 문제가 생겨서, 특정 시점의 commit으로 돌아가고 싶을 때, 이 때 기록한 Hash 값을 기억해서 해당 커밋으로 돌아가는 것이 가능하다.

Head

Git을 기준으로 현재 여러분이 작업을 하고 있는 “위치”이다. commit이 변경될 때마다 가장 최신의 commit 값을 가리키고 있다.

조금 더 전문적으로는 포인터로 가장 최신의 커밋 이력을 보고 있다고도 표현하는데, 해당 부분은 브랜치라는 개념과 함께 맞물려서 “특정 브랜치의 최신 커밋”을 보고 있다고 표현할 수 잇다.

Branch

여러 개발자가 동시에 하나의 프로젝트에 대해 개발을 수행한다고 가정하겠다.

예를 들어, 쿠팡과 같은 전자 상거래 서비스를 개발한다면, 다음과 같을 수 있다.

회원 가입 & 로그인
장바구니 기능
결제하기

이런 식으로 개발 범위를 구분할 수 있고, 서로 맡은 업무에 따라서 업무 영역이 겹치지 않고, 서로 개발한 커밋들이 영향 주지 않도록 격리하는 행위가 필요하다.

이때, 사용하는 것을 Branch라고 한다. 서로의 업무 영역 분리 / 배포 단계 분리 또는 버그 수정 코드 작업 / 개발 단계 (dev/stage/prod) 구분 등의 목적으로 필수로 사용되는 기능이다.

Merge

Branch에서 서로 다른 브랜치에서 기능을 구현해서, 이제 하나의 애플리케이션으로 배포하도록 코드를 합치는 것을 이야기 한다.

코드를 합치는 과정에서 발생하는 여러 가지 문제를 추적할 수 있다.

기본 명령어 더 살펴보기

git --help

git log

git lens라는 VS Code 확장 기능은 이 git logs에서 제공되는 정보를 기반으로 사용되고 있다!

일반적으로, log라는 옵션을 입력하면 위와 같이 현재 사용하고 있는 브랜치에 대한 전체 커밋이 조회가 된다.

좀 더 우리가 원하는 형태로 커밋을 조회하는 것도 가능하다.

예를 들어, 특정 커밋를 기준으로 누가/언제 커밋했는지, 커밋한 내용이 어떻게되는지 조회하는 것도 가능하다!

리눅스?

Git Bash라는 도구는 리눅스 명령어를 윈도우에서 쉽게 사용할 수 있게 구성한 입력 화면으로, 우리가 앞으로 개발하고 관리하는 거의 대부분의 모든 환경은 “리눅스”라는 운영체제에서 동작한다.

리눅스는 컴퓨터를 움직이게 하는 기본 소프트웨어로, 우리가 계속해서 Git을 설치하면서 봤던 Git Bash(윈도우), 터미널(MacOS)가 이러한 리눅스 기반 작업들을 지원할 수 있게 도와주고 있다.

개발할 때 왜 리눅스를 사용하는가?

매우 한정적인 특수한 환경에서 윈도우나 맥OS를 활용한 배포하는 작업이 물론 가능하지만 이건 보편적인 케이스는 아니고 상업용 환경에서의 거의 대부분의 배포는 리눅스 기반으로 배포가 이뤄진다.

이에 따라 많은 개발자들이 개발하는 환경을 리눅스 기반으로 맞춰놓는 것이 소통하기도 편하고, 현대의 개발 및 배포 환경이 전부라고 해도 무방할 정도로 리눅스를 사용하기 때문에 빠른 배포 환경 통합을 위해 개발자들은 리눅스를 필수로 학습해야 한다.

리눅스 개발은 현재 진행형으로 여전히 새로운 버전이 꾸준히 출시되고 있다.

사실 리눅스 개발은 현재 진행형으로 여전히 새로운 버전이 꾸준히 출시되고 있다!

리눅스 토발즈라는 현대의 천재 엔지니어가 첫 삽을 뜬 이래로, 리눅스는 현재 별도의 재단이 만들어지고 전세계의 많은 개발자들이 함께 오픈소스로 지속적인 발전에 기여하고 있다.

유닉스?

유닉스는 1969년에 벨 연구소에서 개발된 운영체제로, 간결하고 효율적인 설계 덕분에 많은 시스템의 기반이 되었습니다. 리눅스는 유닉스의 철학과 설계를 계승한 오픈소스 운영체제이다.

커널?

운영체제의 핵심 부분으로, 하드웨어-소프트웨어를 연결하는 역할을 하며, 우리가 컴퓨터 부품을 살 때 찾는 CPU, 메모리, 디스크 등의 자원 관리를 한다.

또한 사용자와 하드웨어 간의 중재자 역할을 하여 프로그램이 안정적이고 효율적으로 실행되도록 돕는다.

파일과 디렉토리를 관리하기 위해 필요한 명령어 학습하기 (ls, cd, pwd, mkdir, touch, rm, mv, cp 등)

ls

list segment의 준말로, 현재 폴더에 있는 파일과 폴더 목록을 보여준다.

정말 많이 사용하는 커맨드로, 여기에 몇 가지 옵션을 추가하면 각 파일/디렉토리에 존재하는 권한 등을 함께 파악할 수 있다.

보통 -alt라는 옵션을 함께 줘서 실행하기도 한다.

-a 옵션: 숨김 처리된 파일이나 디렉토리까지 출력

-l 옵션: 파일이나 디렉토리의 이름과 속성정보까지 같이 출력

-t 옵션: 수정 또는 생성된 시간 순으로 정렬하여 출력

앞으로 개발하면서 수 많은 파일들을 생성하고, 편집하는 파일 작업들이 분명히 존재하는데 최소 이 옵션들을 활용해야만 어떤 파일들이 언제 생성되었고, 누가 생성했는지 등을 리눅스에서 파악할 수 있다.

ls -alt

cd

change directory의 약자로, 우리가 작업할 디렉토리 (폴더)로 이동할 때 사용하는 명령어이다.

아무런 이동 경로 없이 cd만 입력하면, 컴퓨터에 기본 값으로 설정해 둔 home 경로로 이동하게 된다.

cd <사용자가 이동할 경로>

pwd

print working directory"의 준말로 현재 내가 위치한 "폴더(디렉토리)"를 보여준다.

주로 현재 터미널 상에 위치한 디렉토리의 절대 경로를 파악할 때 사용한다.

pwd

mkdir

make directory의 약자로, 우리가 특정 프로젝트 경로를 새롭게 만들거나 새 카테고리로 파일이나 데이터를 저장할 폴더를 구성할 수 있다.

mkdir <생성할 디렉토리 이름>

touch

파일을 생성할 때 사용하는 리눅스 명령어로, 보통 touch 커맨드 뒤에 파일 이름을 작성해서 생성할 수 있다.

touch <생성할 파일 이름>

rm

remove의 약자로 파일 또는 디렉토리를 삭제하는 명령어로 쉽게 말해 화면상에 삭제하기와 동일한 기능이다.

단, 주의할 점은 화면상 삭제는 휴지통으로 이동하지만, rm으로 삭제한 것은 복구되지 않는다.

그래서 매우 조심해야 하며 삭제할 때도 파인 단위로 하나만 삭제를 해야 한다!

rm dummy.txt

mv

move의 약자로 파일이나 디렉토리를 다른 환경으로 이전시킬 때 사용하는 커맨드이다.

우리가 컴퓨터 화면 상에서 파일을 이동하는 작업과 동일하다.

cd .. 수행은 상위 디렉토리로 이동하겠다는 뜻이다.

mv <이동할 파일 이름> <이동할 파일 경로>

cp

copy의 약자로 파일이나 디렉토리를 다른 곳으로 복제할 때 사용하는 커맨드이다.

종종 사용하는 예시로는 production 파일의 환경을 다른 개발 환경으로 복제해서 사용할 때 사용하기도 하고, 개발 작업을 다른 곳에서 수행하다가 production 등 환경으로 그대로 옮겨 줄 때 쓰기도한다.

cp <복사할 파일 이름> <복사할 파일 위치>

파일 내용 확인 명령어 학습하기 (cat, less, head, tail, nano, vim)

cat

concatenate라는 단어의 약자입니다. 특정 파일에 대해 기록된 텍스트를 확인할 목적으로 사용하는 리눅스 명령어이다.

파일에 쓰여진 내용을 편집 없이 읽고만 싶을 때 유용하게 사용할 수 있다!

grep 이라는 커맨드를 cat 과 함께 사용하면 무척 유용하게 찾고 싶은 키워드 검색이 가능하다.

cat <텍스트가 입력되어 있는 파일 이름>

less

리눅스에서 파일 내용을 확인하는 명령어들 중에 하나로, 파일을 읽어 화면에 출력하는 명령어이다.

한 번에 보여지는 만큼만 읽어서 출력하기 때문에 대용량의 파일을 열어 볼 때 빠르게 읽을 수 있다는 장점을 갖고 있다.

less <텍스트가 입력되어 있는 파일 이름>

head

head 명령어는 텍스트로된 파일의 앞부분을 지정한 만큼 출력하는 명령어로 읽고자 하는 파일의 텍스트가 너무 많거나 앞부분만 빠르게 읽어서 어떤 내용이 있는지 확인할 때 사용한다.

head <텍스트가 입력되어 있는 파일 이름>

물론, head로 읽을 수 있는 줄 수를 지정할 수도 있다.

head -n 2 <텍스트가 입력되어 있는 파일 이름>

tail

head와는 반대로 텍스트 파일의 끝 내용을 읽을 때 사용합니다.

tail도 head처럼 읽을 수 있는 줄 수를 지정할 수 있다.

tail <텍스트가 입력되어 있는 파일 이름>
tail -n 2 <텍스트가 입력되어 있는 파일 이름>

nano

nano는 리눅스에서 가장 많이 사용하고 있는 텍스트 편집 기중 하나로, 리눅스를 사용하게 되면 꼭 마주치게 되는 편집기이다.

git bash를 사용하면 기본적으로 nano, vim이 설치되어 함께 사용 가능하여, 별도로 설치는 필요 없지만, macOS의 경우 2개의 편집기가 설치 되어 있지 않을 수 있다.

아래의 명령을 사용해 nano vim을 설치해주자.

brew install nano vim

텍스트가 입력된 파일 하나를 열 수 있다.

nano <텍스트가 입력되어 있는 파일 이름>

windows 기준으로 빠져나오고자 하면 ctrl+x를 입력하면 된다.mac 기준으로는 control + x를 입력하면 된다.

vim

nano 보다 조금 더 개선된 사용성으로 인해, 최근에 올라오는 리눅스와 관련한 게시글들을 찾아보면 vim을 사용해서 텍스트 편집기를 조작하는 글들을 좀 더 쉽게 찾아볼 수 있다.

vim <텍스트가 입력되어 있는 파일 이름>

빠져나오고자 하면, esc 입력 후 ':q'를 입력해 엔터를 누르면 된다.

기타 유용한 명령어 (clear, history, echo, df, du, whoami)

clear

터미널 입력 화면을 한 번 정리할 때 사용하는 명령어이다.

clear

history

여태껏 우리가 터미널 환경에서 입력한 모든 커맨드들의 이력을 한 번에 조회할 수 있도록 보여주는 커맨드이다.

최대 1000개의 커맨드를 조회할 수 있다.

history

echo

터미널에 입력한 텍스트를 화면에 출력하거나, 변수를 표시할 때 사용한다.

$PATH 변수는 리눅스에 설정한 환경 변수를 의미하는 것으로 대표적으로 PATH 라고해서 터미널 내에 기본으로 코드 실행 등을 위해 지원하는 것들이 있다.

echo $PATH

df

disk free의 약자로, 현재 우리의 컴퓨터에서 사용하고 있는 디스크들의 경로와 경로별 사용하고 있는 용량에 대해 조회하는 커맨드이다.

보통 df만 입력하면 바이트 단위로 용량이 표기되어서 읽이 매우 어렵다.

그래서 사람이 이해하기 편하게 GB(기가 바이트) 단위로 읽을 수 있게 하나의 옵션을 추가해 사용할 수 있다.

주로 디스크 용량이 꽉찼다는 에러 등이 보일 때 확인하는 용도로 사용하는 명령어이다.

df -h

du

disk usage의 약자로 위에서 봤던 df 커맨드가 최상위 디렉토리에서 전체 용량을 볼 수 있다면, du는 개별 경로에서 사용 중인 용량에 대해 조회할 때 사용하는 커맨드이다.

똑같이 dh만 입력하면 바이트 단위로 용량이 표기되어서 읽이 매우 어렵다.

그래서 사람이 이해하기 편하게 GB(기가 바이트) 단위로 읽을 수 있게 하나의 옵션을 추가해 사용할 수 있다.

du -sh

whoami

현재 터미널을 사용하고 있는 유저 정보를 보여주는 명령어로, 사용 중인 노트북 또는 데스크탑에서 사용자가 많을 경우 누구의 계정 정보로 접속하고 있는지 등을 확인하는 용도로 사용된다.

whoami

깃과 자주 사용되는 조합의 명령어 (git rm, grep)

git rm

git rm은 Git 저장소에서 파일을 삭제할 때 사용하는 명령어로, 파일을 워킹 디렉토리(로컬)와 스테이징 영역(인덱스)에서 모두 제거한다.

해당 작업은 본격적으로 git commit에 대해 이해한 뒤 사용해야하므로, 현재는 git 추적 상황과 실제 파일 경로에서 함께 삭제된다는 정도로만 이해하면 될 것 같다!

즉, 우리가 리눅스 명령어 rm을 사용해 삭제를 시도하는 것과 git 상에서 추적하고 있는 파일을 함께 삭제하는 것을 의미한다.

grep

global/regular expression/print의 약자로 입력으로 전달된 파일의 내용에서 특정 문자열을 찾고자 할 때 사용하는 명령어이다.

grep "<찾으려는 문자열>" <문자열을 검색하고자하는 파일 이름>

grep과 다른 커맨드 조합하기

텍스트 탐색에 최적화가 되어 있는 grep 커맨드인만큼, 앞서 배웠던 cat, less, head, tail 커맨드 등을 조합해서 우리가 입력한 텍스트를 조회할 수 있다!

git log를 조회할 때 grep을 사용해서 필요한 로그들만 따로 뽑아 봐야하는 경우도 종종 있어 매우 많이 사용되는 명령어이다.

위 명령은 "최고"라는 값이 현재 조회하려는 파일 내에 있는지 없는지 필터링 후, 있다면 해당 키워드가 있는 줄을 전체 출력한다!

grep -i

대소문자 구분 없이 검색할 수 있다.

grep -E

정규표현식을 사용할 수 있으니, 여러 키워드를 한번에 검색하려면 참고하면 된다.

grep -E "fix|bug|issue" commits.txt

기술에 대한 소개

Git Reference 안내 페이지

https://git-scm.com/docs

Git - Reference

Reference

git-scm.com

(Windows) VS Code 터미널 Git Bash로 선택하기

VS Code를 선택한 화면 왼쪽 상단의 Terminal을 클릭합니다.

처음 터미널을 선택하면, cmd 또는 powershell이라는 명칭의 터미널이 선택되어 있는 것을 볼 수 있다.

아래 사진처럼 해당 창에서 아래 방향으로 표기 되어 있는 화살표를 클릭 후, Git bash로 변경해준다.

변경하면, VSC에서 Git bash 터미널을 사용할 수 있다.

mac에서는 기본으로 제공하는 터미널을 그대로 사용하면 된다.

기술 실습하기

git init

먼저 사용자가 사용할 디렉토리를 기준으로, git init이라는 명령을 반드시 수행해야 한다.

해당 명령어는 현재 사용자가 편집을 수행하는 디렉토리를 git이 추적하는 디렉토리로 만들겠다는 의미이다.

보통 개발에서는 이렇게 초기 개발 세팅하는 작업을 초기화한다고 하며, git에 대한 초기화이므로 저장소를 초기화한다고 표현합니다.

git add

해당 명령어는 원격 저장소로 코드를 업로드하는 커밋 작업을 기록할 때까지 변경 사항을 모아놓기 위해서 사용한다.

앞에 stage area를 언급하면서 git이 추적할 수 있도록 기록하는 행위가 있다고 했는데, 이 작업을 지원하는 것이 git add이다.

따라서 git commit을 명령을 하기 전에는 아무리 git add 명령어를 많이 실행해도 Git 저장소의 변경 이력에는 어떤 영향도 주지 않는다.

실제 git으로 기록한 작업이 “저장”되었다는 이력이 남는 것은 commit에 의해 이뤄지기 때문이다!

git add <git으로 추적을하고 싶은 파일이름> or .(현재 디렉토리에 있는 모든 파일)

이후에 git add를 통해 stage area로 잘 올라갔는지 확인하는 단계는 git status로 확인해볼 수 있다.

모든 파일을 다 commit으로 저장할 목적이라면 git add . 을 수행하면 된다.

git status

status 명령어를 사용하면 아래와 같이 입력 값이 쭉 표기되는 것을 볼 수 있다.

1. 현재 사용하고 있는 브랜치 및 커밋 상태 확인

먼저 우리가 git init을 수행하게 되면 현재 사용하고 있는 브랜치의 이름을 기본적으로 확인할 수 있다.

현재 상태는 별도 commit 작업이 없는 것을 알 수 있다. (No commits yet)

사용자가 별도로 지정하지 않는 한, 기본 브랜치는 main이라는 이름을 가지고 있다.

상대적으로 옛날에 생성된 브랜치들의 기본 값은 master로 되어 있다.

2. git에서 추적하고 있는 파일 상태 확인

git add로 추가한 "add-test.txt", "dummy.txt"는 현재 초록색으로 표기되고 있고, 추가하지 않은 파일은 영문 모를 숫자와 함께 붉은 색 글씨로 표기된 것을 볼 수 있다.

바로 이 부분이 stage area로 들어간 작업과 그렇지 않는 작업을 표기해주고 있는 부분이며, 앞서 이야기한 것처럼 stage area로 들어간 작업은 커밋으로 작업 결과를 이력과 함께 저장될 준비가 되어 있음 (chages to be committed)로 추적되고 있는 것을 볼 수 있다.

반대로 비교 파일은 git이 추적하고 있지 않으므로 (사용자 선택에 의해 추적) Untracked files라고 하는 항목으로 들어가 있고, 한국어가 표기 되지 않는 이유는 git에서 한국어 표기를 지원하는 UTF-8 옵션이 활성화 되어 있지 않아 발생하는 문제이다.

거의 모든 상황에서 개발할 때 다루는 파일들의 이름은 한국어가 아닌 영문으로 사용하기 때문에 그냥 넘어가면 된다.

3. VS Code Git Graph에서 교차 확인하기

VS Code 왼편 사이드 메뉴에서 동그라미 3개가 표기되어 있는 아이콘을 클릭하면, 현재 사용자가 작업하고 있는 경로에서 stage area로 올라온 작업들을 구분해서 볼 수 있다.

4. (참고) git status 명령어 옵션

참고로 git status에도 명령어 옵션이 add 때보다 더 많아서, 여기서는 <options>라고 표기 되어 있다.

git status [<options>] [--] [<pathspec>…]

5. status 좀 더 짧게 보기, short 옵션

하나씩 자세히 봤던 옵션 중 stage area 유무만 체크하기 위해 short 옵션만 추가해서 확인하는 것도 가능하다.

git status --short

기타 다양한 옵션들이 더 있지만, 일반적으로 stage area 에 관한 정보만 확인하면 status는 주어진 역할을 다 수행한 것이기 때문에 여기서 추가로 더 다른 옵션을 알아볼 필요는 없다.

git commit

말 그대로 변경 작업에 대한 이력을 “저장”하는 작업이기 때문에 해당 작업을 수행한 작업자를 변경하거나, 이미 커밋되어 있던 작업에 대해서 수정하는 작업 등을 진행하는 것도 지원한다.

1. commit 메시지 남기기

git commit

먼저 별다른 작업 없이, 아래와 같이 명령어를 입력하면 우리가 add를 할 때 확인 했던 메세지 값이 나오는 것을 볼 수 있다.

이 때 위 내용을 그대로 입력하지는 않고, 커밋할 때 사용하는 메세지 가이드라인이 존재한다.

<제목(50자 이내)>

<본문(선택 사항)>
- 변경한 이유, 변경한 내용, 주요 변경점
- 한 줄에 72자 이내로 작성

<꼬리말(선택 사항)>
- 이슈 트래커 ID
- BREAKING CHANGE: 주요 변경사항 설명

메시지를 입력하고 종료할 때는 우리가 vim 파일 에디터에서 입력 값을 입력 후 종료할 때처럼 :wq를 입력해서 종료하면 된다.

생성이 마무리되면 create mode 라는 문구와 함께 커밋이 정상적으로 반영된 것을 확인할 수 있다.

2. commit message 간략하게 남기기

위와 같이 변경사항이 많은 상황에서는 git commit 만 사용하지만, 여기서 간단한 수정을 반영하는 상황에서는 -m 옵션을 사용할 수 있다.

add -> commit 과정을 거친다.

git commit -m "남기고 싶은 메세지"

3. 커밋된 내용 VS Code로 확인해보기

커밋이 정상적으로 반영되면 add를 수행했던 것과 마찬가지로 git graph에 들어가서 확인해보면 아래와 같이 우리가 작성한 커밋 메세지가 보인다.

각 메세지를 클릭하면 우리가 add에서 추가한 파일 단위로 무엇이 변경되었는지 확인하는 것이 가능하다.

git diff

1. 우리가 이미 VS Code로 봤던 변경 사항 비교

git graph에서 커밋 내역을 확인하면서 우리는 어렴풋하게 커밋이 반영되기 전 파일 상태와 커밋이 반영된 후의 파일 상태를 확인할 수 있었다.

이 작업도 git diff 의 일환이고, 이 상황에서는 직전 원본 값과 가장 최신의 변경 사항을 볼 수 있는 것을 확인할 수 있다!

2. 커밋 메세지로 비교

아래 명령은 최신 커밋이 이전 커밋 대비 무엇이 추가되었거나, 삭제되었는지를 볼 수 있다.

git diff 비교할 커밋 1 비교할 커밋 2

git log

1. 로그 읽어보기

먼저 우리가 커밋 메세지로 기록한 문구들이 표기되는 것을 모두 볼 수 있고, 작성자/작성 일자/작성 시간이 언제인지 확인할 수 있다.

일반적으로 개발자의 생산성이나 업무 역량을 볼 때 이러한 작업 단위와 커밋 시간을 기준으로 측정이 가능하고, 재택을 할 때 코드를 언제 커밋해서 마무리했는지 등을 확인하는 것이 가능하다.

git log

2. 로그 예쁘게 읽어보기

로그를 좀 더 가독성 있게 필요한 정보만 뽑아서 읽으려면, pretty 옵션을 사용하는 것이다.

이걸 사용해서 커밋 해시 값, 작성자, 언제 작성했는지 정보만 뽑아서 확인할 수 있다.

git log --pretty=format:"%h - %an, %ar : %s"

git log --oneline은 현재 저장소의 모든 커밋을 한 줄씩 요약해 보여준다.

물론 아래와 같은 명령도 가능하다.

git log --pretty=oneline > pretty_logs.txt

728x90

저작자표시 비영리 변경금지 (새창열림)