가. GIT(GITHUB)/SourceCommit
VS
1) git? 이거 그냥 하면 되는 것 아닌가?
클라우드 캠프에 참여하기 전부터 GIT에 대해서, 이런것이 있다? 정도로 듣기는 했었다. 그리고 클라우드 캠프에서 배운 프로그램중 가장 문화 충격을 준 두개의 프로그램은 도커와 깃이었다.
사회 생활을 함녀서도 파일/문서의 버전에 대해 어려움도 많았다. 그리고 깃을 보는 순간 와 이런것이 있구나 하고 배우기 시작하였고, 교육을받을때 참 혁신척이면서도 참 쉬웠다. 교육때는..그냥 따라만 가면 되니, 그리고 처음 프로젝트를 시작하면서도 말은 참 쉽게 했다.
2) 개발 구상 단계에서의 깃의 사용
출처 : https://backlog.com/git-tutorial/kr/stepup/stepup1_1.html
와 같이 개발 단계 / 이력관리를 브런치로 하려고 하자고 말했다. 그리고 시작부터 난관에 부딪쳤다.
(사실 위에 가. 글의 분류를 보신 분들은 ??할 수 밖에 없을 것이다. 그리고 그것이 난간에 시작이었다. )
나. git vs git hub
이론상으로 깃과 깃허브에 대해서는 깃은 로컬 저장 / 관리장소 깃 허브는 통합 저장소라는 부분을 알았다. 그리고 깃 허브에 푸쉬하기 전에는 pull 명령어를 통해서 로컬 git을 최신화 할 필요가 있다는 것도 알고는 있었다..알고는.. 그런데 막상 하기 시작하니..오류,오류 그리고 오류가 발생하였다.
0) 사전에 조금 더 조율해야 했던것들
가)사용하는 에디터 및 버전
나)정확한 기본 브런치의 이름
이었다. 개발 일정에 쫓겨 해당 부분을 정확하게 하고 가지 않았던 우리는 브런치를 나누기 전부터 브런치가 나눠지는 기적을 볼 수 있었다. main브런치와 master브런치 문제였다.
1)기본 브런치는 main? master? 브런치
깃의 기본 브런치가 2020년부터 main으로 변경되기 시작하였는데, 나를 포함한 조원들이 사용하는 에디터 등의 버전에 따라서 깃의 브런치가 main과 master가 혼재되어 있었다. 그래서 단순히 pull -> commit -> push로는 재대로 깃 허브에 올라가지 않았다.
출처 : https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main
2)깃 머지(merge) /풀 리퀘스트(Pull Request)
결국 브런치를 합치는 것 부터 다시 공부하고, 해당 문제를 해결하였다. 그리고 곧 두번째 문제에 직면하게 되었다.
다. git hub vs naver souce commit
프로젝트 시작시에서는 깃 허브를 사용하려고 하였다. 사용 이유는?
1) 우리가 교육때 배워서 익숙했고
2) 가장 대중적인 저장소
였기 때문이었다. 그리고 naver에서 소스 빌드를 사용할때까지만 해도 아무런 문제가 없었다.
빌드에서의 리파지토리는 깃 허브도 있었기 때문이었다. 그리고 얼마 뒤 깃 허브로는 해결 할 수 없는 문제가 발생하였다.
빌드와 달리 소스 파이프라인을 구성할때 트리거로는 깃 허브가 불가능했기 때문이었다. 이에 따라 급한 해결책은
Sorce commit에서 외부 지포지토리를 복수하여 사용하는 방법이었다.
네이버 소스 commit은 git의 클론 기능을 제공하고 있었다. 하지만 CI/CD부분에서 수정이 많이 필요함에도 naver sorce commit의 clone기능에서는 지연이 지속적으로 발생하였고, 이에 저장소 변경을 결정하였다.
라. Sorce commit으로 변경
1) 만드는 것은 쉬웠다.
리포티토리는 그냥 다음/다음으로 쉽게 만들수 있었다. 정말로 특이사항은 없었다.
2)접속이 힘들(?)뿐
만들고 계정으로 아무리 만든 저장소에 들어가려고 해도 계속해서 계정이 일치하지 않는다는 오류가 발생하였다. 그래서 다시 찬찬히 확인하니
네이버 Sorce commit은 접속하기 위해 Subaccount설정이 필요했다.
별 수 없이 서브 계정 설정부터 다시 해주었고, 해당 계정을 통해서 접속하였을때는 아무런 문제 없이 접속이 가능했다. 이렇게 공용 저장소 생성/관리는 마무리 되었다.
