[TIL] Git & Github 사용법

오늘은 Git과 Github 사용법에 대해 학습했다.
이전에 Github을 사용해 본 적은 있지만, commit과 push만 사용하고 있었다.
Github을 통해 프로젝트 협업을 진행해야 하므로 이번 기회에 더 제대로 알아보자.

Git & Github 이란?

• Git : Distributed Version Controll System(분산 버전 관리 시스템)으로 파일들을 추적하는 방식이다.
• Github : 우리가 작업한 git 파일(git 변경사항)들을 올리는 일종의 저장소이다.

우선 https://git-scm.com/downloads 이 주소로 들어가 Git을 다운받아보자.

설치가 완료되었다면 터미널에 버전을 확인하는 명령어를 입력하여 잘 설치가 되었는지 확인해보자.

$ git -v

프로젝트를 저장할 폴더를 생성하고, git 저장소를 생성한다.

// 저장소 생성
$ git init

// 저장소 주소에 해당하는 github repository와 현재 내 컴퓨터의 git을 연결
$ git remote add origin <저장소 주소>

Git workflow(Git Area)는 기본적으로 3단계로 나눠져 있다.

1. Working Directory(Unstage Area)
   우리가 현재 작업하고 있는 폴더로 생성, 수정, 삭제한 파일들이 있는 디렉토리

2. Staging Area
   Index라고도 부르며 , 변경사항이 있는 파일들을 선택해 커밋할 수 있도록 지정하는 곳
   (버전을 만들기 위해 준비 중인 파일들의 스냅샷 데이터가 저장된 곳)

3. Git Directory(Local Repository)
   파일들이 커밋된 곳으로, 파일들의 변경사항에 대한 스냅샷을 가지고 있는 곳
   (Staging Area를 거쳐 만들어진 버전들이 저장된 곳)

// staging area에 추가
$ git add <파일명>
$ git add . 

// 커밋하기
$ git commit -m "커밋 메시지"

// github에 올리기
$ git push origin main

Branch

branch는 main(또는 master) branch의 마지막 커밋으로부터 다른 타임라인을 가지게 될 부분이다.
독립적으로 어떤 작업을 진행하기 위한 개념으로, 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있다.

// 브랜치 생성
$ git branch <브랜치명>

// 브랜치로 이동
$ git checkout <브랜치명>

main과 동일하게 다음과 같은 명령어로 commit하고 push할 수 있다.

(브랜치명)$ git add .
(브랜치명)$ git commit -m "메세지"
(브랜치명)$ git push origin <브랜치명>

main에 반영된 코드를 받아오는 명령어는 다음과 같다. push 명령어가 에러가 날 때는 pull을 안하고 push를 하려고 하는 경우가 많다.

$ git pull origin main

Full request

원격 저장소의 특정 branch에 push 하고 나면 프로젝트 관리자에게 이 내용을 알리고 내가 수정한 코드를 검토 후 병합해달라고 요청하는 것을 말한다. 코드 충돌을 최소화할 수 있고 push 권한이 없는 프로젝트나 오픈 소스 프로젝트에 기여할 때 많이 사용한다.

Pull Request 과정

1. Fork
   • Upstream Repository(원본 리포지토리)를 자신의 저장소로 fork
2. Clone, Remote설정 (git clone 깃URL)
   • fork해온 리포지토리를 로컬 저장소로 Clone
3. Branch 생성 (git checkout -b 브랜치명)
   • 클론해온 프로젝트의 코드를 추가, 수정할 때 브랜치를 생성해서 작업할 수 있다.
4. 수정 작업 후 add, commit, push
   • 작업 완료 후 add, commit, push를 통해 해당 코드를 원격 저장소로 푸시
5. Pull Request 생성
   • 원본 리포지토리에서 New pull request를 통해 Pull Request 생성
6. Merge Pull Request
   • 해당 리포지토리의 관리자는 코드의 변경 사항을 확인 후, Merge여부를 결정
7. Merge 이후 동기화 및 Fork 및 Branch 삭제
   • Merge가 완료되면 로컬에 작성한 코드와 원본의 코드를 병합하고 최신의 상태를 유지하게 위해 동기화

github으로 협업하는 방식이 아직 익숙치 않아서 어렵지만, 자주 사용해보며 익숙해지려고 노력해야겠다.