GIT

• 협업을 위한 도구

깃을 왜 써야하는가?

• 개발자로 취업하기 위해 좋은 매리트가 된다.
• 협업도구로서 협업할때 유용하다

깃허브를 좋지 않게 사용하고 있는 예시

• 아카이브 형식이 아닌 협업도구로 사용해야함

깃허브 사용을 겁내지 말자

• 코드가 공개적으로 나와있으니 남들이 본다고 부끄럽다!
  • 생각보다 일반인들은 나의 코드를 꼼꼼히 보지 않는다.
• 취업할 때는 회사에서 확인할 수 있으니깐 완벽한 코드만 넣고싶다.
  • 코드 퀄리티를 본다.
  • 성장 과정을 보여주는 것도 굉장히 중요
• 다른 사람과 같이 협업하다가 코드를 망가뜨릴 수 도 있지 않을까?
  • 깃허브를 믿자

Git의 기본기능

Commit

• 기록을 남기는 것
• 하나의 작업 단위를 마무리할 때
• 커밋을 왜 해야하는가?
  • 협업을 중점으로 뒀을 때 : 커밋을 작성할 때 수정사항에 대한 기록이 남겨져있으면 왜 추가되었는지, 이 코드를 읽어야 하는지 어떤 기능이 추가되었는지 알 수 있음
  • 작업한 기록에 대해서 어떤 작업을 했는지에 대해서 다른 사람이 보기 좋게 작성하는 습관을 들여야 함
    => 코드를 저장 및 내용을 포함하여 기록

repository

• Git 허브 시스템이 나의 코드를 저장하는 방을 하나 만드는 것과 같음
• 코드를 올리면 github가 사라지지 않는 이상 그대로 남아있음
• 내 컴퓨터에만 코드가 있을 시 협업하기 어려움
  => 원격 저장소

push

• 로컬에서 깃 저장소로 저장
  => 원격 저장소에 내 코드를 업로드

pull

• 깃저장소에서 로컬저장소로 가져오기
  => 원격 저장소에서 내 코드를 다운로드
  

branch

• 작업 공간을 분리하는 곳
  
  => 작업공간을 나누는 것

깃허브 쉽게 쓰기

---

code-review 코드리뷰

코드리뷰의 장점

• 코드상의 실수를 미리 파악할 수 있다.
• 책임이 줄어든다.
• 개발자로써 기술적 성장이 쉽다.
• 커뮤니케이션 능력이 늘어난다.

깃허버의 협업도구로써의 강점

Issue

• 큰 기능을 아주 작게 쪼개서 issue로 만든다.

• 이슈만들기

  • 
  • 다른 사람이 쉽게 파악할 수 있게 작성하는 것이 좋음
  • Assignees 담당하는 사람을 설정

• 다른 사람이 만든 코드를 많이 읽어보고, 내가 코드를 잘 작성하는 것이 중요하다.

Pull Request ( PR )

• 프로젝트 코드를 추가하기 전에 다른 사람들의 허락을 구하는 것

• open source : 수정할 수 있는 권한은 없지만 코드르 받아서 코드를 수정해달라고 요청이 가능함

• Retrofit : 네트워크 라이브러리 안드로이드에서 자주 쓰임
  

• 스크린 샷을 넣었을 때 좋다.

• 화면이 없을 때는 스크린 샷이 없어도 괜찮음
  

• 변경된 파일들을 모아서 한눈에 볼 수 있음

• 이 코드에 대해 코멘트에 추가하면 다시 답글을 다는 등 좋게 할 수 있음

코드리뷰를 잘 작성하기 위한 가이드

• 친절하게 코멘트를 남기자
• 코드의 수정량이 +-를 합쳐서 500줄이 넘지 않도록 하자
• 사소해보이더라도 남기는 연습을 하는 것이 좋다. ( Nit : 반영하지 않아도 괜찮다, 가볍게 봐라 , 띄어쓰기 등등 )
  => 이슈를 잘게 조개서 하기
• 이해가 안되는 코드는 질문으로 코멘트를 남겨도 좋다!
• 칭찬의 코멘트를 남기자

Merge할때 사용할 수 있는 커밋의 종류

Merge Commit

Squash Merge

Rebase Merge

깃허브 컨벤션

• 커밋 컨벤션

  • feat : 새로운 기능을 추가한 경우
  • fix : 버그를 고친 경우
  • docs : 문서를 수정한 경우
  • style : 코드 포맷 변경, 세미콜론 누락 , 코드 수정이 없는 경우
  • refactor : 프로덕션 코드 리펙토링
  • test : 테스트 추가, 테스트 리팩터링 ( 프로덕션 코드 변경 없음 )
  • chroe : 빌드 테스트 업데이트, 패키지 매니저 설정할 경우 ( 프로덕션 코드 변경 없음 )

기능 추가 : Add 내용
기능 수정 : Modifier 내용
버그 수정 : Fix 내용
코드 수정 : Refactor 내용

gitmoji 이모지

• 브랜치 네이밍 컨벤션
  - [브랜치 타입]/[#이슈번호] - [브랜치 내용]
  -> / 뒤에 디렉토리 느낌도 같이 반영됨

깃 플로우

• 개발자 통계에서 3위
  
• Master ( main ) 에는 완성 되었다 -> 업로드 할거다 그런 내용만 들어가야함
• develop : 수정되고 잇는 곳이 추합되는 곳
• feature branch : 기능이 추가되고 직접적으로 커밋을 하는 것

마크다운

• 특수기호와 문자를 이용한 매우 간단한 구조의 문법을 사용하여 웹에서도 보다 빠르게 컨텐츠를 작성하고 보다 직관적으로 인식할 수 있다.

readme.md 작성하기

• 프로젝트 요약
• 오랜만에 프로젝트를 확인했을 대 한눈에 어떤 프로젝트 였는지 기억할 수 있음
• 내가 만든 프로젝트를 쉽게 어필할 수 있는 수단
  • 예시화면
  • 기술 스택
  • 패치 노트
• 위 프로젝트를 사용할 때 주의사항 기재