FE가 되고싶니? 나도✨

** 커밋 아이디는 앞에 4자리 까지만 입력해줘도 괜찮다.
** HEAD  : 어떤 커밋 하나를 가리킨다. 보통 가장 최근에 한 커밋을 가리키고, 매번 더 새로운 커밋을 가리킨다.
** working directory는 HEAD가 가리키는 커밋에 다라 다르게 구성된다.
** HEAD가 최신 커밋보다 더 이전의 커밋을 가리키면 working directory의 내부도 과거 커밋의 모습대로 바뀌게 된다.
**staging area에 있던 것들은 커밋을 하더라도 그것과 상관없이 계속 남아있다.
** --hard 옵션은 별로 권장되진 않는다. 커밋 이후 워킹 디렉토리에서 했던 내용들이 다 사라지고 복구를 할 수 없기 때문이다.

커밋(commit)은 Git에서 가장 핵심적인 개념이다. 커밋은 staging area의 현 상태를 그대로 하나의 버전으로 남기는 작업, 또는 그 결과물을 가리킨다.

커밋에는 크게 다음과 같은 3가지 정보가 있다.

(1) 커밋을 한 사용자 아이디
(2) 커밋한 날짜, 시간
(3) 커밋 메시지

특정 프로젝트 디렉토리가 어떻게 변해왔는지를 한 눈에 잘 파악하기 위해서는 커밋의 이런 정보들이 아주 중요하다. 그런데 (1), (2)는 커밋을 할 때 Git에서 자동으로 기록해주지만, (3) 커밋 메시지는 커밋을 하는 사람이 매번 직접 작성하는 것이기 때문에 사람마다 그 분량이나 스타일이 제각각일 수 있다.

개인 프로젝트의 경우에는 커밋 메시지를 어떻게 작성하든 큰 상관이 없을 수 있지만, 회사에서 여러 명이 참여하는 프로젝트의 경우에는 이 커밋 메시지가 아주 중요하다. 그래서 커밋 메시지를 어떻게 작성해야하는지에 대한 규칙이 정해져있는 경우가 많은데,
그 규칙들은 회사마다 전부 다르다. 그래서 커밋 메시지를 어떻게 작성하면 좋은지에 대한 일반적인 가이드라인이 있다.

1. 커밋 메시지 작성 가이드 라인

• 커밋 메시지의 제목과 상세 설명 사이에는 한 줄을 비워두기. (git에서 공식적으로 권장하는 사항)
• 커밋 메시지의 제목 뒤에 온점(.)을 붙이지 말자.
• 커밋 메시지의 제목의 첫 번째 알파벳은 대문자로 작성해라.
• 커밋 메시지의 제목은 명령조로 작성해라.(Fix it / Fixed it / Fixes it)
• 커밋의 상세 내용에는 [①왜 커밋을 했는지 ②어떤 문제가 있었는지 ③적용한 해결책이 어떤 효과를 가져오는지] 를 적으면 좋다.
• 다른 사람들이 자신의 코드를 바로 이해할 수 있다고 가정하지 말고 최대한 친절하게 적어라.

2. 커밋할 때 알아야할 가이드라인

(1) 하나의 커밋에는 하나의 수정사항, 하나의 이슈(issue)를 해결한 내용만 남기도록 한다.

다양하게 수정을 하고나서 하나의 커밋으로 남기는 것은 좋지 않다. 하나의 커밋이 하나의 사실만을 갖고 있어야 나중에 이해하기 쉽다. 이 말은 결국 최대한 작은 단위의 변화를 기준으로 커밋을 하라는 뜻이다.
어느 정도의 수정사항을 하나의 단위로 볼 것인지는 상황에 따라 조금씩 다를 수 있고, 회사의 규칙에 따라 다를 수도 있다. 어찌 됐든 너무 많은 작업의 결과를 하나의 커밋으로 담지 않아야겠다는 생각을 하면서 커밋을 해야한다.

(2) 현재 프로젝트 디렉토리의 상태가 그 내부의 전체 코드를 실행했을 때 에러가 발생하지 않는 상태인 경우에만 커밋을 하도록 하자. 

커밋으로 보관된 특정 시점의 전체 코드는 항상 문제없이 실행되는 상태여야 한다. 이미 과거의 커밋이 되어버렸다고 우리에게 쓸모없는 커밋이 되는 건 절대 아니기 때문에 과거의 커밋이라도 ①과거 버전의 프로그램을 사용해야하거나 ②과거 커밋을 시작점으로 한 다른 방향의 별도 프로젝트를 시작하거나 ③아예 그 커밋으로 현재 프로젝트를 리셋할 수도 있다.

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

혹시 가이드라인이 없다고 할지라도 나중에 다시 봤을 때 이해하는데 어려움이 없도록, 다른 동료 개발자와 협업하는 데 방해가 되지 않도록 커밋을 남기고, 그때마다 커밋 메시지를 잘 작성하는 것이 중요하다.

$ git push
$ git pull

로컬 레포지토리와 똑같은 내용의 리모트 레포지토리를 사용하는 이유?

1. 안전성

• 개인 컴퓨터를 분실하거나 문제가 생겼을 때 복원 할 방법이 없다.
• 이 때 리모트 레포지토리의 내용을 다른 컴퓨터에서 가져오기만 하면 작성하던 내용을 다시 사용할 수 있다.

2. 협업 가능

• 리모트 레포지토리를 가운데 두고 push와 pull을 이용해 새로운 커밋을 계속 만들어 낼 수 있어 여러 개발자와 협업이 가능해진다.

원칙적으로는 자신의 리모트 레포지토리는 자신만 git push를 할 수 있는데 만약 다른 사용자도 git push를 할 수 있게 해주려면 그 사용자를 해당 리모트 레포지토리의 collaborator로 지정해야한다.

git push -u origin master : 로컬 레포지토리의 내용을 처음으로 리모트 레포지토리에 올릴 때 사용
git push : 로컬 레포지토리의 내용을 리모트 레포지토리에 보내기
git pull : 리모트 레포지토리의 내용을 로컬 레포지토리로 가져오기
git clone [프로젝트의 GitHub 상 주소] : GitHub에 있는 프로젝트를 내 컴퓨터로 가져오기

staged 상태

파일의 내용이 수정되고 나서 staging area에 올라와 있는 상태. (스테이징 된. stage area에 올려진)

• 새로 생성한 파일에 내용을 쓰고 git add를 해줌
• 한 번이라도 커밋에 포함 됐었던 파일이라도 내용을 수정하고 git add를 해줌

Unmodified 상태

현재 파일의 내용이 최신 커밋의 모습과 비교했을 때 바뀐게 전혀 없는 상태. (수정되지 않은, 변한게 없는) 커밋을 한 직후에 working directory 안에 모든 파일들의 이 상태이다.

Modified 상태

최신 커밋의 모습과 비교했을 때 조금이라도 바뀐 내용이 있는 상태면 그 파일은 modified(수정된) 상태이다.

• Add the file : untracked 상태의 파일을 처음으로 git add 해주면 staged 상태가 된다.
• Edit the file : 최신 커밋과 비교했을 때 차이가 없는 Unmodified 상태의 파일 내용을 수정하면 Modified 상태가 된다.
• Stage the file : Modified 상태의 파일을 git add 해주면 staged 상태가 된다.
• Remove the file : 파일을 삭제하면 당연히 git에서 더 이상 인식하지 못한다.
• Commit : 커밋을 하면 staging area에 있던 파일들이 커밋에 반영되고, 모든 파일들은 최신 커밋과 차이가 없게 되니 Unmodified 상태가 된다.

+여담

• git help
• man git-

위의 커맨드들을 사용하면 커맨드의 사용법(공식 매뉴얼)에 대해서 알 수 있다. 공식 매뉴얼 화면에서 나갈 땐 q 를 눌러 나갈 수 있다.

$ git help add
$ man git-add

커밋(commit)

프로젝트 디렉토리의 특정 모습을 하나의 버전으로 남기는 행위 & 결과물

레포지토리(repository)

커밋이 저장되는 곳

레포지토리 만들기

$ git init

.git이라는 디렉토리가 생긴걸 확인 할 수 있는데 이게 바로 레포지토리이다. 여기서 git이 어떤 복잡한 작업을 함으로써 버전관리를 할 수 있다.

커밋하기

처음 커밋을 할 때엔 꼭 해야하는 것이 있다. 깃에게 commit한 사람을 알려주는 것이다. 그래야 나중에 누가 커밋햇는지 알 수 있다.

$ git config user.name "사용자 이름"

$ git config user.email "사용자 이메일주소"

$ git add 파일이름

$ git commit -m "남길 메세지"

• config : 설정하다, 구성하다.
• commit : 행하다, 기록하다.

+여담

git은 내부적으로 크게 3가지 종류의 작업 영역을 두고 동작한다.

1. working directory = working tree
2. staging area = index
3. repository

첫번째 작업 영역인 working directory는 작업을 하는 프로젝트 디렉토리를 말한다. 위에 상황에선 MathTool 디렉토리가 working directory가 된다.

두번째 작업 영역인 staging area는 git add를 한 파일들이 존재하는 영역이다. 커밋을 하게 되면 staging area에 있는 파일들만 커밋에 반영된다.

세번째 작업 영역인 repository는 working directory의 변경 이력들이 저장되어 있는 영역이다. 커밋들이 저장되는 영역이라는 뜻인데 풀어서 이야기 해보면

• working direcrory에서 무언가 작업을 하고,
• 작업한 파일들을 git add 해주고,
• 커밋을 하면 staging area에 있던 파일들의 모습이 마치 영화의 한 장면, 스냅샷(snapshot)처럼 이 repository에 저장된다.

1. working directory에서 A.txt 파일과 B.txt 파일을 작성하고
2. git add A.txt와 git add B.txt를 실행해서 A.txt, B.txt 둘다 staging area에 올렸다.
3. 그 다음 git commit -m "Ver_1"를 실행해서 staging area에 있는 파일들을 가져와 커밋으로 남겼다.

1. working directory에서 A.txt 파일 내용에 Python~ 이라는 단어를 추가, B.txt 파일 내용에 Morning이라는 단어를 추가
2. 그런데 이번에는 git add B.txt만 실행해서 B.txt파일만 staging area에 올렸다
3. 그 다음 git commit -m "Ver_2"로 두번째 커밋을 했다.

이전 그림과 다른 점은 A.txt는 staging area에 올리지 않고 B.txt만 staging area에 올렸다는 점인데 지금 레포지토리의 결과는

• A.txt는 staging area에 있던 모습, 수정하기 이전의 모습이 Ver_2에 반영
• B.txt는 staging area에 있던 모습, 하지만 A.txt와는 달리 수정한 이후의 모습이 Ver_2 커밋에 반영되었다.

A와 B 둘 다 working directory에서 수정했다는 사실은 같지만, staging area에 올렸는지 여부에 따라 그 최신 모습이 커밋에 반영되는지 달라지는 것이다. 

복사, 붙여넣기

cp(copy) 커맨드는 아규먼트로 파일이나 디렉토리 경로 두 개를 받는다.

첫번째 아규먼트는 복사할 대상의 경로, 두번째 아규먼트는 복사할 위치이다.

여기서 두번째 아규먼트 이미 존재할 경우 그 안으로 복사, 아니라면 두번째 아규먼트 이름을 가진 파일 또는 디렉토리가 생성된다.

• cp [원본 파일 이름] [옮길 파일 이름]
• cp [원본 파일 위치/원본 파일 이름] [옮길 파일 위치/옮길 파일 이름]
• cp [원본 파일 이름] [옮길 파일 위치]
• cp -r [디렉토리명] [옮길 파일 위치]

동일 디렉토리 안에서 파일 복사하기

reports $ ls /* reports 디렉토리가 현재위치, 리스트를 보여줘 */
Aug  Jul  Oct  Sep

$ cd Jul /* Jul 디렉토리로 이동 */
$ ls /* 리스트 보여줘 */
finances.txt  performance.txt

$ cat finances.txt /* finance 파일 내용 보여줘 */
2024 Jul Finance Report%
$ cat performance.txt /* performance 파일 내용 보여줘 */
2024 Jul Performance Report% 

$ cp finances.txt finances2.txt
/* cp = 복사하겠다. finances파일을 finances2 라는 이름으로 */

$ ls /* 리스트를 확인해보니 복사가 잘 되어있다. */
finances.txt  finances2.txt  performance.txt

$cat finances2.txt /* finances2 파일의 내용을 살펴보자 */
2024 Jul Finance Report%

다른 디렉토리로 파일 복사하기

/* Jul 디렉토리 안에 있는 상태에서 Aug로 파일을 복사해보자. */

Jul $ ls ../Aug
finances.txt  performance.txt

cp 커맨드는 mv 커맨드와 비슷하게 목적지에 똑같은 이름의 파일이 있으면 덮어쓴다. 덮어쓰기를 방지하고 싶다면 이 때도 i 옵션을 사용하면 된다.

Jul $ cp -i finances.txt ../Aug
/* Jul 안에 있는 finances 파일을 Aug 디렉토리로 복사하라는 의미 */
overwrite ../Aug/finances.txt? (y/n [n])?
/* 파일을 덮어쓸 것인지 묻는다. */

디렉토리 복사하기

Jul $ cd .. /* Jul 디렉토리에서 부모 디렉토리로 이동 */
reports $ ls
Aug  Jul  Oct  Sep
$ cp Jul Jul_copy /* Jul 디렉토리를 Jul_copy로 복사하기 */
cp: Jul is a directory (not copied)
/* 복사가 되지 않는다는 멘트가 출력된다. */

디렉토리를 복사할 땐 r(recursive)옵션을 사용해야 한다.

$ cp -r Jul Jul_copy
$ ls
Aug  Jul  Jul_copy  Oct  Sep

삭제

rm(remove)커맨드는 삭제할 파일 또는 디렉토리 경로를 아규먼트로 받는데 경로를 여러개 줄 수 있다.

• rm [지울 파일 이름]
• rm -r [지울 디렉토리명]

파일 지우기

$ ls
reports  warning
$ cd warning
$ ls
test1.txt  test2.txt

$ rm test1.txt
$ ls
text2.txt

디렉토리 지우기

warning $ cd ..
$ ls
reports  warning

$ rm warning
rm: warning: is a directory
/* 디렉토리를 지우려고 하니 오류가 발생한다. */

복사 할 때와 마찬가지로 디렉토리를 지울 때는 r 옵션을 사용해야 한다.

$ rm -r warning
$ ls
reports

mv나 cp는 목적지에 똑같은 이름을 가진 파일이나 디렉토리가 있으면 그걸 덮어쓰기 때문에 덮어쓰기 전에 확인을 하기 위해서 i 옵션을 사용했다. rm에도 i 옵션이 있는데 각 파일을 지우기 전에 확실히 지울것인지를 물어본다.

$ cd reports
$ ls
Aug  Jul  Jul_copy  Oct  Sep

$ rm -ri Jul_copy
/* 확실히 지울건지 묻는 i 옵션과, 디렉토리를 지우기 위한 r 옵션을 같이 사용했다. */
examine files in directory Jul_copy? y
/* Jul_copy 안에 있는 파일들을 하나씩 살펴볼건지 묻는다. yes를 하고 살펴보면 */

remove Jul_copy/finance2.txt? y
/* 각 파일을 지울것인지 묻는다. */
remove Jul_copy/performance.txt? y
remove Jul_copy/finance.txt? y
remove Jul_copy? y /* 디렉토리 자체를 지울건지도 묻는다. */

$ ls
Aug  Jul  Oct  Sep

디렉토리를 지울 때는 안에 뭐가 있는지 알고 지우기 때문에 i옵션이 그렇게 유용하지는 않지만 파일 하나씩 확인하며 지우고 싶다면 i 옵션을 사용할 수 있다. 반대로 파일을 지울것인지 확인하지 않고 바로 지우는 f옵션도 있다. 예를들어 읽기 전용 파일을 지울 때는 보통 이 파일을 지울 것인지 물어보는데 f옵션을 사용하면 물어보지 않고 바로 지운다.

그래서 특히 디렉토리를 지울 때는 rm -rf path/to/dir 등 r과 f 옵션을 같이 쓰는 경우가 많다.

mv 커맨드는 아규먼트로 파일이나 디렉토리 경로 두 개를 받는다.

첫번째 경로는 작업할 대상의 경로, 두번째 경로는 이동할 목적지 또는 변경할 이름이다.

여기서 두번째 경로가 이미 존재하는 디렉토리의 경로일 경우 디렉토리 안으로 이동되고 그렇지 않으면 이름이 변경된다.

• mv [원본 파일 이름] [바뀔 파일 이름]
• mv [원본 디렉토리 이름] [바뀔 디렉토리 이름]
• mv [이동할 디렉토리 이름] [이동할 디렉토리가 도착할 디렉토리 이름]
• mv [옮길 디렉토리의 부모 디렉토리/옮기고자 하는 디렉토리] [옮기는 위치]
•  

이미 존재하는 파일의 이름 바꾸기

reports $ ls
Jul  Aug  Sep

$ cd Sep /* sep 디렉토리로 이동 */
$ ls /* Sep 디렉토리의 리스트 확인 */
finances.txt    performane.txt

/* performane.txt를 performane2.txt 파일로 변경해주자 */
$ mv performane.txt performane2.txt 
/* performane.txt = 작업할 대상, performane2.txt = 변경할 이름 */

$ ls 
finances.txt    performane2.txt

이미 존재하는 디렉토리의 이름 바꾸기

Sep $ cd ..
/* 한단계 위에 있는 부모 디렉토리로 이동 */
$ ls
/* 부모 디렉토리로 이동한 뒤 리스트 확인 */
Jul  Aug  Sep

$ mv Sep Oct
/* 이미 있는 Sep이라는 디렉토리를 Oct로 이름 변경 */
$ ls
Jul  Aug  Oct

디렉토리 옮기기

$ mv Jul Aug
/* Jul 디렉토리를 Aug 디렉토리 안으로 이동한다는 뜻 */
$ ls
Aug  Oct

$ ls Aug
Jul  finance.txt  performance.txt

옮긴 디렉토리 다시 꺼내오기

$ ls
Aug  Oct

$ ls Aug
Jul  finance.txt  performance.txt

$mv Aug/Jul .
/* Aug디렉토리 안에 있는 Jul디렉토리를 .(현재위치)로 옮기겠다 */

$ ls
Aug  Jul  Oct

$ ls Aug
finance.txt  performance.txt /* Jul 디렉토리 사라짐 */

+주의사항

mv 커맨드는 똑같은 이름의 파일이 목적지에 있을 경우 아.묻.따 덮어쓴다.

$ ls
reports  warning

$ cd warning
/* warning 디렉토리로 이동 */

warning $ ls /* 리스트 확인 */
test1.txt  test2.txt

$ cat test1.txt /* test1.txt 파일의 안을 전체 다 보여줘 */
test file 1%
$ cat test2.txt
test file 2%

$ mv test1.txt test2.txt
/*test1 파일을 test2 파일에 덮어쓴다.*/

$ ls
tset2.txt

$ cat test2.txt
test file 1%
/* tset1의 파일이 덮어써지면서 안에 test2에 있던 내용이 test1의 내용으로 덮어써졌다. */

이런 현상을 방지하고 싶다면 i(interactive)옵션을 활용하면 된다. 만약 충돌이 있으면 사용자에게 어떻게 할 것인지를 묻는 것.

$ touch test1.txt /* test1 파일 생성 */
$ ls /* 리스트 확인 */
test1.txt  test2.txt

$ mv -i test1.txt test2.txt /* i 옵션을 사용해서 mv 커맨드 사용 */
overwrite test2.txt? (y/n [n])
/* 파일을 덮어쓸 것인지 묻는 멘트가 출력 덮어쓰려면 y, 취소는 n을 입력하자 */

overwrite test2.txt? (y/n [n]) n /* 덮어쓰기 취소 */
not overwritten /* 덮어쓰지 않았다. */

$ ls
test1.txt  test2.txt

mv 커맨드를 안전하게 사용하고 싶다면 i 옵션을 꼭 활용하자