1. WSL과 VScode 그리고 Git

필자의 경우 기본 개발환경으로 Windows를 주로 사용하며, Linux(Ubuntu)를 사용해야 할 개발환경에 처할 경우, 그전에는 VMWare와 같은 가상OS 혹은 듀얼부팅 등을 활용했으나, 요즈음에는 거의 WSL(Windows Subsystem for Linux)을 주로 사용한다.
이는 그림에서 처럼 WSL이 제공하는 기능을 통해 윈도우 상에서 Linux(우분투)를 제어하는게 편리하며, 사용할 때마다 느끼는 거지만 가상 OS와 도커 그 사이 어딘가의 장점만 취한 느낌을 받는다.

그 중 가장 마음에 드는 것은 VSCode 편집기를 사용할 때 WSL상에서 구동중인 Ubuntu 코드 개발환경과 Windows 코드 개발환경을 동시에 사용 가능하다는 것이다.

그러나 주로 Standalone 환경에서 개발하다 보니 Git을 쓸 기회가 적었고, 이를 적용하려다 보니 많은 시행착오가 있었다.

특히 Github에 등록된 온라인 저장소와 로컬 코드 저장소를 동기화하고, 이를 관리하는 방식은 매우 비효율적이었다.

특히 WSL-Ubuntu 상에서 개발하는 환경을 Github와 연동하는것은 아래의 도식으로 표현될 정도로 처참한 개발환경을 유지했었다.

이렇게 사용한 이유가 Github의 온라인 저장소와 내 PC의 로컬 저장소, 그리고 코드 작업공간 3가지를 연동하는 방법을 몰랐었고, 이것을 구현하는데 SSH나 HTTPS 통신기능, VScode의 git extension을 활용하면 되지만 쓸 줄 몰랏다...

특히 WSL에서 아래의 문제를 해결하지 못했는데

이 문제는 vscode git repository 삭제를 통해 해결이 가능하다

$ git rev-parse --show-toplevel -> 설정된 git의 local 저장소 주소 확인하기
$ cd [저장소 주소]
$ ls -a -> 해당 저장소에서 .git 설정 파일 확인
$ rm -r -f .git -> 설정파일 삭제

위 과정을 수행 후 VScode를 재부팅 하면 설정된 git local 저장소 정보가 삭제된다.

이후 다시 git 로컬 저장소를 적절한 위치로 설정하면 된다.

그리고 SSH Key생성 과정을 통해 git local 저장소와 github 온라인 저장소 동기화 과정을 Windows에서 수행하는 것이 아닌 WSL-Ubuntu에서 해야 함을 알았다.


위 사진처럼 윈도우에서 ssh-keygen하는 것과 WSL-Ubuntu에서 ssh-keygen 하는 것은 생성되는 공개키의 이름도 다르고, 키 내용도 다르다.

즉, Windows랑 WSL-Ubuntu는 별도의 OS취급을 받기에 각 환경에서 keygen 과정을 수행하고 생성된 공개키를 github에 등록해야 github의 온라인 저장소를 git local 저장소와 올바르게 연동할 수 있고, 이를 코드 작업공간으로 활용하는 것이 가능하다.

---

2. git을 활용한 코드 버전 관리 규칙

git을 활용한 코드 관리, 코드 버전 관리, 프로젝트 관리에는 프로젝트 팀에서 나름의 규칙을 세워 관리하는 것이 일반적인데 이것과 관련된 코딩 규칙으로는 MISRA, JSF, AUTOSAR 등이 있다.
코딩 규칙을 준수해야 하는 이유로는 설계하는 시스템의 기능안정성 및 보완성을 보증하는 SW 품질을 확보하는 것이 목적이다.
git은 분산 버전관리 시스템이고 이에 대한 것으로 구글 검색을 해보니
.Major, Minor, Patch(주, 부, 수), 형상 관리 규칙(https://url.kr/ym2l59) 등이 있는데
딱히 코딩 관리 규칙처럼 문서화 된 것은 없는 듯 하다.

이와 관련하여 프로젝트 코드 관리에 잔뼈가 굵은 개발자 분에게 전수받은 git Upstream + 분산저장소 관리 방법론을 소개하고자 한다

이 관리 방법론의 도식도는 위와 같다.(https://namugach.github.io/public/root/dev/github/github-%ED%98%91%EC%97%85-%ED%9D%90%EB%A6%84%EB%8F%84.html)

이 관리 방법론은 기존의 두 git 프로젝트 관리 방식의 문제점을 해결하기 위해 고안된 방식이라 보면 된다.

1. 하나의 저장소만 사용 : 프로젝트에 참여하는 개발자들은 sub_branch를 통해 온라인 저장소와 local저장소를 push/pull/commit를 수행하며, 이 경우 리더 개발자가 관리하는 master branch는 merge 과정에서 빈번한 코드 충돌 문제를 해결하는데 많은 시간을 할애해야 한다

2. 복수의 저장소 사용 : 개발자 별로 프로젝트 저장소를 복제하여 작업 후 결과물을 commit/push 하는 방식으로 전체적인 코드 안정성은 높아지나 코드 버전 싱크에 대한 피로도가 높다.

이 1, 2번문제를 해결하기 위해 Upstream이 도입된 코드 관리 방법론을 연습해봤고 꽤 효용가치가 높아서 이를 소개하고자 한다.

2.1 복수의 저장소 생성

우선 첫번째로 프로젝트 리더 작업공간(온라인, 로컬)
그리고 하위 개발자 작업공간(온라인, 로컬)모두 생성한 상황이다.

리더 작업공간 - 온라인은 도식 흐름도에서 'Upstream'으로 지칭하였으며
리더 작업공간 - 로컬은 도식 흐름도에서 'Origin'으로 지칭한다

하위 개발자 작업공간 - 온라인은 'Upstream'을 fork하여 생성한 작업공간이며, 'upstream/main'으로 명기
하위 개발자 작업공간 - 로컬은 'main'이라 보면 된다.

fork및 온라인 저장소를 로컬 공간으로 'clone'하는 과정에 대한 코드는 아래와 같다.

$ git init -> git초기화
$ git remote add upstream [upstream(리더 작업공간 - 온라인) ssh주소값] -> 'Upstream'이 sync fork 대상위치라 알려줌
$ git fetch upstream -> 'Upstream'의 최신 메타정보로 'upstream/main' 업데이트
$ git checkout main -> 'main' branch 생성
$ git merge upstream/main -> 'main' branch 를 'upstream/main'와 합쳐 'main'를 최신 정보로 업데이트

위 과정을 수행하면 하위 개발자의 'upstream/main' branch가 생성되고 적용됨을 알 수 있다.

2.2 하위개발자 코드 작업공간 Dev

위 과정 후 하위 개발자는 코드 개발 및 작업 공간으로 'main'를 사용하는 것이 아닌 그 아래 branch를 생성하여, 이곳에서 코드 개발 및 검토를 완료한다.
하위 개발자 또한 코드 신뢰성을 확보하기 위한 또다른 보안장치로 해당 branch는 'dev'라 칭한다.

$ git checkout -b dev -> 'dev' branch생성 및 'main'에서 'dev'로 branch전환

그러면 위 사진처럼 현재 작업 branch가 'dev'로 된 것을 알 수 있다.

그리고 코드 개발은 각 하위 개발자 별로 예제 python파일의 Calculator 코드의 add, sub 메서드를 개발했다 정의한다.


'dev' branch에서 작업을 완료(코드 개발 및 자체 검수)를 완료했다면 아래의 명령을 통해 'dev' branch내에서의 모든 작업을 마친다.

$ git add [파일 명, 혹은 .] -> 작업이 수행되어 변경된 코드 혹은 파일 선택
$ git status -> 작업 내용(변경된 내용 확인)
$ git commit -m "[코멘트]" 변경된 내용을 'dev' branch 작업공간에 등록하며, 이 것에 대한 요약(코멘트) 기재

위 과정까지 수행한다면 'dev' branch가 'main' branch보다 좀더 최신의 버전이 되었음을 확인할 수 있다.

이때 때에 따라서는 아래와 같은 오류가 발생 할 수 있다.

이거는 git의 식별 이름이 빠져있다는 내용이니 Run 항목의 두 git config 항목을 채워 넣으면 된다.

$ git config --global user.email "[해당 작업자의 github e-mail]"
$ git config --global user.name "[해당 작업자가 지정하고 싶은 Author이름]"

2.3 하위개발자 코드 push

하위 개발자가 코드 개발&자체 검수를 완료했으면 이를 하위 개발자의 온라인 저장소 공간인 'upstream/main'로 개발된 코드를 Push하는 작업을 수행해야 한다.

이 수행과정에는 개발만을 위해 사용하는 'dev'가 아닌 코드의 push/pull을 관리하는 'main'로 이동 후 작업을 수행한다.

이를위한 명령어는 아래와 같다

$ git checkout main

위 명령어를 수행하면 'dev' branch에서 'main'로 branch로 스위칭됨을 알 수 있다.
여기서 버전 sync를 위해 리더 개발자 온라인공간 : 'Upstream'이 변경되었는지 확인 후 push를 수행한다.

$ git fetch upstream
$ git merge dev
$ git push

코드 push 이전에 'Upstream'의 변동사항이 없음을 확인했으면 'main' branch를 'dev' branc와 merge작업을 통해 'main' branch을 개발 후 정보로 업데이트 하고 이를 push 한다.

위 과정까지 수행하고 github에 접속하여 'upstream/main'를 보고 'New Pull Request'버튼을 누르면 아래와 같이 'Upstream'에서 변경 내용에 대한 req가 발생한다.

이 요청에 대한 메세지를 기록하여 req를 수행하면 된다.

2.4 리더 개발자 저장소 요청 수락 및 업데이트

github의 리더 개발자 저장공간인 'Upstream'에 접속한다면
위 사진처럼 Pull Req가 하나 발생함을 알 수있다.

이것에 대한 Merge Pull Req를 수행을 완료하면

리더 개발자 공간인 'Upstream'이 하위 개발자의 코드 수정 정보를 Update를 완료했으며, 이를 VScode 코드에서 Sync를 진행하면 'Origin'에도 정상적으로 적용됨을 알 수 있다.

2.5 두번째 개발자 코드 업데이트 확인 (pull = fetch + merge)

두번째 하위 개발자는 첫번째 하위 개발자와 리더 개발자 간 사이의 Push/Pull과정이 모두 수행되었으니'Upstream'의 업데이트 된 정보를 'main'까지 끌고와야 한다.

이 과정은 간단하게 $ git Pull 명령어로 수행할 수 있으나, Pull은 fetch 과정과 merge과정의 합산
이를 분리하여 진행한다.

$ git fetch upstream -> 'Upstream'의 변경사항 확인
$ git checkout main -> push/pull만을 관장하는 하위개발자 'main' 공간의 main branch로 전환
$ git merge upstream/main -> 'Upstream'의 변경사항을 'main' branch에 적용

두번째 개발자는 위 과정을 통하여 'Upstream' 저장소의 업데이트 된 정보를 로컬 개발자 자신의 로컬 저장소로

2.2

부분부터 반복하여 수행하면 된다.

이 포스트를 작성함에 있어 중간중간 코드 충돌 및 엉키는 부분이 많이 발생했다.
하여 따라하다 보면 캡쳐된 작업상황과 맞지 않는 부분이 발생할 것이다.
이는 전적으로 필자의 개발역량 부족이니 발생하는 에러 및 코드 충돌 등은 다른 포스트도 참조하여 이 과정을 '연습'하는 것을 권장한다.