코드잇 풀스택 2기 Week 3 - 서술형 평가 (Git and GitHub Collaboration)

# 코드잇 풀스택 2기 Week 3 - 서술형 평가 (Git and GitHub Collaboration) ## PH

• 2024-08-09 : First posting.

## TOC ## git reset의 3가지 옵션에 대해 설명해 주세요.

--soft --soft 옵션은 HEAD만을 변경합니다. 이는 HEAD가 가리키는 커밋을 변경하지만, staging area와 working directory는 영향을 받지 않습니다. 커밋을 취소하고, 해당 파일들을 다시 커밋하기 전 상태(스테이징 상태)로 되돌리고 싶을 때 사용합니다. 이 옵션을 사용하면, reset 명령을 실행한 후에 바로 다른 커밋을 만들 수 있습니다. --mixed --mixed 옵션은 HEAD와 staging area를 변경하지만, working directory는 변경하지 않습니다. staging area의 변경은 커밋되지 않은 상태로 되돌리는 효과가 있습니다. 가장 최근의 커밋을 수정하고 싶을 때 사용합니다. 커밋을 취소하고 해당 파일들을 수정할 준비가 된 상태(하지만 아직 스테이지되지 않은 상태)로 만듭니다. 다시 스테이징하고 커밋을 할 수 있습니다. --hard --hard 옵션은 HEAD, staging area, 그리고 working directory 모두를 변경합니다. 이는 가장 강력한 리셋 옵션으로, 모든 로컬 변경을 버리고 특정 커밋으로 돌아갑니다. 완전히 새로 시작하고 싶을 때, 또는 실험적인 변경을 완전히 제거하고 싶을 때 사용합니다. 이 옵션을 사용하면, 리셋 명령 이전의 모든 로컬 변경이 사라집니다.

## git merge와 git rebase의 차이에 대해 설명해 주세요. git merge와 git rebase는 두 개의 브랜치를 통합하는 Git 명령어입니다. git merge는 두 개의 브랜치를 통합하는 과정에서 새로운 "merge commit"을 생성하여 두 브랜치의 변경사항을 모두 포함하는 새로운 스냅샷을 만듭니다. 이는 두 브랜치의 히스토리가 모두 보존되며, 병합된 히스토리를 통해 어떤 변경사항이 어디서 왔는지 추적할 수 있도록 합니다. 이로 인해 병합 과정이 명확해지고, 원래 브랜치의 히스토리를 그대로 유지할 수있습니다. 하지만, 프로젝트 히스토리가 복잡하고 지저분해질 수 있다는 단점이 존재합니다. git rebase는 한 브랜치의 변경사항을 다른 브랜치의 끝에 적용합니다. 즉, 하나의 브랜치가 시작된 기점을 변경하여 마치 그 브랜치가 최신 상태에서 시작된 것처럼 재배치합니다. 이 과정에서 원래의 커밋들이 새로운 베이스 위에 다시 생성됩니다. 이로 인해 더 깔끔하고 선형적인 커밋 히스토리를 만들 수 있습니다. 이는 특히 추후에 코드 리뷰나 히스토리 검토를 할 때 유용합니다. 하지만, rebase 과정에서 커밋의 시간순서가 바뀌어 원래 커밋의 컨텍스트를 잃어버릴 수 있습니다. ## 이미 remote repository에 올라간 커밋을 취소하는 방법에 대해 설명해 주세요. ### git revert 사용 방법

git revert 명령을 사용하면 특정 커밋의 효과를 취소하는 새로운 커밋을 생성할 수 있습니다. 이 방법은 공개된 커밋을 안전하게 되돌리고 싶을 때 사용되며, 원격 저장소의 히스토리를 그대로 유지하면서 변경사항만 취소합니다. 되돌리고 싶은 커밋의 해시를 찾습니다. (git log 명령을 통해 확인 가능) 다음 명령을 실행하여 해당 커밋을 되돌립니다: ``` git revert <commit-hash> ```/ 이 명령은 편집기를 열고 커밋 메시지를 입력하라고 요청할 수 있습니다. 변경사항을 설명하는 메시지를 작성한 후 저장하고 종료합니다. 변경사항을 원격 저장소에 푸시합니다. ``` git push origin <branch-name> ```/

### git reset 사용 방법

git reset은 커밋을 아예 히스토리에서 제거합니다. 이는 협업 환경에서 주의가 필요합니다. 특히, --hard 옵션은 변경사항을 모두 삭제합니다. 로컬 브랜치를 이전 상태로 되돌리기 ``` git reset --hard <commit-hash> ```/ 여기서 <commit-hash>는 되돌리려는 커밋 이전의 커밋 해시입니다. 강제로 원격 저장소에 푸시 ``` git push origin <branch-name> --force ```/ 여기서 <branch-name>은 작업 중인 브랜치 이름입니다. --force 옵션은 원격 저장소의 히스토리를 덮어씁니다. 주의점 git reset과 git push --force는 협업 중인 다른 사람들의 작업에 영향을 미칠 수 있으므로, 팀원들과 협의 후 사용하는 것이 좋습니다. git reset --hard를 사용할 경우, 변경사항이 완전히 사라지므로 중요한 작업이 있을 경우 백업이 필요합니다.

## GitHub에서 Pull Request를 사용할 때 브랜치 merge 방법들과 각 방법의 특징을 설명해 주세요. pr(pull request)을 할 때 세 가지 merge 방법 중 하나를 선택할 수 있습니다. 왜 이렇게 다른 세 가지 방법 중 하나를 선택할까요? 커밋 메세지, 커밋 그래프를 어떻게 유지해야 할지와 연관되어 있기 때문입니다. ### Merge 일반적으로 많이 사용하는 merge 방법이며, 커밋 이력을 모두 남길 때 사용합니다. 장점이자 단점은 모든 커밋과 분기했던 branch 히스토리가 남는다는 점입니다. Fast-forward 설정이란? git merge 는 —ff 옵션(fast-forward)이 기본으로 설정되어 있는데, 이는 Base 브랜치가 이후 변경 내용이 없는 최신 브랜치일 경우 병합한다는 커밋 없이 합치고, 그렇지 않을 경우 병합 커밋을 남기고 합칩니다.(참고) Github의 Merge pull request는 git merge -—no-ff 옵션으로 Base 브랜치가 최신 브랜치라 할지라도 커밋을 남기도록 강제 합니다. ### Squash & Merge git merge 에 -squash 옵션을 추가한 방법입니다. 분기했던 branch에 있던 내용 a, b, c 커밋을 모두 합쳐 하나의 새로운 커밋을 만듭니다. 지저분한 커밋 히스토리들을 하나로 합쳐서, 기능상 의미있는 하나의 커밋만 남길 때 사용합니다. 잘못 사용해 과도한 생략을 하게 되면, 추후 변경 파악이 힘들 수 있습니다. ### Rebase & Merge 분기했던 branch의 기준을 최신 Base로 설정하고, merge하는 방법입니다. 결과적으로는 git merge -ff 와 같은 형태가 됩니다. rebase를 하면 커밋들의 Base가 변경돼 커밋 해시 또한 변경 될 수 있습니다. 이런 경우 git push -f (force push)해야할 경우도 있습니다. 머지 커밋을 남길 필요가 없는 merge의 경우 사용하면 좋습니다. 커밋 그래프가 하나의 라인으로 그려져 가독성에 좋습니다. ### 언제 어떤 걸 사용할까? branch 전략에 따라 달라질 수 있고, 아래는 Git Flow를 기준으로 얘기한 내용입니다. 특정 기능 개발 후 develop branch에 merge하고자 할 때는 Squash and Merge가 유용할 수 있습니다. develop branch를 production branch로 merge하고자 할 때는 develop branch에 분기가 남아있다면, production branch는 간결하게 유지하고자 Rebase and Merge가 유용할 수 있습니다. ## Git Flow 브랜치 전략에 대해 설명해 주세요. Git flow는 main 또는 master 브랜치와 development 브랜치를 유지하면서, 용도에 따라 임시적으로 feature, release, hotfix 브랜치를 생성해서 사용하는 방식의 전략입니다. 브랜치 별로 약속된 역할에 맞게 생성하여 사용하게 되는데요. 각 브랜치를 통해 규칙에 맞는 흐름flow대로 작업이 이루어지는 것을 지향합니다. 먼저 2가지 기준이 되는 브랜치입니다. master: 정식 배포의 기준이 되는 브랜치로, 항상 안정적인 제품이 서비스될 수 있는 소스코드이며, 언제나 배포가능한상태로 유지되어야 하는 브랜치입니다. develop: 개발 중인 코드를 관리하는 브랜치입니다. 새로운 기능 개발과 개발된 변화를 담은 버전 배포작업이 시작될 수 있는 브랜치입니다. 이렇게 보면, develop은 master를 기준으로 변화가 일어나는 브랜치이고, 준비가 되면 쌓여온 변화들이 master에 병합시키기 위한 브랜치라는 것을 알 수 있죠. 새 버전이 배포되는 시점만큼은 master 브랜치와 동일한 상태일 것입니다. 앞서 본 것처럼, develop 브랜치에서 기능개발과 릴리즈를 준비합니다. 이런 경우 feature, release브랜치를 develop브랜치로부터 생성해서, 작업을 하게 됩니다. feature: 개발할 기능을 위한 브랜치입니다. 기능 개발이 완료되면 그 변화가 develop 브랜치로 병합하고, feature브랜치는 제거됩니다. release: 배포를 위한 브랜치입니다. 배포 전 마무리 작업과 버그 수정이 이루어집니다. 완료되면 master와 develop 브랜치로 병합됩니다. 역시 릴리즈가 끝나면 제거됩니다. 추가로, master 브랜치에 긴급한 수정이 필요할 때는, hotfix 브랜치를 활용해서 빠르게 배포하기도 합니다. hotfix: 긴급한 버그 수정을 위한 브랜치입니다. master 브랜치에서 발생한 버그를 고치고 master와 develop 브랜치로 병합합니다. master브랜치를 기준으로 생성하기 때문에, 빠르게 master에 병합해서 버그에 대응할 수 있습니다. Git flow는 안정적인 코드 배포를 위한 강력한 전략이지만, 프로젝트가 작을 때는 비효율적일 수 있습니다. 배포주기가 긴 대형 서비스이면서, 서비스의 안정성이 강조되는 경우에 좋은 전략이 될 수 있습니다.

장점: 안정적인 배포를 위한 구조가 갖춰져 있습니다. 긴 개발 주기에 적합하며, 복잡한 기능 개발과 버그 수정에 유용합니다. 배포 전 마무리 작업과 테스트를 위한 release 브랜치를 사용할 수 있습니다.

단점: 브랜치가 많아지고 관리해야 할 작업이 증가할 수 있습니다. 이를 보완하기 위한 git flow 도구가 있을 정도죠. 작은 규모의 프로젝트에서는 비효율적일 수 있습니다.

## RRA

1. Git - GIT 강의 (Feat. GitHub) | 코드잇:
   https://recoeve.net/user/kipid/mode/multireco?cat=[IT/Programming]--국비 지원 코딩/공부#https://www.codeit.kr/topics/git
   
   https://www.codeit.kr/topics/git
2. Git 협업하기 - 강의 | 코드잇:
   https://recoeve.net/user/kipid/mode/multireco?cat=[IT/Programming]--국비 지원 코딩/공부#https://www.codeit.kr/topics/collaborating-with-git
   
   https://www.codeit.kr/topics/collaborating-with-git