📚 TIL 30일차

오늘의 주요사항 (6/26, 월요일)

1. git
2. 이메일 인증 (진행중)

오늘은 최고온도 35도... 그리고 실수로 뜨거운 아메리카노를 시켰다.

S.A 문서

S.A 문서

깃헙 규칙을 정한게 인상 깊었다 (여태 아무도 이런 규칙 정하려고 해주지 않앗음....)

기능 단위 별 브랜치 — 병합 → 디벨롭 브랜치 — 최종병합 → 메인 브랜치

1. 기능 단위 별 브랜치 기능_이름

   예시)
   > signup_jungeun

2. 디벨롭 브랜치 ⇒ dev

   • PR 할 때 main 아니고 dev에 보내야 함!

3. PR 수행 시마다 Sync Fork 필수!

4. 커밋 메세지

   [말머리] 작업내용

   [Init] 기능 구현 시 필요한 파일 생성 → [Init] 회원가입 파일 생성
   
   [Update] 기능 구현 중 수정 → [Update] 로그인 기능 수정
   [Complete] 기능 구현 완료 → [Complete] 회원가입 완료
   
   [Refactor] 리팩터링 → [Refactor] ~~ 개선

5. Pull Request 메세지

   [브랜치명][말머리] 제목
   
   상세 내용

   [signup_jungeun][Update] 로그인 기능 수정
   
   ~이런거 했습니다~

💡 Pull Request 시 협업 프로세스

1. 각자 fork한 레퍼지토리에서 작업.
2. dev 브랜치에서 기능_이름 으로 브랜치를 새로 판다.
3. 각 작업 이후
   3-1. commit
   3-2. push
   3-3. Pull Request 등록
4. Repository 관리자가 PR 컨펌
5. 팀원들 모두 Sync Fork

🐱 Pull Request 주의 사항

1. 커밋 어느정도 쌓이면 PR 올리기

   (커밋은 사소한 단위로 하되, Pull Request는 한 번에 올리는 것이 좋음!

   예를 들어 게시글 작성을 구현하면 커밋은 컨트롤러, 서비스, 레퍼지토리 따로 하더라도 PR은 게시글 작성 기능. 이라고 한 번에 올리기)

상황에 따라 유동적으로 자주 올리셔도 관계 없음

2. 충돌 시 Merge 후 PR 하기
3. 한 명이 PR 시 모두 Sync Fork
   • 이때 슬랙에 올릴 테니 Sync 맞춘 뒤 이모지 달아서 확인하기!

git이 나를 괴롭히던 순간들...

1. .gitignore이 적용 안 된다면 캐시를 지워보자

가끔 .gitignore 파일에 추가해도 안먹히는 경우가 있다. 내가 잘못 적은 건 줄 알고 고생했는데 캐시가 쌓인게 문제인 경우도 있다고 한다.

$ git rm -r --cached .     #캐시 삭제
$ git add .      
$ git commit -m "fixed untracked files" 

캐시를 삭제하고 → 캐시 삭제 후 다시 파일들을 VCS에 추가한 다음, → 커밋한다는 순서이다.

2. 커밋 이전으로 상태를 되돌리려면 reset 명령어를 사용하자

원격으로부터 커밋한 걸 되돌리고 싶어서~ 방법을 이래저래 찾아봤다.

$ git reset --hard [commit hash]

$ git reset --hard 4477be9

reset 명령어를 사용해서 위와 같이 명령어를 입력해주면, 입력한 hash의 상태로 강제 회귀된다. 원격 저장소에 올라간 commit을 취소할 때도 사용하는 듯하다. (원격 저장소를 건드리는 건 위험이 따르니 조심할 것)

위와 같이 원격 저장소를 건드리는 것이 걱정이 될 때는 revert명령어를 사용해, 커밋 히스토리에 '되돌렸음!'이라고 흔적을 남기는 것도 방법이 될 수 있다.

3. 아무튼 .gitignore는 미리 잘 처리해주자.

올리고 싶지 않은 파일이 이미 원격 저장소에 올라간 상태라면... .gitignore에 그 파일을 추가했다간 단체로 파일이 삭제될 수가 있다.

.gitignore에 제외할 파일 추가 → 새롭게 추가된 파일은 원격에서 지워야하므로 '지워졌다'고 원격에 올라간다 → 그러면 파일을 pull하는 다른 팀원들의 파일이 지워진다 (ㅋㅋ)

적절한 해결 방법은 없는 것 같고

1. 누군가가 갖고 있는 원본을 공유한다거나....
2. 처음부터 ignore 설정을 잘하는 수 밖에 없는 것 같다. (^^)>

특히 민감한 정보나 저작권이 있는 파일은 공개된 저장소에 올리지 않는게 좋으므로... 귀찮더라도 미리 팀원들에게 설명을 잘하는 (혹은 민첩하게 ignore에 추가를 하는) 사람이 됩시다.