git init이 완료되었다면,
기초 명령어를 통해 commit까지 상태 변경을 할 수 있다.
1. 작업환경 이해
우선 작업환경을 이해하고 넘어가 보자
위 그림처럼 세 부분의 작업환경이 있다.
미리 요약하자면,
working directory에서 작업한 작업물을 staging area에 add 명령어로 올리고
staging area에서 처리를 기다리는 작업물을 commit 명령어로 .git directory에 올리는 일련의 순서를 가진다.
나아가 local에 commit된 버전 기록들을 server에 push 로 올리고 pull 로 내려받을 수 있다.
working directory는 위 그림처럼 세분화하여 나타낼 수 있다.
untracked영역은 .git에서 버전 관리가 되고 있는 않은 작업물이 대기되는 공간이다.
예를 들어 새 파일을 작업한다면 git status로 작업 환경의 상태를 확인해 보았을 때 untraked file로 분류되는 것을 확인할 수 있다.
tracked영역은 반대로 .git에서 버전 관리가 되고 있는 작업물일 때 담기게 되고, 세부적으로 unmodified와 modified로 구분된다.
단어 그대로 modified기록이 있는 작업물이 git add 로 staging area(commit 대기상태)에 올려지고 staging area에서 원하는 파일을 git commit으로 올리면 버전 관리가 이루어진다.
버전 기록을 확인하고 싶다면 git log를 통해 확인할 수 있다.
2. Git Add
git add는 앞서 설명한 대로 staging area에 commit 대기 상태로 올리기 위한 명령어다.
git bash를 열고, vim 에디터를 통해 현제 디렉토리에 txt파일을 만든다.
vim a.txt라는 명령어를 입력하면 아래와 같은 에디터 화면으로 전환된다.
바로 텍스트가 입력되지는 않고 i를 입력하면 insert모드로 전환되어 입력할 수 있다
원하는 코드를 입력했다고 가정하고, 입력이 완료되면 esc키로 insert모드를 해제하고 :wq를 입력하여 터미널 화면으로 돌아온다.
vim 에디터로 a.txt파일이 생성된 것을 확인하기 위해,
ls -al 명령어로 디렉토리내 파일들을 확인하고 cat 명령어로 파일의 입력 내용을 확인해 볼 수 있었다.
git status로 작업환경 상태를 확인해보면 아직 untracked file로 분류되어 있는 것을 볼 수 있고
add 명령어를 사용하라는 텍스트를 확인할 수 있다.
add를 하면 tracking 목록에 포함이 되고 commit 대기 상태로 변경된다.
2. Git Commit
staging area에 올라온 작업물을 버전으로 만들어 저장하기 위해 commit 명령어를 사용한다.
commit으로 버전 관리를 하기 전에, git을 처음 사용한다면 작업자를 기록하기 위해 셋팅을 먼저 해주어야 한다.
git config --global user.name [이름]
git config --global user.email [메일]해당 셋팅은 한 번만 해주면 앞으로의 commit과 함께 기록된다.
git commit 명령어를 입력하면 아래와 같이 vim에디터 창으로 전환된다.
i를 눌러 insert모드로 변경하여 version message를 입력하고 esc, :wq로 터미널로 돌아온다.
돌아온 터미널 화면에서 작성한 메세지를 확인할 수 있고, git log를 통해 상세 정보를 알 수 있다.
commit완료된 파일을 vim을 이용해 수정해 본 후, git status로 상태를 확인해 보았다.
commit된 a.txt파일이 modified 영역에 잡히는 것을 확인할 수 있고, add가 필요하다는 메세지 또한 확인할 수 있다.
다시 add를 하고 commit을 실행했고 log를 확인해보면 변경된 정보와 히스토리를 확인 할 수 있다.
3. Git stage area
cp a.txt b.txt파일 a를 b로 카피하고 git status를 확인해보면 b.txt가 untracked file로 분류된다.
untracked file을 add를 통해 staging area에 올리고 commit하는 일련의 순서를 진행하면 git repository로 버전 정보를 올릴 수 있다.
만일 둘 다 수정을 통해 modified로 분류가 되었을 때, a.txt의 수정사항만 repository에 올리고 싶다면?
해당 질문을 통해 staging area로 굳이 add를 하는 이유를 엿볼 수 있다.
add 를 통해 원하는 파일만 commit하도록 준비할 수 있기 때문이다.
수정을 마친 a.txt만 add, commit의 과정을 거쳐 repository에 올라갔고,
위 그림처럼 b.txt는 modified상태로 staging area에 올라오지 못한 것을 확인할 수 있다.
이처럼 선택적으로 staging area에 commit대기 상태를 만들어 준 다음 commit을 통해 reposotory에 결과를 쌓을 수 있다.
4.Git log -p & diff
git log를 통해 버전 history를 확인할 수 있다.
이 history를 통해 얻을 수 있는 중요한 사항은 commit messege가 될 수 있다.
그리고 log의 기능을 확장하여
git log -p를 입력하면 각 commit 사이의 소스차이를 볼 수 있다.
1) git log
마지막 commit을 기준으로 과거 history와 비교를 하게 된다.
첫번째 박스에서
---a/는 변경 전 파일을
---b/는 변경 후 파일을 나타내고
빨간 텍스트는 변경 전, 초록 텍스트는 변경 된 텍스트를 표시한다.
두번째 박스는 첫번째와 동일하지만
--- /dev/null 부분의 차이가 있는데 이것은 새로 생성된 파일을 나타내 준다.
:부분에 q를 입력하여 터미널로 돌아와
git diff a의 해시코드..b의 해시코드와 어떤 차이를 가지는지 알아보도록 한다.
2) git diff
git log를 통해 commit마다 고유 해시 코드를 가지는 것을 볼 수 있다.
git log [특정 commit id]를 입력하면 해당 commit을 기준으로 이전 history를 볼 수 있다.
git diff는 특정 commit 해시 코드 사이의 차이점을 볼 수 있다.
log의 현버전, 구버전으로의 비교가 아닌, a와 b의 소스 코드 상의 차이를 비교하게 된다.
해당 기능을 통해 commit 전 마지막 리뷰의 기회를 가질 수 있으니 참고하면 좋을 것 같다.
'Study > GitHub' 카테고리의 다른 글
| GitHub | 여러계정 이용하기 (0) | 2022.03.27 |
|---|---|
| GitHub | 원격저장소와 동기화 (0) | 2022.03.27 |
| Git | reset, branch, merge, stash (0) | 2022.03.07 |
| Git | init (0) | 2022.03.04 |
| GitHub 블로그 만들기 (0) | 2022.03.03 |
