Git & GitHub
Git이란?
파일의 수정을 추적하고 수정된 내역을 버전으로 구분하여 관리해주는 시스템으로 수정 내역을 기록할 때 사용된다. 다만 개인이 홀로 사용할 때는 문제가 없지만 여러명의 다수가 동시에 수정을 시도할 때 충돌이 발생할 수 있다.
GitHub란?
Git 저장소를 온라인에 호스팅하여 협업이 가능하도록 한 Git 기반 플랫폼이다.
둘의 차이점
Git은 로컬 환경에서 파일의 수정 내역에 기반한 버전을 관리하는 도구이고
GitHub는 Git이 제공하는 작업을 온라인에서 여러 사람들과 협업할 수 있도록 하는 플랫폼이다.
Git에 대해 더 자세히 알아보자
Repository
레포지토리는 말 그대로 저장소이다. 프로젝트 파일과 해당 파일들의 모든 버전을 추적 · 기록 · 저장하는 공간이다. 해당 저장소는 로컬 저장소와 원격 저장소로 나눌 수 있다.
로컬 저장소는 Git을 이용하여 자신의 컴퓨터에 모든 파일의 버전을 저장하고 원격 저장소는 GitHub와 같은 플랫폼을 이용하여 여러 사람들이 손쉽게 접근할 수 있도록 한다.
Branch
브랜치는 여러 사람의 작업을 구분하여 독립적으로 작업할 수 있도록 해주는 기능이다. 기본적으로 main (=master)브랜치가 있지만, 새로운 기능을 개발하거나 버그 픽스 등을 위해 별도의 브랜치를 만들어 해당 브랜치에 맞는 작업을 하는 전략이 있다. 대표적으로 Git flow 전략이 있다. (아래 이미지 참고)
다만 실제 개발을 진행할 때 Git flow 전략 그대로 진행하는 것 보다 해당 전략을 기반으로 팀 성향에 맞게 혹은 프로젝트에 맞춰서 진행하는 것이 좋다.
Commit
커밋은 파일의 변경 사항을 기록하도록 git에게 명령하는 것이다. 이때 커밋 메시지를 기록하게 되는데 커밋 메시지는 해당 커밋이 어떤 변경 사항을 반영하는지 한눈에 유추할 수 있도록 작성해야한다.
협업하여 하나의 레포지토리를 사용할 때는 커밋이 행해지는 수정의 단계에 의미를 부여할 필요가 있다. 규칙을 정하여 각자마다 다르게 생각하고 정의했던 커밋을 규칙에 맞게 행하도록 해야한다.
커밋으로 인해 새로운 버전의 파일이 저장될 때 고유한 해시값으로 저장된다.
Hash
Hash는 보통 암호화에 많이 쓰인다. 입력된 데이터는 해시 함수를 거쳐 해시된 데이터로 변조된다. Input Data에서 Hashed Data로의 단방향으로만 변조 가능하며 변조된 Hashed Data는 고정된 길이, 임의의 값의 비트열로 구성된 데이터이다.
Commit을 거쳐 저장된 새로운 버전의 파일은 해시 처리된 데이터이다.
대부분의 유저가 겪어본 예시를 들어보자면 비밀번호 찾기 기능이 있다. 해당 기능은 과거 비밀번호 저장 과정에 비밀번호 인풋 값을 해시 데이터로 처리하는 로직이 없었기에 본인인증을 통해 회원가입 시 사용했던 비밀번호를 찾을 수 있었다. 만약 비밀번호를 해시 데이터로 처리하여 저장했다면 단방향 변조인 해시함수의 특성상 비밀번호를 찾을 수 없었을 것이다.
비밀번호 찾기 기능은 현재 비밀번호 재설정 혹은 임시 비밀번호 부여 등과 같은 방식의 기능으로 변경되어 유저들에게 제공되고있다.
Merge & Rebase
Merge
현재 브랜치의 commit을 다른 브랜치에 병합하는 것이다. Merge를 진행하면 병합된 두 브랜치의 변경 이력을 모두 보존하고 새로운 Merge Commit(Merge 정보가 담긴 Commit 내용)이 생성된다. 모든 Commit History가 보존되기에 작업 내용에 대한 추적이 용이하다. 다만 Merge를 자주 행할 경우 많은 Merge Commit으로 인하여 Commit History가 복잡해져 Conflict를 해결하기에 많은 리소스가 쓰일 수 있다.
Rebase
현재 브랜치의 commit을 다른 브랜치의 최신 commit 위치에 재배치하는 것이다. Merge Commit이 새롭게 생겨나지 않아 Commit History를 깔끔하게 유지할 수 있다. 다만 commit을 덮어쓰는 것이므로 Conflict가 발생 할 수 있으므로 협업 중에는 주의가 필요하다. 또한 Conflict 발생 시 해결하기위해 Merge 보다 더 많은 리소스가 쓰일 수 있다.
Reset
commit history, 스테이징 영역, 작업 디렉토리를 원하는 상태로 되돌리는 것으로 git 오류에 대한 troubleshooting 시에 자주 쓰이는 명령어이다. 세가지 옵션이 제공된다.
reset --soft
지정한 commit으로 HEAD 포인터를 이동시키며 스테이징 영역, 작업 디렉토리는 유지된다.
commit history만 삭제할 때 자주 사용되며 파일의 변경 사항은 그대로 유지되므로 다시 커밋할 수 있다.
reset --hard
지정한 commit으로 HEAD 포인터를 이동시키며 스테이징 영역, 작업 디렉토리를 모두 삭제한다.
복구가 불가능하니 사용시에 신중히 사용해야한다.
reset --mixed
지정한 commit으로 HEAD 포인터를 이동시키며 스테이징 영역을 초기화하고 스테이징되었던 파일은 작업 디렉토리로 되돌린다.
작업 디렉토리에 파일이 그대로 남아있기에 다시 스테이징하거나 commit을 수정하고 싶을 때 사용된다.
마무리하며 주저리주저리
git 명령어 관련 내용을 다루는 글은 구글링하다 보면 되게 많다는 것을 알 수 있다. 따라서 git 명령어 관련 내용은 차치하고 git에 관한 정보를 다뤄보고 싶었다.
현재 진행중인 데브캠프의 강사님이신 김민태 개발자님께서 실강을 진행해주시는데 첫 주에 다뤄주신 Git · GitHub에 대해 적어보았다. 다만 이 글에 적지 않은 다양한 내용들이 여전히 많이 남아있다 하지만 앞으로의 협업 프로젝트 과정에서 내게 필요한, 알아야할 것들만 적게 되었다. 현재는 실강으로 HTML, CSS 관련 내용을 다뤄주시는데 첫 강의 때 단순 강의가 아닌 여러 배경에 대해 설명해주셨다. FE 개발자가 되고싶은 사람들에게는 워낙 기초적인 내용인 HTML, CSS라서 그런지 개인적으로 첫 강의가 너무 재밌었고 앞으로의 실강도 너무 기대된다.
