GitHub

• Git Repository를 위한 호스팅 플랫폼
• GitHub와 같은 플랫폼이 없더라도 Git을 사용할 수 있지만, 프로젝트 협업 및 코드 공유가 어려움

Git vs GitHub

• Git: 버전 관리 시스템, 시간이 지남에 따라 파일의 변경 사항을 추적
• GitHub: Git을 사용하는 프로젝트를 위한 호스팅 서비스

기능

• 로컬 프로젝트 Repository를 원격 클라우드 기반 GitHub 저장소에 업로드
• Public Repository를 통해 다른 개발자들과 교류
• 개발자들의 Social Network Service: 유저 간 Follow, 협업 등 다양한 방법으로 교류
• GitHub Repository를 통해 모든 프로젝트 파일들과 코드의 히스토리를 관리하며,
  Public 혹은 Private 하게 협업
• 개발자로서의 포트폴리오 (참여 프로젝트, 개발 전문성 분야 기록)

GitHub: Where the world builds software

Using GitHub

Repository 생성

• GitHub 우측 상단의 + 버튼을 누른 뒤 나타나는 메뉴에서 New repository를 선택

• Repository name을 지정 후, Create repository 버튼을 통해 새로운 repository를 생성

[기존 로컬 repo 활용] Repository에 코드 Push 하기

생성된 repository의 스타팅 페이지에서 ...or push an existing repository from the command line에 따라, 기존 로컬환경에 생성된 Git repository에 연결

• git remote add origin 명령어는 origin이라는 이름의 URL을 통해 컴퓨터의 로컬 repository와 GitHub repository를 연결

git remote add origin https://github.com/<your-username>/<your-repo-name>.git

이름이 꼭 origin일 필요는 없지만, remote 주소가 한 개라면 보통 origin으로 지정함

• git push 명령어는 로컬 repository의 코드를 GitHub repository에 업로드

git push -u origin master

• 위의 명령어를 수행하면, GitHub 유저네임과 비밀번호를 입력하라는 프롬프트가 나옴

위 과정이 성공적으로 수행되었다면, GitHub의 repository 페이지를 새로고침하면, 로컬에서 push한 코드가 업로드 된 것을 확인할 수 있음

[GitHub repo 클론] Repository Clone 하기

로컬 repo를 미리 생성 후 연결하지 않고, GitHub repo를 먼저 생성하여 clone을 받아 로컬환경에 다운로드

• repository 주소 복사

• 해당 repo를 다운로드 받고 싶은 경로에서 git clone을 통해 방금 복사한 URL을 붙여넣고 실행하여 clone

git clone <github-repo-link>

위 명령어를 수행하면, 해당 경로에 Clone받은 GitHub Repository의 이름을 그대로 딴 폴더가 생성되며,
해당 폴더 내에 clone 시점의 remote repository에 존재했던 모든 폴더 및 파일들이 복제됨

위 방법으로 다른 개발자들의 Public Repository를 클론받아 작업할 수 있다.

Repository에 변경사항 남기기

로컬 Git Repo를 GitHub remote repository와 연결 후, 작업한 내용에 대해 다시 push를 해줘야 업데이트됨

• git add 및 commit

git add .
git commit -m "This is first commit"

• 업데이트 된 로컬 repo를 GitHub repo로 push

git push origin master

Branching and merging

• master 브랜치는 항상 잘 작동하고 안정적인 버전의 코드를 포함해야 함
• 신규 기능 및 안정성이 검증되지 않은 코드를 GitHub에 push하기 전에, 별개의 브랜치에서 작업하여 master 브랜치에 영향없이 동일한 작업환경에서 기능을 추가하거나 테스트를 진행할 수 있음
• 이후, 검증이 모두 완료된 안정적인 코드에 대해 master 브랜치와 merge함

GitHub에 브랜치 push

• GitHub에 새로운 브랜치 생성 및 이동

git checkout -b <feature/greetings>

• 새로운 브랜치 상에서 작업 진행 후 commit

git add .
git commit -m "Second Commit"

• 새로운 브랜치를 push를 통해 remote에 올림

git push origin feature/greetings

Pull Request(PR)

커스텀 브랜치를 push 후, master 브랜치에 적용될 준비가 된다면 Pull Request(PR)을 통해 프로젝트 오너에게 브랜치에서의 작업 내용을 master 브랜치에 반영해달라는 요청을 보낼 수 있음

Pull Request에서는 해당 repository 열람 권한이 있는 개발자들이 작업 내용에 대한 리뷰를 하거나 변경 사항을 확인할 수 있음

• Pull Request를 생성할 수 있는 페이지로 이동하며, 해당 PR의 제목과 어떤 내용을 담고 있는지 설명하는 Description을 작성 후 Create pull request를 누름
• 개발자들은 방금 생성된 PR에 대한 리뷰, 분석 후 코멘트를 달 수 있음
• 모든 리뷰 내용이 반영된 후, master와 충돌이 발생하지 않는다면 merge 될 준비가 완료

Conflicts

다양한 원인에 의해 Pull Request 들이 master 브랜치와 충돌이 발생할 수 있음

(대표적 상황) master 브랜치와 파일 겹쳐서, 어떤 버전의 코드를 선택해야할 지 모를 때

위 상황에서는 개발자가 코드를 비교해 충돌을 피하고 merge를 마무리

GitHub로부터 변경사항 Pull

Pull Request를 통해 master 브랜치를 업데이트한다면, 각 개발자 컴퓨터의 로컬 repository와 다른 내용을 가지므로, 최신화된 코드를 반영해야함

• git pull 명령어를 통해 remote의 최신화된 코드를 내 로컬 repo에 반영

git pull origin master

기존 origin이라는 이름으로 GitHub remote repo 링크에 이름을 붙여졌으므로, 그대로 활용함

추가 참고 사이트

GitHub Documentation

GitHub Guides