KT AIVLE 수업 개강!
첫날은 생활코딩으로 유명한 이고잉 강사님에게 git에 대해 배웠다.
하나의 서비스를 만들어야하는 빅 프로젝트 시간에 팀원들과 협업하기에 정말 유용하다고 느꼈다. 그리고 vscode가 참 편하다는걸 알았다... pycharm을 쓰던 지난 날들이여, 무식하게 업로드 하면서도 찾아볼 생각을 하지 않았던 지난 날들이여 안녕~
이론 📝
현업에 나가면 3대 권력이 있다.
: 도메인(분야 지식), 코딩, 협업(git)
특히 협업은 가성비 좋은 기술이고 아래 사항을 포함한다.
- 버전을 잘 다루기
- 만든 버전을 안전하게 백업
- 인터넷에 올려 공유
git은 리눅스의 파생인 4세대 버전관리 도구이다.
4세대 이전은 중앙집중형, 4세대는 분산형.
비슷하게 예시를 들 수 있는 사례로 drobox, google drive등과 같은 cilent와 .com으로 구성된 서비스가 있다. 그러나 이것들은 내가 파일을 수정했을 시 .com으로 자동적으로 올라간다.
git은 단위 작업(하나의 완결된 작업)으로 나눠서 버전별로 업로드가 가능하다.
레퍼지토리에서 commit보면 버전을 확인 가능
(업데이트하면 업데이트 되는대로 남아있음)
각각의 버전은 그 버전이 만들어진 시점의 작업 디렉토리의 스냅샷이다.
- Split : 버전과 버전사이의 차이점을 보여줌
git에 올라간 코드에 이슈를 남기거나 코멘트를 달 수도 있다. (무려 행마다 따로따로 남길 수가 있음...!!)
권한만 있다면 다른 사람이 적어놓은 것도 수정, 삭제가 가능하다.
원격 저장소(레퍼지토리)를 만들 때에는 내 계정 안에서 이름이 unique 해야한다.
💡 자주 사용하는 명령어
commit : 로컬에서 작업한 변경사항을 하나의 버전으로 만들고 저장(인터넷 없어도 됨)
push : 로컬을 원격에 동기화 (버전을 저장소에 제출)
pull : 원격 내용을 로컬에 동기화
fetch : pull과 비슷한 기능 (git fetch + git merge = git pull)
add : working dir > stage area
git graph를 활용한 GUI에서도 가능하나, 주로 터미널에 명령어로 쓰면서 작업한다. 밑은 명령어 버전. 여러가지 바리에이션이 있으니 익숙해지도록 꾸준히 써볼 예정이다.
git commit -m "messsage"
git push
git pull
git add 파일명
git fetch origin
원격 저장소를 로컬과 동기화 📌
git - git 사이트에서 배포하는 프로그램(명령어로 동작)
-
로컬에 git client 다운로드
-
vscode 열기
-
터미널 열기 (뉴)
-
bash 쉘로 변경 (학습에 통일을 위함이어서 생략해도 무방할듯하나..명령어가 달라질듯 싶다.)
-
ssh 인증 비밀번호 만들기 (ssh-keygen)
ras 방식의 공개키와 비밀키로 id_rsa는 완전 private, id_rsa.pub는 github에 셋팅해야한다. -
깃허브 Settings (cat /c/Users/User/.ssh/id_rsa.pub)
프로필 이미지 누르면 Settings 버튼 보인다.
공개키를 cat으로 열어서 복사한 뒤에 깃허브 ssh key에 등록을 한다.
- 깃허브 웹 사이트에서 저장소 ssh 주소 복사
- vscode에서 깃허브 주소 등록
clone repository > yes > open
+++
Commit시 필요한 맨 처음의 셋팅 명령어, 이걸 제일 먼저 해준다!
반드시 깃허브 계정으로 적지 않아도 된다.
Git Graph 📌
git log를 GUI로 볼 수 있게 해준다.
설치하고 나서 보면 하단 파란줄에 버튼이 생겨있다.
HEAD- 빈 동그라미 : 현재 작업 버전, working dir을 알려준다.
main : 로컬에서 마지막으로 작업한 버전
origin : 원격 저장소의 메인이 뭔지 알려준다. (깃허브의 마지막 버전)
즉, 위 사진에서 로컬은 v3에서 마지막 작업이 되어있는데 원격저장소에선 그게 반영이 되어있지 않다.
이렇게 push까지 마쳐야 비로소 반영이 된다.
복수 파일 수정 📌
- 일단 파일을 수정하거나 만듦.
- commit 전에 각 버전 적고 commit하고 다시 push하면 된다.
어려울거 없이 그냥 동일한 과정을 거친다.
Local 📌
셋팅창에서 .git을 보이게 할 수도 안 할 수도 있다.
.git = repository 이고 project dir은 그 상위 개념.
Q. 내가 단위작업 별 commit을 잊었다면?
working dir에서 3작업 후 커밋 하지않고 4작업을 했다.
다행히도 쪼개서 작업별로 commit 할 수 있도록 git에서는 장바구니 개념의 중간과정을 만들어줬다. 장바구니 내용만 새로운 버전으로 .git에 올라간다. 그 장바구니가 바로 stage area.
장바구니에 담아두는 명령어는 아래와 같다.
add : working dir > stage area
commit : stage area > repository
Staged Changes에 올라가서 커밋하면 그것만 새로운 버전이 된다. (git add work1.txt와 같음)
버전관리를 잘하면 디버깅이 쉽다!
1. Head는 working dir가 어떤 버전에서 유래했는지 가리킨다.
2. master는 마지막으로 작업한 버전이 누구인지를 가리킨다.
3. check out은 Head를 옮긴다. (옛날버전으로 돌아갈 수 있음)
Q. 과거의 버그가 난 지점으로 check out한 후 수정을 하면 다시 현재로 복귀했을때 수정한 것이 반영이 되는가?
A. No, 버그를 기억하고 있다가 최신버전에서 픽스를 하고 커밋해야함
check out으로 과거버전으로 돌아갔다가 main에서 check out해야 파란 테두리가 생기고 제대로 돌아온다. (작업물 분실 위험 때문이다.)
Head, main 📌
1. Head 의 위치 ?
working dir는 Head가 있는 v7이다.
2. Head가 과거 버전을 직접 가리키고 있는가?
Yes, main에서 check out branch 해주기
3. 로컬의 메인과 원격저장소 메인이 서로 같은가 다른가?
다르다, 아직 v12을 push하지 않았다.
저장소를 만들면 Head는 main이 생긴다.
Head는 기본적으로 main을 가리킨다.
main은 version을 가리킨다.
version은 commit id를 갖고 있다.
commit id는 commit 내용 기반으로 해쉬값을 만들어서 사용한다.
헤드가 가리키는 버전이 부모 ,메인은 대리인 같은거.
새로 만들면 새쪽으로 메인이 옮겨감
이 상태에서 1번으로 가려면 체크아웃 1번
체크아웃 1번하면 위 그림처럼 된다.
그리고 체크아웃 메인을 해야지 원래대로 돌아옴
근데 체크아웃 4번을 한다면? 그리고 그대로 5번 작업을 한다면?
이렇게 된다.......
그래서 수습하겠다고 체크아웃 메인을 해버리면 5번 커밋 증발, 대신 실험적인 작업을 할 때 쓰면 오히려 좋다... 실패하면 증발시키면 되니까.
but, 성공 해서 5번을 쓰고 싶다면? 체크아웃 5번 하면 헤드가 5번을 가리키고 5번이 다시 살아남; (커밋 아이디 기억하기! 깃의 불변성...깃에는 삭제가 없다...)
Branch, Merge 📌
실험은 실험대로 하다가 메인의 내용이 원래 뭐였는지 보고싶은데
그냥 막 가면 다 날린다. 현재 버전에 이름을 달아놓자.
그것이 create branch!!!
이렇게 됩니다.
main은 디폴트 브랜치, exp는 만든 브랜치
우리의 저장소에는 브랜치가 2개!!
마음놓고 메인에다가 체크아웃 브랜치
exp에 체크아웃 브랜치 등등!
이런 평행우주가 생긴다고 보면 편하다.
다른걸 작업하면 이렇게 됩니다!!! 이것이 브랜치!!!
병렬작업 가능!!!! 막 버릴 수 있음!!!
실험에 성공한다면? 이제 합쳐야 한다...!!!
exp2를 main에 합칠 예정
(main이 exp를 병합)
밑의 그림처럼!
이렇게...된다...!!!! epx2에서 우클릭하고 Merge만 해주면 됨 ㅠ
새로운 버전의 부모는 e1과 m1, main은 새로운 버전을 따라감!!!
Conflict 📌
서로 다른 브랜치가 같은 파일 다른 행, 같은 행을 수정했으면?
병합 불가! = 충돌 (2-way merge)
그러나 git에서는 천재적인 발상이 있다...
m과 e의 공통의 조상(base)을 찾아 meb의 삼자대면..
but, 노란 형광팬 부분에서 충돌나고 나머지는 알아서 변경된 부분으로 병합해줌 (3-way merge)
머지 병합툴, 3 way지원..
내가 쓰고 싶은대로 수정하게 해줌.....
그러고 나서 수정하고 커밋하면.. 깔끔하게 올라감..
덮어쓸지 날릴지 그런거는 동료랑 상의하면 된다.
아니면 싸움날듯...
협업 📌
origin 자체도 사실 branch인데 remote tracking branch이다.
어디까지 push했는지 마킹하는 용도 (git이 관리)
같은 부모 버전을 가졌지만, 각각의 local에서 다른 파일 만들고 올리려하면 손이 느린 사람은 push 불가능!!
원격 저장소에 있는게 로컬에 없으면 오버라이팅 되니까 push 거절 (충돌)당함
올라간거 받아서 합친 다음에 push해줘야함
그러기 위한 fetch와 merge입니다.
fetch : 원격 저장소의 버전이 새로운 브랜치로 다운로드 됨, 원격 저장소의 파일은 안 받아짐, 충돌 안남
merge : 다 병합 내꺼 니꺼 합친 버전 만들어줌, 원격 저장소 파일도 다 받아짐, 그래서 충돌 남
위 그림, 빨간펜 : local / 파란펜 : 원격
이 상황에선 R1은 local에만 있음
push까지 하니까 원격에도 다 올라감 R1 다 올라감 origin보고 아는거임!!!
IF, 이제 다른 사람이 작업한다.
작업전에 먼저 패치한다.
오~ R1과 머지커밋을 받게 됨
여기서 끝나면 안됨~ 헤드가 L1인걸 확인하고!
오리진/메인을 현재 헤드에 머지시킴
++++
이미 local에서 작업 후 다른 원격 저장소에 넣고싶다면,
원격 저장소 주소를 add remote 시키고 이름도 적어준다.
관련 내용은 강의 올라오면 다시 보고 복습할 예정...
열심히 적는다고 적었는데, 빠진 부분이 꽤 있을 수도 있다.
