Git add, commit 명령어(feat. Git과 GitHub 차이)

Git add, commit 명령어(feat. Git과 GitHub 차이)

 

개발자를 지망하는 학생이라면,

Git과 Github는 정말 "뗄래야 뗄 수 없는 사이" 이다.

처음에는 뭐든 헷갈린다.

 

그래서 개념들을 명확히 해보자.

 

"Git"은, 간단하게 "로컬(local) 버전 관리 시스템 (Version Control System)"이다.

"로컬(local)" 이라 함은 내 컴퓨터를 말하는 것이다.

 

이때 "버전 관리 시스템" 이라는게 거창한 것을 말하는게 아니라,

내가 수정했던 내용들, 과거의 히스토리를 모두 기록해두는 것을 의미한다.

 

반면 "Github"는 로컬(local)이 아니라 클라우드에서 관리되는 "버전 관리 시스템"이다.

따라서, 이를 통해 다른 사람들에게 코드를 공유할 수 있고, 협업도 쉽게 할 수 있다.

 

Git과 Github의 차이

 

 

그렇다면 처음에 Git을 어떻게 시작할 것인가?

 

일단 terminal을 열고, 기존의 project라는 폴더로 이동하여

git_project 라는 폴더를 생성하고, 그 폴더로 이동한다.

그리고 "git init" 이라는 코드를 통해, "git 저장소를 생성" 한다.

 

git init

 

그럼 다음과 같이 진행된다.

 

git init

 

 

 

 

 

 

 

 

 

 

 

 

 

그리고 다음으로 자주 쓰이는 명령어인 "git status"는 현재 git에서의 상태를 나타낸다.

git status

자주 쓰게 될 명령어니까, 일단 알아두자.

 

git status

 

마지막으로, "echo" 명령어에 대해 간단히 보자.

사실 이 명령어 처음 봤는데, 편해보여서 사용한다.

아래 예시로 보면, echo 명령어는 새롭게 파일(a.py)을 만들고, 그곳에 새로운 내용(hello world)을 넣는다. 

echo 'hello world' > a.py

echo 명령어

echo 명령

 

요로케 잘 들어가 있는걸 볼 수 있다.

 

이제 본격적으로, 가장 기본이 되는 add, commit push, pull에 대해 알아보려고 한다.

Git에서 이 흐름(Workflow)을 아는 것이 정말 중요하다고 생각한다.

(나도 Git과 Github에 대해 알고 지낸지는 오래되었지만,

정확히 add, commit이 어떻게 동작하는지 헷갈렸음.)

 

내가 좋아하는 코딩 유튜버 "드림코딩 엘리" 님의 영상을 참고해서 자세하게 알아보면,

일단 이게 기본이다.

Workflow의 큰 그림

이 구성에서 add, commit, push, pull 등등을 하나씩 살펴볼 것이다.

 

먼저 아래 코드를 실행하여 기본 세팅을 하자.

초기 설정

그리고 git status로 확인해보면, 다음과 같이 나온다.

 

git status로 확인

 

현재의 상태를 workflow의 큰 그림으로 보면, 아래의 그림과 같은 상황이다.

workflow 큰 그림 

이처럼 처음에 Local저장소의 Working directory에 Untracked file로 존재하는 걸 알 수 있다.

 

 

 

 

 

 

 

 

 

 

※ add 명령어

이제 add 명령어를 사용하여, a.py를 Staging Area로 넣어보자. 

git add a.py

그리고 git status로 보면, 다음과 같다.

 

 

현재 이 상태를 workflow의 큰 그림으로 보면, 아래 그림과 같다.

이처럼, add 명령어는 "변경된(or 새로운) working directory의 파일"을 "Staging Area로 보내주는 역할"을 한다.

 

이때, Staging Area는 "commit"을 할 준비가 된 파일들을 ".Git directory에 저장하기 전에 대기하는 장소" 이다.

 

또한 Working directory에서 Untracted와 Tracked로 나뉘는데,

Untraced file은 "현재 git이 관리를 하고 있지 않은 파일" 이고

Tracked file은 "현재 git이 관리를 하고 있는 파일" 이다.

(Working directory에 있지만, 단 한번도 add나 commit이 되지 않는다면 Untraced로 남고 git은 이를 관리하지 않는다.)

 

 

이번엔, 모든 파일을 Staging Area로 보내자.

git add *

그리고 "a.py" 파일만 수정을 해보자.

echo 'modified' > a.py

 

이때, Workflow의 큰 그림으로 보면, 다음과 같이 된다.

 

이처럼 기존의 a.py, b.py, c.py는 모두 Staging Area에 존재하고,

수정된(modified) a.py는 Working dirctory에 Tracked file로 남아있다.

이를 git status로 보자.

 

git status

cf. "git add -A",  "git add *",  "git add ."  각각의 차이

출처: stackoverflow

git add -A는 정말 모든 것을 추가하는 것을 의미하고,

git add *과 git add . 은 거의 비슷한데, 파일이 삭제된 후에 처리에서 약간 차이가 있다.

파일삭제 후, git add * 를 할 경우, 삭제했던 파일은 Staging Area에 남아있는 반면,

파일삭제 후, git add . 을 할 경우, 삭제했던 파일도 Staging Area에서 사라진다. 

 

여기까지 add 명령어에 대해 알아봤다.

아까도 말했다시피, add 명령어는 commit으로 기록하기 전에 변경된 것들을 "Staging Area에 모아놓는 역할"을 한다. 

그렇기에 commit을 하기 전까지는 사실 Git directory에 아무런 영향을 미치지 않는다.

 

 

 

 

 

 

 

 

 

※ commit 명령어

commit에는 3가지 버전이 있는데

git commit -m "message"
git commit -a
git commit -am "message"

첫 번째는, Staging Area에 있는 것들을 메시지와 함께 commit해주는 것이다.

 

두 번째는, add를 해주고, commit을 해주는 것이다. (이때 vim에서 message를 입력해줘야한다. 귀찮음....)

-> 이때 주의해야 할 것은, Untracked file은 직접 add를 해줘야한다.

(즉, file이 한번도 add가 된 적이 없다면 직접 add를 해줘야 함.)

 

세 번째는, 첫 번째와 두 번째를 합친 버전이다. (이게 제일 편하다.)

-> 이때도 Untracked file은 직접 add해야한다.

 

 

Workflow의 큰 그림을 보기 위해, 초기상태가 다음과 같다고 하자.

초기 상태

 

이때, git commit -m "first" 라는 명령어를 수행했다면, 아래와 같은 상태가 될 것이고, 

git commit -m "first"

git commit -am "first" 라는 명령어를 수행했다면, 아래와 같은 상태가 될 것이다.

git commit -am "first" 

 

이정도면 어느정도 이해할 수 있을거라고 생각한다.

 

 

글이 너무 길어져서, 다음 시간에 push와 pull에 대해서 글을 적어봐야겠다.

 

 

 

혹시라도 틀린 내용이나 보완이 필요한 내용이 있다고 생각하신다면,

댓글주시면 감사하겠습니다.