들어가기 앞서
이 글은 깃과 깃허브에 대해 서툰 지인을 위해 작성한 글입니다.
친분이 있는 지인을 위해 쓴 글이라 조금 과격한 표현이 있음을 미리 알립니다.
가정: 깃허브 레포지토리를 파서 처음부터 프로젝트를 만들고자 한다
0. 깃허브 레포지토리를 만든다.
1. 로컬에서 깃을 생성할 프로젝트 경로의 터미널에서 다음과 같은 명령어를 수행한다.
>> git init
(이제부터 이 프로젝트는 깃 프로젝트다. 이 시점부터 버전 관리를 할 수 있다.)
2. 최초 또는 파일 수정 이후 수정사항을 저장하고 싶다면, 즉 깃에 커밋 푸시하고 싶다면 다음 절차를 따르면 된다.
>> git add .
(변경된 파일을 모두 올리고 싶을 때 사용하는 명령어. 특정 파일만 따로 올리고 싶으면 git add [파일 이름] 이렇게 쓰면 된다. 근데 그냥 웬만하면 저거 쓴다.)
>> git commit -m “[커밋 메시지]”
(그 유명한 커밋 푸시할 때 커밋이다. 깃헙에 본격적으로 push 또는 pull request 하기 전에 거치는 단계이다. 만약 그냥 git commit이라고만 명령어 치면 vim 창이 뜨는데, 거기에 커밋 메시지 쓰고 저장해도 커밋된다.)
>> git branch -M main
(main이라는 이름의 브랜치를 만들겠다는 거다. main 브랜치를 메인 브랜치로 쓴다는 것이다. 예전 버전은 main이 아니라 master라는 이름이었는데 요즘 그런 일은 잘 없겠지만, 깃 버전 업데이트 안 한 사람이 master로 브랜치 파면 그것만큼 꼴받는 게 없다.)
>> git remote add origin [github 주소]
(당신의 로컬 깃과 깃허브 레포지토리(origin)를 연결한다. 이제 원격으로 깃에서 깃허브로 코드를 주고받을 수 있다. origin이라는 건 깃허브 레포지토리의 별칭 같은 건데 그냥 보통 이거 쓴다.)
>> git push -u origin main
(이제 당신의 로컬 변경사항(main)을 깃허브(origin)에 push할 수 있다. 여기까지 해야 깃허브에 올라간다.)
와! 이제 즐거운 개발을 시작하면 된다!
가정: 이미 존재하는 깃허브 레포지토리를 가져와야 한다
위에 거는 당신이 깃허브 레포지토리를 만드는 것이고,
이건 남이 만든 깃허브 레포지토리를 가져와야 한다. 쉽다.
>> git clone [깃허브 주소]
끝이다. 이제 당신만의 브랜치를 파서 즐거운 개발라이프를 즐기면 된다.
잠깐만, 브랜치가 뭔데?
아까 봤던 main ← 이게 branch다. 이름 그대로 "가지"다.
보통 최종 버전인 main 브랜치에서 특별한 사유가 있지 않는 이상 직접 작업하지 않는다.
여러 사람이 자신만의 브랜치를 만들어서 쓰거나, 개발하는 파트 별로 브랜치를 따로 파거나 그렇게 한다.
그럼 왜 이렇게 할까?
왜겠냐. 망할 conflict가 나면 그렇게 꼬울 수가 없기 때문이다.
만약 A와 B가 함께 main 브랜치로 작업한다고 치자.
만약 A가 수정하고, 그 변경사항을 가져와서 다음은 B가 수정하고,
다시 A가 변경사항 가져와서 수정하고... 그렇게 하면 충돌이 안 일어날 거다.
근데 만약 동시에 A와 B로부터 수정 커밋 푸시가 이루어지면
깃허브는 혼란스럽다. 도대체 어느 코드를 채택해야 할지 혼란스럽다.
그때 충돌이 일어난다.
그렇게 되면 깃허브에 변경사항은 올라가지 않고
사람이 코드를 일일이 보고 수정해서 conflict가 사라져야
비로소 깃허브에 올릴 수 있다.
충돌 일어난 코드는 중복 코드가 막 써져 있어서 일일이 눈으로 보고 수정하기 빡세다. 알고 싶지 않았다.
브랜치 활용법
현재 브랜치 목록 보기
>> git branch
새 브랜치 생성
>> git branch [브랜치 이름]
브랜치 이동
>> git checkout [브랜치 이름]
새 브랜치 생성 후 이동
>> git checkout -b [새 브랜치 이름]
브랜치 삭제 (병합된 경우)
>> git branch -d [브랜치 이름]
병합되지 않은 브랜치 강제 삭제
>> git branch -D [브랜치 이름]깃허브에서 최신 변경 사항 로컬로 가져오기
>> git pull
(깃허브에서 변경사항 가져온다. 끝이다.)
실무 프로젝트에서 사용하는 기초적인 git & github 사용 흐름
- VSCode 같은 당신의 로컬 프로젝트 환경에서 터미널을 켠다.
여기서 당신이 있는 브랜치가 main인지 확인한다. - git pull
(작업 전에 제에에에에발 git pull 하세요. 최신 변경사항 적용 안 하고 푸시하면 충돌날 확률 높습니다.) - git branch [내 브랜치]
(브랜치 만든다.) - git checkout [내 브랜치]
(작업할 브랜치로 이동한다.) - 코드 짠다.
- git add .
(변경사항 모두 등록한다.) - git commit -m “대충 커밋 메시지”
(커밋한다. 프로젝트 별로 커밋 메시지 쓰는 규칙은 보통 깃허브 README.md에 적혀있다.) - git push
(푸시한다.) - 이제 GitHub에 간다.
당신이 만든 이름의 브랜치가 생겨있고, 당신이 날린 Pull Request, 즉 PR이 있을 것이다.
Merge 시 Conflict가 안 나고 main 브랜치에 병합에 성공하면 끝!
Conflict가 난다면 유감이다. 잘 해보도록. 암튼 merge에 성공하면 branch는 지워도 된다. - 당신의 로컬 환경으로 다시 이동한다. git checkout main으로 main 브랜치로 이동한다.
- git pull origin main
(병합 완료된 깃허브 main 브랜치로부터 최신 변경사항을 가져온다.) - git branch -d [내 브랜치]
(제 역할을 다한 브랜치는 지운다.)
이제 이 단계를 능숙하게 다룰 수 있으면 나름 어디 가서 개발자라고 말하고 다니기 꿇리지 않는다. 아마도.
기타 주저리 주저리
사실 여기서 말 안 한 git 명령어는 많다.
fetch, stash, ... 등등? 깃 변경사항을 애초에 없었던 것으로 만들 수도 있는 reset이라든가.
암튼 많은데, 본인도 깃 마스터는 아니니 필요할 때 검색해봅시다.
(사실 이게 필요한 경우는 작업 중에 뭔가 꼬였다는 것이긴 하다. 특히 reset은 신중하게 합시다.)
깃허브로 협업하는 방법 중에는 branch 말고도 fork라는 게 있는데
그냥 레포지토리를 내 걸로 가져와서 단독으로 작업하는 것이다.
물론 작업 하나 후엔 branch처럼 메인 레포지토리에서 synchronize 해야 한다.
간혹 실무에서 브랜치 대신 포크 쓰는 경우도 있다고 한다.
VSCode에는 그냥 Sync 딸깍하면 커밋 푸시 자동으로 해주기도 한다.
간혹 변경한 적 없는 게 충돌 일으키는 경우가 있다.
그건 높은 확률로 로컬의 캐시 파일이나 yaml 파일 같은 거일 텐데,
.gitignore에 적어두면 그거는 깃이 반영 안 한다.
.gitignore에 토큰 정보 같은 중요 정보가 있는 파일도 넣어야 한다.
코드에서 중요 정보는 파일에 Key로 참조하도록 하면 된다.
애초에 토큰 정보 같은 중요한 거 깃허브에 올리면 바보긴 하다.
.gitignore 쓰는 법은 지피티 친구한테 물어보자.