이번 글은 코드잇 강의를 수강하면서 배운 내용을 주로 하여 정리되어 있습니다. (코드잇 스프린트 데이터 애널리스트 트랙 1기 훈련생)
Github 시작하기
Github
Git으로 관리하는 프로젝트를 올려둘 수 있는 프로그램입니다.
프로젝트 디렉토리에서 작업하던 내용을 외부 컴퓨터에 전송합니다.(작업하던 내용을 전송한다. ← 로컬(컴퓨터) 레포지토리에서 리모트(원격) 레포지토리로 전송한다.)
- 로컬 레포지토리 (Local Repository) : 개인 컴퓨터나 작업 환경에 저장된 Git 레포지토리를 말합니다.(내 컴퓨터의 레포지토리)
개발자가 코드를 작성하고 변경 사항을 추적하는 공간입니다 - 리모트 레포지토리 (Remote Repository) : 네트워크 상에 존재하는 Git 레포지토리로, GitHub와 같은 원격 서버에 저장됩니다. (Github의 레포지토리)
Github의 계정과 Remote Repository 만들기
Github 계정은 https://github.com/에 접속하고, sign-up버튼을 눌러 계정을 생성합니다.(플랜 설정, 설문 사항 개별 선택)
이메일 인증까지 모두 완료했다면, 계정이 잘 생성되었으며, 이제 Remote Repository를 만들 수 있습니다.
Remote Repository는 Create Repository 버튼을 누르고 레포지토리의 이름과 description(설명)을 작성하고 공개 범위를 선택한다면 잘 생성할 수 있습니다.
Local Repositry의 내용을 Remote Repositry로 보내기
내 컴퓨터의 레포지토리인 로컬 레포지트리를 깃허브의 레포지트리인 리모트(원격) 레포지트리로 보내려고 할 때, 방법에는 2가지가 있습니다.
- 로컬 레포지트리를 만들고 커밋을 한 후에, 깃허브에 업로드하기
- 이미 만든 로컬 레포지트리를 깃허브에 업로드하기
2번 방법을 하기 위해서는
git remote add origin 원격 저장소 링크 # 예시 : git remote add origin https://github.com/ourkofe/Math_Box.git
git branch -M main
git pull origin main # (push중 오류 발생시 사용 가능한 커맨드)
git push -u origin main
위 커맨드를 차례대로 입력합니다.
위 커맨드를 입력하면 성공적으로 리모트 레포지트리에 로컬 레포지트리의 내용을 보낼 수 있으며, 깃허브 사이트에서 잘 전송된 것을 확인할 수 있습니다.
Local Repositry에서 바뀐 내용을 Remote Repositry에도 반영하기 : git push
Remote Repositry에 Local Repositry의 내용을 성공적으로 보낸 상태에서 Local Repositry에서 수정 사항이 생기거나 파일이 추가된 경우에 Remote Repositry에 그 내용을 반영할 필요가 있을 때, git add . 이나 git add 파일명을 통해 staging area로 올리고 git commit으로 커밋합니다. (메시지는 개인적으로 내용을 작성)
로컬 레포지토리에서 매번 새로운 커밋을 할 때마다 매번 리모트 레포지토리에 반영해주어야 합니다.
이 때, git push 라는 커맨드를 이용하면 로컬 레포지트리에서 수정한 내용을 간단하게 깃허브(리모트 레포지토리)에 반영할 수 있으며, 잘 되었는지 깃허브 사이트에서도 확인할 수 있습니다.
Remote Repositry에서 바뀐 내용을 Local Repositry에도 반영하기 : git pull
위와 반대로 Remote Repositry에서 새로운 커밋으로 수정 사항이 생겨(리모트 레포지토리의 내용이 더 최신인 경우) Local Repositry에도 새로운 커밋을 반영할 필요가 있을 때, git pull 이라는 커맨드를 이용하면 리모트 레포지트리에서 수정한 내용을 컴퓨터 레포지토리에 반영할 수 있습니다.
예를 들어, 깃허브 사이트에서 Remote Repositry의 README.md 파일을 수정했다고 하겠습니다.(커밋 메시지도 작성해야 합니다.)
커밋이 완료된 리모트 레포지트리의 내용을 Local Repositry에 반영하기 위해 터미널로 돌아가서 프로젝트 디렉토리에 git pull 커맨드를 입력합니다.
실제로 반영이 잘 되었는지는 cat 커맨드를 통해 확인할 수 있습니다.
리모트 레포지토리를 사용하는 이유
- 안전 (똑같은 레포지토리가 하나 더 생기는 것으로, 벡업본이 있다고 말할 수 있어 안전합니다.)
- 협업 용이
Remote Repositry를 만들고 지속적으로 수정하는 이유는 파일이 안전하고 협업이 용이하기 때문입니다.
깃허브에 협업하기 위해 협업자 추가하는 방법(collaborators)
git push는 본래 리모트 레포지토리의 주인, 그러니까 본인만 할 수 있습니다.
원칙적으로 본인만 레포지토리에 git push를 할 수 있지만, 본인이 아닌 다른 사용자도 git push를 할 수 있게 하고 싶거나 협업을 하고 싶다면 레포지토리에서 Settings 탭에 들어가 collaborators 버튼을 누르고 이 페이지에서 Add People에서 다른 사용자를 collaborator로 초대하고 그 사용자가 수락한다면 그 사용자는 제 리모트 레포지토리에 git push할 수 있는 권한을 가질 수 있습니다.
위 내용을 정리하자면, 다른 사용자도 git push를 할 수 있게 해주려면 그 사용자를 해당 리모트 레포지토리의 collaborator로 지정하면 됩니다.
다른 프로젝트 가져오기 : git clone
깃허브에는 다른 사용자들이 만든 다양한 프로젝트의 레포지트리들이 있습니다.
깃허브 페이지에서 explore 탭에서 관심 있는 레포지트리를 찾을 수 있으며, 깃허브에서 사람들이 만들어놓은 다양한 프로젝트를 통해 정보를 얻거나 사용할 수 있습니다.
깃허브에서 마음에 드는 프로젝트가 있어 내 컴퓨터로 가져오고 싶다면, 우선 해당 프로젝트의 레포지토리 주소가 필요합니다.
해당 프로젝트 레포지토리의 사이트 우측 상단의 초록색 ‘Clone or Download’를 클릭하면 주소를 복사할 수 있습니다.
이제 상위 디렉토리에서 복사한 주소를 내 터미널에 ‘git clone 주소’ 커맨드를 입력하여 다른 프로젝트를 내 컴퓨터에 가져올 수 있습니다. (레포지토리가 엉키지 않도록 적절한 디렉토리에서 커맨드를 사용하는 것이 중요합니다.)
즉, git clone 커맨드는 깃허브 프로젝트의 레포지토리를 그대로 복제해오는 기능을 갖고 있습니다.
오픈 소스 프로젝트
예전에 프로그래밍을 할 때는 소스 코드를 공개하고, 공유하고, 그 원리를 아는 사람이 모르는 사람에게 가르쳐주는 게 당연한 문화가 일반적이었지만, 컴퓨터 프로그램 시장이 발전하면서 특정 회사가 자체적으로 소스 코드를 개발하고 소스 코드를 감추면서 유료로 사용료를 받는 모습이 만연해졌습니다.
이런 변화와 함께 프로그램의 소스 코드들은 점점 그 프로그램을 만든 회사만 갖고 있고 공개하지 않기 시작했습니다.
하지만 오픈 소스 소프트웨어가 점차 생겨나며(mysql, numpy, Linux 등) 무료로 사용 가능하고, 폐쇄적인 면이 사라지며 오픈 소스를 활용하기 좋은 환경이 만들어졌습니다.
현재 GitHub에는 훌륭한 프로젝트들이 많이 존재하며, 이러한 프로젝트는 대부분 그 소스 코드가 공개되어 있습니다.
위와 같이 소스 코드가 공개되어 있는 프로젝트를 '오픈 소스 프로젝트(open source project)'라고 하고, 프로그램의 소스 코드가 대중에 공개된 상태일 때 오픈 소스라고 합니다.
하지만 오픈 소스라고 해서 사용할 때 항상 아무런 제약이 없는 것은 아니며, 오픈 소스에도 다양한 종류의 라이센스(open source license)들이 있어 이를 준수해야 할 필요가 있습니다.
오픈 소스 프로젝트의 장점
- 무료로 사용할 수 있습니다.
- 프로젝트에 참여 중인 다른 개발자들에게 질문을 할 수 있습니다.
- 어떤 프로그램을 개발할 때 특정 분야에서 사실상 표준처럼 사용되는 오픈 소스 프로그램을 많이 활용할수록 전체 개발 속도를 단축시킬 수 있습니다.
오픈 소스 프로젝트의 단점
- 참여자 수가 많지 않거나, 참여자의 실력이 좋지 않으면 소스 코드의 신뢰성을 보장하기 어렵습니다.
README.md 꾸미기
깃허브 사이트에서는 파일이름이 README인 경우 내용을 레포지토리 홈에 바로 보여줍니다.
일반적으로 README.md 파일에는 이 프로젝트가 어떤 프로젝트인지 설명하거나 프로그램의 주요 사용법을 알려주거나 프로그램을 실행시키려면 어떤 사전 작업이 필요한지를 알려주는 내용이 담겨있습니다.
파일의 확장자인 md는 markdown으로 이 파일에 마크다운으로 내용을 작성할 수 있다는 걸 나타냅니다.
마크다운이란 특정 규칙에 맞게, 간단한 텍스트만으로 어떤 표시를 해두면, 텍스트를 간단한 구문으로 서식화하여 HTML로 변환할 수 있게 하는 경량 마크업 언어입니다.
그래서 README.md는 텍스트만으로 꾸밀 수 있으며, 꾸미는 방식에는 마크다운 문법과 똑같이 #를 통해 텍스트를 제목처럼 보이게 만들어주는 방법, 글자를 통해 글씨를 굵게 만드는 방법등이 있습니다.
추가적으로 리모트 레포지트리에서 파일을 수정했다면 로컬 레포지트리에 git pull로 수정 사항을 반영하는 것을 잊지 마시길 바랍니다.
Github에서 사용하는 주요 커맨드 리스트
git push -u origin main | 로컬 레포지토리의 내용을 처음으로 리모트 레포지토리에 반영하고 싶을 때 사용합니다. |
git push | 로컬 레포지토리의 내용을 리모트 레포지토리에 보냅니다. |
git pull | 리모트 레포지토리의 내용을 로컬 레포지토리로 가져옵니다. |
git clone [프로젝트의 GitHub 상 주소] | GitHub에 있는 프로젝트를 내 컴퓨터로 가져옵니다. |
커밋 다루기
커밋 히스토리 보기 : git log, git show
Git을 사용하다보면 파일들에 많은 수정이 이루어지면서 많은 커밋을 하게 될 것이고 이때까지 한 커밋들을 커밋 히스토리라고 표현합니다.
커밋 히스토리를 확인한다면 프로젝트 디렉토리에서 그동안 있었던 변화들을 모두 확인할 수 있습니다.
이러한 커밋 히스토리를 보고 싶은 경우에 git log 커맨드를 사용합니다.
git log를 사용한다면 commit 아이디, 누가 커밋했는지, 날짜 및 시간, 커밋 메시지등을 확인할 수 있습니다.(commit이라는 글자 뒤에 있는 긴 문자열이 커밋의 아이디입니다.)
깃은 커밋을 구별하기 위해 커밋들에게 각각의 아이디를 부여하고 관리합니다.(커밋 아이디 = 커밋 해시)
만약 커밋 히스토리를 깔끔하고 예쁘게 보고 싶다면 git log — pretty=oneline 커맨드를 사용할 수 있습니다.
커밋 히스토리에는 가장 오래된 커밋이 가장 아래에 있고, 위에 있을수록 가장 최근의 커밋입니다.
그리고 히스토리를 확인하고 나서 특정 커밋을 자세히 확인하고 싶다면 git show [커밋 아이디] 커맨드를 사용할 수 있으며, 이 커맨드는 구체적으로 어떤 일이 있었는지 보여줄 수 있습니다.
git show [커밋 아이디] (커밋 아이디는 앞 4글자정도만 입력해도 알아서 판단하여 출력하기 때문에 4글자만 입력합니다.)
위 커맨드를 입력한다면, 이전 커밋과 해당 커밋의 변화를 자세히 나타내어 보여줍니다.
m 옵션 없이 커밋 메시지 작성하기 : git commit
파일이 수정되어 git add가 되어 staging area로 파일이 올라가고 커밋을 해야할 때, -m 옵션을 주지 않고 git commit 커맨드만 입력해서 커밋 메시지를 작성할 수 있습니다.
하지만 이 경우 vim 텍스트 에디터를 통해 커밋 메시지 작성 창으로 이동하게 되며, 메시지 작성 창을 다루는 방법을 설명하겠습니다.
우선 메시지를 작성하고 싶다면 i 를 눌러 입력모드로 변환한 뒤에 원하는 내용으로 메시지를 작성합니다.
내용 작성을 완료했다면, esc를 눌러 입력모드에서 나온 뒤에 :wq를 입력하여 커밋 메시지 작성을 완료합니다.
커밋 메시지 작성을 완료했다면 커밋 메시지가 저장되면서 성공적으로 커밋이 완료됩니다.
내용을 정리하면, -m옵션이 없더라도 git commit만을 이용해 텍스트 에디터에 커밋 메시지를 남길 수 있고, -m 옵션을 사용한 것보다 복잡한 긴 커밋 메시지를 남기는데 매우 유용합니다.
잘못 입력한 경우 최신 커밋 수정하기 : git commit —amend
가끔 커밋을 하고난 뒤에 코드를 좀 더 수정하고 커밋하고 싶거나 메시지를 다시 작성하고 싶은 마음이 들 수도 있으며, 어떤 경우에는 파일을 잘못 수정하고 커밋할 수도 있습니다.
이 경우에 아쉬운 부분들을 수정하고 다시 커밋을 하면 되는데 git은 자신이 했던 커밋 중에 최신 커밋을 다시 수정할 수 있는 기능을 제공하고 있습니다.
그래서 이러한 과정을 수행하고 싶은 경우 우선 파일의 수정이 필요하다면 파일을 수정한 후에 다시 git add를 합니다.
그리고 그 다음에 git commit --amend 커맨드를 입력하게 되면 다시 커밋 메시지를 작성할 수 있는 창이 나타납니다.
하지만 이번 경우에는 전과 다르게 원래 커밋했던 내용이 담겨 있는 창을 확인할 수 있는데, 이 때 커밋 메시지를 수정하거나 수정하지 않아도 괜찮습니다.
수정하고 싶다면, i 를 눌러 입력모드로 변환하고 수정하고 싶은 내용으로 작성한 뒤에, esc를 누르고 :wq를 입력해 작성을 완료합니다.
그러면 커밋 메시지가 정상적으로 수정되고, 정상적으로 커밋을 완료할 수 있습니다.
내용을 정리하면, 최신 커밋을 수정해서 다시 새로운 커밋으로 만들고 싶다면, git commit —amend 커맨드를 사용합니다.
커밋 생성 및 메시지 작성 가이드라인
커밋이란 Git에서 가장 핵심적인 개념으로, staging area의 현 상태를 그대로 하나의 버전으로 남기는 작업, 또는 그 결과물을 가리키는 말입니다.
커밋에는 일반적으로 커밋을 한 사용자 아이디, 커밋한 날짜 및 시간과 커밋 메시지로 구성되어 있습니다.
커밋 생성 가이드라인
- 최대한 작은 단위의 변화를 기준으로 커밋합니다. (하나의 커밋에는 하나의 수정사항, 하나의 이슈(issue)를 해결한 내용만 남긴다.)
- 나중에 다시 봤을 때 이해하는데 어려움이 없도록 작성합니다.
- 다른 동료 개발자들과 협업하는데 방해가 되지 않도록 커밋을 작성합니다.
- 현재 프로젝트 디렉토리의 상태가 그 내부의 전체 코드를 실행했을 때 에러가 발생하지 않는 상태인 경우에만 커밋을 합니다.
메시지 작성 가이드라인
- 커밋 메시지의 제목 (첫줄)과 상세 설명 (그 다음 줄) 사이에는 한 줄을 비워둡니다.
- 커밋 메시지의 제목 뒤에 온점 (.)을 붙이지 않습니다.
- 커밋 메시지의 제목의 첫번째 알파벳은 대문자로 작성합니다.
- 커밋 메시지의 제목은 명령조로 작성합니다.
- 커밋 메시지의 상세 내용에 왜 커밋을 했는지, 어떤 문제가 있었고, 적용한 해결책이 어떤 효과를 가지는지에 대한 내용이 포함되면 좋습니다.
- 다른 사람들이 자신의 코드를 바로 이해할 수 있다고 가정하지 말고 최대한 친절하게 작성합니다.
긴 커맨드에 alias 설정하기(aliasing ; 별칭 부여)
옵션의 길이가 긴 경우에 커맨드 전체가 길어지고 매번 커맨드를 입력하는데 불편함이 있을 때, Git에는 커맨드 전체에 별명을 붙여서 그 별명을 사용할 수 있도록 해주는 기능이 있습니다.
이 때 붙이는 별명을 alias라고 하고, 별명을 붙이는 행위를 aliasing이라고 합니다.
git log —pretty=oneline 라는 커맨드를 git history로 별칭을 부여한다고 예를 들면,
git config alias.history ’log —pretty=oneline’ 라고 커맨드를 작성할 수 있습니다. (템플릿 : git config alias.별칭 ‘별칭을 부여하고 싶은 커맨드’)
두 커밋 간의 차이 보기 : git diff
커밋 히스토리를 보다보면, 두 커밋 간의 차이를 보고 싶을 때가 있습니다.(어떤 코드가 추가 및 삭제되었는지)
이 경우에는 git log —pretty=oneline나 aliasing했을 경우 git history라고 입력하고 히스토리를 확인하고, git diff [커밋 아이디1] [커밋 아이디2] 커맨드를 사용하면 두 커밋 간의 차이를 확인할 수 있습니다. (아이디의 순서는 좀 더 이전의 커밋의 아이디를 앞에 작성한다.)
출력에서 나오는 빨간 줄은 이전 초록 줄은 이후 줄은 나타냅니다.
즉, git diff는 두 커밋 간의 변화를 알아볼 때 사용합니다.
HEAD의 의미
HEAD는 어떤 커밋 하나를 가리키며, HEAD는 보통 가장 최근에 한 커밋을 가리키고 있습니다.
커밋을 할 때마다 새로운 커밋이 생기며, HEAD는 매번 더 새로운 커밋을 가리킵니다.
working directory의 내부는 HEAD가 가리키는 커밋에 따라 구성되고 있습니다. 그 이유는 HEAD가 커밋을 가리키고 있어서라고 할 수 있습니다.
만약 HEAD가 이전의 커밋을 가리키도록 수정한다면 working directory 내부도 그때마다 과거 커밋에 해당하는 모습으로 바뀌게 됩니다.(물론 파일은 사라지지 않습니다. 그 해당 커밋의 모습을 보여준다고 생각하면 됩니다.)
만약 HEAD를 변경하고 싶다면 git reset [—옵션] 커맨드를 적용합니다.
좀 더 자세히 보면, HEAD가 브랜치를 가리키고, 브랜치가 커밋을 가리킵니다.
이전 커밋으로 git reset하기
HEAD가 최신 커밋보다 이전의 커밋을 가리키게 하고 싶을 때, git reset 옵션 [변경하고 싶은 커밋 아이디]커맨드를 사용합니다.
예) git reset —hard
git reset 커맨드를 사용한다면 HEAD가 과거의 커밋을 가리키게 할 수 있으며, 그에 따라 working directory의 내용도 과거의 커밋 모습으로 돌아가게 하는 것을 볼 수 있습니다.
정리한다면, git reset은 과거 커밋으로 아예 돌아가고 싶을 때 사용할 수 있습니다.
추가적으로 git reset에 관해 자세히 다루기 전에, staging area에 있던 것(파일)들은 커밋하고 나면 어떻게 되는지에 대해 알고 넘어갈 필요가 있습니다.
우선, staging area에 있던 것들은 커밋을 하더라도 그것과 상관없이 계속 상태 그대로 기록이 남아있습니다.
우리는 프로젝트 디렉토리 안의 파일을 수정하고 git add를 해서 staging area에 올린 다음 커밋을 합니다.
이 과정에서 git add를 할 때마다 staging area에서는 새로운 파일이 추가되거나 원래 있던 파일이 더 새로운 버전의 것으로 교체되거나 할 뿐이기 때문에 staging area에 있는 파일들이 사라지지 않는 것입니다.
git reset의 옵션
git reset 커맨드에서 무슨 옵션을 적용하는지에 따라 어떤 작업 영역이 reset 되는지가 다르기 때문에 옵션에 대해 잘 알고 넘어갈 필요가 있습니다.
옵션은 hard, mixed, soft 3가지가 있으며, 이에 대해 자세히 설명하겠습니다.
- git reset —hard [변경하고 싶은 커밋 아이디] : HEAD가 과거의 특정 커밋을 가리키고, staging area와 working directory를 과거의 특정 커밋의 내용과 똑같게 만듭니다.(모든 영역을 리셋)
- git reset —mixed [변경하고 싶은 커밋 아이디] : HEAD가 과거의 특정 커밋을 가리키고, staging area를 과거의 특정 커밋의 내용과 똑같게 만듭니다.(working directory를 제외한 영역만 리셋)
- git reset —soft [변경하고 싶은 커밋 아이디] : HEAD가 과거의 특정 커밋을 가리키도록 하는 옵션입니다.(repository만 리셋)
hard 옵션은 커밋 이후로 working directory에서 진행한 내용들이 모두 사라지고,복구를 할 수 없기 때문에 별로 권장되지 않습니다.
커밋 이후로 한 내용들이 전부 사라져도 상관 없을 경우에만 hard 옵션을 사용하고, 일반적으로는 soft, mixed 옵션을 사용하는 것이 좋습니다.
working directory | staging area | repository | |
git reset —hard | 변경 | 변경 | 변경 |
git reset —mixed | 변경 x | 변경 | 변경 |
git reset —soft | 변경 x | 변경 x | 변경 |
실수로 hard옵션을 적용하여 작업 내용이 날라간 경우에는 리모트 레포지토리부터 git pull로 다시 내용을 가져와서 리모트 레포지토리의 내용은 복구할 수 있습니다.
HEAD를 기준으로 git reset하기
일반적으로 git reset을 할 때는 git reset [옵션] [커밋 아이디]라는 형식으로 커맨드를 작성하는데 매번 아이디를 찾아야하는 불편함을 갖고 있습니다.
이런 경우에 커밋 아이디를 대체할 수 있는 방법이 있는데, 이는 ^와 ~n입니다.
**HEAD^**는 현재 HEAD가 가리키고 있는 커밋의 바로 이전 커밋을 나타내고 있어, 현재 커밋보다 하나 이전의 커밋을 HEAD로 변경하여 사용하고 싶다면 git reset —hard HEAD^ 라는 커맨드를 사용할 수 있습니다.
만약 현재 커밋보다 n만큼의 이전 커밋을 HEAD로 변경하고 싶다면 git reset —hard HEAD~n 라는 커맨드를 사용할 수 있습니다.
커밋에 tag 달기 (git tag)
커밋 메시지를 작성하고 커밋을 하다보면 커밋 중에서는 다른 것들보다 좀더 중요한 의미가 있는 커밋들도 있습니다.
그런 경우에는 중요한 커밋에 커밋 메시지뿐만 아니라 **태그(tag)**라는 것을 추가적으로 달아줄 수 있습니다.
보통 프로젝트에서 주요 버전의 시작점이 되는 커밋에 이렇게 태그를 달아주는데, 원하는 커밋에 태그를 달아주고 싶다면 git tag [태그명] [해당 커밋 아이디] 커맨드를 사용합니다.
- git tag만 입력 : 현재 tag 목록 확인 (프로젝트 디렉토리에 있는 모든 태그를 조회)
- git show [태그명] : 태그에 관련된 커밋과 여러가지 확인 가능(각 태그와 연결된 커밋이 보고 싶을 때)
- git tag -d [태그명] : 태그 제거하기
커밋을 다루는 주요 커맨드 리스트
git log | 커밋 히스토리를 출력합니다. |
git log --pretty=oneline | --pretty 옵션을 사용하면 커밋 히스토리를 다양한 방식으로 출력할 수 있습니다. --pretty 옵션에 oneline이라는 값을 주면 커밋 하나당 한 줄씩 출력해줍니다. |
git show [커밋 아이디] | 특정 커밋에서 어떤 변경사항이 있었는지 확인합니다. |
git commit --amend | 최신 커밋을 다시 수정해서 새로운 커밋으로 만듭니다. |
git config alias.[별명] [커맨드] | 길이가 긴 커맨드에 별명을 붙여서 이후로 별명으로 해당 커맨드를 실행할 수 있도록 설정합니다. |
git diff [커밋 A의 아이디] [커밋 B의 아이디] | 두 커밋 간의 차이를 비교합니다. |
git reset --soft [커밋 아이디] | HEAD가 특정 커밋을 가리키도록 이동시킵니다. |
git reset --mixed [커밋 아이디] | staging area도 특정 커밋처럼 리셋합니다. (옵션을 생략하면 --mixed 옵션이 적용됨) |
git reset --hard [커밋 아이디] | working directory도 특정 커밋처럼 리셋합니다. |
git reset —hard HEAD^ | 현재 커밋보다 하나 이전의 커밋을 HEAD로 변경합니다. |
git reset —hard HEAD~n | 현재 커밋보다 n만큼의 이전 커밋을 HEAD로 변경합니다. |
git tag [태그 이름] [커밋 아이디] | 특정 커밋에 태그를 붙입니다. |
이번 글에서는 Github를 사용하는 기초적인 방법 그리고 커밋을 다루는 방법들을 다루었습니다.
이번 글에 이어 다음 글에서 브랜치와 Git의 협업에 관련된 다양한 내용들을 다룰 예정입니다.
Git과 Github은 프로젝트 등을 진행할 때, 개발자라면 사용할 일이 있고 자주 사용할 수 있는 프로그램으로 내용을 숙지하거나 이번 기회를 통해 알아가면 좋을 것 같습니다.
글 읽어주셔서 감사합니다.
출처 및 참고자료 : 코드잇 사이트 강의 'Git' https://www.codeit.kr/topics/git
'프로그래밍 > Git' 카테고리의 다른 글
Git 협업하기 개념 정리 1️⃣ (Git을 통한 협업) (0) | 2024.08.06 |
---|---|
[Git 개념 정리] Git 개념 정리 5️⃣ (Git에서 사용하는 주요 커맨드 리스트) (0) | 2024.07.26 |
[Git 개념 정리] Git 개념 정리 4️⃣ (Git을 자유자재로 활용) (0) | 2024.07.26 |
[Git 개념 정리] Git 개념 정리 3️⃣ (브랜치 사용하기, Git을 통한 협업) (6) | 2024.07.25 |
[Git 개념 정리] Git 개념 정리 1️⃣ (Git, Github, Git 다루기) (0) | 2024.07.20 |
데이터 분석을 공부하고 카페를 열심히 돌아다니는 이야기
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!