[MGS 3기 - 4일차] Git 협업 심화

박철연·2022년 4월 14일
0

MGS STFE 3기

목록 보기
4/35
post-thumbnail

오늘도 최우영 강사님께서 Git과 관련된 강의를 진행해 주셨습니다. 오늘은 본격적인 Github 협업과 관련된 심화 내용을 다루는 강의였습니다.

Git 추가 요소

README.md

README.md 파일은 거의 모든 프로젝트에 포함된 마크다운 형식의 문서입니다.

보통 책의 표지처럼 프로젝트의 전반적인 설명에 대해 담고 있는 문서입니다.

타인들에게 프로젝트에 대한 요악을 제공할 뿐만 아니라, 저장소의 주인과 협업자 모두에게 지침을 제공하기 때문에 협업 간에 공들여 작성할 필요가 있습니다.

License

라이센스는 협업과 직결되는 부분은 아니지만, 레포지토리를 구성할 때 항상 설정하게 되는 부분입니다.

저장소를 만드는 과정에서도, 배포를 하는 과정에서도 신경써야 할 필요가 있습니다.

MIT License는 MIT에서 만든 라이센스로, 모든 행동에 제약이 없으며, 저작권자는 소프트웨어와 관련한 책임에서 자유롭습니다.

Apache License 2.0는 Apache 재단이 만든 라이센스로, 특허권 관련 내용이 포함되어 있습니다.

GNU General Public License v3.0는 가장 많이 알려진 라이센스로, 의무사항(해당 라이센스가 적용된 소스코드 사용시 GPL을 따라야 함)이 존재합니다.

.gitignore

.gitignore 는 git이 파일을 추적할 때, 어떤 파일이나 폴더 등을 추적하지 않도록 명시하기 위해 작성하며, 해당 문서에 작성된 리스트는 수정사항이 발생해도 git이 무시하게 됩니다.

특정 파일 확장자를 무시하거나 이름에 패턴이 존재하는 경우, 또는 특정 디렉토리 아래의 모든 파일을 무시할 수 있습니다.

gitignore를 대신 생성해주는 사이트도 있습니다.

https://www.toptal.com/developers/gitignore

Branching Model

Git Flow

git flow는 현업에서 가장 널리 쓰이는 브랜칭 모델입니다.

Feature, Develop, Release, Hotfix, Master 5가지의 브랜치를 갖고 이를 통해 체계적으로 저장소를 관리해나가는 방식입니다.

https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html

위 페이지를 참고하면 git flow를 직접 컴퓨터에 설치해볼 수 있습니다.

Github Flow

github flow는 git flow의 브랜치 전략이 너무 복잡하고 적용하기 어렵다고 해서 생겨난 브랜치 전략입니다.

github flow는 master 브랜치 하나만을 가지고 진행하는 방식이기 때문에, master 브랜치는 어떤 기능이 구현되든, 오류가 수정되든 모두 master에 머지되어 항상 update된 상태를 유지하게 됩니다.

Gitlab Flow

gitlab flow는 복잡하지 않고 효율을 높이고자 생겨난 브랜치 전략으로 master, feature, production 브랜치가 존재합니다.

이슈트래킹을 연동해 프로세스를 단순화하고자 하는 것이 핵심입니다.

추가 Git 명령어

mv를 통한 rename

mv 명령어로 파일의 이름을 다시 정하는 것은 두 가지 방법이 있습니다.

$ mv app.js main.js
$ git mv app.js main.js

둘 중 git 명령어 없이 mv로만 파일명을 바꾸게 되면, git log 상에 app.js라는 파일이 삭제되고 main.js가 새롭게 만들어 진 것으로 간주됩니다.

다만 이는 깃허브를 통해 협업하는 과정에서 오해와 비효율을 초래할 가능성이 높습니다.

아래처럼 git 명령어를 앞에 붙여주면 실제 git log 상에서도 단순이 파일명이 바뀌었다고 뜨기 때문에, 다른 협업자들이 해당 작업을 더 쉽고 정확하게 이해할 수 있습니다.

Undoing & UnStaging

$ git checkout -- .
$ git checkout -- {filename}

파일 수정을 되돌리고 싶다면, 위 명령어를 통해 undo를 할 수 있습니다. 다만 add 명령어를 통해 스테이징되기 전에만 해당됩니다.

$ git reset HEAD {filename}
$ git rm -f {filename}

add를 통해 스테이징한 것들을 되돌릴 때에는 reset을 하시면 됩니다. HEAD는 최신 버전의 git commit 내역을 가리킵니다.

아래 명령어로는 unstaging과 동시에 삭제까지 시켜줍니다.

--amend

$ git commit --amend

위 명령어로 Vim 에디터를 통해 작성했던 커밋 메시지를 수정할 수 있습니다.

Revert

git revert --no-commit HEAD~3..

Revert는 잘못하기 전 과거로 돌아가 최신을 유지하면서 되돌렸다는 이력을 commit으로 남겨 줍니다.

모든 팀원이 이 사항을 공유할 수 있기 때문에 reset보다 협업에 적합합니다.

원래 revert는 revert가 일어날 때 마다 커밋을 자동으로 합니다. 이러한 상황을 피하기 위해서 --no-commit을 추가할 수 있습니다.

revert --no-commit은 돌릴 때 마다 커밋을 하는 것이 아니라 모든 revert가 끝나고 나서 비로소 커밋하겠다는 플래그입니다.

또한 ..은 순차적으로 revert를 해달라는 뜻입니다.

revert는 기본적으로 다른 동료들이 빠르게 이해하기 쉽지 않으므로, 상세하게 커밋 메시지를 적어주는 것이 좋습니다.

profile
Frontend Developer

0개의 댓글