[Mendix Docs] Mendix에서 Version Control

[2024.07.21] 아래 내용은 내가 테스트해본 결과 알게 된 것이고 실제 개발환경에서 혹시 다른 이슈를 경험하게 된다면 글을 업데이트 하고자 한다.

---

Mendix로 개발하는 신입 개발자로서, 본격적으로 협업을 하게 되었고 멘붕을 겪게 된 것은 바로 버전 컨트롤이었다. 인텔리제이와 같은 IDE를 활용하면 터미널을 이용해 commit이나 pull이 가능했고, git이나 git lab에서 해당 레포지토리의 브랜치들을 merge할 수 있었다.

그런데 Mendix는 진짜 정말 모르겠는 것이다...  미치고 팔짝 뛸 노릇.. 

아래 화면에서 보는 것처럼 하나의 개발 브랜치 내에서 commit, push, pull은 아주 간편하고 좋았다. commit의 경우에도 별도의 창이 뜨면서 커밋 메세지를 작성할 수 있도록 잘 구현되어 있었다.

 

하지만 문제는 다른 브랜치로 머지를 해야 하거나, 다른 브랜치를 pull 당겨와야할 때였다.

멘딕스가 제공하는 레포지토리는 기본적으로 git 이기 때문에 혹시나 정말 혹시나 파워쉘로 할 수 있지 않을까 라는 희망이 있었다. status를 확인하고 add하고 commit까지는 좋았는데 push하는 순간 계정 내놓으라고 난리 ^^;; 

혹시 몰라 mendix 계정 정보를 넣었지만 멘딕스가 멘딕스의 앱들을 일괄 관리하는 것인지^^;; 실패했다.. 왜 내 소스고 내 코드인데!!.... 그래서 결심한 건 다음부터는 Private Repository로 설정해 나의 레포지토리를 사용하리라... 뭐 결론: git 접근 안 된다.

 

그래서 결국은 멘딕스 플랫폼을 활용해야했다. 내 프로젝트 내에서 여러 브랜치를 만들고 Docs를 참고한 결과 내린 결론은 다음과 같다. (근데 Docs 내가 못찾은 건지 모르겠지만 정말 자세하지 않다.. 기존의 개발 환경을 고려한 설명이 추가되면 멘딕스 개발자 유입이 더 빠를 것 같은데 말이지)

CASE1: 메인 브랜치로부터 생성된 개발 A 브랜치에서 기능 a를 개발했고 이를 메인 브랜치에 병합

1) 메인 브랜치(로컬)로 이동한다.
2) 메인 브랜치의 원격 저장소에서 최신 소스를 pull 받는다.
(순서대로 병합해야 하잖아.. 로컬저장소... 최신 아닐 수 있잖아..)
3) Version Control에서 'Merge Changes Here'를 선택한다.
4) 아래 창에서 Port fix를 선택한다. 
참고. Merge feature branch는 revision을 선택하는 것 없이 브랜치 통째로 가져오는 것 같아서 이번 케이스와 같은 경우 웬만하면 사용하지 않으려고 한다.

5) 다음을 누르면 아래와 같은 화면이 나오는데 소스를 가져올 대상 브랜치를 선택한다. 이 케이스에서는 개발 A 브랜치를 선택하면 된다.

6) 그리고 Revision을 선택하면 아래와 같은 화면이 뜨는데 병합하고자 하는 Revision과 OK를 누르면 해당 변경사항이 현재 위치한 메인 브랜치로 병합된다.

7) 그리고.. 이 병합 사항은 로컬에서만 이루어진 것이기 때문에 메인 브랜치에서 반드시 원격 저장소로 Push 해줘야 한다. (커밋은 필요 없음; 개발 브랜치에서 커밋한 내용들이 그대로 반영되기 때문)

생각해보면 당연한 것인데 항상 merge를 깃과 깃랩에서 진행했던 나로서는 왜 원격에 반영이 되어 있지 않은 것인가 고민했었다. 뭐... 여하튼 이렇게 반영된 사항은 멘딕스 팀서버에서 다시 확인할 수 있다. 만약 Private Repository를 사용하고 있다면 그냥 깃이나 깃랩으로 처리하고 확인하거나 소스 트리 툴을 활용하는 게 덜 불안할 것 같다.

 

CASE 2: 메인 브랜치로부터 생성된 개발 B 브랜치에서 '개발 A 브랜치에서 개발하고 메인 브랜치로 병합한 a 기능'을 메인 브랜치로부터 Pull 받고자 함

1) 개발 B 브랜치(로컬)로 이동한다.
2) 개발 B 브랜치 의 원격 저장소에서 최신 소스를 pull 받는다.
참고. 동일 브랜치를 쓰는 개발자가 있어 업데이트 사항이 있는 경우를 고려함
3) Version Control에서 'Merge Changes Here'를 선택한다.
4) 아래 창에서 Merge feature branch 를 선택한다. 그 이유는 수많은 개발 브랜치가 병합한 모든 리비전을 각각 merge받을 수 없기 때문이다. (아니 근데 이 경우는 pull 이라는 표현이 좀 더 익숙하다)

 

5) 그리고 다음 화면에서 Pull 받고자 하는 브랜치를 선택하고 Merge한다. 우리 케이스의 경우 메인 브랜치에 병합된 a기능을 pull 받으려고 하기 때문에 메인 브랜치를 선택했다. 

 

이 때 메인 브랜치에서 pull을 받아 로컬을 업데이트 하지 않아도 되는 이유는 이 merge 작업이 원격 저장소와 통신하여 이뤄지기 때문이다. 아래 작업 창을 보면 확인할 수 있다.

6) 그 결과,  a 기능이 개발 B 브랜치로 병합된 것을 확인할 수 있다. 
7) 마찬가지로 이러한 병합은 로컬에서 이뤄졌기 때문에 해당 브랜치의 원격 저장소로 커밋과 push를 진행해줘야 한다. 

이렇게 테스트는 종료되었고 의도한대로 브랜치를 병합할 수 있었다.

---

 

참고. 한 브랜치에서 작업하긴 했지만 협업을 하면서 경험한 것인데.. run을 할 때마다 특정 json 파일이 변경된다는 것이다. 나 참나!! (아니 이거 git ignore 어디서 못하나..) 근데 변경사항은 없다고 인식해서 console에서 revert를 못해^^; 뭐 어떡하라는 건지.. 그래서 진짜 멍텅구리 같게도 항상 프로젝트 소스를 지우고 새로 받아서 진행했었다.

그런데 오늘 위의 시행착오를 통해 알게 된 사실은... 프로젝트를 새로 다운로드 받는 것 대신에  아래 Rever All Changes를 누르면 인식하지 못했던 변경사항도 원복해주는 것 같다. 이 좋은 걸 그 개발 끝나고 알았어 하하 진짜 행복해...! ;;;