깃 기초(init/add/commit/status/tag/+커밋상세)

2021.09.14 (화)

깃을 시작한다.

깃 먼저 다져보고 차차 깃허브를 세심하게 어루만져보려고 한다.

일단, 깃은 아래 사이트에서 다운받으면 되는데

https://git-scm.com/

Git

깃을 다운받는 것은 적당히 생략하고,

 

다 받았으면

실행시키고 몇가지 커맨드를 입력해서 잘 받아졌는지만 확인하면 된다.

 

잘 되면

만들고 싶은 깃 저장소 위치를 정해서 $git init을 실행하면 된다.

(참고로

GUI에서 깃 저장소를 만들고 싶은 폴더에서 마우스 우클릭 해서

Git Bash Here 클릭하면 바로 해당위치에서 Git bash로 작업을 시작해서 할 수도 있다.)

 

$git init은 비어있는 저장소를 생성하는 커맨드다.

 

위 절차에 따라 아래와 같이 깃 저장소를 만들었고 두 파일을 먼저 생성했다.

 

이 파일들을 가지고 이제 첫 커밋을 해볼건데 그전에 깃에게 commit한 사람을 알려줘야 한다. 

그래야 나중에 협업하게 되면 누가 커밋을 했는지 알 수 있으니깐~

이름과 이메일을 알려주면 된다.

 

이제 커밋하면 된다. (앞으로 커밋할 때마다 나는 위와 같은 정보가 같이 올라가게 된다.)

이때 커밋메시지도 같이 입력해준다. 변동사항이 뭣이 있는지를 간략하게 알려주게 되는것이다.

 

근데 그전에! git add를 먼저 입력 해줘서 커밋할 파일을 미리 지정해줘야 한다.

add는 수정될 파일의 모습이 커밋에 포함될 것이라 지정하는 것이다.

$git add 파일명 을 입력해주면 된다.

 

이제 진짜 변동사항이 담긴 커밋메시지와 함께 커밋하면 된다.

$git commit -m "변동사항"

이때 root-commit은 첫번째 커밋이라는 의미

7 insertions(+)는 License와 calculator 내용이 담긴 라인 총 7줄이 추가 되었다는 의미

 

 

$git status 깃 상태확인으로 add 된 파일과 아닌 파일을 알 수 있다.

 

 

 

---

 

2021-09-30 (목)

git commit 내용 추가

위와 같이 $git commit -m "변동사항" 외에도

 

$git commit 만 입력할 수 있다.

이때에는 vim 커맨드 창이 뜨는데 여기서 커밋메시지를 잘 입력해주면 된다.

i 를 입력하면 insert모드로 전환

제목

(두줄enter)

커밋메시지

Esc를 입력, 모드전환후

:wq 누르고 enter하면 write, quit 되면서 자동 커밋이 된다.

 

https://git-scm.com/docs/git-commit#_discussion

Git - git-commit Documentation

깃 커밋할 때 깃에서 공식적으로 권장하는 사항이 몇가지 있으니 참고하면좋다.

<<커밋 메시지 가이드 라인>>

(1) 커밋 메시지의 제목과 상세 설명 사이에는 한 줄을 비워두세요.

(2) 커밋 메시지의 제목 뒤에 온점(.)을 붙이지 마세요.

(3) 커밋 메시지의 제목의 첫 번째 알파벳은 대문자로 작성하세요.

(4) 커밋 메시지의 제목은 명령조로 작성하세요.(Fix it / Fixed it / Fixes it)

(5) 커밋의 상세 내용에는 이런 걸 적으면 좋습니다.

• 왜 커밋을 했는지
• 어떤 문제가 있었고
• 적용한 해결책이 어떤 효과를 가지는지

(6) 다른 사람들이 자신의 코드를 바로 이해할 수 있다고 가정하지 말고 최대한 친절하게 작성하세요.

 

<<일반적인 커밋 가이드 라인>>

(1) 하나의 커밋에는 하나의 수정사항, 하나의 이슈(issue)를 해결한 내용만 남기도록 하세요. 다양하게 수정을 하고나서 하나의 커밋으로 남기는 것은 좋지 않습니다. 하나의 커밋이 하나의 사실만을 갖고 있어야 나중에 이해하기 쉽습니다. 

이 말은 결국 최대한 작은 단위의 변화를 기준으로 커밋을 하라는 뜻입니다. 예를 들어 여러분이 A라는 파일에서 기존 함수를 3개 삭제하고, B라는 파일에서 기존 함수 2개를 삭제, C라는 파일에서 기존 함수를 1개 삭제했다고 합시다. 그 다음 프로그램을 실행해봤는데 오류가 생겼다면 과연 A, B, C 파일 중 무엇때문에 문제가 생긴건지 일일이 확인해보지 않는 이상 알 수 없겠죠? 이처럼 다양한 종류의 수정을 다 하고나서야 커밋을 하면 바로 그 다음에 프로그램에 문제가 생겼을 때 그 원인을 파악하는데 시간이 더 오래 걸립니다. 그리고 이렇게 하면 커밋 간의 독립성이 사라져서 나중에 프로젝트의 이력을 파악하는 일도 어려워지기도 하죠.

하지만 어느 정도의 수정사항을 하나의 단위로 볼 것인지는 상황에 따라 조금씩 다를 수 있습니다. 회사의 규칙에 따라 다를 수도 있구요. 어찌 됐든 너무 많은 작업의 결과를 하나의 커밋으로 담지 않아야겠다는 생각을 하면서 커밋을 해야합니다.

(2) 현재 프로젝트 디렉토리의 상태가 그 내부의 전체 코드를 실행했을 때 에러가 발생하지 않는 상태인 경우에만 커밋을 하도록 하세요. 나중에 동료 개발자가 특정 커밋의 코드로 실행했을 때 에러가 발생한다면 혼란을 줄 수 있습니다.

커밋으로 보관된 특정 시점의 전체 코드는 항상 문제없이 실행되는 상태여야 합니다. 이미 과거의 커밋이 되어버렸다고 우리에게 쓸모없는 커밋이 되는 건 절대 아닙니다. 과거의 커밋이라도

• 과거 버전의 프로그램을 사용해야하거나
• 과거 커밋을 시작점으로 한 다른 방향의 별도 프로젝트를 시작하거나
• 아예 그 커밋으로 현재 프로젝트를 리셋할 수도 있습니다.

따라서 매 커밋의 코드들은 항상 정상 실행되는 상태의 코드여야 합니다. 그렇지 않으면 나중에 그 커밋을 위와 같은 용도로 사용하려고 할 때 문제가 생길 수 있습니다. 그리고 협업하는 상황을 생각해봐도 내가 남긴 커밋을 동료 개발자가 실행해봤는데 에러가 나고 실행이 되지 않는다면 좀 민망하겠죠? 따라서 커밋을 하기 전에 프로그램이 정상 실행되는지 점검하고 커밋하는 것이 좋습니다. 

자, 이때까지 커밋에 관한 가이드라인들을 살펴봤습니다. 사실 이런 가이드라인은 회사마다 다를 수 있고, 절대적인 규칙이 있는 것도 아닙니다. 어떤 경우든지 본인이 다니는 회사의 가이드라인을 잘 준수하는 것이 좋겠죠? 혹시 가이드라인이 없다고 할지라도

• 나중에 다시 봤을 때 이해하는데 어려움이 없도록
• 다른 동료 개발자와 협업하는 데 방해가 되지 않도록

커밋을 남기고, 그 때마다 커밋 메시지를 잘 작성하는 것이 중요합니다.

 

 

$git log 를 해서 커밋 히스토리를 보면 아래와 같이 잘 커밋 된 사항을 볼 수 있다.

 

 

++ 최신 커밋을 수정할 수 있다.

$git commit --amend

대신에 위처럼 커밋아이디도 변경된다.

 

 

++ 커밋을 비교하고 싶으면 비교하고 싶은 커밋아이디 1, 2를 입력하면 된다.

$git diff 커밋아이디1 커밋아이디2

ex) $git diff bee1 e515

빨간글씨는 이전 커밋의 모습, 초록글씨는 이후 커밋의 모습을 보여준다.

 

 

++ 커밋에 태그 달기

커밋 중에 다른 것들보다 좀더 중요한 의미가 있는 커밋들은 태그를 추가적으로 달기도 한다.

$git tag [태그이름] [커밋아이디]

위는 Version_1, 2를 각각 4146, 0729 커밋아이디에 달아주었고,

git tag로 모든 태그를 조회할 수 있다.

 

각 태그와 연결 된 커밋이 보고싶으면

$git show [태그명] 을 입력하면 된다.

 

태그 삭제는 -d 옵션을 달아주면 된다.

 

 

 

++

깃 공부에 도움 사이트!

https://backlog.com/git-tutorial/kr/reference/log.html

누구나 쉽게 이해할 수 있는 Git 입문~버전 관리를 완벽하게 이용해보자~ | Backlog