2023.05.17 78일차 Git
78일차
git 동작 활용방법
버전관리 프로그램이다. commit에 의해서 기록이 된다.
commit을 옮겨다닐 수 있다. branch를 만들고 옮겨다닐 수 있었다.
5.7 전체파일 stage하기
git ass -A 전체다 add
git add . 지운파일은 add안함5.6 branch 이어서
그냥 위치에서 branch를 하면 현재위치에 별칭을 붙이게된다.
여기서 commit을 하면 가지가 쳐지는 것이다.
(HEAD -> my-branch1, master) add aa, bb
add a, b
(HEAD -> my-branch1) add aaa
(master) add aa, bb
add a, b둘다 새로운 commit을 따라가는게 아니라 현재 위치한 branch만 commit을 따라가게 된다.
(HEAD -> my-branch2) add bbb
| (my-branch1) add aaa
|/
(master) add aa, bb
add a, b그러면 이런 branch를 어떻게 사용하느냐
과거로 돌아가고 싶을때 branch를 만들어서 그 branch로 이동해라
그리고 현재 브랜치로 돌아오면된다.
checkout은 이동뿐만 아니라 여러 일을 한다.
그래서 switch라는 새로운 명령어가 생겼다.
git switch branch이름위치를 옮기면서 브랜치 이름을 붙이면서 갈수 있다.
git switch -c branch이름 커밋코드연습하기
repo4 폴더만들고 해답: mkdir repo4
repo4로 옮겨서 해답 : cd repo4
repo4를 git project folder로 만들고 해답 : git init
여러 커밋 하기
git switch -c feat1 (master있는곳)
git switch -c feat2 ecadba2(master있는곳)(HEAD -> feat2) b.txt생성
| (feat1) aaa추가
|/
(master) aa추가함
a 추가함5.6.2 브랜치 지우기
지우려는 브랜치에 내가 있으면 못지운다.
git branch -d 브랜치이름5.6.3 브랜치 이름 변경
브랜치 이름도 변경할 수 있다.
새이름만 작성하면 현재위치의 브랜치이름을 변경하고
다른브랜치+새이름 하면 다른브랜치의 이름을 변경할 수 있다.
git branch -m 새브랜치이름
git branch -m 다른브랜치이름 새이름브랜치 만드는게 협업의 기초이다.
A의사람이 A브랜치를 따라가며 작업하고
B라는 사람이 B브랜치를 따라가며 작업하고
나중가서 통합을 하면된다.
특정 뿌리 기준으로 다른 BRANCH를 따서 서로 다른 작업을 할 수 있다.
5.8 commit되돌리기
있다는 것만 알고 가능하면 쓰지 말아라.
HEAD가 현재 커밋위치 즉 가리키고 있는 곳인데 HEAD전이 HEAD1이다.숫자 HEAD기준 1전 2전전 이런식으로 간다.
HEAD
git reset --hard HEAD~1그런데 커밋을 지우고 싶다면 브랜치를 새로 만들고 돌아가서 다시 커밋해라
우리 수준에서는 리셋까지 하지말자.
git reset --soft HEAD~1 commit실수시 파일 은 수정되고 statged된상태로 돌아가기
hard는 아예 돌아가기인듯
5.9 commit
하나의 commit이 어떻게 이루어지나?
폴더 구조를 보면 .git과 내가 만든 폴더들이 있다.
.git제외 내가 만든 것들이 working directory영역이다.
.git폴더를 보면 INDEX와 OBJECT REPOSITORY로 나누어진다.
.git폴더안에는 프로젝트관련된 파일이 여러개가 있고 index와 object가있다.
즉 git 프로젝트 폴더에 물리적으로 총 3영역이 있게 되는 것이다.
working directory / INDEX / OBJECT REPOSITORY
git 프로젝트 폴더 상태보기
git status파일을 변경하면 working directory가 변경된 것이다.
git status하면 어떤 파일이 수정되었음을 알려준다.
git add하면 working directory의 내용을 INDEX영역에 옮겨지게 된다.
git status하면 옮겨진게 보인다.
git commit 하면 INDEX에서 OBJECT REPOSITORY로 옮겨지게 된다.
그래서 working directory에서 바로 OBJECT REPOSITORY로 갈수 없기때문에
add - commit의 과정을 거치는 것이다.
연습
a.txt수정하고 git status실행 -> working directory가 변경된상태
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")a.txt를 index에 수행하고 git status실행
-> add : working directory에서 INDEX에 복사한상태 마지막 commit과 index상태가 다른상태
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: a.txtindext에 있는 a.txt를 object repository에 복사 git status실행
-> INDEX -> OBJECT REPOSITORY 복사
On branch master
nothing to commit, working tree cleancommit하면 git에서는 snapshot이라고 한다.
사진찍는 느낌
index에 올려 놓는 것 무대에 올린다.
staged 되었다고한다. indexed나 add했다라고도 한다.
chechout이나 switch하면 해당영역이 index와 working directory까지 모두 영향을 미치는 상태이다
왜 이 3가지 상태로 나누어놨는가?
새로운 기능이 필요해서 새로운 파일을 만들어야한다고 되엇을때
두개의 파일이 있는 상태가 된다
그런데 이전 파일에 잘못된 내용이 있어서 수정을 해달라고 하고 저장을 하면
working directory에 변경된 파일이 두개가 된다.
이러면 a.txt는 버그 수정이고 b.txt는 새로운 기능이다.
git add .하면 두개의 파일이 다 stage된 상태로 commit하면 두개의 파일이 한번에 등록되는 것이다.
최초 개발자는 이걸 원하지 않았다.
모든 파일을 한꺼번에 commit하고 싶지 않아서 중간과정을 거치는 것이다.
이미 stated된 것을 다시 working directory에 돌리고 싶다면 다음의 명령어를 입력하면된다.
git restore --staged 파일명Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: a.txt
Untracked files:
(use "git add <file>..." to include in what will be committed)
b.txt두 상태가 되는 것이다. staged된 파일과 안된 파일
연습
1.working directory
c.txt파일 새로만들기
b.txt파일 수정하기
2.b.txt만 스테이지에 올리고 커밋
git add b.txt
git commit -m 'b.txt수정'3.c.txt만 스테이지에 올리고 커밋
git add c.txt
git commit -m 'c.txt생성'git log --all --oneline
e77c3fe (HEAD -> master) c.txt생성
4640ca4 b.txt수정
b6ca600 새 기능 추가
1873a1e 버그수정
69a97d2 ee추가
5a434f0 add dd
03a5891 (feat2) b.txt생성
76c1643 (feat1) aaa추가
ecadba2 aa추가함
4e1f26b a 추가함working directory가 변경된 상태에서 다른 branch로 옮겨가는 일 같은 것은 왠만해선 하지 말자.
commit하고 움직여라
강사님께 질문하기 전에 commit을 먼저 하고 질문해라.
5.10 파일의 상태
c를 수정하고 d를 추가하면 다음과 같이 나온다.
modified: c.txt
Untracked files: d.txt파일 상태는 공식문서의 2.2에 나온다.
파일 상태는 총4개이다
크게는 두가지 untracted / tracted
untracted /unmodified / modified /staged
새파일 /수정전 / 수정후 /index에 올린 상태
add하면 tracted된상태 staged된 상태이다.
c.txt modified파일은 unmodified를 거친 것이다.
d.txt는 unmodified된적없으니 untracted상태에 있는 것이다.
tracted된 파일은 unmodified modified staged의 사이클을 돈다.
gitignore에 파일 넣을때 주의하라고 했던 것있다.
한번이라도 commit하면 tracted된상태에서 계속 돌아가게 된다.
5.11 파일 합치기
그러면 작업이 끝난 다음 엔 어떻게 하느냐?
아직 협업까지오지도 못했다.
새 기능을 추가해달라고하면 새 브랜치를 만들어서 새 가지를 치자.
이미 tratcted되엇다면 git commit -am '주석'하면 add안해도된다.
가지쳐서 하고 있는 데 a.txt를 수정해달라 master로돌아가서
작업을 하고 새로운 branch를 만들고 수정을 해주자.
* 0283947 (HEAD -> bug1) 버그수정
| * f8bdb26 (feature1) b 기능 추가중...
| * 907ef37 b기능 추가 중
|/
* 6ea279b (master) add a꼭 정해야하는게 있다.
잘돌아가는 branch 메인인 branch를 정해둬야한다.
함부로 건들면 안되는 branch를 정해서 만들어 두어야한다.
여러 작업물을 master에 통합 시킬 것이니 통합 브랜치라는 이름으로 불린다.
위 상태에서 master로 돌아가면 버그가 있는 상태이다.
bug1 브랜치를 만든 이유는 버그를 만들고 master에 반영하고 싶어서 만든 것이다.
수정한 내용을 master로 합치고 싶다면 merge명령어를 사용해야한다.
사용할때 주의해야하는 점이 있다.
합칠대상소스 -> 합치고싶은타겟
타겟 branch에서 작업을 해야한다.
git merge 브랜치명bug1은 master로부터 시작을 했다. 이걸합친다는 것은 master가 bug1이 간길을 따라가기만하면된다.
이 merge가 fast foward merge이다.
Updating 6ea279b..0283947
Fast-forward
a.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)다시 보면 master와 bug1이 가리키고 있는 것이 같아진다.
* 0283947 (HEAD -> master, bug1) 버그수정
| * f8bdb26 (feature1) b 기능 추가중...
| * 907ef37 b기능 추가 중
|/
* 6ea279b add a연습
featA에서 a.txt파일 수정하고 커밋하고 master로 옮겨서
echo aaa >> a.txt
git add .
git commitfeatA의 변경내용 master에 반영
git merge featAfeatA 브랜치 삭제
git branch -d featA최종상태
59682a7 (HEAD -> master) a.txt 파일 수정
146b682 b추가
ed37ef7 first commitb기능을 추가하다가 c기능을 추가해야한다.
통합브랜치로 옮겨서 c기능을 추가하면된다.
c508b4c (featB) bbbb 기능 추가
d322258 bbb 기능 추가
59682a7 (HEAD -> featC, master) a.txt 파일 수정
146b682 b추가
ed37ef7 first commit312e267 (HEAD -> featC) c기능 추가
c508b4c (featB) bbbb 기능 추가
| d322258 bbb 기능 추가
|/
59682a7 (master) a.txt 파일 수정
146b682 b추가
ed37ef7 first commit312e267 (HEAD -> master) c기능 추가
| c508b4c (featB) bbbb 기능 추가
| d322258 bbb 기능 추가
|/
59682a7 a.txt 파일 수정
146b682 b추가
ed37ef7 first commit이때 b기능은 추가하는 중이었다.
다시 featB로 돌아가서 작업을 하면된다.
6caa88a (HEAD -> featB) b기능 추가 완료
c508b4c bbbb 기능 추가
d322258 bbb 기능 추가
| 312e267 (master) c기능 추가
|/
59682a7 a.txt 파일 수정
146b682 b추가
ed37ef7 first commit뿌리는 a파일이고 통합 브랜치는 옮겨가버렷다.
결국 master에 featB를 붙여야하는데
뿌리가 다르기 때문에 fast forward merge가 발생하지 않는다.
master와 featB가 합쳐진 새로운 commit이 생긴다.
이걸 하면 vscode가 뜨고 머지하려는 commit message를 입력해달라고 한다.
새로운 commit이 생겨나기 직전이기 때문에 vscode가 열리는 것이다.
Merge made by the 'ort' strategy.
b.txt | 3 +++
1 file changed, 3 insertions(+)* f9e9c84 (HEAD -> master) Merge branch 'featB'
|\
| * 6caa88a (featB) b기능 추가 완료
| * c508b4c bbbb 기능 추가
| * d322258 bbb 기능 추가
* | 312e267 c기능 추가
|/
* 59682a7 a.txt 파일 수정
* 146b682 b추가
* ed37ef7 first commit서로다른 길을 가다가 merge를 하면 merge커밋이 되는 것이다.
featB를 master에 반영하려고 했던 것이니 master의 위치가 merge commit이 된것이다.
연습
여기서 다른 작업을 하고 싶다면 또 다른 브랜치를 만들어서 작업해야한다.
featC에서 c.txt파일 수정하고 commit
featD에서 d.txt파일 만들고 commit
featD를 master에 통합 merge
featD 지우기
featC를 master에 통합 merge
featC지우기
* f9e9c84 (HEAD -> featD, master, featC) Merge branch 'featB'
|\
| * 6caa88a b기능 추가 완료
| * c508b4c bbbb 기능 추가
| * d322258 bbb 기능 추가
* | 312e267 c기능 추가
|/
* 59682a7 a.txt 파일 수정
* 146b682 b추가
* ed37ef7 first commit* a68cb75 (HEAD -> master) Merge branch 'featC'
|\
| * a437299 cc기능 추가
* | fb03bfe d기능 추가
|/
* f9e9c84 Merge branch 'featB'
|\
| * 6caa88a b기능 추가 완료
| * c508b4c bbbb 기능 추가
| * d322258 bbb 기능 추가
* | 312e267 c기능 추가
|/
* 59682a7 a.txt 파일 수정
* 146b682 b추가
* ed37ef7 first commit기능 C를 만들다가 통합하지 않고 지우려고 하면 문제가 생긴다.
진짜로 필요없다면? 진짜통합할필요가 없다면
대문자 -D로 지우면된다.
branch를 지워버려서 가리키던 커밋번호가 안나온다면 방금지운 커밋번호가 적혀있다.
혹시 실수로 branch를 강제로 지워버렸다면 커밋번호를 메모를 해두고 복구하자
git branch -D 이름
git branch branch이름 지웟던커밋번호이렇게 별일없이 merge되는 일이 별로없다.
아름답지 않은 상황을 만들어보자.
fast forward는 아름답다.
merge commit이 생길때 아름답지 않은게 생긴다.
같은 파일을 여러 branch에서 작업을 했을때를 문제가 생긴다.
master기준으로 e와f로 가지가 쳐진 상황인데 같은 파일을 건든 상황이다.
Auto-merging d.txt
CONFLICT (content): Merge conflict in d.txt
Automatic merge failed; fix conflicts and then commit the result.자동으로 merge하려는 시도를 먼저한다.
같은 파일에 같은 줄에 변경사항이 있으니 git이 혼란스러움을 느낀다.
merge하다가 CONFLICT이 생기고 실패하였다.
CONFLICT를 수정한다음에 commit을 하라고 한다.
이 해소를 어떻게 하는가가 중요하다.
두가지 액션을 취할 수 있다.
하나는 merge취소
git merge --abort하나는 d파일을 수정하면된다.
vscode로 충돌난파일을 열어라
d
Accept Current Change | Accept Incoming Change | Accpet Both Change | Compare Changes
<<<<<<< HEAD (current Change)
eeeeeee
=======
fffff
>>>>>>> featF (Incoming Change)====기준으로 아래가 featF내용 위가 master에 있는 내용이다.
처음으로 eeee가 맞는지 ffff가 맞는지를 판단하거나
둘다 맞는지 아니면 둘다 아닌지를 판단해야한다.
이걸 vscode가 옵션을 준다.
Accept Current Change(기존) | Accept Incoming Change(새거) | Accpet Both Change(둘다) | Compare Changes
git이 처리를 하지 못하고 개발자가 선택해줘야한다.
* a2dd569 (HEAD -> master) ff기능 반영
|\
| * 0411626 ff기능 추가
* | 11f814a 기능 e추가
|/
* a68cb75 Merge branch 'featC'git은 CONFLICT가 낫다고 알려줄뿐이고 해결은 개발자가 해야한다.
지금은 간단해서 이렇게 해결되지만 실제로는 복잡한 상황이 올 수 있다.
스스로 해결하거나 강사님을 부르자.
CONFLICT 발생시키기
master에서 featG, featH 브랜치만들고
featG a.txt에 gggggggg추가
커밋
featH a.txt에 HHHHH추가
커밋
master에 featH통합
featH지우기
master에 featG통합 ---> 이때 CONFLICT발생 해소필요
featG지우기
* 4656a1d (HEAD -> master) merge gg기능 반영
|\
| * d963b2b gg기능추가
* | 492dc19 HH기능 추가
|/
* a2dd569 ff기능 반영6. git hub
같은 리포지터리에서 작업하고 싶은데 이것을 중계해주는게 github(ms)이다.
gitlab bitbucket 등등 다른 사이트들도 있다.
git hub사용하는 방법 일단 혼자 사용하는 방법을 배울 것이다.
branch만들고 merge가 온라인에서 하는 것일뿐이다.
리포저터리를 만들면 git이 관리하는 폴더가 생긴다.
github에서는 main이라는 최초 branch를 만들어 놓는다.
최초커밋이 커밋번호를 가지고 되어있다.
누가 언제 어디서 파생되있는지를 hash함수로 암호화해서 만들어 놓은 것이다.
이것을 다운로드 받으려면 git bash에서 해야한다.
6.1 git clone
온라인에 있는 것을 가져오고 싶다. 이미 있는 리포지터리를 가져오는 것이다.
code를 누르고 있는 주소를 가져오면된다.
git clone 링크log를 보면 github에서본 똑같은 commit history를 볼 수 있다.
.git폴더가 그대로 복사되서 왔기때문이다.
그런데 여기서 작성을 하면 github에 반영이 되겠는가
-> 안된다.
깃의 특징 중하나가 git은 버전관리시스템인데 분산되어 있다.
버전관리를 각 로컬에서 서로 따로 따로 한다는 것이다.
내가 한다고 반영되는게 아니다.
반대의 의미의 중앙버전관리시스템이 있다. 메인에서만 버전을 관리한다.
6.2 git push
git hub에반영하고 싶다면
작업을 다 끝내고 반영하고 싶은 branch에서 push하면된다.
git push연습
feat2브랜치만들고
a.txt 변경하고 커밋하고
main에 feat2 통합하고 feat2지우고 main을 업로드
push할때마다 origin/main, origin/HEAD이 옮겨다니는데 github가 어디인지를 보여주는 것 같다.
* 5a44469 (HEAD -> main, origin/main, origin/HEAD) bbbb 추가함
* 8361fca aa 추가
* 709d4e1 Initial commitgithub는 git을 온라인에서 관리하는 폴더일뿐이다.
그럼 github에서 merge를 할 수 있지 않겠느냐? 가능하다.
feat3브랜치만들고
a.txt 변경하고 커밋하고
main에 feat2 통합하고 feat2지우고 ->local
main을 업로드
이엇던것을
feat3브랜치만들고
a.txt 변경하고 커밋하고 ->local
main에 feat2 통합하고 feat2지우고
main을 업로드 -> online
merge를 온라인에서 하게 될것이다.
master가 아니라 feat3를 git push하면되는데 그냥 안되서 다음 명령어를 작성해야한다.
$ git push -u origin branch이름6.3 git pull(merge)
그러면 pull request를 주소에가서 만들어라라고 한다.
Create a pull request for 'feat3' on GitHub by visiting:
주소github에서는 pull request 다른 git사이트는 같은 용어를 쓰거나 merge request를 쓰기도 한다.
merge 요청을 생성해라라고 한다.
기능 branch를 완성이 됫으면 merge요청을 하라는 것이다.
github를 가면 pull요청을 하라는 alert이 뜨고 두개의 branch가 있는 것을 볼 수 있다.
github Pull requests들어가서 new pull request만들겠다고 하고
어느 branch를 어느 branch에 할지의 select 창이 뜬다.

협업이면 리포지터리 주인한테 merge요청이 들어왔다고 하고 이것을 할지 말지를 결정한다.
최종 허락을 하면 merge가끝난것이다.
github merge는 fast forward가 아니라 merge 커밋이 생긴다.
merge가 깃허브에서 이루어졌다. git은 분산관리이니 github를 로컬에서 알 수없다.
그래서 다시 가져와야한다.
git fetch깃허브의 내용을 가져오게 된다.
* 4512a94 (origin/main, origin/HEAD) Merge pull request #1 from ChunPingE/feat3
|\
| * ea27c0a (HEAD -> feat3, origin/feat3) ccc추가함
|/
* 5a44469 (main) bbbb 추가함
* 8361fca aa 추가
* 709d4e1 Initial commitgithub에서 지웠는데 feat3이 안사라져있다.
이제 local의 main branch가 github에 따라 가야한다.
github에서 온 또다른 커밋이니 로컬의 main에 github를 merge하면된다.
git merge origin/main* 4512a94 (HEAD -> main, origin/main, origin/HEAD) Merge pull request #1 from ChunPingE/feat3
|\
| * ea27c0a (origin/feat3, feat3) ccc추가함
|/
* 5a44469 bbbb 추가함
* 8361fca aa 추가
* 709d4e1 Initial commit남아있는 필요없는 branch는 지워줘야한다.
git branch -d branch이름
git fetch origin --prune내일 CONFLICT 깃허브에서 나면 어떻게하는지
2023.05.17
git 헷갈린다 혼자 작업시 이정도인데 협업으로 가면 매우 헷갈릴듯하다.
다음 주소록 불러오는 서비스 만들어보자.
주소검색 api?
https://tyrannocoding.tistory.com/48 쉽다
전화번호 같은거 가입시 js에서 패턴비교
배송준비중이라면? 주문취소못함
취소 -delete
검색 평점기준 장르(카테고리)기준
제목기준 등등 작성자기준
여러개 제안을 해보려고 한다.