TIL9 | Thank you - "Git & Github"

🔥🔥🔥🔥🔥개발자들에게 "협업","소통"은 가장 중요하고, 필수적인 부분이라고 생각합니다.
그 이유는 방대한 프로젝트를 혼자서 모든 부분을 수정하고 처리할 수는 없기 때문입니다. 개발자들이 협업을 할 수 있게 기여하고 도와주는 Git 과 Github에 대해서 공부해 봅시다 🔥🔥🔥🔥🔥



설명에 앞서 밑에 이미지를 보시면 아주 간단하게 Git과 Github의 관계를 이해할 수 있습니다.

Git?

• 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템

• 작업 트리(Work Tree) : 우리가 작업하고 있는 폴더, 디렉터리를 말함

• 인덱스 : 커밋을 실행하기 전의 저장소와 작업 트리 사이에 존재하는 공간
  Staging Area라고도 불림

• 스테이징(Staging) : 인덱스에 파일 상태를 기록하는 것
  
  
  

Github?

• Git을 호스팅해주는 웹 서비스
• Git 저장소 서버를 대신 유지 및 관리해주는 서비스
  
  
  

Git Repository (저장소)

• 파일이나 폴더를 저장해 두는 곳

• 원격 저장소(Remote Repository)
  파일이 원격 저장소 전용 서버에서 관리되며 여러 사람이 함께 공유하기 위한 저장소
• 로컬 저장소(Local Repository)
  내 PC에 파일이 저장되는 개인 전용 저장소
  
  
  

Git의 핵심기능 & 사용하는 이유

• 버전 관리 : 문서를 수정할 때마다 언제 수정했는지, 어떤 것을 변경했는지 편하고 구체적으로 기록하기 위한 버전 관리 시스템

• 백업 : 현재 컴퓨터에 있는 자료를 다른 컴퓨터에 복제하는 것이다. 외장 하드 디스크나 USB 디스크 등의 별도 저장 장치를 마련해서 백업할 수도 있고, 드롭박스나 구글 드라이브와 같은 인터넷 서비스를 사용하기도 한다. 백업 공간을 제공하는 인터넷 서비스 중에는 깃 파일을 위한 것이 여럿 있는데 이를 깃의 원격 저장소라고 한다.

• 협업 : 팀원들이 파일을 편하게 주고 받으면서 협업할 수 있다. 누가 어느 부분을 어떻게 수정했는지 기록이 남아 나중에 오류가 생겼을 경우 파악하기 쉽다.
  
  
  

Git flow

• git-flow는 Vincent Driessen의 branching model을 적용해 고수준으로 저장소를 관리할 수 있게 해주는 확장 기능이다. branching model은 feature - develop(dev) - release - hotfix - master 단계로 브랜치를 나눠 코드를 관리하는 전략이며 사용자가 쉽게 접근하고 사용할 수 있도록 확장 기능(명령어)을 제공하는 것이다. git-flow에는 5가지 브랜치가 있다. 항상 유지되는 주요 브랜치들(master, develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)이 있다

저장소를 보다 고수준으로 관리하기 위한 브랜칭 관리 전략

• master : 기준이 되는 브랜치로 제품을 배포하는 브랜치 입니다.
• develop : 개발 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 합(Merge)칩니다.
• feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 합칩니다.
• release : 배포를 위해 master 브랜치로 보내기 전에 먼저 QA(품질검사)를 하기위한 브랜치 입니다
• hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치 입니다

Git 기본 명령어

• git init (생성하기) : 새로운 git 저장소 생성

• git pull (가져와 병합하기) : 원격 저장소에서 로컬 저장소로 업데이트, 원격 저장소에서 최신 변경 이력을 다운로드하여 내 로컬 저장소에 그 내용을 적용

• git fetch origin(가져오기)
  : 원격 저장소의 내용을 확인만 하고 로컬 데이터와 병합은 하고 싶지 않은 경우 사용하는 명령어
  원격 저장소의 최신 이력을 확인, 가져온 최신 커밋 이력은 이름 없는 브랜치로 로컬에 가져옴, 'FETCH_HEAD'의 이름으로 체크아웃 가능
  fetch 명령어 후 merge 를 수행하는 것은 pull 명령어와 동일한 기능

• git add <인덱스에 등록할 파일명> (추가하기) : 변경사항을 인덱스에 등록

• git commit -m "커밋 내용" (기록하기)
  : 이전 커밋 상태부터 현재 상태까지의 변경 이력이 기록된 커밋(혹은 리비전)이 생성
  '작업 트리'에 있는 변경 내용을 저장소에 바로 기록하는 것이 아니라 그 사이 공간인 '인덱스'에 파일 상태를 기록(stage - 스테이징 한다고 표현)
  commit 진행 시, 내용 입력 필수

• git push (밀어넣기) : 원격 저장소로 변경된 파일을 업로드하는 것

• git clone (복제하기)
  : 원격 저장소를 복제(원격 저장소의 내용을 통째로 다운로드하는 것)
  변경 이력도 함께 로컬 저장소에 복제되어 오므로, 원래 원격 저장소와 똑같이 이력을 참조하고 커밋 진행 가능

• git reset <옵션> <돌아가고싶은 커밋> (되돌리기, 이력 x)
  : 돌아가려는 커밋으로 리파지토리는 재설정, 해당 커밋 이후의 이력은 없애는 명령어

• git revert <되돌릴 커밋> (되돌리기, 이력 o)
  : 상태를 되돌리는 명령어, reset 명령어와 달리 이전 이력은 그대로 유지

• merge (병합하기, 바로 합치기)
  : 여러 개의 브랜치를 하나로 모을 수 있음 내가 끌어온 저장소가 최신 버전이 아닌 경우, 즉 내가 pull 을 실행한 후 다른 사람이 push 를 하여 원격 저장소를 업데이트 해버린 경우에는 위의 그림과 같이 내 push 요청이 거부될 수 있음, 다른 사람의 업데이트 이력을 내 저장소에도 갱신 해야함

• rebase (병합하기, 브랜치 이력 재정렬하기)
  : 히스토리 관리를 별로 신경쓰지 않고 혼자서만 커밋하거나 아니면 믿을수
  있는 소수만 커밋한다면 merge 대신 rebase 사용 권장

• git checkout <브랜치명> (전환하기)
  : 원하는 다른 브랜치로 전환 시 사용하는 명령어

👉 merge (바로 합치기) vs rebase (브랜치 이력 재정렬하기)

merge :
변경 내용의 이력이 모두 그대로 남아 있기 때문에 이력이 복잡해짐

rebase :
이력은 단순해지지만, 원래의 커밋 이력이 변경됨. 정확한 이력을 남겨야 할 필요가 있을 경우에는 사용하면 안됨.

리모트(Remote) 저장소

• 인터넷이나 네트워크 어딘가에 있는 저장소

• git remote 리모트 저장소 확인
• git remote add <단축이름> :리모트 저장소 추가
• git remote show <리모트 저장소 이름> :리모트 저장소 살펴보기
• git remote rename <기존 리모트 저장소 이름> <변경할 리모트 저장소 이름> :리모트 저장소 이름 변경
• git remote remove <리모트 저장소 이름> : 리모트 저장소 삭제

Branch

• 독립적으로 어떤 작업을 진행하기 위한 개념
• 각자 독립적인 작업 영역(저장소) 안에서 여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어 주는 기능

• git branch : 브랜치 생성
• git branch : 브랜치 조회
• git checkout : 브랜치 전환
• git checkout -b : 브랜치 작성과 체크아웃을 한꺼번에 실행
• git merge : 브랜치 병합, 이 명령어에 병합할 커밋 이름을 넣어 실행하면, 지정한 커밋 내용이 'HEAD'가 가리키고 있는 브랜치에 넣어지며, 'HEAD'는 현재 사용중인 브랜치에 위치하게 됨
  'master' 브랜치에 넣기 위해서는 우선 'master' 브랜치에 'HEAD'가 위치하게 만들어야 함

Fork

• 다른 사람의 Github repository에서 내가 어떤 부분을 수정하거나 추가 기능을 넣고 싶을 때 해당 respository를 내 Github repository로 그대로 복제하는 기능

Pull Request

• fork 및 파일 수정 후, 다른 사람의 Github repository에 변경 사항을 적용하고 싶으면 해당 저장소에 요청하는 것
  pull request가 original repository의 관리자로 부터 승인 되었으면 내가 만든 코드가 commit, merge되어 original 에 반영
  

---

1️⃣ 새 저장소 생성 후 Push

$ git init
$ git add .
$ git commit -m 메세지
$ git remote add origin 저장소 주소
$ git push origin master
---------> 최초 레포 생성 후 branch 만들기

---

2️⃣ 최초 레포 생성 후 branch 만들기

master 기준으로 branch 생성

$ git branch feature/이름
$ git checkout feature/이름

---> 여기서 현재 브랜치 어딘지 확인 (git branch 명령어로 초록불이 어디에 들어와 있는지 확인해야됨)

$ git add .
$ git status
$ git commit -m 메세지
$ git push origin feature/이름

---

3️⃣ 다른 사람이 만들어 놓은 레포에서 branch 만들어서 push 할 경우 (다른 사람이 최초 레포 생성 예를 들어 다른 사람 레포를 git clone할 경우 )

$ git init
$ git remote add origin 저장소 주소
$ git add .
$ git commit -m 메세지
$ git branch 새 브런치 이름
$ git branch
$ git checkout 새 브런치 이름
$ git push origin feature/이름