📓 Pull (Remote -> Local)

Git에는 새로 만드는 Push와 가져오는 Pull이 있다.
Pull의 경우 이미 원격에 저장되어 있다.

그래서 Git 가져오기로 git clone 하면 된다.

  • 이미 이미 누군가가 자신의 Local 에서 git init 을 통해 Git 설정한 뒤 Remote 에 업로드한게 있다면 내 로컬에 그것을 가져와서 이어서 작업을 진행하면 된다

🏷️ Pull = Fetch + Merge

  • Fetch : 원격 저장소에서 최신 변경 내용을 로컬 저장소로 가져오는 역할을 한다. 로컬 저장소의 브랜치에는 아직 반영되지 않지만, 원격 저장소의 최신 상태를 확인할 수 있다.

    • 사용 이유 : 원격과 로컬 레포지토리의 변경 사항이 달라 비교 대조하고 싶을 때 사용.

  • Merge : 가져온 파일을 Local에 반영한다. 그러면 두 개의 다른 브랜치를 통합한다. 주로 현재 작업 중인 브랜치에 다른 브랜치의 변경 내용을 통합할 때 사용된다.
    두 브랜치의 커밋 히스토리가 합쳐져서 새로운 커밋이 생성되며, 이를 통해 두 브랜치의 변경 내용이 반영된다.

    • 충돌 방지


FETCH_HEAD : Git에서 원격 저장소로부터 최신 변경 내용을 가져온 후에 해당 변경 내용을 가리키는 포인터.
최근의 git fetch 명령으로 가져온 원격 저장소의 변경 내용을 기록한다.

HEAD : 최종적인 커밋 작업의 위치.






📓 Push (Local -> Remote)

Push의 경우에는 새로 만들어야 한다.

  • git init을 통해 현재 내 디렉토리에 .git 디렉토리를 생성하여 현재 내 디렉토리를 Git으로 추적하겠다고 선언.
  1. Git 생성 : git init
  2. 메인(디폴트) 브랜치 설정 : git branch -M main
  3. 목표 설정 : git remote add origin 주소
  4. 발사(업로드) : git push -u origin main


🏷️ Pull과 Push 그림

main 은 branch 명이다.






📓 Remote 관리

  • 설정 : 기존 원격 저장소 URL을 변경하기 위해 git remote set-url origin [주소] 명령어를 사용

  • 추가 : git remote add origin [주소]

  • 삭제 : git remote remove origin [주소]

  • 조회 : git remote -v

🔔 명칭 : Origin - 일반적으로 많이 사용.

  • Gerrit / Bitbucket 등으로 이름 지어 연결 혹은 Backup 같은 것도 사용.
  • 다중 Remote 사용
    • 특정 코드를 내 개인 Repository에 백업하여 나중에 학습할 때 활용.





📓 Branch 관리

  • 원격 Branch 조회 : git branch -r
  • 원격 Branch 삭제 : git push --delete/-D origin bc
  • 로컬 Branch 조회 : git branch -l
  • Branch 전부 조회 : git branch -a
  • 로컬 Branch 삭제 : git branch -d/-D bc
  • 로컬 Branch 생성 및 선택(이동) : git checkout -b be


총 9개의 branch를 생성했다.
origin/ba, origin/bb, origin/bc, backup/ba, backup/bb, backup/bc, ba, bb, bc

origin과 backup은 Remote에 있는 branch고 ba, bb, bc는 Local에 있는 branch이다.

모든 branch를 다 보고 싶다면 git branch -a

바라보고 있는, 현재의 branch를 바꾸고 싶다면 git checkout -b ba 라 하면 된다.

git branch --delete origin branch명 이면 원격 branch를 삭제한다.






📓 Commit

파일 기반일 때는 버전을 관리한다. 버전은 의미있는 변화를 뜻하고 작업이 완결된 상태이다.
사이 분량 기준일 때는 스냅샷을 찍는다. 즉 파일의 변화를 깃 Repository에 영구적으로 기록한다.

쉽게 말하면 의미있는 변경사항들을 깃이라는 저장소에 저장하는 동작으로 시간에 따라서 변화하는 내용만 관리하고 코드가 변화된 시간 순서에 따라 영구적으로 저장하는 것이다.

그래서 코드를 삭제, 변경 또는 잘못된 행동을 하더라도 다시 이전 상태로 되돌릴 수 있다.

Untracked -> Tracked

commit하기 전에 add를 해줘야 commit할 수 있다.
현재 Staging area의 내용을 local repository에 저장하고, 하나의 버전으로 등록






📓 git add

현재 작업중인것들을 각각 나눠서 따로따로 commit을 해주고 올리고 싶을때 사용한다.

git에 내가 작업한 파일이나 폴더를 저장할때는 add-commit의 단계를 거친다. add를 해주면 그 파일, 폴더는 commit의 대상이 된다.

🏷️ 사용 이유

현재 작업중인 것들중에서 같은버전으로 묶고 싶은것들을 다 add해준다음, commit을 하고, 다른 버전으로 해주고 싶은 것들을 나눠서 add-commit의 과정을 거침으로서 버전을 분리 할 수 있는 것이다.

내가 알고 싶었던 것
git add를 하면 현재 Working Directory에 있는 모든 또는 일부 내용을 Staging area로 이동시킬 수 있다.






📓 git status

Working Directory와 Staging area의 상태를 확인하기 위해서 사용한다.






📓 Git 구조

🏷️ 1. Remote

🏷️ 2. Local

  • Working Directory
    • Tracked (Git의 관리를 받을 수 있는 영역)
      • Staging Area
      • Unstaged
    • Untracked (Git 관리 X 영역)

🏷️ 수정 여부를 추적한다는 것이다.

Working Directory에서 새로 생성된 파일들은 모두 Untracked 상태인 것이다. 이 파일들을 관리하고 싶다면 추적 상태로 변경을 해야 한다.
이게 git add 설정하는 것이다.

.git 파일이 Git이 인지하고 추적하는 파일.
그래서 Tracked 상태의 파일은 .git, 로컬 Repository에 존재하는 파일 중 변동사항이 있는 파일.




🏷️ Working Directory

내가 작업하고 있는 프로젝트의 디렉토리. git init을 통해서 git이 관리하도록 지정된 디렉토리이다.

  • Working tree 또는 Workspace라고도 함.

쉽게 말해 내가 프로젝트 폴더를 하나 생성한다면 그게 Working Directory.

  • 이동 : git checkout ba
  • 생성 후 이동 : git checkout -b be

-b : branch creating



🏷️ Staging Area

git add를 하여 commit 단계 이전의 공간을 Staging Area라고 한다.
Git이 다음 커밋에 포함될 변경 사항들을 모아놓는 임시 영역.
즉 commit을 위한 대기조로 commit하면 바로 저장된다. (스포츠에서 1군 역할)
커밋할 준비가 된 파일들이 존재하는 영역으로 index라고도 불림.

git add 명령어 사용하면 Staging Area에 파일을 추가한다.
git add 명령 이후 git status 명령을 실행하면 "changes to be committed : 파일이름" 을 볼 수 있다.
그럼 이 파일은 Staging area에 있는 파일이 된 것이다.

commit이 가능한 영역!!!!!
git commit 실행하면 Staging Area에 있는 변경 사항들이 새로운 커밋으로 기록됨.



🏷️ Unstaged

branch를 기준으로 어떤 변경사항이 있었는지를 확인하는 공간이다. (Tracked)
수정된 파일 중 Staging area에 들어있지 않고 git add를 하지 않았거나 취소한 경우 Unstaged 상태가 된다.

즉 이미 존재하던 파일을 수정하고 git add 파일명 명령어를 사용하지 않았다면 해당 파일은 Unstaged 상태.
(현재 커밋에 포함 X.)

commit할 준비 X
Git이 변화 이력을 commit하려면 파일들의 최종 상태가 Stage. Unstage 상태라면 파일에 변화가 있다는 것을 의미한다.

Staging Area에 올라간다는 표현은 정확히는 Working Directory의 파일이 이동하는 것이 아니라 Local Repository의 Staging Area에 복사되는 것
🔗 git add 후 상태 변화



🏷️ Untracked

Working Directory에는 존재하지만 git이 관리를 하지 않는 파일, 폴더.
새로운 파일을 만들고 git status를 실행하면 Untracked files라고 나온다.
깃이 처음 보는 파일이기 때문이다.

git log
시간 순으로 commit 기록을 출력






Git Data 전송 정리





❓❓ 질문 사항

Q1. Repository 라는것은 단지 저장소라는 의미 외에는 존재하지 않는다고 생각하시면 됩니다 🙂

Local Repository 와 Remote Repository 를 구별할때
Repository 는 저장소 그 이상의 의미를 갖지않고,
로컬이냐 원격이냐의 의미는 그 앞의 Local 과 Remote 가 갖고있다고 보시면됩니다.

소방서 경찰서 할때 '서' 는 단지 구역 혹은 장소를 뜻할뿐
'소방' 과 '경찰' 이 실질적인 의미를 갖는것과 같아요

커밋들이 모여있는 저장소 로써 Repository 의미가 맞고
커밋들이 모여있는 "로컬" 저장소 일땐 Local Repository 로 사용하고
커밋들이 모여있는 "원격" 저장소 일땐 Remote Repository 로 사용합니다.

Github 은 Remote 니까 Github 에서 레포지토리 하나 판다 라는 뜻은
(Remote) 레포리토리 하나 판다 가 되는것이죠.

맥락에 따라 "서에 가실까요?" 라는 말이 "(경찰)서에 가실까요?" 라고 해석되는것과 같습니다 🙂






배운 내용 발표 (팀원들끼리 돌아가면서 발표함!!!)

🔗 내용 발표하면서 받은 피드백


Reference

🔗 https://rnclf1005.tistory.com/16 - Git과 Github는 무엇일까?
🔗 https://m31phy.tistory.com/146 - [Git 교과서]
🔗 https://soobindeveloper8.tistory.com/713 - Git 파일 상태
🔗 https://cloud-oky.tistory.com/659 - pull과 fetch 차이

profile
일상의 인연에 감사하라. 기적은 의외로 가까운 곳에 있을지도 모른다.

0개의 댓글