[Git] github이란

1.Github이란?

git 원격 저장소를 제공 해주는 서비스 중 하나입니다. git 원격 저장소를 지원해주는 서비스는 github, gitlab, wiki 등이 있습니다.

필요 이유

• pull & request, git flow 등 다른 사람과 작업 내용을 공유할 때 즉, '협업'시 유용합니다.
• 개인 프로젝트의 경우 '백업'용으로, 버전 관리용으로 유용합니다.
• '오픈소스'에 유용합니다. 누구나 해당 프로젝트를 개발하고 PR을 날려 함께 논의합니다.

2. Github 명령어

[1] git remote

원격 저장소에 관한 명령어입니다. git clone을 수행하면 보통 default로 'origin'으로 지칭합니다.

$ git remote add remoteAlias remoteUrl # github 원격 저장소 url '별칭'을 지정합니다.이때, remoteUrl은 .git 끝까지 복사하고 https로 연결된 링크를 가져오는 것이 좋습니다.

$ git remote show remoteAlias # 원격 저장소 상세 정보를 확인합니다.

$ git remote -v

[2] git fork & clone

git clone

$ git clone remoteUrl

이미 존재하는 원격 저장소에 있는 깃 파일들을 로컬에 복사하는 명령어입니다. 보통 초기 셋팅시 사용합니다.

git fork

다른 사람의 레포를 자신의 깃헙 레포로 그대로 복제하는 기능입니다. 이때 fork한 원본 reop와 연결 되있는데요, 원본 repo에 어떤 변화가 생기면 그대로 fork한 repo에게도 반영할 수 있습니다.

예를 들어 오픈소스 repo가 있고 이를 자신의 repo에 fork한 후 자신의 repo에서 작업을 수행합니다. 이제 오픈소스 repo에 적용하고 싶다면 원격 repo에 PR을 날리고 관리자 승인 하에 merge할 수 있습니다.

[3] git push

$ git push remoteAlias remoteBranchName
$ git push origin dev # origin 별칭의 레포에 dev 브랜치에 현재 브랜치가 가진 내역들을 푸시합니다.

원격 저장소의 지정한 브랜치에 로컬에서 작업한 커밋들[히스토리]을 밀어 넣는 명령어입니다. 주의할 점은 push하기 전 pull 작업을 통해 remote 레포와 동기화를 맞춰줘야합니다. 이해의 편의상 리모트 서버의 최신 헤드와 로컬의 헤드가 각각 다른 브랜치이고 이를 머지하는 느낌으로 이해하길 추천합니다.

gitignore
.gitignore : git에 포함 안 시킬 파일을 미리 지정하여 push할 때 해당 파일을 무시합니다. 예를 들어, 키 값과 같은 유출되서는 안될 주요 정보, 불 필요 설정 파일 등이 있습니다.
sample site : https://www.gitignore.io

만약 .gitignore 파일을 잘못 포함시켰다면 아래의 명령어를 수행하면 됩니다. cached를 붙이면 로컬에 있는 파일과 폴더들은 그대로 놔두고 원격 저장소에 있는 것들만 지웁니다.

$ git rm --cached someDirectory
$ git commit -m 'remove ignored directory'
$ git push origin master

[4] git fetch & pull

원격 저장소의 변경 내역을 가져옵니다.

git fetch

원격 저장소에 추가된 git object들을 받아와서 로컬에 저장합니다. 이때 로컬의 마스터와 리모트에서 가져온 파일들의 마스터를 병합하지 않고 받아오기만 수행합니다. (이해의 편의를 돕기 위해 리모트에서 가져온 것과 현 로컬 브랜치가 각각 다른 브랜치 커밋으로 이해합니다.) 만약 두 브랜치를 합치고 싶다면 FETCH_HEAD(remote branch)와 마스터 현 브랜치를 merge하면 됩니다.

git pull

fetch와 merge 작업을 둘다 수행합니다. 즉 원격 저장소에 추가된 object들을 로컬로 받아오면서 merge까지 수행합니다.

$ git fetch remoteAlias remoteBranch
$ git fetch origin master
$ git pull origin dev

Your local changes to the following files would be overwritten by merge
remote repo에서 소스를 가져올 때 위의 에러 메시지를 볼 수 있습니다. 보통 자신이 작업한 내역을 push하기 전 pull 작업을 거칩니다. 만약 pull 받은 내역 중 로컬에서 변경한 파일과 겹치는 경우 발생합니다.

해결법

$ git stash # 현재 staging 영역에 있는 파일의 변경 사항을 스택에 넣습니다. 즉, 로컬에서 변경한 파일을 임시로 백업합니다.

$ git pull origin dev # 원격 저장소에서 내 로컬 브랜치로 변경사항을 적용합니다. 로컬에는 원격 저장소에 있는 내용으로 변경됩니다.

$ git stash pop # 백업한 내용을 꺼내, 파일을 합칩니다.

# 이후 중첩 변경된 파일을 수정 후 다시 commit & push 작업을 거칩니다.

[5] git pull & request

브랜치에 병합 하기 전 코드가 적절한지 팀원들과 의논하는 방법 중 하나입니다.
예를 들어, dev 브랜치에서 각자 맡은 기능을 개발하고 dev에 머지 하기 전 PR을 올려 팀원간 의사소통하며 코드에 대한 논쟁을 벌입니다. 이런 과정이 마무리 되면 관리자가 해당 커밋을 승인 혹은 거부 할 수 있고, 승인 시 CLI or GUI로 머지하게됩니다.

PR 참고 사항

• 적절한 PR 분량은 약 200줄 정도인데 너무 길면 새끼 브랜치를 따서 별도의 브랜치로 요청함을 권장합니다.
• PR 요청 시 'create pull'과 'create draft pull'이 존재합니다. 후자의 경우 아직 미완성 상태인데, 팀원들에게 빠른 정보 공유 혹은 피드백을 요청할 때 사용합니다.
• PR 리뷰는 관점에 따라 '내가 잘 가고 있나?'와 같이 스스로 돌아볼 수 있는 기회입니다. 너무 완벽한 상태에서만 요청하지 말고 방향성, 궁금증이 있을 때 질문 용도로도 활용될 수 있습니다.
• PR 리뷰시 가르치는 듯 하지말고 ~~~ 하면 어떨까요?와 같이 상대방이 한번 더 생각하게 추천하는 뉘양스로 접근해야합니다. 즉, 내 리뷰를 상대방이 받아들이지 않더라도 괜찮으니, 나는 제안만하는 포지션을 권장합니다.