이제 겨우 프로그래밍의 기초 공부를 시작한 입장이지만, 슬슬 작성하는 코드의 양도 많아지고 이것들을 관리하는 것이 어려워지기 시작했다.
저번에 작업한 콘솔 프로젝트만 해도 코드가 200줄이 넘게 나오기도 했고, 작업 내용을 벨로그로 작성하는 데에도 불편함이 있었다.
(어떻게 코드를 작성했는지 과정이 기록되지 않으니, 일일히 완성된 코드를 복사해서 처음에는 이렇게 작성했고 등등을 기록해야 했다.)
더군다나 게임을 만들 때에도 잘 되는 상황에서 저장해 놓고, 다음 작업에서 문제가 생겼을 때 이전 상황으로 복구하는 기능 같은 것도 있으면 좋겠다고 생각했다.
이런 상황을 위해서 Git이란 것을 활용해 보려고 한다.
1. Git이 무엇인가?
- 기존 작성된 내용에서부터 생긴 변동 사항을 추적하고, 버전처럼 관리할 수 있게 한다
- 작업 중인 사항에 문제가 생겼을 경우, 변경 사항 취소 및 되돌리기 기능도 있다
- 기기가 달라졌을 때에도 최신 작업본을 편리하게 내려받을 수 있다.
- 원격 저장되는 특성 때문에 팀 단위로 프로젝트 진행 시 협업이 가능하게 한다.
이와 같이 저장소의 역할 뿐만 아니라 다양한 활동을 할 수 있게 하는 공공저장소, 활동영역이라 할 수 있다.
다만, 깃을 그대로 사용하기에는 초보자 입장에서는 진입장벽이 있기에, 깃을 그대로 쓰는 대신에 깃허브를 활용해보도록 하자.
2. GitHub 시작하기
GitHub Desktop을 사용할 것이다. 이에 관해 설치 작업과 계정 생성 등의 필요한 과정을 수행했고,
깃에 있는 기능과 사용 방법에 대한 걸 알아보고자 한다.
GitHub가 어떻게 파일의 변동 사항을 추적하고 감지하는지 알아보자.
2.1) Repository 만들기
깃허브를 사용하기 위해 제일 첫 번째로 해야 할 것은 레포지토리(Repository)를 만드는 것이다.
테스트용으로 만든 레포지토리이다. 처음 레포지토리를 만들었을 때에는 좌측에 있는 Initial commit 하나만 자동으로 만들어져 있을 것이다.
깃허브 웹사이트로 들어가면 첫 레포지토리를 만들었다며 이렇게 알림까지 떠 있다.
이렇게 만들어졌으면 이제 깃을 사용할 준비가 되었다는 것이다.
2.2) 파일의 생성과 변동사항 추적하기
레포지토리를 생성했다고 전부가 아니다. 작업하던 파일의 변동사항을 추적하려면, 우선 해당 파일을 레포지토리 안에 넣어야 한다.
- 레포지토리가 어디에 있나요?
레포지토리에서 우클릭을 하여 Show in Explorer를 눌러보자.
그러면 위와 같이 해당 레포지토리가 있는 경로의 파일이 열린다.
(초기 설정 단계에서는 맨 위의 폴더는 없을 것이다.)
이렇게 해당 레포지토리 경로를 확인했으면, 작업 파일을 이 경로로 생성하거나, 아니면 복사나 옮기기로 넣어주면 그때부터 변동 사항 추적이 시작된다.
3. 주요 기능
깃허브를 사용할 준비가 되었으니, 주요 기능을 알아보자.
3.1) 커밋(commit)
흔히 개발자들이 잔디를 심는다고 하는 게 커밋이다. 그럼 커밋이란 뭘까? 테스트로 만든 레포지토리를 이용해 커밋을 해 보자.
우선 Visual Studio로 새 프로젝트를 만들고, 레포지토리에 넣은 다음 아래와 같이 작업을 했다고 하자.
이렇게 작업을 하고서 깃허브를 확인하면 변동 사항을 감지한 것을 확인할 수 있다.
(사실은 파일을 생성한 것부터 커밋이 되어 있어야 하는데 실수로 Push를 해 버려서 해당 내용만 남아있다.)
이제 여기에서 커밋하고 싶은 변동사항에 관해 제목과 상세 내용을 작성하면 된다.
- 커밋 작성 요령
커밋 메시지는 개인으로 작업할 때에는 개인 취향대로 하되, 회사에서는 회사별로 커밋 작성 요령이 있을 정도로 중요하다. 즉 정해진 작성 요령이 있을 경우에는 필수적으로 작성 요령을 따르고, 아닐 경우에도 어느 정도 가독성과 간결함이 필요해 보인다.
특히, 커밋을 단순히 시간으로 작성하는 것만큼은 피하자. (날짜, 혹은 몇일 차 등등)
적절한 커밋 작성의 예는, 무슨 기능을 만들었고, 수정했고, 삭제했는지 등등 활동 내역을 써 주도록 한다.
- 커밋 메시지 규칙
- 커밋은 왠만하면 영어로 작성하자.
- 제목으로 작업 내용을 파악할 수 있도록 하되, 필요시 상세 내용을 적는다.
- 제목을 적을 때 커밋의 타입(성격)을 "[]" 안에 넣어서 적은 후, 내용을 뒤에 적는다.
<커밋의 타입>
| 타입 이름 | 내용 |
|---|---|
| feat | 새로운 기능에 대한 커밋 |
| fix | 버그 수정에 대한 커밋 |
| build | 빌드 관련 파일 수정 / 모듈 설치 또는 삭제에 대한 커밋 |
| chore | 그 외 자잘한 수정에 대한 커밋 |
| ci | ci 관련 설정 수정에 대한 커밋 |
| docs | 문서 수정에 대한 커밋 |
| style | 코드 스타일 혹은 포맷 등에 관한 커밋 |
| refactor | 코드 리팩터링에 대한 커밋 |
| test | 테스트 코드 수정에 대한 커밋 |
| perf | 성능 개선에 대한 커밋 |
*ci:소프트웨어 개발에서 각 소프트웨어 개발자가 작업한 변경점을 프로젝트의 원래 소스 코드에 자주, 빠르게 통합하는 것
커밋을 올리면 위와 같이 반영된다.
3.2) 푸시(push)
위의 단계에서 커밋을 작성했다. 다만 커밋을 작성했다고 해당 내용이 깃허브에 올라간 것이 아니다.
변동 사항(커밋)이 있으면 이와 같이 Push가 활성화되는 것이 보인다.
이것을 누르면 지금까지 작성한 커밋이 깃허브에 올라간다.
다만 Push를 하는 것에 대해서는 신중하게 하도록 한다. 한 번 깃허브에 올린 내용은 수정할 수 없으니, 아직 수정해야 할 작업이 있을 경우 누르지 않도록 조심한다.
(나만 해도 당장 테스트파일을 Push해 버린 실수를 저질렀으니...)
3.3) 패치(fetch)
만약 내가 푸시로 지금까지의 커밋을 올리고, 이걸 다른 컴퓨터에서 이어서 작업한다고 할 때, 필수적으로 fetch를 해야 한다.
fetch는 깃허브의 레포지토리의 내용을 새로고침하는 것이다. 이전에 푸시를 한 기록이 있을 경우, 해당 내용의 업데이트를 볼 수 있다.
3.4) 풀(pull)
위에서 언급한 푸시와는 다르게, 풀은 지금까지의 변동 사항을 다운로드 받는 것이다.
만약 이전 컴퓨터에서 작업한 내용을 다른 컴퓨터에서 이어 한다고 했을 때 무조건 기억하자.
fetch와 pull을 하는 습관을 생활화하자!
3.5) 클론(clone)
깃허브에 있는 레포지토리를 다운 받는 것이다. 다만 pull 과는 다른 부분이 있다.
pull은 해당 레포지토리에서 권한이 있는 상태로 작업 상황을 업데이트 받는 것이고,
clone은 나의, 혹은 타인의 레포지토리를 복제하는 것이다.
편집 권한이 없으면 해당 레포지토리를 편집할 수 없으며, 코드 참고용으로 사용하면 좋아보이는 기능이다.
3.6) checkout commit
이전 버전의 상황으로 돌아갈 때 사용하는 기능이다.
이런 식으로 버튼이 있는 것을 확인할 수 있는데, 이를 이용해 특정 버전으로 이동할 수 있고, 테스트를 진행하는 등의 방식으로 활용할 수 있다.
- 주의사항 : 다만 해당 버전에서 내용을 수정해도 반영되지 않으니, 본인이 작업하고 있는 버전을 확인하도록 한다.
4. Merge Conflict(충돌)
아직은 팀 프로젝트를 진행하는 상황은 아니라서 충돌이 발생할 경우가 적지만, 충돌이 어떻게 발생하는지 알아보자.
- 집에서 int level = 1; 로 작업하고 push.
- 다른 컴퓨터에서 작업을 이어가고 있었는데, 실수로 fetch, pull 작업을 거치지 않아서 똑같은 작업을 또 했고, 이때 int level = 5;로 작업하고 push 했다.
- 깃허브는 int level = 1;로 해야 할지, int level = 5;로 해야 할지 판단할 수 없다. 이것 때문에 충돌이 발생한다.
이와 같이 버전이 다른데, 상이한 내용을 넣으려고 할 때 충돌이 발생한다.
이것 때문에 fetch와 pull을 하는 습관을 들여야 하며, 특히 팀 프로젝트에서는 충돌이 발생하지 않도록 작업하는 방식에 대한 고민이 필요하다.
5. 그래서 깃허브로 뭘 할 건데?
깃허브의 주요 기능을 알아보았고, 이제 남은 건 깃허브로 열심히 커밋을 하는 것이다.
그런데 아무래도 고민이 많았다. 지금 아직 프로젝트를 진행하는 단계도 아니고, 깃허브로 뭘 해야 하지?
이 와중에 코딩테스트를 깃허브와 연동하는 방법에 대해 배우게 되었다.
크롬 확장프로그램으로 깃허브를 연결하고, 백준 혹은 프로그래머스 문제를 풀면 문제를 품과 동시에 저렇게 로딩과 체크화면이 뜨면서 자동으로 깃허브에 푼 문제가 업로드 된다.
이미 푼 문제도 다시 제출하면 이런 식으로 깃허브에 자동으로 등록된다.
이와 같이 작업을 하고 나의 활동기록을 살펴보았다.
첫 잔디가 심어졌다. 계정을 이제 갓 만든 단계라서 허허벌판이 따로 없지만, 앞으로도 열심히 공부해서 잔디를 메워보도록 하자.
-참고 자료
(커밋 메시지 규칙)
https://velog.io/@chojs28/Git-%EC%BB%A4%EB%B0%8B-%EB%A9%94%EC%8B%9C%EC%A7%80-%EA%B7%9C%EC%B9%99
(코딩테스트 깃허브 연동하기)
https://publish.obsidian.md/jade-blog/Git/%EC%BD%94%EB%94%A9%ED%85%8C%EC%8A%A4%ED%8A%B8+Github+%EC%97%B0%EB%8F%99%ED%95%98%EA%B8%B0
