Git Tag란? Git Tag란 버저닝을 위해 사용하는 포인터이다. HEAD가 특정 커밋 해시를 가리키는 것 같이 Git Tag 또한 특정 커밋 해시를 가리킨다. *만약 HEAD에 대해 익숙하지 않으면 아래 글을 살펴보자. [Git] .git 내부에서 HEAD를 인식하는 방법 .git 내부에서 HEAD를 인식하는 방법 .git 내부에는 HEAD파일이 있다. 이 파일은 HEAD를 인식하기 위한 메타 데이터를 저장하는 파일이다. 작업 중인 브랜치에 따라 변하는 HEAD파일 HEAD 파일은 현재 kotlinworld.com 이번 글에서는 다음의 순서로 Git Tag에 대해 다룰 것이다. Git Tag 만들기 Git Tag 목록 조회하기 Git Tag 필터링하기 Git Tag간 차이 확인하기 Git Tag로 ..
분류 전체보기
interactive rebase 사용해 이전 커밋 조작하기 앞선글에서 git rebase를 이용해 rebase 대상 브랜치의 commit history를 새로 만드는 것을 살펴보았다. commit history를 새로 만들 수 있다는 것은 현재 시점 이전에 생긴 커밋들을 조작할 수 있다는 것이다. git rebase는 interaction 모드인 -i 옵션을 이용해 커밋 히스토리를 합칠 수 있는 기능을 제공한다. git을 사용하다 보면 이전 커밋들을 합치고 싶은 경우가 생기는데, 그 때 이 기능을 사용하면 된다. git rebase -i 를 사용해 커밋 메세지를 수정하기 위해서는 다음 명령어를 사용하면 된다. HEAD~n 은 HEAD 커밋으로부터 n 번째 까지의 커밋을 수정한다는 뜻이다. git reb..
Git Merge와 Git Rebase의 차이 git merge와 rebase는 모두 두 브랜치를 합치기 위한 명령어이다. 우리는 이곳에서 이 두 브랜치를 기준 브랜치와 대상 브랜치로 나눈다. 기준 브랜치는 master과 같이 기준이 되는 브랜치이고, 대상 브랜치는 feature 브랜치들과 같이 master에 합쳐져야 하는 브랜치이다. git merge와 git rebase가 다른 점은 두 브랜치의 커밋들을 합치기 위해 어떤 전략을 취하는지이다. 만약 기준 브랜치를 대상 브랜치에 merge한다고 하면(feature 브랜치에 master 브랜치를 merge), git merge는 기본적으로 merge를 하기 위해 대상 브랜치를 그대로 두고 기준 브랜치의 변경 사항(커밋)을 대상 브랜치에 얹으면서 합친다. ..
Branch를 보호하는 것이 중요한 이유 협업을 할 때 Rule이 없으면 각자 자신의 방식으로 일을 하게 되기 때문에 뒤죽박죽이 된다. 만약 인원이 적다면 별 문제가 되지 않지만, 실무에서는 적게는 3명 많게는 수십 수백명이 하나의 저장소를 관리하기 때문에 저장소를 관리하기 위한 Rule이 중요하다. 특히 Git의 Branch는 협업을 위한 기본 토대이기 때문에 최소한의 규칙을 정해야 협업 시의 혼란을 방지할 수 있다. GitHub의 Branch Protection Rules GitHub에서는 GitHub에 올라간 Branch들에 대한 Rule을 지정할 수 있게 해준다. 이 Rule을 이용하면 특정 브랜치가 실수로 지워지는 것을 방지하거나 PR(Pull Request)가 아닌 다른 방식으로 커밋을 추가하..
GitHub Pages란? GitHub에서 제공하는 정적 웹페이지(static webpage) 호스팅 서비스로, 포트폴리오 사이트 같은 간단한 사이트를 만드는데 활용된다. 요즘에는 이곳에 Jekyll 이라는 서비스를 결합해 블로그를 만드는 경우도 있다. 이 글에서는 정적 웹페이지를 이용해 간단히 사이트를 올리는 만드는 방법에 대해 알아볼 것이다. GitHub Page 만들 준비하기 GitHub Page를 만들기 위해서는 다음 두 작업을 먼저 해야한다. 템플릿 다운로드 하기 github 저장소 만들고 다운받은 템플릿 올리기 템플릿 다운로드 하기 이번 글에서는 https://html5up.net/ 에서 제공하는 photon이라는 템플릿을 활용해 실습을 진행한다. Photon은 CCA 3.0 license를 ..
