-
명령어로 Git을 사용하자! Git CLI ( 버전관리 )Knowledge/Git 2019. 11. 27. 15:35반응형
이 포스팅은 이고잉 님의 Git CLI - 버전 관리 ( https://opentutorials.org/course/3839 ) 강의를 듣고 정리한 내용입니다.
- 버전 관리의 시작
먼저 git을 설치해 ( https://opentutorials.org/course/3839/22590 ) git bash를 실행시키고
버전 관리 하고 싶은 폴더로 이동한다.
해당 폴더는 현재 비어있는 상태다
이 상태에서 git bash 명령창에서
1git init을 입력하면
비어 있는 Git Repository가 Initialized 되었다는 알림이 나온다. 다시 파일 목록을 보면
.git이란 폴더가 생성된 걸 확인할 수 있다.
이는 버전 정보가 저장되는 디렉토리로서
위와 같은 방법으로 이 폴더를 생성하는 것이 버전관리의 시작이다.
- 버전의 생성
버전의 생성 과정을 이해하기 위해선 Working Tree, Staging Area, Repository를 이해해야 한다.
이를 간단히 설명하자면 아래와 같다.
Working Tree : 추가, 수정된 파일들이 존재하는 곳
Staging Area : 변경된 파일 중 버전을 만들려고 하는 파일들이 존재하는 곳
Repository : 버전이 저장되는 곳
예를 들어 1이라는 내용을 적은 hello1.txt라는 파일을 git 초기화 해놓은 폴더안에 만들고
1git status라는 명령어를 입력해보면
위와 같은 내용을 확인할 수 있다.
이 중 No commits yet은 아직 생성된 버전이 없다는 뜻이고
Untracked files 목록에 나오는 hello1.txt는 말 그대로 추가, 수정되었지만 아직 추적되지 않고 있다는 뜻,
즉 Working Tree에 존재한다는 뜻이다. 그러니 이걸 버전 관리 하려면 우선 Staging Area에 올려야 한다.
Stagig Area에 파일을 올리는 명령어는
1git add 파일명이다. 입력후 다시 한번 git status로 내용을 확인해보면
hello1.txt라는 파일이 Changes to be committed 목록으로 옮겨진 걸 볼 수 있다.
버전으로 만들 준비가 되어 있다는 뜻이니 Staging Area에 올라갔음을 의미한다.
이제 버전을 만들기만 하면 된다. 버전은
1git commit -m "커밋 메모"명령어로 만들 수 있다.
뒤에 -m "커밋 메모"는 필수는 아니지만 해당 옵션을 사용하면 에디터를 거치지 않고 커밋 메모를 남길 수 있는 이점이 있다. 아무튼 입력하고 다시 git satus로 상태를 보면
Staging Area에 올라가 있던 hello1.txt 파일이 Message 1이란 메모와 함께 커밋이 되어서
지금은 커밋할 게 없다. working tree가 clean하다는 내용을 확인할 수 있다. 실제로
1git log명령어를 입력하면
commit된 내역, 즉 버전이 만들어진 일종의 역사를 확인할 수 있다.
자 그럼 여기서 파일을 수정해보면 어떨까?
hello1.txt에 2라는 내용을 추가하고 git status로 다시 한번 상태를 보면
변경된 내역은 있지만 아직 커밋할 수 있게 Stage에 올라가 있진 않다고 나온다.
그럼 어떻게 해야할까? 방법은 같다. git add hello1.txt -> git status 하면
변경이 커밋될 준비가 되었다고 나오고 git commit -m "Message2" 를 입력하고 git log를 보면
Message2라는 메모와 함께 새로운 버전이 생성된 걸 확인할 수 있다.
오케이. 그럼 이제 git에서 파일 하나를 다루는 방법은 알게 되었다.
그렇다면 파일 두개를 다뤄야하는 상황은 어떨까?
예를 들어 hello1.txt에 3을 추가하고, hello2.txt 라는 파일을 생성해 1이라는 내용을 적은 후 git status를 확인하면
hello1.txt는 Changes not staged for commit 목록에, hello2.txt 는 Untracked files 목록에 나오는 걸 확인할 수 있다.
이는 hello1.txt는 버전 관리를 한 적이 있지만 hello2.txt는 한번도 버전관리 한 적이 없기 때문에 발생하는 차이다
근데 뭐, 만약 둘 파일 모두 버전 관리를 하고 싶다면 둘 다 Staging Area에 올리면 되는 건 다름이 없다.
git add hello1.txt , git add hello2.txt를 입력하면되는데 굳이 이렇게 하지 않고
1git add .이렇게 하면 모든 파일을 한번에 Staging area에 올릴 수도 있다.
응용해서 add 뒤에 특정 디렉토리 명을 적을 경우 그 특정 디렉토리 안의 파일만 모두 올릴 수도 있다.
아무튼 파일을 Staging Area에 올리고 git status를 보면
이렇게 두가지 파일 모두 잘 올라가 있는 걸 확인할 수 있다. 커밋 후 log를 보면
Message 3이란 메모로 버전이 잘 생성된 걸 확인할 수 있고
좀 더 상세히, 연루되어 있는 파일들 목록까지 확인할 수 있게
1git log --stat을 입력하면
이렇게 좀 더 상세한 내용을 확인할 수 있다.
1git log -p를 입력하면
이렇게 더욱 상세하게, commit에 포함된 파일별 변경 내역까지 볼 수 있다.
- 버전간의 차이점 비교
파일 내용을 변경 후 가장 최근 버전과 현재의 차이점을 볼 수도 있다.
예를 들어 hello1.txt에서 3이란 내용을 지우고 four란 내용을 추가한 다음
1git diff를 입력하면
이렇게 3이 빠지고 four가 추가된 내역을 확인할 수 있다.
- checkout과 시간여행
Git 을 이용해서 과거 버전으로 갈 수도 있다. git log를 입력해서 목록을 보면
각 commit 마다 ID가 있는 걸 알 수 있다. 이를 이용하면 되는데 예를 들어 Message 2때로 돌아가고 싶다면
1git checkout 돌아가려는 commit id명령어를 입력하면
위와 같은 메세지와 함께
다음과 같이 git log를 확인해도 Message 2까지만 목록에 나타나고
ls -al을 입력해도 hello1.txt만 나타나는 걸 확인할 수 있다.
그러나 이는 이전 버전이 사라진 건 아니다. master는 최신 버전을 의미하는데
1git checkout master명령어를 입력하고 git log와 파일 목록을 확인하면
Message 3와 hello2.txt가 다시 보인다.
즉 git checkout 명령어는 git이 가르키는 head를 특정 시점으로 옮길 수 있는 명령어임을 알 수 있다.
- 버전 삭제
만약 버전을 아예 삭제하고 싶다면
1git reset --hard 최신 버전으로 만들고 싶은 commit id를 입력하면 된다. 예를 들어 Message 2 로 reset 하면
위와 같이 Message 2 위 메모를 적은 commit이 master가 되어있는 걸 볼 수 있다.
이 때는 지금 마스터가 된 버전 이후의 버전들 뿐만 아니라 수정하고 있던 내역도 reset되는데
위 명령어에서 --hard를 --soft나 --mixed로 바꾸면 버전만 reset되고 수정하던 내역은 남길 수도 있다
- 버전 되돌리기
버전을 삭제하지 않고 되돌리기만 할 수도 있다.
위에서 보듯 reset을 활용했을 때는 삭제 내역을 볼 수 없게 말 그대로 삭제되어 버리지만
버전 되돌리기, 즉 git revert를 활용하면 그 내역 역시 남길 수 있다.
예를 들어 hello1.txt에 R3, R4라는 내용을 추가하고 각각 R3, R4라는 메모를 남겨 commit했다고 하자
( 깨알 같이 하나 더 추가하자면
1git commit -am "커밋메세지"명령어로
위와 같이 add와 commit을 동시에 처리할 수 있다. 다시 돌아가서 )
이 때 내역을 남기면서 R4에서 R3로 돌아가고 싶다면
1git revert 이전 단계로 되돌리려는 (내역을 남기고 없애려는) 버전 commit id를 입력하면 된다. 그러니까 git revert R4 commit id를 하면
revert 4는 그대로 있고 Revert "R4" 추가된 걸 볼 수 있다. hello1.txt의 내용과 변경 내역을 보면
이처럼 내용이 R3와 같은 상태인 것을 알 수 있다.
이 Revert를 사용할 때 유의할 점이 있는데 단계를 뛰어넘어서 사용하면 충돌이 발생한다.
예를 들어 R4가 Master인 상태에서 한번에 git revert Message 2 commit id를 입력하면 안 된다는 것이다.
이런 처리를 하고 싶다면 git revert R4 commit id -> git revert R3 commit id -> git revert Message 2 commit id처럼
단계적으로 역순으로 되돌아가야 한다.
반응형'Knowledge > Git' 카테고리의 다른 글
명령어로 Git을 사용하자! Git CLI ( 협업 ) (0) 2019.11.28 명령어로 Git을 사용하자! Git CLI ( Branch & Conflict ) (0) 2019.11.28 명령어로 Git을 사용하자! Git CLI ( Backup ) (0) 2019.11.27 GIT 커밋 실패 - commit failed - exit code 1 received (0) 2019.09.23