[Git/GitHub Session] Git 시작하기

 

---

1. Git을 써야하는 이유
2. Git 이란?
3. Git, GitHub 시작하기
4. Git, GitHub 명령어 모음
5. Github 완벽 정복

---

 

1. Git을 써야하는 이유

평상 시 우리가 문서를 작성하는 방법

보고서.hwp
보고서_최종.hwp
보고서_최종111.hwp
final.hwp
진짜최종_보고서.hwp

 과제로 제출할 보고서를 쓰거나, PPT를 만들 때 바탕화면이 위와 같은 보고서 버전 파일들로 너저분했던 경험이 한 번 쯤 있을 것입니다. 위와 같이 첫 번째로 작성한 보고서부터 최종적으로 제출할 보고서까지의 변화들을 버전으로 관리할 수 있도록 여러 기능을 제공하는 게 바로 git 분산 버전 시스템이 맡은 역할입니다.

 

---

2. Git 이란?

Git의 구조

 'Working Directory'란 내 컴퓨터에서 자유롭게 코드를 추가하고 수정할 수 있는 폴더를 의미합니다. Working Directory에서 개발을 한 다음, 그 중에서 새 버전으로 배포하고 싶은 코드들을 골라 'Staging Area'로 스테이징합니다. 마지막으로 스테이징까지 모두 완료되면 Staging Area에 올라간 코드들을 모아 'Commit'이라는 하나의 덩어리로 묶은 뒤에 git directory의 새 버전으로 배포합니다.

 

GitHub?

 Git으로 만든 버전들을 저장하고, 관리하기 위해서 Git Server 컴퓨터가 필요합니다. Git Server 서비스로는 GitHub, GitLab, Git KraKen 등이 있으며 그 중에서도 GitHub가 가장 대중적으로 사용되고 있습니다.

 

---

 

3. Git, GitHub 시작하기

GitHub에 내 코드를 올려보자

1. 내 컴퓨터에 프로젝트 폴더로 사용할 빈 폴더를 생성
2. 만든 빈 폴더를 Git 폴더로 초기화( git init )
3. 폴더 안에서 자유롭게 코딩
4. 변경한 파일 중 GitHub에 올리고 싶은 파일만 선택( git add )
5. 선택한 파일들을 한 덩어리(commit)로 만들고 설명 추가( git commit -m “설명” )
6. GitHub 사이트에서 코드를 올릴 프로젝트 저장소 만들기
7. 내 컴퓨터의 Git 폴더에 프로젝트 저장소의 주소 연결( git remote add )
8. 아까 만들었던 commit을 GitHub의 프로젝트 저장소에 올리기( git push )

 

---

 

4. Git, GitHub 명령어 모음

$ git status

 git에서 파일이 가질 수 있는 상태는 총 4가지가 존재합니다. 새로 생성된 파일은 'untracked' 상태가 되고, 이미 존재하던 파일이 수정된 경우에는 'modified' 상태가 됩니다. 이 두 가지 상태의 파일들을 Staging Area에 올리면 'staged' 상태가 됩니다. 이 3가지 상태는 'git status' 라는 명령어로 확인할 수 있습니다. 수정 내역을 커밋한 다음에 git 저장소에 푸시하면 따로 수정하거나, 삭제되지 않는 한 변경 내역이 없는 파일들은 'unmodified' 상태를 가지며, 'unmodified' 상태는 'git status' 명령어로 확인할 수 없습니다.

 

$ git diff

  git diff 명령어는 현재 내 Wokring Directory와 Staging Area에 올라간 코드를 비교해줍니다. 바뀌기 전의 내용 앞에 '-'가 붙고, 수정한 내용의 앞에 '+'가 붙어있는 것을 확인할 수 있습니다.

 

$ git log

 git log 명령어는 현재까지의 커밋 내역을 리스트로 출력합니다.

 

$ git branch

git branch 전략

 여러 명의 개발자가 협업할 때에는 하나의 repository를 보다 효과적으로 활용하기 위해 여러 개의 브랜치로 나눠 개발을 진행합니다. 이 때 브랜치를 더 전략적으로 사용하는 방법을 'git branch 전략'이라고 말합니다. 가장 대중적으로 사용하는 전략인 'git flow'는 아래와 같이 5가지 종류의 브랜치로 나눠 일을 분업합니다.

• master : 서버에 제품으로 출시되는 브랜치
• develop : 다음에 출시할 버전을 개발하는 브랜치
• feature : 각 기능을 개발하는 브랜치 -> develop
• release : 다음 버전 출시를 준비하는 브랜치
• hotfix : master 브랜치의 버그를 수정하는 브랜치

 

 이 때 사용되는 브랜치는 아래의 코드를 통해서 생성하고 변경할 수 있습니다.

# 브랜치 생성하기
$ git branch [브랜치명]

# 브랜치 리스트 확인하기
$ git branch

# 작업 중인 브랜치 변경하기
$ git checkout [브랜치명]

# 브랜치 생성과 변경을 동시에!
$ git checkout -b [브랜치명]

 

$ git merge

 feature/1 브랜치에 있는 '회원가입' 기능이 완성되었다고 가정했을 때, 완성된 '회원가입' 기능을 feature/1 브랜치에서 develop 브랜치로 합쳐야 합니다. 이렇게 다른 브랜치의 코드를 가져와 현재 브랜치의 코드와 합쳐야 할 때 git merge 명령어를 사용합니다.

# 현재 작업 중인 브랜치를 develop 브랜치로 변경한다.
$ git checkout develop

# feature/1에 있는 '회원가입' 기능을 가져온다.
$ git merge feature/1

 

---

5. GitHub 완벽 정복

Pull Request

 여러 개발자들과 협업하고 있을 때, 팀원들에게 언급 없이 merge를 하면 알 수 없는 오류가 앞으로 출시할 버전에 함께 합쳐지는 문제가 발생할 수 있습니다. GitHub에는 이 문제를 방지하기 위해서 팀원들에게 merge해도 되는지 허락을 구하고, 코드를 리뷰할 수 있는 Pull Request 기능이 존재합니다. 'Pull Request'란 각자의 브랜치에서 변경한 내용을 머지하기 이전에 협업하는 사람들에게 변경 내역을 알려주고, 허락을 받는 과정을 말합니다.