10분 개발자

개괄

MBTI에서 늘 P를 유지하고 있는 영준씨는 또 성급하게 커밋을 올리고 PR을 날려버렸다.

그제서야 생각나는 "아, 이거 안 올렸다" 또는 "헉 이걸 올렸네"

긴급하게 눈에 보이는 REVERT를 눌러버렸다.

문제 발생

Revert를 하는것까진 좋았다. 다시 pr을 날리려고 했는데 문제는 "Nothing to compare"가 뜬 것이다.

분명히 코드는 예전 코드인데....

구글에 찾아보니 Revert로 되돌린 파일들은

"스포일러를 당했는데 기억 속에서만 삭제된 상태"이라고 한다.

분명히 스포일러는 당한 상태인데 (github 이력에 Revert : ~로 나와있음)

내가 알고있는건 아무것도 없는.... 그런 상태

시도한 것

당연하게도, 상남자답게 branch를 밀어버리고 새로이 다른 branch에서 PR을 날렸다.

그렇지만 지금은 회사가 아니고, 나중에 회사라면 정말 큰 문제가 생길 것이다.

깨달은 것

후의 나에게 부탁하는 것과 일맥상통한다.

"제발 성급하게 커밋과 PR을 하지 말 것"

그러나 혹시나 했다면

Revert로 돌릴 때 더 먼 옛날의 코드로 revert를 하거나 reset을 하면 된다.

그러나 최대한 하지 말자.

개괄

처음으로 진행하는 협업, FE와 BE 모두 협업은 처음이었다.

대박 프로젝트의 꿈을 안고 협업을 시작하기로 한 대현씨와 영준씨.

그들은 git repo에 프로젝트명을 넣고 그 안에 모든 FE/BE의 코드를 몽땅 넣어버린다.

문제 발생

그 결과 미친 키메라가 탄생했다.

한 프로젝트 안에 fe/be를 모두 넣고 돌릴때 두명 다 터미널에서 npm start를 하고, 스프링 컨테이너를 띄웠다.

프론트와 백 전부다 gitignore에 코드를 넣었다.

리포지토리는 난잡해졌고 이게 뭔지 모르겠는 상태가 되어버렸다.

그러다 프론트는 SOS를 요청하러 갔고 백엔드는 다른 사람들의 프로젝트를 염탐하러 갔다.

그리고 발견한 다른 팀의 리포지토리. 이게 뭐야!

이렇게 깔끔한 repo가 있을 수가 없다. 그때서야 github Organization에 대한 필요성을 알게 되었다.

그 전까지는 Organization이란 그냥 "나도 pr 받게 해줘"의 연장선인 줄만 알았는데..

그제서야 organization을 만들고 그 안에 서로의 repo를 파서 코드를 나눠 담았다.

이렇게 깔끔할 수가 없다.

이게 협업의 기본이구나 라는걸 또 새삼 깨달아버렸다.

알게 된 점

한 레포에서 BE와 FE를 모두 나누어 담는것은, 1인 프로젝트 때나 하는 것이고,

다른 사람과의, 특히 다른 단에 있는 개발자와 협업을 할 때는 레포지토리를 꼭 나눠야 하는구나 라는것을 깨달았다.