✔GIT에 대하여
- 3대 권력
- 도메인
- 코딩
- 협업
- 버전관리 시스템
- GIT - 20시간 30시간 정도만 제대로 배우만 앞으로 잘할 수 있다.
- 버전 → 백업 → 협업
- 각각의 버전은 그 버전이 만들어진 시점의 작업 디렉토리의 스냅샷이다.
- ISSUE- 협업을 할때 사용할 수 있는 게시판이다.
- GIT - 20시간 30시간 정도만 제대로 배우만 앞으로 잘할 수 있다.
- 버전관리 시스템
$ ssh-keygen
→ 해당위치에 파일을 저장할지 물어본다.
→ 비밀번호 입력할것인지 물어볼것이다.
→ 파일생성
$ ls -al /c/Users/User/.ssh/
$ cat /c/Users/User/.ssh/id_rsa.pub
→ id_rsa는 절대 유출X / 공개키는 올려도 상관없다.
deepl 번역기
git 설정해주기
$ git config --global user.name "jeong-yooon"
$ git config --global user.email "chjy1819@gmail.com"
-> 내용 변경 전
-> 내용 변경 후 push 이전
-> 커밋 직후
-> 오른쪽 위의 ...에서 push를 통해 push 한다.
-> 완료 후 모습
-> 해당창에서 .키를 누르면
-> 해당창이 나온다.
-> 해당창에서 바로 내용 수정 후
-> push후에 바로 git hub로 업로드 된것을 확인할 수 있다.
-> 이상태에서 ctrl+. 을 누르면 settings창이 뜬다.
또는 file - preferences - settings
-> settings창에 exclude를 검색하고 ./git 우측의 x표시를 누르면 vscode에서도 .git 폴더가 보이게 된다.
-> git 구조
-> 오른쪽의 + 버튼을 활용하여 장바구니처럼 선택파일만 커밋할 수 있다.
-> checkout은 head를 옮긴다.
-> 현재 위치로 다시 checkout 하려면 빈공간에 우클릭하지 말고 main에서 우클릭해주어야 한다.
-> main에서 우클릭해주어야 하는 이유
-> 해당 상황에서 4 main brach checkout을 해주면 5번을 버리고 4로 향하는 정상상황으로 되돌릴 수 있다.
-> 만약 빈공간에서 checkout하고 난 후 이를 모르고 내용 변경 후 바로 커밋해버리면 위의 사진과 같이 main이 움직이지 않는 상황이 발생한다.
-> 이런 때에는 main에서 checkout을 해준 후 다시 커밋해주면 정상적으로 돌아온다. (v9은 삭제)
-> commit만 하고 push직전일때 수정을 원한다면 일부러 빈공간에서 checkout을 해주어서 수정한 후 다시 커밋해주면
-> 위 사진과 같이 head는 v9를 main v10을 가르키는 상황이 연출된다.
-> 위 상황에서 브랜치를 생성하면 exp라는 브랜치가 생성되어 v11을 가르키게 된다.
-> 해당상황에서는 main과 exp 총 2개의 브랜치가 존재하게 된다.
-> 이 상황에서 main으로 브랜치를 이동하면 v11이 사라지지 않고 안전하게 브랜치 사이를 이동할 수 있게 된다.
-> 이 상황에서 커밋을 진행하게 되면
-> 위 그림과 같이 main과 exp가 평행세계에서 서로 다른 길을 가게 된다.
-> 커밋을 진행한 후 위와 같이 exp 브랜치가 따로 남겨지고 main이 v15로 이동한다.
-> 이 상황에서 v15에 exp2라는 브랜치를 새로 생성하면 main과 exp2 모두 v15를 가르키게 된다.
-> main에 checkout 되어있는 상태에서 main.txt라는 새 파일을 만들어서 commit을 진행하면
-> 위와 같이 바뀌고
-> 위 상황에서 exp2로 checkout(더블클릭)한 후 exp.txt파일을 커밋하면 위 사진처럼 바뀐다.
-> main에 checkout되어 있는 상태에서 exp2브랜치를 merge해주게 되면 main브랜치와 exp2가 병합된다. 이때 새로운 버전을 따른다.
-> 병합되어 main에 합쳐진다.
-> conflict 발생시에 위와 같이 알아서 병합해준 후 둘 다 변경사항이 있어 이를 고쳐야 할 때는 사용자에게 어떤 코드를 사용할 것인지 물어본다.
-> main에서 common.txt를 만든 후 commit 해준다.
-> exp3 브랜치를 제작한다.
-> main의 3을 m3으로 exp의 3을 e3으로 변경한 후 각자 commit해준다.
-> main과 exp3 merge를 진행하면 충돌이 발생한다.
-> Resolve in Merge Editor 실행
-> 이상황에서 accept combination을 누르면 둘 다 적용된다.
-> commit하면 충돌이 모두 해결된다.
-> 서로 다른 공간에서 작업한 후 왼쪽은 먼저 push하고 오른쪽은 push하지 않은 상황에서 나중에 오른쪽 사용자가 push를 진행하게 되면 reject 당하게 된다.
-> 오른쪽 작업물이 만약 push가 성공하게 되면 왼쪽 작업물이 날아가버리기 때문에 거절당하는 것이다.
? 어떻게 해야할까
-> 원격 저장소의 작업물을 먼저 pull(fetch+merge)또는 fetch를 활용하여 해결 후 push를 진행하면 문제없이 진행할 수 있다.
-> fecth를 누르면 원격 저장소에 있던 L1이 새로운 브랜치로 만들어져서 표시된다.
-> 오른쪽 사용자가 작업한 브랜치는 main 왼쪽 사용자가 작업한 브랜치는 origin/main으로 표시된다.
-> merge를 진행하면 left.txt파일이 추가된다.
-> 이 상태에서 push를 진행해도 안전하다.
fetch에서는 절대 conflict가 나지 않는다.
merge에서만 conflict 발생!!
위의 모든 작업들이 끝나고 왼쪽 사람이 새로운 작업을 시작할때
-> fetch를 해주고 진행한다.
-> fetch이후 상황
4시부터 수업 놓침.😂
-> 로컬에 새로운 파일들 생성
-> 깃에서 initial 설정을 해주면 아직 연결되지 않은 원격저장소가 생긴다.
-> 깃허브에서 새로운 레파지토리를 생성하고 해당 주소를 복사한다.
-> add remote에 주소를 붙여넣는다.
-> remote이름은 대부분 origin으로 짓는다.
-> push 진행하면 git hub에 적용된다.
SYNC는 pull,merge,push를 한번에 해준다.
