도입
요즘 개발자들 사이에서 협업과 프로젝트 관리의 중요성이 커지면서, 이를 효율적으로 처리할 수 있는 도구에 대한 관심도 높아지고 있다. 이번 포스팅에서는 Git과 GitHub를 활용해 협업 프로젝트를 관리하는 방법을 배우는 강의를 소개한다. 여러 사람과 함께 프로젝트를 진행하면서 코드 변경 사항을 효과적으로 관리하고 싶은 분들에게 유용한 강의이다.
이 강의는 Git과 GitHub의 사용법을 실전 위주로 다루고 있으며, 개발 경험이 적은 초심자도 쉽게 따라할 수 있도록 구성되어 있다. Git의 기초 명령어 사용부터 브랜치 관리, 협업 요청(pull request) 방법까지 실제로 실습을 통해 경험하며 배우게 된다. 이러한 실습 과정은 학습자가 Git을 완벽히 이해하고 자신감을 키울 수 있는 기회를 제공한다.
강의를 통해 Git과 GitHub의 다양한 기능을 배우며, 프로젝트 관리와 협업에 필요한 핵심 개념들을 제대로 다질 수 있었다. 이제부터는 이 강의를 통해 제가 배운 내용을 바탕으로 여러분께 도움이 될 만한 강의 후기를 공유하고자 한다.
https://metacodes.co.kr/edu/read2.nx?M2_IDX=31635&EP_IDX=12234&EM_IDX=12058
1. Commit
git에서 commit는 특정 시점을 기록한 단위를 말하며
이것은 SHA-1 해시것은 SHA-1 해시알고리즘으로 암호화되어 기록된다
해당 해시값에는 작성자, 작성날짜 + 커밋날짜, 커밋메세지, 이전의 연관된 커밋 정보, 파일 상태 등이 기록된다
이를 도식화 한다면 아래와 같아진다.
위 사진처럼 각각의 작업자가 작업을 한 내용을 기록한 것이 commit이라 볼 수 있으며,
날짜 정보가 작성날짜, 커밋날짜 2개의 시간이 기록되기에
이를 함께 표현하는 단어로 commit란 단어를 선정한 듯 하다.
그 외로 해당 작업의 작성자, 작업한 내용을 설명하는 커밋 메세지, 해당 작업과 연관되어 있는 이전 커밋, 변경된 파일 리스트 등이 기록되고
이에 대한 정보가 모두 SHA-1 알고리즘으로 암호화 되는 것이다.
여기서 변경되는 파일은 총 4가지의 상태를 가지는데 그림으로 표현하면 아래와 같다.
1) Untracked(추적되지 않음) : Git에서 아직 파일을 추적하지 않는 상태를 말하며
좀 더 명확하게는 git add 명령어로 관리가 되지않는 파일을 의미한다.
2) Unmodified(수정되지 않음) : Git에서 파일은 추적중이나, 가장 마지막 commit과 동일한 상태
즉, 해당 파일이 변경되지 않은 최신 상태라 볼 수 있다
-> 만약 파일을 변경하면 3) Modified로 상태가 이전된다.
3) Modified (수정됨) : 파일은 수정되었고, git에서 추적하고 잇으나, 아직 staging area에 추가되지 않은 상태
즉, commit은 되지 않은 상태를 의미한다.
4) Stage (스테이지됨) : commit 바로 직전의 상태라고 이해하는게 제일 편할 듯 하다.
이제 각 파일 상태를 확인하는 실습을 진행하도록 하겠다
1.1 Untracked
위 사진처럼 'Module2.txt'파일을 생성하고
git add명령어를 통해 해당 파일을 등록하지 않은 상태라면
해당 파일은 Untracked 즉, 추적되지 않은 상태의 파일이다
이를 git status명령어를 실행하면
Untracted files 목록에 해당 파일이 추적되지 않는 것으로 파일 리스트가 팝업된다.
1.2 Unmodified
반대로 위와 같이 git add 명령어로 파일이 등록 된 뒤 변경사항을 commit명령어를 통해 반영한
'Module1.txt'파일은 Unmodified 상태라 볼 수 있다.
1.3 Modified
다음으로 git add명령어를 통해서 추적 관리 대상 파일이 된 Module1.txt 파일의 내용을 수정하면
위와 같이 Modified상태로 변경된다.
이 Modified 상태는 겉으로 보면 Untracked 상태와 같아보일 수 있으나, 위 사진처럼
초기화 명령을 수행하면 추적 대상 파일들은 모두 변경 전 상태로 복귀할 수 있는 장점이 존재한다
1.4 Stage
마지막으로 git add 명령어를 통해 'Module2.txt'
파일을 등록하면 해당 파일은 추적 및 staging area에 올라간 상태가 된다
이 상태에서 commit명령어를 수행하면
해당 변경된 상태를 git에서 관리하는 '시점'으로 등록하는 것이 된다.
반대로 git add 명령어로 'Module1.txt'를 등록하지 않았기에 해당파일은 commit를 실행해도 변경사항이 등록되지 않는다
실제로 위 사진처럼
git commit 명령어를 실행하게 되면
staging area위에 올라간 Module2.txt는 정상적으로 변경된 시점이 등록되지만
Module1.txt은 여전히 Modified 상태인 것을 확인할 수 있다.
이같은 각 파일의 상태는 파일이 Delete되더라도
시점이 등록되어 있으니 이를 백업 - 복구 형식으로 복원하는게 가능하다
2. git 명령어세트
1) git diff
파일의 수정상태를 확인할 수 있는 명령이다.
지금처럼 Module1, Module2 두개의 파일을 수정 후 저장했을 때
git diff 명령어를 실행하면
각 파일별로 어느 부분이 변경되었는지를 보여준다.
물론 특정 파일에 대해서만 변경사항을 확인하는 상세옵션을 지정할 수 있다
이럴때는 아래 명령어를 실행하면 된다.
$ git diff [파일이름]2) git log
수행한 commit 기록을 보여준느 명령어이다.
지금처럼 모든 파일을 add 한 뒤 commit하고
아래의 명령어를 실행시켜보자
$ git log
그러면 현재까지 수행한 commit항목을 열람하는 것이 가능하다.
이때 위 사진처럼 -p 옵션을 추가하면
각 commit별로 어떠한 항목이 수정이 되었는지를
좀 더 상세하게 확인하는 것이 가능하다
3) git restore
다음으로 살펴볼 git restore 명령어는
commit를 수행하기 전 변경한 사항을 원복하는 명령어라 볼 수 있다.
먼저 실습을 위해 위 사진처럼 임의의 구문을 채운 뒤 저장하여 변경사항을 생성하자
그 이후 아래의 명령어를 수행하면
각 항목별로 복구하는 것이 가능하다
$ git restore [파일이름]
위 사진처럼 git restore명령어를 통해 지정한 파일의 변경사항을 복구할 수 있다.
이때 복구는 git add를 통해 staged 상태가 되더라도 무관하게 복구하는 것이 가능하다.
4) git revert
위 명령어는 commit을 수행한 항목에 대해서 복구를 하는 명령어이다.
먼저 실습을 위한 사전 상황을 설계하도록 하겠다.
위 사진처럼 어떤 파일의 변경이 진행되었는데
해당 파일이 git add -> git commit로 인해서 저장소에 시점이 등록된 불상사가 발생했다 가정해보자
이때 복구를 위한 git revert 명령을 사용하면 해당 커밋이 등록된 바로 직전 커밋 시점으로 복구가 가능하며
commit는 ID명을 기입해야한다.
이때 해당명령을 수행하면
unix 편집기 창이 뜨는데 당황하지 말고 :wq 명령어를 입력하여 해당 과정을 확정하도록 하자
참고로 git revert명령어는 굉장히 위험한 작업이기에
위 사진처럼 2번에 걸쳐서 해당 명령을 수행할지 묻는 과정이 나오는 것이다.
그리고 revert를 수행하는 커밋을 새로 남기는 것이지
commit기록이 완전히 말소되는 것은 아니다
5) git reset
위 명령어는 특정 커밋으로 되돌아가는 git revert와 유사한데 추가 옵션으로 --hard를 넣으면 복귀 후 커밋을 완전히 삭제하는 명령어라 보면 된다.
따라서 4), 5) 항목은 이전 시점의 commit로 넘어가는 것 자체를 git에서는 위험하다 판단하기에
가급적 사용을 자제하는 것을 권장한다.
즉 버전 복구를 하고 싶다면 git restore로 파일만 복구한 뒤 복구된 버전을 새로운 시점의 commit로 남기는 것이 더 올바른 협업 과정이라 볼 수 있다.
감사의 글
본 포스트는 메타코드 서포터즈로서 작성하였습니다
