Git 협업 가이드

다른사람 보라고 만든게 아니라 가독성이 떨어짐 …

그리고 협업 목적보다는 노트북 + 데스크탑 옮겨가며 작업하느라 공유설정을 하는 차원

연결도 안된 상태에서 처음 환경설정하는 상황을 가정합니다.

1.깃 연결 확인

git remote -v

이미 연결되어 있는 깃이 있는지 확인

로컬 파일을 갓 만든 초기 세팅시에는 git init 먼저 해 주고 확인한다.

초기 세팅시엔 확인 안해도 되지만 불안하니까 한다.

git remote add <브랜치 이름> <원격 저장소 주소>

공유받을 주소를 내 브랜치에 가져오는 작업.

정상적으로 수행되면 git remote -v 를 사용해 연결이 되었는지 한번 더 확인한다.

이때 브랜치 이름… 내 마음대로 정할 수 있다.

git pull <브랜치 이름> <원격 저장소 이름>

앞서 사용한 브랜치 이름을 써서 원격 저장소에 있는 데이터를 가져온다.

git clone <원격 저장소 주소>

pull 대신 clone를 사용해도 된다.

git pull : 로컬에서 작업한 내용을 현재 브랜치와 병합해주며 원격 저장소에서 가져옴

git clone : 원격 저장소에 있는 내용을 내 로컬파일과 일치하게 만듬. 초기 세팅에서 많이 사용. 로컬에서 작업하던 내용 사라지므로 주의

npm install

package.json에 있는 내용을 토대로 필요한 모듈을 다운받아준다.

git switch -c test // 새버전
git checkout -b <이름> // 구버전

이름으로 브랜치가 생성되면서 작업장을 만들어주는 셈…

“이름”브랜치를 생성하면서 해당 브랜치로 이동함 +

git branch "이름" // 브랜치 생성
git switch <브랜치명> // 브랜치 이동
git branch -m <브랜치명> <새로운 브랜치명> // 브랜치 이름 변경

원랜 switch를 썼는데 checkout이랑 switch랑 뭐가 다른건지 모르겠어서 찾아봄

switch : 로컬에 있는 브랜치로만 이동 가능

checkout : remote에 있는 브랜치로도 이동 가능

기존 checkout의 기능을 switch와 restore로 분할한 느낌이라고 한다.

이제 checkout 헷갈려서 안쓴다고 –help 명령어에도 안띄워놓는듯한

git restore <수정할파일> // 새버전
git checkout -- <수정할파일> // 구버전

restore는 이런 식으로 사용됨

git add .
git commit -m "메모"
git push <원격저장소> <브랜치이름>

staging하고 커밋하고 원격저장소로 보내는 과정

이후, 깃허브에서 코드를 확인하고 merge를 할지 말지 결정할 수 있는데,

대체로 merge하는 사람은 하나인모양….(헷갈리니까)

+ 여담

git이 엉키면 뭐야 내 파일 돌려주세요 하게되고

내 작업파일을 인질잡힌채로 하는 매 시도가 다 식은땀나니까 엥간해선 잘 알아보고 하는게 좋은듯하다

혼자 작업하면 그냥 대충 로컬에서 휘뚜루마뚜루 만들고 냅다 push해버리면 되는데

내가 다른 사람이랑 작업해본적이없어서 한번 찾아봤다 (회사에다 건의했었지만 잘안됐음)

애초에 .gitgnore로 노드 모듈을 제외하고 업로드하니까

여러 사람들이 공통 데이터를 가지고 개발을 진행할 때를 생각해보니

데이터 내려받고 모듈 다운로드 각자 일일히 하는 똥같은 방법으로 다같이 협업한다고 생각하니 말이안되는거다

(내가 계속 레포지토리에서 데이터 내려받을때마다 그러고 있었음)

내가 찾던건 결국 npm install로 한방에 처리해버려서 지난 세월이 억울하지만 …

바보같은 세월이 있었으니 깨달음을 얻는거라고 생각합니다.