※버전 : 유의미한 변환가 결과물로 저장된 것
패치 : 시급한 오류 해결을 동반하거나 규모가 작은 버전
업데이트: 새롭게 추가되는 기능을 담은 버전
Git : 버전 관리를 도와주는 소프트웨어(명령어로 동작하는 소프트웨어)
Github : 원격 저장소 호스팅 서비스 (깃으로 버전을 관리하는 프로젝트들이 모여 있는 웹 사이트)
깃 설정하기
$ git config —global user.name “만든 사람”
$ git config —global user.email “이메일주소”
$ git config —list
깃이 관리하는 3개의 공간 ⇒ 작업 디렉터리, 스테이지, 저장소
작업 디렉터리 : 버전 관리의 대상이 위치하는 공간
스테이지( = 스테이징 영역, 인덱스 ) : 작업 디렉터리 내에서 변경된 파일들 중에서 새로운 버전이 될 파일만 특별한 공간으로 옮기는 작업
저장소 : 버전이 만들어지고 관리되는 공간 (최종 결과물)
작업 디렉터리에서 버전이 될 파일을 스테이지로 옮기는 것을 스테이지에 추가**(add)** or 해당 파일을 스테이지 시킨다**(staged)**
저장소에 새로운 버전을 만드는 것 (commit)
{작업 디렉터리 변경 순서}
1) 변경 사항 생성 → 2) add → 3) commit 의 과정으로
1) 작업 디렉터리 → 2) 스테이지 → 3) 저장소 의 순서로 새로운 버전으로 만들어짐
.gitignore : 변경 사항이 생기더라도 버전에 포함하고 싶지 않은 파일/폴더 즉, 무시할 파일/폴더 목록을 적은 파일
확장자를 포함한 파일 및 폴더 이름이 **“.gitignore”**이어야 함
ex) “.gitginore.txt” 이런 형태는 안됨
.gitignore 파일 및 폴더 내부에 내용으로 추가하지 않을 파일이나 폴더 명을 작성하면 그 폴더가 생성되더라도 커밋할 내용에 포함되지 않음
ex)
- 파일일 경우 ⇒ 내용에 파일명.확장자명
- 폴더일 경우 ⇒ 내용에 파일명/
각각의 커밋에는 고유한 커밋 해시가 존재함 ⇒ 이걸로 커밋을 구분
커밋한 내용들이 쌓여 웹 서비스를 완성하면 개발한 소프트웨어를
다른 사용자들에게 오픈하는 릴리스(release)과정을 거침
**특정 커밋(버전)**에 태그를 붙이면 유의미한 커밋
vX. Y. Z < = 태그의 가장 보편적인 표기법
- X : 주 버전 - 가장 중요한 버전(새롭게 변경된 버전이 기존의 버전과 호환되지 않을 정도로 큰 변화가 있을 때 수정)
- Y : 부 버전(새롭게 변경된 버전이 기존의 버전과 호환되는 데에는 문제가 없지만 새로운 기능을 추가했을 때 수정)
- Z : 수 버전(기존에 내놓은 버전과 문제 없이 호환되며 버그를 수정한 정도의 작은 변화가 있을 때 수정)
⇒ 각 커밋에는 커밋해시라는 고유한 문자열이 존재 ⇒ 쌓인 커밋에 태그라는 꼬리표를 붙임 ⇒ 버전을 작성하는 규칙으로 버전을 작성 ⇒ 사용자에게 공개할 준비가 끝나면 릴리스함
커밋 되돌리기
revert : 버전을 되돌리되, 되돌아간 상태에 대한 새로운 버전(커밋)을 만드는 형식
1~5까지 버전을 작성하고 4번째 버전으로 revert를 하게 되면 1~5 다음 6버전에 4버전의 내용이 작성됨
reset : 되돌아갈 버전의 시점으로 완전하게 되돌아가는 방식 / 즉, 되돌아갈 버전 이후의 버전은 삭제되는 방식
1~5까지 버전을 작성하고 3번째 버전으로 reset을 하게 되면 4,5 버전은 삭제됨
- soft : 작업 디렉토리 내 변경 사항과 스테이지에 추가된 변경 사항은 유지하되, 커밋했다는 사실만 되돌리는 reset(커밋만 복원)
- mixed : 작업 디렉터리 내 변경 사항은 유지하되, 스테이지와 커밋을 되돌리는 reset(스테이지까지 복원)
- hard : 작업 디렉터리 내 변경 사항까지 통째로 되돌리는 reset(작업 디렉토리까지 복원)
이 커밋까지 현재 브랜치를 초기화(마우스 오른쪽)
⇒ reset의 3가지 종류
<커밋의 순서>
- 작업 디렉토리에서 변경 사항 생성하기 ⇒ 2) 스테이지로 올리기 ⇒ 3) 커밋하기
Just 스테이지에 올라간 상태 & 커밋 전 상태 또는 스테이지에 올라가기 전 상태 & 커밋 x
스태시(stash) - 임시 저장 기능(작업 디렉터리에서 생성한 모든 변경 사항이 임시 저장됨)
- 마음에 들지 않지만 버리기는 아까운 경우
- 다른 더 중요한 일을 처리해야 할 때
- 변경 사항을 추적하는(tracked) 파일에만 사용 가능 즉, 스테이지에 이미 올라와 있거나 한 번이라도 커밋한 적이 있는 파일에만 사용 가능 {untracked 파일 불가능}
스태시에 임시저장을 하게되면 작업 디렉터리에는 비워지게 되고 스태시에 저장한 파일에서 마우스 오른쪽으로 스태시 적용을 누르게 되면 작업 디렉터리에 다시 반영이 됨
브랜치 - 버전의 분기
- 브랜치를 나눈다.
- 각자의 브랜치에서 작업한다.
- (필요한 경우) 나눈 브랜치를 합친다.
master 브랜치(main 브랜치) - 최초의 브랜치
HEAD : 현재 작업 중인 브랜치의 최신 커밋
체크아웃 : 특정 브랜치에서 작업할 수 있도록 작업환경을 바꾸는 것
브랜치 병합하기 - merge
빨리 감기 병합 (fast-forward merge)
- foo 브랜치가 master 브랜치에서부터 뻗어나온 시점부터 병합되는 순간까지 master 브랜치에 어떤 새로운 커밋도 없어서 master 브랜치 이후 foo 브랜치에서 작성한 내용을 그대로 옮겨 커밋하는 것
충돌 - 병합하려는 두 브랜치가 서로 같은 내용을 다르게 수정한 상황
ex) 다른 브랜치가 a.txt 파일의 첫 문장을 각각 A 와 B 로 수정한 상황
충돌 해결하기 : 같은 내용을 다르게 수정한 브랜치 중 어떤 브랜치 내용을 최종적으로 반영할지를 직접 선택하는 것
충돌이 발생한 파일에는 <<<<<<<, >>>>>>>, ======= 기호가 표시
======== 기호를 기준으로 윗 부분 <<<<<< ======= 기호를 기준으로 아랫 부분 >>>>>>> 에서 둘 중 어느 부분을 고르라는 표시
충돌 해결 ⇒
- ‘내것’ 을 이용해 해결 (현재 체크아웃된 브랜치의 내용으로 해결)
- ‘저장소것’ 을 이용해 해결 (병합하려는 브랜치의 내용으로 해결)
충돌을 해결하고 나면 충돌을 해결할 내용을 결정하고 그 내용을 다시 커밋을 해야 충돌이 해결된 것
브랜치 재배치하기 - rebase : 브랜치가 뻗어나온 기준점을 변경하는 것
- master 브랜치의 2번 째 커밋에서 ku브랜치가 뻗어나온 상황을 master 브랜치의 4번 째 커밋에서 ku브랜치가 뻗어나오도록 변경하는 것
⇒ 브랜치를 재배치하려면 재배치하려는 브랜치로 체크아웃하고 재배치하려는 브랜치의 커밋에 마우스 오른쪽 버튼을 클릭하여 클릭 후 재배치를 클릭합니다.
깃허브 레포지터리 삭제하는 방법
Github : 원격 저장소 호스팅 서비스
README.md : 해당 프로젝트의 설치 방법, 사용 방법 등을 담고 있는 파일(일종의 안내서)
백업 & 협업
생성한 github repository를 삭제하려면 우측 상단에 setting 메뉴에서 danger zone에서 delete this repository를 클릭하면 됨
- 클론(clone) : 원격 저장소를 복제하기
- 푸시(push) : 원격 저장소에 밀어넣기
- 패치(fetch) : 원격 저장소를 일단 가져만 오기
- 풀(pull) : 원격 저장소를 가져와서 합치기
클론: 원격 저장소 복제하기
깃허브상에 존재하는 원격 저장소를 로컬로 복사하여 가져오는 방법
Download ZIP을 클릭하면 원격 저장소의 내용을 압축 파일로 다운로드
푸시: 원격 저장소에 밀어넣기
원격 저장소에 로컬 저장소의 변경 사항을 밀어넣는 것
패치(fetch): 원격 저장소를 일단 가져만 오기
원격 저장소의 변경 사항들을 가져만 오는 방법
풀: 원격 저장소를 가져와서 합치기
패치와 병합을 동시에 하는 방법
풀 리퀘스트: 깃허브로 협업하기
원격 저장소가 내 변경 사항을 풀(pull)하도록 요청(request)하는 방법
푸시 권한이 없는 원격 저장소에 코드를 밀어넣는 방법?
풀 리퀘스트
{풀 리퀘스트 단계}
- 기여하려는 저장소를 본인 계정으로 포크하기
→ 일반적으로 자신이 소유하지 않는 원격 저장소에 푸시할 수 없습니다. 그렇기에, 자신의 계정으로 원격 저장소를 복제하는데 이 과정을 포크
- 포크한 자신의 계정의 저장소를 클론하기
→ 자신이 소유하지 않은 원격 저장소에 푸시하기는 불가능하여도 포크한 원격 저장소에 푸시하기는 가능합니다. 그래서 포크한 저장소를 클론합니다.
- 브랜치 생성 후 생성한 브랜치에서 작업하기
→ 새로운 브랜치를 생성한 후 해당 브랜치에서 변경 사항을 만들고 커밋합니다.
- 작업한 브랜치 푸시하기
→ 생성한 브랜치를 푸시합니다. 그러면 깃허브에 풀 리퀘스트 버튼이 생성됩니다.
- 풀 리퀘스트 보내기 (Compare & pull request)
→ 마지막으로 풀 리퀘스트를 보내면 끝이 납니다.
포크(fork) : 원격 저장소를 자신의 계정으로 복제하는 방법 / 즉, 소유하지 않은 원격 저장소에 직접 푸시할 수 없지만, 자신의 계정으로 포크(복제)한 원격 저장소에 푸시할 수 있습니다.
풀 리퀘스트를 받은 사람은 Merge pull request를 클릭하여 풀 리퀘스트를 병합함
⇒ 저장소의 소유자가 받은 코드를 풀 리퀘스트를 병합하면 풀 리퀘스트의 상태가 Open → Merged로 변경이 됨
- Collaborator로 추가하여 푸시 권한 주기
⇒ Settings에서 Collaborators를 클릭한 뒤 Add people을 클릭하여 협업자를 추가함
명령어로 깃 다루기
.git init : 로컬 저장소 만들기
.git status : 작업 디렉터리 상태 확인하기
.git add : 스테이지에 올리기
.git commit : 커밋하기
.git log : 커밋 조회하기
.git tag : 태그 추가/조회/삭제하기
1단계
git init : 로컬 저장소 만들기
- 저장소를 만들려는 경로에서 Git Bash 열기
- 원하는 경로에서 깃 배시가 열리면 자신의 저장하려는 주소가 맞는지 확인
- $ git init를 입력합니다.
이때, Initialized empty Git repository in <경로> 메시지가 뜨면 성공입니다.
→ 저장소가 만들어지면 .git 폴더가 만들어지면 성공한 것
💡
시작 메뉴에서 Git Bash열기
이 경우 cd <경로> 명령어로 원하는 경로로 이동할 수 있습니다.
ex) cd C:\test로 이동하고 싶다면 cd C:\test를 입력하면 됩니다.
현재 경로를 확인하는 명령어는 pwd입니다.
2단계
git status : 현재 작업 디렉터리 상태 확인하기
$ git status
On branch master
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
a.txt
nothing added to commit but untracked files present (use "git add" to track)On branch master : 현재 기본 브랜치, 즉 master 브랜치에 존재함을 의미
No commits yet : 현재 아무런 커밋도 하지 않았음을 의미
Untracked files : 깃이 기존에 변경 사항을 추적하지 않은 대상을 나타냄
3단계
git add: 스테이지에 올리기
$ git add <스테이지에 추가할 대상>
ex) $ git add a.txt ⇒ a.txt 파일을 스테이지에 추가
📌 다음과 같이 경고 메시지가 뜰 수 있는데, 이는 윈도우의 개행(줄 바꿈) 문자와 깃 배시가 따르는 리눅스의 개행 문자가 다르기 때문에 발생하는 메시지입니다. 무시해도 상관없습니다.
warning : LF will be replaced by CRLF i a.txt.
The file will have its original line endings in your working directory
한꺼번에 스테이지에 추가하기
$ git add . 명령으로 여러 개의 파일을 한 번에 스테이지로 올릴 수 있습니다.
$ git add .
Administrator@YounghakBook MINGW64 ~/OneDrive/바탕 화면/git (master)
$ git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: a.txt
new file: b.txt
new file: c.txt
new file: d.txt
new file: e.txtgit status를 입력해 추가한 파일이 정상적으로 추가되었는지 확인합니다.
$ git status
On branch master
No commits yet
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: a.txt위 내용이 뜨면 성공한 것입니다!
4단계
git commit: 커밋하기
$ git commit -m “커밋 메시지” 또는 git commit —message “커밋 메시지”
$ git commit -m 'first commit'
[master (root-commit) 2a9ac6b] first commit
5 files changed, 1 insertion(+)
create mode 100644 a.txt
create mode 100644 b.txt
create mode 100644 c.txt
create mode 100644 d.txt
create mode 100644 e.txt$ git log : 저장소의 커밋 목록을 출력하는 명령
$ git log
commit 2a9ac6b76574fb09a27ac4b218662cab48cf76c7 (HEAD -> master)
Author: YongHak <charismayoung1993@gmail.com>
Date: Fri Jun 28 17:49:20 2024 +0900
first commit💡 git commit -am “커밋 메시지” 명령은 git commit -a -m “커밋 메시지”,
git commit —all —message “커밋 메시지”명령과 동일커밋 해시 우측의 HEAD → master는 현재 HEAD가 master 브랜치에 있음을 나타냅니다.
git add (버전으로 만들 파일을 스테이지로 올리는 명령) + git commit -m “커밋 메시지”(이를 버전으로 만드는 명령) ⇒ 이 2가지의 명령을 합쳐서 git commit -am “커밋 메시지”명령으로 한 번에 사용할 수 있습니다.
즉, git commit -am “커밋 메시지”명령으로 스테이지에 추가(add) 및 커밋(commit)을 동시에 할 수 있습니다.
a.txt 파일에 일부 내용을 추가하고 git status로 변경된 내용을 확인
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: a.txt
no changes added to commit (use "git add" and/or "git commit -a")
→ modified: a.txt로 a.txt 파일이 수정되었음을 의미합니다.
git commit -am “커밋 메시지” 는 깃이 변경 사항을 추적하는(tracked) 파일에만 사용이 가능합니다.
즉, 스테이지에 이미 올라와 있거나 1번이라도 커밋한 적이 있는 파일에만 사용 가능합니다.
기존에 변경 사항을 추적하지 않은(untracked) 파일은 이 명령어를 사용할 수 없습니다.
위 2가지 명령어는 커밋 메시지를 제목정도로만 간단하게 작성할 때 사용합니다.
a.txt 파일에 추가로 수정한 뒤에 git add a.txt 명령으로 a.txt 파일을 스테이지로 추가합니다.
여기에 git commit을 입력하게 되면
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
# Changes to be committed:
# modified: a.txt
#
~
~
~
~
third commit
This is my third commit
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
# Changes to be committed:
# modified: a.txt
#
~
위 처럼 커밋 메시지를 입력하고 ESC키를 눌러서 입력 모드를 명령
모드로 변경하면 하단의 INSERT가 사라지고 여기에 :write 또는
:w를 입력한 뒤 Enter를 누르면 입력한 내용이 저장됩니다.
그리고 :quit 또는 :q 입력 후 Enter를 누르면 입력 창이 닫힙니다.
위 창이 나오게 되는데 입력하려면 a 또는 i를 입력하여 입력 모드로 전환하고 “INSERT”가 나오게 되면
입력이 가능해집니다.
$ git log
commit 3a785c93b03f16feae2a888756efe79fe4ad47b7 (HEAD -> master)
Author: YongHak <charismayoung1993@gmail.com>
Date: Fri Jun 28 18:15:31 2024 +0900
sdfasdf
asdffsdafasf
.
.
.git log로 이제까지 커밋한 내용을 확인합니다.
5단계
git log: 커밋 조회하기
git log —oneline : 커밋 목록을 1줄로 출력해주는 옵셥 ( 짧은 커밋 해시 + 커밋 메시지 제목만 출력)
$ git log --oneline
3a785c9 (HEAD -> master) sdfasdf
8c0f12f third commit
4c4fc86 first commit
2a9ac6b first commit
git log —patch 또는 git log -p : 해당 커밋으로 어떤 파일이 어떻게 수정되었는지를 출력합니다.
$ git log -p
commit 3a785c93b03f16feae2a888756efe79fe4ad47b7 (HEAD -> master)
Author: YongHak <charismayoung1993@gmail.com>
Date: Fri Jun 28 18:15:31 2024 +0900
sdfasdf
asdffsdafasf
.
.
.
git log —graph : 각 커밋을 그래프의 형태로 출력하는 방법
$ git log --graph
* commit 3a785c93b03f16feae2a888756efe79fe4ad47b7 (HEAD -> master)
| Author: YongHak <charismayoung1993@gmail.com>
| Date: Fri Jun 28 18:15:31 2024 +0900
|
| sdfasdf
|
| asdffsdafasf
|
* commit 8c0f12faafcbecc48e88ba27909c962005a1170b
| Author: YongHak <charismayoung1993@gmail.com>
| Date: Fri Jun 28 18:08:19 2024 +0900
|
| third commit
|
| This is my third commit
|
* commit 4c4fc86a68868d0a6fa3def74c2b38072e84a907
| Author: YongHak <charismayoung1993@gmail.com>
| Date: Fri Jun 28 17:58:54 2024 +0900
|
| first commit
|
이렇게 작성하면 브랜치별 커밋의 가독성을 높일 수 있습니다.
git tag <태그> : 태그 추가하기
$ git tag v1.0.0
Administrator@YounghakBook MINGW64 ~/OneDrive/바탕 화면/git (master)
$ git log
commit 3a785c93b03f16feae2a888756efe79fe4ad47b7 (HEAD -> master, tag: v1.0.0)
Author: YongHak <charismayoung1993@gmail.com>
Date: Fri Jun 28 18:15:31 2024 +0900
sdfasdf
asdffsdafasf
commit 8c0f12faafcbecc48e88ba27909c962005a1170b
Author: YongHak <charismayoung1993@gmail.com>
Date: Fri Jun 28 18:08:19 2024 +0900
third commit$ git tag v0.0.1 4c4fc86
commit 4c4fc86a68868d0a6fa3def74c2b38072e84a907 (tag: v0.0.1)
2번 째 해시함수에 태그를 붙여서 커밋을 합니다.
git tag —list : 태그 조회하기
태그 목록을 조회하는 명령 git tag —list 또는 git tag -list
$ git tag --list
v0.0.1
v1.0.0
git tag —delete <태그> : 태그 삭제하기
$ git tag --delete v0.0.1
Deleted tag 'v0.0.1' (was 4c4fc86)
$ git tag
v1.0.0
태그를 조회하였을 때 1개의 태그만 나오므로 정상적으로
삭제된 것을 확인할 수 있습니다!버전 비교하기
.git diff : 최근 커밋과 작업 디렉터리 비교하기
.git diff —staged : 최근 커밋과 스테이지 비교하기
.git diff <커밋> <커밋> : 커밋끼리 비교하기
.git reset <되돌아갈 커밋> : <되돌아갈 커밋>으로 되돌아가기
.git revert <취소할 커밋> : <취소할 커밋>이 취소된 새로운 커밋 만들기
.git stash : 변경 사항 임시 저장하기
.git stash list : 임시 저장한 내역 조회하기
.git stash apply <스태시> : 임시 저장한 작업 적용하기
.git stash drop <스태시> : 임시 저장한 작업 삭제하기
.git branch <브랜치> : 브랜치 나누기
.git checkout <브랜치> : 체크아웃하기
.git merge <브랜치> : 브랜치 병합하기
.git rebase <브랜치> : 브랜치 재배치하기
git diff: 최근 커밋과 작업 디렉터리 비교하기
커밋한 이후로 작업 디렉터리에서 무엇을 수정했는지 확인하기 위해 사용합니다.
$ git diff
warning: in the working copy of 'a.txt', CRLF will be replaced by LF the next time Git touches it
diff --git a/a.txt b/a.txt
index 597b079..6eba831 100644
--- a/a.txt
+++ b/a.txt
@@ -1,8 +1,8 @@
-Aasdfasdfasfa
-asdfa
-sadf
-asd
-f
-sad
-fsa
-asdfasdfas
\ No newline at end of file
+A
+B
+C
+D
+E
git diff —staged : 최근 커밋과 스테이지 비교하기
스테이지에 추가된 항목과 최근 커밋의 차이를 보여주는 명령은 git diff —cached 또는 git diff —staged 입니다.
git diff <커밋> <커밋> :커밋끼리 비교하기
커밋 간 차이를 비교하는 명령은 git diff <커밋(해시함수)> <커밋(해시함수)>
git diff <이 커밋을 기준으로> <이 커밋이 달라진 점>$ git diff 8c0f12f 2a9ac6b
diff --git a/a.txt b/a.txt
index dadf4cf..8c7e5a6 100644
--- a/a.txt
+++ b/a.txt
@@ -1,7 +1 @@
-Aasdfasdfasfa
-asdfa
-sadf
-asd
-f
-sad
-fsa
+A
git diff <브랜치> <브랜치> : 브랜치끼리 비교하기
git diff <브랜치> <브랜치> : 2개의 브랜치의 차이를 알려주는 방식
$ git diff master foo
diff --git a/a. txt b/a.txt
index f70f10e..35d242b 100644
--- a/a.txt
+++ b/a.txt
@@ -1 +1,2 @@
A
+B작업 되돌리기 ⇒ reset & revert
git reset <되돌아갈 커밋(해시함수)> : 예전 커밋으로 되돌아가기
- soft reset : 커밋만 되돌리기
⇒ 3 번째 커밋으로 soft reset하는 것은 곧 4 번째 커밋이 만들어진 그 순간만을 되돌리는 것
git reset —mixed <되돌아갈 커밋(해시함수)>
- mixed reset : 스테이지까지 되돌리기
⇒ 커밋한 사실과 스테이지에 추가한 사실만을 되돌릴 뿐 파일을 수정한 내역까지 되돌리지는 않는 방식
git reset —hard <되돌아갈 커밋>
- hard reset : 작업 디렉터리까지 되돌리기
⇒ 파일을 수정했던 사실까지 완전하게 되돌리는 방식
git revert <취소할 커밋> : 취소된 새로운 커밋 만들기
revert : 해당 커밋을 취소한 새로운 커밋을 추가하는 방식
헷갈리는 point! ⇒ git reset <2 번째 커밋> 은 2 번째 커밋으로 돌아가는 명령이지만 git revert <2 번째 커밋> 은 2 번째 커밋을 취소한 새로운 커밋을 추가하는 명령입니다!
Revert "fourth commit"
This reverts commit a71f35f8fa9a2064ab84012ea868a2ef94390b8f.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
# Changes to be committed:
# modified: a.txt
#
# Untracked files:
# ada
#
~
~
~
~
~작업 임시 저장하기
git stash : 변경 사항 임시 저장하기
- stash 명령은 기본적으로 tracked 상태의 파일에 대해서만 사용할 수 있습니다.
→ git stash -m “메시지” 또는 git stash —message “<메시지>” 명령으로 간단한 메시지와 함께 임시 저장할 수 있습니다.
$ git stash -m "add B"
Saved working directory and index state On master: add Bgit stash list : 임시 저장된 작업 내역 조회하기
stash한 작업 목록을 조회하는 명령은 git stash list
git stash apply <스태시> : 임시 저장된 작업 적용하기
임시 저장된 작업을 작업 디렉터리에 적용하는 것
git stash apply stash@{0} 은 stash에 임시 저장된 파일 stash@{0}을 현재 작업 디렉터리에 포함시키는 것
git stash drop <스태시> : 임시 저장된 작업 삭제하기
git stash drop stash@{0} : stash@{0} 명령으로 기존 저장소 내용을 삭제
git stash clear : 임시 저장된 작업을 전부 삭제하기
브랜치 관리하기
현재 작업 중인 브랜치의 이름이 master인 것을 알 수 있습니다!
$ git branch : 현재 작업중인 브랜치의 이름이 * 브랜치 명* 으로 표시됨
$ git branch
* foo => 현재 체크아웃된 브랜치 명
mastergit branch <브랜치> : 브랜치 나누기
$ git branch 브랜치 명 : 브랜치 명을 가진 브랜치 생성
$ git branch foo => foo라는 브랜치 생성
git checkout <브랜치> : 체크아웃하기
체크아웃 : 해당 브랜치로 작업 환경을 바꾸는 것
⇒ master인 브랜치에서 파일 3개를 작성하고 master 브랜치에서 foo 브랜치로 체크아웃하여 브랜치를 이동한 뒤에 foo 브랜치에서 파일 2개를 더해 총 5개의 파일을 작성하고 다시 master 브랜치로 체크아웃을 이동학데 되면 master 브랜치에는 기존에 작성한 3개의 파일만 남게 됩니다
브랜치를 만듦과 동시에 체크 아웃하기!
새로운 브랜치를 만드는 명령은 git branch <브랜치> , 특정 브랜치에 체크아웃하는 명령은 git checkout <브랜치>
⇒ 위 2가지 기능을 동시에 하는 명령어는 git checkout -b <브랜치>
브랜치 명이 bar인 브랜치를 생성 및 체크아웃하는 명령은
$ git checkout -b bar
git merge <브랜치> : 브랜치 병합하기
git merge <병합할 브랜치> : 브랜치를 병합하는 명령
→ 만일 foo 브랜치를 master 브랜치에 병합하고 싶다면 master 브랜치로 체크 아웃한 뒤 git merge foo 명령을 입력
$ git checkout master
$ git merge foo
충돌 해결
Administrator@YounghakBook MINGW64 ~/OneDrive/바탕 화면/git (master)
$ git checkout foo
Switched to branch 'foo'
Administrator@YounghakBook MINGW64 ~/OneDrive/바탕 화면/git (foo)
$ git add a.txt
Administrator@YounghakBook MINGW64 ~/OneDrive/바탕 화면/git (foo)
$ git commit -m "foo commit"
On branch foo
nothing to commit, working tree clean
Administrator@YounghakBook MINGW64 ~/OneDrive/바탕 화면/git (foo)
$ git commit a.txt
[foo 6633e24] 첫 번째 커밋
1 file changed, 1 insertion(+), 1 deletion(-)
Administrator@YounghakBook MINGW64 ~/OneDrive/바탕 화면/git (foo)
$ git checkout master
Switched to branch 'master'
Administrator@YounghakBook MINGW64 ~/OneDrive/바탕 화면/git (master)
$ git merge foo
Auto-merging a.txt
CONFLICT (content): Merge conflict in a.txt
Automatic merge failed; fix conflicts and then commit the result.a.txt 파일을 첫 문장을 동일하게 수정하고 각각 master 브랜치와 foo 브랜치에 내용을 추가하고 나서 $ git checkout master로 전환 후 $ git merge foo 라는 병합을 하게 되면 충돌이 발생!
<<<<<<< HEAD
master
=======
fooasdfasdfasf
>>>>>>> foo충돌이 발생한 후 a.txt 파일을 열게 되면 위의 코드처럼 내용이 작성됨
======= 기호의 윗 부분은 HEAD가 가리키는 브랜치 즉, master 브랜치
======= 기호의 아랫 부분은 HEAD가 가리키는 브랜치 즉, foo 브랜치
여기서 병합의 결과로 master 브랜치의 내용과 foo 브랜치의 내용 중
선택할지 결정해야 합니다. 만약, 병합의 결과로 master 브랜치의
내용을 반영하려 하면 a.txt 파일에 master 브랜치의 변경사항을
작성하고 나서 $ git add a.txt 명령을 입력하고 $ git commit을
입력하게 되면
Merge branch 'foo'
# Conflicts:
# a.txt
#
# It looks like you may be committing a merge.
# If this is not correct, please run
# git update-ref -d MERGE_HEAD
# and try again.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
# All conflicts fixed but you are still merging.
#
# Changes to be committed:
# modified: a.txt
#
이러한 커밋 메시지가 나오게 됩니다.
여기에 :wq를 작성하고 화면을 나오게 되면
$ git commit
[master 09a8f20] Merge branch 'foo'
이렇게 성공적으로 병합이 되었다고 나오게 됩니다.git branch -d <브랜치> : 브랜치 삭제하기
git branch -d <브랜치> 또는 git branch —delete <브랜치>로 입력하여 브랜치를 삭제합니다.
<aside>
💡 **이때, foo 브랜치를 삭제하려고 하면 checkout된 상태를 foo가 아닌 master 브랜치로 바꾸게 작성하고 $ git branch -d foo로 작성하게 되면 아래와 같이 성공적으로 브랜치가 삭제됩니다.**
$ git branch -d foo
Deleted branch foo (was 6633e24).
</aside>
git rebase <브랜치> : 브랜치 재배치하기
rebase - 브랜치가 뻗어나온 기준점을 옮기는 방법
⇒ 예를 들어, master 브랜치의 2번째 커밋으로 부터 foo 브랜치가 뻗어나온 것을 master 브랜치의 4번째 커밋으로 foo 브랜치가 뻗어나도록 옮기는 역할을 수행
명령어 정리
명령어로 깃허브 다루기
.git clone : 원격 저장소를 복제하기
.git remote : 원격 저장소를 추가, 조회, 삭제하기
.git push : 원격 저장소에 밀어넣기
.git fetch : 원격 저장소를 일단 가져만 오기
.git pull : 원격 저장소를 가져와서 합치기
.git <명령> —help : 매뉴얼 페이지 보기
깃허브와 상호작용
- 클론(clone) : 원격 저장소를 복제하기
- 리모트(remote) : 원격 저장소를 추가하고, 조회하고, 삭제하기
- 푸시(push) : 원격 저장소에 밀어넣기
- 패치(fetch) : 원격 저장소를 일단 가져만 오기
- 풀(pull) : 원격 저장소를 가져와서 합치기
git clone : 원격 저장소를 복제하기
git clone <원격 저장소>
⇒ git clone 깃허브 url
Administrator@YounghakBook MINGW64 ~/OneDrive/바탕 화면/git (bar)
$ git clone https://github.com/JeonYongHak/test-repo.git
Cloning into 'test-repo'...
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 6 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (6/6), done.
위 내용처럼 화면에 표시가 되면 git clone이 성공한 것
※ 특정 경로로 클론 받기 ⇒ git clone <원격 저장소> <클론받을 경로> 형식으로 명령을 입력하면 됩니다.
따로 <클론받을 경로>로 지정하지 않을 경우 암묵적으로 현재 경로(git bash가 열려진 곳)에서 클론이 실행됩니다.
git remote : 원격 저장소를 추가, 조회, 삭제하기
Github에서 new repository를 생성하고 “test-repo(파일명 자유)” 파일을 생성하고 파일 내부에서 $ git init을 작성하여 로컬 저장소를 만듭니다.
⇒ 현재는 로컬 저장소 test-repo는 원격 저장소 test-repo의 존재를 모르기에 로컬 저장소와 원격 저장소 간의 상호작용을 하려면 원격 저장소 test-repo를 로컬 저장소 test-repo에 추가해야 합니다.
※ 로컬 저장소에 원격 저장소를 추가하는 명령은 git remote add <원격 저장소 이름> <원격 저장소 경로> 입니다.
git remote add origin(원격 저장소 이름) https://github.com/JeonYongHak/test.git
위 내용처럼 명령을 작성합니다.$ git remote 내용을 작성하게되면 방금 추가한 원격 저장소의 이름
origin이 출력되면 성공적으로 연결이 된 것입니다.
$ git remote
origin- git remote -v 또는 git remote —verbose 명령을 통해서 원격 저장소의 이름과 경로를 함께 확인할 수 있습니다.
⇒ 위 과정을 통해 로컬 저장소와 원격 저장소 간의 상호작용 가능해 졌습니다.
- git remote rename <기존 원격 저장소 이름> <바꿀 원격 저장소 이름> 으로 원격 저장소의 이름을 바꿀 수 있습니다.
- git remote remove <원격 저장소 이름> 으로 원격 저장소를 삭제 가능합니다.
Administrator@YounghakBook MINGW64 ~/OneDrive/바탕 화면/git/test-repo (main)
$ git remote remove changed
Administrator@YounghakBook MINGW64 ~/OneDrive/바탕 화면/git/test-repo (main)
$ git remote
이처럼 삭제하고 나서 $ git remote를 입력했을 때 아무런 정보가 나오
지 않으면 성공적으로 삭제된 것 입니다.git push : 원격 저장소에 밀어넣기
로컬 저장소의 커밋(들)을 처음 원격 저장소로 푸시하는 경우,
박스 안에 있는 명령들을 그대로 복사 붙여넣기 하면 됩니다.
git remote add origin(원격 저장소 이름) https://github.com/JeonYongHak/test.git(원격 저장소의 주소)
git branch -M main
git push -u origin mainAdministrator@YounghakBook MINGW64 ~/OneDrive/바탕 화면/git/test-repo (main)
$ git push -u origin main
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 16 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (9/9), 2.05 KiB | 2.05 MiB/s, done.
Total 9 (delta 0), reused 6 (delta 0), pack-reused 0 (from 0)
To https://github.com/JeonYongHak/test.git
* [new branch] main -> main
branch 'main' set up to track 'origin/main'.
아래 내용이 나타나게 되면 성공적으로 원격 저장소로 푸시한 것 입니다.- $ git remote add origin git@github.com:First-github-user/test-repo.git : 원격 저장소에 origin이라는 이름으로 추가하는 명령
- git branch -M main : git branch -M <브랜치 이름>은 현재 브랜치 이름을 <브랜치 이름>으로 바꾸는 명령 / 즉, 현재 브랜치(master) 이름을 main으로 변경하는 명령
- 로컬 저장소의 기본 브랜치는 master 이지만 깃허브의 기본 브랜치는 main이기 때문에 로컬 저장소의 기본 브랜치(master)에서 만든 변경 사항을 깃허브의 기본 브랜치(main)으로 푸시하기 위해서 브랜치 이름을 main으로 변경해야 합니다.
- git push -u origin main ⇒ git push <원격 저장소 이름> <브랜치 이름> : <원격 저장소 이름>으로 <브랜치 이름>을 푸시하는 명령
이때, -u 옵셥은 처음 푸시할 때 한 번만 사용하는데 이 옵션과 함께 푸시하게되면 이후 간단히 git push(혹은 git pull) 명령만으로 origin의 main 브랜치로 푸시 또는 풀을 할 수 있습니다.
Administrator@YounghakBook MINGW64 ~/OneDrive/바탕 화면/git/test-repo (main)
$ git commit -am "Second commit"
[main 26d2897] Second commit
1 file changed, 2 insertions(+), 1 deletion(-)
Administrator@YounghakBook MINGW64 ~/OneDrive/바탕 화면/git/test-repo (main)
$ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 16 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 312 bytes | 312.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
To https://github.com/JeonYongHak/test.git
f72b943..26d2897 main -> main
처음 -u 옵션을 작성했기에 a.txt 파일의 내용을 변경하고 수정사항을
커밋하고 git push만 작성해도 github 저장소에 커밋이 반영이 됩니다.git fetch : 원격 저장소를 일단 가져만 오기
Github 저장소에서 파일을 일부 수정하고 commit changes를 하면 원격 저장소와 로컬 저장소의 커밋 상태가 달라지게 됩니다. 이런 상황에서
$ git fetch를 입력하고 $ git status를 입력하게 되면
$ git status
On branch main
Your branch is behind 'origin/main' by 1 commit, and can be fast-forwarded.
(use "git pull" to update your local branch)
nothing to commit, working tree clean
=> Your branch is behind 'origin/main' by 1 commit으로 나타
나게 되는데 이는 origin/main 브랜치가 현재 main 브랜치에 비해
1 커밋 앞서 있다는 의미입니다.패치는 원격 저장소의 변경 사항을 origin/main 브랜치로 가져올 뿐 main 브랜치는 변함이 없기에 / 즉, 패치는 원격 저장소의 변경 사항을 ‘일단 가지고 올 뿐’ 로컬 저장소의 브랜치로 병합하지 않습니다.
Administrator@YounghakBook MINGW64 ~/OneDrive/바탕 화면/git/test-repo (main)
$ git checkout origin/main
Note: switching to 'origin/main'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false
HEAD is now at 007c762 add C in a.txt원격 저장소로 $ git chekcout origin/main을 입력하고 위 화면이 나오면
성공입니다!
⇒ 위 내용과 동일하게 $ git checkout FETCH_HEAD 로 작성하면 됩니다
이제 $ git merge origin/main으로 원격 저장소 origin/main 브랜치로
로컬 저장소의 main 브랜치로 병합합니다.
Administrator@YounghakBook MINGW64 ~/OneDrive/바탕 화면/git/test-repo (main)
$ git log
commit 007c76253489bdb78af247de69aaf9b19c4b22ae (HEAD -> main, origin/main)
Author: YongHak <162122203+JeonYongHak@users.noreply.github.com>
Date: Sat Jun 29 03:18:52 2024 +0900
아래 문구가 나오게 되면 성공한 것입니다.
git pull : 원격 저장소를 가져와서 합치기
pull은 패치와 병합을 동시에 하는 방식
⇒ 원격 저장소에서 파일을 추가하고 원격 저장소에서 commit changes를 입력하게 되면 원격 저장소에는 로컬 저장소에는 없는 커밋이 존재합니다.
git pull 또는 git pull <원격 저장소 이름> 을 입력하여 원격 저장소의 변경 사항을 풀합니다.
이때, 풀은 원격 저장소를 가져와서 합치는 방식입니다.
깃 명령으로 풀 리퀘스트 보내기
{ 풀 리퀘스트 방식}
- 기여하려는 저장소를 본인 계정으로 포크하기
- 포크한 저장소를 클론하기
- 브랜치 생성 후 생성한 브랜치에서 작업하기
- 작업한 브랜치 푸시하기
- 풀 리퀘스트 보내기
※ 다른 사람의 깃 허브 주소를 fork 하고 나서 fork한 주소와 기존 주소와의 commit의 차이가 있으면 github의 <>Code 부분에서 Fetch upstream을 클릭하여 Fetch and merge 버튼을 클릭하여 업데이트 된 커밋 상태를 동기화 시켜줍니다.
깃허브 명령어（원격 저장소 ＆ 로컬 저장소 연결 ）
부록
git <명령> —help : 매뉴얼 페이지 보기
$ git commit —help : git commit 명령에 대한 자세한 설명을 보여줍니다.
$ git log —help : git log 명령에 대한 매뉴얼 페이지
git-scm.com : 공식 사이트
https://git-scm.com 사이트에 접속하여 Documentation 을 참고하면 다양한 git에 관한 정보들이 존재합니다.
'협업 및 기타 툴 정보 > 깃 & 깃허브' 카테고리의 다른 글
| README.md 파일에서 동영상 및 텍스트 한 눈에 보기 (1) | 2024.11.20 |
|---|---|
| Git 핵심 명령어 (2) | 2024.11.10 |
| Github CLI 명령어 & 기본 실행 구조 로직 (0) | 2024.06.30 |