Session 7. Git & GitHub

*🔐Study Keyword :

• 🗝️Git의 개념과 필요성과 Git & GitHub의 차이에 대해서 인지하며
  🗝️터미널 명령어를 사용해 기본적인 Git 사용법과 🗝️GitHub를 사용한 개발 협업까지 알아보자.

-keynote

1. Git

-WHAT IS❓

• ☝GIT이란VERSTION 관리 시스템이다

-코드의 버젼을 관리해야하는 이유는 저장, 즉 `백업`을 해두기 위해 필요하다.

- 코드 버전 관리 이유?

1. 수정할 때 마다 파일을 생성하면 관리가 어렵다.
2. 언젠가 이전 코드로 돌아갈 수 있는 가능성이 있다.
3. 자신의 작업에 대한 이력을 남길 수 있다.
4. 하나의 프로젝트를 두고 여러 개발자들 협업할 수 있는 환경을 마련하기 위해서

-깃 설치 관련 명령어'S

git --version, 깃 설치후 버젼 확인하는 명령어
git config --global user.name "이름"
git config --global user.email "이메일", 깃의 본인 정보를 등록하기 위한 명령어

-Repositories(저장소)?

• Git repository는 Git으로 관리하는 프로젝트 저장소이다. (쉽게 말해 폴더 개념!)
• Git repository에 두 가지 종류
  • Local repository - 나의 컴퓨터에 저장된 로컬 버전의 프로젝트 저장소
  • Remote repository - 로컬 repository와 반대인 내부가 아닌 외부 (일반적으로 원격 서버) 버전의 프로젝트 저장소
  • 팀과 협업하여 작업 할 때 이 곳에서 프로젝트 코드를 공유 및 확인하며 로컬 버전의 프로젝트와 병합을 통해 변경 사항을 적용 할 수도 있다.

2. GitHub

-WHAT IS❓

1. 👍GitHub이란 ☝Git을 사용한 프로젝트들의 저장소를 말한다.
2. 다른 의미로는 개발자들의 Social network service이다.
   => 즉 ☝Git은 프로젝트의 버전 관리를 도와주는 시스템이고 GitHub는 ☝Git을 이용해 버전관리를 한 프로젝트들을 관리하게 해주는 호스팅 서비스이다.

<Git & GitHub 관계>

• 따라서 Git이라는 버전관리 시스템으로 관리한 코드, 프로젝트들을 모아두는 곳 바로 GitHub이다.

STEP1) 1>Local => 2>Remote

• Git을 CLI로 다루는 건 가장 중요하고, 기본적인 명령어들이다. 많이 사용하여 익숙해지자.
  

• Local은 우리의 Laptop을 의미, Remote는 Github를 의미한다.
  위 이미지는 Local에서 Remote로 Push하는 Flow를 보여준다.

  - 로그인 페이지를 만드는 작업을 진행한다 가정해보자. 작업 과정엔 여러 버젼이 존재하는데 이를 관리하기 위해 git & github을 이용해야한다.

• 1. git 시작을 위한 명령어 git init : 깃을 시작, 레포지터리를 만든다.
     (Git은 숨겨진 .git 디렉토리를 생성해 현재 저장소에 대한 변경사항 추적/관리하는 구조)
• 2. git 상태 확인을 위한 명령어 : git status , 어떤 파일이 변경되었는지, 어떤 파일이 추가되었는지 보여준다.
• 3. 파일 수정 이력 기록을 준비하기 위한 명령어 : git add .
     (프로젝트 폴더 내의 모든 파일과 폴더를 staging area에 추가하고 커밋을 남길 수 있게 준비해준다.)
• 4. 파일 수정 이력을 실제로 기록하는 명령어 : git commit -m "mesaage"
     (커밋은 특정 시간의 코드 스냅샷의 형태로 해당 repository의 커밋 기록에 남겨 git add 명령어를 사용하여 모든 파일을 staging area에 추가하면 commit 가능하다.)
• 5. 로컬 repository를 GitHub repository 와 연결해주는 명령어 : git remote add origin https://github.com/<your-username>/<your-repo-name>.git
     (로컬 Git repository에게 이름이 origin 이라는 어떤 URL을 알려주는 것과 같은 원리)
• 6. 로컬 Git repository의 코드를 GitHub repository 로 업로드 해주는 명령어 : git push 명령어
• 7(3~5). Local 저장소에 변경사항이 생기면 Local에서 작업한 내용을 Remote에 반영하기 위해
  • 다시 git add . 후에 git commit -m "Add:수정사항으로 작업 단위를 나눠준 뒤
  • git push origin master를 해줘야 Local repo를 GitHub repo로 push되어 업데이트된다.

• 깃의 커밋 내역의 히스토리 확인하기 위한 명령어 git log : 작성자, hash 값, 날짜와 시간, 그리고 커밋 메세지를 보여준다.

• 특정 커밋 시점의 코드로 되돌리는 명령어 git checkout <commit-hash> : <commit-hash>에서 git log에 보이는 커밋의 실제 hash 값으로 대체해주면 커밋 시점으로 코드를 되돌린다.
• staging area에 추가하고 싶지 않거나, git 에서 관리하지 않아도 되는 파일을 생성하는 명령어: .gitignore (파일을 프로젝트 폴더에 생성하고 .gitignore 파일 안에, 해당하는 파일명과 폴더명을 나열하면 됩니다.
• 깃 상에는 2개의 공간이 존재한는데(staging area와 repository) add와 commit 명령어를 구분해서 사용해해야 한다.

- add 명령어와 commit 명령어

• 이때 말하는 작업 내역 즉, 작업의 단위를 📡commit이라고 한다.
• 📢add 명령어를 사용하면 📡commit을 하기 위한 공간이 만들어진다.
• 📢add 명령어를 사용하면 공간을 한 곳으로 모아 임시 저장소 같은 공간을 만들어진다.
• => 이를 작업 단위로 모으기 위해서 로그인 작업을 한 코드들을 하나의 📡commit 단위를 사용하여, 즉 명령어로 이름을 붙여 모여주게 만들어준다.
  이떄 📡commit을 하면서 작업 단위를 설명하는 메세지를 함께 적어줄 수 있다.

참고✨)

• 수정하고 status 명령어를 써도 📡commit을 안한 내용은 Git에 들어가지 않는다는 사실

<과정 요약>

• 1.git init = 폴더를 git으로 관리하겠다는 명령어
• 2. git add . = commit 하기 전 준비단계의 공간을 만들어주는 명령어
  • git add .의 dot은 현재폴더안에있는 전부를 의미.
• 3. commit = 하나의 작업 단위(로그인, 회원가입 페이지 등의 작업 내역)가 commit.
  • ✔ git add & commit
    • add 명령어는 commit을 하기 위한 준비 단계의 명령어
    • commit 명령어에는 메세지(= 어떤 작업내역이 추가되고 삭제되었는지 등 다른 사람한테 알려주는 내용이 포함)가 포함
    • 보통 이 메세지의 형식은 회사의 convention을 따른다.
• 4. git status = 상태를 보여주는 명령어이다

TIP_ONE💥)

• 파일 작업 commit 중간에 status하는 습관을 가져 확인하며 진행하자.
  TIP_TWO💥)
• commit 한 내역을 볼려면 git log 명령어를 사용하면 commit ID가 나와 이 ID를 통해 돌아갈 수 있고 q키를 누르면 log 화면에서 나간다.

• 현재까지의 과정은 1>Local => 2>Remote, 즉 나의 랩탑에서 github로의 방향으로 진행한 과정으로

• 4번 까지 마친 후 깃 허브 사이트에 들어가 레퍼지토리를 생성(public은 모두에게 공개)한다.
• remote orginal 주소url 명령어, 통해 나의 git 폴더를 어디에 보낼지를 URL 주소 형식으로 저장소 주소를 적어 연결해준다.
• 나의 저장소가 remote 영역의 깃허브와 잘 연결되었는지 확인하기 위한 명령어 git remote -v
• 나의 폴더를 저장소와 연결한 후 나의 폴더를 저장소에 올려줄 수 있는 git push 명령어까지
  Local -> Remote로의 Flow이다.
  '

---

STEP2) Remote => Local

• 버젼관리를 위한 1> Git init, 2>git add, 3>git commit Local에서 자료 빈 저장소를 만들고 비어있는 곳에다 넣는 건 쉬운 편이다.
  
• 이번엔 이미 저장소에 들어온 자료가 있기 때문에 Remote에서 Local로 Flow을 가져가야한다.

-WHAT IS❓

• Remote에서 Local의 Flow는 깃 허브 상에 존재하는 저장소에 무언가가(보통 회사의 저장소) 들어가 있고 STEP1의 Local에서 만든 나의 저장소, 즉 Local 레퍼지토리로 가져오는 흐름을 가진다.

• 이 과정을 Git clone이라고 한다.
  • 이때 STEP1 과정과 다른 건 굳이 저장소를 연결을 할 필요가 없어진다는 점으로, Git 폴더와 저장소를 연결하는 remote 과정이 없어도 된다.
• branch가 default로 master(현재 main 바뀌었고)로 이 저장소 하나에 모두의 git 폴더를 모을 수 있다.

• 그러나 모두가 master branch에서 작업을 뒤 push를 하면 작업공간이 겹치게되어 충돌이 일어날 가능성이 있다. 따라서 어떤 작업이든 항상 작업내역을 나누고 진행해야한다

-WHAT IS❓

• 이렇게 작업과정을 나누기 위해 branch를 생성하여 나눈다.
  -branch란 독립적으로 어떤 작업을 진행하기 위한 개념으로 필요에 의해 만들어지는 각각의 branch는 다른 branch의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행하는 데 용이하다.
  • branch자체를 나눠서 생성하는데 위 이미지의 git branch feature/login과 같이 작업내역을 나누기 위해 1>branch 자체를 만들어서 작업 과정을 나누고 2>만든 branch의 작업 공간(master branch에서 다른 branch로)으로 이동시켜야한다.

• 왜 master에서 작업하면 안되유🤷‍♂️?

🙆‍♀️ 왜냐면 master branch는 유저에게 보여지는 최종적인 branch들 보통 들어간다.
=> 따라서 마스터(메인)에 코드가 들어가기위서는 refactoring이 된 깔끔한 코드들'만'이 들어간다!

• 0. git clone을 통해 회사의 코드를 받아온다. git clone은 최초에 레퍼지토리에서 작업을 할 때만 해준다. 클론 할 주소는 깃허브에서 복사하여 붙여넣기한다
• 1. 항상 git branch feature/login(branchName), branch를 만드는 걸로 시작한다.
     • TIP1💡) branch 생성과 동시에 생성된 branch로 이동하는 명령어 git checkout -b <new-branch-name>로 기존 checkout 명령어에 -b, flag를 추가해주면 된다.
     • TIP2💡) 프로젝트에 존재하는 모든 브랜치를 확인하는 명령어는 git branch
     • TIP3💡) 브랜치를 삭제할 수 있는 명령어 git branch -d <branch-name> (사용 시 주의)
• 2. branch를 옮기기 위해서 작업하기 위한 폴더로 이동 후 git cheack feature/login을 해준다.
• 3. 이동을 마치고 작업한 내용들을 git add, commit 해준 뒤 git push를 해주면 생성한 feature/login branch가 깃허브에 생겨난다.
  • Local에서 생성한 branch의 feature/login에서 작업한 코드를 Push하면 Remote 영역의 Github master branch엔 내가 작업한 내용이 들어가 있게된다.
    

• 4. commit하여 Remote영역으로 push한 코드를 master branch로 보내주는 작업을 pull request/PR**이라 부른다.
  • 이때는 보통 PR template,(회사의 컨벤션 따른다.)를 작성하여 본인의 요청사항이나 내용을 함께 적어서 보내준다.
• 5. Local 영역의 branch에서 작업한 내용을 Github의 master branch에 적용하고 싶을 때, 즉 branch A 와 branchB 를 병합할 수 있어 marge 명령어를 통해 과정을 거치면 생성한 feature login, branch가 회사의 master branch와 합쳐진다.
  • 5_1> 특정 branch에서 새로운 기능을 완벽히 구현 후 테스트까지 완료한 시점에선 기준이 되는 master branch에 구현내용을 적용시키 위해서 merge 명령어로 합쳐준다.
  • 5_2> 이렇게 리뷰 내용이 반영된 후 master branch와 충돌이 발생하지 않았다면, PR한 master branch로 merge할 준비가 완료된 것이다.
    

• 코드가 업데이트 되있는 상황이 Remote에서만 진행된 상태로 Local 영역의 master branch에도 업데이트를 해줘야한다.
• 6. git pull origin master 명령어을 통해 업데이트된 Remote 영역 master branch를 나의 Local 영역의 master branch로 이동시킨다.
  • git pull 명령어를 쓰면 Github에 있는 master branch를 그대로 가져와 이 시점부터 업데이트 된 작업 내역을 알 수 있다,
  • 즉 git pull을 거쳐야 Local 영역, 나의 노트북에 존재하는 Local영역의 master branch에도 업데이트된 내용을 알 수 있다.
    

📛주의📛)실수가 많이 발생하는 부분

• 1. 기존의 branch, feature/login에서 새로운 branch를 또 파게되면(생성하면) 깊은 형태의 branch 구조가 만들어져좋지 않다.
• 메인 줄기에서 branch의 가지가 하나씩만 나오는 형태가 가장 좋기때문에 브랜치는 한 번만 파는 것이 효율적이다.
• 2. 서로의 branch가 겹치면 충돌이 발생하니 조심해야한다.

<요약>

1. git clone <Url주소>, 깃허브 레퍼지토리가 있어 그 저장소의 주소값 복사해서 클론하여 가져온다.
2. cd 명령어로 작업하여 branch를 생성할 폴더로 이동한다
3. pwd로 경로 파악 후 git branch <new-branch-name> 명령어를 통해 작업 분리를 위한 branch를 만들어준다.
4. git checkout <branch-name> 명령어를 통해 생성한 branch를 작업할 폴더로 이동시키면 termianl 창 옆의 나의 작업 단위가 main에서 생성한 브랜치 명으로 바뀐다.

• 주의📛) Remote => Local Flow에선
  • git init할 필요 ❌
  • remote도 할 필요 ❌

5. git add . > commit -m "Add: 작업", 작업한 브랜치를 git add 후에 commit 단위로 나눠준다.
6. git push하여 Remote`영역으로 branch에서 작업한 작업한 내역을 올려주면 깃헙 사이트에` pull repositort**는 버튼이 생기고 클릭하여 해당 링크로 이동한다.
7. 옵션들을 설정하고나서 최종적으로 PR을 날려준다.

*💡conclusion

• 지금까지 살펴본 과정을 명령어와 함께 익숙해질 때까지 사용해 누군가에 설명할 정도의 수준이 되야한다.
• Local => Remote 방향으로의 Flow와 Remote => Local 방향으로의 Flow 2가지 모두 위 이미지처럼 머리속에 그림이 그려져야한다.

#📑Study Source

• WeCode 강의 중 관희님의 열정 강의 중:}