오픈소스 컨트리뷰션이 이제 다음주를 기점으로 막바지를 향해 달려가고 있다.
처음에는 현직자 분들이 이렇게나 많은데 한낱 취준생인 내가 기여를 할 수 있을까
하는 생각에 굉장히 소극적으로 임하면서 자신이 없었는데,
지금은 그래도 어느 정도 PR 올리고 fetch하고 다시 push하는 게 익숙해져서 많은 것을 배웠다고 느끼고 있다.
처음 git 실습하면서 rebase할 때 살 떨리던 게 벌써 두 달 전!
(이것도 글을 쓴다쓴다 해놓고선 아직도 작성 중이다)
지금 완전히 git에 대해 정복한 것이라고 말하긴 어렵지만,
그래도 git과 관련된 프로젝트를 하면서 팀 프로젝트 때 만나던 것과는 다른, git의 면모를 볼 수 있었는데,
오늘은 특히나 내가 구현을 맡았던 부분인 git log parse
중에서 <git log>
부분에 대한 글을 적어보려고 한다.
[Githru.v] git log 자동 실행 및 log parse
🌝parseSpawn.ts
import { spawn } from "child_process";
const git = spawn("git", [
"--no-pager",
"log",
"--all",
"--parents",
"--numstat",
"--date-order",
"--pretty=fuller",
"-c",
]);
export default function getGitLog(): Promise<string> {
return new Promise((resolve, reject) => {
let gitLog = "";
git.stdout.on("data", (data) => {
gitLog += data.toString();
});
git.stderr.on("error", (data) => {
console.error(`stderr: ${data}`);
reject(data);
});
git.on("close", () => {
resolve(gitLog);
});
});
}
코드 로직은 다음과 같다.
spawn()
으로 감싸 작성한다.getGitLog()
는 위의 spawn함수를 Promise를 반환하는데 세 가지 파이프라인을 구성하여 resolve 또는 reject한다.spawn().on
으로 resolve하며 끝을 맺어준다.어려워보이지만 전혀 어렵지 않다. git log 명령어의 경우 특히나 많은 줄의 결과값이 터미널에 찍히게 되는데, 이를 비동기로 받아서 git log 문자열을 구성하는 건 아이디어 자체가 어려운 건 아니다.
추후 이야기하겠지만, 실행 환경과 git log 코드 그 자체의 특징때문에 발생한 오류가 있었는데... 미처 생각지도 못한 부분이어서 흥미로운 이슈였다.
(하지만 당시에는 전혀 흥미롭지 않았음)
물론 지식으로의 배울 점도 참 많지만, 무엇보다 태도 측면에서 배울 점도 하나 얻어갔다.
git log와 관련되어 심상치 않은 버그(원인을 바로 파악하기 어려웠던 오류)를 기능 구현 직후에 발견했는데,
어제 회의가 끝나갈 쯤에 팀원분들과 공유했다.
이제 거의 모든 구현이 마무리가 되는 시점에 괜한 차질을 발생시킨 게 아닌가하여 죄송한 마음이 들었지만,
멘토 및 리드 멘티분께서 정말 적극적으로 해당 버그에 관해 원인을 찾기 위해 힘써주셨다.
심지어 회의가 밤 11시가 넘어서 끝났지만 그 이후에 새벽 1시까지 해당 원인을 찾기 위해 여러 시도를 해보고, 해당 시도를 공유하고 탄식하며 마지막엔 기뻐했다.
나는 도중에 너무 피곤해서 언제 갈까 고민만 했었는데,
다들 발생한 문제에 대해 한 마음 한 뜻으로 고민하는 모습들이 정말 멋져 보였다.
이번에 많은 도움을 받았던 리드 멘티 한 분께서는 이렇게 말씀하셨다.
이거 해결될 때까지 잠 못 잘 것 같아요.
이런 분들이 진짜 타고난 개발자들이 아닐까!
혼자 취준생이라며 단계를 낮추고, 나는 현직자들과 급이 다르다며
해결할 수 없을 거라고 무의식적으로 단정짓던 내 지난 모습들에 반성하게 된 밤이었다.
반성하면서 동시에 나도 언젠간 지난 시간을 함께했던 다른 멘티 분들처럼 멋지고 책임감 강한 개발자가 되자는 다짐으로 이 글을 마무리하겠다!