Git - 2. 개인 프로젝트를 위한 Git 사용법

서론

---

이전의 git 기본 사용법에 이어서, 이번에는 혼자서 프로젝트를 진행할 때의 git 사용법을 간단하게 정리해보고자 합니다.

 

혼자서 하는 프로젝트이므로, 굳이 다른 브렌치를 나누어서 할 필요는 없지만, 간단하게 main, dev, topic정도의 브렌치를 구현해서 사용해보도록 해보겠습니다.

 

 

 

 

 

 

 

 

repository 생성, 연동

---

 

 

제 깃허브에 연습용 Repository를 생성했습니다. 위와같이 README.md도 생성해 주었습니다. 

repository를 생성할 때는, 아무파일도 없으므로 해당 공간이 저장소라는.. 한마디로 "git init"만 되어진 상태입니다. 하지만 위처럼 README.md파일을 생성해주면, 해당 파일이 add, commit된 상태가 되어서 main브렌치가 생성이 됩니다.  그러니 repository를 새로 생성했을 때 README.md파일을 생성해주는 것이 좋습니다.

 

 

 

 

 

git clone {git 주소}

이후 제가 개발하기 원하는 경로에 "git clone"을 해주었습니다. 

 

 

 

 

 

 

 

위에서 말했듯, READMD.md파일을 만들었으므로 main 브렌치가 생성되어, clone후 해당 경로에 들어가면 main브렌치에 들어와 있는 것을 확인해볼 수 있습니다.

 

 

 

 

 

 

 

 

 

브렌치 생성 및 머지

---

 

git checkout -b dev
git checkout -b setting_topic

하지만 main에서 개발을 진행하면 안됩니다. main은 완성된 코드만이 담길 브렌치로 남겨놓겠습니다.

개발한 내용들을 통합할 dev, 그리고 세팅내용을 진행할 setting_topic이라는 브렌치들을 생성해줍니다. 

 

 

 

 

 

touch 환경설정.txt
git add .
git commit -m "환경설정 완료"

현재 setting_topic이라는 브렌치를 만들었으므로 해당 브렌치에 위치되어 있을겁니다.

여기서 환경설정이라는 txt파일을 만들고, add, commit 해줍니다. 

 

 

 

 

git checkout dev
git merge --no-ff setting_topic

세팅파일의 작업을 다 끝냈다고 치고, 이제 dev로 와서 개발한 내용을 합쳐주겠습니다. 

여기서 "git merge {브렌치이름}"을 통해서 브렌치를 합칠 수 있지만, 그냥 merge를 하면, fast-forward merge가 되면서 setting_topic에서 진행한 커밋들이 추가되지 않고 머지가 진행되어 버립니다. 한마디로, setting_topic에서 진행한 "환경설정 완료"라는 내역의 커밋은 dev로 합쳐지면서 사라지게 됩니다. 

이런 커밋 로그 기록들은 중요합니다. 그러므로 merge에서 --no-ff 라는 옵션을 이용해서 fast-forward merge라도 로그를 남기도록 해줍니다. 

해당 명령어를 쓰면 vi창이 뜰텐데, esc > :wq 를 쳐서 저장 후 나와줍니다.

 

 

 

 

 

 

 

git log

git log명령어를 통해 로그들을 살펴보면, dev에 merge한 기록과 "환경설정 완료"라는 커밋이 남아있는 것을 확인해볼 수 있습니다.

 

 

 

 

git checkout -b join_topic
touch 회원가입.txt
git add .
git commit -m "2. 회원가입 완료"
git checkout dev
git merge --no-ff join_topic

회원가입을 개발하기 위해 join_topic이라는 브렌치를 만들어줍니다. 방금 dev에서 진행하고 있었으므로, dev에서 checkout을 생성하면 setting_topic이 합쳐진 내용으로 새로운 브렌치임 join_topic이 생성됩니다. 여기서도 위에서 했던 작업을 해줍니다.

 

 

 

 

 

 

 

 

 

커밋 합치기 (rebase)

---

 

 

git checkout -b write_topic
touch 글쓰기.txt
git add .
git commit -m "글쓰기 끝남. DB 연결 아직 안됨"


git add .
git commit -m "글쓰기 진짜 끝남"

하지만 이번에는 만약 write_topic에서 작성하다가, 오늘 일을 다 못끝내고 퇴근하는 상황입니다.

그럼 일단 add, commit을 합니다.  그리고 다음날 다시와서 완성했다고 생각해봅시다.

 

그러면 위처럼 로그가 남을텐데, dev와 머지를 할때 이렇게 쓸데없는 내용의 로그들이 많으면 지저분합니다.  그러므로 rebase라는 명령어를 통해서 commit들을 합쳐줄겁니다.

 

 

 

 

 

git rebase -i HEAD~2

git rebase 명령어를 사용합니다. 

i 옵션은 인터랙티브 모드로 실행하겠다는 옵션입니다. 이 모드에서는 재배치할 커밋들에 대한 명령어를 선택적으로 입력할 수 있습니다. HEAD~2 옵션으로 가장최근의 커밋 2개에 대해 작업을 진행합니다.

해당 명령어를 치면 위처럼 vi에디터 창이 뜰텐데, 여기서 s는 Squash로 다른 commit에 합쳐진다는 의미이며 pick은 해당 commit을 사용한다는 의미입니다. 한마디로 "글쓰기 끝남. DB 연결 아직 안됨" 이라는 commit을 "글쓰기 진짜 끝남" 이라는 commit에 합쳐집니다.

 

저장하고 나와줍니다.

 

 

이후에 또 창이 하나가 더 뜰텐데, 남길 커밋을 정합니다. 저는 "글쓰기 진짜 끝남"이라는 commit만 남길거라, 위에 "DB연결 안됨" 이라는 커밋은 지워버리겠습니다. 

 

 

 

 

 

 

저장하고 나온 다음, 위처럼 log를 찍어보면 커밋이 하나로 합쳐진 것을 확인할 수 있습니다. 

 

 

git checkout dev
git merge --no-ff write_topic

dev에 머지해 준 후에도 dev에서도 해당 로그를 확인해 볼 수 있었습니다. 

 

 

 

 

 

 

 

 

 

 

 

깃허브에 올리기(push, tags)

---

 

 

git checkout main
git merge --no-ff dev

 

최종적으로 main브렌치에 가서 dev를 머지해서 합쳐줍니다.

 

 

 

git tag blog1.0.0

추가적으로 tag 라는 명령어로 main브렌치에 내용들에 blog1.0.0이라는 이름의 태그를 붙여줍니다.

 

그럼 위처럼 log에서도 태그를 확인해볼 수 있습니다.

 

 

 

 

 

git tag -n

 

git tag -n 명령어로 확인해보면, 마지막으로 dev에서 merge한 내용이 있는데, blog1.0.0이라는 태그의 제품으로 되었다고 볼 수 있습니다.

 

 

 

 

 

git push --tags origin main

그럼 이제 main을 태그와 함께 push해줍니다.

 

 

그럼 위처럼 깃허브에 업로드가 되고 tag라는 부분이 추가가 되는데,

 

여기에 들어가서 해당 태그 버전의 코드들이 뭉쳐있는 zip을 다운받을 수도 있고,

 

해당 버전의 업로드 내용만 이렇게 따로 볼 수도 있다.

 

 

 

 

커밋 또한 잘 올라온 것을 확인할 수 있다.