clone과 fork의 차이점을 설명하시오.
https://github.blog/2015-07-29-git-2-5-including-multiple-worktrees-and-triangular-workflows/
- fork란, 오픈 소스에 기여하거나 협업을 진행할 때 다른 사람의 저장소에 있는 코드를 수정하는 등의 행위를 위해 다른 사람의 원격 레포지토리(Upstream)를 내 원격 레포지토리(Origin)로 복사해오는 것
- clone이란, 특정 원격 레포지토리를 나의 로컬 레포지토리로 복사해오는 것
Pull Request가 무엇이고 사용해본적 있는지
- 내가 수정한 코드에 대해 특정 브랜치를 가져가 검토한 후, 해당 레포지토리의 브랜치에 병합해달라고 요청하는 것
- PR을 사용하는 경우
- 협업을 진행할 때, merge하기 전 팀원간의 자연스러운 코드 리뷰를 통해 충돌을 최소화하고 코드를 검증하기 위해 사용
- push 권한이 없는 오픈 소스 프로젝트에 기여하기 위해 사용할 수도 있다.
Issus의 사용 경험 여부
- 프로젝트를 진행하며, 새로운 기능의 추가나 파일 추가, 버그 개선 등을 나누어 개발 전 이슈를 먼저 생성하고 이슈를 기반으로 작업을 진행하였다.
- 이슈를 생성하며 팀원들과 아이디어를 교환하며 구현 방향에 관한 논의를 할 수 있다는 점, 작업의 진행상황을 체크하기 좋다는 점, 기능별 구현자를 알 수 있다는 점 등 다양한 장점을 느낄 수 있었다.
커밋을 취소하고 싶은 경우 어떻게 하는지
- 혼자 진행하는 프로젝트거나, 커밋을 아직 푸시하지 않은 경우는
reset을 사용한다. - 협업을 하는 상태에서 이미 푸시한 커밋의 경우
revert를 사용한다. revert는 reset과 달리 커밋을 삭제하는 것이 아닌 새로운 커밋을 추가하는 방식이므로 다른 사람들과 함께 사용하는 브랜치에서 충돌을 방지할 수 있다. 또한 특정 커밋을 revert했다는 commit history도 남길 수 있으므로 협업에는 reset보다 더욱 적절하다.
커밋은 보통 어떤 단위로 하고 그렇게 하는 이유가 무엇인지
- 하나의 객체를 생성하거나 기능을 구현하는 단위로 커밋을 많이 합니다. 객체가 너무 크거나 복잡한 기능이라 커지는 경우, 커밋 로그를 보는 것만으로도 어떤 기능과 객체를 개발하고 있는 것인지 파악할 수 있을 정도로 나누어 커밋을 해왔다.
- 특정 시점으로 돌아갈 수 있는 포인트들을 많이 만들어놓기 위해서
- 커밋 로그를 통해 어떻게 개발을 진행해왔는지 쉽게 파악하기 위해서
프로젝트에서 사용한 브랜치 전략과 이유
- git-flow 전략을 master, develop, feature 브랜치만 간략화해 사용했다. 주로 실제 배포 서비스가 아니었기 때문에 복잡한 git-flow 전략 전체가 필요하지 않았고, github-flow의 경우 PR을 사용하지 않았으므로 장점이 없었고 일관되고 체계적으로 관리하기가 쉽지 않아 git-flow를 간략화해 사용했다.