Github-Flow 전략 프로젝트 연습하기

이왕 알게 된 전략 혼자서라도 연습해봐야겠습니다.

 

프로젝트 초기 구조화 작업

Todo 예시

 

해야할 일들

 

이번 스프린트 동안 개발해야 하는 메인 페이지 컴포넌트들입니다. 연습이니까, 보기 편하게 일단 Todo에 넘어온 기능에 관한 것만 폴더를 생성하여 구조화 해보겠습니다.

 

 

 

Server

 

Server 폴더 구조

 

위에서 정리한 기능을 구현하기 위해 꼭 필요한 폴더/파일 들을 만들어 보았습니다.

 

모듈은 express, cors, nodemon, morgan 만 우선적으로 설치해놓은 상태이고, MVC(Model-View-Controller)모델에 따라 controller, repository로 구조화 했습니다.

 

router 폴더는 요청 메서드 경로에 따른 라우팅을 관리할 폴더입니다.

 

 

 

Client

 

client 폴더 구조

 

먼저 public 폴더에 필요한 이미지들을 images 폴더를 만들어 넣어두었습니다. public 폴더에 이미지를 넣어두면 이미지를 불러올 때 ./images/blabla.png 라고만 적어도 되어서 간편하다.

 

src 폴더 안에는 대표적으로 components 폴더와 pages 폴더가 존재합니다. 컴포넌트를 모아두는 폴더와 라우팅 하는 페이지를 모아둔 폴더입니다.

 

pages 폴더에는 이번 스프린트 동안 만들어야 할 MainPage 폴더를 생성하고, 그 안에 css, js 파일을 넣었습니다.

components 폴더에는 카테고리 버튼, Footer, Header, 아이템 버튼을 일단 넣어두었습니다.

 

추후 또 어떻게 수정 될 지는 당장 모르겠지만 일단 기본 틀은 저렇게 잡아두고 시작합니다.

 

 

 

Github-Flow 전략으로 Git에 반영하기

프로젝트 구조화 작업까지는 대충 마쳤는데, 이제 Git에 반영하려니 뭔가 어색했습니다.

지금껏 혼자 프로젝트를 해올 때마다 git add . git push origin main 을 밥 먹듯이 해서... 왜그랬는지 이제 와 보니 모르겠습니다.

 

단 하나 지켜야 하는 규칙은 이렇습니다.

 

모든 코드는 메인에서 절대 직접 작성하지않는다.

 

 

 

 

이렇게 진행하면 아주 적절히 전략에 따랐다고 볼 수 있습니다.

 

그런데 문득 이런 고민이 들었습니다.

 

'프로젝트 구조화를 하는 것도 브랜치로 빼놓고 main에 넣어야 하나? 초기화 작업인데 그냥 바로 main에 넣으면 안 되나?'

 

그래서 "구조화작업만을 위한 브랜치가 존재하는 것인지" 여쭤봤더니

 

 

 

 

라는 답변을 받았습니다. 감사합니다 ^__^

 

 

그래서 일단

 

git checkout main 으로 HEAD를 main에 가리킨 뒤

 

git checkout -b feature/프로젝트-구조화 브랜치를 생성하고

(브랜치 네이밍 규칙)

 

 

git branch -v 결과

 

 

브랜치 생성 및 HEAD 포인터가 잘 가리키고 있는지 확인 후

 

git push origin feature/프로젝트-구조화

 

위 명령어를 통해 로컬에 생성한 브랜치를 원격 저장소에 옮겨주었습니다.

 

 

원격저장소 브랜치 목록

 

 

그럼 이렇게 원격저장소에도 브랜치가 잘 추가된 걸 볼 수 있습니다.

 

또, 앞으로 로컬 브랜치에 push 명령어를 내릴 때마다 자동으로 origin의 브랜치에 push 하겠다. 라는 의미의 명령어를 추가할 수 있습니다

 

git push --set-upstream origin feature/프로젝트-구조화

또는

git push -u origin feature/프로젝트-구조화

 

 

이 부분에 대해서는 이곳을 참고하였습니다. (왜 로컬에서 만든 브랜치는 원격 저장소에 반영되지 않을까?)

 

 

git add . 

git commit -m 'feat/클라이언트&서버 기본 프로젝트 구조화 작업 완료'

(좋은 커밋 작성법)

=> 다른 분이 작성한 구조화 브랜치/커밋 네이밍을 보니까 feat 보다는 init 이 더 직관적이고 좋은 것 같네요.

(브랜치 이름도 되도록 영어로 작성해야 합니다. 제가 뭘 몰랐어요)

 

커밋을 하고 나면 원격 저장소에

 

 

 

 

이렇게 PR을 날리라고 알림이 뜹니다. 버튼을 클릭하면

 

 

Pull Request 보내기

 

 

이렇게 방금 전 올린 커밋 메모를 제목으로

 

base:main ← compare:feature/프로젝트-구조화

 

main 브랜치에 feature/프로젝트-구조화 브랜치를 합병해도 괜찮은지에 대한 PR을 작성하는 화면이 나타납니다.

 

 

PR을 작성한 모습

 

 

설명을 더 추가하여 PR을 날려보았습니다.

비록 솔로 프로젝트이지만 이 과정을 연습하기 위해 내일 오후 2시인가 코치님들이 PR을 검토해주겠다고 하시네요.

 

그런데 여기서 조금 바보 같은 실수를 했습니다.

 

 

 

 

feature/프로젝트-구조화 브랜치에 들어가보면 아까 commit 한 폴더/파일들이 잘 업로드된 걸 볼 수 있는데

 

 

 

 

어라...? server 폴더에서 빈 폴더로 만들어둔 것들 (controller, repository, router)는 빈 폴더라 그런가 반영이 안 되었네요.

client 폴더에는 빈 폴더가 없어서 구조화한 것들 전부 잘 보이는데, sever 폴더의 빈 폴더들만 안 보입니다.

 

이제 폴더 구조화를 할 때 안에 임시 파일을 꼭 하나씩 넣어 PR을 날려야겠습니다.

 

이제 실제 기능을 구현하면서 전략대로 프로젝트를 관리해보겠습니다.

 

 

In Progress - 헤더 섹션 기능 개발 (3h)

제일 먼저 Header를 만듭니다. 나름 페어 분과 플래닝 포커까지 진행해서 3시간으로 개발 시간을 측정해보았습니다.

저는 한 번도 기능 하나를 개발하는 데 드는 시간을 제대로 측정해본 적이 없어서 잘 정한건지는 모르겠습니다. 앞으로 기능 하나에 얼마나 시간이 걸리는지 확인도 해야겠네요.

 

Header 브랜치 생성

가장 먼저 헤더 관련 작업 브랜치를 생성하기 위해 HEAD를 main으로 변경 "하려고" 했습니다.

 

git checkout main

 

명령어를 입력했는데,

 

error: Your local changes to the following files would be overwritten by checkout:
        client/src/App.js
        client/src/index.js
Please commit your changes or stash them before you switch branches.

 

이런 에러가 나타났습니다.

 

알고보니 feature/프로젝트-구조화 브랜치 안에서 client 파일 두 개를 수정했고

(별 것도 아니고 그냥 필요 없는 import 한 줄씩 지운 것 뿐인데)

 

한 브랜치에서 파일 수정이 일어나게 되면 merge, switch branch를 하기 전에 해당 사항을 commit 하거나 stash 해야한다는 것입니다.

 

하지만 내가 파일에서 바꾼 부분들은 현재 브랜치(feature/프로젝트-구조화)와는 전혀 관련 없기 때문에 commit 하고싶지 않았습니다.

 

그럼 일단 add 명령어로 Staging 영역에 저장한 뒤에 다른 브랜치에서 커밋 하면 안 될까? 하고

 

git add .\client\src\App.js

git add .\client\src\index.js

 

명령어를 통해

 

 

 

 

이렇게 스테이징 시키긴 했는데, 그런다고 브랜치를 옮길 수 있는 건 아니었습니다. pull 명령을 했을 때 이런 오류가 난다면 add로 스테이징 하는 것만으로도 pull 이 된다던데...

 

 

그렇다면 git stash 방법은 뭘까...

 

git stash - 현재 디렉토리의 파일을 임시로 백업하고 깨끗한 상태로 돌린다.

 

1) 현재 Staging 영역에 있는 파일의 변경사항을 스택에 넣어 둡니다.

git stash

2) main에서 pull하거나, git checkout 등 원격 저장소에서 내 로컬 브랜치로 변경사항을 적용합니다.

git pull origin master  /  git checkout main

3) 변경 사항을 적용했으므로 스택에서 제거 합니다.

git stash pop

4) 한번에 처리하는 명령어

git stash && git pull origin master && git stash pop

 

(참고 블로그)

 

 

일단 시키는대로 git stash를 했습니다.

gitignore를 적용시킨 node_modules 제외 client 폴더 내 모든 폴더/파일들이 삭제되어 스택으로 옮겨졌습니다.

처음 보는 광경에 살짝 멘붕이 왔지만 잘 넘어갔어요.

git pull origin feature/프로젝트-구조화

를 시도해서 client 폴더를 끌어왔더니 App.js, index.js 파일을 수정하기 전 버전이 불러져왔고(당연하겠죠)

그 상태에서 git stash pop 을 했더니

App.js, index.js 모두 import를 제거한 버전으로 돌아왔습니다.

 

이렇게 하는 거 맞아...???

 

 

일단 시간이 부족하니까 빨리 넘어가고

 

git checkout -b feature/Header

 

위 명령어로 feature/Header 브랜치를 생성했습니다.

 

 

git branch -v 명령어 실행 결과

 

그런데 commit 하고 merge를 안 해줘서 그런가 모든 브랜치에 최근 커밋 상태가 저렇네요? 저는 브랜치마다 커밋 이력이 별도로 존재하는 줄 알았는데 이에 대해선 다시 한 번 공부 해야겠습니다.

 

일단 Header 전용 브랜치에서 기능을 구현해 봅시다.

 

 

App.js 라우트 설정

라우팅을 위해 react-router-dom 모듈을 설치합니다. 예전 팀 프로젝트 때 팀장님이 package.json 바꿨을 땐 PR 날리고도 무조건 본인에게 알려달라 했었는데 잊지 말고 PR에 구체히 적어놔야겠다.

 

git add .\client\package-lock.json .\client\package.json

git commit -m 'chore/client 폴더 react-router-dom 설치'

git push origin feature/Header

 

 

근데 터미널에 명령어 치는  게 귀찮으면 vsCode 소스제어에서 편리한 GUI 방식으로 관리할 수 있습니다.

동그라미 친 + 버튼을 클릭하면 두 개의 변경사항이 스테이징 됩니다.

 

 

 

그리고 커밋, 푸쉬를 하고나면 선택한 두 파일에 대해서만 잘 업데이트 되어있네요.

 

 

이제 App.js 파일에서 진짜 라우트 설정을 해보겠습니다.

 

헤더 요구사항

 

헤더 섹션에 대한 요구사항 정리를 다시 살펴보면, 헤더는 '어느 페이지를 가더라도 존재해야 한다.' 는 요구사항을 가지고 있습니다. 따라서 App.js에 Header(나중에 Footer까지도)를 고정해놓고, 그 아래 라우터를 정의할 것입니다.

 

import { BrowserRouter, Routes, Route } from 'react-router-dom';

import MainPage from './pages/MainPage/MainPage'
import Header from './components/Header/Header'

function App() {
  return (
    <BrowserRouter>
      <div className='main'>
        <Header></Header> <!-- 헤더 고정 -->
        <Routes> <!-- 라우터 정리 -->
          <Route path="/" element={<MainPage/>}></Route>
        </Routes>
      </div>
    </BrowserRouter>
  );
}

export default App;

 

이제 또 App.js 파일의 변경 사항에 대한 commit & push 를 진행해야 합니다.

 

아. 조금전 feature/프로젝트-구조화 브랜치에서 App.js와 index.js 파일을 잘못 수정하여

stash를 사용해 백업->브랜치 이동->복구 를 했었는데, 복구를 하면서 index.js에 대한 변경사항도 다시 살아났습니다.

그래서 결론적으로 App.js와 index.js를 스테이징 해줘야 합니다.

 

 

App.js, index.js 스테이징 결과

 

이번에는 vsCode에서 gui를 통해 스테이징 해주고,

 

git commit -m 'feat/App.js 메인페이지 라우트'

git push origin feature/Header

 

명령어를 실행합니다.

 

그러면 또 feature/Header 브랜치에서는

 

Header 브랜치 push 결과

 

커밋한 두 파일에 대해서 반영 되어있습니다.

 

main 브랜치나 feature/프로젝트-구조화 브랜치에 가면 여전히 이전 버전임을 확인할 수 있습니다.

 

이제 Header와 MainPage가 잘 출력되나 확인하기 위해 export 해보면

 

 

 

 

이렇게 잘 나타나는 걸 볼 수 있습니다. 헤더 또한 어느 경로에서든 늘 상단에 잘 뜨는 것 같습니다.

 

 

git commit -m 'feat/MainPage.js, Header.js export'

git push origin feature/Header

 

그럼 마찬가지로 Header.js와 MainPage.js 파일을 커밋/푸쉬 해주는 반복 작업을 수행합니다.

 

Header를 목업과 동일하게 작업한 뒤 main에 PR을 날릴 예정입니다.

 

 

 

코치 님의 중간 코멘트

 

PR 확인 후 받은 피드백

 

 

styled-component...!! 아직 이 녀석한테 정이 안 들어서 자꾸 모른척하고 회피했던 건데... 딱 걸렸네요.

이참에 연습 겸 css파일을 대폭 줄이고 css in js 형태로 구현해야겠습니다.

 

그리고 bem 방법론 참고 링크