커밋 개념 자체를 모른다면 아래 링크로 가 공부를 먼저 하는 것을 추천한다.
여기선 이미 커밋에 대한 개념은 어느 정도 알고 있다는 가정 하에 IntelliJ에서 커밋 하는 법에 대해 배우려 한다.
IntelliJ에서 커밋 하기
0. 파일 2~3개 변경하기
커밋을 확실히 공부하기 위하여 여러 개의 파일을 동시에 변경시켜보자.
1. Git > Commit 선택
Commit 창 설명
파일 리스트 칸
여기엔 git add 할 수 있는 파일들이 리스트화되어 있다.
git add 할 수 있는 파일들이라 하니 감이 안 올 수 있는데, Staging Area에 등록되어 있는 파일과 내용이 다른 파일들이라고 보면 이해가 편할 것이다.
필자는 총 3개의 파일(README.md, AdminController, HomeApplicatioin)을 수정하였는데 수정한 파일이 모두 리스트에 등록되어 있음을 확인할 수 있다.
파일이 추가되는 경우는 따로 생각할 필요가 있다.
이전에 말했듯, 일단 Staging Area에 파일이 한 번이라도 등록되어야지만 Git에서 관리가 가능해진다.
반대로 Staging Area에 등록되지 않은 신규 파일은 Git 시스템에서 관리할 수 없다.
그래서 IntelliJ에서는 신규 파일을 생성할 때마다 "신규 파일을 git add 시킬 것인가요?"라고 물어본다.
여기서 Add 버튼을 클릭했다면 문제없이 Git을 활용할 수 있지만 실수로 Cancel을 눌렀다면 아래 사진과 같이 빨간색 이름을 가지게 된다.
IntelliJ에서 파란색 파일은 변경된 파일(커밋 가능한 파일), 흰색 파일은 Staging Area 파일과 동일한 형태의 파일, 빨간색 파일은 Staging Area에 등록되지 않은 파일을 의미한다.
(노란색으로 .gitignore에 등록된 파일을 표시하기도 하지만 이는 일단 무시하자)
이렇게 빨간색 파일을 Staging Area에 등록시키고 싶다면 파일을 마우스 오른쪽 클릭하여 Git > Add을 클릭하면 된다.
Commit Message칸
커밋을 시킬 때 커밋을 설명하는 메시지를 달 수 있는 공간이다.
아래서도 강조하겠지만 꼭 커밋 메시지는 커밋을 대표할 수 있도록 자세히 써놓자.
Commit Checks
생각보다 현업에서 많이 활용되는 것 같다.
IntelliJ Format에서는 Code Format을 설정할 수 있는데 Reformat code, Rearange code를 선택해 놓으면 Code Format에 맞도록 코드를 수정한 뒤 커밋 시켜준다.
Optimize imports는 사용하지 않는 import문을 지워준다.
기본적으로 체크되어 있는 Analyze Code는 코드를 분석해 주지만 큰 의미는 없고, Check TODO는 TODO가 있으면 이를 알림으로 알려주지만 코드를 보다 보면 아무 의미 없이 TODO를 쓰는 경우도 있어 큰 의미가 없다.
따라서 이 2개는 체크 버튼을 풀고 커밋 하는 것을 추천한다.
Diff
왼쪽에 있는 파일이 Staging Area에 등록되어 있는 파일, 오른쪽에 있는 파일이 현재 Working Directory에 존재하고 있는 파일이다.
두 파일을 비교하여 어떤 부분에 차이가 존재하는지 설명해 준다.
파일명을 더블 클릭하면 더 큰 창에서 파일의 변경점을 확인할 수 있다.
2. 커밋 하고 싶은 파일들만 선택 & 커밋 메시지 기록
IntelliJ에선 git add에 대한 과정이 따로 존재하지 않는다.
단순히 커밋 창에서 체크 표시한 파일들은 모두 git add로 Staging Area에 등록시킨 다음 바로 커밋 시켜버린다.
따라서, 이번 단계에서 커밋 하기 원하는 파일들만 선택한 후 커밋 메시지를 달아주면 된다.
이전에 말했듯, 커밋 메시지는 구체적으로 입력하는 것이 좋다.
협업을 위해선 특정 커밋이 어떤 이유로 발생한 것인지 알아야 하고, 이를 나타내기 위한 가장 좋은 방법이 커밋 메시지이기 때문이다.
그래서 현업에 가면 커밋 메시지에 대한 Ground Rule이 있는 경우도 많다.
마지막으로 git status를 통해 확인해 보면 2개 파일에 대한 커밋이 하나 생성되었고, 커밋 하지 않은 1개 파일은 Staging 되지 않았다고 알리고 있다.
부록 : 왜 저는 위 사진과 다른 형태의 커밋 창이 뜨죠?
아마 이런 식으로 커밋 창이 새 창이 아닌 Non-modal 창으로 뜨는 사람도 있을 것이다.
이는 IntelliJ 설정 때문에 그렇다.
만약 새 창으로 띄우고 싶다면 File > Settings를 선택 후 "Commit"을 검색한 뒤 "Use non-modal commit interface" 체크를 해제해 주면 된다.
어떤 식이든 상관없지만 필자는 새 창으로 띄우는 게 편해서 체크를 해제해 주었다.
원격 저장소에 푸시 하기
커밋에 대해 잘 공부했다면 우리가 위에 한 과정이 "로컬 저장소에 커밋"이라는 것을 알 것이다.
협업을 위해선 최종적으로 로컬 저장소 커밋을 원격 저장소에 Push할 필요가 있다.
이제 IntelliJ에서 커밋을 원격 저장소로 푸시 하는 방법을 알아보자.
0. Git 창 열어보기
Push 하기 전 IntelliJ의 Git 창을 열어보자.
그럼 최신 커밋에는 "main"이라는 꼬리표가, 그 이전 커밋에는 "origin/main"이라는 꼬리표가 붙어 있다.
이는 어떤 것을 의미할까?
이 꼬리표는 브랜치가 가리키는 현재 버전 상태(커밋)에 붙어 있는 것이다.
즉, "main" 브랜치의 현재 커밋은 "feat: IntelliJ에서의 최초 커밋" 메시지를 가진 커밋이고 "origin/main" 브랜치의 현재 커밋은 "Update README.md"인 것이다.
그렇다면, "main"과 "origin/main"의 차이가 무엇일까?
origin 하면 무엇이 생각나는가?
만약 당신이 원격 저장소를 떠올렸다면 공부를 잘 한 것이다.
그렇다. Git에서는 대부분 원격 저장소 이름을 "origin"이라고 명시한다.
즉, "main"은 "로컬 저장소의 main 브랜치"를 의미하며 "origin/main"은 "원격 저장소의 main 브랜치"를 의미하는 것이다.
1. Git > Push 선택
2. 커밋 확인 & Push
창을 보면 지금까지 로컬 저장소에 커밋 했던 내용들이 나올 것이다.
이들을 확인한 뒤 커밋들을 Push 해도 된다면 Push 버튼을 눌러주자.
3. 원격 저장소 확인
원격 저장소에 "IntelliJ에서 테스트해봅시다!"라는 문구가 추가되었음을 알 수 있다.
원격 저장소에 Push도 했으니 이젠 원격 저장소의 현재 커밋과 로컬 저장소의 현재 커밋이 동일할 것이다.
실제로 그럴지 IntelliJ Git 창에서 다시 확인해 보자.
origin & main의 꼬리표가 모두 "feat: IntelliJ 에서의 최초 커밋" 메시지의 커밋에 붙어있다.
즉, 현재 커밋이 동일함을 볼 수 있다.
