Git Hub

simoniful·2021년 5월 23일

Wecode

목록 보기

10/14

코딩을 시작하면서는 작은 양의 코드만 작성했기에 GitHub를 일종의 저장소로써만 사용했었습니다. 윈도우 환경을 사용하면서 깃허브 데스크탑에 익숙해져 있었고 리눅스 기반 환경에 대한 막연한 두려움 때문에 우분투도 몇 번 안써본 것이 사실입니다. 하지만, 부트캠프에 들어와서 코딩을 시작하면서 스스로가 관리할 수 범위를 벗어나며 수정하는 부분에 대하여 버전 관리가 점점 필요하게 된 거 같습니다.

역시 목마를 때 가장 와닿는 것인지 부랴부랴 Git 관련해서 지식을 배우고 부족한 부분을 채워나가고 있습니다. 우선적으로 튜토리얼을 보면서 정리한 부분을 블로깅하려 합니다.

👉🏻 가장 쉬운 GitHub 강좌

github는 전 세계에서 가장 많은 소스코드들이 공유되어있는 클라우드라고 할 수 있습니다. 오픈소스의 성지. 내 소스들을 안전하게 보관하고 동료들과 협업하고 전세계의 뛰어난 개발자들과 소통할 수 있는 일종의 원격 저장소입니다.

Github 사용법

Common Workflow: 내 로컬 Repository를 GitHub 에 push 하기

로컬에서 add / commit 한다.
Github 으로 이동 후 새 repository를 생성한다.
나의 로컬 repository 를 GitHub repository 와 연결한다. (remote 추가)
새 remote 를 이용하여 코드를 Push 한다.

1. repository 생성하기

GitHub repository 를 생성하려면, github.com 으로 이동 후 우측 상단 + 버튼을 누른 뒤 'New repository' 라는 옵션을 선택해주세요.

repository 를 생성하는 페이지에서 제일 먼저 Repository name 을 설정해주셔야 합니다.

'Create repository' 버튼을 누르게 되면, 새로 만든 GitHub repository 의 스타팅 페이지로 이동하게 됩니다.

로컬환경에 이미 Git repository 가 있다면 아래 ...or push an existing repository from the command line 부분에 나와있는 순서대로 진행하면 됩니다.

2. Github 에 소스 올리기

만든 코드를 레파지토리에 올리는 방법입니다. $ git status 로 모두 commit 되어 있는지 확인합니다. 빠진게 있다면 전부 add 해서 commit 합니다.

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

이 후 $ git remote 를 통하여 remote 와 local 의 연결을 사이사이 확인하면서 잘 push 되었는지 확인합니다.

이 것으로 로컬에서 Git repo 를 생성한 뒤 리모트 GitHub repo 를 생성해 연결하게 되었습니다.

$ git remote
$ git remote add origin https://github.com/MiaJLee/github-practice.git
$ git remote
$ git push -u origin master

git push 명령어를 실행하면 GitHub 유저네임과 비밀번호를 입력하라는 prompt 가 뜨게 됩니다. 처음 연결 시에 뜨는 거니 당황하지 말고 GitHub 의 계정 비밀번호를 입력해주면 계속 진행됩니다.

3. 수정사항 반영하기

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

4. Github 내 리모트 소스 내려받기(Cloning)

GitHub 내 repository 를 clone 을 받아 내 로컬환경에 다운로드 후 프로젝트를 시작하는 방법도 있습니다. repository 를 clone 하기 위해서 Github 에서 오른쪽 상단 'Clone or download' 라는 초록색 버튼을 누른 뒤 아래 복사 아이콘을 클릭해주세요. (repository 주소를 복사해줍니다)

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

다운 받은 경로로 이동한 뒤 $ cd (다운 받은 repo 폴더명)을 입력해서 그 폴더 안으로 들어간 후에 git log를 입력해보면 프로젝트의 내역들이 그대로 복사되는 것을 확인할 수 있습니다. 이렇게 다른 개발자들의 public repository 를 클론받아 작업할 수도 있습니다.

$ git clone https://github.com/simoniful/github-practice.git
$ cd github-practice
$ git log

5. Branching and merging

일반적으로 GitHub repository 의 master 브랜치는 항상 잘 작동하고 안정적인 버전의 코드를 포함하고 있어야 합니다. 하지만, 테스트를 아직 해보지 않았거나, 새로 추가한 기능을 GitHub repo 에 push 하고 싶다면 어떻게 해야할까요?

앞서 Git을 정리하면서 브랜치를 통하여 기존의 것과는 다른 새로운 시도를 할 수 있다는 것을 알아 보았습니다. 브랜치를 만들고 체크아웃하면서 원하는 버전을 나누어 만드는 것이 가능하기에, 이를 GitHub와 연결하여 사용하면 프로토 타입을 작성하여 올리고 테스트 한 후에 마스터 브랜치와 병합하는 것이 가능합니다.

$ git branch : 로컬에서의 브랜치 확인
$ git branch -a : 로컬과 원격 모두 확인
$ git branch name : 브랜치 생성
$ git checkout : 브랜치로 넘어가기
$ git checkout -b name : 생성 + 이동 한 번에 가능

GitHub 에 브랜치 push 하기

프로젝트에 새로운 버전을 추가하고 싶다면, 우선 새로운 브랜치를 생성하고 이동해야 합니다.

git checkout -b feature/greetings

브랜치에서 작업물을 수정하고 익히 아는 방법으로 커밋 절차를 진행합니다.

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

이 후, 리모트 브랜치로 push하여 작업 내용을 올려줍니다.

git push origin feature/greetings

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

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

Pull Request (PR) 생성하기

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

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

회사마다 정해진 형식으로 작성하므로 규칙을 준수하여 구체적으로 마크 다운 문서로 작성하여 줍니다. 이 때부터는 함께 협업하는 개발자들이 방금 만든 PR을 리뷰, 분석하고 댓글까지 달아줄 수 있습니다.

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

Conflicts (충돌)

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