Jost Do It!

문제 상황사내 gitlab 서버를 이전하면서 git 관련 명령(fetch, pull 등)을 하면 아래와 같이 server의 인증서 검증에 실패했다는 메시지가 발생했다.git fetch>> fatal: unable to access 'https://gitlab.xxxx.com/financial_backend/us_stock_processing/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none  그리고 해당 도메인으로 POST 명령 시에도 Peer's Certificate issuer is not recognized. 에러 메시지가 발생한다.curl -v https://gitlab..

개요 .gitignore로 적용 시 기존에 원격 레포에 업로드된 파일들은 여전히 tracked 되고 있는 문제가 있었다. 해결 방법 .gitignore에 config 파일들을 등록했다. *.cfg *.config 이후 기존에 원격레포에 업로드 돼 있던 cfg파일들의 캐시를 제거해준다. git rm --cached test.cfg # 특정 파일만 제거 git add . git commit -m "remove cached file" git push origin master 전체 캐쉬를 삭제하려면 git rm -r --cached .으로 명령할 수 있다. gitignore 적용 파일 확인 다음 명령어로 .gitignore에 적용되는 파일 리스트를 확인할 수 있다. git status --ignored >> I..

문제 상황 성질이 다른 데이터에 대해 거의 비슷한 작업을 해야해서 기존에 작업했던 모듈을 copy해 작업했다. 기존에 작업했던 모듈들은 git submodule을 가지고 있는데 copy한 작업을 git에 올리니까 submodule로 인식이 안됐다. .gitmodules에는 submodule 경로와 url이 잘 잡혀있지만... push된 결과는 일반 레포로 잡힌걸 확인할 수 있다. git submodule status를 확인 해보니 기존 레포와 달리 서브모듈이 인식안되는걸 확인할 수 있었다 (결과가 안나옴). 원래 레포에선 이렇게 서브모듈에 대한 상태정보가 나온다. 원인 깃을 초기화하고 새로운 원격 레포에 push 하면 git은 submodule에 대한 정보를 알 수 없다. 즉, submodule에 대한 ..

깃은 디폴트(메인) 브랜치에서 여러 브랜치를 파생할 수 있다. 여러 브랜치로 파생하여 메인 브랜치의 내용들과 충돌 없이 파생된 브랜치에 코드 내용을 수정할 수 있다. 그리고 수정된 코드 내용들을 메인 브랜치와 통합할 때는 PR을 요청하여 깃헙 관리자가 이를 허용/거절하는 구조로 이루어진다. 그러면 이 브랜치를 어떻게 파생할 수 있을까? 깃 브랜치 생성 로컬에서 깃 브랜치를 생성하는 방법은 다음과 같다. 아래 명령어를 쉘의 로컬 깃저장소 위치에서 입력한다. git branch {생성할 브랜치명} 한편 메인 브랜치와의 충돌을 피하려면 메인브랜치의 최신 내용을 pull한 상태여야 한다. 이후에 브랜치에 커밋을 하여야 메인 브랜치와 충돌을 피할 수 있다. 깃 브랜치 변경 위 명령어는 로컬 깃 저장소에 새로운 브..

에러 내용 깃헙에서 workflow 내용을 수정하고 github 저장소에 push하니까 위 에러가 떴다. 내용은 다음과 같다. ! [remote rejected] {원격저장소 branch명} -> {원격저장소 branch명} (refusing to allow a Personal Access Token to create or update workflow `.github/workflows/code-style-check.yaml` without `workflow` scope) error: failed to push some refs to 'https://github.com/{원격저장소 링크}' 메세지 내용을 살펴보면 github에서 발급받은 개인 access token이 workflow를 수정할 수 있는 권한..

보통 회사에서 코드 작성을 마치면 바로 디폴트 브랜치에 코드 내용을 merge하지 않는다. 동료에게 먼저 코드 리뷰를 받는데, 보통은 1명 ~ 3명 내지의 동료들에게 코드 리뷰를 받는다. 코드 리뷰를 통해 내 코드에 이슈가 없는지, 수정하면 좋은 부분이 있는지 검토를 받고 문제가 없으면 디폴트 브랜치에 merge 하는 것을 승인 받는다. 위 과정을 Pull Request (PR)이라고 한다. 그럼 Github에서 PR을 하는 방법에 대해 알아보자. Github에서 Pull Request (PR) 요청 하기 PR전에 변경한 코드 내용들은 별도의 브랜치에 push된 상태여야 한다. 다음으로 PR을 할 Repository에 들어간다. 그리고 아래의 Pull Request 를 클릭한다. 그럼 아래의 화면이 뜬다..

Git은 가장 먼저 해야할 일이 있다. git 저장소를 생성하는 일인데, git 저장소는 파일의 생성, 변경 내용, 삭제 등을 기록하게 된다. 그러면 사용자가 commit한 지점마다의 파일들의 생성 / 변경 / 삭제 이력을 추적할 수 있다. 이를 통해 코드 버전관리, 롤백, 팀원과의 협업 등을 용이하게 할 수 있다. git 로컬 저장소 생성과 원격 저장소와 연결은 보통 아래 명령어로 수행된다. 로컬 경로 내에 git 저장소를 새로 생성 (git init) 및 원격 저장소에 연결 (git remote) git 저장소의 git 정보와 파일 가져오기 (git pull) 위 과정을 한번에 하기 (git clone) 이 글에서는 git 저장소를 생성하고 원격 저장소에 연결하는 방법과 원격 저장소의 파일들을 가져오..