개발자 필수템 Git!

maketheworldwise·2021년 12월 14일

나의 Git 개선 기록 📝

목록 보기

1/7

이 글의 목적?

Git은 개발자라면 반드시 숙지해야할 필수 분산 버전 관리 시스템이다. Git은 내가 만든 버전만이 아니라 동료가 만든 버전으로 이동할 수 있고 동료와 내 버전을 비교해서 최신본으로 코드를 업데이트할 수 있도록 도움을 준다.

사실 Git은 예전부터 알고 있었지만 제대로 활용하지 못했다. 지금도 잘사용하고 있다고는 말은 못하지만 회사를 다니면서 점차 익숙해지고 있는 중이다. 이전에 Git에 대해 포스팅을 해본적은 있으나, 조금은 성장한 지금의 내가 나만의 방식으로 글을 작성할 수 있을 것 같아서 다시 한번 정리해보고자 한다.

(개발자라면 당연히 알고 있는 지식이라니까 Git이 무엇인지는 생략하기로 하자 🤫)

Git 작업 영역?

우선, Git에는 실제로 작업하는 공간(Working Directory), git add 를 한 파일들이 존재하는 공간(Staging Area), 변경 이력들이 저장되어있는 공간(Repository) 3가지 영역으로 분리된다.

Git은 이 영역들을 거쳐가면서 동작한다. 먼저 Working Directory에서 작업을 한 뒤, 작업한 파일을 Staging Area에 올리고 Staging Area에 있는 파일들을 Repository에 저장을 한다.

(👉 Working Directory > git add > Staging Area > git commit > Repository)

출처 : https://devlog-wjdrbs96.tistory.com/236

Git 상태?

git status 명령어를 적용하게 되면 Repository에서 각 파일들의 상태를 확인할 수 있다. 그리고 각 파일의 상태는 "untracked, tracked (unmodified, modified, staged)" 로 나뉜다.

untracked: Git에 의해 그 변동사항이 전혀 추적되고 있지 않은 상태
tracked: Git에 의해 그 변동사항이 추적되고 있는 상태
unmodified: 현재 파일의 내용이 최신 커밋의 모습과 비교했을 때 전혀 바뀐게 없는 상태
modified: 최신 커밋의 모습과 비교했을 때 조금이라도 바뀐 내용이 있는 상태
staged: 파일 내용이 수정되고 나서 Staging Area에 올라와 있는 상태

Git 명령어?

참 친절하게도 Git에 Repository를 만들게 되면 어떤 명령어를 적용해야할지 알려준다.

add, commit, push, pull 정도만 사용해도 큰 문제 없지만, 협업하면서 사용할 법한 유용한 명령어들도 숙지해두는 편이 좋기에 한번 나열해보자. 😀

# 초기화
$ git init

# 현재 사용자의 아이디 설정
$ git config user.name '아이디' 

# 현재 사용자의 이메일 주소 설정
$ git config user.email '이메일'

# 현재 인식하고 있는 프로젝트 관련 내용
$ git status

# 현재 작업 내용을 스택 영역에 저장
$ git stash

# 스택 영역에 저장된 가장 최근의 작업 내용을 Working Directory에 적용
$ git stash apply 커밋_아이디

# 스택 영역에 저장된 가장 최근의 작업 내용을 스택에서 삭제
$ git stash drop 커밋_아이디

# 스택 영역에 저장된 가장 최근의 작업 내용을 Working Directory에 적용하면서 스택에 삭제
$ git stash pop 커밋_아이디

# 수정 사항이 있는 파일을 Stage Area에 반영
$ git add 파일명

# Staging Area에서 파일 제거 (변경된 모습은 그대로 Working Directory에 남음)
$ git reset 파일명

# Staging Area에 있는 내용에 메시지 남기기
$ git commit -m "커밋_메시지"

# 'origin' 이름으로 원격 Repository 등록
$ git remote add origin 깃헙_주소

# 처음에 반영할 때 로컬 Repository와 연결과 동시에 원격 Repository에 반영
$ git push -u origin master

# 원격 Repository에 반영
$ git push

# 원격 Repository의 내용을 로컬 Repository로 가져오기 (merge x)
$ git fetch

# 특정 파일의 내용 한줄 한줄이 어떤 커밋에 의해 생긴 것인지 출력
$ git blame 파일명

# 특정 커밋에서 이루어진 작업을 되돌리는 커밋을 새로 생성
$ git revert 커밋_아이디

# 브랜치 생성
$ git branch 브랜치명

# 브랜치 이동
$ git checkout 브랜치명

# 브랜치 merge (베이스가 될 브랜치로 이동 후 적용)
$ git merge 브랜치명

Git 포크는 언제 사용할까?

Git 포크는 오픈소스에 기여를 하기 위해, 원본 저장소 주인에게 기여자를 등록해달라고 부탁하지 않고도 저장소를 그대로 복제해와서 자유롭게 사용하는 방법으로 많이 사용한다. 원본 저장소를 복제한 뒤에는 자유롭게 commit과 push를 하고 복제한 저장소의 브랜치를 merge해달라고 요청하는 방법으로 기여를 한다.

브랜치와 포크 모두 코드를 협업하기 위해 분기점을 나누는 방식이지만, 특성이 다르기에 프로젝트에 맞게 잘 사용해야 한다.

기능	특징	장점	단점
브랜치	하나의 원본 저장소에서 분기를 나눔	하나의 원본 저장소에서 코드 커밋 이력을 편하게 확인할 수 있음	다수의 사용자가 다수의 브랜치를 만들 경우 관리하기가 힘듬
포크	여러 원격 저장소를 만들어 분기를 나눔	원본 저장소에 영향을 미치지 않으므로 마음껏 코드를 수정할 수 있음	원본 저장소의 이력을 보려면 따로 주소를 추가해주어야 함

Git Pull Request(PR)은 뭘까?

Git Pull Request는 포크한 저장소에서 기능 개발이 완료되면 원본 저장소에 merge할 때, 코드를 올릴 권한이 없을 경우 사용한다. merge하고 싶은 두 브랜치를 선택하고 어떤 변경을 했는지 제목과 내용을 작성한 뒤 단일 저장소나 포크한 저장소에 전달한다.

(💁🏻 오픈소스에 PR을 보낼 경우에는 기여 안내문서를 반드시 참고해야한다!)

주로 코드를 함께 작성하는 팀원이 있을 때, 최대한 직접 merge하는 것을 피하고 모든 merge를 PR을 통해서 한다. 그렇게 할 경우 다른 팀원이 내 PR을 보고 코드를 리뷰할 수 있고, 다른 팀원의 PR에 댓글(Comment)을 달거나 merge를 승인(Approve) 혹은 수정(Request changes)할 수 있도록 한다.

Git의 3가지 Merge 버튼은 뭘까?

GitHub에서 merge 할 때, "Merge Commit, Squash Merging, Rebase Merging" 3가지 버튼을 확인할 수 있다. 내가 생각한 이 3가지 기능은 단순히 커밋을 어떻게 처리를 할지에 대한 전략이라고 생각한다.

"Merge Commit" 은 말 그대로 하나의 브랜치와 다른 브랜치의 변경 이력 전체를 합치는 방법이다.

"Squash Merging" 은 커밋한 내용들을 합쳐서 새로운 커밋을 만든 뒤에 합쳐지는 방법이다. (일반적으로 feature 브랜치의 커밋 히스토리를 깔끔하게 만들기 위해 사용한다.)

"Rebase Merging" 은 모든 커밋들이 합쳐지지 않고 각각의 커밋이 합쳐지는 방법이다. (이 방법을 사용할 경우, 병합 기록이 남지 않기 때문에 마치 하나의 브랜치에서 작업한 것처럼 보여진다. 내가 많이 사용하는 방법이다. 😋)

출처 : https://velog.io/@injoon2019/Git-Merge-%EC%A2%85%EB%A5%98

Gitmoji는 뭘까?

일반적으로 commit 메시지를 작성할 때, 내용이 일정하지 않고 쉽게 확인할 수 없는 문제가 있었다. 하지만 Gitmoji가 등장하면서 commit 내용을 확인하기 수월해졌다고 하니, 잘만 사용하면 큰 도움이 될 수 있을 것 같다.

깃모지	코드	설명
🎨	art	파일/코드 구조 개선
🩹	adhesive_bandage	간단한 수정
⚡️	zap	성능 향상
🔥️	fire	코드나 파일 삭제
🐛️	bug	버그 해결
🚑️	ambulance	긴급 수정
✨️	sparkles	새로운 기능
📝️	memo	문서 추가/수정
💄️	lipstick	화면 UI 추가/수정
🎉️	tada	프로젝트 시작
✅️	white_check_mark	테스트 추가/수정
🔒️	lock	보안 이슈 수정
🔖️	bookmark	릴리즈/버전 태그
🚧	construction	작업 진행 중
💚	green_heart	CI 빌드 수정
⬇️	arrow_down	의존성 버전 다운
⬆️	arrow_up	의존성 버전 업
📌	pushpin	특정 버전 의존성 고정
👷	construction_worker	CI 빌드 시스템 추가/수정
📈	chart_with_upwards_trend	분석, 추적 코드 추가/수정
♻️	recycle	코드 리팩토링
➕	heavy_plus_sign	의존성 추가
➖	heavy_minus_sign	의존성 제거
🔧	wrench	설정 파일 추가/수정
🔨	hammer	개발 스크립트 추가/수정
🌐	globe_with_meridians	다국어 지원
💩	poop	안좋은 코드 추가
⏪	rewind	변경 내용 되돌리기
🔀	twisted_rightwards_arrows	브랜치 합병
👽	alien	외부 API 변화로 인한 수정
🚚	truck	리소스 이동/이름 변경
💥	boom	놀라운 기능 소개
🍱	bento	에셋 추가/수정
💡	bulb	주석 추가/수정
💬	speech_balloon	스트링 파일 추가/수정
🗃	card_file_box	데이버베이스 관련 수정
🔊	loud_sound	로그 추가/수정
🔇	mute	로그 삭제
📱	iphone	반응형 디자인
🙈	see_no_evil	gitignore 추가

Git의 달라진 인증 방식?

혹여나 저장소에 push를 하려할 때, 하단의 에러 메시지가 발생한다면 인증 방식을 변경해주어야 한다. 😡

"비밀번호 인증 지원은 2021년 8월 13일에 제거되었습니다. 개인 액세스 토큰을 사용하세요."

remote: support for password authentication was removed on august 13, 2021. please use a personal access token instead. remote: please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information. ...

인증 방식이 달라졌기 때문에 Github에서 개인 토큰을 발급받고 등록을 해주어야 정상적으로 push할 수 있기에 잊지말고 발급을 받도록 하자. 😅

Gist는 뭘까?

GitHub gist는 짧은 코드, 메모 등을 기록 또는 공유 목적으로 사용할 수 있는 무료 서비스라고 한다. 아무리 저장소에 코드를 저장하더라도 필요할 때 해당 코드를 찾아보는라 시간을 쏟는 경우가 있기 때문에 나에게 있어서는 단비💧 같은 서비스다. 많이 사용하는 코드나 주의 사항은 Gist를 활용하면 좋을 것 같다.