pinarystudy/git-study

git-study's Issues

[ 홍서희 ] 1주차 정리

HEAD란?

HEAD는 현재 내가 바라보고있는 commit을 가리킨다.
따라서 branch를 변경하게되면, 변경한branch의 가장 최신commit을 가리키게 된다.
이렇게 될 경우, 보통 HEAD는 브랜치 이름을 가리키도록 표시!

👉 파일을 변경할때마다 git이 그걸 보고 저장을 하는데 그 흐름을 보는 시점을 head라고 한다.

깃의 3가지 영역

1. workgin directory - 종이 (그림그리기) :: 작업공간
2. staging area - 카메라 (찰칵) :: 저장소
3. local repo - 내 영역에 (내 갤러리에저장 ) :: 임시저장공간

깃의 4가지 상태

1. tracked
   👉 파일이 Git에 의해 추적되고 있는 상태를 말한다.

• unmodify : commit으로 저장되고 변경이 없는 상태
• modify : commit이후 뭔가 변경했을 때
• staged : add해서 staging area에 기록 된 상태

2. untracked
   👉 추적되지 않고 있다는 뜻이며 , 파일을 생성하고 해당 파일을 한번도 add 하지 않았다는 것을 의미한다.

자신만의 정리

Add the file : Untracked 상태의 파일을 처음으로 git add 해주면 Staged 상태.
Edit the file : 최신 커밋과 비교했을 때 차이가 없는 Unmodified 상태의 파일의 내용을 수정하면 Modified 상태.
Stage the file : Modified 상태의 파일을 git add 해주면 Staged 상태.
Remove the file : 파일을 삭제하면 당연히 Git에서 더이상 인식하지 않음.
Commit : 커밋을 하면 staging area에 있던 파일들이 커밋에 반영되고, 이제 모든 파일들은 최신 커밋과 차이가 없게 되니까 Unmodified 상태.

**작성자: 홍서희 **

[정동규] 2주차 정리

fast-forward merge

변경사항을 합치는 단순하고 기본적인 방법
(실질적으로 변경 사항의 병합이 아닌 단순 참조값만 옮기는 상황)

⁜ Branch는 Commit을 참조하게 되는데 한 쪽 Branch에만 변경 사항이 발생하면 단순히 A 기능의 커밋만 필요한 것이다.
그에 따라 다른 한 쪽의 변경점이 없는 Branch의 참조 Commit을 "A 기능 Branch로 참조값"으로 변경하면 끝이다.

3-way-merge

위 fast-forward merge와는 다르게
비교적 복잡한 작업 병합 중 하나이다.

• 3-way : 3가지의 브랜치(흐름)를 조작
  • Base Branch
  • Branch 1 from Base Branch
  • Branch 2 from Base Branch

두 변경점을 비교하게 되는데
두 변경 사항을 하나로 합칠 변경점을 따로 만들어 두고
양 변경 사항들을 모두 병합한 후,
저장을 위해 Commit 한다.
( Merge의 결과는 반드시 새로운 Commit 이 생성된다. )

⁜ 파일을 합치는 것이 아닌 "변경사항"을 합치는 것
⁜ 어떤 흐름(branch)의 변경 사항들이 어떤 흐름(branch)로 병합되느냐에 대한 방향성을 명확히 인지해야 한다.

자신만의 정리

Branch

작업의 흐름이 기록되는 버전 관리에서
초기(root)에서부터 시작되는 서로 다른 흐름들(branch)을 의미한다.

• 처음 Commit (root commit) : Git → 기본 흐름(main branch) 자동 생성
  • 흐름을 바라보는 시점(HEAD) : main branch 참조 상태로 시작
    (HEAD : 현재 흐름(branch) 의 최신 Commit 참조)
  • HEAD ⎯(참조)→ Branch ⎯(참조)→ Commit

Switch

새로운 흐름으로 이동한 후,
새로운 변경사항이 발생하게 될 경우,
기존에 위치했던 (ex. main) 브랜치에는 해당 변경사항을 알 수 없다.
(이러한 흐름의 분리 → 나무의 나뭇가지 형상 :: Branch)

→ 동일한 시점에 여러 명의 여러 작업을 동시에 할 수 있게 된다.

Conflict

동일한 파일과 영역에 대해 여러 사람의 변경이 발생한 흐름간의 병합에서 발생하는 "변경점 충돌"

A-Login()
B-post()
<<< a1   ⎤‾ A의 Conflict 발생 변경점
A-auth() ⎦
===
B-auth() ⎤
>>> b1   ⎦⎽ B의 Conflict 발생 변경점

⁜ Conflict는 에러가 아니니 당황하지 말고 채택할 변경점이 무엇인지 고려하여 해당 부분을 수정하면 해결된다.

작성자: 정동규(yummygyudon)

[김민정] 1주차 정리

HEAD란?
현재 작업하는 브랜치의 마지막 commit을 가리키는 포인터
"흐름을 연결해서 보는 시점"

깃의 3가지 영역
init 명령어로 git이 해당 directory를 추적하도록 초기화하면 .git이라는 폴더로 3개 영역이 만들어짐

• Working DIrectory
  변경 사항 발생했을 때 이러한 작업을 하는 디렉토리
• Staging Area
  add 명령어를 통해 변경사항 기록
  (Untracted상태에서 add하는 순간 Staged 상태가 됨)
• Local Repository
  변경사항 저장

깃의 4가지 상태

• Untracted: git이 추적하지 않는 상태
  파일 자체를 처음 생성하는 경우 git이 변경사항을 추적하지 않음
  (파일 삭제 후에 동일한 이름의 파일을 새롭게 생성하더라도 untracted 상태!)

• Tracted

• Unmodified
  commit으로 저장. 더 이상 변경할 것이 없는 상태

• modified
  commit한 내용에서 추가적으로 변경이 발생했을 때
  삭제한 파일에 대해서는 modified 상태

• staged
  add하여 Staging Area에 기록된 상태
  

자신만의 정리
$ git add <파일 경로 이름> or $ git add
$ git commit -m "commit 메시지"
$ git remote add origin <저장소 주소>
$ git push origin <branch 이름>

작성자: 김민정

[임승하] 1주차 정리

HEAD란?

Git에서 스냅샷(변경점)을 기준으로 파일이 변화하는 흐름을 보고 있는 시선

깃의 3가지 영역

git init 명령어로 해당 세 개의 영역이 생성됨
Working Dir - 내 로컬 컴퓨터에 있는 폴더
파일을 변경하면 파일 변경사항이 감지됨
staging area - git add 명령어로 변경 사항에 대해 스냅샷이 떠지는데 해당 스냅샷이 저장되는 영역
깃에 파일을 올리기 전 어떤 파일의 변경사항을 올릴 지 선별해서여기에 올림
local repo - staging area에 올라간 파일들을 하나의 commit에 묶어서 git commit 명령어로 올리면 local repo라는 영역에 들어감

깃의 4가지 상태

untracked

• 깃이 추적하지 않는 상태
  tracked
• 1. unmodified: commit으로 저장되었고 변경 사항이 없는 상태
• 2. modified: commit한 저장 내용에서 추가적으로 변경이 발생한 상태
• 3. staged: add 명령어로

자신만의 정리

새로 알게된 내용:
git에 있는 index 개념(라이브)
git init 명령어로 3가지 영역이 로컬에 생성됨
git 영역에서 remote repo는 해당되지 않는다!(여기는 github의 영역임)

작성자: 임승하

[곽성준] 2주차 인증

fast-forward merge

A에 기능이 만들어지고, B에는 변경 사항이 없을 때, B에 A를 합치고 싶다면 a1이라는 변경점을 새로 안 만들어도 참조값만 바꾸면 된다.

3-way-merge

A와 B 모두 변경사항이 있고, A에 B를 합치는 경우

두 흐름이 만들어진 base인 c2 커밋도 필요하다. 왜냐하면 무엇이 삭제 됐고 무엇이 추가 되었는지 확인이 필요하기 때문이다.

모든 변경사항이 적용되면 위와 같다.

자신만의 정리

Conflict : 3-way-merge에서 base에 없던 내용이 A와 B 모두 추가 됐을 때, git은 둘 중 어느 것을 정해야 되는지 개발자에게 물어본다. 그러면 우리가 선택해서 고친 후 변경사항을 적용시키면 된다.
**작성자: 곽성준

[권은빈] 1주차 정리

HEAD란?

• 해당 브런치의 마지막 커밋에 대한 포인터
• 항상 현재 브랜치의 최신 커밋을 포인팅하며, 그 외의 브랜치의 최신 커밋은 커밋 해시 뒤에 ([branch name])으로 표기 된다.

깃의 3가지 영역

• Working Directory 내가 작업하고 있는 프로젝트의 디렉토리
• Staging Area 커밋을 하기 위해 $ git add 명령어로 추가한 파일들이 모여있는 공간
  • atomic한 커밋을 할 수 있게 해줌 (부분 커밋)
  • 충돌이 발생한 파일에서, 필요한 만큼만 충돌을 해소하고 그 부분만 add하여 커밋하면 됨 (충돌 해결)
  • 로그 메시지만이 아니라 파일들도 고치고 싶다면 commit-ammend 전에 파일을 고쳐서 add 하면 고치기 쉬움! (재커밋)
• Repository 커밋들이 모여있는 장소 Commit 했을 때 최종 저장소

깃의 4가지 상태

• Untracked
  • 추적되지 않는 파일, ⇒ Git에 의해서 그 변동 사항이 추적되고 있지 않을 때를 말함 (파일 수정 후 add를 하지 않았을 때)
• Tracked
  • Unmodified
    • 현재 파일의 내용이 최신 커밋과 비교했을 때 전혀 바뀐게 없는 상태
    • 커밋 직후 working diretory 안의 모든 파일의 상태
  • Modified
    • 최신 커밋과 비교했을 때 조금이라도 바귄 내용이 있는 상태
  • Staged
    • 파일의 내용이 수정 된 후 staging area에 올라와 있는 경우
      • 새로 생성한 파일에 내용을 쓰고 git add를 하거나 한 번이라도 커밋에 포함됐었던 파일일징라도 내용을 수정학 git add를 하면 그 파일은 staged 상태

자신만의 정리

• git help 를 사용해서 커맨드의 의미와 사용법을 자세히 알 수 있음!

ex) git help add

• 자주 쓰이는 Git Command

  • 현재 directory 의 모든 파일을 Staging Area 로 이동
    • git add .
  • file 들의 tracking 상태 보기
    • git status
  • Staging 의 파일들 commit 하기
    • git commit -m "messsage"
  • 저장소에 commit 반영하기
    • git push
  • 저장소에서 commit 가지고 오기
    • git pull
  • remote origin의 development branch merge
    • git merge origin/development
  • 한 줄로 그래프 형태로 commit 히스토리 보기
    • git log --oneline --graph
  • remote에서 삭제된 brach를 local 에서도 깔끔하게 삭제
    • git fetch origin --prune

• *작성자: 권은빈

[박민주] 1주차 정리

HEAD란?

Git은 매 순간의 파일이 아닌 매 순간의 변경점을 저장하는데 이 흐름(stream)을 연결해서 보는 시점,
즉 시점마다 보고있는 머리를 HEAD라고 한다.

깃의 3가지 영역?

$ git init 명령어로 git이 해당 디렉토리를 추적하도록 초기화하면 .git이라는 폴더와 함께 이 3가지 영역이 만들어진다.

• Working Dir : 작업하는 공간

변경 사항 (파일 추가, 삭제, 파일 변경, 파일 경로 변경 등) 발생하면 git은 이를 알아차린다.
이 변경 사항을 add 명령어를 통해 변경 사항을 snapshot으로 기록 시 Staging Area에 기록

• Staging Area : 저장소

변경 사항이 Staging Area에 저장되고 commit 명령어로 변경 사항을 저장한 내용은 바로 Local Repo에 저장된다.

• Local Repo : 임시 저장 공간

그 후에 업로드 시 git의 3가지 영역을 넘어 깃허브의 Remote Repo에 push 명령어를 통해 업로드한다.

깃의 4가지 상태

• Untracked 상태

git이 추적하지 않는 상태 ex) 파일 자체를 아에 처음 생성해준 경우

• Tracked 상태

git이 파일의 변경사항을 추적중인 상태 ex) 파일 변경이 일어나면 git이 알고 사용자에게 알려주는 상태
Tracked 상태는 다시 3가지 상태로 나뉜다.

• Unmodified 상태

commit으로 저장되었고, 더 이상 변경이 없는 상태

• Modified 상태

commit한 저장 내용에서 추가적으로 변경이 발생한 상태

• Staged 상태

add하여 Staging Area에 기록된 상태

자신만의 정리

$ git init : 준비
$ git add <파일 경로 이름> or $ git add . : 한 시점에 찍어 추가
$ git commit -m "commit 메시지" : 저장 및 구분하기 쉽게 이름 짓기
$ git remote add origin <저장소 주소>
=> git아 ! remote 주소 add 할건데 origin 이라는 이름으로 <저장소 주소> 저장해줘~
$ git push origin <branch 이름>
=> git아 ! 저장된 내용을 모두 push할건데 origin 이름의 주소에 를 밀어 넣어줘~

**작성자: 박민주

[서재원] 2주차 인증

fast-forward merge

• merge = 여러 브랜치에서 작업된 것을 합치는 과정
• fast-forward merge란 ?
  • 실질적으로 변경사항을 합치는과정이 아닌 참조값만 옮기는 상황
  • 예) 동일한 main에서 나온 브랜치 a,b에서 a에 새로운 변경사항이 반영되었을 때 둘을 머지하게 된다면 b 브랜치가 참조하는 커밋을 a의 새로운 변경사항 커밋으로 변경만 해준다면 두 브랜치의 변경사항을 합칠 수 있다.

3-way-merge

• 3-way merge란?
  • 3가지 변경 흐름을 보고 비교하여 합치는 과정, 비교를 하게 되는 main을 base라고 부른다.
• a,b 에서 모두 변경 사항이 발생한 경우에 둘을 합친다면?
  • 수정사항이 어느 것이 추가/삭제되고 무엇을 넣어야할지 확인하기 위해서 a,b가 갈라진 시점의 커밋이 필요하다
  • 갈라진 시점의 커멋과 a,b 변경점을 비교하고 두 변경사항을 하나로 합친 변경점을 생성

Conflict

• merge를 진행할 때 git이 해결할 수 없는 부분을 우리에게 선택을 요구하는 것이다.

자신만의 정리

• fast-forward vs 3 way
  • 가장 큰 차이점은 새로운 커밋이 발생하는지 여부이다.
  • fast-forward는 병합을 진행할 때 새로운 커밋이 생기지 않고 브랜치의 Head가 다른 브랜치의 Head로 참조가 변경된다.
    • Head가 이동한 것이기 때문에 merge commit 이력이 남지 않는다. (commit이 생기지 않으니까 당연한건가?)
  • 3 way는 base와 2개의 변경점 파일을 비교하고 머지하여 새로운 커밋을 발생키시는 것이고 conflict가 발생할 수 있으니 당황하지 말고 어떤 변경으로 반영을 해야할 지 선택해주면 된다.

*작성자: 서재원

1주차 정리

HEAD란?

Git 내의 연결하는 흐름 중에서 바라보고 있는 시점(머리)

---

깃의 3가지 영역

Working Directory

• 변경 사항 발생
  • 파일 추가/삭제/수정
  • 파일 변경 (내용 추가/삭제)
  • 파일 경로 변경 등

add : 변경사항 기록 → Snapshot 기록 → Staging Area

Staging Area

• 과거 기록 시점 직후 부터의 변경 사항들 중
  add 된 변경 사항들이 저장되어 있는 영역
• commit 으로 묶게 되면 하나의 변경 시점으로서 기록

commit : 변경사항 저장 → Local Repository

Local Repository

• 기록된 commit 들의 영역

push : 변경사항 반영 & 업로드 → Remote Repository

---

깃의 4가지 상태

• Untracked : Git이 추적하지 않는 상태
  : 파일 자체를 아예 처음 생성해준 경우는 git이 변경사항을 추적하지 않는다.
• Tracked : Git이 추적하는 상태
  : 파일 변경이 일어나면 Git이 알고 사용자에게 알려주는 상태
  • Unmodified : Commit으로 저장 & 더 이상 변경이 없는 상태
  • Modified : Commit 한 저장 내용에서 추가적인 변경이 발생한 상태
  • Staged : Add 해서 Staging Area에 기록된 상태

---

자신만의 정리

역방향 관리

• Remote Repository → Local Repository : pull
• Local Repository → Staging Area : reset --mixed
• Staging Area → Working Directory : restore --staged

[Untracked]  [Unmodified]   [Modified]    [Staged]
    |              |             |            |
    |--------------------(add)--------------->|
    |              |<-----------(commit)------|
    |              |             |            |
    |              |--Edit file->|            |
    |              |             |--(add)---->|
    |<-Remove file-|             |            |
    |              |             |            |

⁜ 단, 위 Remove file이 Untracked 상태로 변환되는 것은 “삭제되는 파일”의 기준이지
전체 Flow 내에서는추적 중이던 파일의 삭제 또한 변경으로 인식하기 때문에 “삭제” 자체가 변경으로서 기록

작성자: 정동규 ( 32th YB Server )

[이준희] 1주차 정리

HEAD란?

git은 매 순간의 파일을 저장하는 것이 아닌 변경점을 저장한다.
따라서 시간의 흐름으로 보기 위해서는 변경점의 흐름을 연결해서
보아야하는데, 이때 흐름을 보는 시점을 HEAD라고 한다.

깃의 3가지 영역

init 명령어로 git이 해당 directory를 추적하도록 초기화하면
git 폴더와 아래 3가지 영역이 만들어진다.

1. working directory

   작업을 하는 공간 -> 실제로 파일을 생성하고 수정하는 공간임

2. Local Repo

   git에서 작업한 이력들을 저장 -> 저장소

3. Staging Area

   git add한 파일들이 존재하는 영역 -> 커밋하면 여기 있는 파일들만 커밋에 반영됨

깃의 4가지 상태

1. Untracked 상태
   git이 추적하지 않는 상태
   파일 자체를 아예 처음 생성해준 경우 → git이 변경사항을 추적하지 않음

2. Tracked 상태

   git이 파일의 변경사항을 추적 중인 상태
   파일 변경이 일어나면 git이 알고 사용자에게 알려주는 상태

   3가지 상태로 나뉨

   1. Unmodified : commit으로 저장되었고, 더 이상 변경이 없는 상태
   2. Modified : commit 한 저장 내용에서 추가적으로 변경이 발생한 상태
   3. Staged : add 하여 Staging Area에 기록된 상태

작성자: 이준희

[이동헌] 1주차 정리

HEAD란?

• 깃에서 시점마다 보고 있는 머리 : 가장 최종 커밋이 된 시점에서 전체흐름을 봄.

깃의 3가지 영역

init이라는 명령어 -> git이 해당 dir을 추적 -> .git이라는 폴더와 함께 3가지 영역 생성
실질적인 깃의 영역 :

• 종이(local dir)
• 카메라(staging area)
• 컴퓨터(local repo)

영역을 넘어갈 때 add -> commit -> push -> pull 까지 주로 씀

깃의 4가지 상태

1. untracked : git이 추적하지 않는 상태.
2. tracked 상태 : git 이 추적
   a. unmodified : 커밋 후 변경 X
   b. modified : 변경 발생
   c. staged : add 하여 staging area에 기록된 상태.

자신만의 정리

• 종이(local dir) 카메라(staging area) 컴퓨터(local repo) 블로그(remote repo)

1. 준비물을 준비 : git init
2. 종이에 변경사항 발생
3. 카메라로 촬영 : git add . or git add <파일 경로 이름>
4. 각 사진에 이름 지어 컴퓨터에 저장 : git commit -m "커밋 메세지"
5. 주소창에 블로그 주소를 입력 : git remote add origin <저장소 주소>
   (git아, remote 주소 add 할건데, origin 이라는 이름으로 <저장소 주소> 저장해)
6. 저장된 사진을 블로그에 밀어넣기 : git push origin <브랜치 이름>
   (git아 저장된 내용을 push 할건데, origin 이름의 주소에 branch 밀어 넣어줘)

작성자: 이동헌

[김준서] 2주차

fast-forward merge

fast-forward merge란, 같은 시점에서 나온 두 branch 중 하나는 변경사항이 없고, 다른 하나만 변경사항이 있을 때
이름 그대로 변경사항이 없는 branch가 다른 branch에서 나온 변경사항을 참조하도록 forward로 이동하는 것!

• fast-forward 는 빨리감기 라는 뜻인데, 단순히 앞으로만 이동하면 되어서 이런 이름이 지어진게 아닐까 싶다.

3-way merge

base가 되는 commit에서 나온 두 흐름 모두 변경사항이 있을 때
새로운 커밋을 만들어 두 흐름이 이 커밋을 참조하게 되는 것.

그 과정에서 기존의 commit에 각 branch에서 나온 변경점들을 적용하게 되고, 기준이 되는 옛 commit을 base라고 함

• 이 merge에 필요한 commit이 총 3개라, 3-way merge 라는 이름이 붙지 않았나 싶다.

자신만의 정리

그러나 위의 2가지 경우는 매우 이상적인 상황이고, 특히 3-way merge 과정에서는 두 변경점의 위치가 겹치는 경우가 발생하게 된다.
이를 충돌(conflict)라 한다. 이는 오류나 문제 상황이 아닌, 서로의 작업이 한 공간의 한 곳에서 발생한 것일 뿐이므로, 이러한 작업 내용을 적절히 나누고, 겹치는 부분은 삭제하면 되겠다.

**작성자: 김준서

[정채은] 2주차 정리

fast-forward merge

참조값을 변경하여 브랜치의 변경사항을 하나로 합치는 merge 방법
바라보고 있는 흐름을 뒤에 있는 흐름으로 참조값을 옮기는 방법

3-way-merge

모두의 변경점을 비교하고 변경사항을 모두 기록하여 합치게 되는 것, 그리고 이렇게 합치겠다고 커밋을 통해서 합쳐줌
merge의 결과는 commit
갈라진 시점이 base

자신만의 정리

main에 있을 때 HEAD는 main에 있고, 변경 사항이 발생할 경우 main에 생김
checkout - 변경 외에도 파일 복원 시에도 사용함
switch - 최신 버젼, 위를 분리하여 브랜치 변경에 사용
conflict - 내용이 겹칠 경우 충돌이 발생할 수도 있음, 어떻게 할 것인지 개발자에게 물어봄

**작성자: 정채은 **

[윤주영] 1주차

HEAD 란?

깃은 시간의 흐름에서 해당 시점의 파일 상태를 저장하지 않는다. 깃은 매 순간의 변경점을 저장하기 때문에 하나의 변경점을 보는 것이 아니라 그 흐름을 연결해서 봐야 한다. 이 흐름을 연결해서 보는 시점을 헤드라고 한다.

깃의 3가지 영역

Working Dir

[변경 사항 발생] 파일 추가 또는 삭제, 파일 내용 추가 또는 삭제, 파일 경로 변경 등 git 이 이를 알아차린다

Staging Area

SnapShot을 기록한다.
git add <파일 이름>

Local Repo

변경사항을 저장한다.
git commit -m "커밋 메시지"

깃의 4가지 상태

untracked

• git이 추적하지 않는 상태를 의미
• 파일 자체를 아예 처음 생성해준 경우는 git이 변경사항을 추적하지 않는다

tracked

• git이 파일의 변경사항을 추적중인 상태이다
• 파일 변경이 일어나면 git이 알고 사용자에게 알려주는 상태이다

상태	설명
unmodified	commit 으로 저장되었고, 더 이상 변경이 없는 상태
modified	commit 한 저장 내용에서 추가적으로 변경이 발생한 상태
staged	add 하고 staging area 에 기록된 상태

자신만의 정리

🔗 깃털 1주차

작성자 : 윤주영

[권혜인] 2주차 정리

fast-forward merge

바라보고 있는 흐름의 시점을 뒤에 있는 참조값으로 옮기는 것

3-way-merge

두 변경 사항 확인 두 변경사항을 합침
두 변경사항의 변경점을 만들어 저장
반드시 새로운 commit 생성

자신만의 정리

Branch: HEAD와 같이 최신 commit을 참조하게 변경됨
checkout switch

conflict : 어떤 변경점인지 개발자에게 물어보기
잘못된 것이 아님!

작성자: 권혜인

[권혜인] 1주차 정리

HEAD란?

-> Git은 매 순간 파일이 아닌, 매 순간 변경점을 저장한다.
이러한 흐름을 Stream, 순간의 변경점을 스냅샷이며,
Git에서 시점마다 보고 있는 부분을 HEAD라고 한다.
하나의 변경점이 아닌 흐름을 연결해서 봐야 하고, 흐름을 연결해서
보는 시점 = HEAD!

깃의 3가지 영역

Working Dir : 변경 사항 발생(파일 추가, 삭제, 변경)
Staging Area : 변경 사항 기록 (add)
Local Repo : commit을 통한 저장

깃의 4가지 상태

1. Untracked: git이 추적하지 않는 상태, 파일을 처음 생성한 경우
2. Tracked : git이 변경 사항을 알려줌
   2-1. Unmodified: commit으로 저장, 더 이상 변경이 없음
   2-2. Modified: commit한 저장 내용에서 추가적으로 변경 발생
   2-3. Staged: add해서 staging area에 기록된 상태
   

자신만의 정리

준비물: git init
찍어 놓기: git add <파일 이름 경로> or git add . (경로의 모든 파일)
쉽게 구별: git commit -m "commit 메세지" -> git에서 id할당, 구별하기 좋은 라벨지를 붙여줌
올려야 할 저장 주소 git remote add origin <주소>
origin: github 내 저장소의 컴퓨터 주소를 지칭
등록하기: `git push origin <branch 이름>

**작성자: **

[김동현] 1주차 인증

HEAD란?

git의 경우 우리가 흔히 아는 것처럼 버전이 바뀔 때의 바뀐 버전의 파일을 저장하는 것이 아니다. A시점에서 B시점으로 변경되었을 때 변경된 것이 무엇인지 체크를 하는 것이다. 이때 변경점에 대한 흐름을 git의 시점에서 보고있는 머리를 HEAD라고 하는 것이다.

깃의 3가지 영역

• Working Dir: 변경사항의 발생과 관련된 부분
• Staging Area: 이러한 변경사항은 Staging Area에 기록된다.
• Local Repo: 실질적으로 변경된 사항을 저장하는 부분

깃의 4가지 상태

• Untracked: 추적되지 않는 상태
• Tracked: 추적되는 상태

Tracked는 3가지 상태로 또 나뉘어진다.

1. Unmodified
   커밋으로 저장되었고 더 이상 변경할 것이 없는 상태

2. Modified
   커밋 이후 무언가 변경된 상태

3. Staged
   add하여 Straging Area에 기록된 상태

자신만의 정리

• 변경된 하나의 파일을 저장하는 것이 아니라, 변경된 시점에서 변경된 내용을 체크하는 것이 Git이다.

작성자: 김동현

[박희정] 1주차 정리

HEAD란?

Git은 매 순간의 변경점을 저장하기 때문에 흐름을 연결해서 봐야 하고, 이 때 흐름을 연결해서 보는 것이 head이다.

깃의 3가지 영역

init 명령어로 git이 추적할 수 있도록 하면, 아래와 같이 3가지 깃의 영역이 만들어진다.

1. Working Directory
   종이에 비유되며, 작업공간으로서 변경사항이 발생한다.
2. Staging Area
   카메라에 비유되며, add 명령어로 변경사항을 기록할 때 Staging Area 에 기록된다.
3. Local Repository
   컴퓨터에 비유되며, commit 명령어로 저장할 경우 Local Repository에 저장된다.

깃의 4가지 상태

1. Tracked 상태

• Git에 의해 추적되고 있는 상태이다.

1. Unmodified : commit으로 저장된 이후에 변경이 없는 상태
2. Modified : commit 한 후 변경이 있는 상태
3. Staged : add 함으로써 Staging Area에 기록된 상태

2. Untracked 상태

• Git에 의해 추적되고 있지 않는 상태이다.

자신만의 정리

Working Directory - > add -> Staging Area
Staging Area -> commit -> Local Repository
Local Repository -> push -> Remote Repository
Local Repository <- pull <- Remote Repository
Staging Area <- reset - mixed <- Local Repository
Working Directory -<- restore - staged <- Staging Area

**작성자: **
박희정

1주차 정리!

HEAD란?

Git에서는 매 순간의 파일이 아닌 변경점을 기준으로 상황을 저장합니다. 이 때 이 상황을 보고있는 시점을 나타내는 것을HEAD라고 합니다.

깃의 3가지 영역

깃에는 working dir, staging area, local repo가 존재합니다.

깃의 4가지 상태

Untracked - 깃이 추적하지않는 상태
Unmodified - commit 으로 더이상 저장할게없다
Modified - 추가적으로 변경이 있을 때
Staged - add하여 staging area에 기록된 상태

자신만의 정리

git add를 하면 staging area로 카메라로 찍은 시점을 올릴 수 있고, commit을 하면 local repo인 .git폴더에 내용을 저장할 수 있습니다. 여기까지가 우리의 로컬 컴퓨터에서 일어나는 일이고 $ git push origin main(예전엔 master)를 하면 이제 로컬이 아닌 우리의 깃허브 원격 저장소에 저장이 됩니다!

작성자: 김수현

[김윤지] 1주차 정리

HEAD란?

Git은 매 순간의 파일이 아니라 매 순간의 변경점을 저장한다. 이런 변경점들의 흐름을 연결해서 보는 시점을 HEAD라고 한다.

깃의 3가지 영역

git init 명령어로 git이 해당 Directory를 추적하도록 초기화하면 .git이라는 폴더와 함께 3가지 영역이 만들어 짐

Working Dir

• 변경 사항 발생 (파일 추가, 삭제, 경로변경 등)

Staging Area

• add 명령어를 통해 변경사항을 snapshot으로 기록하면서 Staging Area에 저장됨

Local Repo

• commit 명령어를 통해 변경사항을 저장하는 경우 Local Repo에 저장됨

이후 push 명령어를 통해 git의 3가지 영역에 포함되지 않는 Remote Repo에 업로드 됨

깃의 4가지 상태

Untracked

• git이 추적하지 않는 상태
• 파일 자체를 아예 처음 생성해서 git이 변경사항을 추적하지 않는 경우에 해당

Tracked

• git이 파일의 변경 사항을 추적 중인 상태
• 파일 변경이 일어나면 git이 알고 사용자에게 알려줌
  • Unmodified : commit으로 저장되었고, 더 이상 변경이 없는 상태
  • Modified : commit 한 저장 내용에서 추가적으로 변경이 발생한 상태
  • Staged : add 하여 Staging Area에 기록된 상태

자신만의 정리

Git이 어려운 이유? 매 순간의 파일이 아닌 변경점을 저장하기 때문(이전 순간에 대한 변경점만 표시!)

Git 용어

• 하나의 변경점을 보는 것이 아니라, 시간의 흐름을 따라 순간의 변경점이 연결되기 때문에 이러한 형태를 깃에서는 Stream이라고 함
• 순간의 변경점을 찍어둔 것을 스냅샷이라고 함
• 흐름을 연결해서 보는 시점을 Head라고 함

현실 예시로 알아보는 파일 관리

• 준비물을 준비
  • $ git init
• 직접 글을 작성할 종이 -> local Dir
  • 종이를 찍어서 카메라에 추가
  • $ git add <파일 경로 이름> or $ git add .
• 과정을 촬영할 카메라 -> Staging Area
  • 컴퓨터에 올릴 때 각 사진을 구분하기 쉽게 이름을 지어줌
  • $ git commit -m "commit 메세지"
• 블로그에 올리기 전 파일을 모아둘 컴퓨터 -> local repo
  • 블로그에 올리기 위해 주소창에 블로그 주소 입력 (git에서 github로 넘어가는 구간)
  • git아 remote 주소 add 할건데 origin이라는 이름으로 <저장소 주소> 저장해!
  • origin = github 내 저장소의 컴퓨터 주소
  • $ git remote add origin <저장소 주소>
• 실제로 포스팅을 할 블로그 -> remote repo
  • 저장된 사진들을 블로그에 밀어 넣어서 포스팅
  • $ git push origin <branch 이름>

Git의 3가지 영역과 4가지 상태

git init 명령어로 git이 해당 Directory를 추적하도록 초기화하면 .git이라는 폴더와 함께 3가지 영역이 만들어 짐

Working Dir

• 변경 사항 발생 (파일 추가, 삭제, 경로변경 등)

Staging Area

• add 명령어를 통해 변경사항을 snapshot으로 기록하면서 Staging Area에 저장됨

Local Repo

• commit 명령어를 통해 변경사항을 저장하는 경우 Local Repo에 저장됨

이후 push 명령어를 통해 git의 3가지 영역에 포함되지 않는 Remote Repo에 업로드 됨

Git의 3가지 영역을 오가는 파일에 대한 4가지 상태

Untracked

• git이 추적하지 않는 상태
• 파일 자체를 아예 처음 생성해서 git이 변경사항을 추적하지 않는 경우에 해당

Tracked

• git이 파일의 변경 사항을 추적 중인 상태
• 파일 변경이 일어나면 git이 알고 사용자에게 알려줌
  • Unmodified : commit으로 저장되었고, 더 이상 변경이 없는 상태
  • Modified : commit 한 저장 내용에서 추가적으로 변경이 발생한 상태
  • Staged : add 하여 Staging Area에 기록된 상태

작성자: 김윤지

[최윤정] 1주차 인증

HEAD란?

내가 파일을 변경할때마다 git이 그걸 보고 저장을 하는데 그 흐름을 보는 시점을 head라고 한다.

깃의 3가지 영역

1. workgin directory - 종이 (그림그리기)
2. staging area - 카메라 (찰칵)
3. local repo - 내 영역에 (내 갤러리에저장 )

깃의 4가지 상태

1. tracked
2. untracked
   • unmodify : commit으로 저장되고 변경이 없는 상태
   • modify : commit이후 뭔가 변경했을 때
   • staged : add해서 staging area에 기록 된 상태

자신만의 정리

4.remote repo - 갤러리에 저장한걸 네이버클라우드에 업로드~

1. 어쩌고라고 작성
2. add
3. commit
4. push

**작성자: 최윤정

스장님 고생이 많으십니다

[우상욱] 1주차 정리

HEAD란?

깃은 매 순간의 변경점을 저장한다.
하나의 변경점을 보는 것이 아닌 흐름을 봐야하는데, 그 흐름을 연결해서 보는 시점을 HEAD라고 한다.

깃의 3가지 영역

init 명령어로 초기화시, .git이라는 폴더와 함께 3가지 영역이 만들어진다.

Working Dir

• 변경 사항 발생 (파일 추가 or 삭제)
  Staging Area
• snapshot 기록 (add 명령어를 통해 변경사항 기록)
  Local Repo
• commit 명령어로 변경사항 저장

---> push 명령어를 통한 remote repo로 전달

깃의 4가지 상태

Untracked 상태

• git이 추적하지 않는 상태를 의미한다.

Tracked 상태 (Unmodified, Modified, Staged로 나뉨)

• git이 파일의 변경사항을 추적중인 상태

Unmodified 상태

• commit으로 저장되었고, 더 이상 변경이 없는 상태

Modified 상태

• commit한 내용에서 추가적인 변경이 발생한 상태

Staged 상태

• add하여 Staging Area에 기록된 상태

자신만의 정리

$ git init - 준비물을 준비
직접 글을 작성할 -> local Dir
과정을 저장할 -> Staging Area
파일을 모아둘 -> local repo
모아둔 파일을 적용할 -> remote repo

$ git add <파일경로이름> or $ git add . - 변경된 점을 남긴다

$ git commit -m "commit 메시지" - 변경 사항을 저장(구별하기 좋은 라벨지를 붙여주는 과정)

$ git remote add origin <저장소 주소> - origin이라는 이름으로 <저장소 주소>에 저장

$ git push origin <branch 이름> - origin 이름의 주소에 를 밀어 넣는다

**작성자: 우상욱

[곽성준] 1주차 인증

HEAD란?

HEAD : 흐름(stream)을 연결해서 보는 시점

깃의 3가지 영역

git init 명령어(git이 해당 directory를 추적하게 한다)를 실행하면 .git이라는 폴더와 함께 Working Directory, Staging Area, Local Repository라는 3가지 영역이 생긴다.

1. Working Directory : 변경사항 발생 (파일 삭제, 생성, 내용추가 등), add 명령어를 실행해 Staging Area에 기록시킨다.
2. Staging Area : 기록된 변경사항을 commit 명령어를 실행시켜 Local Repository에 저장한다.
3. Local Repository : 저장된 사항을 push 명령어를 실행시켜 git의 영역이 아닌 github의 Remote Repository에 업로드시킨다.

깃의 4가지 상태

git은 크게 2가지 상태로 나눌 수 있다. git이 추적하는 상태와 추적하지 않는 상태다. git이 추적하지 않는 상태는 untracked, 추적하는 상태면 Tracked이다. git이 추적하고 있으면 변경사항을 git이 알게 된다. Tracked 상태에는 Unmodified, Modified, Staged 상태가 있다.

1. Unmodified : commit으로 저장되었고, 더 이상 변경 사항이 없는 상태
2. commit한 저장 내용에서 추가적으로 변경이 발생한 상태.
3. add하여 Staging Area에 기록된 상태

자신만의 정리

git은 매 순간의 파일이 아닌 매 순간의 변경점을 저장한다. 변경점을 저장하기 때문에 처음부터 현재까지의 변화의 흐름을 봐야 된다.
**작성자: 곽성준

[김수현] 2주차 정리

fast-forward merge

단순히 바라보고 있는 참조값만 옮기는 상황
단순하게 어떤 브랜치(멀티버스)의 상황이 기존의 내용에서 추가되거나 큰 변경사항이 없어 head가 바라보고 있는 곳을 옮겨서 같은 멀티버스를 보게 만드는 merge 상황!

3-way-merge

두 가지 변경사항이 합쳐지는 경우 전에 base가 된 c2 커밋과 a,b라는 두 가지의 다른 변경사항들을 비교하여 새로운 커밋을 만들어 변경사항들을 모아서 합칠 때 c2를 base라고 부르고 이 base, a,b의 변경사항을 합치는 과정을 3-way merge라고 부른다.

자신만의 정리

브랜치는 하나의 멀티버스다.
첫 커밋 시에는 사실 main이라는 브랜치가 만들어지는 것이다. 예전에는 master!
다른 브랜치로 이동하여 다른 멀티버스를 보려면 git switch branch를 통해 이동하면 된다.
기존에는 master였으나 git 2.x 버전으로 바뀌면서 main으로 바뀌었다.
conflict는 base와 다른 내용으로 다른 a, b브랜치에서도 같은 위치에 다른 변경사항이 있을 때 발생한다.
오류인 것 같지만 오류가 아니니 당황하지말 것.
작성자: 김수현

[배지현] 2주차 정리

fast-forward merge

✔ A에는 새로운 기능이 만들어지고 B에는 변경 사항이 없는 경우, B에 A를 합치고 싶은 경우

• B가 참조하는 commit을 A가 참조하는 commit으로 바꾸면 됨
  • 이 경우 B가 A의 변경점을 가진 흐름이 되므로 두 branch의 변경 사항을 하나로 합칠 수 있음
• 새로운 변경점을 생성하지 않아도 됨
• 실질적으로 변경 사항을 합치는 과정이 아닌 참조값만 옮기는 과정

3-way-merge

✔ A, B 모두 변경 사항을 가졌을 때, A에 B를 합치는 경우

• A, B의 변경점을 비교한 뒤 변경 사항을 하나로 합친 변경점을 새로 만들어 실제로 이렇게 합치겠다라고 git에게 말하면 됨
• 이 경우 merge의 결과로 새로운 commit이 생성됨
• A, B에 존재하는 변경 사항을 모두 봐야 함
• 합쳐지는 과정에서 필요한 것이 3가지이므로 3-way merge
  1. A가 참조하는 commit
  2. B가 참조하는 commit
  3. A와 B로 나누어지기 전의 commit = A와 B가 참조하는 commit을 비교하는 base

자신만의 정리

branch

• branch = 멀티버스
• 생성된 위치의 commit을 참조
• HEAD가 보는 위치에서 변경 사항을 저장하면 branch 또한 HEAD와 같이 최신 commit을 참조하게 변경
• HEAD가 branch를 참조하고, branch는 commit을 참조함
• branch 사용 장점?
  • 동일한 시점에 여러 명이 여러 작업을 동시에 할 수 있게 됨
  • 즉, 병렬적인 작업이 가능함

conflict

• 두 branch에서 내용이 겹치는 경우 conflict 발생
• base에 없던 내용이 A, B 모두에 추가된 경우 git은 A와 B 중 무엇이 해당 라인의 변경점인지 알 수 없음
  • 이 경우 git이 두 변경 중 무엇이 이 곳의 변경점인지 개발자에게 물어보게 됨
  • 이 과정을 conflict라고 함
• conflict는 에러나 잘못된 것이 아님
  • git이 해결할 수 없는 부분을 우리에게 해결하도록 하는 것
  • conflict이 발생하는 부분을 고쳐서 실제 변경 사항에 넣어주면 conflict 해결 가능!

작성자: 배지현

[김성은] 1주차 정리

HEAD란?

• 깃허브는 매 순간마다 파일이 아닌 변경점을 저장하는데, 우리는 이 변경점을 기준으로 바라보는 곳을 변경할 수 있다.
• 이때 우리가 바라보는 시점을 HEAD라고 한다

깃의 3가지 영역

• Working Directory
• Staging Area
• Local Repository
• git flow
  1. git init 명령어로 git이 working dir를 추적하도록 초기화하면 .git 이라는 폴더와 함께 위의 3가지 영역이 만들어진다
  2. 작업 폴더에서 파일을 만들거나 삭제하는 변경사항이 발생한다면 git이 알아차리게 된다
  3. 이러한 변경사항을 기록하고자 add 명령어를 사용하며, 해당 기록(snapshot)은 staging area에 저장된다
  4. commit을 하게 되면 변경 사항이 Local Repository에 저장된다
  5. 그 후에 push 명령어를 통해 Remote Repository에 업로드할 수 있다
• 여기서 Remote Repository는 git의 3가지 영역에 포함되지 않는다

깃의 4가지 상태

• Untracked 상태
  • git이 추적하지 않는 상태를 의미한다
  • 파일 자체를 아예 처음 생성한 경우는 git이 변경사항을 추적하지 않는 상태인 untracked에 해당한다
• Tracked 상태: Unmodified, Modified, Staged 상태로 나눌 수 있다
  • Unmodified: commit으로 저장되었고, 더 이상 변경이 없는 상태이다
  • Modified: commit한 저장 내용에서 추가적으로 변경이 발생한 상태이다
  • Staged: add하여 Staging Area에 기록된 상태이다

자신만의 정리

• 삭제된 파일과 관련하여 깃의 상태를 정리해보자
  • 파일을 삭제한다고 해서 바로 untracked 상태가 되는 것은 아니다
  • 삭제하는 것 또한 변경으로 인식되기 때문에 삭제할 경우 git이 추적하여 unmodified 상태가 되었다가, add를 통해 staged 상태가 되며, commit을 통해 삭제된 것에 대한 변경사항을 저장하면 다시 unmodified 상태가 된다
  • 이렇게 commit을 하여 삭제된 변경 상태를 저장한 상태 이후로는 해당 파일이 존재하지 않기 때문에 untracked 상태가 된다

작성자: 김성은

[김의성] 1주차정리

HEAD

git에서 시점마다 보고있는 머리를 HEAD라고 한다

깃의 3가지 영역

1. workgin directory - 작업공간
2. staging area - 저장소
3. local repo - 임시저장공간

깃의 4가지 상태

1. tracked - 깃이 파일의 변경을 추적중인 상태(세가지 상태로 나뉨)

• unmodify : 커밋으로저장되고, 이후 변경이 없는 상태
• modify : 커밋한 내용에서 추가적인 변경이 발생한 상태
• staged : add하여 저장소에 기록된 상태

2. untracked - 깃이 추적하지 않은 상태(파일 처음생성시)

자신만의 정리

git init -> 깃준비
git add . -> 찍어놓기, 추가
git commit -m “커밋메세지”
git remote add orgin [원격저장소 url] -> orgin이라는 이름으로 [원격저장소 url]을 다루겠다
git push [저장소] [브랜치이름]

작성자: 김의성

[서재원] 1주차 인증

HEAD란?

• Git에서 흐름 시점마다 보고 있는 머리를 HEAD라고 칭한다.

깃의 3가지 영역

$ git init 으로 생성되는 3가지 영역

• Working Dir

  • 파일 변경사항 발생(추가, 삭제, 이동)

• Staging Area = snapshot으로 기록

  • ex) add 명령어를 통해 변경사항을 기록
  • $ git add file.txt

• Local Repo(.git)

  • commit 명령어로 변경사항을 저장
  • $ git commit -m “코멘트”

• Remote Repo (git의 3가지 영역에 포함되지 않음)

  • push 명령어를 통한 내용을 리모트로 업로드
  • $ push origin main

깃의 4가지 상태

• Untracked State
  • git이 파일의 변경사항을 추적하지 않은 상태를 의미한다.
  • 초기 파일 생성시 변경사항을 추적하지 않는다.
• Tracked State
  • git이 파일의 변경사항을 추적중인 상태를 의미한다.
  • Unmodified
    • commit으로 저장되었고 더 이상 변경이 없는 상태
  • Modified
    • commit한 내용에서 추가적으로 변경이 발생한 상태
  • Staged
    • add 하여 Staging Area에 기록된 상태

자신만의 정리

• 깃은 변경점을 기준으로 snapshot을 기록하고 그 snapshot을 이은 흐름을 이어서 전체 프로젝트를 기록한다.
• 흐름을 기록하는 과정에서 3가지 영역과 4가지의 상태를 유의하여야 하고 생각없이 commit을 날렸던 나를 다시 생각하게 되었다.
• Head에 대한 추가 내용
  • Head는 현재 체크아웃된 브랜치의 가장 최신 커밋을 가리킨다.
  • 브랜치를 변경하게되면 변경한 브랜치의 가장 최신 커밋을 가리키게 되는데 보통 브랜치의 이름을 가리키게 되니 잘 살펴보자.
  • Head는 체크아웃된 브랜치의 가장 최신 커밋을 가리키는 포인터라고 생각하면 좋을 것 같다.

*작성자: 서재원

[장명지] 1주차 정리

HEAD란?

• 깃은 매 순간의 변경점을 저장하기 때문에 흐름을 연결해서 처음부터 현재까지 모든 흐름에 따른 변화를 봐야한다.
  흐름을 연결해서 보는 시점, 이것을 HEAD라고 한다.

깃의 3가지 영역

• init 명령어로 git이 해당 Directory를 추적하도록 초기화 하면 .git이라는 폴더와 함께 3가지 영역이 만들어진다.

영역1	영역2	영역3
Working Dir	Staging Area	Local Repo
변경 사항 발생시	snapshot 기록	변경사항 저장
파일 추가 or 삭제 파일변경(내용 추가 or 삭제) 파일 경로 변경 등	add명령어를 통해 변경사항을 기록 할 때 이곳에 기록됨	commit명령어로 변경사항을 저장하는 경우

remote repo는 다른 영역!
내용을 리모트로 업로드 함! "push 명령어를 통한 업로드"

깃의 4가지 상태

먼저 git 의 상태는 두 가지로 분류가능하다.

• Untracked(git이 추적하지 않는 상태): 파일 자체를 아예 처음 생성해준 경우 git이 변경사항을 추적하지 않는다
• Tracked(git이 추적하는 상태): 파일 변경이 일어나면 git 이 알고 사용자에게 알려준다.
  - Unmodified : commit으로 저장되었고 더 이상 변경이 없는 상태
  - Modified: commit한 저장 내용에서 추가적으로 변경이 발생한 상태
  - Staged : add 하여 Staing Area에 기록된 상태

4가지 상태 : Untracked Unmodified Modified Staged
Untracked => add => Staged
Modified=> add => Staged
Staged => commit => Unmodified

파일의 삭제 => 삭제가 아닌 삭제또한 파일의 변경으로 추적함<Modified>상태에서 add 한걸 commit 해서 기록에 남게 되면 로 돌아옴. 실질적으로 파일을 삭제한 것이기에 <Untracked>상태가 된다. (동일한 이름의 파일을 만들어도 이미 삭제되었고 그 파일은 새로 만들어진 파일로 < Untracked>상태가 된다.)

자신만의 정리

---

• Working Dir=>git add .(or 작업디렉토리) => Staging Area
• Staging Area => git commit -m"" => Local Repo
• Local Repo => git push => Remote Repo
• Remote Repo => git pull =>Local Repo

작성자: 장명지

[서아름] 1주차 정리

HEAD란?

• 작업 중인 브랜치의 마지막 커밋 id를 가리키는 참조 포인터
• HEAD는 현재 체크아웃된 브랜치의 가장 최신 커밋을 가리킴
• branch 변경 시, 변경한 branch의 가장 최신 commit을 가리키고, HEAD는 브랜치 이름을 가리키도록 표시

👉 HEAD → [branch name]

위와 같이 HEAD가 특정 영역에 찍혀 있다면, HEAD는 [branch name] 브랜치를 포인터로써 가리키고 있음을 알 수 있다!

깃의 3가지 영역

✅ Working Directory

작업하고 있는 프로젝트의 디렉토리/ 실제로 파일을 생성하고 수정하는 공간

✅ Staging Area

변경 사항들이 모여있는 공간

✅ Local Repo

변경사항들을 저장하는 저장소

깃의 4가지 상태

✅ Untracked: 파일 생성 후, 파일을 한 번도 git add 해주지 않은 상태

✅ Tracked: 파일 생성 후, git에 의해 변경 사항이 추적되고 있는 상태

👉 Tracked 상태는 3가지 상태로 나뉨!

1. staged : staging area에 올라와 있는 상태
2. unmodified : 최신 커밋과 현재 파일이 동일한 상태
3. modified : 현재 파일에 변경 사항이 있는 상태

[이동섭] 2주차 정리

fast-forward merge

👉 실질적으로 변경사항을 합치는 과정이 아닌 그저 참조값만 옮기는 상황
👉 합치려는 두 branch의 한쪽에만 변경사항이 있을 경우

❗️ feat/b가 참조하는 커밋을 a1으로 바꾸면 a1의 변경점을 가진 흐름이 됨
❗️ a1이라는 변경점을 새로 생성하지 않아도, 참조값을 변경하여 두 branch의 변경사항을 하나로 합칠 수 있음

---

3-way-merge

👉 합치려는 두 branch에 모두 변경사항이 있을 경우, fast-forward 방식에 비해 복잡한 방법이 필요

👉 두 변경사항을 합치기 위해서는 a1, b1 라는 변경사항을 모두 봐야하며,
👉 수정사항이 어느 것이 추가/삭제 되고 무엇을 넣어야할지 확인하기 위해 git에서는 두 흐름이 만들어진 시점인 c2 커밋이 필요

❗️변경사항을 합친 변경점을 만들었을 뿐, 이를 저장하여 실제로 이렇게 합치겠다! 라고 git에게 commit 명령어를 통해 말해야 함
❗️merge의 결과로 반드시 새로운 commit이 생성됨

---

자신만의 정리

Branch

👉 git commit -m “c1”이라는 명령어를 통해 main branch가 생성됨 (root commit)
👉 HEAD → main branch → c1 순서로 참조함 (포인터 느낌)
👉 첫 commit이 생기면 main 흐름의 멀티버스가 생기고, HEAD는 그 멀티버스에 있게 됨

👉 git commit -m “c2” 명령어를 통해 HEAD가 보는 위치에서 변경사항 저장하면 HEAD → main branch → c2 로 변경
👉 git branch “feat” 명령어를 통해 feat branch → c2 로 변경 (하지만 HEAD는 main branch를 바라보고 있으므로, 추가적인 commit을 하게되면 아래 그림에서 위의 케이스처럼 될 것임)

---

Switch

👉 새로 만든 흐름인 branch에서 작업을 하려면, 그 브랜치로 이동해야함 (HEAD를 이동) → 변경사항은 우리가 있는 흐름에서 발생하고 저장할 수 있기 때문!
👉 checkout 명령어는 파일을 저장하는 역할도 하기 때문에, 단순히 branch를 변경은 switch 명령어를 사용!

---

Conflict

👉 git이 두 변경 중 무엇이 이 곳의 변경점인지 개발자에게 물어보게 되는데, 아래와 같은 코드를 수정해서 알려주면 됨

A-Login()
B-post()
<<<a1
A-auth()
===
B-auth()
>>>b1

---

작성자: 이동섭

1주차 정리

HEAD란?

변경되는 시점마다 보고 있는 머리
해당 브랜치의 마지막 커밋

깃의 3가지 영역

• Working Dir : 변경 사항 발생
• Staging Area : snapshot 기록하면 이곳에 기록
• Local Repo : 변경사항 저장 시 올라감

깃의 4가지 상태

• Untracked : 추적하지 않는 상태
• Tracked : 변경사항을 추적하는 상태
  • Unmodified : commit으로 저장되었고, 더이상 변경할 것이 없는 상태
  • Modified : commit 한 저장 내용에서 추가적으로 변경 발생한 상태
  • Staged : add 해서 Staging Area에 기록된 상태

자신만의 정리

스냅샷 - 순간의 변경점을 찍어둔 것
커밋 메세지 - 구별하기 위함
Working Dir -> Staging Area (add)
Staging Area -> Local Repo (commit)
Local Repo -> Remote Repo (push)
Remote Repo -> Local Repo (pull)

Untracked -> Staged (add)
Staged -> Unmodified (commit)
Unmodified -> Modified (Edit file)
Modified -> Staged (add)
Unmodified -> Untracked (remove file)

작성자: 정채은

[이하은] 1주차 인증

💥 혹시 강의 자료에 대한 캡처가 불가능 하다면 댓글 남겨주세요!! 바로 삭제하겠습니다!!

HEAD란?

Git은 매순간의 파일이 아니라 매순간의 변경점을 저장하기 때문에 이 흐름을 연결해서 봐야 한다. 이렇게 매순간의 변경점에 대한 흐름을 연결해서 바라보고 있는 머리를 HEAD 라고 부른다.

깃의 3가지 영역

git init . 이라는 명령어로 Git이 현재 디렉토리를 추적하도록 초기화 하면, .git 이라는 폴더와 함께 3가지 영역이 만들어진다.

• Working Directory: 파일의 변경 사항이 발생하는 곳 (ex. 파일의 추가, 수정, 삭제, 파일의 경로 변경 등)
• Staging Area: add 명령어로 변경 사항 (Snapshot) 을 올려두는 곳
• Local Repository: commit 명령어로 변경 사항을 저장하는 곳 (로컬 저장소)
• Remote Repository (3가지 영역에 포함 X): push 명령어로 변경 사항을 업로드 하는 곳 (원격 저장소)

깃의 4가지 상태

• Untracked: Git이 추적하지 않는 상태 (파일 자체를 처음 생성한 경우)
• Tracked: Git이 추적하는 상태 (파일 변경이 일어나면 Git이 알아채서 우리에게 알려주는 상태)
  • Unmodified: commit으로 변경사항이 저장되었고, 더 이상 변경이 없는 상태
  • Modified: commit한 내용에서 추가적으로 변경이 발생한 상태
  • Staged: add하여 변경사항이 Staging Area에 올라간 상태

• Untracked → add → Staged → commit → Unmodified → Edit file → Modified → add → Staged → commit → Unmodified → ...
• 파일을 삭제했다고 바로 Untracked 상태로 가는 건 아니다. 파일의 삭제 또한 변경사항이므로 Modified 상태가 된다. 이를 add, commit 하면 Unmodified 상태가 되는데, 결과적으로 삭제한 파일은 더 이상 추적하지 못하므로 Untracked 상태라고 볼 수 있다.

자신만의 정리

• 매순간의 변경점이 연결되어 흐르는 거 같다 해서 Stream 형태라고 부른다.
• 매순간의 변경점을 찰칵 찍어둔 것을 Snapshot이라고 부른다.
• 매순간의 변경점에 대한 흐름을 연결해서 바라보고 있는 머리를 HEAD라고 부른다.

작성자: 이하은

[최윤한] 1주차 정리

HEAD란?

• HEAD는 현재 작업 중인 브랜치의 가장 최근 커밋을 가리키는 포인터.
• 현재 체크아웃된 커밋을 가리키는 포인터로서, 가장 최근의 커밋을 나타내며, 작업 디렉토리에서 수정 사항을 추가하거나, 새로운 커밋을 만들 때 기준이 된다.
• 보통 HEAD는 기본적으로 현재 브랜치의 가장 최근 커밋을 가리키지만, 다른 브랜치나 커밋을 체크아웃하면 HEAD가 가리키는 커밋이 변경됨.

깃의 3가지 영역

1. Working Directory : add 되기 전, 작업하고 있는 파일들
2. Staging Area : add 된 상태.
3. Repository : commit 된 상태.

깃의 4가지 상태

1. Untracked

• Working Directory에 있는 상태.

3. Modified

• 직전 커밋과 비교 했을 때 수정 된 상태

4. Unmodified

• 직전 커밋과 비교 했을 때 수정 되어 있지 않은 상태

5. Staged

• add된 상태

자신만의 정리

HEAD^
HEAD~4

**작성자: **
최윤한

[이동섭] 1주차 정리

HEAD란?

Git은 매 순간의 파일이 아닌 매 순간의 변경점을 저장하기 때문에, 하나의 변경점을 보는 것이 아니라 그 흐름을 연결해서 봐야하고, 이 흐름을 연결해서 보는 시점을 HEAD라고 함.

깃의 3가지 영역

👉 init 명령어로 git이 해당 디렉토리를 추적하도록 초기화하면 .git이라는 폴더와 함께 3가지 영역이 만들어짐.

1️⃣ Working Dir
직접 글을 작성할 "종이"에 비유됨. 변경사항이 발생하는 곳임.
2️⃣ Staging Area
과정을 촬영할 "카메라"에 비유됨. add 명령어를 통해 변경사항을 기록 (스냅샷을 기록) 할때 Staging Area에 올라가게 됨.
3️⃣ Local Repo
블로그 올리기전 각 사진을 구분하기 쉽게 이름을 지어주고, 파일을 모아둘 "컴퓨터"에 비유됨. commit 명령어를 통해 변경사항을 저장하는 경우 Local Repo로 올라가게 됨.

깃의 4가지 상태

👉 Untracked 상태
git이 추적하지 않는 상태를 의미. 파일 자체를 아예 처음 생성해준 경우는 git이 변경사항을 추적하지 않음.

👉 Tracked 상태
git이 파일의 변경사항을 추적중인 상태로, 파일 변경이 일어나면 git이 알고 사용자에게 알려주는 상태. 3가지 상태가 존재함.

1️⃣ Unmodified: commit으로 저장되었고, 더이상 변경이 없는 상태.
2️⃣ Modified: commit 한 저장 내용에서 추가적으로 변경이 발생한 상태.
3️⃣ Staged: add 하여 Staging Area에 기록된 상태.

자신만의 정리

👉 Remote Repo
git의 3가지 영역에 포함 X. 실제로 포스팅을 할 "블로그"에 비유됨.
git remote add origin <저장소 주소> 명령어를 통해 Local Repo를 <저장소 주소>와 연결시켜줌.
이후 git push origin <branch 이름> 명령어로 Local Repo의 data를 Remote Repo에 업로드할 수 있음.
이때 origin은 github 내 저장소의 컴퓨터 주소를 지칭하는 이름. origin이라는 이름으로 <저장소 주소> 저장한 것임.

👉 명령어와 깃의 상태 관계
1️⃣ 첫번째 add: Untracked -> Staged
2️⃣ commit: Staged -> Unmodified
3️⃣ 파일 변경: Unmodified -> Modified
4️⃣ add: Modified -> Staged
5️⃣ 파일 삭제: UnModified -> Untracked

작성자: 이동섭

[이하은] 2주차 인증

fast-forward merge (간단한 브랜치 병합)

case 1) A 기능이 만들어지고 B에는 변경사항이 없을 때, B에 A를 합치고 싶은 경우

이렇게 feat/b 브랜치가 참조하는 커밋을 feat/a 브랜치가 참조하는 커밋과 일치시키면 된다. 이처럼 실질적으로 변경사항을 합치는 게 아니라, 그저 참조값만 옮기는 방법을 fast-forward 라고 한다.

3-way-merge (복잡한 브랜치 병합)

case 2) A, B 모두 변경사항이 발생했을 때, A에 B를 합치는 경우

위처럼 서로 다른 브랜치의 커밋 내용을 합치려면 c2, a1, b1 이 3가지를 서로 비교하고 합쳐야 한다. 이를 보고 3-way merge 라고 한다. 여기서 c2는 a1, b1 커밋이 갈라져 나와 그 변경사항을 비교하는 기준이 되기 때문에 base 라고 부른다.

Conflict (변경사항의 충돌)

따라서, git이 두 변경사항 중에 어떤 것을 선택할 것인지 개발자에게 물어본다. 이 상황을 Conflict 라고 한다.

자신만의 정리

main branch

• 첫 commit이 생기면 main 흐름의 멀티버스가 생기고, HEAD는 그 멀티버스에 있게 된다.
• 정확히는 HEAD는 main 브랜치를 참조하고, main 브랜치는 커밋 메시지를 참조한다. (HEAD → main → c1)
• 결과적으로, HEAD는 현재 흐름(main)의 최신 커밋을 바라본다.
• 새로운 커밋이 생기면 브랜치 또한 HEAD와 같이 최신 커밋을 바라본다.

브랜치의 생성

브랜치의 전환

이제 HEAD는 feat 브랜치의 흐름을 바라보게 된다.

이렇게 여러 흐름으로 나누면 동일한 시점에서 여러 명이 동시에 여러 작업을 진행할 수 있다. 이후 나눠진 작업들은 나중에 다시 합쳐야 하는데, 이를 merge 라고 한다.

작성자: 이하은

[배지현] 1주차 정리

HEAD란?

Git은 매 순간의 파일이 아닌 매 순간의 변경점을 저장함
따라서 하나의 변경점을 보는 것이 아니라 그 흐름을 연결해서 보아야 함
이 때 흐름을 연결해서 보는 시점을 HEAD라고 함

깃의 3가지 영역

1. Working Directory
   • 현재 작업 중인 프로젝트가 위치한 Directory
2. Staging Area
   • Commit할 파일의 예비 저장소
3. Local Repo
   • 각 컴퓨터의 git이 관리하는 로컬 저장소

• init 명령어로 git이 해당 Directory를 추적하도록 초기화하면 .git이라는 폴더와 함께 3가지 영역이 만들어짐
• 동작
  • Working Directory에서 변경 사항이 발생
  • add 명령어로 Staging Area에 변경 사항을 기록
  • commit 명령어로 Local Repo에 변경 사항을 저장
  • push 명령어를 통해 Remote Repo에 업로드 (Remote Repo는 git의 3가지 영역에 포함 X)

깃의 4가지 상태

• Untracked 상태
  • git이 추적하지 않는 상태
  • 파일 자체를 아예 처음 생성해준 경우 → git이 변경사항을 추적하지 X
• Tracked 상태
  • git이 파일의 변경사항을 추적 중인 상태
  • 파일 변경이 일어나면 git이 알고 사용자에게 알려주는 상태
  • 3가지 상태로 나뉨
  1. Unmodified
     • commit으로 저장되었고, 더 이상 변경이 없는 상태
  2. Modified
     • commit 한 저장 내용에서 추가적으로 변경이 발생한 상태
  3. Staged
     • add 하여 Staging Area에 기록된 상태

자신만의 정리

• 깃 명령어

1. git init
2. git add <파일 경로 이름>
3. git commit -m "commit 메시지"
4. git remote add origin <저장 주소>
5. git push origin <branch 이름>

작성자: 배지현

[김성은] 2주차 인증

fast-forward merge

• 실질적으로 변경사항을 합치는 과정이 아니라 참조값만 옮기는 것

3-way-merge

• base가 되는 commit에서 생성된 두 흐름 모두 각각의 변경사항이 겹칠 때 두 흐름의 변경사항을 하나의 커밋으로 만들고 이를 참조하게 만드는 것
• 만들어지는 커밋은 base(두 흐름이 생성된 커밋)으로부터 변경사항이 무엇인지를 반영하여 만들어진다

자신만의 정리

• branch는 생성된 위치의 commit을 참조한다
• 새로 만든 흐름에서 작업하기 위해 switch 명령어를 통해 branch를 이동할 수 있다
• 여러 branch에서 작업된 것을 합치는 과정을 merge라고 한다
• merge 과정에서 두 흐름의 변경 사항이 겹칠 경우 두 변경 중 무엇이 이곳의 변경점인지 개발자에게 물어보는 과정을 conflict라고 한다

작성자: 김성은

[장유진] 1주차 정리

HEAD란?

현재의 작업 공간에 대해서 알 수 있는 브랜치의 마지막 커밋ID를 가리키는 참조 포인터

만약 원격 저장소와 연동한다면?
=> 로컬 HEAD 포인터,원격 HEAD 포인터 총 2개가 존재

깃의 3가지 영역

• Working Directory(작업 공간)
• Repository(저장소)
• Staging area(임시 저장 공간)

Working Directory 에서 파일을 생성 혹은 수정하는 작업 이후, git add 명령어를 통해 Staging-Area라는 임시 저장소에 저장합니다.
이후, 커밋을 하게 되면 Reporisitory에 저장하게 됩니다.

깃의 4가지 상태

• Untracked

  깃에서 한번도 add 해주지 않은 추적되고 있지 않은 파일을 의미합니다.

• Staged (Tracked)

  파일이 Staging Area에 올라가 있을때, 스테이지에 올라간 이 파일의 상태를 의미합니다.

• Modified (Tracked)

  최신 커밋과 비교하여 파일이 조금이라도 수정이 되어 있을 때의 상태를 의미합니다.

• Unmodified (Tracked)

  최신 커밋과 비교하여 파일이 수정이 전혀 없을때의 상태를 의미하며, 커밋 직후의 파일은 모두 이 상태가 됩니다.

자신만의 정리

명령어와 결과

✅ Working Directory + git add >> Staging Area
✅ Staging Area + git commit -m >> 로컬 Reporisitory
✅ 로컬 Reporisitory + git push >> 원격 Reporisitory
✅ 원격 Reporisitory + git pull >>로컬 Reporisitory

작성자: 장유진

[김준서] 1주차

HEAD란?

git에서 특정 시점에서 보고있는 머리 -> 그 이전의 파일들을 겹쳐서 봄

깃의 3가지 영역

git에서는 Working(local) Directory, Staging Area, Local Repository가 존재한다.
이 3가지 영역은 git init이라는 명령어를 통해 생겨나고, 기존의 파일들은 Working Directory에 들어가게 된다.
git add 명령어를 통해 Working Dir에서 Staging Area로,
git commit 명령어를 통해 Local Repository로 이동하며,
그 이후 git push 명령어를 통해 github에 존재하는, Remote Repository로 이동하게 된다.

깃의 4가지 상태

�git의 4가지 상태는 먼저 Tracked 상태와 Untracked 상태로 나뉜다.
이름대로 git에 추적되는 상태와 그렇지 않은 상태로 나눌 수 있다.

Untracked 상태는 준비(git init)된 디렉토리 안에서 파일을 처음 생성할 경우이고, git이 변경사항을 추적하지 않는다.
Tracked 상태는 git이 추적하고 있는 상태이며, 이 안에 3가지 상태가 존재한다. 각각 Unmodified, Modified, Staged 이다.
Unmodified는 변경 사항이 존재하지 않는 상태이다. 이전에 이미 commit으로 저장된 상태이다.
Staged는 git add 명령어를 통해 Staging Area에 존재하는 상태이다.
Modified는 기존에 git commit 명령어를 통해 저장된 상태(Unmodified)에서 변경사항이 발생한 상태이다.

자신만의 정리

지금까지 git을 사용하며 Unmodified 상태에서 바로 commit을 한 적이 많습니다.
어떻게 add 없이도 commit을 할 수 있었던 것인지, 이에 대해 알아보고 이슈에 내용을 추가하겠습니다.

**작성자: 김준서

[정동규] 3주차 정리

reset --hard 정리

예시

# 현재 상황 : Commit 3가 잘못되었다.
<<Commit 1>>----<<Commit 2>>----<<Commit 3>> [main]
  ( root )                        ( HEAD )

• 이전 커밋 이후로 작업된 내용이 필요 없는 경우 ( 커밋 자체 롤백 )
  • 강제로 HEAD를 <<Commit 2>> 로 돌리고 <<Commit 3>> 를 사라지게 하여 다시 시작하기
  • git reset --hard commit2
  • 해당 커밋 이후의 모든 작업을 단호하게 날려버림
  • 사실살 저장하지 않은 모든 내용 소실 가능

---

reset --mixed 정리

예시

# 현재 상황 : Commit 3가 잘못되었다.
<<Commit 1>>----<<Commit 2>>----<<Commit 3>> [main]
  ( root )                        ( HEAD )

• 이전 커밋 이후로 작업된 내용은 올바르지만
  단순 "추가하면 안될 파일 혹은 내용이 같이 들어간 경우" / "단순 잘못된 Commit Message 를 작성한 경우"
  ( 내용 유지 & 다시 커밋 )
  • Working Directory 영역에는 보존 내용이 작성되어 있어야 함
  • Commit으로 추가한 snapshot 자체도 수정이 필요하기 때문에
    Staging Area에는 잘못된 Commit에 추가한 내용이 없어야 함
  • git reset --mixed commit2 (—-mixed 생략 가능)
  • Branch 라는 흐름으로 뒤로 가지는 않지만 현재 저장되어 있는 영역을 되돌림
    ( 잘못된 Commit 작성 전으로 돌아온 듯한 모습으로 롤백 )
  • Staging Area 변경 위험
    • 작업 내역이 사라지진 않지만, 저장하기 이전이기에 위험

---

revert 정리하기

과거로 직접 돌아가는 것이 아닌
과거의 작업 내역을 수정하는 방법

• 새로운 변경점으로서 되돌리면서 발생하는 변경점 자체를 새로운 작업 내용으로서 기록하는 방법
• 얼핏 눈에 보이는 작업물은 돌아간 것으로 보이지만
  Git에서는 이전으로 돌아가면서 변경되버린 부분까지 기록을 하는 것

... --<<Commit 2>>----<<Commit 3>> [main] 
                                  ( HEAD )


... --<<Commit 2>>----<<Commit 3>>----<<revert>>  [main]
                                       ( HEAD )
																			Commit 2 시점
                              (Commit 3 - Commit 2 내용도 기록)


     ↱⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻↴
<<Commit 2>>     <<Commit 3>>     <<revert>>
﹢－－－－－－﹢     ﹢－－－－－－﹢     ﹢－－－－－－﹢
ᅵ +정상코드 ᅵ     ᅵ -정상코드 ᅵ     ᅵ  +정상코드 ᅵ
ᅵ         ᅵ     ᅵ +수정코드 ᅵ-----ᅵ->-수정코드 ᅵ                         
ᅵ         ᅵ     ᅵ +추가코드 ᅵ-----ᅵ->-추가코드 ᅵ
﹢－－－－－－﹢     ﹢－－－－－－﹢     ﹢－－－－－－﹢

reset 의 경우, commit history도 남지 않고
직접적으로 Working Directory 및 Staging Area 를 변경하기 때문에
협업에 있어 잦은 충돌을 야기하지만

revert 를 통해
되돌린 history 까지 남겨 세세한 변경 내역과 변경 이유를 남길 수 있어
협업에서 충돌을 최소화 시킬 수 있다.

---

다음 상황에 대한 명령어를 정리해봅시다

(상황1) 팀원이 잘못 reset --hard를 사용하여 작성한 내용을 잃어버렸다고 합니다.

우선 reset을 어떤 Commit에서부터 돌아왔는지 확인하기 위해
git reflog 를 통해 Reset History를 확인합니다.

Reset History에서 본래 HEAD가 있었던 시점의 Commit을 찾아
해당 커밋으로 다시 reset --hard를 통해 돌아갑니다.

• git reset --hard HEAD@{<되돌아온 커밋 수>}
• git reset --hard <되돌아가고자 하는 Commit ID>

이후, Confilt 발생 시, 그저 되돌려서 문제를 회피하기보다는
직접 Conflict를 해결하며 함께 작업을 진행시켜나가는 것이 바람직하다고 생각합니다.

---

자신만의 정리

⁜ 상대 참조

Commit ID(절댓값) 확인하고 복붙하여 쓰기 번거로울 때 도움

1. 캐럿(^)

   ^ 을 사용하여 한 커밋 위로 움직일 수 있다.

   • 적은 단계를 이동할 때 유용

2. 틸트(~)

   ~ 을 사용하여 여러 커밋 위로 움직을 수 있다.

   • ~<이동횟수> → ^^^^^ == ~5
   • 한 번에 여러 커밋을 선택적으로 건너뛸 때 유용

⁜ Reflog : 숨겨진 Reset History까지 조회하는 명령어

Reset 되어 단순 git log 를 통해 확인할 수 없는
되돌려진 시점 이후의 Commit들의 로그를 확일할 수 있다.

> git log --oneline
[commitId] (HEAD -> main) commit 3
[commitId] commit 2 
[commitId] root commit


> git reset --hard HEAD^

> git log --oneline
[commitId] (HEAD -> main) commit 2
[commitId] root commit

> git reflog
[commitId] (HEAD -> main) HEAD@{0} reset : moving to HEAD^
[commitId] HEAD@{1} commit : commit 3
[commitId] (HEAD -> main) HEAD@{2} : commit : commit 2 
[commitId] HEAD@{3} : commit (initial): root commit

⁜ Commit ID 를 Hash 로 사용하는 이유

Git : 분산 VCS → 어떤 상황에서도 Commit을 할 수 있어야 한다.
( 온라인/오프라인, 서버 연결/비연결 등 어떤 상황에서든 Commit을 통해 관리가 될 수 있어야 한다. )

이 때,
만약 Commit ID 값으로 순서적이고 선형적인 값을 쓰게 된다면
Git은 기록을 할 때마다 이전 Commit ID가 무엇이었는지 서버를 통해 확인이 필요하게 된다.

하지만 위에서 언급되었듯
” Git은 어떤 상황에서든 관리가 가능 “해야 하기때문에
최신 번호 확인 필요 없이도 중복 걱정이 없는 상태로 Commit이 가능하도록 Hash 값을 사용하는 것이다.

⁜ Git → SHA-1 암호화 해시 함수 사용 ( 중복 발생 확률 : 1 / 2^80 )

순서 는 어떻게 기억하는가

단순 Hash 값으로 순서를 기억하는 것이 아닌
커밋의 Commit ID 값을 생성할 때, 부모의 Hash 값도 함께 저장한다.

이를 통해 이전 및 이후에 어떤 Commit이 있는지 확인이 가능한 것이다.

⁜ 강제 Push / Pull

• 강제 Push : git push origin <Branch> -f
  • remote의 내용을 local의 내용으로 덮어씌우는 작업
  • local에 없는 remote의 파일은 사라지게 됨.
  • 전체 운영 Branch 들 중 강제 push 한 Branch만 기형적인 구조를 가지게 됨.
    • Merge 시, Reject 발생 가능성 매우 높음
    • 협업상황에선 매우 불리함

• 강제 Pull :

  ⁜ Pull = Fetch & Merge

  1. remote에 있는 모든 내용 받아오기 : git fetch --all
     • remote에서의 origin/main을 불러오게 됨
     • remote에서의 commit 참조 또한 같이 오는 것
       
       
  2. remote 레포의 origin/main 내용으로 local 을 reset : git **reset --hard origin/main**
     • fetch 받을 때 함께온 remote에서의 origin/main 참조를 기반으로
       local을 reset 시키는 것
       
       
  3. 마지막 확인/검수 : git pull origin main

작성자: 정동규(yummygyudon)

[김다예] 1주차 정리

HEAD란?

Git은 해당 시점의 파일 정보를 저장하는 것이 아닌, 변경점을 저장하는데
이 때 Git의 시점마다 보고있는 머리를 HEAD라고 한다.

깃의 3가지 영역

1. Working Dir

   • 실제 작업이 이루어지는 곳이며, Working Dir에서 변경 사항이 발생한다.

2. Staging Area

   • git add 명령어를 통해 Working Dir에서 변경된 사항이 Staging Area에 기록된다.

3. Local Repo

   • git commit 명령어로 Staging Area에 올라와있는 변경된 사항들이 Local Repo에 저장된다.

4. +Remote Repo (깃의 3가지 영역에 포함되진 않음, 깃허브 영역)

   • git push 명령어로 Local Repo에 저장된 커밋들이 github의 Remote Repo에 업로드 된다.

깃의 4가지 상태

• Untracked, Tracked(Unmodified, Modified, Staged)

1. Untracked : 깃이 추적하지 않는 상태
2. Tracked - UnModified : 깃이 추적하고 있는 상태에서 변경 사항이 없는 상태 (git commit으로 저장되고 난 직후 어떠한 변경 사항도 없는 상태)
3. Tracked - Modified : 깃이 추적하고 있는 상태에서 변경 사항이 있는 상태 (git commit으로 저장되고 난 후, 추가적인 변경 사항이 생겼으며 아직 add되지 않은 상태)
4. Tracked - Staged : 깃이 추적하고 있는 상태에서 변경 사항이 Staging Area에 기록된 상태 (git add를 한 상태)

작성자: 김다예

[이소민] 1주차 정리

HEAD란?

깃은 매 순간마다 파일의 내용 대신 변경점을 기록한다.

따라서 결과는 하나의 흐름(stream)으로 봐야 하며, 시점마다 보고 있는 머리를 HEAD 라고 한다.

깃의 3가지 영역

init 명령어로 git이 directory를 추적하도록 초기화 하면 .git이란 폴더와 함께 아래와 같은 3가지 영역이 만들어진다. (아래 사진에서 Remote Repo는 제외)

각 영역에서 벌어지는 일

Working Dir : 직접 글을 작성할 종이

파일을 수정하는 작업 폴더. 변경 사항이 발생하면 git이 이를 알아차릴 수 있다.
수정한 파일을 git add를 통해 snapshot 하여 Staging Area에 기록한다.

Staging Area : 과정을 촬영한 카메라

commit 명령어로 변경사항을 Local Repo에 저장한다.

Local Repo (.git directory) : 블로그 업로드 전 파일을 모아둔 컴퓨터

Staging Area에 있는 파일들을 commit 해서 Git Directory(Repository)에 영구적인 스냅샷으로 저장한다.

Remote Repo : 실제 포스팅을 할 블로그

Remote Repo (in github)

깃의 4가지 상태

기본적인 분류

• Untracked : git이 추적하지 않는 상태를 의미. ex) 파일을 처음 생성해준 경우
• Tracked : git이 파일의 변경 사항을 추적, 변경이 일어나면 이를 사용자에게 알려준다.
  
  Tracked 상태는 다시 아래 세 가지로 나눠진다.
  ㅤ- Unmodified : commit으로 저장되었고 더 이상 변경이 없는 상태
  ㅤ- modified : commit된 내용에서 추가적인 변경이 발생한 상태
  ㅤ- Staged : add하여 Staging Area에 기록된 상태

[ Working Dir ] ― git add ⟶ [ Staging Area ] ― git commit ⟶ [ Local Repo ] ― git push ⟶ [ Remote Repo ]
ㅤㅤ ㅤㅤㅤ⟵ restore staged ― ㅤㅤㅤㅤㅤㅤ⟵ reset mixed ― ㅤㅤㅤㅤㅤㅤ ⟵ git pull ― ㅤㅤㅤㅤㅤㅤㅤ

작성자 : 이소민

[이찬미] 1주차

HEAD란?

특정 브런치의 마지막 커밋에 대한 포인터

모든 브런치에는 HEAD 값이 존재하는데
HEAD는 브런치의 마지막 커밋, 즉 현재 속한 브런치의 최신 커밋을 의미한다.

Git은 시간의 흐름에서 해당 시점의 파일을 저장하지 않고 매 순간의 변경점을 저장하기 때문에
하나의 변경점을 보는 것이 아니라 그 흐름을 연결해서 봐야하고, 이 흐름을 연결해서 보는 시점을 HEAD라고 한다.

깃의 3가지 영역

Working Directory

현재 작업하고 있는 디렉토리

Staging Area

git add 명령어로 전달한 파일들이 존재하는 영역
commit 시 staging area에 있는 파일들만 commit에 반영된다.

Local Repository

working directory의 변경 이력들이 저장되어 있는 영역
commit들이 모여있는 저장소

깃의 4가지 상태

• untracked : git이 추적하지 않는 상태 ex) 새로 생성한 파일
• tracked : git이 파일의 변경사항을 추적하는 상태
  • unmodified : commit으로 저장되었고, 더 이상의 변경이 없는 상태
  • modified : commit한 저장 내용에서 추가적으로 변경이 발생한 상태
  • staged : add하여 Staging area에 기록된 상태

자신만의 정리

새로 생성된 파일은 git add 명령어로 staging area에 기록되고, tracked-staged 상태가 된다.
이후 commit 되면 unmodified 상태가 되고, 해당 파일을 수정하면 modified 상태가 된다.
add(staged) 후 commit하면 다시 unmodified 상태가 된다.

작성자: 이찬미

[정홍준] 1주차 정리

HEAD란?

=> head가 현재 바라보고 있는 커밋을 가리키는건지, 현재 브랜치 이름을 가리키는 건지 헷갈릴 수 있다.
=> 결론은 HEAD는 현재 체크아웃된 브랜치의 가장 최신 커밋을 가리킵니다.
=> 따라서 branch를 변경하게되면, 변경한 branch의 가장 최신 commit을 가리키게 된다. -> 이럴 경우 HEAD는 브랜치 이름을 가리키도록 표시된다.

깃의 3가지 영역

1. Working Directory(작업 공간)
   => 실제로 파일을 생성하고 수정하는 공간
   => 그냥 폴더라고 생각해도 무방하다,

2. Repository(저장소)
   => Git에서 작업한 이력들을 저장하는 '저장소'이다.
   => 깃 저장소에는 일반 폴더와 달리 숨겨진 영역이 있다. 이 숨겨진 영역에는 버전 관리 시스템에 필요한 파일 변경 이력들이 기록된다.
   => 저장소를 생성하려면 초기화 작업이 필요한데 이때의 초기화란 위의 숨겨진 영역을 생성하는 작업이다.

3. Statging area(임시 저장 공간)
   => 새로운 버전을 저장하기 위해 변경된 내용을 다른 곳에 임시로 저장해놓고, 임시 저장소에서 커밋을 하면 저장이 완료된다. 이런 임시 저장소로 보내는 작업을 'git add'라고 한다,
   => 스테이지는 git add한 파일들이 존재하는 영역이고, 커밋을 하게 되면 이 영역에 있는 파일들만 커밋에 반영된다.

깃의 3가지 영역과 깃 명령어

• $ git init 명령어로 git 이 해당 Directory를 추적하도록 초기화하면 .git이라는 폴더와 함께 3가지 영역이 만들어진다.
• Working Dir ⇒ 변경 사항 발생(파일 추가, 파일 삭제, 파일 변경(내용 추가*삭제), 파일 결로 변경 등
• snapshot 기록 ⇒ $ git add file.txt 와 같은 add 명령어를 통해 변경사항을 기록
• 변경 사항 저장 ⇒ $ git commit -m “메시지” 와 같은 commit 명령어로 변경사항을 저장
• 내용 리모트로 업로드(git의 3가지 영역에 포함되지는 않는다.) ⇒ $git push origin main 과 같은 push 명령어로 업로드.

Git의 4가지 상태

• 깃의 상태는 크게 2가지로 나뉜다. → untracked vs tracked(unmodified, modified, staged)

untracked

• git이 추적하지 않는 상태를 의미한다.
• 파일 자체를 아예 처음 생성해준 경우는 git이 변경 사항을 추적하지 않는다.

tracked

• git이 파일의 변경 사항을 추적 중인 상태이다.
• 파일 변경이 일어나면 git이 이를 인식하고 사용자에게 알려준다.
• tracked상태는 Unmodified, Modified, Staged상태로 나눌 수 있다.
• Unmodified 상태는 commit으로 저장되었고, 더 이상 변경이 없는 상태다.
• Modified상태는 commit한 저장 내용에서 추가적으로 변경이 발생한 상태다.
• Staged는 add하여 Staging Area 에 기록된 상태다.

자신만의 정리

3가지 영역에 대한 깃 플로우

• Working dir -(add)-> Staging area -(commit)-> Local repo -(push)-> Remote repo
• Remote repo -(pull)-> Local repo -(reset --mixed)-> Staging area -(resotre --staged)->Working dir
• Local repo -(checkout)-> Working dir

작성자: 정홍준

[이성민] 1주차 정리

HEAD란?

우리는 파일을 한 순간의 모습만 보고 파악하는 반면,
깃은 파일의 변경점을 기록하고 파악한다

그리고 이런 변경사항들을 흐름으로 관리하는데,
이 흐름을 보는 시점을 HEAD 라고 한다!

깃의 3가지 영역

Working Directory - 코드를 직접 작성할 영역

Staging Area - 순간을 카메라로 찍는 것과 같은 영역

Local Repository - 컴퓨터에 저장해 둘 영역 ( .git 디렉토리 )

그 외 Remote Repository 는 GitHub의 영역!

깃의 4가지 상태

Untracked 상태 - git이 추적하지 않는 상태 / 파일 자체를 처음 생성해 준 경우 변경사항을 추적하지 않음

Tracked 상태 - git 이 추적중인 상태 / 파일 변경이 일어나면 git 이 알고 사용자에게 알려주는 상태

• Unmodified 상태 - 더 이상 변경할 게 없는 상태

• Modified 상태 - commit 한 내용에서 변경이 발생한 상태

• Staged 상태 - add 하여 Staging area 에 추가된 상태

자신만의 정리

**작성자: 이성민 **

[이하은] 3주차 인증

reset --hard 정리

Case1) C2 커밋을 작성한 시점으로 되돌리기

c2 이후에 작성한 모든 내용이 잘못되었거나 필요 없는 경우에는, c2라는 커밋을 작성한 시간으로 시간을 되돌리면 된다. 현재 main 이라는 멀티버스의 시간이 c3에 있기 때문에 이를 이전으로 돌려줘야 한다. 또한 그곳에 있는 HEAD도 같이 돌려줘야 한다. 이럴 때 git에서 reset에 hard 옵션을 줘서 이러한 동작을 수행할 수 있다.

reset --mixed 정리

Case2) C3 커밋 작성 바로 전으로 돌아가기

c2 이후에 작성한 내용은 틀리지 않았는데 c3 커밋에서 추가하면 안될 파일이나 내용이 있을 때는, 작성된 내용을 날려서는 안 된다. 이 내용을 유지하면서 c3 이전으로 돌아가려면 어떻게 해야 될까?

이럴 때는 main 브랜치와 HEAD가 과거로 가는 것과 더불어, 커밋을 하기 전 상태여야 한다. 그러면 Working Directory 영역에는 이전에 작성한 내용이 그대로 남아있을 것이다. 그리고 커밋으로 추가한 스냅샷 자체도 수정이 필요하기 때문에, Staging Area에는 c3에서 추가한 내용이 없는 게 좋을 것이다.

이때 깃에서는 reset에 --mixed 옵션을 줘서 이러한 동작을 수행할 수 있다. 브랜치라는 흐름에서는 뒤로 가지 않았지만 현재 저장되어 있는 영역을 되돌리는 것으로 c3 커밋 작성 전으로 돌아온 느낌을 줄 수 있다.

--mixed 옵션은 디폴트여서 생략이 가능하다.

reset의 3가지 옵션

• soft: HEAD와 브랜치만 이동한다. 사실상 Staging Area, Working Dir에 변화가 없기 때문에 과거 여행을 해도 그냥 그 시점을 바라보고 있는 느낌이다.
• mixed: Staging Area 변경의 위험성이 있다. Working Dir에 작업한 내용이 남아있으며, 여기서 수정 작업을 거쳐 Staging Area에 다시 올리게 된다.
• hard: 사실상 저장되지 않은 모든 내용이 날아갈 수 있다. 잘못하는 경우 모든 내용이 싹 날아가므로 조심해야 한다.

커밋 id를 외워야 하나요?

No! 커밋 id 자체를 참조하지 않는, 상대 참조 방법이 있다.

revert

reset의 단점

reset을 사용하면 직접적으로 커밋을 되돌릴 수 있는데, 이미 push를 통해 remote로 올라간 내용을 reset 하고 수정해서 올리려고 하면 reject가 된다. 그 이유는 git은 변경점에 대한 덮어쓰기를 허용하지 않기 때문이다. 이를 해결하기 위해 강제로 덮어쓰도록 하는 명령어가 있긴 하다.

git push origin <branch> -f

하지만, 이 방법은 추천하지 않는다. 덮어씌우면서 생각지 못한 부분이 날아가거나 커밋 로그가 변경되면서 복구가 불가능 할 수 있기 때문이다.

이런 상황에서 사용할 수 있는 명령어가 revert이다.

revert 사용하기

revert를 사용하면 c3에서 만들어진 변경사항을 없애고 c2 상황으로 되돌린 후, 이에 대해 revert 했다는 기록을 남길 수 있다. 쉽게 생각하면, c3에 만든 모든 변경사항을 없애는 새로운 변경사항을 만드는 것이다.

reset을 하면 커밋 히스토리도 남지 않고, 직접 Working Dir, Staging Area를 변경하기 때문에 협업에서 충돌이 발생할 가능성이 커진다. 반면에, revert를 사용하면 되돌린 히스토리를 통해 그 이유를 남길 수 있으며, 협업에서 충돌을 최소화 할 수 있다.

그런데 실제 협업에서는 바로 전 커밋을 revert 하는 경우는 그렇게 많지 않다. 주로, 보다 과거에 수정한 내용이나 merge 한 내용에 대해 풀어낼 때 revert 하고 그 이유를 남기는 경우가 많다.

reflog (reference + log)

git의 HEAD가 참조했던 모든 기록을 보여주는 명령어 (reset, revert 등도 포함)

커밋 id 대신에 HEAD@(1} 과 같은 값으로 상대 참조를 할 수 있다.

강제 push, pull

git push origin main -f 

git fetch --all
git reset --hard origin/main
git pull origin main

강제 pull은 보통 로컬에서 충돌이 발생했을 때, 충돌이 발생하기 전 리모트 상태도 되돌리기 위해 사용하는 경우가 많다. 하지만, 이런 식으로 강제 pull을 받기 보다는 파일의 변경 사항을 확인하며 직접 충돌을 해결하는 것이 더 좋다.

다음 상황에 대한 명령어를 정리해봅시다

(상황1) 팀원이 잘못 reset --hard를 사용하여 작성한 내용을 잃어버렸다고 합니다.

git reflog 명령어를 통해 HEAD의 참조가 어떻게 바뀌었는지 확인하고, reset --hard 명령어를 실행하기 전 커밋 상태로 되돌릴 거 같습니다. 이 링크에서 좀 더 구체적인 설명을 읽었습니다!

자신만의 정리

• git reset: 특정 커밋을 작성했던 시점 (--hard) 또는 특정 커밋을 작성하기 바로 전으로 (--mixed) 되돌아가고 싶을 때 사용한다. (soft, mixed, hard 옵션에 따라 Working Dir, Staging Area의 상태가 달라진다.)
• git revert: 특정 커밋의 모든 변경사항을 없애는 새로운 변경사항을 만든다. reset과 달리, 되돌린 히스토리를 작성하여 그 이유를 남길 수 있으며, 이를 통해 협업 시 충돌을 최소화 할 수 있다.
• 그런데 실제 협업에서는 바로 전 커밋을 revert 하는 경우가 그리 많지 않다. 주로, 보다 과거에 수정한 내용이나 merge 한 내용에 대해 풀어낼 때 revert 하고 그 이유를 남기는 경우가 많다.

작성자: 이하은

[이재훈] 1주차정리

HEAD란?

깃은 매순간 파일이 아닌 변경점을 저장하는데 그 변경점을 보고있는 시점

깃의 3가지 영역

깃의 3가지 영역으로는 Working Directory, Staging Area, Local Repo가 있습니다.
Working Directory : 변경 사항 발생
Staging Area : git add 명령어를 통해 변경사항을 기록한 영역
Local Repo - commit 명령어로 변경사항 저장하는 영역

깃의 4가지 상태

Untracked - git이 추적하지 않는 상태
Tracked - git파일의 변경사항을 추적중인상태
(파일변경이 일어나면 git이 알고 사용자에게 알려주는 상태)

• Unmodified - commit으로 저장되었고 더이상 변경할 것이 없는 상태
• Modified - commit한 내용에서 추가적으로 변경이 발생한 상태
• Staged - add해서 Staging Area에 기록된 상태

자신만의 정리

Head란? 현재 체크아웃된 브랜치의 가장 최신 커밋을 가리킨다.

Head에 대해
Head로 내가 어떤 공간에서 작업하는지 알 수 있다.
브랜치를 이동하면 Head도 이동하며 브랜치가 여러개면 Head도 여러개다.
원격저장소와 연동하여 깃을 관리하면 로컬Head와 원격Head, 브랜치마다 두개의 Head가 존재한다.

**작성자: 이재훈 **

[이재훈] 2주차정리

fast-forward merge

실질적인 변경사항을 합치는 것이 아닌 참조값만 옮겨서 merge하는 것

3-way-merge

base커밋과 함께 두 가지의 브랜치를 비교하여 merge하는 것

자신만의 정리

fast-forward merge

서로 다른 상태를 병합하는 것이 아니고 main브랜치를 a브랜치 위치로 이동만해도 되는 상태이기 때문에 merge를 위한 커밋이 발생하지 않는다. main을 a브랜치와 동일한 커밋을 가리키도록 이동시키는 것 (main에서 커밋이 발생하기 전에 발생하는 merge방식)

3way-merge

git이 merge할 때 각 브랜치의 마지막 커밋 두개와 브랜치의 공통 조상 커밋(base커밋) 총 3개의 커밋을 비교하여 새로운 커밋을 만들어 병합 수행한다.

**작성자: 이재훈 **

[정채은] 3주차 정리

reset --hard 정리

특정 과거 커밋을 작성한 시간으로 시간을 돌림, HEAD도 함께 돌아감

reset --mixed 정리

커밋을 작성하기 직전으로 돌아감, 변경 사항을 유지해줌
reset의 기본 옵션, default값

revert 정리하기

reset과는 다르게 과거 내용만을 수정
되돌린 이유를 남길 수 있음

다음 상황에 대한 명령어를 정리해봅시다

(상황1) 팀원이 잘못 reset --hard를 사용하여 작성한 내용을 잃어버렸다고 합니다.

git reflog를 이용해서 지워진, 돌아가고자 하는 커밋을 확인하고 reset 을 통해서 다시 복구시킨다.

자신만의 정리

reset
soft, mixed, hard 모두 HEAD는 지정한 commit으로 이동함
staging area는 mixed와 hard에만 지정 commit과 동일한 상태가 되고 (잘못하는 경우 hard에서는 내용이 날아감), working dir은 hard에서만 지정 commit과 동일하게 됨
soft는 branch를 이동시킬 때, mixed는 내용을 유지하고 다시 커밋할 때, hard는 commit 자체를 되돌릴 때 사용함

상대 참조 캐럿 : ^ (바로 위)
상대 참조 틸트 : ~ (여러 커밋 위로 올라감)

reflog
reflog = reference + log
HEAD가 참조했던 모든 기록을 볼 수 있음

작성자:정채은