이번에도 예시를 들어보겠다. 물론 같은 앱을 개발하는 방식으로 그 주인공이 듀랑고로 하는 것만 같은 거만 빼면 말이다.
만약 내가 전투 기능을 만든다고 해보자. 그렇다면 멍청하게 main
브랜치에서 박치기로 작업할 것인가라고 한다면, 나라면 절대 하지 말아야 할 행동을 했다고 보는게 맞다고 생각한다. 물론, 개발의 ㄱ자도 모르는 사람이 그랬다면 인정하겠지만, 적어도 이 글을 보고 있는 당신은 그렇지 않다고 생각한다.
물론 급한 경우에 어쩔 수 없이 실수했다면 어쩔수가 없다지만, 사실 이 경우도 개발자 사이에선 용납이 불가능한 실수라고 들은거 같다.
이런 경우가 아니고서야 그런 실수를 하지 않게 하기 위한 하나의 룰이라고 생각하는 것이 맞다고 생각이 든다. 그게 바로 "깃 컨벤션 (GIT Convention)"이다.
사실 이거 전 문서인 Final Day 1 _ GIT? GITFlow? 에서 다뤘던 이야기라 기초원리 는 건너뛰도록 하겠다.사실 정의에 가깝다.
먼저 커맨드 라인에 아래의 사진과 같이 브랜치를 만들어준다.
이러면 GIT Convention를 지켜서 만든거라고 보면 되는데, 무슨 말이냐 하면,
git branch feature/login
^^^^^^^ ^^^^^
이게 기능 폴더라는 의미 / 이게 기능이라는 의미
라고 생각하면 된다. 그럼 아래의 사진처럼 GUI를 보면 브랜치가 생긴 모습을 볼 수 있고, 이대로 본인이 만들고자 했던 기능인 예시에선 로그인 기능을 만들면 되는것이다.
근데 문제가 하나 있다. 저기 GUI를 보면 내 현재 브랜치 위치가 체크 표시로 나타나는데, 현재 내 위치가 main
으로 보인다는 것이다.
이럴때는, 단순하게 위치를 바꿔주면 되는데, 아래의 사진을 참고해서 위치를 옮겨주면 된다.
git switch feature/login
^^^^^^^^^^^^^^^^^^^^
이 브랜치로 이동한다는 의미
그런 다음에 다시 GUI를 보게 된다면, 올바르게 이동이 완료된거니 다시 하던 작업에 맞춰서 적용하면 되는 것이니 작업을 이어가면 된다.
사실 위의 컨벤션을 지킨다고 하더라도 commit message를 그냥 내가 원하는 방식대로 하는건, 협업에서는 대체 뭘 하고 있는지 구분이 불가능 할거다. 생각을 해보면, 메세지를 "~~ 추가"나 "~~ 수정", "~~ 삭제", "~~ 오류 해결"로만 해둔다면 뒤에 있는 말로 구분해야 하는데 이게 여간 힘든게 아니니까 말이다. 그래서 생긴 하나의 또다른 컨벤션이자 규칙이 "커밋 컨벤션 (COMMIT Convention)"이다.
이것도 사실은 Final Day 1 _ GIT? GITFlow? 에서 다 이야기 했으니 기본 은 넘어간다.사실 정의에 가깝다.
내가 로그인 브랜치에서 로그인 기능을 다 구현했다고 해보자. 그럼 서버에 올려서 다른 사람이 가져올 수 있게 해야하는데, 그 순서가 GIT에서는 Commit > Push > PR (Pull Request) 순서로 이뤄진다. 이 순서에 맞게 하기 위해서는 먼저 앞에 있는 Commit이 선행되어야 하는데 그걸 아래의 사진과 같이 진행하면 된다.
git add .
^^^^^
그동안 작업한 내용 스테이지하는거 (커밋할 파일에 추가하는 것)
git commit -m '[FEAT] : ⚙️ 로그인 기능 구현'
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
커밋을 하고 그 커밋에 관한 내용을 쓰는 것
이렇게 진행하면 GUI에서도 본인이 날린 커밋이 뜬다. 아래의 사진과 같이 말이다.
이렇게만 진행하면 PR을 할 수 있게 되는거냐고 묻는다면 아직이다. 이제 다음 과정인 Push로 넘어간다. Push를 하기 전에 보면 앞에 깃허브 모양이 우리가 있는 feature/login
는 없는걸로 뜬다. 이러면 무턱대고 push를 하면 오류 코드를 뿜고는 GIT이 추천해주는데 그 코드가 바로 아래 사진과 같은 코드다.
git push --set-upstream origin feature/login
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
자신의 브랜치에 오리진이라는 파일 저장소를 만들어 주는 것
이와 같이 진행하면 GUI에서는 당신이 뭘 했는지 다른 사람이 볼 수 있는 오리진 브랜치가 생기고 이제 PR을 할 수 있게 된다. 물론 아래의 사진과 같이 노란빛으로 깃허브가 알려주기까지 해주니 참고 !
아마 이것도 하나의 과정이라고 생각이 든다. 천천히 앞으로 나아가는 걸음마랄까 ,,,
다음에는 드디어 SwiftUI와 싸우는 시간이다. 먼저 간단한 탭바도 만들어보고 앱처럼 만들수 있게 구상도 해보면서 투닥이는 시간이니 많은걸 할 수 있지 않을까라는 생각이 든다.