Git

깃 관리하는데 있어 필요한 내용

  1. Markdown : https://github.com/runabird36/GitControl/blob/master/docs/01_markdown_grammar.md
  2. Linux 명령어 : https://github.com/runabird36/GitControl/blob/master/docs/02_linux_command.md
  3. Git 명령어 : https://github.com/runabird36/GitControl/blob/master/docs/03_git_command.md
  4. Git 내부 규약 : https://github.com/runabird36/GitControl/blob/master/docs/04_git_%EA%B4%B8%EB%A6%AC%EA%B7%9C%EC%95%BD.md




Git Basics - Recording Changes to the Repository

  • Remember that each file in your working directory can be in one of two states: tracked or untracked
    • Tracked files are files that were in the last snapshot, as well as any newly staged files; they can be unmodified, modified, or staged. In short, tracked files are files that Git knows about.
    • Untracked files are everything else — any files in your working directory that were not in your last snapshot and are not in your staging area.


git 명령어 사용방법 / github 연동

[ user name / email 내용 저장 ]

  git config --global user.name "my name"
  git config --global user.email email


[ commit 메세지 템플릿 저장 ]


[ git 저장공간 세가지 + 알파 구분 ]

  • 실제공간 / stage 가상공간 / git directory / remote 공간 (github)


[ git directory 로그 확인 방법 ]

  • git log 확인
    git log
    
  • git log를 그래프와 함께 확인
    git log --decorate --graph
    
  • git log를 한줄로 요약해서 확인
    git log --decorate --all --oneline
    


[ local / git의 현재 상태 확인 ]

  git status


[ Staging ]

  git add -A (지양)
  git add 파일명


[ UnStaging ]

  • Stage area –> Working Directory

    git restore --staged (file name)
    
  • cf ) reset은 repository –> Stage area 이다!!

    git reset HEAD [file]  ## Stage area로 이동
    

[ Filter Staging ]

  • .gitignore 파일 안에 지정된 포멧 / 파일 / 폴더 를 제외하고 staging하도록 필터링


[ git commit ]

  • git directory에 실제 저장
  • 이때서부터 실제 로그로 남음
    git commit : 만일 .gitmessage.txt 가 지정되어있으면 vim 메모장으로 전환
    git commit -m "메세지"
    

[ git directory 컨트롤 ]

  • 가정 : main 브랜치와 pib-1111 브랜치 두가지가 있는 상태에서, 현재 추가한 파일들을 pib브랜치에 올려야하는데 main을 이미 commit 되었다고 가정해보자. 이때, 어떻게 commit 한 내용을 되돌려서 pib-1111 브랜치로 commit 해야할까 ?

  • revert : 해당 로그보다 앞선 로그들을 강제로 강하게 삭제하고 원하는 로그로 이동. 아예 삭제를 하다보니, commit 했던 내용을 다 삭제해버려서, commit 했던 파일들이 사라져버림

    git reset log_code(6-digits)(돌아갈 과거 로그) --hard
    
  • 이때의 log_code는 꼭 가장 위에있는 log_code 이지 않아도 됨
  • 나름대로의 정리가 끝나면 reset으로 최종 정리해도 됨
```
git revert log_code(6-digits)(취소할 시점)
```
  • reset : 마지막 commit 을 취소하는것으로 commit 기록이 변경되기때문에 거의 사용하면 안됨.
    git reset --soft HEAD~1
    


[ Branch 컨트롤 ]

  • branch는 생성 이후에, add해서 staging해준 뒤, commit을 통해 실제 git directory에 저장을 해줘야지 하나의 로그로 남는다.

  • 브랜치 생성 (브랜치를 생성하는 시점을 기준으로, 가장 최신의 로그를 복사해서 새로운 브랜치로 생성)

    git branch branch_name
    
  • 해당 이름의 브랜치로 이동

    git switch branch_name
    
  • 다 쓴 브랜치 삭제

    git branch -D branch_name
    
  • branch list up
    git branch -l ## local에 있는 branch list up
    git branch -r ## remote 경로의 branch list up
    git branch -a ## local + remote의 branch list up
    
  • 현재 사용중인 branch 확인
    git branch -v
    
  • 특정 branch 가져오기
    git pull ## 현재 사용중인 branch를 가져오기
    git pull origin <branch name> ## 특정 branch 가져오기
    


[ Merge / Conflict / Rebase(재배치) ]

  • 전제 1 : merge 할것을 : B (from)
  • 전제 2 : merge 할것을 가져와서 합쳐질 공간을 : A (to)
  • 라고 할때,

  • A로 이동 후, B merge

  • 이렇게 하면 (윈도우의 경우, vi 화면이 나옴 -> :wq)

    git checkout A
    git merge B
    
  • conflict!

  • 애초에 branch 의미단위를 잘 나누어서 같은 파일을 서로 다른 branch에서 수정하지 않도록 해야됨

  • conflict 발생시!

    - git merge B 했을때,
    - conflict 된 부분을 보여줌
    - A, B 둘중 한군데를 수정 후, commit
      - git commit 만 해주기
    
  • Rebase

  • merge와 같이 지정한 브랜치를 하나로 합쳐줌
  • 단, 하나 다른점은 git log –decorate –graph를 깔금하게 한줄로 만들어줌
  • 팀 별 정책에 따라서 의논후 입력

    git rebase B
    


[ squash or message 정리 - rebase ]

  1. 변경된 모든 로그 확인 (숨어있는 ID 찾기)
  2. rebase 하기전 backup 용 branch 만들기
  3. interactive rebase 실행 : rebase -i HEAD~갯수 진행 (git log –graph 에 있는 commit 기준 / not with git reflog)
  4. squash등 edit진행
    • edit_win
  5. 다른 사람의 commit이 중간중간에 섞여있어서, 나의 commit들만 담아내고 싶을때 - drop
    • branch 생성해서 작업 하고있지만, 중간중간에 git pull origin main해서 최신버전으로 업데이트를하게되면 다른 사람들의 commit이 rebase 할 대상으로 지정됨. 이때, 그 다른 사람들의 commit들을 drop 또는 d 표시를 해주면 제외시킬 수 있음
    • drop_win
  6. squash되는 commit들을 중에서 어떤 메세지를 쓸것인지 선택 또는 수정 :wq!
    • edit_msg
  7. 강제로 원격 저장소에 push
  git reflog

  git branch backup-before-rebase <ID> # create new branch that hold ID commit

  git rebase -i HEAD~3

  git push -f origin main


[ rebase 한 내용 취소 ]

  • rebase 도중에 중단
  • rebase 완료된 후 되돌리기
    1. 변경된 모든 로그 확인 (숨어있는 ID 찾기)
    2. rebase 하기전 backup 용 branch 만들기
    3. 되돌아가고 싶은 commit의 이전 내용들 삭제
    git rebase --abort 
    
    or
    
    git reflog # 변경된 모든 로그 확인 가능
    git branch backup-before-rebase <ID> # create new branch that hold ID commit
    git reset --hard <ID> # move to ID commit and then remove all commits which are created after the ID commit
    


[ remote 명령어 관련! / Fetch / Push / Pull ]

  • 원격 저장소 경로를 변경할 때,
    -> git remote -v : 현재 원격저장소를 칭하고 있는 이름(remote_name) 확인 : origin
    -> git remote remove remote_name : remote_name과 연결된 remote 경로 삭제
    -> git remote add remote_name 깃주소 : 새롭게 지정할 remote 주소를 연결
    ex) git remote add origin 깃주소
    
  • push 하기전에 현재 local git directory가 최신인지 확인 방법
  • fetch와 pull의 차이 : 둘다 remote로 부터 가져오는것 이지만, 로컬 실제 데이터에 merge를 하냐 안하냐의 차이 (pull 은 merge / fetch는 merge X)
    -> git fetch origin : origin 이라는 원격 저장소를 가져오되 merge는 하지 않겠다.
    -> git log --decorate --all --oneline : 어떠한 내용이 달라졌는지를, log들을 한줄로 정리해서 확인하겠다
    -> git diff HEAD origin/master : 어떠한 내용이 달라졌는지, 실제 내용을 뜯어보겠다.
    
  • origin 이라는 remote repository(github)으로 master이라는 브랜치를 올리겠다.
    git push origin master
    
  • origin 이라는 remote repository(github)으로 master이라는 브랜치를 받아오겠다.
    git pull origin master
    


[ github 연동 ]

  1. github에 repository 생성

  2. 현재 로컬 git directory에 모든 내용이 commit되어있는지 확인
      git status
    
  3. 현재 지정된 원격 repository가 있는지 확인 후, 없을 시 지정
      ## 현재 지정되어있는 원격 저장소 확인
      git remote -v
      ## origin 이라는 이름으로 원격 저장소 지정
      git remote add origin github원격저장소주소
    
  4. origin 이라는 이름으로 지정된 원격 저장소에, master이라는 branch를 올리겠다 (현재 main branch가 무엇인지 확인 필요. master 이라는 이름이 아닐수도 있음)
      ## 현재 있는 branch 들 확인
      git branch
      ## git push origin master
    
  5. git pull origin master


[authentification 안내 메세지 이슈]

  • 계정입력
  • token 만든뒤 token 코드를 비밀번호로 입력
  • 매번 패스워드 입력안하는 방법 : git config credential.helper store
  • 참고자료


[default branch 변경]

  • 원격 저장소 : [repository]-[Settings]-[general] 항목에서 변경
  • 로컬 저장소 : git config –global init.defaultBranch 브랜치이름
  • 참고자료


[.gitignore 가 반영되지 않을때]

  1. 아래의 명령어로 캐쉬 삭제 후, 다시 commit
    git rm -r --cached .
    git add .
    git commit -m "fixed untracked files"
    


[ Authentication 에러 발생할때 ]

  • 토큰 발급해서 비밀번호란에 입력
  • ID는 깃 ID 그대로 사용


[ Git ID/PW(Access-token) 매번 입력에서 벗어나기 ]

  • 참고자료
    1. Credential 어보를 반영구 저장하는 방식
      git config --unset credential.helper 
      git config credential.helper store
      
    2. Credential 정보를 특정 시간동한 git caceh에 임시로 저장하는 방식
      git config --unset credential.helper 
      git config credential.helper cache
      git config credential.helper 'cache --timeout 7200'
      

[Git fetch 란 - 원격 저장소 정보를 로컬로 가져올때]

  • git fetch는 Git에서 원격 저장소의 변경 사항을 로컬 저장소로 가져오는 명령어입니다. 이 명령어를 사용하면 원격 저장소의 최신 커밋, 브랜치, 태그 등의 정보를 로컬에 업데이트하지만, 실제로 로컬 브랜치에 병합하거나 작업 디렉토리에 변경을 적용하지는 않습니다.

  • 주요 기능 및 특징

    • 원격 추적 브랜치 업데이트: 원격 저장소의 변경 사항을 로컬의 원격 추적 브랜치(origin/main, origin/develop 등)에 반영합니다.
    • 작업 디렉토리 영향 없음: 현재 작업 중인 파일이나 브랜치에는 직접적인 영향을 주지 않으므로 안전하게 실행할 수 있습니다.
    • 병합 또는 리베이스 필요: 가져온 변경 사항을 로컬 브랜치에 적용하려면 추가로 git merge 또는 git rebase 명령어를 사용해야 합니다.
  • 사용 방법

    1. 원격 저장소의 모든 변경 사항 가져오기

      git fetch
      
    2. 특정 원격 저장소의 변경 사항 가져오기

      git fetch <원격저장소이름>
      # 예시: git fetch origin
      
    3. 특정 브랜치만 가져오기

      git fetch origin <브랜치이름>
      # 예시: git fetch origin feature/login
      
    4. 모든 원격 저장소의 변경 사항 가져오기

      git fetch --all
      
  • 추가 옵션

  • 원격에서 삭제된 브랜치나 태그를 로컬에서 제거하기

    git fetch --prune
    
  • 태그만 가져오기

    git fetch --tags
    
  • 사용 예시

    • 예시 1: 동료가 원격 저장소에 새로운 브랜치를 추가한 경우
      git fetch
      
      • 이 명령어를 실행하면 새로운 브랜치 정보가 로컬에 업데이트됩니다.
      • 이후 해당 브랜치를 체크아웃하여 작업할 수 있습니다.

        git checkout feature/new-feature
        
    • 예시 2: 원격 브랜치가 삭제되었을 때 로컬에서 반영하기
      git fetch --prune
      
      • 원격 저장소에서 삭제된 브랜치에 대한 로컬의 원격 추적 브랜치가 제거됩니다.
  • git fetchgit pull의 차이점

    • git fetch

      • 원격 저장소의 변경 사항을 로컬로 가져오지만 자동으로 병합하지 않습니다.
      • 가져온 변경 사항을 확인하고 선택적으로 병합할 수 있습니다.
    • git pull

      • git fetchgit merge를 한 번에 수행합니다.
      • 원격 변경 사항을 가져오고 현재 체크아웃된 브랜치에 바로 병합합니다.
  • 병합 방법

    • 가져온 변경 사항을 로컬 브랜치에 병합하려면 다음과 같이 실행합니다.
    1. 병합하기

      git merge origin/<브랜치이름>
      # 예시: git merge origin/main
      
    2. 리베이스하기

      git rebase origin/<브랜치이름>
      # 예시: git rebase origin/main
      
  • 요약

    • git fetch는 원격 저장소의 최신 상태를 로컬에 업데이트하여 이후 작업에 필요한 정보를 가져옵니다.
    • 로컬 작업에 영향을 주지 않으므로 안전하게 사용할 수 있는 명령어입니다.
    • 가져온 변경 사항을 적용하려면 추가적인 병합 작업이 필요합니다.
  • 추가 참고사항

    • 정기적인 업데이트: 팀 프로젝트에서 다른 사람들이 푸시한 내용을 자주 가져와서 충돌을 최소화하는 것이 좋습니다.
    • 원격 저장소 이름: 기본적으로 origin이지만, 여러 원격 저장소를 사용하는 경우 해당 이름을 지정해야 합니다.
    • 브랜치 동기화: 로컬 브랜치와 원격 브랜치를 동기화하여 일관된 작업 환경을 유지할 수 있습니다.
  • 예시 명령어 실행 흐름

    1. 원격 저장소의 변경 사항 가져오기

      git fetch
      
    2. 변경 사항 확인하기

      git log HEAD..origin/<브랜치이름>
      # 예시: git log HEAD..origin/main
      
    3. 변경 사항 병합하기

      git merge origin/<브랜치이름>
      

results matching ""

    No results matching ""