ddodoi 님의 블로그
1주차-04: 포트폴리오/ 협업 환경 구성(3) 본문
일단 깃허브에 가입하여 계정을 생성하자.
Chapter1. 깃허브 레포지토리 create
깃허브 레포지토리란?
프로젝트를 깃허브에서 관리하기 위한 저장소로 대충 컴퓨터에 폴더의 역할이라 생각하면 된다.
다음 버튼을 이용하여 새로운 레포지토리를 생성한다.
Public: 레포지토리를 인터넷 사용자 모두에게 공유한다. 커밋 권한이 있는 사람을 지정할 수 있다.
Private: 레포지토리를 보고 커밋 할 수 있는 사람을 지정할 수 있다.
레포지토리 이름을 정하고 생성하면 된다.
Chapter2. 깃허브에 내 로컬 프로젝트 업로드 하기
깃허브에서 레포지토리를 만들었으니 이제 내 프로젝트를 업로드 해보자!
첫번째 박스는 아예 새로운 레포지토리를 만들때 사용하는 것이므로 넘어가고 우리는 존재하는 레포지토리를 불러와야하므로 두번째 박스의 방법을 이용한다. 다음 명령어를 vs code의 터미널 창에 불러오면 된다.
git remote add 원격저장소(깃허브 레포지토리)별칭 원격저장소 url
여기서는
git remote add origin https://github.com/ddodoi/KDT_FirstRepository.git
터미널에 명령어를 친 모습, 이후 git remote -v를 해주면 전에는 뜨지 않던 새로운게 뜬다. 이로써 깃허브와 연동됨을 알 수 있다. 그러나 코드는 아직 올라가지 않은 모습이다.
fetch: 서버에 있는 코드를 가지고 올 때 사용하는 명령어
push: 깃허브 원격 저장소에 로컬 컴퓨터 안에 있는 코드를 업로드(백업) 시킬 때 사용하는 명령어
이제 깃허브에 소스코드를 올려보자. 먼저 비교를 위해 git log 명령어로 현재 상태를 확인한다.
git push origin master
git push origin main
이제 깃허브 레포지토리를 확인해보면 성공적으로 소스코드가 업로드 된 것을 볼 수 있다.
이로써 내 컴퓨터 안에서만 로컬로 접근 가능했던 프로젝트를 깃허브에 올린 것이다.
다시 git log를 보자. HEAD->main옆에 아까는 없던 origin/main이 생겼다.
Chapter3. 토큰 생성
터미널에서 git push origin main 했는데 튕기거나 password를 적으라 해서 적었는데 안되면 토큰을 발급받아 이용해야 한다.
깃허브에서 토큰을 발급받아보자. 먼저 깃허브 오른쪽 상단의 내 프로필 사진을 클릭하면 다음 창이 뜬다.
여기서 Settings에 들어가 나온 페이지의 왼쪽 하단 아래 Developer settings에 들어간다.
Personal access tokens - Tokens(classic)클릭
오른쪽에 Generate new token - Generate new token(classic) 클릭
용도랑 만료일을 적어주고(no expriation은 추천 x), 아래 항목들 중 workflow, write:packages,delete_repo, project 체크후 맨 아래 Generate token 버튼을 눌러준다.
생성완료 된 모습. 초록 박스 안에 있는 것이 토큰이다. 복사해서 사용하면 된다.
Chapter4. 기존 깃허브 레포지토리를 로컬로 받아오기(CLI clone)
이번에는 반대로 기존 깃허브 레포지토리를 로컬 컴퓨터로 불러오는 작업을 해볼거다. 프로젝트를 불러오기 위해 로컬 컴퓨터에 GitTestClone이란 폴더를 생성한 후 터미널 창에
git clone 원격저장소url
을 입력해주면 된다.
clone이란 명령어는 1) 연결과 2) 소스코드를 받아오는 것까지 포함하고 있다.
Chapter5. 수정된 코드 올리고, 수정된 코드 받아오기
위에서는 로컬에서 만든 프로젝트를 깃허브 레포지토리에 업로드 하였고 그 레포지토리를 다시 로컬로 불러오는 작업을 하였다. 이때 맨 처음 로컬에서 프로젝트를 수정하게 되면 어떻게 될까? 다음 실습으로 알아보자.
원본 프로젝트의 jina.txt의 내용물을 수정해주었다.
이제 source control 버튼을 누르면 다음과 같은 창이 뜬다 M은 modified의 약자로 수정되었다는 뜻이다. +를 눌러 add를 진행시키고 commit버튼을 누른다.
그러나 이 수정은 로컬에 있는 프로젝트에만 반영된 것이고 깃허브에는 반영되지 않은 상태이다. 따라서 push 명령어를 이용하여 깃허브에 해당 수정을 반영해줘야한다. 터미널창을 열고
git push origin main
을 입력해준다.
이제 깃허브를 보면 Second commit이 반영되었음을 확인할 수 있다.
깃허브는 버전관리를 자동으로 해주므로 지난 버전의 커밋 기록또한 볼수 있다.
이 버튼을 누르면
이전 커밋 기록들을 볼 수 있다.
1. CLI로 commit하기
이제 수정된 깃허브 레포지토리의 코드들을 다시 로컬로 받아오는 작업을 해보자. GitTestClone폴더의 터미널 창에서
git pull origin main
명령어를 입력해준다.
다음과 같이 폴더가 깃이 아니라는 에러가 뜬다.
정말로 깃과 연결되어있지 않은지 확인하기 위해 git remote -v 명령어를 치니 연결되어있지 않다는 것을 확인할 수 있다.
이유는 깃허브에서 레포지토리를 clone해올 때 GitTestClonedml폴더 밑에로 불러왔기 때문이다.
이를 해결하기 위해 해당 레포지토리로 이동해준다. 어제 배웠던 cd 명령어를 이용한다.
이후 git remote -v를 사용해 해당 폴더의 깃과의 연결 유무를 확인해 보니 연결되어있다.
이를 해결하기 위해 해당 폴더와 깃과의 연결을 끊어준다. 명령어는
git remote remove origin
이다. (내가 별칭 지어줬던 원격 저장소와 연결을 끊겠다.)
다시 cd .. 으로 이전 폴더로 이동해주고 KDT_FirstRepository폴더는 우클릭으로 delete해준다. clone해온 프로젝트를 수정하는 것은 깃허브에 반영되지 않는다.
다시 GitTestClone폴더에 git init을 적용하고 clone을 다시 해오면 이상하게 아까처럼 하위폴더로 clone되어오는 문제가 발생한다. 이것은 다음에서 해결해보도록 하자.
2. GUI로 commit하기
vs code로 깃허브 레포지토리를 clone해올 때 미리 폴더를 만들어 놓고 폴더로 불러오는 것보다 그냥 clone한 프로젝트를 부르는 것이 훨씬 좋다. 새로운 창을 불러와서 실습해보자.
Source Control에 들어가 Clone Repository 버튼을 눌러준다.
받아올 레포지토리 url을 입력후 enter.
레포지토리를 받아올 폴더 생성 후 해당 폴더에 프로젝트를 클론해온다.
이번에는 하위 폴더로 클론된게 아닌 모습을 볼 수 있다.
깃허브에서 레포지토리를 클론해오는데 2가지 방법이 있다. 1. CLI로 직접 클론해오거나 2. GUI로 클론하거나. 둘다 틀린 방법이 아니다.
Chapter6. 연습: 깃허브에 올린 프로젝트 내려받기
GitTestGui 폴더에 새로운 파일 test1.txt를 만들어 깃허브에 커밋하는 과정까지 앞에서 배운대로 진행해보자. 명령어 git push origin main을 입력해 깃허브에 반영시키는 걸 잊지 말자.
이제 아까 레포지토리를 클론해온 폴더에서 git log명령어로 확인해보면 이번에 새로 만든 파일인 test1.txt는 아직 없다.
test1.txt파일을 불러오기 위해 git pull origin main을 입력한다.
Chapter7. 연습: 거꾸로 업로드하고 내려받기
이번에는 chapter 6에서 한것을 반대로 해보자. 클론해온 레포지토리에서 새로운 파일 test2.txt를 생성한다.
그 후 source control에 들어가 +(add)해주고 커밋메시지 입력후 커밋해주자.
다음과 같은 창이 뜬다. Sync Changes 버튼은 깃허브에 push해주는 역할을 한다. 눌러주면 깃허브에 성공적으로 수정이 반영된다.
다시 원본 프로젝트에 git pull origin main을 입력하면 test2.txt가 성공적으로 불려온 것을 확인할 수 있다.
Chapter8. 브랜치란?
브랜치(branch): 프로젝트를 따로따로 복사해서 용도별로 기능 구현을 위해 브랜치를 분리 하는 기능을 깃이 제공한다.
예를 들어, 프로젝트를 구현할 때 로그인 기능, 상품 조회 기능등으로 분리하여 따로따로 구현을 하고 싶을 때 이 기능을 사용하면 유용하다.
먼저 git status를 이용해 현재 프로젝트의 상태를 확인해보자.
On branch main
nothing to commit, working tree clean이란 문장 뜨는 것을 확인할 수 있다. 현재 main branch에 있고 커밋할 것이 아무것도 없으며 작업하는 트리(우리가 작업하고 있는 공간)가 깨끗하다는 의미다.
이제 내가 작업하는 공간(트리)에 다른 branch도 있는지 확인해보자.
git branch: branch목록 확인하는 명령어
명령어를 치니 *main 하나만 뜬다. 이것은 main브랜치 하나만 있는것을 의미하며 앞에 별은 현재 main브랜치에 위치하고 있다는 것을 의미한다.
이제 새로운 브랜치를 생성해보자.
git branch 브랜치명: 해당 브랜치명의 브랜치를 생성하겠다.
dev라는 브랜치 생성 후 git branch 명령어 입력하면 새로운 브랜치가 잘 생성된 걸 확인할 수 있다. 그러나 main브랜치에 계속 머물고 있다.
이제 dev브랜치로 이동해보자.
git checkout 브랜치명: 지금 있는 브랜치에서 나가서 해당 브랜치명의 브랜치로 이동하겠다.
명령어 입력후 git branch로 확인해보면 dev 브랜치로 이동한 것을 확인 할 수 있다.
dev브랜치로 이동한 상태에서 git log로 확인해보면 main브랜치의 내용과 완전히 유사하다는 것을 알 수 있다. 이는 가상적으로 복사가 된것이며 pointer와 같은 원리이다.
git checkout -: 이전 브랜치로 돌아간다.
'웹풀스택 일일정리' 카테고리의 다른 글
| 2주차-파트02: 웹 서비스의 이해1 (0) | 2024.08.22 |
|---|---|
| 2주차 파트-01: 협업 TOOL (0) | 2024.08.22 |
| 1주차-파트06: 브랜치 (0) | 2024.08.20 |
| 1주차-03: 포트폴리오/ 협업 환경 구성(2) (0) | 2024.08.17 |
| 1주차-02: 포트폴리오/협업 환경 구성(1) (0) | 2024.08.13 |
