✏멘토링 일지✏ - 2021community/Algorithm-skills GitHub Wiki

❤ 2021.08.28(토)

<멘토링>

정책

  • branch protection을 걸어 develop에 접근 제한을 잘 했다.

Branch Convention

  • feature/#19/이름 - 이슈 뒤에 슬래시를 붙이는 경우는 거의 없으므로 feature/#19_김지혜 혹은 feature/#19-김지혜로 만든다.
  • hotfix는 배포 후 버그가 발견되는 긴급한 수정이 필요할 때 main에서 따서 작업해야 한다. 작업 후 main에 바로 merge하는 경우도 있지만 회사마다 다르다.

마지막 발표

  • 전략의 이유를 설명하면 좋을 것이다.

<질문>

1. README.md 파일의 경우 팀원 모두가 같이 담당하는 이슈인데 이런 경우에 이슈를 상세히 나누는 것과 한 이슈에서 branch를 각자 생성하는 것 중에 더 효율적인 방안은 어떤 것인가요?
▶ branch를 생성해서 만드는 방법이 좋다.
1) feature/#19 공동작업 베이스를 공유
2) 베이스에서 분기를 나눠 작업
3) 각자 작업한 분기를 베이스에 merge
4) 베이스를 develop에 merge

2. 잘못했을 때 수정은 어떻게 하는 것이 좋은가요?
 ▶ 커밋 메시지 수정, 커밋 합치기, 순서 바꾸기, 삭제 등 커밋 로그를 꾸밀 때 interactive rebase 사용한다.

git rebase -I HEAD~5

HEAD: 현재 체크아웃한 브랜치의 가장 최신 커밋을 가리키는 포인터
-I: interactive rebase

1) 실수하더라도 reset을 사용하지 않고 rebase 옵션을 잘 사용해 커밋을 수정, 삭제할 수 있다. (amend, suqash, drop 등)
2) 막힐 때는 git status로 힌트를 얻는다.

3. 현업에서는 git reset, rebase 사용 안 한다는 말이 있는데 그러한가요?

▶ 보통 f1이 공동작업을 하는 브랜치일 경우 문제 발생한다.
1) 브랜치의 이력이 변경된 것을 모를 때 문제가 발생함으로 커뮤니케이션이 중요
2) 공동작업자가 메커니즘을 잘 이해하고 있다면 reset, rebase를 사용 가능
3) 혼자 하다가 같이 하게 되면 주의를 먼저 줘야 함(공동작업자가 잘 모르면 내가 푸시 할 때마다 공동작업자는 f1을 지우고 다시 받아서 작업하는 방법을 이용)
4) main, develop에는 절대 reset, rebase하면 안 됨
5) reset 대신에 revert 사용: 커밋을 취소하는 커밋이 생김(반대로 되돌리는 커밋 생성. 그러면 이력이 달라지지 않으므로 중요할 때 사용)

예) https://git-school.github.io/visualizing-git/

🧡 2021.09.02(월)

<멘토링>

포트폴리오 홍보

  • 개발자 커뮤니티가 Facebook을 중심으로 활발하게 활동하기 때문에 최신 소식이나 정보를 빠르게 얻고 싶다면 Facebook을 활용해보자.
  • 지금 프로젝트를 진행한 결과물을 그냥 끝내기에는 아까우므로 Facebook 개발자 커뮤니티에 홍보를 해보는 것도 좋을 것 같다.
  • 해외 소식은 트위터에서 가장 빠르게 얻을 수 있다.

master에 자주 merge 하기

  • git flow 전략을 사용하는 근본적인 이유는, 빠르게 비즈니스 요구사항을 반영하기 위함인데, 마지막에만 develop 브랜치를 master에 merge 하게 되면, 전략이 생긴 이유와는 거리가 멀어지게 된다.

<질문>

1. git pages에서는 아이콘(SVG 파일) 깨짐 현상이 발생하는데 어떻게 해결해야 좋을까요?
▶ Status code를 확인하고 찾아보는 것이 좋다.
1) 페이지 검사를 통해서 Status code를 확인
2) github pages SVG status [코드]를 검색해서 해결방안을 찾음

2. rebase를 사용하니까 커밋이 계속 기록에 남는데 괜찮은 것인가요?
▶ 공동작업하는 곳에서 rebase를 하게 되면 충돌이 일어나거나 어긋나게 되는데 커밋이 기록에 남으면 서로 진행 상황을 확인할 수 있어서 커밋 기록이 남는 것이 더 도움이 된다.

3. master에 release 할 때 pull request를 통해 master에 병합해야 하나요?
▶ 팀에서 결정해서 진행하면 되지만, 주로 pull request를 통해 병합한다.
배포하기 전에 여러 사람이 함께 확인하는 것이 좋으므로 pull request를 주로 사용한다.



⚠️ **GitHub.com Fallback** ⚠️