본문 바로가기
CS/Unix 시스템

리눅스 문제 풀이 - 버전 관리와 깃, 브랜치의 생성과 병합, 스태시와 버전 되돌리기

by Renechoi 2023. 11. 28.

깃은 무엇인가?

  1. 버전 관리 시스템
  2. 프로그래밍 환경
  3. 프로그래밍 언어
  4. 공유 저장소 서버

정답: 1

깃의 파일 상태 중 '수정 전(unmodified)' 상태란?

  1. 파일이 생성되었지만 깃으로 관리하지 않는 파일의 상태
  2. 파일 수정 작업을 커밋한 이후에 파일이 수정되지 않은 상태
  3. 파일을 생성한 후 작성한 후 스테이지 영역에 올린 상태
  4. 파일을 수정하였지만 스테이지 영역에 올리지 않은 상태

정답: 2

  1. 파일이 생성되었지만 깃으로 관리하지 않는 파일의 상태: 이 상태는 일반적으로 'Untracked' 상태로 불린다. 이 상태의 파일은 깃 저장소에 추가되지 않았기 때문에 깃의 추적 대상이 아니다.
  2. 파일 수정 작업을 커밋한 이후에 파일이 수정되지 않은 상태: 이 설명은 '수정 전(unmodified)' 상태를 정확히 설명한다. 이 상태의 파일은 깃 저장소에 커밋된 이후 변경사항이 없는 파일을 의미한다다. 이 파일은 깃에 의해 추적되고 있으며, 마지막 커밋 이후 변경되지 않았다.
  3. 파일을 생성한 후 작성한 후 스테이지 영역에 올린 상태: 이 상태는 'Staged' 상태이다. 파일이 스테이지 영역에 추가되어 다음 커밋에 포함될 준비가 된 상태를 말한다.
  4. 파일을 수정하였지만 스테이지 영역에 올리지 않은 상태: 이 상태는 'Modified' 상태이다. 파일이 마지막 커밋 이후 수정되었지만 아직 스테이지 영역에 추가되지 않은 상태를 말한다.

따라서, 깃의 파일 상태 중 '수정 전(unmodified)' 상태는 '파일 수정 작업을 커밋한 이후에 파일이 수정되지 않은 상태'를 의미한다.

깃 저장소의 상태를 확인하는 명령은?

  1. git chectk
  2. git status
  3. git state
  4. git log

정답: 2

깃 저장소를 만들고 초기화하는 명령은?

  1. git config
  2. git run
  3. git init
  4. git start

정답: 3

스테이지 영역에 기록된 변경을 깃 저장소에 커밋하는 명령은?

  1. git commit
  2. git add
  3. git save
  4. git snapshot

정답: 1

현재 디렉터리에서 모든 변경 내용을 인덱스에 등록하는 명령은?

  1. git commit .
  2. git commit --all
  3. git push .
  4. git add .

정답: 4

깃 저장소에 저장된 커밋 이력을 확인하는 명령으로, 커밋당 한 줄의 정보만 출력하는 명령은?

  1. git status -s
  2. git log --short
  3. git log --online
  4. git show --oneline

정답: 3
해설: git show --oneline은 git show HEAD --oneline과 같으며 최신 커밋의 정보를 한 줄로 출력하고 이전 커밋과 비교도 한다.

두 커밋 사이에 저장된 파일을 비교하는 명령은?

  1. git diff HEAD~ HEAD
  2. git diff
  3. git diff --staged
  4. git diff file1 file2

정답: 1
해설: 1은 직전 커밋을 기준으로 최신 커밋과 파일의 차이를 비교한다. git diff는 스테이지 영역을 기준으로 작업 디렉터리와 비교하고, 3은 깃 저장소를 기준으로 스테이지 영역과 비교한다.

깃 저장소에 존재하는 기존 브랜치 이름을 나열하는 명령은?

  1. git checkout
  2. git branch
  3. git show
  4. git list

정답: 2
해설: git show는 이전 커밋과의 비교를 포함하여 커밋 정보를 자세히 출력한다.

커밋 이력을 그래프로 표현해주는 명령은?

  1. git showt --graph
  2. git log -v
  3. git log --graph
  4. git log --oneline

정답: 3

  1. git show --graph: 이 옵션은 존재하지 않는다. git show 명령은 주로 단일 커밋의 상세 정보를 보여준다.
  2. git log -v: -v 옵션은 git log에서 사용되지 않는 옵션이다. git log는 커밋 이력을 보여주는 명령이지만, -v 옵션은 그것과 관련이 없다.
  3. git log --graph: 이 옵션이 정답이다. git log --graph 명령은 커밋 이력을 그래프 형태로 표시하여, 브랜치와 머지의 시각적 표현을 제공한다.
  4. git log --oneline: 이 옵션은 커밋 이력을 한 줄로 요약하여 보여주지만, 그래프 형태는 아다. --oneline 옵션은 커밋의 해시와 제목만 간단하게 표시한다.

깃에서 사용하는 브랜치 개념이나 사용에 관한 설명으로 옳지 않은 것은?

  1. 브랜치는 독립적으로 수행되는 개발 작업의 흐름을 의미한다.
  2. 버그 수정이나 기능 추가 작업을 할 때 브랜치를 새로 만들어 작업한다.
  3. 저장소에 존재하는 분리 개발되는 특정 용도의 버전을 의미한다.
  4. 새로운 브랜치에서의 수정 작업은 기존 브랜치에도 계속 영향을 준다.

정답: 4

이미 병합된 브랜치를 삭제하는 명령은?

  1. git delete branchName
  2. git checkout -d branchName
  3. git switcht -d branchName
  4. git branch -d branchName

정답: 4
해설: git branch 명령에서 -d 옵션은 --delete 옵션과 같다.

새로운 브랜치를 생성하지만 HEAD가 이동되지 않는 명령은?

  1. git switch -c newBranchName
  2. git checkout -b newBranchName
  3. git switch --create newBranchName
  4. git branch newBranchName

정답: 4

새 브랜치를 만들 때 git branch newBranchName 명령을 사용하면 새로운 브랜치가 생성되지만, HEAD는 현재 브랜치를 가리키고 있게 된다. 여기서 HEAD는 현재 작업 중인 브랜치를 나타내는 포인터라고 생각하면 된다.

git switch -c newBranchName이나 git checkout -b newBranchName는 새 브랜치를 생성하고, 바로 그 브랜치로 작업 환경을 이동시킨다.

git branch newBranchName 명령은 새 브랜치를 만들기만 하고, HEAD는 이동하지 않는다. 즉, 현재 작업 중인 브랜치에 계속 머무르게 된다. 이러한 특성 때문에, 단순히 브랜치를 만들고 싶을 때 사용하며, 바로 작업을 시작하고 싶지 않을 때 유용하다.

따라서 git branch newBranchName 명령은 새 브랜치를 만드는 것에만 초점을 맞추며, 현재 작업 중인 브랜치에서는 벗어나지 않는다.

브랜치와 커밋 이력이 다음 그림과 같다. 아래 명령에서 수행되는 병합방식은 무엇인가?

A -> B -> C (master) -> E (hotfix)
-> D (issue)

$ git checkout master
$ git merge hotfix 
  1. fast-forward 병합
  2. 2-way 병합
  3. 3-way 병합
  4. cross 병합

정답: 1

이 문제에서는 master 브랜치와 hotfix 브랜치를 병합하는 상황을 다루고 있다. 명령어에 따르면, 먼저 master 브랜치로 이동한 후에 hotfix 브랜치를 master에 병합하려고 한다. 이 상황에서의 병합 방식은 "Fast-forward Merge" 즉, "빠른 전진 병합"이라고 부른다.

이유는 간단하다. master 브랜치의 마지막 커밋(C)이 hotfix 브랜치의 기반점이 되기 때문이다. 즉, hotfix 브랜치는 master 브랜치에서 분기된 후에 추가적인 커밋(E)이 이루어졌다. master 브랜치에는 hotfix가 분기된 후 새로운 커밋이 없기 때문에, master의 HEAD는 그저 hotfix의 마지막 커밋(E)으로 이동하기만 하면 된다.

빠른 전진 병합은 다른 브랜치의 커밋들을 현재 브랜치에 그대로 추가할 수 있을 때 사용되며, 복잡한 병합 과정 없이 단순히 HEAD 포인터를 이동시키는 것으로 병합이 완료된다. 이 경우, master 브랜치의 HEAD를 hotfix 브랜치의 최신 커밋(E)로 옮기면 되므로, 복잡한 병합 과정이 필요 없다.

결과적으로, 이 명령은 master 브랜치의 HEAD를 hotfix 브랜치의 마지막 커밋(E)으로 빠르게 이동시키는 빠른 전진 병합을 수행한다.

주어진 브랜치 또는 커밋으로 HEAD를 이동시키는 명령이 아닌 것은?

  1. git merge branch
  2. git switch branch
  3. git checkout commit
  4. git checkout branch

정답: 1

3-way 병합에 관한 설명으로 옳지 않은 것은?

  1. 독립적 두 브랜치를 하나로 합치는 것이다.
  2. 병합이 처리될 때 새로운 커밋은 추가되지 않는다.
  3. 충돌이 발생하면 자동 병합은 실패한다.
  4. fast-forward 병합과 마찬가지로 git merge 명령을 사용한다.

정답: 2

3-way 병합은 Git에서 두 브랜치를 합칠 때 사용되는 방법이다. 두 브랜치의 최신 커밋과 이 두 브랜치가 분기하기 전의 공통 조상 커밋을 사용하여 병합을 수행한다.

1번에 대한 설명: 맞는 설명이다. 3-way 병합은 독립적으로 발전한 두 브랜치를 하나로 합칠 때 사용한다. 예를 들어, 하나의 프로젝트에서 두 개의 다른 기능을 개발하는 두 브랜치가 있다면, 이 두 브랜치를 하나로 합칠 때 3-way 병합을 사용한다.

2번에 대한 설명: 이게 바로 틀린 설명이다. 3-way 병합을 수행할 때는 새로운 커밋이 생성된다. 이 커밋은 두 브랜치의 변경 사항을 통합한 결과를 담고 있다. 즉, 병합 과정에서 발생한 모든 변경 사항을 하나의 커밋에 담아서 기록한다.

3번에 대한 설명: 맞는 설명이다. 두 브랜치를 병합할 때 같은 파일의 같은 부분을 수정했다면 충돌이 발생한다. 이런 경우 Git은 자동으로 병합을 처리하지 못하고 사용자에게 해결을 요청한다. 사용자가 충돌을 해결한 후에 병합을 완료할 수 있다.

4번에 대한 설명: 이것도 맞는 설명이다. 3-way 병합과 fast-forward 병합 모두 git merge 명령어를 사용한다. fast-forward 병합은 한 브랜치가 다른 브랜치의 직접적인 후속 브랜치인 경우 사용되며, 별도의 병합 커밋을 생성하지 않는다.

다른 브랜치로 이동하기 전에 변경 작업을 임시 저장하는 명령으로 옳지 않은 것은?

  1. git stach
  2. git stash save "message"
  3. git stash push
  4. git stash push "message"

정답: 4

  1. git stash: 이 명령어는 현재 작업 중인 변경사항(아직 커밋하지 않은 변경사항)을 임시로 저장한다. 나중에 다시 이 변경사항들을 작업 트리로 불러올 수 있다. 이 명령어는 기본적인 임시 저장 기능을 수행한다.
  2. git stash save "message": 이 명령어도 현재의 변경사항을 임시 저장한다. 하지만 "message"라는 추가적인 메시지를 stash에 포함시킬 수 있다. 이 메시지는 나중에 어떤 변경사항을 임시 저장했는지 기억하는 데 도움이 된다.
  3. git stash push: 이 명령어는 git stash와 유사하게 작동하며, 현재의 변경사항을 임시 저장한다. git stashgit stash push는 사실상 같은 명령이며, push는 명령어의 새로운 형식을 나타낸다.
  4. git stash push "message": 이 명령어는 실제로 존재하지 않는다. git stash push 명령어는 메시지를 그대로 인자로 받지 않는다. 만약 메시지를 포함시키고 싶다면, 올바른 형식은 git stash push -m "message"가 되어야 한다.

따라서 정답은 4번이다. git stash push "message"는 잘못된 형식의 명령어이므로, 이를 사용할 수 없다.

스태시 명령에서 '추적되지 않는 파일'도 저장하는 옵션을 사용한 것은?

  1. git stash -a
  2. git stash -k
  3. git stash -u
  4. git stash -q

정답: 3
해설: 스태시 명령으로 '추적되지 않는 파일'을 저장하려면 -u 또는 --include -untracked 옵션을 사용해야 한다.

'git stash apply' 명령의 기능을 정확히 설명한 것은?

  1. 스태시에서 stash@{0}을 가져와 작업 영역에만 적용한다.
  2. 스태시에서 stash@{0}을 가져와 스테이지 영역에만 적용한다.
  3. 스태시에서 stash@{0}을 가져와 작업 영역과 스테이지 영역에 적용한다.
  4. 스태시에서 stash@{0}을 가져와 추적되지 않는 파일로 복원한다.

정답: 1

git stash apply 이 명령어는 Git에서 임시 저장된 변경사항들을 현재의 작업 영역에 다시 적용하는 데 사용된다. 이 명령어는 임시 저장한 변경사항들을 스태시(stash)에서 꺼내와서 작업 디렉토리에 적용하지만, 스태시 자체는 그대로 유지된다.

  1. git stash apply: 이 명령어는 스태시에서 가장 최근에 저장된 변경사항(stash@{0})을 현재 작업 영역에 적용한다. 이 명령어는 저장된 변경사항을 스태시에서 삭제하지 않고, 단지 현재 작업 중인 브랜치에 적용하기만 한다.
  2. 스태시에서 변경사항을 가져와 스테이지 영역에만 적용하는 기능은 git stash apply 명령어의 기능이 아니다. 스테이지 영역에 적용하려면 다른 명령어를 사용해야 한다.
  3. git stash apply 명령어는 작업 영역과 스테이지 영역 모두에 적용하는 것이 아니라, 오직 작업 영역에만 적용한다.
  4. 추적되지 않는 파일을 복원하는 것은 git stash apply 명령어의 기본 기능이 아니다. 추적되지 않는 파일을 포함하여 스태시를 만들려면 다른 옵션을 사용해야 한다.

따라서, 정답은 1번이다. git stash apply 명령어는 스태시에서 가장 최근의 변경사항을 가져와 현재의 작업 영역에 적용하는 기능을 한다.

스태시에 저장된 항목을 불러와 작업 영역을 복원할 때, 스테이지 영역까지 복원하는 명령은?

  1. git stash --index
  2. git stash save --keep-index
  3. git stash apply --keep-index
  4. git stash apply --index

정답: 4

  1. git stash --index: 이 형식의 명령어는 존재하지 않는다.
  2. git stash save --keep-index: 이 명령어는 스태시를 생성할 때 사용된다. --keep-index 옵션은 현재 스테이지 영역에 있는 변경사항들을 유지하면서 스태시를 만드는 데 사용된다. 즉, 이 명령어는 스태시를 불러오는 것이 아니라, 스태시를 만들 때 스테이지 영역의 내용을 유지한다.
  3. git stash apply --keep-index: 이 명령어는 스태시에서 변경사항을 불러와 작업 영역에 적용할 때 사용된다. 하지만 --keep-index 옵션은 현재 스테이지에 있는 변경사항을 유지하면서 스태시의 내용을 적용한다. 즉, 이 명령어는 스테이지 영역까지 복원하지 않는다.
  4. git stash apply --index: 이 명령어는 스태시에 저장된 변경사항을 불러와 작업 영역에 적용하는 동시에 스테이지 영역의 상태도 복원한다. --index 옵션을 사용하면, 스태시에 저장될 당시의 스테이지 영역 상태도 함께 복원된다.

따라서 정답은 4번이다. git stash apply --index 명령어는 스태시에 저장된 변경사항을 작업 영역에 적용하면서, 해당 변경사항이 스태시될 당시의 스테이지 영역 상태도 함께 복원한다.

스태시 항목을 가져와 작업 영역에 적용하고 스태시 목록에서 제거하는 명령은?

  1. git stash drop
  2. git stash clear
  3. git stash pop
  4. git stash push

정답: 3

  1. git stash drop: 이 명령어는 스태시 목록에서 특정 항목을 제거한다. 하지만 이 명령어는 스태시 항목을 작업 영역에 적용하지 않는다. 단순히 스태시 목록에서 항목을 삭제할 때 사용된다.
  2. git stash clear: 이 명령어는 스태시 목록의 모든 항목을 삭제한다. 마찬가지로, 이 명령어는 스태시 항목을 작업 영역에 적용하지 않는다. 스태시 목록을 완전히 비울 때 사용된다.
  3. git stash pop: 이 명령어는 스태시 목록의 가장 최근 항목을 작업 영역에 적용하고, 해당 항목을 스태시 목록에서 제거한다. 즉, 스태시 항목을 불러와 적용한 후에, 그 항목을 스태시 목록에서 없앤다.
  4. git stash push: 이 명령어는 현재의 변경사항을 스태시 목록에 추가한다. 이 명령어는 새로운 스태시 항목을 만들 때 사용되며, 기존의 스태시 항목을 작업 영역에 적용하거나 제거하지 않는다.

'git reset --hard HEAD'의 기능을 바르게 설명ㅎ한 것은?

  1. 마지막 커밋의 상태로 작업 영역과 스테이지 영역을 변경한다.
  2. 최신 커밋을 취소하고 그 이전 커밋으로 되돌아간다.
  3. 마지막 커밋 이후 수행했던 변경 작업을 임시 저장한다.
  4. 최신 커밋을 가리키는 HEAD를 그 이전 커밋으로 이동시킨다.

정답: 1

  1. "마지막 커밋의 상태로 작업 영역과 스테이지 영역을 변경한다": 이 설명이 git reset --hard HEAD의 정확한 기능을 설명한다. 이 명령은 현재 HEAD가 가리키는 마지막 커밋의 상태로 작업 영역과 스테이지 영역을 모두 되돌린다. 이 명령을 사용하면 마지막 커밋 이후에 수행된 모든 변경사항이 삭제되므로 주의해서 사용해야 한다.
  2. "최신 커밋을 취소하고 그 이전 커밋으로 되돌아간다": 이 설명은 git reset 명령의 다른 사용 방식에 가깝다. git reset 명령에 --soft--mixed 옵션을 사용하면 이와 유사한 작동을 할 수 있다. 하지만 --hard 옵션을 사용할 경우, 작업 영역과 스테이지 영역의 변경사항까지 모두 삭제한다.
  3. "마지막 커밋 이후 수행했던 변경 작업을 임시 저장한다": 이 설명은 git reset --hard HEAD의 기능과 일치하지 않는다. 이 명령은 변경사항을 임시 저장하지 않고, 오히려 완전히 삭제한다.
  4. "최신 커밋을 가리키는 HEAD를 그 이전 커밋으로 이동시킨다": 이 설명도 git reset 명령의 다른 사용 방식을 설명한다. git reset --hard는 HEAD의 위치를 변경하지 않고, 현재 HEAD가 가리키는 커밋 상태로 작업 영역과 스테이지 영역을 되돌린다.

따라서 정답은 1번이다. git reset --hard HEAD 명령은 현재 HEAD가 가리키는 마지막 커밋의 상태로 작업 영역과 스테이지 영역을 모두 되돌린다.

reset 과 revert 기능 중에서 reset 기능에 관한 것은?

  1. 새로운 커밋이 생성된다.
  2. 취소된 커밋이 커밋 이력에 남아 있다.
  3. 작업 폴더가 깨끗한 상태라야 실행이 가능하다.
  4. --mixed, --hard, --soft의 세 가지 모드가 있다.

정답: 4
해설: 1,2,3은 rever에 관한 것이다.

 

 


참고 자료: Unix 시스템 (김희천, 김진욱 공저, KNOU press 출판)

반응형