당장 월요일부터 협업이 시작이다. gitflow-workflow 레파지토리 - 깃에서 내 레파지토리를 볼 수 있고, 레피지토리하나를 클릭해 들어가면 Branch가 있다.
=> 즉, 브랜치는 내부의 세부폴더라고 할 수 있다.
기존에는 git branch를 하면 git의 세부 폴더 내용이 나오는데, 지금은 아무것도 생성하지 않았으니 기본 폴더인 master나 main폴더만 존재한다. 해당 폴더는 다른 사람들도 다 같기에 협업을 위해서는 폴더만들기 branch만들기가 필요하다.
git 명령어
git checkout qqq -> qqq라는 폴더로 (브랜치로)이동하기
git checkout -b qqq -> qqq라는 브랜치를만들고 이동해줘.
->이렇게하면 switched to a new branch 'qqq' ( 이동되었다. 새 폴더 (새 브랜치 ) qqq로!) 라고 나온다.
이렇게 하고
git branch 하면 master(또는 main) 브랜치를 포함해 새로만든 qqq라는 브랜치도 나온것을 확인할 수 있다.
이렇게 branch를 만들면 (가지를 만드는것). 이것을 master(main)에 합치거나 잘라내는것이 가능하다.
이렇게 브랜치별로 따로 따로 파일관리가 가능하다.
==> 어떻게?
현재 qqq라는 곳에 있는상태에서파일을 아무거나 하나 생성한다. 아무거나 작성후, git add . ->
git commit -m "커밋메세지"
-> git push origin qqq 이렇게 하고
git checkout master을 하여
master(main)로 이동하면,
qqq를 생성해 저장한것은 사라지게된다. 다시 qqq로
체크아웃해 들어가면 다시 나옴을 확인 할 수 있다.
합치기 위해서는 git checkout master
이렇게 합치기 위해 마스터(메인)브랜치로 와서
git merge qqq
=>
qqq 파일들을 master(main)으로 끌고와 주세요
이러면 마스터 브랜치 임에도 qqq의 파일이 합쳐져 기존에 qqq에만 있던 파일도 나온것을 확인할 수 있다.
이렇게 기능을 나누기 위해 따로 만든 브랜치를 기능브랜치 라고 부른다. 즉 이부분을 피쳐브랜치 라고 한다.
따라서 보통 qqq 라고 붙이지 않고 feature-createBoard 이런식으로 feature뒤에 작업하는 부분이름을 붙이는 식으로 피쳐브랜치를 생성한다.
gitflow라고 구글링 해보면 많은 이미지들이 나온다.
그중에 아무거나 하나를 들어가보았다.
우아한 형제들 기술블로그였다.
여기서는 브랜치를 여러개 만들어 활용하는것을 볼 수 있었다.
먼저 feature-branch 가 있다.이곳에서 작업을하고 바로 master브랜치로 합치는것이 아니라 develop branch로 합친다.
그리고 어느시점에서 거의 기능이 완성된것 같다면 이제는 버그를 잡는 release브랜치 라는것을 만들어 해당 브랜치에서는 버그만 잡는다.
이후 버그를 다 잡고 master브랜치로 옮기는데, 여기서 발생한 실 운영중의 버그는 여기서 checkout하여 브랜치를 하나 더 만들어 여기서 해결하는 방식이었다.
이렇게 수정해서 다시 master브랜치로 올리는 이 브랜치가 hotfixes브랜치!
브랜치를 만드는것을 브랜치를 딴다 라고 표현한다.
이렇게 마스터 브랜치에 merge 해놓고 이 마스터브랜치를 docker-compose up 하거나 또는 yarn start로 실행하면 마스터 브랜치의 소스코드로(최종완성된 소스코드)다운받아지는것!
왜 다운받아진다고 표현하는지 다시 생각해보니 웹 접속이 곧 소스코드를 다운받아오는 것이라 그렇게 표현하는것이라고 이해했다.
gitflow-workflow 와 forking-repositiory 함께 쓰기
upstream의 레파지토리를 fork해서 받는 방법이다. 다이렉트로 push되는것을 방지해 안정성이 높다.
회사를 갈 경우 회사 깃허브 계정을 받는다.
초기세팅인 보일러 플레이트를 만든다.
그런데 이것을 클론받는게 아니라 이것을 fork하여 내 레파지토리로 만들고!
이 내 레파지토리에서 클론을 진행한다.
회사의 레파지토리를 내 깃허브에 먼저 복사하는 과정을 fork라고한다.
자기 레파지토리에 회사의 것을 fork한다음 자신의것을 clone하는 것!!
clone하면 master(main)브랜치 여기서 피쳐브랜치을 하나 만들고(브랜치 하나따기), 그 브랜치에서 기능을 만든다.
기능을 다 만들었다-> 회사 레파지토리에는 push가 안된다. 회사자체에서 막아놓은것!
따라서 각각 자신의 피쳐레파지토리에 push해야한다.
git push origin feature-productList
이렇게 하고서는 pull요청을 해야한다. 회사의 developBranch기준으로 해당 브랜치에 pull요청을 보낸다. 위쪽에 보면 pull request가 있다. 해당 부분을 클릭해 보내면됨다.
이 pull-request를 pr이라고 한다.
다음날 모여서 회의를 통해 pr 목록들을 보며 각각 코드 리뷰를 보거나, 아니면 깃허브 상에서 코드리뷰를 하는 경우도 있다.
문제가 없다면 통과하여 developBranch에 merge한다.
통과가 안되는 경우에는 합치지 않고 그렇게되면 수정을 해야한다.
이렇게되면 업데이트 된 develop브랜치를 pull해 다시받는다.
이어서 개발 + 수정 한다.
다 되면 즉, 기능을 어느정도 완성했다싶으면 release브랜치에 옮기고!, 여기서는 버그만 수정...
그 후 master브랜치로 옮긴다.
이때 pull받는 곳은 오리진이 아니라 upstream이다.
push가 내꺼의 origin에 하는것.
fork받아놔 pr 날리는방식이다...
upstream?
회사 부분이 위에 있으니 upstream이라고 불리는 것이다.
-->> gitflow + forking-repository
오픈소스 참여하기
오픈소스?
npm의 라이브러리등 여러 라이브러리를 들어가면 깃허브와 연동되어있다. 안의 소스코드 볼수 있는데 이런것을 오픈소스 라고 한다
즉, 오픈소스니까 참여가능!!
앞에서 했던방식과 비슷한 구조이다.
fork해서 내 레파지토리로 받는다.
vs코드에 clone하고, 버그수정을 하거나 내가 추가하고 싶은사항을 추가한다.
그다음 push,
원본에 pr요청을 한다.
merge가 되면 오픈소스에 기여된것이다.
이렇게 오픈소스에 참여하는것이 기여한다 라고한다.
오픈소스에 기여했다 => open source contributor
오픈소스를 만들었다 => open source maintainer
주의사항
- 하루에 적어도 1번이상의 pr을 날려야한다.
기존의 기능 즉, 내가 작성하고 있는중에 merge된것이 있을 수 있기에 나중에 날린 기능과, 기존의 기능이 충돌이될 수 있다.이렇게되면 개개인의 코드수정이 필요하다.따라서 오래걸리는 기능이라면 기능단위를 작게 쪼개서라도 작업하여 commit을 여러번하고, 1일 1pr이 가능한 단위로 작업을 쪼개야한다.
- 서로가 독립적인 기능을 만들어야한다. 같은기능을 만들게하면 안된다.(즉, 큰 범위. 완전히 다른부분)
누군가 게시글 등록을 만들면 게시를 목록이나 수정...등을 만드는게 아니라 게시글 말고 상품 부분을 만들다던가 마이페이지를 만든다던가 하는 것이다.
두개를 합쳤을 시 전혀 거리낌없게.독립적으로 나누기!
- 1일 2회이상 pr한다면 이 경우에도 서로 독립적인 기능을 만들기.
오늘 게시글 만들기를 하고 pr을 날렸다 -> 수정을 같은 날 만들고 다시 pr을 날린다.
==> 이렇게 되면 만약 게시글 만들기가 merge가 되지않으면 어차피 수정부분도 만들기와 관련이 있기에 이 부분도 쓸수가 없게된다.
만약 완전히 별개의 기능들이라면 하나가 merge되지 않아도 다른하나가 통과된다면 그것이 merge될 수 있다.
이런식으로 독립적인 기능!!
그럼에도 불구하고 공통적인 부분이 있을 수 있다.
공통기능!!!
-=> 이 경우에는 잘하는 사람이 해야한다. 그리고 이 사람은 이것이 합쳐질때 전반적으로 문제가 발생하지 않는지 봐야한다.
실습하기
CI /CD
CI:Continuous Integration => 지속적으로 통합한다. 테스트코드 실행하고 배포 준비상태로 만들어 놓는것. 이 후 배포
CD:Continuous Delivery => 손으로 최종배포(마지막 체크까지 할 수 있어 좀 더 안전하다.) / Continuous Deployment (배포까지 자동화되어 편리)
Trunc-Based development ==> 얘 활용하는 회사도 있고,
gitflow를 활용하는 회사도 있다.
Trunc-Based development를 활용하는 회사는 CI /CD 가 잘 갖춰져 있는 회사이다.즉, 테스트 코드 문화가 잘 갖춰져 있는 화사에서 적용한다.
develop브랜치로 feature브랜치를 pr로 날리고, 합쳐지면(merge되는 순간) 바로 CI가 작동된디. -> 성공하면 CD가 Delivery 이면 배포를 사람이 하게되고, Deployment면 배포가 자동으로 이루어진다.
Trunc-Based development => 나중에 버그따로 잡는게 아니라 할때마다 CI 테스트코드가 도는 방식이다. 그래서 그때그때 버그를 찾아낸다.
=> CI /CD 깃허브액션이나 젠킨슨 등 프로세스가 잘 갖춰진 회사에서 가능하다.
gitflow-workflow 실습
upstream의 깃허브계정을 받는다.
->
이 레파지 토리를 fork해서 내 레파지토리로 가지고 오기
->
fork
-> create fork
-> 내 계정에 만들어진다. 이렇게 내 레파지토리로 온다면 아래쪽에 upstream의 주소가 나온다. (실제 원본주소를 확인하는것) 여기로부터 fork된 레파지토리임을 가리킨다.
이제 주소를 복사한뒤 git clone 을 한다.
mkdir 폴더명
폴더 새로 만들고 그 안에 들어가 git clone 내 레파지토리 를 진행한다.
(fork한 것)
다시 원본주소(upstream)으로 간다.
더 나아가기
회의하고 기능만드는 것을 정리해놓는 사이트를 존재한다.
트랠로 => 할일을 정리한다.
또는 깃허브 issues에 할일을 올리는 방법이 있다.
즉 upstream 이슈에 New issues - submit new issue
이것을 가지고 feature브랜치로!
이슈를 보면 #번호 가있다.
feature-#5이런식으로 작성해도 된다.
vs코드. 터미널에 현재 폴더로 돌아와
git checkout -b 브랜치명
git branch하면 새로만든 브랜치로 이동되어있다
여기서 만들면 main에는 영향이 없다.
기능 만들고 git add .
커밋 컨벤션(커밋 위한 규칙)익혀서 사용하기
git commit -m "커밋메세지"
git push origin 내 새 브랜치 이름(지금 새로만든!!)
push 후에 내 레파지토리로!
-> 들어오면 Compare & pull request 있다.
main에 혹은 develop에 pr보내기
-> create pull request 클릭!
회사(또는 리더)
pull request확인하고, file changed부분들어가 확인하고 코드리뷰를 문제없이 통과했으면 기존코드와 합치기
=> upstream주인이 담당하는데 Conversation에서 merge pull request 클릭하면 합쳐짐(merge)
=> 문제가 있다면 close pull request 드롭시킨다.(close 하기)
실수로 close한다면 reopen도 가능하다.
pull은 upstream에서 이루어져야한다.(업데이트 본을 다운받는 주소) 즉, pull할 upstream 주소가 하나 더 등록되어야한다.
git remote -v 하면 현재 내꺼밖에 안뜬다.
git remote add upstream pull받아야할 주소
이후 git remote -v하면 origin과 => 내가 push시 쓰는것.
upstream 이 있다 => pull 받아올때 쓰는것.
pull 받을때 upstream으로부터 받아와야하니
git pull upstream main (해당 브렌치 main에서 받음(지금 현재 main이 있음.))
main에 있는것을 pull받으려면 현재 내 브랜치가 main 이어야한다.
만약 develope의 것을 pull받으려면 develope으로 가서 pull받기
git checkout main
git pull upstream main
=> 이렇게 하면 upstream의 메인이 내 브랜치 main에 합쳐진다.
이렇게 다른사람이 만든 소스코드를 받을 수 있다.
---> 이런식으로 반복된다.
브랜치 지우기
-> git branch -D 지울 브랜치 이름
주의사항: 두번째기능을 다시 만들어야한다. --->>
pr merge되기까지 시간이 남았다. 따라서 보내놓은것 merge될지 안될지 모르니 연결된 기능말고 다른기능을 만든다.
==> 브랜치 확인 잘 하기!!
즉, main으로 돌아가 또는 develop으로 돌아가 브랜치 따기
특정기능브랜치에서 따면 그 기능의 파일을 기반으로 반들어지기에 무조건 만든 기능이 있는 브랜치가 아닌!
main 이나 develop.. 등에서
즉, 시작점에서!!! 브랜치를 딴다.
팀프로젝트에서 무엇을 배울것인가?
많이 찾아보고.. 꼬여보게될것이다.
만약 적용하고싶은게 있다면 기존 코드를 복사해두고 그후 명령어를 입력해 과감하게 시도하고 안되면 되돌리자.
빠른 기술 습득능력 가지기
recoil
apollo/client 등 이미 국내에서 유명기업들이 사용하는 것은 배우긴 하였다.
그러나 모든회사에서쓰는것은 아니다.
협업 프로젝트를 통해 배운기술을 복습하는것도 괜찮으나, 다른 기술도 조금 녹여보는 것도 좋다.
(회사에서 과제를 받을때 우리가 안써본 기술을 적용하라고 할 수도 있기에)
누가 가르쳐주지 않는다.
하다가 모르는 것이 나오면 물어볼 수는 있지만, 사수의 개인시간을 뺏는 일이다.
만약 질문을 할경우 일단 검색하고, 공식문서(Docs)를 보고, 어디까지는 알겠는데 어디는 모르겠다 라는 식으로 질문을 해야한다.
그리고 먼저 검색을 해가며 내 검색노하우를 만들어 내는것도 좋겠다.
팀원에게 물어보기 전 검색해보기!!
나만의 검색 노하우찾기?
만약 react-query로 rest-API를 해보려한다.
어떻게 시작하나?
만약 Docs를 보고 이해를 못했다 ==> import {reactQuery} from 'react-query'
예를들어 이렇게 적힌것을 그대로 복사해 깃허브에서 검색할 수도 있다.
그러면 해당 복사란 내용처럼 작성된 코드들이 쫙 나오고, 참고하면서 그 회사나 그쪽에서쓰는 패턴을 익힐 수 있다.
이러한 검색 노하우를 키우자.
공식문서보는 순서 ==>
처음에 get started,
또는 introduction
또는 installation
이 부분을 먼저 본다. 시작하기위해 알아야할 사항, 핵심개념, 설치방법등이 나와있어 그대로 따라하며 감을 잡자.
이 다음부터는 필요한 부분만찾아본다.
프론트엔드는 기술변화가 빠르다. 어떻게 새로운 기술을 빠르게 적용시키는지에 대해 능력을 키우는게 중요하다.
집요하게 해결하려는 능력.. => 수료하고 나서라도 꼭.
아무에게도 물어보지않고 5일정도는 한문제만 푼다!라고 생각하며 해본다.
지금하기 어렵다싶으면 따로 적어두고, 나만의 노트들을 만들어주고, 날 잡고 이것만 해결하기위해 검색한다.
검색, 날잡고 몰입.
git / Blog다듬기. 보통 최근 1주일을 주로본다. 최근에 어디까지 실력이 늘었는가를 확인이 가능하기 때문.
최근것들은 양보다 질로!!
공부할것이 없다? 그럼 코드 한줄한줄에 왜? 를 붙여보자.(변수를 살펴보며 변수네이밍 붙이는법, 기술스텍으로 graphql을 했는데 rest-API 를 써도 되지 않는가 하는부분, .. 등 쪼개보면 여러 질문들이 나오게된다.
