[TIL] Day03 - Github 원격 코드 관리, 브랜치 전략의 협업 워크 플로우
Github 레포지토리 생성, 연결
==깃허브 폴더
https://github.com/chae-dahee/GitTest
remote 연결
`git remote add 원격저장소별칭 원격저장소URL`
원격저장소 === 깃허브 레포지토리
원격저장소 별칭은 origin으로 많이 쓴다.
`git remote add origin https://github.com/chae-dahee/GitTest.git`
fetch : 깃허브의 코드를 가져올때,
push : 로컬 코드를 깃허브에 업로드할때 사용하는 명령어
코드 업로드
`git push origin main` → origin은 레파지토리 별칭!
❓ main VS master `git log`에서 commit head → main 이라고 되어있다.
new branch 생성되었다는 log 나옴
push 이후! 깃 레파지토리에 폴더가 업로드됨
git log를 했을때, `head → main, origin/main` 변경되었다.
CLI clone
깃허브의 소스코드를 받는 방법
연결, 코드 받아오기
`git clone 원격저장소URL`
pull, remote 삭제
수정된 사항을 github 에 올리는 방법
log로 커밋 잘 했는지 확인 후, git push origin main, 깃허브 사이트의 commit 기록을 보면, 어느부분이 수정되었는지 확인할 수 있다.
❓ git clone이 내부 폴더로 되는 경우? GitTestClone에는 git이 없고, 그 안 폴더 GitTest에 git이 있을 경우?
하위폴더 remote 제거하고, 상위폴더로 다시 연결!
`git remote remove origin`
해결방법 `GUI`
vscode에는 원하는대로 들어왔는데,
파일탐색기를 보면, 폴더구성이 그대로! vscode가 기존 폴더를 focusing하는지, clone된 GitTest폴더를 포커싱하는지 다른점이다.
즉, GUI CUI 동일한 방식인데, vscode에서 어떻게 화면에 띄워주느냐가 다르다
수정된 부분 pull 하기
`git pull origin main`
브랜치 Branch
나뭇가지에서 따온 이름. 프로젝트 하나를 여러 갈래로 가상 복사해서Clone 작업한다.
파일 단위가 아닌 프로젝트 단위로!
기능 별 병렬 구현할 때 사용한다. 추후에 하나로 합치는 과정을 겪는다.
`git status` : commit 되었는지, 브랜치 상태, working tree 확인
`git branch` : 브랜치 생성 목록 확인
`git branch 브랜치명` : 브랜치 생성
`git checkout 브랜치명`: 지금 브랜치에서 나가고, 브랜치명으로 이동하겠다!
이때, dev 브랜치로 바뀌어도, commit은 이전과 동일하다. 가상으로 커밋을 복사하는 느낌. 포인터 개념을 따른다.
`git checkout -` : 직전 branch로 돌아간다.
☑️ 배운 점
`git checkout -` 하이픈 사용하면 직전 브랜치로 돌아간다는 명령어
폴더의 포커싱에 따라 폴더 구성이 보이기가 달라질 수 있다.
remote, clone, pull의 개념. 세가지 모두 깃허브와 연결 및 받아오는 명령어인데 자세히 보면 다르다. 헷갈리기 쉬운 개념인데 정확히 이해할 수 있었다. 간단히 정리하자면, remote는 깃허브 저장소와 로컬을 연결하는 명령어. clone은 복사. pull은 수정사항 받아오기. 그런데 여기서 fork나 브랜치가 마구마구 섞이면 개념이 난리가 날 것 같아 두렵다..ㅋㅋㅋ
지금까지 git을 사용하면서 사고친적이 없긴 한데, 기본부터 이해하니 사고가 발생해도 뭔가 해결할 수 있을 것 같은 자신감이 든다!! 아자아자💪