Commit
개발 중 뼈대 작성, 버그 수정, 기능 추가 등 변경사항에 대한 작업이력을 기록하는 것을 의미한다.
시간 순으로 저장되며 현재까지 진행된 작업 진행 상황을 파악하기에 용이하다.
좋은 Commit이란?
커밋 메세지만 봐도 이해가 쉽게
커밋에는 메모를 작성할 수 있으며, 명료하고 이해하기 쉽게 남기는 것이 좋다.
의미가 있는 업데이트를 작업사항 별로 구분하여 메모를 작성하면 이력만을 보고 변경 내용을 찾기 쉽다. 또한 다른 사람의 커밋 로그를 이해하고 확인하는 것이 빠르다.
더 쉬운 유지보수, 더 나은 협업과 리뷰, 더 좋은 가독성을 위한 것이다!
- commit을 쪼개서 작업하는 이유
결국 커밋도 사람이 읽기 쉽게 해야하는 것이다.
한번에 여러 수정사항이 있는 커밋보다 잘게 쪼갠 커밋이 각 역할을 하나하나 확인하기가 쉽다.
메세지만 보고도 어떤 파일들이 변경되었는지 추측이 가능해야한다.
- git add
작업의 변경내용을 "스테이징" 영역에 추가하는 명령어
그동안 42서울에서 과제를 제출하기 위해 습관마냥 git add . 명령어를 사용하여 한번에 모든 내용을 add하고 commit하고 간결하게 "update" 와 같은 메세지를 남겼다. 42 과제는 개인 과제였고, 파일명 = 과제명이었기 때문에 어떤 문제를 풀었는지가 명확해서 구분이 가능했다. 하지만 실제 팀원들과 프로젝트나 일을 할 경우 대체 뭘 update 했는지 일일히 확인해야하는 불편함이 생긴다.
긍까,,, 이제 아니까 쓰지말기,,, 명확한 뜻이 있는 commit 을 남기기!
- tip
커밋 메세지는 어떻게 변경하였는지 보다 무엇을, 왜 변경했는지를 간단히 적는 것이 좋다.
Convention
협업을 위해 일관성있게 작성하는 원칙과 규칙
가독성을 높이고 유지보수를 위한 공통의 약속으로 정하는 것이다.
commit convention
commit message에 대한 약속
커밋의 내용은 새 기능 추가, 버그 수정, 디자인의 변경, 리팩토링, 포맷 변경, 이름 변경 ... 등등등 다양한 수정사항들이 적히게 될 것이다. 함께 협업하는 사람들이 detail하게 메세지를 적어도 정해진 양식이나 규칙이 존재하지 않으면 가독성이 떨어질 것이다.
그렇기에 동일한 레이아웃으로 커밋을 작성하면 보기에도 편하고 찾기가 쉬울 것이다. 협업할 때 다른 동료가 무엇을 수정했는지를 파악하기 쉬울 것 같다. 또한 나중에는 배포 프로세스를 정할 수 있는 기준이 된다.
Commit type
Push
push의 역할
git commit
커밋은 로컬 저장소(clone 을 통해 내 컴퓨터에 복제된 원격 저장소의 복사본)에 변경 이력을 남기는 것이었다.
그렇기에 복사본에서 아무리 작업해도 본래의 원격 저장소는 변경사항을 알 수가 없기에 이 사항을 넘겨줘야하는데 그 때 사용하는 명령어가 바로 git push 이다!
git push <저장소명> <브랜치명>
푸시를 날려주면, 그 동안 로컬 저장소에서 작업했던 내용이 원격 저장소에 전송이 되는 것이다.
원격 저장소에 올리기 전에는 내 컴퓨터에서만 벌어지는 일이기 때문에 문제가 발생하지 않지만 원격 저장소에 올린 이후부터는 함부로 변경이력을 수정하면 문제가 발생할 수 있다. 동료와 동시에 코드 변경 이력을 업데이트하면
코드 충돌이 발생할 수 있기 때문이다 !
그렇기에 원격 저장소에 올린 코드는 덮어쓰지 않는 것이 원칙이다 ~,~
Branch
나무가지 ~,~
본 환경의 복사본(branch)를 만들어 독립적으로 작업을 진행하고 저장할 수 있는 작업환경
브랜치를 사용하는 이유
- 독립적으로 관리하기 위해서
- 안정적인 개발환경 유지 (기존의 안정적인 코드와 현재 작업중인 환경을 구분해서 관리가 가능함)
협업 과정에서의 Branch
- 메인 브랜치에는 직접 커밋하지 않으며 이는 동시에 하다 생길 수 있는 이슈들을 방지하기 위해서이다.
그렇기에 해당 브랜치에서의 개발이 끝난다면 이 브랜치에 작업 내용을 푸시하고 메인 브랜치와 병합한다.
브랜치 이동
git checkout <이동할 브랜치 이름>
브랜치 로그
git log
--graph : 브랜치의 흐름을 같이 출력
-- all : 모든 브랜치 로그 출력Pull Request (PR)
push 는 내 작업을 깃 서버에 올리는 것이었다면 pull은 반대로 깃 서버에 업데이트 된 내용을 받아오는 것이다. 즉 Pull request란 서버에 업데이트 된 내용을 받아와달라는 요청이다.
내 저장소에서 뭔가 작업 내용을 업데이트 했다고 가정 할 때 원본 저장소 관리자에게 요청을 한다고 생각하면 된다.
Main은 손댈 일이 없는 걸
로컬 저장소에서 브랜치를 만들어 작업한 commit을 메인 브랜치에 merge 한다.
배포가 될 메인에 아직 완전하지 않은 변경사항이 올라간다면 🤪🤯😱 !
메인에서 떨어진 곳에서 수정하고, 테스트하기 위해 브랜치가 있었다. 이때 혼자서는 브랜치에서 작업하고 메인에 병합하면 그만이었지만 만약 여러사람들과 함께 하고 있는 작업이라면? 동료들의 리뷰와 병합 여부에 대한 결정이 필요해질 것이다. 그렇기에 이 과정에서 pull request가 있는 것이다. pull request를 통해 내가 변경한 내용을 다른 사람들이 확인할 수 있고 승인할지 변경을 요청할지 결정 할 수 있다.
세세하게, 알아볼 수 있도록!
PR 역시 제목에는 커밋과 같이 작업한 내용을 컨벤션에 따라 함축적으로 작성한다!
그리고 PR은 이에 대한 설명을 적을 수 있는데 제목에는 적지 못한 구체적인 내용과 사항, 자료 등을 넣어 리뷰하는 동료가 이해할 수 있도록 작성한다.
병합하기!
기엽담
