GitHub (특강)

 GitHub (특강)

목차

1. 버전 관리 시스템 (Version Control System)

2. Git의 3가지 영역

3. Git 브랜치

4. GitHub 시작하기

5. GitHub 협업하기

---

1.  버전 관리 시스템 (Version Control System)

 

 1.1 버전이란?

1. 이전과 다른 ‘변화’를 구분하는 표시 방법
2. 수정이 끝난 상태를 가르킴

 1.2 버전 관리

버전을 관리하는 것 → 동일한 파일에 대한 여러 버전을 관리하는 것

즉 ‘소스코드를 관리’

 

 1.3 버전 관리의 필요성

개발 중에는 많은 기능(요구사항)이 추가/변경되고, 이에 따라 수 많은 코드가 변경됨

 

 1.4 버전 관리 시스템

→ 문선나 소스코드, 콘텐츠의 변경 내용을 관리하고 추적하는 SW

 

1. 버전 관리 시스템에서 제공하는 기능

• 변경점 관리
• 버전 관리
• 백업 및 복구
• 협업

2. 버전 관리 시스템의 종류

• Git은 분산 VCS
• 파일들을 저장하는 서버 존재
• 프로젝트 전체를 받아 수정 후 변경 내용을 서버에 업로드
• 작업 컴퓨터와 서버 둘 다 버전 관리를 함

 1.5 Git으로 할 수 있는 것

 

버전 관리

• 특정 파일을 수정할 때마다 변경내용을 구체적으로 기록하는 버전 관리
• 네트워크나 인터넷이 연결되어 있지 않은 상태에서도 로컬 컴퓨터의 소스 코드만으로 버전을 관리

백업

• 버전 관리하는 파일들을 원격저장소(온라인 저장소)에 복제(저장)을 할 수 있음 → GitHub

협업

• 온라인 저장소 서비스를 이용하면 프로그램 개발 참여자들과 관리 파일과 변경 내용을 공유하며 협업이 가능

 1.6 Git의 관리 흐름

 

 1.7 Git CLI, GUI

CLI

• 리눅스의 기본 명령어 사용
• 깃 명령어 사용
• 많은 개발자들이 CLI로 깃을 사용

 1.8 정리

• 버전이란 : 변경사 항을 구분하는 방법
• 버전관리 : 하나의 정보 또는 파일의 버전들을 관리하는 것, 소프트웨어 개발 관점에서는 소스코드를 관리하는 것
• 버전관리의 필요성 : 여러 상태의 파일들이 필요한 시점이 존재하고, 변경 내용의 자세한 정보가 필요
• 버전 관리 시스템 (Version Control System) : 문서나 소스 코드의 변경 내용을 관리하고 추적하는 소프트웨어로 버전 관리, 변경 점 관리, 협업 등의 기능을 제공
• Git : 최근 가장 많이 사용되는 버전 관리 시스템

---

2. Git을 이용한 버전 관리

 

 2.1 Git의 3가지 영역

작업 폴더, 작업 트리

• 사용자가 변경하는 실제 파일이 들어가는 폴더

스테이지(Stage, Index)

• 변경 사항을 관리할 파일들의 리스트, 버전으로 만들 파일이 대기하는 곳

변경 이력(History), 저장소(repository)

• 커밋 (Commit)이라 불리는 변경사항 묶음과 커밋들의 연결관계를 저장하는 곳
• 리포지토리 (repository)는 스테이지에서 대기하고 있던 파일들을 버전으로 만들어 저장

 

스테이지와 저장소는 눈에 보이지 않음

Git을 초기화했을 때 만들어지는 .git 디렉토리 안에 숨은 파일 형태로 존재하는 영역

Git에는 로컬 저장소에 커밋을 하기 전, 스테이지 영역(인덱스) 단계가 있음

 

 2.2 Git의 저장소 구조

 

 2.3 Git 버전 생성 과정

 

1. 저장소로 사용할 directory 생성

• $ mkdir html_project
• $ cd html_project

2. 생성한 directory에서 Git을 사용할 수 있도록 초기화

ex) root@root-Desktop MINGW64 ~/Documents/html_project $ git init

root@root-Desktop MINGW64 ~/Documents/html_project (main) ← 저장소 생성 됨

 

3. working directory에서 문서를 생성 또는 수정

• $ git status
• $ vim index.html
• $ ls –al
• $ git status

4. 생성 또는 수정한 파일 가운데 버전으로 만들고 싶은 파일을 스테이징 영역(stage)에 저장

• $ git add index.html
• $ git status

5. stage 에 있던 파일을 저장소로 commit 하면 버전이 생성됨

• git commit 을 사용해서 커밋 명령, git -m 은 커밋과 함께 저장할 메시지를 적고 실행
• $ git commit –m “index.html 파일 생성”
• $ git status
• 스테이징과 커밋 한꺼번에 처리하기→ git commit -am 명령 사용 $ git commit –am “<p> 태그 추가 스테이징과 커밋을 한번에 처리” $ git status

 2.4 변경 사항 확인

 

마지막 커밋 상태의 파일과 현재 수정한 파일이 어떻게 다른 지 확인

• $ git diff 명령 사용
• $ vim index.html
• $ git diff

현재 수정한 파일의 변경 내용을 삭제

• $ git restore {파일명} 명령 사용
• $ git status

 2.5 단계 별 파일 상태 확인

• tracked : 버전을 만든 후에 깃에서 변경 내역을 추적 중인 상태
• untracked : 한번도 버전을 만들지 않은 상태

1. index.html 파일 수정

2. index2.html 파일 생성

3. 상태 확인

     - $ git status

4. 수정한 index.html 파일과 새롭게 생성한 index2.html 파일 모두 git add 명령을 사용해서 스테이징

     - $ git add

     - $ git status

5. 커밋 로그에서 커밋된 파일까지 확인

     - $ git log --stat

 

---

• unmodified : 수정되지 않은 상태 (working tree is clean)
• modified : 작업 트리에서 수정한 후 아직 스테이지에 저장하지 않은 상태
• staged : 스테이지에 있고 아직 커밋하지 않은 상태

1. 워크 트리에 파일 리스트 확인 - $ ls -al
2. Git 상태 확인 - $ git status
3. index2.html 파일 수정
4. Git 상태 확인 - $ git status
5. 변경된 파일을 스테이지에 올림 - $ git add index2.html
6. Git 상태 확인 - $ git status
7. 스테이지에 있는 파일 커밋 - $ git commit –m “4번째 커밋”
8. Git 상태 확인 - $ git status

 2.6 작업 되돌리기

1. 작업 트리에서 수정한 파일 되돌리기 - $ git restore
   1. index.html 파일 수정
   2. Git 상태 확인 - $ git status
   3. index.html 파일 수정 취소 - $ git restore index.html
   4. index.html 파일 확인
2. 스테이징 되돌리기
   1. index.html 파일 수정
   2. index.html 파일 스테이지에 올림 - $ git add index.html
   3. git 상태 확인 - $ git status
   4. index.html 파일 수정 취소 - $ git restore —staged index.html
   5. git 상태 확인 - $ git status
3. 최신 커밋 되돌리기 - $ git reset HEAD^

• HEAD^는 현재 HEAD가 가리키는 브랜치의 최신 커밋을 가리킴
  1. index.html 파일 커밋 - $ git commit -am “5번째 커밋”
  2. Commit 상태 확인 - $ git log
  3. 최신 커밋을 이전 상태로 되돌리기 - $ git reset HEAD^
  4. Commit 상태 확인 - $ git log

1. 특정 커밋으로 되돌리기 - $ git reset 해시
   1. index3.html 파일 생성, 파일 커밋 - $ git commint -am “6번째 커밋”
   2. $ git commint -am “7번째 커밋”
   3. $ git commint -am “8번째 커밋”
   4. Commit 로그 확인 - $ git log
   5. “6번째커밋” 로그 메시지가 있는 커밋으로 리셋 - $ git reset --hard 복사한 커밋 해시
   6. Commit 로그 확인 - $ git log

 2.7 정리

• Git의 저장소 구조
  • 작업 폴더 (Working Directory), 스테이지 (Stage, Index), 저장소 (repository)
• Git 버전 생성 과정
  • 작업 폭더 생성 -> Git 초기화 -> 문서 생성/수정 -> 스테이지 영역에 저장 -> 커밋
• Commit 기록 확인 : $ git log
• 변경사항 확인 : $ git diff
• 단계별 파일 상태 확인 : tracked, untracked, unmodified, modified, staged
• 작업 되돌리기
  • 작업 트리에서 수정한 파일 되돌리기 : $ git restore
  • 스테이징 되돌리기 : $ git restore –staged
  • 최신 커밋 되돌리기 : $ git reset HEAD^
  • 특정 커밋으로 되돌리기 : $ git reset 해시

---

3. Git Branch

 

 3.1 Branch 란?

• 새로운 작업을 만드는 것
• 큰 나무 줄기에서 작은 줄기가 뻗어 나오는 것처럼 저장 공간 하나에서 가상의 또 다른 저장 공간을 만드는 것이라고 생각하면 쉽다
• 브랜치는 부분 프로젝트를 독립적으로 관리하는데 사용

 3.2 브랜치 기능

• Git으로 버전 관리를 시작하면 기본적으로 main 브랜치가 만들어짐
• 사용자가 커밋할 때마다 main 브랜치는 어떤 게 최신 커밋인지 정보를 가짐 → 브랜치는 커밋을 가리키는 포인터와 비슷함

 

 3.3 브랜치 실습

 

3.3.1 분기(branch)

main 브랜치에서 새 브랜치를 만드는 것

기존 파일은 main 브랜치에 그대로 유지하면서, 새 브랜치에서 기존 파일 내용을 수정하거나 새로운 기능을 추가할 수 있음.

 

3.3.2 병합(merge)

새 브랜치에서 원하는 작업을 다 끝냈다면 새 브랜치에 있던 파일을 원래 main 브랜치에 합치는 것 → 기본 파일은 main 브랜치에 그대로 둔 상태에서 새로운 브랜치를 분기한 후 수정이나 추가 작업을 하고 별 문제없이 완성되었다면, 새 브랜치의 내용을 main 브랜치와 병합

 

3.3.3 서로 다른 파일 병합

1. main 브랜치로 이동
2. “queen” 브랜치 생성 → 브랜치 변경
3. “queen” 브렌치에서 blog_queen.html 파일 생성 후 커밋
4. “queen” 브랜치 → “main” 브랜치로 변경
5. “queen” 브랜치에서 “queen” 브랜치 병합(merge)
6. commit log 확인

3.3.4 서로 다른 브랜치에서 한 문서의 다른 부분을 수정했을 때 병합하기

1. “main” 브랜치의 blog.html 파일과 “king” 브랜치의 blog.html 파일 비교
2. “king” 브랜치에서 blog.html 수정 commit
3. “main” 브랜치로 이동해서 “king” 브랜치 병합
   • main 브랜치의 수정 내용과 king 브랜치의 수정 내용이 자연스럽게 하나의 파일에 합쳐진 것을 볼 수 있음 이렇게 같은 문서로 서로 다른 위치를 수정했을 경우 자동으로 합쳐 주는 기능이 있어 Git은 더욱 강력한 도구가 됨
4. “main” 브랜치에서 blog.html 확인

3.3.5 서로 다른 브랜치에서 한 문서의 같은 부분을 수정했을 때 병합하기

1. main” 브랜치의 blog.html 의 <hearder> 태그 부분을 수정 하고 커밋
2. “king” 브랜치의 blog.html 의 <hearder> 태그 부분을 수정 하고 커밋
3. “main” 브랜치에서 “king” 브랜치 병합 → 경고 메시지가 나타남. 이 메시지는 work.txt를 자동 병합하는 동안 충돌이 발생했다는 뜻
4. 충돌이 생긴 문서는 자동으로 병합될 수 없으므로 사용자가 충돌 부분을 직접 해결한 후 커밋해야 함
5. 커밋 로그 확인

3.3.6 병합이 끝난 브랜치 삭제하기

1. 새롭게 생성했던 브랜치를 삭제하려면 main 브랜치에서 삭제 진행
2. 현재 브랜치가 main 브랜치가 아니라면 main 브랜치로 전환
3. 브랜치를 삭제할 때는 git branch 명령에 -d 옵션을 추가한 후 그 뒤에 삭제할 브랜치 이름 형식으로 작성
4. “queen” 브랜치를 삭제

---

4. GitHub 시작하기

 

 4.1 지역 저장소와 원격 저장소

• GitHub에서 버전을 관리할 때도 저장소를 만들어 사용
• 지역 저장소(local repository) : 사용자 컴퓨터에 있는 저장소
• 원격 저장소(remote repository) : GitHub에 있는 저장소
• 먼저 local repository를 만들어 작업한 후 그 내용을 remote repository로 올리고 변경 사항이 생길 때마다 remote repository에 반영

→ 지역 저장소에서 원격 저장소로 커밋을 등록하는 것을 ‘푸시(push)’

• 지역 저장소를 거치지 않고 원격 저장소에서 커밋 생성

→ 원격 저장소의 변경 사항을 지역 저장소로 내려 받는 것을 ‘풀(pull)’

• 지역 저장소와 원격 저장소를 항상 같게 유지하는 것 → ‘동기화(synchronize)’

 

 4.2 원격 저장소

• Git에서는 지역 저장소와 원격 저장소를 연결해서 버전 관리하는 파일을 백업
• 원격 저장소는 여러 로컬 저장소와 연결되어 ‘백업’과 ‘협업’과 같은 중요한 역할을 함

 4.3 Git의 개념

commit은 로컬 저장소에서 이루어 지고 Push라는 동작으로 원격 저장소에 반영됨(SVN의 차이점)

• 로컬 저장소에서 작업이 이루어져 매우 빠른 응답을 받을 수 있음
• Pull 또는 Fetch로 서버에서 변경된 내역을 받아 올 수 있음

 4.4 GitHub로 할 수 있는 일

 

원격 저장소에서 Git을 사용

• GitHub는 깃 사용을 위한 원격 저장소를 제공하는 서비스

→ 깃을 설치하지 않고도 온라인에서 깃의 버전 관리 기능을 사용할 수 있음

• 지역 저장소를 만들지 않아도 GitHub에 원격 저장소를 만들어 사용 가능
• 지역 저장소가 있다면 원격 저장소와 연결해서 사용

→ 동기화하면 지역 저장소를 인터넷에서 백업

 

자신의 개발 이력을 남길 수 있음

• GitHub에서 소스를 수정하고 커밋 → 사용자 초기 화면에 날짜별로 기록
• Github는 개발자가 자신의 개발 이력을 관리하기 좋은 플랫폼
• 다른 사람의 소스를 살펴볼 수 있고, 오픈 소스에 참여할 수도 있음

 4.5 설정 절차

 

1. 원격 저장소 생성하기

• Repository name : 저장소 이름 입력
• Descritption : 설명 입력(선택)
• Public, Priate : 공개 또는 개인저장소 선택 → [Create repository]
• Add a README file 체크
• Add .gitignore 체크

2. 로컬 저장소 생성하기

• 디렉토리에 폴더 및 파일 생성
• 생성한 디렉토리 확인 - $ ls
• 디렉토리로 이동 - $ cd 디렉토리 명
• Git 저장소 생성 - $ git init

3. 원격 저장소에 저장하기

• 저장소 등록 - $ git remote add origin : 복사한 원격 저장소의 주소
• Push : 로컬 저장소 내용을 원격 저장소로 보내기 : $ git push -u origin main
• Password 입력

4. 원격 저장소에 저장하기

• 새로운 파일 생성 및 원격 저장소에 저장하기

$ git add 파일명
$ git commit -m "메시지 내용"
$ git push -u origin main

• 새로운 문서가 저장된 것 확인

5. 원격 저장소 파일 가져오기

• 원격 저장소에서 직접 커밋

→ 파일 목록 위에 있는 [Add file]을 클릭한 후 [Create new file]을 선택

→ [Commit new file]을 클릭

• 파일 가져오기

$ git pull origin main

commit hash 오른쪽을 보면 (HEAD -> main) 외에 origin/main도 있음 원격 저장소의 최신 커밋이라는 뜻

---

 

5. GitHub 협업하기

 

 5.1 원격 저장소 복제하기

서로 다른 컴퓨터에서 원격 저장소 함께 사용

git clone

• GitHub에 만든 원격 저장소를 ‘git_home’이라는 지역 저장소로 복제
• 터미널 창에서 홈 디렉터리로 이동
  • $ git clone remote repository 주소 git_home
  • git_home이라는 디렉터리가 없다면 자동으로 디렉터리가 만들어짐
• 원격 저장소의 내용을 ‘git_office’ 디렉터리에도 복제
• 원격 저장소를 복제하면 지역 저장소와 원격 저장소가 자동으로 연결됨 git_home 디렉터리나 git_office 디렉터리에서 git remote -v 명령을 사용하면 원격 저장소에 연결된 것을 확인할 수 있음

 5.2 Home에 있는 작업 파일 올리기

• git_home 디렉터리로 이동한 후 새로운 커밋을 만듦
• txt 문서를 열고 간단한 내용을 추가, 스테이징, 커밋 - $ git push
• 커밋을 원격 저장소에 올림

 5.3 Office에서 내려 받아 작업

• 터미널 창에서 git_office 디렉터리로 이동 - $ git pull 원격 저장소에 새로 올라온 커밋을 가져옴
• 이번에는 git_office 디렉터리에서 txt 파일을 수정 txt를 열면 git_home에서 수정했던 내용이 포함되어 있음 git_office 에서는 추가 수정하고 하고 저장
• 커밋을 만들고, remote repository로 push

 5.4 원격 브랜치 정보 가져오기

git fetch

remote repository 에서 변경 이력(원격 저장소의 최신 commit 정보)만 가져옴, 원본 파일은 병합 X

fetch로 가져온 커밋 정보를 확인하려면 git diff 명령을 사용해서 현재 최신 커밋과 원격 저장소에서 가져온 커밋의 차이 확인

$ git diff HEAD origin/main

원격 저장소의 commit을 확인하고 지역 저장소에 합치겠다고 결정했다면 merge 명령을 사용해 병합

$ git merge origin/main

 

 5.5 협업을 위한 저장소 만들기

• GitHub의 공개 저장소는 주소만 알면 누구든지 접속해서 모든 소스를 살펴볼 수 있음
• GitHub 회원이라면 누구나 오픈 소스 프로젝트의 소스를 내려 받을 수도 있음 하지만 누구나 저장소에 커밋을 푸시 할 수는 없음
• 공개 저장소든 비공개 저장소든 승인된 공동 작업자에게만 커밋을 올릴 수 있는 권한을 주어야 함 그래야 프로젝트 소스가 무분별하게 수정되는 일을 막을 수 있음
• 팀장과 팀원 1, 팀원 2 이렇게 세 사람이 GitHub를 통해 협업 한다고 가정
• 팀장이 저장소를 만든 후 팀원 1과 팀원 2를 공동 작업자로 추가
• 팀장이 ‘teamproject’라는 GitHub 저장소를 만들 때 ‘Add a README file’에 체크한 후 [Create repository]를 클릭하면 main 브랜치가 만들어짐

 5.6 저장소에 브랜치 만들기

• GitHub 저장소에서 [main]이라고 브랜치가 표시된 부분을 클릭하면 브랜치를 추가하거나 전환가능
• 새로 추가할 king을 입력한 후 그 아래 표시된 [Create branch king from ‘main’]을 클릭
• king 브랜치가 추가되면서 king 브랜치로 전환됨
• 같은 방법으로 queen 브랜치도 추가할 수 있음
• 이제 브랜치 목록을 클릭하면 기본 main 브랜치 외에 king 브랜치와 queen 브랜치가 생겨 있고, 사용자마다 이 브랜치들로 자신의 커밋을 푸시 하는 것

 5.7 공동 작업자 추가하기

• 저장소에서 [Settings]를 클릭
• 왼쪽 항목 중 [Collaborators]를 선택한 후 [Add People]을 클릭하면 공동 작업자를 추가할 수 있음
• 공동 작업자의 이메일 주소를 입력하다 보면 입력 창 아래에 완성된 이메일 주소가 나타남
• 완성된 이메일 주소를 클릭한 후 [Add 메일 주소 또는 사용자 이름 to this repository]를 클릭
• 같은 방법으로 필요한 공동 작업자를 계속 추가할 수 있음
• 저장소에 초대받은 사용자는 협업자로 초대됐다는 이메일과 GitHub 메시지를 받게 되는데, GitHub 메시지 화면에서 [Accept Invitation]을 클릭하면 초대를 수락하는 것이 됨

 5.8 원격 저장소 복제하기

• 터미널에서 git clone 명령 뒤에 원격 저장소 주소를 붙여 넣음 그리고 뒤에 지역 저장소 디렉터리 이름까지 적으면 그 디렉터리로 저장소가 복제
• 원격 저장소를 복제했다면 앞으로 자신이 직접 커밋을 만들고 GitHub로 푸시할 수 있음 그런데 그 전에 커밋할 때 사용할 이름과 이메일 주소를 설정해야 함 아직 지역 저장소 디렉터리에 있지 않다면 지역 저장소 디렉터리로 이동한 후 git config 명령을 사용해 이름과 주소를 지정

 5.9 원격 저장소에 커밋 푸시

• 공동 작업을 할 때는 내가 커밋을 올리기 전에 누군가가 원격 저장소에 커밋을 푸시 했을 수도 있으므로 항상 풀을 먼저 해야 함
• 변경 사항이 있다면 내려 받아서 지역 저장소에 병합해 주고, 변경 사항이 없다면 ‘Already up to date’ 라고 표시됨
• king 브랜치로 전환한 후 임의의 king.txt 문서를 작성 → 문서를 스테이지에 올리고 → 커밋
• git push 명령을 사용해 방금 만든 커밋을 GitHub에 올림
• 처음 푸시 할 때는 –u 옵션을 붙이고, GitHub의 king 브랜치로 푸시 할 것이기 때문에 ‘origin king’ 브랜치 이름을 넣어 줌
• GitHub에 제대로 올라갔는지 확인하려면 저장소에서 main이라고 된 브랜치 목록을 클릭한 후 [king]을 선택해서 브랜치를 전환
• 방금 푸시 한 커밋이 king 브랜치에 올라온 것을 확인할 수 있음

 5.10 Pull request 보내기 및 병함

• king 브랜치에 푸시 했던 커밋은 main 브랜치에는 커밋이 병합되지 않은 상태
• 파일 목록 위에 있는 [Contribute]를 클릭한 후 [Open pull request]를 클릭
• 다음과 같이 ‘Pull Request’ 메시지를 작성한 후 [Create pull request]를 클릭하면 협업 중인 저장소에 풀 리퀘스트가 전송
• 협업 중인 원격 저장소에 등록된 풀 리퀘스트는 공동 작업자 누구나 살펴보고 병합할 수 있음 공동 작업자 가운데 누군가 ‘Pull Request’를 요청하면 저장소 파일 목록 위의 [Pull request]에 숫자가 표시됨 [Pull Request]를 클릭
• 공동 작업자들이 등록한 ‘Pull Request’가 목록 형태로 나타남 아직 마무리되지 않은 ‘Pull Request’는 Open 상태라고 하는데, ‘Pull Request’ 제목 앞에 가 붙은 것은 Open 상태의 ‘Pull Request’임
• ‘Pull Request’ 메시지를 살펴본 뒤 내용에 문제가 없으면 [Merge pull request]를 클릭해 병합 필요하다면 이 공간을 통해 ‘Pull Request’를 남긴 사람과 메시지를 주고받을 수도 있음
• 커밋을 브랜치로 병합하는 것도 하나의 커밋이므로, 커밋 메시지를 입력해야 함 기본 메시지를 사용하거나 원하는 내용을 입력할 수 있음. 입력한 후에는 [Confirm merge]를 클릭
• ‘Pull Request’가 성공적으로 병합되었다는 메시지가 나타나면 병합이 끝난 것 그리고 Open 상태였던 ‘Pull Request’가 Merged 상태로 바뀜
• 화면 왼쪽 위에 있는 [Code]를 클릭해서 파일 목록으로 돌아가 보면, king 브랜치로 푸시 했던 커밋이 main 브랜치로 병합된 것을 확인 할 수 있음