[Git] Git의 기초 배우기

 

이전 글에서 많이 사용되는 linux 명령어들에 대해 공부했으니, 이제 본격적으로 git이 무엇인지, 어떻게 사용하는건지 정리해 보고자 한다.

 

Git

Git은 형상 관리 도구 중 하나로, 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템이다.

 

Characteristics of git

• 빠른속도, 단순한 구조
• 분산형 저장소 지원
• 비선형적 개발(수천개의 브랜치) 가능

 

Pros of git

• 소스코드 주고받기 없이 동시작업이 가능해져 생산성이 증가
• 수정내용은 commit 단위로 관리, 배포 뿐 아니라 원하는 시점으로 Checkout 가능
• 새로운 기능 추가는 Branch로 개발하여 편안한 실험이 가능하며, 성공적으로 개발이 완료되면 Merge하여 반영
• 인터넷이 연결되지 않아도 개발할 수 있음

 

Git objects

• Blob: 파일 하나의 내용에 대한 정보
• Tree: Blob이나 subtree의 메타데이터(디렉토리 위치, 속성, 이름 등)
• Commit: 커밋 순간의 스냅샷

여기서 Blob은 카메라 렌즈에 담긴 모습, Tree는 사진을 찍었을때 나타나는(위치, 시간등) 메타데이터, Commit은 그 "사진"을 생각하면 이해하기 쉽다. 

 

 

Git process

git process flow and command

작업을 할 때 생기는 변경사항을 git add를 통해 staging area에 저장한다.

staging area에 있는 것들을 commit하면 메타데이터와 함께 local repo에 저장된다.

commit이 어느정도 쌓이면 push한다.

 

 

 

Github

깃허브(Github)는 분산 버전 관리 툴인 깃(Git)를 사용하는 프로젝트를 지원하는 웹호스팅 서비스이다.

 

 

첫 프로젝트 세팅

 

컴퓨터를 샀을 때, 계정을 변경했을 때는 git config설정을 해줘야 한다. (처음 한번만 해주면 된다)

$ git config --global user.name "당신의유저네임"
$ git config --global user.email "당신의메일주소"
$ git config --global core.editor "vim"
$ git config --global core.pager "cat"
$ git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --"

 

 

1. 원격 repo 생성

깃허브에서 원격 repo를 생성한다. 처음 생성할때 README, 라이센스를 등록해주는게 좋다. 

 

2. 로컬 repo에 clone

clone해줄 로컬repo를 선택해서 그곳으로 이동한다. (ex dev라는 디렉토리로 이동)

그 다음 clone을 해주면 그 로컬 repo안에 원격repo의 이름을 가진 디렉토리가 하나 생기는 것을 볼 수 있다. 

$ git clone {repo address}
$ git add .
$ git commit
$ git push

git init으로 세팅하는 방법이 있는데 기왕이면 clone으로 하는게 좋다. 

 

 

Commit

공부하면서 지금까지 commit을 잘못해왔다는 것을 깨달았다..

 

• commit은 동작 가능한 최소 단위로 자주 해야 한다.
• 해당 작업 단위에 수행된 모든 파일 변화가 해당 commit에 포함되어야 한다.
• 제목은 축약하여 쓰되, 40자 내의 구나 절이어야 하며 내용은 문장형으로 작성하여 추가설명 해야 한다.
• 제목과 내용을 모두 적는 것이 좋다. 
• 제목과 내용은 한 줄 띄워 분리해야 한다.
• 내용에는  이 commit의 구성과 의도를 충실히 작성해야 한다.
• 제목에 prefix를 잘 달아줘야 한다. prefix가 커밋을 카테고리화 시켜준다.
• Conventional Commits
  • eat: 기능 개발 관련
  • fix: 오류 개선 혹은 버그 패치
  • docs: 문서화 작업
  • test: test 관련
  • conf: 환경설정 관련
  • build: 빌드 관련
  • ci: Continuous Integration 관련
  • refactor: 리팩토링
  • BREAKING CHANGE : 중요한 변경

 

git commit -m 을 추천하지 않는다. 편하기 때문에 많이 사용하기도 하지만 git commit을 통해 창을 넘어가서 커밋 메시지를 작성하는 것을 권장한다. merge커밋인지 일반커밋인지 구분이 안되기 때문이다.

그리고 commit할때 내용에 브랜치 위치를 , on branch main 이렇게 표시하는 것이 좋다.

 

 

 

README.md

• 프로젝트와 Repository를 설명하는 책의 표지와 같은 문서
• 나와 동료, 이 repo의 사용자를 위한 문서

 

 

LICENSE

오픈소스 프로젝트에서 가장 중요한 License는 내가 만들 때에도, 배포할 때에도 가장 신경써
야 하는 일 중 하나입니다. 

가장 많이 사용되는 라이센스는 다음과 같습니다.

 

• MIT license - 오픈소스임을 증명하는 라이센스
• Apache license - 자유롭게 써도 되는데 자신의 소유임을 확실히하는(특허권이 포함됨) 라이센스
• GNU GPL - 의무사항이 존재한다. GPL 묻은 코드 한줄만 써도 내가 쓰고있던 전체코드 다 의무사항 따라야 한다.

 

.gitignore

.gitignore 는 git이 파일을 추적할 때, 어떤 파일이나 폴더 등을 추적하지 않도록 명시하기 위해 작성하며, 해당 문서에 작성된 리스트는 수정사항이 발생해도 git이 무시하게 된다. 특정 파일 확장자를 무시하거나 이름에 패턴이 존재하는 경우, 또는 특정 디렉토리 아래의 모든 파일을 무시할 수 있다.

대표적인 환경설정에 관련된 파일이다.

 

디렉토리안의 모든 파일을 표현하고 싶을때 [ 디렉토리이름/** ] 으로 작성한다.

 

gitignore.io

https://www.toptal.com/developers/gitignore/ 에서 내가 사용하는 언어, 프레임워크, os등을 입력하면 ,

자동으로 깃에 올라가지 않아도 되는 파일들을 뽑아내준다. 그를 복붙에서 사용하면 된다.

 

ex) 

java, Vim
Windows, linux, macOS - 올리는 이유는 각자 썸네일 파일이 생길 수 있기 때문
Intellij

 

새로운 원격 repo를 생성할때 ignore파일을 지정할 수 있지만, 언어로 한정되어있어 위 사이트에서 지정하는 것이 가장 좋다. 

 

Branch

: 분기점을 생성하여 독립적으로 코드를 변경할 수 있도록 도와주는 모델

 

branch를 사용하여 독립적으로 코드를 변경할 수 있다.

새로운 기능을 개발할 때 더 안전하게, 도전적으로 개발할 수 있게 하기 위해 branch를 사용한다.

 

자주 사용되는 명령어이다.

git branch                        : 브랜치 조회
git branch '브랜치 이름'           : 브랜치 생성 
git switch '브랜치 이름'           : 브랜치 이동
git merge '병합하고 싶은 브랜치'    : 브랜치 병합
git branch -D '브랜치 이름'        : 브랜치 삭제

 

브랜치를 만들때는 어떤일을 할지 이름으로 표현해야 한다.

 

그리고 예전에는 git checkout 으로 이동 했었던 것 같은데 요즘에는 switch를 통해 브랜치를 이동하도록 바뀌었다고 한다.

브랜치를 이동할 때에는 커밋을 하고 이동해야 하는데, 커밋을 하지 않고 이동했을 경우, 변경사항이 따라다닌다.

따라서 그 브랜치 위에서 했던 작업은 commit으로 마무리 지어놓고 이동해야 한다.

 

변경된 브랜치를 main브랜치로 병합하고 싶을 때 

git merge '변경된 브랜치'를 수행한다.

merge는 땡기는 것이다. 현재 브랜치에서 합치고 싶은 브랜치를 땡기는 것. (main브랜치에서 변경된 브랜치를 땡기는 것)

 

한번 merge가 된 브랜치는 그 브랜치에서 할 일은 다 했다고 생각하면 된다. 따라서 지워도 된다. 

안 지우면 헷갈리기 때문에 브랜치 구조가 완벽하게 파악되어있는 상태라면(브랜치 많은 회사에서는 잘못 삭제했다가 알돌아갈 수도 있다고 함) 삭제하면 된다. 

 

Merge confilct

if  branch1에서 작업을 하고, main 브랜치에서도 작업을 할때 (같은 줄을 작업) main에서의 변경사항을 어떻게 처리할 것인가? 

 

branch1에서도 2번줄을 변경하고 main에서도 2번줄을 변경한다면 충돌이 발생한다.

이 때 main브랜치에서 git merge branch1을 하면 Merge Confilct가 일어나고 아래의 오류메시지가 뜬다.

Auto-merging menus.md
CONFLICT (content): Merge conflict in menus.md
Automatic merge failed; fix conflicts and then commit the result.

 

충돌이 발생한 화면                                                  충돌이 발생한 부분을 없애고, 필요없는 문자를 제거

깃에서 HEAD는 "최신"이라는 의미이다. (최신 커밋, 최신 브랜치) 여기서 HEAD는 main브랜치이다.

위와 같이 충돌을 수정하고 git status를 하면 아직 merge가 되지 않았다고 나온다. 이 상태에서 add, commit을 하면 된다.

 

이때 git commit을 하면 제목이 Merge~로 정해져 있다.

커밋 메시지 작성을 완료하면 갈등을 봉합한 merge commit이 생긴다. 

 

 

git push origin main 에서 main이란 브랜치 이름이고 origin은 원격저장소의 주소이다. 

 

 

branch를 공부하며 꼭 기억해야 할 것!!

1. 이름을 잘 짓자

2. merge를 했으면 지우자.