Archive
팀 프로젝트 세부 계획에 대한 진전이 없어, 내일은 학원에 일찍가서 조원들과 이야기를 좀 해봐야겠다.
오늘의 한 줄 총평 : 길을 잃었다
figma 30일 trial 끝나기 전에 얼른 작업하자..
오늘의 한 줄 총평 : 벌써 3월 중순
Animations in React App
```
SourceTree, Pull-Request, Conflict 해결 등등 형한테 많은 지식을 공유받았다.
친구들이나 주변사람한테 받은 만큼 나도 누군가에게 지식을 공유할 수 있는 개발자가 되고 싶다.
오늘의 한 줄 총평 : Thanks James.
Git Command Cheat-sheet
그 외 자주 쓰이는 커맨드 (계속 추가)
git checkout -t <remote_path/branch_name> : 원격 브랜치 선택git branch -r : 원격 브랜치 목록보기git branch -a : 로컬 브랜치 목록보기git branch -m <name> <newName> : 브랜치 이름 변경git branch -d/-D name : 브랜치 삭제(-d), 강제 삭제(-D)git push <remote_name> --delete <branch_name> : 원격 브랜치 삭제기타 알게된 것 (계속 추가)
Open Source Project 같은 경우엔 바로 clone 하기보다 fork하여 내 repo에 복사 후 clone하여 작업한다
일반적인 경우는 초대받은 프로젝트를 clone해서 로컬에서 branch를 나누어 작업한다. 로컬에서도 origin과 마찬가지로 master / develop을 만들어 개발은 develop에서 진행한다. 작업이 끝나면 commit하여 origin에 push하고 pull request(PR)를 작성한다. reviewer를 설정하고 필요에 따라 assignee, milestone 등도 설정한다. 그러면 팀원들이 코드리뷰를 하고 approve 되면 merge하여 origin에 병합하고 내 로컬 master 브랜치에서 origin의 코드를 pull 하여 동기화하고 최신 코드를 유지한다. 작업이 끝난 브랜치는 삭제한다.
pull request가 approve되는 규칙은 팀 마다 다르지만 대체로 과반수의 동의가 있어야하고 수정이 필요할 경우 코드를 수정하여 다시 commit, push 한다
PR을 merge하는 방법은 세 가지가 있다.
merge commit : master에 병합되고 commit log에 남는다
rebase merge : (그림으로 보는게 제일 빠를듯..)
squash merge : PR의 commit log를 하나로 추려서 master에 병합하는 방법
원격이건 로컬이건 master를 직접 조작하는 것은 피해야한다
남이 올린 PR에 Suggestion이 있을 경우 md 파일 작성시처럼 백틱 3개와 언어를 이용해 코드를 작성한다. 이는 github에서 제공하는 기능이다
milestone은 일종의 목표? 계획? 같은 개념으로 진행의 척도를 한 눈에 볼 수 있다
원격에 push 또는 원격의 repo를 clone하는 것은 remote의 default로 설정되어있는 branch이다. 초기 default는 master이므로 이를 develop으로 바꿔야한다