깃허브 커밋 히스토리 초기화 방법

@baealex·2020-04-19 22:53

한 때 나는 깃허브를 사용하는 것 만으로 스스로를 대견해한 적이 있었다. 하지만 되돌아보니 내게 남은건 너저분한 커밋과 정리되지 않은 ReadMe 뿐이었다. 깃의 사용에 익숙해질 즈음 취업용으로 깃허브의 링크를 제출하려보니 되려 "나는 이 회사에 가고싶지 않아요" 같은 느낌이 주는 것 같았다.

asd

"asd"

커밋 히스토리 리셋

일단 가장 먼저 한 일은 커밋 히스토리를 날리는 것이었다. 웹상에선 불가능하고 반드시 터미널을 사용해야 한다. 아래 나열될 명령어만 따라쳐도 가능한 수준이니 큰 부담은 필요없다. 필자는 리눅스에서 진행했지만 윈도우를 사용한다면 GitBash를 별도로 설치해야 한다.

깃 터미널

이 상태로 진행된다.

바로 명령어

# 프로젝트를 클론하세요. 가령 프로젝트 이름이 `myproject'라면 아래와 같습니다.
git clone https://github.com/heiswayi/myproject.git

# 모든 커밋 히스토리는 `.git`에 들어있습니다. 우리는 이걸 지울겁니다.
cd myproject

# 아래 명령어로 `.git` 디렉터리르 지웁시다.
rm -rf .git

# 이제, 우리는 저장소를 재초기화 해야합니다.
git init
git remote add origin https://github.com/heiswayi/myproject.git
git remote -v

# 모든 파일과 커밋을 추가합시다.
git add --all
git commit -am "Initial commit"

# 마스터 브랜치에 강제로 푸시를 해줍니다.
git push -f origin master

터미널에서 깃을 처음 사용하는 유저라면 아래 명령어를 통해서 사용자 정보를 등록하자.

git config –global user.name …
git config –global user.email …@…

깔끔해진 커밋 히스토리

그럼 위와같이 깔끔한 커밋 히스토리와 조우하게 된다.

커밋 규칙

커밋은 어떻게 달아야 보기좋을까? 정답은 없을 것이다. 자기만 보기 좋으면 베스트다. 'asd'라는 커밋도 의미가 있다면 사용해도 무방하겠다. 하지만 깃허브라는 '공개된' 공간에 올려둔 만큼 혹은 취업을 위해서라면 나도 보기 좋으면서 남들에게도 보기 좋은 형태로 기록해 두는게 좋을거다. 필자는 이곳에 나열된 규칙이 개인적으로 맘에 들었다.

정리하면 아래와 같다.

태그	상황
feat	새로운 기능을 추가할 경우
fix	버그를 고친 경우
docs	문서 수정한 경우
style	코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
refactor	프로덕션 코드 리팩터링
test	테스트 추가, 테스트 리팩터링 (프로덕션 코드 변경 없음)
chore	빌드 테스크 업데이트, 패키지 매니저 설정할 경우 (프로덕션 코드 변경 없음)

필자의 경우엔 위에서 feat, fix, docs, style만을 사용하여 커밋을 유지하고 있다.

테스트 추가라던가 빌드 테스크 업데이트와 같은 상황은 아직 능력밖의 일이다.

문서 작성하기

다음으론 ReadMe를 어떻게 관리할까 고민하자. 이글을 작성했던 시점부터(2018-08-18) 필자는 아래와 같은 ReadMe 템플릿 양식을 무의식적으로 따랐었다.

# 프로젝트명
> 간략한 프로젝트 소개 문구를 작성합니다.

한 두 문단으로 프로젝트 소개 글을 작성합니다.

## 설치 방법

OS X & 리눅스:

## 사용 예제

스크린 샷과 코드 예제를 통해 사용 방법을 자세히 설명합니다.

_더 많은 예제와 사용법은 [Wiki][wiki]를 참고하세요._

## 업데이트 내역

* 0.2.1
    * 수정: 문서 업데이트 (모듈 코드 동일)
* 0.2.0
    * 수정: `setDefaultXYZ()` 메서드 제거
    * 추가: `init()` 메서드 추가
* 0.1.1
      * 버그 수정: `baz()` 메서드 호출 시 부팅되지 않는 현상 (@컨트리뷰터 감사합니다!)
* 0.1.0
    * 첫 출시
    * 수정: `foo()` 메서드 네이밍을 `bar()`로 수정
* 0.0.1
    * 작업 진행 중

## 정보

이름 – [@트위터 주소](https://twitter.com/dbader_org) – 이메일주소@example.com

XYZ 라이센스를 준수하며 ``LICENSE``에서 자세한 정보를 확인할 수 있습니다.

[https://github.com/yourname/github-link

지금은 위 양식을 무조건적으로 따르진 않는다. 가령 라이브러리라면 설치 방법이 필수로 들어가야하지만 서비스라면 빠져도 되는 부분이다. 컨트리뷰션하기 위해서 설치를 해야한다면 별도의 문서로 작성하도록하여 왠만하면 필수적인 부분만 간추려서 예쁘게 만드는게 좋은 것 같다. 아주 개인적인 견해다.

필자는 이런식으로 Raven-Reader 스러운 느낌으로 작성하는 중이다. 이유는 예쁘기 때문이다!

깃

이 글이 도움이 되었나요?

신고하기