싱글벙글 일일 개발쇼ㅋㅋ

개발 목표

• 누락된 API 개발 (식당 메뉴 보기)
• 홀로 gitFlow
• 더 있으면 추가~ ㅋㅋ

(시간의 흐름에 따라 써내려갑니다.)

1. 로컬, 리모트 dev 브랜치 제거

• dev 브랜치를 삭제하지 않으면 커밋 했던 로그들이 쌓이는데, 조금 있을 때는 크게 상관 없을거라 여기겠지만 많아졌을 때 오류가 나면 관리에 어려움을 겪는다고 한다. 그래서 지움니다. (이 내용은 좀더 알아봐야 할 것 같다)

2. 로컬 develop, feature 브랜치 생성

• 자세한 설명은 생략한다 (엄근진)

3. 식당 메뉴 보기 API 개발 출바알~!

• 코드가 추가될 지점은 당연히 컨트롤러, 서비스, 리포지토리 3계층이고 추가적으로 데이터 전달을 위한 DTO클래스를 만들었다.

• 컨트롤러 추가 로직

@GetMapping("/api/v1/restaurants/{restaurantId}/foods")
    public ResponseEntity<FoodsResponseDto> getFoods(@PathVariable Long restaurantId) {
        return ResponseEntity
                .ok()
                .body(new FoodsResponseDto(foodService.getFoods(restaurantId)));
    }

• 서비스 추가 로직

public List<FoodsDto> getFoods(Long restaurantId) {
        Restaurant restaurant = getRestaurant(restaurantId);
        return restaurant.getMenu().stream()
                .map(FoodsDto::new)
                .collect(Collectors.toList());
    }

• DTO 클래스

public class FoodsDto {
    private Long id;
    private String name;
    private String price;
    ...
}
...

public class FoodsResponseDto {
    private String code;
    private String message;
    private List<FoodsDto> data;

    public FoodsResponseDto(List<FoodsDto> data) {
    	...
    }
}

• 리포지토리
  Entity 모델링?을 잘해놔서 였을까? 리포지토리에 사용자 요청 데이터를 이용하여 정보를 찾는 메서드를 추가할 필요는 없었다. (성능적인 것은 솔직히 아직도 잘 모르겠다ㅠㅠ) 요구 사항을 좀만 풀어 놓자면... 현재 만드는 API는 특정 음식점의 음식 리스트를 가져오는 것이다. 즉 메뉴 보기이다. 관계형 데이터베이스의 장점 'JOIN'을 통해 정보를 가져오는데 음식점에 대한 모든 메뉴는 음식점 아이디로 가져올 수 있다! '음식점' 엔티티를 잠시 보면...

public class Restaurant extends Timestamped {

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "RESTAURANT_ID")
    private Long id;

    @OneToMany(mappedBy = "restaurant", fetch = LAZY)
    List<Food> menu = new ArrayList<>();
    
    (나머진 생략...)
}

메뉴라는 'Food'에 관한 리스트를 음식점 조회만으로 확인을 할 수 있기 때문에 손쉽게 조회가 가능하다!
('Restaurant'과 'Food'는 일대다 관계이며 그에 대한 엔티티 모델링이 되어 있다. 갸꿀~!)

- 여기까지가 메뉴 보기 API에 관한 구현 내용이다 -

4. feature 브랜치 Commit, develop로 Merge 그리고 push

git add .
git commit -m '메시지'

새로 생성된 파일이 없다면

git commit -am '메시지'

그리고 dev 브랜치로 switch 하고 feature 브랜치를 Merge 이후 리모트로 푸시! 혹시나 틀리면 bash가 힌트를 줄 것이다. 병합된 feature 브랜치는 꼭 삭제하자!

git switch dev브랜치명
git merge feature브랜치명
git push
git branch -D feature브랜치명

5. Remote에서 Pull Request

• 아... 미처 다 캡쳐를 못했는데 아무튼 로컬에서 푸시된 브랜치를 remote에서 'pull request'하고 관리자의 승인을 기다린다. 이후 Main에 Merge가 될 것이다. 그렇지 않다면 로컬에서 수정 혹은 재구현 후 앞선 과정을 반복하는 것이 아닐까 싶다.

6. 병합된 dev 브랜치를 삭제하고 remote에서 다시 받아오기

• 앞서 설명했지만 다시 설명하자면 컷밋 로그가 쌓이면 복잡하고 관리의 어려움을 겪을 수 있기 때문이다.
• main 브랜치로 이동 후 dev를 제거한다.

git switch main
git branch -D dev브랜치명

• remote에도 dev브랜치를 제거한다. (물론 merge된 상태겠쥬?)
  

• 리모트의 최신 내역을 로컬로 불러들인다.

git remote update

• 여기서부터 막혔다. 아무래도 참고한 글에서의 git 상태와 나의 git 상태의 조건이 같지 않기 때문인 것 같다 그래서 update 이후 소스트리를 통해 최신이 아닌 로컬의 main 브랜치에 최신 브랜치를 merge했다.

git pull upstream develop # 이건 안돼~!

결과는 이러하다

결론...

• 다시 한 번 최선의 DB모델링과 JPA의 파워를 느낄 수 있었다 (너무 편해~ 하지만 SQL 공부는 해야해!)
• 하나의 기능이 만들어지는 과정을 한 번 GitFlow를 통해 진행해 보았는데 마지막 부분이 좀 아쉬운 것 같다. 재도전 각이다ㅋㅋ