GitHub

GitHub은 Git repository를 위한 호스팅 플랫폼이다. GitHub (및 기타 유사한 플랫폼) 없이도 Git을 사용할 수 있지만 다른 개발자와 같은 프로젝트를 두고 협업하거나 내 코드를 공유하기는 어렵다.

Git vs GitHub

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

GitHub을 사용하여 로컬 프로젝트 repository를 원격 클라우드 기반 GitHub 저장소에 업로드 할 수 있고, public repository 들을 통해 다른 개발자들과 교류할 수도 있다.

GitHub repository는 모든 프로젝트 파일들과 코드의 히스토리를 관리할 수 있게 해주고, public 혹은 private 하게 협업할 수 있게 해준다.

다른 사람들이 나의 GitHub 계정을 통해 내가 어떤 개발자인지도 알 수 있고, 내가 진행했던 프로젝트를 확인할 수도 있으므로, 개발자로서 GitHub 은 정말로 중요한 플랫폼이다.

ℹ️ GitHub 은 개발자들의 SNS 라고 해도 과언이 아니다. GitHub 유저들은 서로 follow 하고, 협업하기도 하면서, 다양한 방법으로 교류할 수 있다.

코드 버전 관리를 하는 이유

1. 수정할 때 마다 파일을 새로 만들면 관리가 힘들기 때문에
2. 언제든 이전 버전의 코드로 돌아갈 수 있기 때문에
3. 이력을 남기기 위해
4. 하나의 프로젝트를 두고 여러명의 개발자들이 협업할 수 있기 때문에

Using GitHub

Common Workflow: 내 로컬 Repository를 GitHub 에 push 하기
1. 로컬에서 add / commit 한다.
2. Github 으로 이동 후 새 repository를 생성한다.
3. 나의 로컬 repository 를 GitHub repository 와 연결한다. (remote 추가)
4. 새 remote 를 이용하여 코드를 Push 한다.

1. repository 생성하기

GitHub repository 를 생성하려면, github.com 으로 이동 후 우측 상단 + 버튼을 누른 뒤 'New repository' 라는 옵션 선택. repository 를 생성하는 페이지에서 제일 먼저 Repository name 을 설정해줘야 한다.

2. repository에 코드 push 하기

'Create repository' 버튼을 누르게 되면 새로 만든 GitHub repository 의 스타팅 페이지로 이동하게 된다. 로컬환경에 이미 Git repository 가 있다면 아래 ...or push an existing repository from the command line 부분에 나와있는 순서대로 진행하면 된다.

git remote add origin 명령어는 내 컴퓨터에 있는 로컬 repository 와 방금 만든 GitHub repository 를 연결해준다. 쉽게 설명하면, 로컬 Git repository 에게 이름이 origin 이라는 어떤 URL을 알려주는 것과 같다. 이름이 꼭 origin 이어야 하지는 않지만 보통 remote 주소가 한개라면 origin 이라고 지어주게 된다.

git push 명령어는 로컬 Git repository 의 코드를 GitHub repository 로 업로드 해준다.

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

git push 명령어를 실행하면 GitHub 유저네임과 비밀번호를 입력하라는 prompt가 뜨게 된다.

repository 가 성공적으로 push 되었다면, 전에 만든 GitHub repo 페이지로 가서 새로고침하면 로컬에서 push 한 코드가 해당 remote repository 로 업로드 된 것을 확인할 수 있다.

3. repository 에 변경사항 남기기

로컬 Git repo를 GitHub remote repo 와 연결 후 push 까지 했다고 로컬에서 작업한 내용들이 자동으로 remote 에 반영되는 것은 아니다. 그래서 변경사항이 있으면 다시 push 를 해줘야 GitHub repo 가 업데이트 된다.

예를 들어,

console.log("안녕하세요!");

위와 같이 콘솔로그문을 이미 가지고 있는 js 파일에 추가해주거나, 해당 내용을 담고 있는 새로운 js 파일을 생성해준다. 저장 후 커밋을 위해 add 후 커밋메세지를 남겨준다.

git add .
git commit -m "Change greeting"

커밋을 한 뒤, 아래 명령어를 입력해서 업데이트 된 로컬 repo를 GitHub repo로 push 해준다.

git push origin master

4. repository 클론하기 (clone)

지금까지는 로컬에서 Git repo 를 생성한 뒤 리모트 GitHub repo 를 생성해 연결해주는 예시였다. 다른 방법으로, GitHub repo 를 먼저 생성한 뒤 clone 을 받아 내 로컬환경에 다운로드 후 프로젝트를 시작하는 방법도 있다.

1번 에서와 같이 GitHub repo 를 생성한 후 repository 를 clone 하기 위해서 'Clone or download' 라는 초록색 버튼을 누른 뒤 아래 복사 아이콘을 클릭한다. (repository 주소를 복사해준다.)

그 다음 해당 remote repository 를 내 컴퓨터로 받아오기 위해, 해당 repo 를 다운로드 받고 싶은 경로로 이동한 뒤 git clone 명령어에 방금 복사해준 URL 을 붙여주고 실행해준다.

git clone <github-repo-link>

이렇게 하면 해당 경로에 clone 받은 GitHub repository 의 이름을 그대로 딴 폴더가 생성되고 cd 명령어를 사용해 해당 폴더로 이동하면, clone 시점에 remote repository에 존재했던 모든 폴더 및 파일들이 그대로 복제되어 있는것을 확인할 수 있다.

💡 이렇게 다른 개발자들의 public repository 를 클론받아 작업할 수도 있습니다.

Branching and merging

일반적으로 GitHub repository 의 master 브랜치는 항상 잘 작동하고 안정적인 버전의 코드를 포함하고 있어야 한다.

테스트를 아직 해보지 않았거나, 새로 추가한 기능을 GitHub repo 에 push 하고 싶을 때 Branch 가 필요하다. 브랜치를 사용해서 현재 프로젝트의 코드를 그대로 복제하여 작업 환경을 만들 수 있다. 그렇게 된다면, master 브랜치를 건드릴 필요없이 작업환경에서 기능을 추가하거나 테스트를 진행할 수 있게 된다. 나중에 전부 완료가 된다면, 그 때 master 브랜치와 merge(병합) 해줄 수 있다.

1. GitHub 에 브랜치 push 하기

예를 들어, 아까 생성 한 hello 프로젝트에 새로운 파일을 추가하고 싶다면, 우선 아래 명령어를 통해 새로운 브랜치를 생성하고 이동해야 한다.

git checkout -b feature/greetings

<feature/greetings> 부분을 원하는 브랜치 이름으로 대체하면 된다.

그런 다음, example.js 라는 파일을 만들고, 아래 코드를 삽입해준다.

console.log("Hello World!");

그런 뒤, 우리가 이제 익히 알고있는 커밋 절차를 거쳐 변경사항을 커밋해준다.

git add .
git commit -m "Add: greetings"

이제 push를 통해 feature/greetings 브랜치를 remote 로 올려줄 차례다.

git push origin feature/greetings

이렇게 하면, GitHub repository 에 내가 방금 push 한 branch가 추가되는 것을 확인할 수 있다.

2. Pull Request (PR) 생성하기

커스텀 브랜치를 push 하고 master 브랜치에 적용될 준비가 되었다면, Pull Request (PR) 라는 것을 통해 프로젝트 오너 (혹은 팀 리더) 에게 내가 작업한 브랜치의 작업내용을 master 브랜치에 반영해달라는 요청을 보낼 수 있다.

Pull Request 에서는 해당 repository 를 열람할 수 있는 권한이 있는 개발자들이 작업내용에 대한 리뷰를 해주거나, 변경 사항을 확인할 수 있다. (master 브랜치로 합쳐지기 전에 확인해야 하기 때문에)

해당 링크를 클릭하면, Pull Request 를 생성할 수 있는 페이지로 이동하게 된다. 거기서 해당 PR의 제목과 어떤 내용을 담고 있는지 설명하는 Description을 작성할 수 있다.

작성을 완료했다면, 하단에 'Create pull request' 버튼을 눌러 마무리한다.

이때부터는 함께 협업하는 개발자들이 방금 만든 PR을 리뷰, 분석하고 댓글까지 달아줄 수 있다.

모든 리뷰 내용이 반영된 후 master 브랜치와 충돌이 발생하지 않았다면, 해당 PR은 master 브랜치로 merge 될 준비가 완료되었다.

3. Conflicts (충돌)

항상 이렇게 순조롭게 merge 까지 진행되면 너무 좋겠지만, merge 하기 전 conflicts (충돌) 가 발생할 수도 있다. 충돌은 어떤 파일의 변경사항이 기준이 되는 master 브랜치의 파일과 겹쳐, Git 에서 어떤 버전의 코드를 선택해야하는지 모를 때 발생한다. 이런 상황에서는, 개발자가 직접 코드를 비교해 충돌을 해결하고 merge 를 마무리 해야한다.

4. GitHub 으로부터 변경사항 pull 하기

Pull Request 를 통해 master 브랜치를 업데이트했다면, 이제 로컬 repository 는 GitHub 에 있는 master 와 서로 다른 내용을 가지고 있게 된다. 이 때 git pull 명령어를 통해 remote 의 최신화 된 코드를 내 로컬 repo 에 반영할 수 있다.

우리는 GitHub remote repo 링크에 origin 이라는 이름을 붙여줬었기 때문에 아래 명령어를 통해 GitHub repo 의 master 브랜치 내용을 받아올 수 있다.

git pull origin master