깃(Git), 깃허브(Github) 활용하기

 

개발자라면 깃에 대해서 한 번쯤은 들어봤을 것이다.

이번 포스팅에서는 깃을 쓰는 이유와 간단하게 깃허브를 활용하는 방법에 대해 정리해보고자 한다.

git 문법 및 github에 대해 설명하는 글은 많이 보았는데, github를 활용하는 방법에 대해 포스팅한 글은 적은 것 같아서 활용 방법에 초점을 두어 포스팅을 작성해보고자 한다.

 

깃의 3대 목적

한 개발자가 개발을 열심히 해서 프로그램 하나를 만들었다고 생각해보자.

개발자는 바탕화면에 폴더를 하나 만들고, 방금 만든 프로그램을 보관해둔다.

다음 날에 개발자는 또 기존 프로그램을 업데이트하여 새로운 버전의 프로그램을 만들고, 또 보관한다.

그렇게 여러 번을 반복하다보면 한 폴더 안에 프로그램이 여러 개 쌓이게 된다.

 

개발자의 프로그램이 1~2개 일 때는 관리하기 어렵지 않을 것 같다.

하지만, 프로그램이 100개, 1000개가 된다면 어떨까?

아마 관리하기가 쉽지 않을 뿐만 아니라, 컴퓨터 용량도 점점 부담될 것이다.

만에 하나 컴퓨터가 고장이라도 나버린다면? 지금까지의 모든 작업 파일을 잃게 되는 눈물 나는 상황이 일어날 수 있다.

 

 

• 버전 관리

깃을 사용하는 첫 번째 목적은 이러한 파일을 버전 별로 관리하기 위함이다.

깃은 각각의 작업 내용 수정사항을 스냅샷을 찍어 관리한다. (스냅샷: 마치 사진 찍듯이 특정 시점에 스토리지의 파일 시스템을 포착해 보관하는 기술)

스냅샷의 경우 전체 데이터를 복제하지 않기 때문에 데이터 저장, 관리, 복원에 효과적이다.

또한 수정사항에 메세지를 남겨 변경 사항에 대한 내용을 기록할 수 있다.

 

 

• 백업

깃은 데이터 백업을 위해서도 사용한다.

버전 별로 관리하는 과정에서 데이터를 효율적으로 저장, 관리할 수 있게 되면서 데이터 백업을 할 수 있게 된다.

로컬뿐만 아니라 push, pull 작업을 통해 원격 저장소에 파일을 보관할 수도 있다.

그렇게 되면 컴퓨터가 고장 나더라도 원격 저장소에서 언제든지 파일을 동기화할 수 있다.

 

 

• 협업

백업이 가능하다는 것은 단순히 데이터를 안전하게 보관할 수 있다는 의미 외에도 협업을 가능하게 해 준다는 의의를 갖는다.

원격 저장소에 파일 백업을 하게 되면, 동기화를 통해 어느 컴퓨터든지 해당 데이터를 동기화할 수 있다.

즉, 한 저장소를 여러 사람들이 동기화 작업을 하면서 작업하면 그것이 협업이 된다.

깃은 협업 과정에서 충돌이 날 수 있는 부분을 관리해주는 역할도 해준다.

 

 

깃 활용과 Github

깃을 활용하여 로컬에서 버전 관리와 백업을 효율적으로 할 수 있다.

하지만 깃의 진짜 핵심은 다른 사람들과 협업하는 데 있다.

깃 협업을 가능하게 해주는 깃 웹 호스팅 서비스는 Github, Gitlab, Bitbuket 등 다양한 호스팅 서비스가 있다.

이 중에서 가장 대중적이고 많이 사용하는 Github를 활용하는 방법을 알아보자.

 

 

현재 작업하고 있는 워디 프로젝트를 Github를 통해 작업하는 과정을 보여주며, Github를 활용하는 방법에 대해 간단하게 보여주고자 한다.

여기서 보여주는 예시는 Github를 활용하는 여러 상황 중 하나의 예시이다.(정답이 아니다)

Github Rule은 프로젝트를 진행하는 팀, 조직마다 다르기 때문에 Github를 어떻게 활용하는지 참고하는 정도로 봐주면 좋겠다.

 

 

 

Issue 등록

Issue는 앞으로 작업할 내용을 등록하는 곳이라는 정도로 알아두자.

깃허브 상단을 보면 Issue 탭이 있다.

해당 탭에서 Issue를 등록하고 조회할 수 있다.

Issue 등록은 New Issue 버튼을 통해 새로 생성할 수 있다.

 

 

 

New Issue를 누르면, 다음과 같이 이슈를 등록할 수 있는 페이지가 뜬다.

Issue는 프로젝트마다 정해진 양식이 있을 수 있다.

정해진 양식이 있다면, github 저장소 내에 양식(템플릿)을 등록하여 활용할 수 있다.

사진은 워디 프로젝트의 Issue 양식에 맞춰 이슈를 작성한 모습이다.

 

 

 

Issue를 작성하는 오른쪽에는 해당 Issue를 할당할 작업자와 작업 내용이 어떤 종류의 작업인지 알리는 Label 등을 설정할 수 있으며, 그 외에도 Projects와 Milestone 등을 설정할 수 있다.

 

Issue를 등록하면 다음과 같은 페이지를 볼 수 있다.

 

 

 

프로젝트 작업

Issue를 등록했다면 Issue에 해당하는 작업을 프로젝트에 수행해야 한다.

이번 예시는 task/Issue번호로 간단하게 브랜치를 만들어 작업하는 형태로 진행했다.

이 부분은 프로젝트 마다 Git-Flow, branch 전략 등이 매우 다양하기 때문에 정해진 답이 없기 때문에 흐름만 참고하도록 하자.

작업 전에 로컬 브랜치를 동기화해줘야 한다.

해당 예시에서는 main 브랜치에 곧바로 작업하는 형태로 진행됐기 때문에 작업 전에 main 브랜치를 동기화하고 진행하였다. 

 

 

 

앞서 언급했던 프로젝트 브랜치 네이밍 task/issue번호 형태로 작업할 브랜치를 만들고, 해당 브랜치로 이동한다.

해당 브랜치에서 Issue에서 계획한 작업들을 수행하고, 작업이 마무리되면 해당 브랜치를 원격 저장소로 push 해준다.

 

 

Pull Request

Pull Request는 작업한 브랜치를 main 브랜치에 merge 요청을 하는 과정이다.

작업 내용이 main에 merge 되기 전에 다른 팀원들과 공유하고, 코드 리뷰 및 코멘트를 달 수 있기 때문에 보다 효율적인 협업이 가능하다.

 

새로운 브랜치가 저장소에 등록되면 다음과 같이 pull request를 생성하라는 버튼이 뜬다.

해당 버튼을 누르거나, Pull Requests 페이지에서 New pull request 버튼을 눌러 Pull Request를 생성할 수 있다.

 

 

 

 

pull request 또한 Issue와 마찬가지로 템플릿을 활용할 수 있다.

해당 예시에서는 따로 템플릿을 사용하지는 않았으며, 간단하게 작업 상세에 대한 내용을 기입하였다.

PR 오른쪽에는 해당 PR을 리뷰해 줄 팀원과 작업한 사람, 작업 내용과 관련된 Label, Projects, Milestone, Linked Issues 등을 설정할 수 있다.

 

 

 

 

PR을 생성하면, 다른 팀원들은 해당 PR에서 코드 리뷰를 진행할 수 있다.

다음 사진과 같이 코드 리뷰가 필요한 부분을 지정하여 리뷰를 남길 수 있다.

리뷰는 여러 개를 한 번에 남길 수 있으며, 제안할 코드 등을 기입할 수도 있다.

 

 

 

 

위에서 작성한 리뷰 내용을 확인하면 다음과 같다.

기존에 작성한 코드는 빨간색, 리뷰를 제안한 코드는 녹색으로 뜨면서 작업자가 편리하게 제안한 코드를 확인할 수 있다.

제안한 코드는 IDE에서 작업하여 수정할 수도 있지만, github는 github 페이지 내에서 곧바로 수정할 수 있는 간편 기능을 제공한다.

 

 

 

 

코드 리뷰 및 작업 사항이 모두 완료되면 PR 하단의 Merge pull request를 눌러 merge 시키도록 하자.

참고로 해당 부분은 merge 할 브랜치와 충돌이 나는 부분이 없는 경우에만 녹색으로 표시되며 merge가 가능함을 알려준다.

충돌이 나거나 문제가 있는 경우에는 github 내에서 수정하거나 IDE에서 문제 사항을 해결한 뒤, merge를 하면 된다.