Day 03 - Github 가입, Repo 생성 및 실습

이유승·2024년 10월 30일
0

* 프로그래머스, 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 5기 강의 수강 내용을 정리하는 포스팅.

* 내용 이해를 위해 수업 이외의 개인 자료 등을 덧붙이고 있음.



1. Github 가입

  • 이미 계정 생성 및 저장소까지 만들어서 사용 중.. 과정 스킵.

  • 실습용 Git Repo를 하나 새로 만들었다.



2. 새 Repository 생성

  • Repo 이름 및 설명 작성.

  • 개인/공개 여부 설정.

  • Readme 파일 및 .gitignore 파일 생성 여부 선택.
    (생성하는 것이 당연히 좋다. 둘 다 필요한 파일이기 때문.)

  • License 부분은 특정 라이센스 여부를 표시해야하는 저장소냐는 뜻인데.. 보통은 필요없다.

  • 만약 Readme 파일 생성을 하지 않았다면, 몇 가지 수행해야하는 절차가 출력된다. CLI 방식의 Readme 생성이나 로컬과의 연결 등등..
    (Readme 생성 이후 CLI 방식으로 Git을 연동하고 하는 절차들.)



3. Github 사용법

Github Repo에 파일 업로드

  • 이런게 번거로워서 소스트리 같은걸 쓰긴 하지만.. 툴을 사용하지 않는 날 것의 방법을 익혀두는 것 역시 중요하다. 기억해둘 것.




git remote add (Repo별칭)/(RepoURL주소)

git remote add origin https://github.com/Akows/web-fullcycle-ts-react-node-5th.git

  • Git 연결 및 확인. 제대로 연결되었다면 fetch, push 주소까지 반환된다.
    (fetch: 원격 저장소에서 데이터를 가져올 때 사용하는 URL.)
    (push: 로컬 변경 사항을 원격 저장소로 푸시할 때 사용하는 URL.)
  • origin? 원격 저장소의 별칭. 원본이라는 뜻은 Github쪽의 저장소를 원본으로 개별 사용자들이 '복제'받아서 사용하는 것이기 때문.



git branch와 git push

  • 로컬에서 GitHub와 같은 원격 저장소에 파일을 업로드할 때 사용하는 명령어

  • git branch
    목적: 새로운 브랜치를 생성하거나 현재 사용 중인 브랜치를 확인하는 데 사용. 주로 새로운 기능이나 버그 수정을 위해 별도의 작업 공간을 만들 때 사용함.

git branch new-feature  # 'new-feature'라는 이름의 새 브랜치 생성
git branch              # 현재 저장소에 있는 모든 브랜치 목록을 보여줌
  • git push
    목적: 로컬 브랜치의 커밋을 원격 저장소로 업로드(push). 주로 git branch로 새 브랜치를 생성한 뒤, 이 브랜치에서 작업한 내용을 원격 저장소에 업로드할 때 git push 명령어를 사용함.
    (브랜치가 이미 존재한다면 git branch를 하지 않고, 존재하는 브랜치를 사용하면 된다.)
git push origin main         # 로컬 'main' 브랜치를 원격 저장소의 'main' 브랜치에 푸시
git push origin new-feature  # 로컬 'new-feature' 브랜치를 원격 저장소의 'new-feature' 브랜치에 푸시

  • 가끔 브랜치 이름이 main과 master가 혼동되는 경우가 있다. 브랜치 이름을 정확하게 파악하고 있을 것.
    (구글 등지의 자료에서 명령어를 복붙해올 때 내 브랜치는 master인데, 자료에서 main이라서 에러가 나는 경우가 있다..)

  • push가 정상적으로 이루어졌다면, Github UI 상에서 내가 작성한 파일이 정상적으로 업로드 된 것을 확인할 수 있다.

  • git log에서도 origin 저장소로 전달된 것으로 확인 가능.



GUI로 파일을 업로드 할 때, commit -> push의 순서를 빼먹지 말 것.

  • 로컬에서 commit만 수행하고 push를 수행하지 않으면, github 저장소의 내용은 업데이트 되지 않는다. HEAD -> master와 origin/master가 같은 commit 위치에 있지 않다면, push가 누락된 것이니 유의.



CLI으로 Clone 받기

  • 로컬에서 Github로 파일을 업로드 하는 방법 말고, 그 반대의 방법.

git clone (Repo별칭)/(RepoURL주소)

git clone https://github.com/Akows/web-fullcycle-ts-react-node-5th.git

  • Github 저장소에 있던 파일들이, 로컬로 복제되어 들어온다.



GUI로 Clone 받기

  • 당연히 GUI 방식으로도 Github Repo를 Clone 할 수 있다.

  • Repo URL은 Github URL에서 가져와도 되지만, 웹 UI에서 친절하게 Clone을 위한 URL 및 복사 기능을 제공해주고 있으니 그대로 사용하면 된다.

  • 그러면 Clone 및 Git 연동까지 자동으로 이루어진다.



Personal Access Token

  • 참조링크. 자세한 절차는 링크 참고할 것.

  • 몇년 전에 Github에서 보안 강화를 이유로 몇 가지 절차를 추가하였다.

  • 비밀번호 노출 방지, 권한 제한, 유효기간 설정 등의 이유로 보안 토큰을 추가한 것. 이제 Github에서는 보안 토큰 없이는 로그인이나 원격 저장소와 로컬 사이에 파일을 주고받는 것 등을 하지 못한다.

  • 보안 토큰을 생성했을 때, 이 토큰으로 어떤 권한이 필요한 작업을 수행할 수 있는지 범위와 유효기간 등을 설정할 수 있다.

pull 받아오기

  • Git 저장소를 클론해서 받아온 다음에, 원격 저장소에 갱신이 발생해서 업데이트 된 파일을 받아와야 한다면? pull을 사용한다.

  • 한 사용자가 파일을 수정해서 commit - push 작업을 수행 했다고 가정해보자.

  • Github Repo의 파일이 수정되었고, 또 다른 사용자는 이제 Repo에서 갱신된 '최신' 버전을 받아와야 한다.




git pull origin main

  • 이러면 Github에서 관리하는 원격저장소에서 최신 파일을 복제하여 로컬로 가져오게 된다.

  • 실습 중 폴더 구조가 꼬여서 일단 강제병합 명령어로 pull을 받았다.. 원래는 안되는게 정상.



git remote remove origin

  • 현재 저장소에서 원격 저장소(origin)를 제거하는 명령어.

  • 기존에 연결되어 있던 원격 저장소와의 연결이 해제되어 더 이상 git pull, git push 같은 명령을 사용할 수 없게 된다.

  • 모종의 사유로 git 사용에 문제가 생겼다면. Github 저장소가 온전하다면 차라리 연결을 해지하고 폴더를 비워버린 다음에 클론부터 받아서 깨끗하게 처리하는게 더 편할 수 있다.

  • 정상적으로 해지되었기 때문에, 연결을 시도해도 아무일도 일어나지 않는다.



GUI에서 pull, push 등등 수행하기

  • 당연히 GUI에서 Git - Github의 모든 기능들을 수행할 수 있다. pull, push 등등 여러가지 명령어들을 GUI 방식으로 제공해준다.



Github에서 프로젝트 파일 내려받기

  • Download ZIP. 프로젝트 파일을 Clone하는것 이외에 아예 ZIP 형식의 압축 파일로 프로젝트 전체를 내려받을 수 있다.

  • 다만 용량이나 파일 갯수 문제 등으로 인해 프로젝트 실행에 필요한 패키지 파일 등은 포함되지 않고, 사용자가 로컬에서 따로 설치해줘야한다.
    (그래서 npm i / npm install 명령어를 사용한다.)



4. Branch브랜치

  • Git에서 프로젝트의 독립적인 작업 흐름을 관리하기 위해 사용하는 개념.

  • 메인 코드라인을 유지하면서, 별도의 브랜치를 만들어 새로운 기능을 개발하거나 버그를 수정하는 용도로 사용한다.

  • 만약 여러 개발자가 메인 브랜치에서 기능 개발이나 테스트 작업을 동시에 진행하게 되면, 한 브랜치에 많은 변경 사항이 쌓이게 된다. 당연히 각 개발자들의 작업이 충돌하기 쉬워지고 이러면 Git의 버전 관리 기능은 아예 동작할 수가 없게된다.

  • 이걸 방지하려면 여러 명의 개발자가 차례대로 작업을 완료할 때마다 push하고, 나머지 개발자들이 pull해서 작업을 이어가는 방식으로 진행해야하는데.. 당연하게도 극도로 비효율적이고 조금만 잘못해도 충돌 문제가 터질 수 밖에 없다.

  • 이래서 각 개발자는 각자의 브랜치에서 작업하고, 작업이 끝나면 메인 브랜치에 병합하는 훨씬 효율적이고 안정적인 방법을 사용한다.



복수 브랜치 사용 예시


참고 링크 및 이미지 출처.

메인 브랜치(main/master): 대부분의 Git 저장소에서 main 또는 master라는 브랜치는 프로젝트의 주요 코드라인을 의미하며, 최종적인 코드가 합쳐지는 브랜치.

기능 브랜치(feature branch): 새로운 기능을 개발하기 위해 만든 브랜치로, 작업이 완료되면 주 브랜치로 병합. 예: feature/new-login

버그 수정 브랜치(fix branch): 특정 버그를 수정하기 위해 만든 브랜치로, 수정이 완료되면 주 브랜치로 병합. 예: fix/login-bug

단계 브랜치(staging branch): 코드가 배포되기 전에 최종적으로 테스트하는 브랜치로, 배포 환경에서 테스트를 진행하기 위해 사용.



브랜치 관련 주요 CLI 명령어

브랜치 생성: git branch <브랜치이름>
브랜치 전환: git checkout <브랜치이름>
브랜치 생성과 전환: git checkout -b <브랜치이름>
브랜치 병합: git merge <브랜치이름>
브랜치 삭제: git branch -d <브랜치이름>

  • 당연하지만 GUI에서도 브랜치 명령어들은 조금 더 편하게 사용하는 기능을 제공해주고 있다. 소스트리 같은 툴에서 브랜치 전환 정도는 클릭만으로도 가능할 정도.
profile
프론트엔드 개발자를 준비하고 있습니다.

0개의 댓글