* 프로그래머스, 타입스크립트로 함께하는 웹 풀 사이클 개발(React, Node.js) 5기 강의 수강 내용을 정리하는 포스팅.
* 내용 이해를 위해 수업 이외의 개인 자료 등을 덧붙이고 있음.
이미 계정 생성 및 저장소까지 만들어서 사용 중.. 과정 스킵.
실습용 Git Repo를 하나 새로 만들었다.
Repo 이름 및 설명 작성.
개인/공개 여부 설정.
Readme 파일 및 .gitignore 파일 생성 여부 선택.
(생성하는 것이 당연히 좋다. 둘 다 필요한 파일이기 때문.)
License 부분은 특정 라이센스 여부를 표시해야하는 저장소냐는 뜻인데.. 보통은 필요없다.
만약 Readme 파일 생성을 하지 않았다면, 몇 가지 수행해야하는 절차가 출력된다. CLI 방식의 Readme 생성이나 로컬과의 연결 등등..
(Readme 생성 이후 CLI 방식으로 Git을 연동하고 하는 절차들.)
git remote add (Repo별칭)/(RepoURL주소)
git remote add origin https://github.com/Akows/web-fullcycle-ts-react-node-5th.git
로컬에서 GitHub와 같은 원격 저장소에 파일을 업로드할 때 사용하는 명령어
git branch
목적: 새로운 브랜치를 생성하거나 현재 사용 중인 브랜치를 확인하는 데 사용. 주로 새로운 기능이나 버그 수정을 위해 별도의 작업 공간을 만들 때 사용함.
git branch new-feature # 'new-feature'라는 이름의 새 브랜치 생성
git branch # 현재 저장소에 있는 모든 브랜치 목록을 보여줌
git push origin main # 로컬 'main' 브랜치를 원격 저장소의 'main' 브랜치에 푸시
git push origin new-feature # 로컬 'new-feature' 브랜치를 원격 저장소의 'new-feature' 브랜치에 푸시
push가 정상적으로 이루어졌다면, Github UI 상에서 내가 작성한 파일이 정상적으로 업로드 된 것을 확인할 수 있다.
git log에서도 origin 저장소로 전달된 것으로 확인 가능.
git clone (Repo별칭)/(RepoURL주소)
git clone https://github.com/Akows/web-fullcycle-ts-react-node-5th.git
당연히 GUI 방식으로도 Github Repo를 Clone 할 수 있다.
Repo URL은 Github URL에서 가져와도 되지만, 웹 UI에서 친절하게 Clone을 위한 URL 및 복사 기능을 제공해주고 있으니 그대로 사용하면 된다.
참조링크. 자세한 절차는 링크 참고할 것.
몇년 전에 Github에서 보안 강화를 이유로 몇 가지 절차를 추가하였다.
비밀번호 노출 방지, 권한 제한, 유효기간 설정 등의 이유로 보안 토큰을 추가한 것. 이제 Github에서는 보안 토큰 없이는 로그인이나 원격 저장소와 로컬 사이에 파일을 주고받는 것 등을 하지 못한다.
보안 토큰을 생성했을 때, 이 토큰으로 어떤 권한이 필요한 작업을 수행할 수 있는지 범위와 유효기간 등을 설정할 수 있다.
한 사용자가 파일을 수정해서 commit - push 작업을 수행 했다고 가정해보자.
Github Repo의 파일이 수정되었고, 또 다른 사용자는 이제 Repo에서 갱신된 '최신' 버전을 받아와야 한다.
git pull origin main
이러면 Github에서 관리하는 원격저장소에서 최신 파일을 복제하여 로컬로 가져오게 된다.
실습 중 폴더 구조가 꼬여서 일단 강제병합 명령어로 pull을 받았다.. 원래는 안되는게 정상.
현재 저장소에서 원격 저장소(origin)를 제거하는 명령어.
기존에 연결되어 있던 원격 저장소와의 연결이 해제되어 더 이상 git pull, git push 같은 명령을 사용할 수 없게 된다.
모종의 사유로 git 사용에 문제가 생겼다면. Github 저장소가 온전하다면 차라리 연결을 해지하고 폴더를 비워버린 다음에 클론부터 받아서 깨끗하게 처리하는게 더 편할 수 있다.
Download ZIP. 프로젝트 파일을 Clone하는것 이외에 아예 ZIP 형식의 압축 파일로 프로젝트 전체를 내려받을 수 있다.
다만 용량이나 파일 갯수 문제 등으로 인해 프로젝트 실행에 필요한 패키지 파일 등은 포함되지 않고, 사용자가 로컬에서 따로 설치해줘야한다.
(그래서 npm i / npm install 명령어를 사용한다.)
Git에서 프로젝트의 독립적인 작업 흐름을 관리하기 위해 사용하는 개념.
메인 코드라인을 유지하면서, 별도의 브랜치를 만들어 새로운 기능을 개발하거나 버그를 수정하는 용도로 사용한다.
만약 여러 개발자가 메인 브랜치에서 기능 개발이나 테스트 작업을 동시에 진행하게 되면, 한 브랜치에 많은 변경 사항이 쌓이게 된다. 당연히 각 개발자들의 작업이 충돌하기 쉬워지고 이러면 Git의 버전 관리 기능은 아예 동작할 수가 없게된다.
이걸 방지하려면 여러 명의 개발자가 차례대로 작업을 완료할 때마다 push하고, 나머지 개발자들이 pull해서 작업을 이어가는 방식으로 진행해야하는데.. 당연하게도 극도로 비효율적이고 조금만 잘못해도 충돌 문제가 터질 수 밖에 없다.
이래서 각 개발자는 각자의 브랜치에서 작업하고, 작업이 끝나면 메인 브랜치에 병합하는 훨씬 효율적이고 안정적인 방법을 사용한다.
메인 브랜치(main/master): 대부분의 Git 저장소에서 main 또는 master라는 브랜치는 프로젝트의 주요 코드라인을 의미하며, 최종적인 코드가 합쳐지는 브랜치.
기능 브랜치(feature branch): 새로운 기능을 개발하기 위해 만든 브랜치로, 작업이 완료되면 주 브랜치로 병합. 예: feature/new-login
버그 수정 브랜치(fix branch): 특정 버그를 수정하기 위해 만든 브랜치로, 수정이 완료되면 주 브랜치로 병합. 예: fix/login-bug
단계 브랜치(staging branch): 코드가 배포되기 전에 최종적으로 테스트하는 브랜치로, 배포 환경에서 테스트를 진행하기 위해 사용.
브랜치 생성: git branch <브랜치이름>
브랜치 전환: git checkout <브랜치이름>
브랜치 생성과 전환: git checkout -b <브랜치이름>
브랜치 병합: git merge <브랜치이름>
브랜치 삭제: git branch -d <브랜치이름>