[오픈소스설계][git]

밥슌·2024년 9월 25일

🐈‍⬛github

목록 보기
9/12

파일 변경 내용 보기

 git diff

– 워킹 디렉터리에 있는 것(unstaged 상태)과 staging area에 있는 것을 비교
– 커밋을 수행한 경우에는 마지막 커밋한 것과 워킹 디렉터리에 있는것을 비교
– 수정한 파일을 모두 staging area에 넣은 경우 출력 내용은 없음

ex)
여기서는 git diff 명령어에서 출력된 변경된 부분과 헝크 헤더를 기준으로, 파일이 어떻게 변화했는지 설명드리겠습니다.

실제 차이 내용 설명:

@@ -3,3 +3,4 @@

이 헝크 헤더는 원본 파일의 3번 줄부터 3줄이 있었고, 변경된 파일에서는 3번 줄부터 4줄이 있다는 것을 의미합니다. 이제 원본 파일과 변경된 파일의 각 줄을 하나씩 살펴보겠습니다.

원본 파일 (diff --git a/difffile b/difffile 이전 상태):

iksuplorer        (1번 줄, 변경 없음)
iksuplorerssu     (2번 줄, 변경 없음)
ikr               (3번 줄)
ikr               (4번 줄)
ikr               (5번 줄)
  • 1번 줄: iksuplorer (변경 없음)
  • 2번 줄: iksuplorerssu (변경 없음)
  • 3번 줄: ikr (변경 없음)
  • 4번 줄: ikr (변경 없음)
  • 5번 줄: ikr (변경 없음)

변경된 파일 (diff --git a/difffile b/difffile 이후 상태):

iksuplorer        (1번 줄, 변경 없음)
iksuplorerssu     (2번 줄, 변경 없음)
ikr               (3번 줄, 변경 없음)
ikr               (4번 줄, 변경 없음)
ikr               (5번 줄, 변경 없음)
ik                (6번 줄에 새롭게 추가된 줄)
  • 1번 줄: iksuplorer (변경 없음)
  • 2번 줄: iksuplorerssu (변경 없음)
  • 3번 줄: ikr (변경 없음)
  • 4번 줄: ikr (변경 없음)
  • 5번 줄: ikr (변경 없음)
  • 6번 줄: ik (새로 추가된 줄)

구체적인 설명:

  • 원본 파일: 1번 줄부터 5번 줄까지 내용이 있었으며, 3번 줄부터 5번 줄까지는 ikr이라는 내용이 반복됩니다.
  • 변경된 파일: 기존 1번 줄부터 5번 줄까지는 변경되지 않았고, 6번 줄에 ik라는 새로운 줄이 추가되었습니다.

헝크 헤더의 의미 (@@ -3,3 +3,4 @@):

  1. -3,3: 원본 파일에서 3번 줄부터 시작해 3줄이 있었다는 뜻입니다.
    • 즉, 원본 파일에는 3번 줄, 4번 줄, 5번 줄에 ikr이 존재했음을 나타냅니다.
  2. +3,4: 변경된 파일에서는 3번 줄부터 시작해 4줄이 있다는 뜻입니다.
    • 즉, 3번 줄부터 5번 줄까지는 그대로 유지되고, 6번 줄에 ik가 새롭게 추가되었음을 의미합니다.

요약:

  • 원본 파일:

    iksuplorer
iksuplorerssu
ikr
ikr
ikr

  • 변경된 파일:

    iksuplorer
iksuplorerssu
ikr
ikr
ikr
ik   (새로 추가된 줄)

결과적으로, 변경된 내용은 6번째 줄에 ik라는 새로운 줄이 추가된 것입니다. 헝크 헤더는 이 변경이 3번 줄부터 시작되어 6번 줄까지 이어진다는 것을 설명하고 있습니다.

변경사항 커밋하기

git commit –a –m “커밋 제목”

: git add 추가 기능
– -a 옵션은 tracked 파일에만 사용 가능

파일 삭제

git rm {파일명}

– 위 명령 후 commit을 수행해야 함
– Git으로부터 더 이상 추적되지 않음
– 워킹 디렉터리에 있는 파일도 삭제됨

git rm --cached {파일명}

– 위 명령 후 commit을 수행해야 함
– Git으로부터 더 이상 추적되지 않음
– 워킹 디렉터리에 여전히 보존됨
– 추적되지 말아야 할 파일들을 실수로 넣은 경우에 사용
• 오브젝트 파일 등등

둘 다 추적상태를 끊어주지만, 워킹 디렉토리에서의 보존 여부가 다르다.

파일명 변경

git mv file_from file_to

파일명 변경 예1) 

git mv README.md README

파일명 변경 예2) 

mv README.md README
git rm README.md
git add README

ex)
1. mv README.md README를 실행하면 워킹 디렉토리에서 파일 이름은 변경되지만, Git은 이 변경 사항을 반영하지 않습니다.
2. 따라서 Git은 여전히 README.md를 추적 중이며, 새로 생성된 README 파일은 Git에 의해 추적되지 않는 상태로 남아 있습니다.
Git의 상태 확인:

파일 이름을 변경한 후 git status 명령어를 실행하면 다음과 같은 상태를 확인할 수 있습니다:

  • README.md 파일이 삭제된 것으로 표시됩니다.
  • README 파일은 새 파일로 인식됩니다.
  1. Git에 파일 이름 변경을 제대로 반영하려면 git mv 명령어를 사용하는 것이 좋습니다.

커밋 히스토리 조회

 git log

– 저장소의 커밋 히스토리를 시간순으로 보여줌
– 체크섬, 저자명, 저자 이메일, 커밋 날짜, 커밋 메시지

– -숫자
• 최근 숫자 개의 결과만 출력
– --oneline
• 각 커밋을 한 라인으로 요약해서 출력
– --graph
• 브랜치와 머지 히스토리 출력

되돌리기

• 최근 커밋 덮어쓰기

git commit --amend

• 커밋을 했는데 파일을 빠뜨린 경우, 혹은 커밋 메시지를 잘못 작성하여 다시 커밋하고 싶을 때 사용
• 커밋을 했는데 stage하는 것을 잊은 경우 다음과 같이 수행

git commit –m “initial commit”
git add forgotten_file
git commit --amend //커밋이 첫 번째 커밋을 덮어씀(체크섬 값은 변경)

태그

– 커밋에 태그를 다는 기능
– 하나의 커밋에 여러 태그 가능하지만 여러 커밋에 같은 태그는 불가능

태그 달기

– git tag –a –m <message> <tag name> [branch or checksum]

• -a : 주석 포함하여 태그 달기
• -m : 로 간단한 주석 작성

Branch 관리

새로운 브랜치를 만들면 그 브랜치는 현재 체크아웃된 브랜치를 기준으로 만들어지며, 현재 브랜치의 최신 커밋 내용을 그대로 이어받습니다. 이 과정에서 자동으로 병합(merge)이 일어나는 것은 아니지만, 새로운 브랜치는 기존 브랜치의 상태를 그대로 복사하게 됩니다.

  1. git fetch origin: 원격 저장소 origin의 최신 커밋 정보들을 로컬로 가져옵니다. 하지만 로컬의 main 브랜치는 아직 업데이트되지 않습니다.
    반영하려면:
  2. git merge origin/main: 로컬 main 브랜치에 원격의 main 브랜치 변경 사항을 병합.
    또는 git pull origin main: fetch와 merge를 한꺼번에 실행해서 로컬 main 브랜치를 원격 main 브랜치와 동기화.

따라서 git fetch는 원격의 내용을 가져오는 것일 뿐, 로컬 브랜치에는 자동으로 반영되지 않는다는 점을 기억하면 됩니다.

실습


mkdir branch로 시작하며 git tag를 사용한 버전 관리를 포함하여 원하는 결과를 얻을 수 있습니다.

단계별 해결 방법

  1. 디렉토리 생성
    먼저 branch라는 디렉토리를 만들고 그 안에서 작업을 시작합니다.

    mkdir branch
cd branch
git init

  2. 파일 생성 및 첫 번째 커밋
    project_file 파일을 생성하고 첫 번째 커밋을 합니다.

    echo "Project Version 1" > project_file
git add project_file
git commit -m "첫 번째 커밋"

  3. 두 번째 커밋
    project_file에 내용을 추가한 후 두 번째 커밋을 합니다.

    echo "Project Version 2" >> project_file
git commit -a -m "두 번째 커밋"

  4. 세 번째 커밋
    또다시 내용을 추가하고 세 번째 커밋을 진행합니다.

    echo "Project Version 3" >> project_file
git commit -a -m "세 번째 커밋"

  5. 브랜치 생성: left와 right
    이제 브랜치를 분기합니다.

    • left 브랜치:

      git branch left
git checkout left
echo "Left branch content" >> project_file
git commit -a -m "left 브랜치 첫 번째 커밋"
git tag V3.1

    • right 브랜치:

      git checkout master
git branch right
git checkout right
echo "Right branch content" >> project_file
git commit -am "right 브랜치 첫 번째 커밋"
git tag V3.2

  6. V4 버전으로 이동
    다시 master 브랜치로 돌아가서 V4 버전과 커밋을 관리합니다.

    git checkout main

echo "V4 버전 네 번째 커밋" >> project_file
git commit -a -m "네 번째 커밋 (V4)"

git tag V4

  7. 결과 확인
    이제 git log --oneline --graph --all 명령어로 다이어그램에서처럼 브랜치와 버전 태그가 제대로 만들어졌는지 확인합니다.

    git log --oneline --graph --all

버전 관리 확인

  • V3.1과 V3.2는 각각 left와 right 브랜치에서 첫 번째 커밋 이후 태그가 설정되었고,
  • V4는 master 브랜치에서 다수의 커밋 후 태그로 관리되었습니다.

이와 같이 진행하면 문제에서 요구하는 Git 브랜치와 버전 관리 구조를 성공적으로 구현할 수 있습니다.

profile
밥슌
마트 시식코너같은 저의 벨로그에 어서오세요.
이전 포스트

[오픈소스 설계][git][linux]

다음 포스트

[오픈소스설계] reset과 checkout

0개의 댓글