conflict 관리 참고 영상

 

https://www.youtube.com/watch?v=wVUnsTsRQ3g 

 

 

git pull = fetch 와 merge를 한번에 해준다.

 

같은 이름의 branch여도 원격 저장소와 지역 저장소를 다른 브랜치로 취급한다.

 

merge fast forward 현상

https://otzslayer.github.io/git/2021/12/05/git-merge-fast-forward.html

 

Git Merge에서 Fast Forward 관계 이해하기 - Jay's Blog

Git Merge에서 항상 헷갈리는 Fast Forward 관계에 대해 정리해보았습니다. 🙌 들어가며 Git을 사용하다보면 브랜치를 분기하여 다시 병합하는 일이 빈번하게 일어납니다. 최근 Git 커밋 히스토리 관리

otzslayer.github.io

 

fast forward인 경우

병한된 branch의 head가 따라간다.

fast forward인 경우

병한된 branch의 head가 따라간다.

git merge --no-ff “branch name”을 사용해서 fast forward를 사용 안 할 수있다.

 

참고사이트

https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html

 

[GitHub] Git 브랜치의 종류 및 사용법 (5가지) - Heee's Development Blog

Step by step goes a long way.

gmlwjd9405.github.io

https://gmlwjd9405.github.io/2018/05/12/how-to-collaborate-on-GitHub-3.html

 

[GitHub] GitHub로 협업하는 방법[3] - Gitflow Workflow - Heee's Development Blog

Step by step goes a long way.

gmlwjd9405.github.io

https://koreabigname.tistory.com/65

 

git-merge에서 --ff, --no-ff의 차이점

버전컨트롤관리 프로그램인 git을 사용하게 되면 git-merge에서 옵션의 차이를 명확하게 이해하야할 필요가 있어 정리하여봅니다. fast-forward 옵션중에 ff는 fast-forward의 약자입니다. 두개의 커밋A와

koreabigname.tistory.com

https://minemanemo.tistory.com/46

 

[GIT] 병합(merge) 종류 별 완벽 설명

조금 더 케이스를 상세하게 다시 포스팅 해보았습니다 https://minemanemo.tistory.com/157 [Git] merge와 rebase - (1) 주요 개념 및 예시 목차 목차 🤓 개요 🥶 중요 개념: Fast-Forward 관계란? 🥸 merge와 reb..

minemanemo.tistory.com

https://velog.io/@shin6403/Git-git-커밋-컨벤션-설정하기

 

Git | git 커밋 컨벤션 설정하기

개발자로 시작한지 얼마 안되고 나서, 첫 직장은 지금도 다니고 있는 모든것을 처음부터 새로 시작하는 스타트업이다.프론트엔드는 작성자 혼자 뿐이었고, 아무것도 모르는 주니어 개발자가 하

velog.io

 

Tracked File이란?

    • Unmodified/Modifed/Stage일 경우: 이 파일이 Git에 의해 관리가 되고 있다.
    • Untracked일 경우: 이 파일은 Git에 의해 관리가 안되고 있다. (= 방금 추가한 파일이거나 쓸모없는 파일임을 추측 가능)
    • Modified일 경우: 이 파일은 변경되었다. 변경되었다고 기록을 해야 한다.
    • Unmodified일 경우: 이 파일은 저번에 저장한 파일과 비교해보니 그대로이다.Git이 관리해주는 파일(Tracked File)은 다시 한번 더 파일의 상태를 3개의 상태로 세분화해서 관리합니다.
      1. Unmodified: 파일이 수정되지 않은 상태 (= 파일이 최근에 저장한 상태 그대로임)
      2. Modified: 파일이 수정된 상태 (= 파일이 최근에 저장한 파일과 달라짐)
      3. Staged: 파일을 저장할 예정인 상태 (= 이 파일을 저장할 것이라는 뜻)
      이러한 세분화된 상태들을 보고 우리들은 다음과 같은 정보를 알 수 있습니다.

Untracked File이란?

Untracked File은 이 파일이 Git 저장소에는 있지만 Git에 의해서 관리되고 있지 않은 파일입니다. Unmodified/Modifed/Stage이 세 가지 외의 상태는 모두 Untracked입니다. Untracked File은 삭제되든 변형이 일어나든 Git이 추적하고 있지 않기 때문에 손상되었을 때 Git으로 복구할 수 없습니다.

Git이 파일을 분류하는 방법에 대해서 알아봤습니다. 우리가 Git으로 관리되는 폴더에 넣어준 모든 파일은 이렇게 관리가 됩니다. 이제 이러한 Git이 분류해주는 파일의 상태를 확인하는 명령어를 배워봅시다.

add를 통해서 untracked 상태에서 벗어날 수 있다.


git commit -a -m “commit_name”

 

-a 는 auto adding이다. 하나하나 파일들을 add 하기 귀찮을 때 사용

이렇게 할 때 untracked된 파일은 commit 되지 않는다.

한번이라도 add를 한 tracked 된 파일에 대해서만 auto adding이 된다.

= git commit -am “commit_name”

 

add의 의미

  1. commit 대기 상태를 만든다.
  2. untracked를 tracked로 만든다

.gitignore

password나 오픈하면 안되는 정보들을 이 파일에 목록들을 저장해둔다.

여기에 들어가있는 곳은 기록된 파일들은 없는셈친다.

 

checkout은 head를 옮기고, reset은 head가 가리키는 branch를 옮긴다.

  • git reset —hard이전에 했던 commit으로 checkout하는 것과의 차이점은?취소를 한다고 하더라도 git은 삭제하지 않기 때문에 git reflog를 사용해서 삭제된 과거의 commit의 id로 갈 수 도 있다.

if(attached){

HEAD의 Branch가 움직임

} else {

== checkout

}

  • HEAD의 Branch가 움직임
  • git reset --hard COMMIT_ID로 Branch를 이동
  • check out은 시간여행이지 최근 작업물의 커밋을 지우지는 못한다.
  • 이 명령어를 사용해서 뒤의 주소로 이동하면서 commit을 취소할 수 있다.

branch를 만드는 것이 버리기 쉽기 때문에 branch 를 만드는게 유리하다.

 

git log —oneline -all -graph

⇒ git graph 없이도 git bash 창에서 그래프로 표현해줌

 

연습

  1. 프로젝트 폴더를 만든다.
  2. git init 으로 저장소 생성
  3. 파일을 만들고 2개의 commit을 만든다. (git add “file name”, git commit -m “commit message”)
  4. 시간여행을 해보세요.(git checkout “commit id”, git checkout master)
  5. branch 생성 (git branch exp, git checkout exp) ⇒ (git checkout -b exp)

→ 헤드가 master와 exp를 둘다 가르키고 있다. 즉, 헤드가 exp를 가르키도록 해주어야 한다.

  1. 다음의 과정을 각각의 브랜치에서 진행한다.

→ exp 브랜치: exp.txt 파일 생성, master branch: master.txt 커밋

(git add exp.txt, git commit -m “exp1”) , (git add master.txt, git commit -m “master 1”)

  1. 병합한다.
  2. (head → master) git merge exp → vi editor뜨면 ((esc) → :wq)

 

버전 관리의 필요성

  • 프로젝트를 진행하다 보면 버그가 발생한다.
    • 버그의 종류
        1. 행복한 버그 = 문법 에러 Why? 해결하지 않으면 프로그램이 돌아가지 않아서
        1. 개 같은 버그 = 기획자의 의도와 다르게 진행 됨. 등등
      • → 버그가 발생하지 않은 버전을 찾기 위해서 버전 관리가 중요하다.

.git 파일

  • 숨겨져있음.
  • 레파지토리, 저장소
  • git init 으로 생성
  • git config —global user.name “이름쓰기”

 

터미널을 git bash를 사용

 

working dir

우리가 사용하고 있는 프로젝트 파일 모든 것

stage area

우리가 commit하기 전에 대기하고 있는 대기소, 장바구니.

git은 working directory를 고려하지 않는다. commit을 하기 전에 stage에 올라간 것만 확인하고 commit한다.

master는 마지막 작업을 가르킨다.

head는 현재 작업을 가르킨다.

(head→master 가 아닐 경우)새 버전의 부모는 Head다.

detached head state라고 한다.

(head→master 일 경우) master 와 head는 새로운 버전을 가르킨다.

마지막 커밋으로 직접 head를 움직여줬다면 마스터는 헤드를 따라오지 않기 때문에 오류가 생길 수 있기 때문이다. 따라서 마지막 거로 갈거면 git checkout master를 써서 마스터로 head를 마스터를 가르키도록 만들어 줘라

 

깃은 어떠한 버전도 지우지 않고 수정하지 않는다. = 불변성 = 안정성

이전 작업으로 가고 싶다면

git chechkout “이전 작업의 주소”

 

실험이 끝났다면 master가 exp branch를 병합한다.

마스터에서 exp를 병합하기 위해서는 우선 head → master인 상태가 되어야 한다.

 

그 후 Merge 합니다.

Merge한 버전의 parent는 master1, exp1 이다. 즉, master와 병합한 branch이다.

master에 merge한 결과를 과거로 돌리고 싶다면 reset을 하면 된다.

exp가 master를 병합한다. => master를 업데이트 한다. 실험이 끝났다면, master가 exp(branch)를 병합한다. -> 'merge' into current branch 새로운 version의 부모는 master, exp(branch)이며 master는 새로 만들어진 version을 가리킨다. 병합을 취소하려면 'reset' current branch

git 명령어

git config user.name = user name 확인

git config user.email = email 확인

git init

git status = 제일 많이 사용하게 될 명령어

git add “파일 이름” = 명령어를 사용해서 스테이지에 올릴 수 있다.

git commit -m “커밋 이름” = 커밋한다.

git log = git commit log를 확인할 수 있다.

git log --oneline = 한줄로만 나오게 하는 log

git log --oneline --all = 전체 commit을 출력

git checkout ‘커밋 주소’ = 커밋 주소의 상태로 working directory를 이동시킨다.

git checkout master

git reflog = 모든 행동에 대한 정보가 담긴 로그 why? 깃을 어떠한 버전도 지우지 않고 수정하지 않는다.

git branch “branch_name” = 브랜치 생성

git merge “target branch”

git reset

+ Recent posts