저자는 CSS와 함께한 자신의 여정을 되돌아보며, 처음에는 구조적인 장점 때문에 Tailwind를 채택했지만 이제는 순수 CSS로 전환하고 있습니다. 이러한 변화는 CSS를 더 깊이 이해하고 기술을 향상시키고자 하는 열망에서 비롯되었습니다. 저자는 가져온 리셋, 컴포넌트 기반 스타일링, 미리 정의된 색상 변수, Tailwind에서 파생된 글꼴 크기 시스템을 포함한 새로운 CSS 구조를 자세히 설명합니다. 또한 유틸리티 클래스를 활용하고, 전역 스타일에 대한 기반을 설정하며, 간격을 의식적으로 관리합니다. 반응형 디자인은 Tailwind의 미디어 쿼리 중심 접근 방식에서 벗어나 CSS 그리드 레이아웃에 더 의존합니다. 빌드 시스템은 프로덕션 번들링을 위해 esbuild를 사용하지만, 개발 중에는 필수적이지 않습니다. 저자는 빌드 시스템에 대한 의존성, 향상된 CSS 지식, Tailwind의 한계, 그리고 더 의미론적인 HTML에 대한 열망을 언급하며 마이그레이션의 주요 이유를 설명합니다. 마지막으로 @layer와 같은 기능에 대해 논의하고 Tailwind의 이점을 인정하면서도 그 원칙에서 가치를 찾고 있음을 밝힙니다.

저자는 Tailwind 사용을 중단했지만 편리한 색상 팔레트가 그리웠습니다. 워크플로우 개선을 위해 Tailwind의 색상 시스템에 대한 대안을 모색했습니다. 사용 편의성, 특히 CSS에서의 사용 편의성을 위해 미리 정의된 색상 팔레트를 원했습니다. 저자는 Mastodon에 팔레트 제안을 요청했고 응답을 컴파일하기로 결정했습니다. 이 게시물에는 uchū, flexoki, reasonable colours와 같은 여러 색상 팔레트가 나열되어 있습니다. 다양한 다른 팔레트와 디자인 시스템도 고려할 옵션으로 제공됩니다. 다양한 색상 구성표 생성기가 포함되어 있지만 저자는 사용하기 어렵다고 생각합니다. 색맹 정보 및 oklch CSS 함수를 포함한 추가 색상 도구가 제시됩니다. 저자는 이 리소스가 자신과 CSS 색상 솔루션을 찾는 다른 사람들에게 유용하기를 바랍니다.

저자는 Node.js에 의존하지 않고 프론트엔드 JavaScript를 작성하는 것을 목표로 합니다. 직면한 중요한 과제는 프론트엔드 코드에 대한 효과적인 테스트 방법의 부족입니다. Playwright를 사용한 이전 시도는 느리고 Node.js가 필요하다고 판단되었습니다. 이를 해결하기 위해 저자는 Alex Chan의 미니멀리스트 인브라우저 단위 테스트 프레임워크에 대한 작업을 참고하여 테스트를 브라우저 탭 내에서 직접 실행하는 것을 탐구했습니다. Chan의 접근 방식은 단위 테스트에 중점을 두었지만, 저자는 Node.js 빌드 프로세스 없이 Vue 컴포넌트에 대한 엔드투엔드 통합 테스트를 수행하고자 했습니다. 저자는 테스트 프레임워크로 QUnit을 사용했으며, 디버깅을 위한 "rerun test" 버튼을 높이 평가했습니다. 이 과정에는 Vue 컴포넌트를 전역적으로 노출하여 설정하고, 보이지 않는 페이지 외부 div에 렌더링하는 `mountComponent` 함수를 만드는 것이 포함되었습니다. Fixture 데이터는 전용 엔드포인트로 POST 요청을 보내 데이터베이스를 재설정하여 관리되었습니다. 그런 다음 기본적인 테스트는 컴포넌트를 렌더링하고 해당 내용을 어설션했습니다. 비동기 작업 완료를 기다리는 것이 주요 문제로 대두되었고, 이는 `waitFor()` 함수의 개발로 이어졌습니다. 기다릴 올바른 요소나 조건을 식별하는 것이 어려웠으며, 더 나은 안정성을 위해 애플리케이션을 리팩토링하라는 제안을 유도했습니다. 저자는 또한 요소 식별을 위해 CSS 클래스를 추가하는 것을 실험했으며, Testing Library와 같은 라이브러리가 더 접근 가능한 접근 방식을 권장한다고 언급했습니다. 폼 처리는 단순히 값을 설정하는 것만으로는 충분하지 않았기 때문에 어려움을 겪었습니다. 관련 DOM 이벤트를 디스패치해야 했습니다. 이는 UI 테스트 라이브러리가 이러한 작업을 단순화할 수 있는 이유를 강조했습니다. 테스트 커버리지는 Chrome의 내장 개발자 도구를 사용하여 부분적으로 평가되었지만, 번들링된 JavaScript와 함께 작동하려면 특정 구성 및 작업이 필요했습니다. 학습 곡선에도 불구하고 저자는 이 경험을 즐겁게 여겼으며 자신의 프론트엔드 프로젝트에 대한 자신감 있는 테스트 스위트를 구축하는 것에 대해 낙관적인 태도를 보였습니다. 또한 브라우저 전용 실행과 호환되는 UMD 빌드를 제공하는 Testing Library와 같은 라이브러리를 더 탐구하고 브라우저 우선 테스트를 CI 환경에 통합하는 방법을 고민하고 있습니다.

저자는 man 페이지에서 예시의 유용성에 영감을 받아 `dig` 및 `tcpdump` 도구에 대한 예시를 개선했습니다. 주요 목표는 드물게 사용하거나 초보자인 사용자를 위한 가장 기본적인 예시를 제공하는 것이었습니다. 초보자와 드물게 사용하는 사용자를 대상으로 하는 이러한 접근 방식은 효과적이고 좋은 반응을 얻었습니다. 저자는 검토 과정이 man 페이지 내에서 더 정확한 정보를 찾을 수 있도록 하는 데 가치 있다고 생각했습니다. 그는 패킷을 저장할 때 `-v` 플래그와 같은 유용한 `tcpdump` 기능에 대해 배웠습니다. 문서화에 대한 일반적인 회의론에도 불구하고 저자는 이제 고품질의 정확한 man 페이지의 잠재력에 대해 낙관적입니다. roff를 배우는 것을 피하기 위해 `tcpdump` man 페이지 업데이트를 위해 사용자 정의 markdown-to-roff 스크립트가 만들어졌습니다. 여기에는 Markdown의 추상 구문 트리를 파싱하고 roff 코드를 출력하는 작업이 포함되었습니다. 저자는 또한 roff와 mandoc 프로젝트의 역사와 발전에 대해 탐구했습니다. BSD 및 Linux 시스템 간의 문서화 관행의 기술적 및 문화적 차이에 대한 호기심이 생겼습니다.

"저자는 man 페이지에서 정보를 찾는 데 어려움을 겪은 경험을 바탕으로 man 페이지 개선에 대해 고찰합니다. 빠른 참조를 위해 `perlcheat`에서 볼 수 있는 치트 시트 통합을 고려합니다. `rsync` 및 `strace` man 페이지의 예시에서 영감을 받아 옵션 요약 및 범주별 구성을 제안합니다. 저자는 OpenBSD의 접근 방식과 `curl` man 페이지의 옵션별 예시 전략을 언급하며 예시의 인기를 강조합니다. 또한 `man ascii`에서 볼 수 있는 표 형식의 가치를 강조하여 정보 스캔을 더 쉽게 만듭니다. 저자는 GNU 프로젝트가 man 페이지 대신 "info" 매뉴얼을 사용하는 것과 터미널 기반 man 페이지의 한계를 대조합니다. `tldr.sh` 및 Dash와 같은 도구를 논의하고 제한된 형식 내에서 man 페이지를 개선하는 방법을 숙고합니다. 저자는 특히 예시를 중요하게 생각하지만, 다른 디자인 개선에도 열려 있습니다."

"저자는 성숙한 기술을 배우는 것을 즐기며, 최근 웹사이트 프로젝트에 Django를 사용하기 시작했습니다. `urls.py` 및 `models.py`와 같은 핵심 파일이 있는 Django의 명시적인 구조는 저자가 프로젝트를 쉽게 이해하는 데 도움이 됩니다. Django의 내장 관리자 인터페이스는 쉬운 데이터 관리를 제공하며, ORM은 데이터베이스 상호 작용을 단순화하고 자동 마이그레이션은 데이터베이스 변경을 간소화합니다. 저자는 Django 설명서를 높이 평가하며, 단순성 때문에 소규모 프로젝트에는 SQLite를 사용하는 것을 선호합니다. Django의 "배터리 포함" 접근 방식은 CSRF 보호 및 이메일 구성과 같은 작업을 단순화합니다. 저자는 아직 배우는 중이지만 Django의 기능 세트가 매력적이라고 생각합니다. 설정 파일은 전역적이고 즉각적인 오타 감지가 부족하기 때문에 여전히 다소 부담스럽습니다. 저자는 다른 백엔드를 사용하여 이메일을 설정하는 것을 실험하고 있습니다. 저자는 주로 단일 Go 바이너리 또는 정적 사이트만 작업했기 때문에 Django를 탐색하게 되어 기쁩니다. 저자는 ORM 사용을 장려해 준 Marco Rogers에게 감사하고 있습니다."

저자는 블로그 게시물과 소책자를 쓴 후 Git의 문서를 개선하기로 결정했습니다. 그들은 Marie와 협력하여 객체, 참조, 인덱스와 같은 Git의 핵심 개념을 설명하는 "데이터 모델" 문서를 만들었습니다. 저자는 `git push` 및 `git pull`과 같은 여러 Git man 페이지의 소개 부분을 업데이트했습니다. 그들은 문서 문제를 식별하기 위해 더 증거 기반의 접근 방식이 필요하다는 것을 깨달았습니다. 저자는 Mastodon에서 테스트 독자들에게 기존 문서에 대한 피드백을 요청했습니다. 테스트 독자들은 혼란스러운 용어, 불분명한 문장, 그리고 문서의 불일치를 지적했습니다. 이 피드백은 저자가 `git add`, `git checkout`, `git push`, 그리고 `git pull`에 대한 man 페이지를 개선하는 데 도움이 되었습니다. 저자는 `git push`와 `git pull`에 대한 변경 사항이 가장 흥미로웠으며, "upstream branch"와 "push refspec"에 대한 정의를 포함했습니다. Git에 기여하는 것은 Discord 서버와 GitGitGadget을 사용하는 것을 포함하여 개발 프로세스를 배우는 것을 포함했습니다. 그들은 Git 커뮤니티가 환영하며 많은 기여자의 도움을 받았다고 느꼈습니다. 저자는 또한 메일링 리스트 아카이브를 탐색하기 위해 맞춤형 Git 목록 뷰어를 만들었습니다.

저자는 언어 서버 통합의 용이성에 매료되어 Vim/Neovim에서 텍스트 편집기인 Helix로 전환했습니다. 복잡한 Vim 설정을 수년간 고생한 후 Helix의 내장 기능이 매력적이었습니다. Helix의 검색 및 빠른 참조 기능은 특히 유용하고 감사하게 생각합니다. 저자는 일부 Vim 습관을 조정해야 했지만 Helix의 키 바인딩에 쉽게 적응했습니다. 저자는 Helix의 다중 커서와 버퍼 전환이 Vim의 매크로와 탭보다 선호된다는 것을 발견했습니다. 그러나 저자는 목록의 재정렬 문제와 지속적인 실행 취소 및 자동 다시 로딩 부족을 포함한 몇 가지 불편한 점을 지적합니다. 이러한 좌절에도 불구하고 저자는 예상보다 쉬운 전환을 통해 Helix에 적응했습니다. 편집기의 간단한 구성은 이전 설정의 복잡성에 비해 큰 이점입니다. 저자는 주로 터미널 내에서 Helix를 사용하며 전용 창으로 프로젝트를 구성합니다. 저자는 3개월 사용 후 Helix에 만족하지만 Vim으로 돌아갈 가능성도 열어두고 있습니다.

저자는 "터미널의 비밀 규칙"이라는 새로운 쟁을 출시했습니다. 이 쟁은 터미널이 어떻게 작동하는지 설명하고 터미널 프로그램 사용에 대한 팁과 요령을 제공합니다. 저자는 20년 동안 매일 터미널을 사용했지만 여전히 작동 방식에 대해 많은 오해가 있었습니다. 터미널에는 화살표 키를 이동할 때도 있고 그렇지 않을 때도 있는 등 여러 가지 사소한 불일치가 있습니다. 터미널이 작동하는 "규칙"은 여러 다른 소프트웨어 조각으로 구성되어 있기 때문에 이해하기 어렵습니다. 이 쟁은 터미널의 네 가지 구성 요소(셸, 터미널 에뮬레이터, 프로그램 및 TTY 드라이버)가 어떻게 함께 작동하는지 설명하고 터미널에서 작동하는 방식에 대한 핵심 규칙을 제공합니다. 저자는 셸을 구성하는 방법과 이스케이프 코드를 이해하는 방법을 포함하여 쟁을 쓰는 동안 놀라운 양을 배웠습니다. 이 쟁은 PDF 또는 인쇄 버전으로 구매할 수 있으며, 저자의 모든 쟁을 15개 묶음으로 구매할 수도 있습니다. 저자는 PuTTY를 작성한 기술 검토자와 터미널의 내부 작동을 이해하는 사람을 포함하여 많은 사람들의 도움을 받았습니다. 인쇄 버전은 8월에 배송될 예정이며, 저자는 인쇄할 수량을 결정하기 위해 주문을 기다려야 합니다. 이 쟁은 12달러이며, 저자는 독자들이 터미널을 더 잘 이해하고 사용하는 데 도움이 되기를 바랍니다.

저자는 C 프로그래머는 아니지만, 가끔 소스 코드에서 C/C++ 프로그램을 컴파일해야 합니다. 예전에는 다른 사람에게 프로그램 컴파일을 의존했지만, Mac으로 전환한 이후 직접 컴파일 방법을 배워야 했습니다. C 프로그램을 컴파일하려면, C 컴파일러를 설치하고, 프로그램의 종속성을 설치하며, 필요하다면 ./configure를 실행하고, make를 실행해야 합니다. 저자는 C 컴파일러 설치, 종속성 설치, 그리고 ./configure 실행 방법을 설명합니다. 또한, 종속성 문제나 컴파일러 오류와 같이 컴파일 과정에서 발생할 수 있는 일반적인 문제들을 논의합니다. 저자는 컴파일러와 링커에 플래그를 전달하여 이러한 문제들을 해결하는 방법을 설명합니다. 또한, 특정 파일을 빌드하고, 다른 패키징 시스템이 동일한 C 프로그램을 빌드하는 방식을 살펴보고, 바이너리를 설치하는 방법에 대한 팁을 제공합니다. 저자는 C 프로그래머가 아니더라도 C 프로그램의 기본 작동 방식을 이해하는 것이 유용하다고 결론짓습니다.

ANSI 이스케이프 코드는 터미널 사용성을 향상시키는 데 사용되지만, 완전히 표준화되지 않아 신뢰성 문제를 야기합니다. 저자는 터미널을 연구하는 과정에서 ANSI 이스케이프 코드에 대해 알게 되었고, 이를 둘러싼 표준을 이해하고자 했습니다. 이스케이프 코드는 터미널 에뮬레이터가 프로그램과 통신하는 데 사용되며, 키 입력 및 마우스 움직임을 위한 입력 코드와 텍스트 색상 변경 및 커서 이동과 같은 작업을 위한 출력 코드의 두 가지 유형이 있습니다. 1976년에 발표된 ECMA-48 표준은 이스케이프 코드의 일반적인 형식과 일부 특정 코드를 정의하지만, 완전한 것은 아닙니다. Xterm 제어 시퀀스는 터미널 에뮬레이터에서 널리 구현되었지만 공식 표준은 아닌 또 다른 이스케이프 코드 집합입니다. ncurses에서 관리하는 terminfo 데이터베이스는 다양한 터미널에 대한 이스케이프 코드를 저장하며, 일부 프로그램은 이를 사용하여 어떤 코드를 사용할지 결정합니다. 그러나 일부 프로그램은 terminfo를 사용하지 않고 대부분의 터미널 에뮬레이터에서 작동하는 "단일 공통 집합"의 이스케이프 코드를 직접 코딩합니다. 이 공통 집합이 무엇인지에 대한 명확한 합의는 없지만, VT100, ECMA-48 및 xterm의 코드가 포함될 가능성이 높습니다. 이러한 어려움에도 불구하고 ANSI 이스케이프 코드의 표준화는 더 풍부한 터미널 환경을 가져올 수 있으며, 저자는 더 명확한 표준 환경이 터미널 에뮬레이터 및 응용 프로그램의 혁신을 촉진할 수 있기를 기대합니다.

PATH에 디렉터리를 추가하려면 먼저 사용 중인 셸을 확인해야 하며, 이를 확인하는 방법은 `ps -p $$ -o pid,comm=` 명령어를 실행하는 것입니다. 리눅스의 기본 셸은 bash이며, Mac OS의 기본 셸은 zsh입니다. 다음으로, 셸의 구성 파일을 찾을 필요가 있습니다. 일반적으로 zsh의 경우는 `~/.zshrc`, bash의 경우는 `~/.bashrc`, fish의 경우는 `~/.config/fish/config.fish`입니다. 그러나 bash의 구성 파일은 세 가지 옵션이 있을 수 있습니다. `~/.bashrc`, `~/.bash_profile`, `~/.profile` 중 하나를 사용 중일 수 있으며, 실제로 사용 중인 파일을 확인해야 할 수 있습니다. 셸의 구성 파일을 찾은 후, PATH에 추가할 디렉터리를 확인해야 합니다. 이를 확인하는 방법은 프로그램의 설치 지침을 확인하거나, 설치 프로그램에 특정 명령어를 사용하는 것입니다. 예를 들어 Node/npm의 경우는 `npm config get prefix` 명령어를 사용할 수 있습니다. 정확한 디렉터리를 찾은 후, 해당 디렉터리에서 프로그램을 실행해보기 위해 확인해야 합니다. 다음으로, 셸 구성 파일을 편집하여 PATH에 디렉터리를 추가해야 합니다. 이 구문은 셸에 따라 다르며, bash와 zsh의 경우는 `export PATH=$PATH:~/directory`, fish의 경우는 `set PATH $PATH ~/directory`입니다. 마지막으로, 셸을 다시 시작하여 변경 사항을 적용해야 합니다. 프로그램이 여전히 작동하지 않는 경우, PATH의 시작 부분에 디렉터리를 추가하거나, IDE 또는 cron 작업에서 프로그램을 실행하는 경우에는 PATH에 디렉터리를 추가하는 다른 방법을 사용해야 할 수 있습니다. 추가적으로, 일부 설치 프로그램은 PATH를 자동으로 설정하는 스크립트를 제공할 수 있습니다. 이를 셸 구성 파일에 추가할 수 있습니다. 그러나 PATH에 디렉터리를 수동으로 추가하는 것이 더 좋을 수 있습니다.

단말기 사용과 관련하여 가장 불편한 점에 대한 정보를 수집하기 위해 설문조사를 실시했으며 1600명이 응답했습니다. 응답자는 대부분 숙련 된 사용자였으며 40 %는 21 + 년, 95 %는 최소 4 년 동안 터미널을 사용했습니다. 불만의 상위 범주에는 구문 기억, 터미널 전환, 색상 문제, 키보드 단축키, 복사 및 붙여넣기 문제가 포함되었습니다. 다른 일반적인 불만 사항으로는 검색 가능성, 가파른 학습 곡선, 기록, 잘못된 문서 및 스크롤백 문제가 있습니다. 일부 사용자는 터미널을 사용할 때 불안하거나 무섭다고 언급했으며 다른 사용자는 셸 스크립팅, 일관되지 않은 명령줄 인수 및 성능 문제를 겪었습니다. 설문 조사에 따르면 많은 사용자가 서로 다른 시스템에서 도트 파일을 동기화하고 tmux 탭 및 터미널 탭으로 창을 관리하는 데 어려움을 겪고 있습니다. 일부 사용자는 터미널의 기능에 압도당하고 보다 간소화된 경험을 원한다고 언급했습니다. 설문 조사 결과는 터미널에 대한 잡지 제작을 알리는 데 사용됩니다. 전반적으로 설문 조사는 숙련된 사용자에게도 터미널 사용의 복잡성과 과제를 강조합니다.

글쓴이는 복사/붙여넣기에 대한 다중 라인 지원, 무한 쉘 기록, 24비트 컬러 지원과 같은 기능이 포함된 "현대적" 터미널 경험을 구성하는 요인을 숙고합니다. 이러한 경험을 달성하는 것이 쉘, 터미널 에뮬레이터, 텍스트 편집기를 포함한 관련된 여러 구성 요소로 인해 어려울 수 있다는 점을 인정합니다. 현대적 터미널 경험을 달성하기 위한 글쓴이의 개인적 접근 방식에는 24비트 컬러를 지원하는 터미널 에뮬레이터의 fish shell, 사용자 지정 구성이 적용된 neovim이 포함됩니다. 많은 시간을 구성에 할애하고 싶지 않은 사람들에게 글쓴이는 oh-my-zsh와 함께 fish나 zsh를 사용하고 24비트 컬러를 지원하는 터미널 에뮬레이터와 micro나 helix와 같은 텍스트 편집기를 사용할 것을 제안합니다. 그러나 글쓴이는 이러한 옵션에도 불구하고 쉘, 텍스트 편집기, 개별 애플리케이션에 문제가 있어 현대적 터미널 경험을 얻는 것이 어려울 수 있다는 점에 유의합니다. bash나 zsh와 같은 일반적인 쉘은 만족스러운 경험을 제공하기 위해 사용자 지정이 필요하므로 쉘은 특히 문제가 될 수 있습니다. 텍스트 편집기도 문제가 될 수 있으며 vim이나 emacs와 같은 옵션에는 상당한 구성이 필요하지만 nano는 제한된 경험을 제공합니다. 글쓴이는 개별 애플리케이션도 문제를 일으킬 수 있고, 이러한 문제를 디버깅하는 데 시간이 많이 걸릴 수 있다는 점에 유의합니다. 궁극적으로 글쓴이는 현대적 터미널 경험을 달성하려면 인내, 실험, 그리고 작은 변경을 하고 새로운 도구와 구성에 적응하려는 의지가 필요하다고 결론 내립니다.

터미널의 프로그램들은 표준이 없어도 일관적으로 작동합니다. 예를 들어, 비대화형 프로그램은 Ctrl-C를 눌렀을 때 종료하고, TUI는 'q'를 눌렀을 때 종료하며, REPL은 빈 줄에서 Ctrl-D를 눌렀을 때 종료합니다. 대부분의 프로그램은 readline 키 바인딩을 지원하고, 파이프에 쓰일 때 색상을 비활성화하며, '-'를 stdin/stdout을 의미하는 것으로 사용합니다. 이러한 규칙들은 설명적이지 않고, 명시적이지 않으며, 터미널 프로그램을 효과적으로 사용하는 데 도움이 됩니다.

"버퍼링은 터미널 프로그램에서 성능을 개선하기 위해 출력을 그룹화하는 일반적인 방법입니다. 일정한 크기 임계값에 도달할 때까지 출력을 버퍼링합니다. 이렇게 하면 파이프에 데이터가 느리게 추가되는 경우 문제가 발생할 수 있습니다. 프로그램이 출력을 버퍼링하고 이를 작성하지 않을 수 있습니다. Grep 및 유사한 프로그램은 파이프에 쓰일 때 블록 버퍼링을 기본적으로 사용하지만 터미널에 쓰일 때는 라인 버퍼링을 사용합니다. 따라서 "tail -f /some/log/file | grep thing1 | grep thing2" 명령어가 출력을 표시하지 않는 이유를 설명합니다. grep, sed, awk, tcpdump, jq와 같은 명령어는 출력을 버퍼링합니다. 반면 tail, cat, tee와 같은 명령어는 버퍼링하지 않습니다. C, Python, Ruby, Perl과 같은 프로그래밍 언어도 출력을 버퍼링할 수 있습니다. 이러한 버퍼링을 비활성화하는 다양한 방법이 있습니다. 파이프에서 Ctrl-C를 누르면 프로그램의 출력 버퍼가 손실될 수 있습니다. 신호가 버퍼가 플러시되기 전에 수신되기 때문입니다. 파일로 리디렉션할 때도 버퍼링이 발생하지만 일반적으로 예상대로 작동합니다. 프로그램이 종료되기 전에 버퍼의 내용이 작성됩니다. 버퍼링을 피하려면 프로그램이 빠르게 끝나는지 확인하거나 grep에서 "--line-buffered" 플래그를 사용할 수 있습니다. 명령어를 awk로 다시 작성하거나 stdbuf를 사용하여 프로그램이 터미널에 쓰이는 것처럼 작동하게 할 수도 있습니다. unbuffer를 사용하여 프로그램이 일관된 동작을 수행하게 할 수도 있습니다. 이deal한 솔루션은 특정 상황에 따라 다르며 unbuffer가 일관된 동작을 제공하는 신뢰할 수 있는 선택입니다. 버퍼링은 일반적으로 문제가 되지 않지만 파이프에 데이터가 느리게 추가되는 경우 발생할 수 있습니다. 버퍼링을 비활성화하는 환경 변수가 있으면 유용할 수 있지만, 설계 및 구현에는 도전이 있습니다."

저자는 빌드 시스템 없이 자바스크립트를 작성하는 것을 선호하며, 빌드 시스템 없이 라이브러리를 가져오는 경험을 공유합니다. 저자는 라이브러리가 제공할 수 있는 세 가지 주요 자바스크립트 파일 유형을 설명합니다. 즉, "클래식" 전역 변수 파일, ES 모듈 및 CommonJS 모듈입니다. 저자는 라이브러리의 NPM 빌드에서 파일을 찾는 방법을 보여주고 브라우저에서 ES 모듈을 사용하기 위해 importmaps를 사용하는 방법에 대해 논의합니다. 또한 CommonJS 모듈을 ES 모듈로 변환하기 위해 esm.sh를 사용하는 방법도 언급합니다. 저자는 Chart.js, @atcute/oauth-browser-client 및 @atproto/oauth-client-browser를 사용하는 예를 제공하며 각 예에 대한 다른 접근 방식을 논의합니다. importmaps를 사용하려면 브라우저 지원이 필요하므로 오래된 브라우저에서 문제가 될 수 있다고 주목합니다. 저자는 또한 importmaps의 대안으로 esbuild를 사용하는 방법을 언급합니다. 마지막으로, 저자는 세 가지 유형의 자바스크립트 파일과 이를 식별 및 사용하는 방법을 요약합니다.

저자는 자신의 사이트에 새로운 섹션을 만들었습니다. "TIL" (오늘 배운 것)이라고 불리는 이 섹션은 저자가 소셜 미디어에 게시하는 흥미로운 도구와 사실들을 저장하는 곳입니다. 목표는 전체 블로그 게시물을 작성하지 않고도 이러한 정보를 저장할 수 있는 곳을 만들기 위함입니다. 저자는 종종 마스토돈과 블루스카이에 "멋진 것들"을 게시하지만, 이러한 것들을 추적할 곳이 없었습니다. 이 새로운 섹션은 사이먼 윌리슨의 TIL 블로그에서 영감을 받았지만, 저자의 게시물은 훨씬 짧습니다. 저자는 TIL 섹션을 위한 새로운 폴더를 만들었고, 사용자 정의 스타일링을 추가하고, 별도의 RSS 피드를 설정했습니다. TIL 섹션은 주로 저자의 자신의 용도로, 유용한 링크와 도구를 추적하는 방법입니다. 저자는 이 섹션을 몇 주 동안 사용해 왔고, 잘 작동하는 것을 발견했습니다. 저자는 "POSSE" (자신의 사이트에 게시하고, 다른 곳에 공유)라는 아이디어를 좋아하지만, 자신이 자신의 사이트에 유지하고 싶은 콘텐츠의 특정 카테고리를 식별하는 것이 더 쉽다고 생각합니다. 저자는 블로그 게시물과 만화책에 대한 이메일 목록과 RSS 피드를 가지고 있으며, TIL 게시물의 요약을 자신의 메일링 목록에 추가할 수 있습니다. 저자는 일부 콘텐츠를 일시적(ephemeral)로 유지하는 것을 선호합니다. 예를 들어, 투표와 농담은 일시적이며, 특정 카테고리의 콘텐츠만 보관합니다.

저자는 터미널에서 제어 코드의 개념을 탐구합니다. 예를 들어 Ctrl-A, Ctrl-C, Ctrl-W와 같은 코드들이 어떻게 작동하는지에 대해 설명합니다. ASCII 제어 문자는 33개가 있으며, 운영 체제의 터미널 드라이버가 처리하는 코드, 실제 키 누름에 해당하는 코드, readline에서 사용하는 코드로 분류할 수 있습니다. 저자는 이러한 코드들이 실제 구조 없이 유기적으로 진화했기 때문에 어느 코드가 어느 카테고리에 속하는지에 대한 실제 구조가 없음을 지적합니다. 제어 코드는 총 33개밖에 없으므로 Ctrl-1을 키보드 단축키로 사용하고 싶다면 의미가 없습니다. 왜냐하면 1을 누르는 것과 동일하기 때문입니다. 저자는 Ctrl+Shift+C도 제어 코드가 아니며, 터미널 에뮬레이터에 따라 행동이 다르다고 지적합니다. ASCII 제어 코드의 공식 이름은 실제로 사용되지 않습니다. 왜냐하면 원래 텔레그래프 기계를 위해 정의되었고, 이후 다른 용도로 재사용되었기 때문입니다. 저자는 Ctrl-M과 Ctrl-I를 키보드 단축키로 사용하는 것이 어려움을 느낍니다. 왜냐하면 Enter와 Tab 키와 동일하기 때문입니다. 저자는 다양한 키 조합을 눌렀을 때 보내지는 제어 코드를 확인하는 파이썬 스크립트를 제공합니다. 저자는 Ctrl-W와 Ctrl-U와 같은 일부 제어 코드가 터미널이 표준 모드인지 비표준 모드인지에 따라 다르게 처리될 수 있음을 지적합니다. 마지막으로 저자는 제어 코드와 관련된 많은 예외 사항과 충돌이 있으며, 이러한 모든 정보가 실제로는 유용하지 않을 수 있음을 인정합니다.

'Mess With DNS'의 저자는 프로그램이 메모리가 부족해 OOM(Out-Of-Memory)으로 인해 종료되는 문제를 겪었고, 이로 인해 백업 스크립트에 문제가 발생했습니다. 이를 해결하기 위해 저자는 'Mess With DNS'가 메모리를 덜 사용하도록 하기 위해 시도했습니다. 프로그램은 메모리에 IP 주소 데이터베이스를 로드했는데, 이는 약 117MB의 메모리를 사용하고 있었습니다. 저자는 메모리 사용량을 줄이기 위해 세 가지 다른 접근 방식을 시도했습니다. 첫 번째 접근 방식은 데이터를 디스크에 저장하기 위해 SQLite를 사용하는 것이었습니다. 이는 초기 메모리 목표를 달성했지만 IPv6 주소를 저장하는 문제가 있었고 원래의 이진 검색보다 500배 느렸습니다. 두 번째 접근 방식은 트라이(trie)를 사용하는 것이었습니다. 그러나 이는 더 많은 메모리를 사용했고 원래의 이진 검색보다 느렸습니다. 세 번째 접근 방식은 이름과 국가 필드를 중복 제거하여 배열이 메모리를 덜 사용하도록 하는 것이었습니다. 이는 메모리 사용량을 117MB에서 65MB로 줄였고, netip.Addr 대신 net.IP를 사용하여 추가로 20MB의 메모리를 절약하여 총 46MB로 줄였습니다. 저자는 총 70MB의 메모리를 절약할 수 있었습니다.

블로그 게시물 작성자는 이전 버전이 잘 작동함에도 불구하고 Hugo 버전을 0.40에서 0.135로 업그레이드하기로 했습니다. 그들은 템플릿 호출 대체, 페이지 참조 업데이트, 테마의 "다음"과 "이전"의 의미 바꾸기 등의 업그레이드 과정에서 필요한 변경 사항을 문서화했습니다. 작성자는 또한 이전의 Blackfriday 렌더러를 대체한 새로운 Goldmark 렌더러에서 작동하도록 Markdown 파일을 업데이트해야 했습니다. 여기에는 Markdown을 작성하는 방법을 변경하는 것도 포함됩니다. 예를 들어, HTML과 Markdown 섞기, 꺾쇠 따옴표 사용, 중첩 목록 들여쓰기 등이 있습니다. 또한 작성자는 코드 강조 표시를 해제하고 제목 ID 생성에 이전 방법을 사용하도록 Goldmark 렌더러를 구성해야 했습니다. 그들은 Blackfriday와 Goldmark 렌더러의 출력을 비교하는 스크립트를 작성하여 문제를 파악하고 Markdown 파일에 있는 문제를 수정했습니다. 작성자는 업그레이드 과정이 시간이 많이 들고 어려움이 없지 않았지만 궁극적으로는 보다 미래 지향적인 Markdown 렌더러를 갖게 된 것이 가치가 있었다고 생각합니다. 또한 여전히 이전 버전의 Hugo를 사용 중인 다른 사이트 wizardzines.com을 업그레이드할 때도 비슷한 변경 사항을 해야 할 가능성이 있다고 언급했습니다.

Fish는 사용자 경험을 향상시키는 다양한 주요 기능을 제공하는 인기 있는 셸입니다. 이러한 기능에는 자동 역사 제안, 스마트 자동 완성, 멀티 라인 명령어의 쉬운 붙여넣기, 사용자 친화적인 탭 완성 인터페이스 및 깃 통합이 있는 잘 설계된 기본 프롬프트가 포함됩니다. Fish는 또한 검색 기능이 있는 포괄적인 역사 시스템, 터미널 손상 방지, 글로벌 경로 수정 유틸리티, 존재하지 않는 명령어에 대한 구문 강조 표시를 제공합니다. 또한 Fish는 간소화된 루프 구문, 멀티 라인 편집을 용이하게 하며, 단어 탐색을 위한 편리한 Ctrl+왼쪽/오른쪽 화살표 키 단축키를 제공합니다. Fish와 특정 도구를 통합하는 방법에 대한 제한된 지침이 있을 수 있지만, Fish는 점점 더 널리 받아들여지고 있으며, 필요한 경우 POSIX 셸로 돌아갈 수 있습니다. Fish는 최소한의 구성, 기본 설정을 높이 평가하고, 직관적이고 기능이 풍부한 설계를 원하는 사람에게 특히 적합합니다.

"Mess With DNS는 DNS 기능을 학습하는 플랫폼으로, 레코드 생성 및 편집을 통해 작동합니다. 원래 DNS 구현에는 제약이 있었는데, 밑줄이 포함된 도메인 이름이 허용되지 않았고, CNAME 레코드 지원이 없었으며, SVCB 및 HTTPS 레코드 유형이 없었

저자, 캐주얼한 Go 프로그래머, 할당 중 구조체가 복사되는 방식에 대한 기본적인 오해를 드러내는 버그를 마주쳤다. 구조체가 할당 중 복사되는 것이 아니라 참조되는 것임을 알지 못했기 때문이었다. 이러한 행동은 예상치 못한 결과를 초래했는데, 변수에 할당된 후 구조체를 수정했을 때였다. 저자는 다른 언어에서 변수가 일반적으로 참조로 전달되는 경험이 있었기 때문에 이러한 행동에 놀랐다. 함수 인수에서 pass-by-value와 pass-by-reference의 차이를 이해했지만 변수 할당에 이를 확장하지 않았다. 저자는 또한 Go에서 하위 슬라이스가 원래 슬라이스와 동일한 백킹 배열을 공유하는 것을 발견했는데, 이는 하위 슬라이스에 추가하는 것이 원래 슬라이스를 의도치 않게 수정할 수 있음을 의미한다. 저자는 또한 Go 메서드에서 값 수신자와 포인터 수신자 사이의 차이를 분명하게 이해했는데, 메서드가 호출된 구조체를 변경해야 하는 경우 포인터 수신자가 필요함을 알게 되었다. 저자는 "100 Go Mistakes" 리소스를 그들의 분명하고 간결한 형식으로 인해 칭찬했는데, 이는 저자가 Go의 일반적인 함정들을 쉽게 확인하고 배울 수 있도록 했다. 마지막으로 저자는 "Go by Example," "go.dev/play," 및 "staticcheck"와 "golangci-lint"와 같은 정적 분석 도구를 포함하여 다른 가치 있는 Go 리소스들을 나열했다.

터미널에서 텍스트를 입력하는 것은 프로그램 간의 불일치로 인해 어려울 수 있습니다. 기본 기능인 화살표 키조차 지원되지 않을 수 있습니다. Readline은 텍스트 편집 기능을 제공하는 라이브러리이고 다양한 키보드 단축키를 지원합니다. Readline 지원이 없는 프로그램은 rlwrap을 사용하여 개선할 수 있습니다. 일부 프로그램은 readline을 모방하거나 추가 기능을 제공하는 사용자 지정 입력 시스템을 사용합니다. 사용 중인 입력 시스템을 이해하면 예측 가능성이 향상됩니다. 일반적인 단축키로는 Ctrl+A가 행의 시작, Ctrl+E가 행의 끝, Ctrl+R이 역사 검색을 위한 것입니다. 많은 셸은 대체 입력 모드인 vi 키바인딩을 지원합니다. 입력 시스템을 진단하는 것은 (입력 시스템이 없는 경우, readline, 또는 사용자 지정) 사용할 수 있는 기능을 맞춤화하는 것을 허용합니다. 그러나 이 요약에서는 터미널에서 텍스트 입력과 관련된 추가 복잡성이 다루어지지 않습니다.

작업 제어은 셸의 기능으로 프로세스를 전경, 배경 및 중단된 세 가지 상태로 관리할 수 있도록 허용합니다. fg, bg, Ctrl+z, jobs, kill, disown 및 wait와 같은 명령이 포함됩니다. Fish, bash 및 zsh 모두 작업 제어을 지원하지만 각 셸에서 이를 다르게 사용할 수 있습니다. 일부 사람들은 터미널 탭을 사용하는 것보다 작업 제어을 선호하는 경우가 있습니다. 왜냐하면 모든 터미널을 화면에 동시에 표시할 수 있기 때문입니다. 작업 제어은 Ctrl+C에 응답하지 않는 프로세스를 죽이는 것, 배경에서 GUI 앱 또는 CPU를 많이 사용하는 프로그램을 실행하는 것, 여러 명령에 대한 환경 변수를 설정하는 등 다양한 상황에서 유용할 수 있습니다. 작업 제어은 또한 싱글 사용자 모드에서 있거나 tmux 또는 스크린 없이 SSH로 접근한 기기에서 필요할 수 있습니다.

"How Git Works"는 인기 있는 버전 관리 시스템인 Git을 이해하기 쉽게 설명하는 Julia Evans의 새로운 진입니다. 이 진은 수년간 Git을 사용해 왔지만 여전히 어려움을 겪고 있는 사용자를 대상으로 일반적인 오해를 명확히 하고 내부 논리를 더 깊이 이해하는 것을 목표로 합니다. Evans는 Git의 용어, 오류 메시지, 일관되지 않은 동작의 혼란스러운 특성을 인정하지만 이러한 문제를 처리하는 것은 경험을 통해 일상적인 일이 될 수 있다고 강조합니다. 이 진은 사용자 인터페이스 동작과 내부 Git 프로세스와의 관계에 중점을 두어 내부에 대한 지나친 강조를 피하고 있습니다. 또한 인쇄 가능한 치트 시트와 접근성을 위한 HTML 스크립트도 포함되어 있습니다. Git의 복잡성을 강조하면서도 Evans는 이 도구의 속도, 이전 버전과의 호환성, 무료 호스팅 옵션의 가용성을 높이 평가하며 여전히 열렬한 애정을 드러내고 있습니다. 이 진의 제작에는 명확한 설명을 제공한 Marie Claire LeBlanc Flanagan, 표지 디자인을 담당한 블라디미르 카시코비치, 피드백을 제공한 66명의 베타 독자 등 다양한 개인과의 협력이 있었습니다. 진은 PDF 또는 인쇄본으로 구매할 수 있으며, 인쇄본은 7월에 배송됩니다.

Git 오류 메시지는 특히 초심자에게 혼란스러울 수 있습니다. 저자는 일반적인 오류 메시지 몇 가지를 분석하여 그 복잡성을 강조하고 실제적인 해결책을 제안합니다. 이러한 메시지를 개선하는 데 있어 실제로 변경이 유익한지 판단하는 것이 어려운 점이 있습니다. 저자는 Git 유지 관리가 복잡하다는 점을 지적하며, 국제 번역 및 개선 노력에 대한 제한된 자금과 같은 요소를 언급합니다. 그러나 오류 메시지를 개선하는 방법으로는 분기된 브랜치와 뒤처진 브랜치 사이의 분명한 구별을 제공하고, 분기된 브랜치를 조정할 때 사용자에게 제시되는 엄청난 옵션 수를 줄이는 것을 포함할 수 있습니다. 또한 저자는 Git의 내부 논리, 예를 들어 명령어 `git checkout`의 맥락에서 브랜치와 경로 사이의 차이를 이해하는 것이 중요하다고 강조합니다. 이러한 미묘한 차이를 이해하면 사용자는 오류 메시지를 더 잘 해석하고 Git의 명령줄 인터페이스를 효과적으로 탐색할 수 있습니다.

저자는 작은 선인장을 뜨개질하는 등 컴퓨터 이외의 취미에 도전하고 있습니다. 자신이 사용한 패턴, 실의 종류, 기법 등 자신의 경험을 공유합니다. 처음에는 무료 패턴을 사용했지만 지금은 크리에이터를 지원하기 위해 패턴을 구매하는 것을 선호합니다. 이들은 패턴을 수정하고 실수를 학습의 기회로 받아들이는 기쁨을 강조합니다. 안전핀 대신 눈을 자수하고 자투리 실을 스티치 마커로 사용하여 과정을 단순화합니다. 저자는 크로 셰 뜨개질에서 수를 세는 데 어려움을 겪지만 시각적 검사와 근사치를 통해 이를 극복하는 방법을 찾습니다. 메리노, 면, 아크릴로 실험하면서 다양한 실의 무게와 브랜드를 탐구했습니다. 선인장 프로젝트에서는 후크 크기가 덜 중요해 보입니다. 저자는 기본 스티치를 배우고 패턴을 시작하고 YouTube 동영상에서 지침을 찾아 새로운 스티치에 접근했습니다. 코끼리, 선인장, 진행 중인 마우스 등의 아이템을 만들었습니다. 저자는 크로 셰 뜨개질의 촉각적 특성, 사회적 측면, 재료에 필요한 최소한의 공간에 대해 높이 평가합니다. 또한 크로 셰 뜨개질의 용서를 강조하여 실험과 실수를 포용할 수 있다고 말합니다.

저자는 Git에 대한 사람들의 사용 방식과 인식을 조사하기 위해 Mastodon에서 설문조사를 진행했습니다. 놀라운 결과를 얻었습니다. 가장 일반적인 병합 전략은 "병합"으로, "재베이스"를 자주 사용하는 사람은 30%에 불과합니다. 가끔씩 충돌이 발생하지만, 최근 몇 년 동안 Git 문제로 작업을 잃은 사람은 14%에 불과합니다. 많은 사용자가 "HEAD", "ref", "fast-forward"와 같은 용어에 익숙하지 않아 저자는 이러한 용어 사용에 주의를 기울었습니다. 흥미롭게도, 대부분의 사용자는 Git을 SVN보다 선호하며, Git과 Mercurial 사이에는 선호도가 분할되어 있습니다. 특히 71%의 사용자가 셸 프롬프트에 현재 브랜치를 표시합니다. 저자는 Git 개념인 커밋, 브랜치, Git 환경에 대한 설문조사 결과를 공유하여 사용자의 인식과 선호도를 제공합니다.

Git에서 '현재 분기'라는 개념은 가까이 들여다보면 모호성을 보여준다. Git 용어집에서 .git/HEAD 파일의 내용으로 정의되지만, 'git status' 출력, 마지막으로 체크아웃한 분기, 쉘 프롬프트 등 다른 해석들도 있다. 이러한 해석들은 일반적으로 일치하지만, 분리된 HEAD 상태, 태그 체크아웃, 리베이스 중인 상황 등에서 다르다. 예를 들어 태그를 체크아웃하면 .git/HEAD에는 커밋 ID가 저장되지만, 'git status'는 사용자 편의를 위해 태그 이름을 표시한다. 리베이스 중에는 'git status'가 리베이스 상태를 강조표시하지만, 쉘 프롬프트는 원래의 분기를 나타낸다. 심지어 'git init'에서도 '현재 분기'가 명시적으로 체크아웃하지 않고도 자동으로 설정된다. bare 저장소에서는 'git status'와 'git checkout'이 작동하지 않아 추가적인 복잡성이 발생한다. 이러한 불일치점들은 '현재 분기'를 엄격하게 정의하는 제약을 보여주고, 문맥에 따른 이해의 중요성을 강조한다. '현재 분기'가 새로운 커밋의 대상이라고 일반적으로 생각되지만, 리베이스 중에는 최종적으로 원래의 분기에 커밋이 랜딩하는 경우에는 그러하지 않다. '현재 분기'가 Git 작업의 문맥을 나타낸다고 생각하는 것은 타당하지만, bare 저장소에서 'git status'가 다르게 작동하는 등 불일치점들이 있다. 최종적으로 '현재 분기'의 모호성을 이해하려면 .git/HEAD, 'git status' 출력, 마지막 체크아웃 액션 등 다양한 지표를 고려해야 한다.

기사의 저자는 Mastodon에서 HEAD가 Git에서 어떻게 작동하는지에 대한 이해에 대한 설문조사를 진행했는데, 많은 사람들이 불확신하거나 전혀 알지 못하는 것으로 나타났다. 저자는 처음에는 HEAD가 직관적이고 간단한 주제라고 생각했지만, 다른 사람들과의 후속 대화 후에 그것이 그들이 이해하는 것보다 훨씬 더 복잡하다는 것을 알게 되었다. HEAD는 다양한 것들을 참조할 수 있는데, .git/HEAD 파일, git show HEAD와 같은 명령어에서 "revision parameter" HEAD, Git의 출력에서 HEAD가 사용되는 다양한 방식들이 포함된다. .git/HEAD 파일은 브랜치의 이름이나 커밋 ID를 포함하고 Git에서 현재 브랜치를 결정한다. .git/HEAD가 커밋 ID를 포함하고 있다면, Git은 이를 "detached HEAD state"라고 부르며, 이는 현재 브랜치가 없음을 의미한다. 분리된 HEAD 상태에서 새로운 커밋은 어떤 브랜치에도 연결되지 않으며 찾기 어려울 수 있거나 Git의 가비지 수집에 의해 삭제될 수 있다. 저자는 git status, git log, 병합 충돌과 같은 다양한 Git 명령어의 출력에서 HEAD를 해석하는 방법을 설명하고, Git의 HEAD 관련 용어를 더 일관적이고 직관적으로 만들 수 있다고 제안한다.

- 풀 처리: 업스트림 브랜치가 분기할 때 병합 커밋을 피하기 위해 `pull.ff only` 또는 `pull.rebase true`를 사용합니다. - 병합 충돌 가독성: `merge.conflictstyle zdiff3`은 병합 충돌의 가시성을 높이기 위해 중간에 원래 코드를 표시합니다. - 자동 커밋 수정: `rebase.autosquash true`는 리베이스 중에 `fixup!` 커밋을 대상과 결합합니다. - 자동 스테이싱: `rebase.autostash true`는 리베이스 전에 및 후에 `git stash`를 실행합니다. - 푸시 자동화: `push.default current` 또는 `push.default simple`은 현재 브랜치를 일치하는 원격 브랜치에 푸시합니다. `push.autoSetupRemote true`는 첫 번째 푸시에 추적을 설정합니다. - 기본 브랜치: `init.defaultBranch main`은 새로운 저장소에서 `main` 브랜치를 생성하여 `master` 브랜치 대신 사용합니다. - 커밋 메시지 개선: `commit.verbose true`은 커밋 메시지 편집기에서 커밋 차이를 표시합니다. - 충돌 해결 자동화: `rerere.enabled true`은 병합 충돌 해결을 기억하고 자동화합니다. - 오타 수정: `help.autocorrect 10`은 Git이 오타 수정을 실행하는 데 일정한 지연을 허용합니다. - 차이점 시각화: `core.pager delta`는 구문 강조 표시하는 차이점 뷰어를 사용합니다. `diff.algorithm histogram`은 함수 재정렬 가시성을 개선합니다. - 글로벌 Gitignore: `core.excludesfile`은 글로벌 gitignore 파일을 지정합니다. - 별도의 Git 구성: `includeIf`는 개인 및 직장 저장소에 대한 다른 구성들을 허용합니다. - 데이터 손상 방지: `transfer.fsckobjects` 및 관련 설정은 데이터 손상을 감지하고 방지합니다. - 기타 주목할만한 옵션: 블라임 무시, 브랜치 정렬, 색상 설정, 에디터 선택, 커밋 정리, 코어 설정, 차이점 도구, 병합 설정, 태그 추적 푸시, 리베이스 안전, 로그 날짜 형식 등입니다.

분기된 가지가 발생하는 것은 로컬 브랜치와 원격 브랜치가 서로 다른 역사(히스토리)를 가지고 있을 때입니다. 분기 인식을 확인하는 것은 중요하며, 이를 확인하는 방법으로는 `git status`, `git push`, `git pull`이 있습니다. 분기 해소를 위해서는 상황에 따라 다릅니다. 하나의 방법은 `git pull --rebase`를 사용하여 양쪽 변경 사항을 모두 유지하는 것입니다. 원격 변경 사항을 삭제하려면 `git push --force`를 사용하지만, 추가 안전성을 위해 `git push --force-with-lease`를 사용할 수 있습니다. 또는 로컬 변경 사항을 덮어쓰려면 `git reset --hard origin/main`을 사용할 수 있습니다. 이러한 해결책은 워크플로우와 상황에 따라 분기 해소를 위한 옵션을 제공합니다.

.git 디렉터리는 Git에서 버전 제어에 필요한 기본 정보를 포함합니다. HEAD는 현재 브랜치에 지적합니다. 브랜치, 커밋, 트리, 블롭은 Git의 핵심을 형성하여 커밋 기록, 파일 목록, 실제 코드를 각각 저장합니다. 리포지토리 로그는 브랜치, 태그, HEAD의 변경을 추적합니다. 원격 추적 브랜치는 원격 브랜치의 최신 커밋을 유지하고, 태그는 특정 커밋을 표시합니다. 스태시 저장소는 커밋되지 않은 변경을 저장합니다. .git/config에는 저장소 설정이 포함됩니다. 후크를 사용하여 커밋 전에 자동화된 작업을 수행할 수 있습니다. 스테이징 영역(인덱스)은 파일을 커밋 준비 상태로 만듭니다. 이 개요는 .git 디렉터리에 대한 일반적인 이해를 제공하지만, 모든 복잡성을 다루지는 않습니다.

Git 커밋을 이해하는 것은 복잡하고, 사람들은 다양한 정신 모델을 가지고 있습니다. 설문 조사에 따르면 51%는 커밋을 버전 간의 변경(diffs)으로 생각하고, 42%는 파일의 현재 상태인 스냅샷으로 생각하며, 오직 4%만이 이전 커밋의 역사로 생각합니다. 내부적으로 Git은 커밋을 스냅샷으로 저장하여 체크아웃 시간을 더 빠르게 합니다. 그러나 공간을 절약하기 위해 델타(differences)로 파일을 저장하는 팩파일도 사용합니다. 이 스냅샷 기반 구현에도 불구하고 Git은 델타에서 스냅샷을 재구성하여 비교하는 방식으로 차이를 계산합니다. 일반적인 "잘못된" 정신 모델은 이전 커밋에서부터의 차이로 커밋을 인식하는 것입니다. 이는 정확하지 않지만, 일상적인 사용에서 여전히 유용할 수 있습니다. 가장 일반적인 정신 모델은 코드 변경에 초점을 맞추는 차이로 커밋을 고려하는 것입니다. 다른 모델, 예를 들어 스냅샷,은 파일 이동 및 병합 커밋을 이해하는 데 유용합니다. 또한, 사람들은 커밋과 추가 정보(예: 이메일, 대화)를 연관시키거나 "전" 및 "후" 상태로 바라보는 경우도 있습니다.

Ansible을 사용할 때 임의 변경 문제에 직면하여, 저자는 서버에 NixOS를 설치하기로 결정했습니다. NixOS는 패키지 및 사용자에 대한 더 많은 제어를 제공했습니다. NixOS 설치 과정은 nixos-infect를 사용하여 시작했으며, 생성된 구성 파일을 복사하고, flake를 생성하고, nixos-rebuild를 사용하여 변경 사항을 배포했습니다. 서버에서 Go 서비스를 실행하려면 저자는 .nix 파일 하나에 서비스 구성 정의를 정의했습니다. 이렇게 하면 동적 사용자 생성 및 지속적인 저장이 가능했습니다. Nix 언어 구문이 복잡하다는 점에도 불구하고, 저자는 NixOS가 제공하는 안정성 및 중앙 집중식 구성 관리를 높이 평가했습니다. 그러나 nixos-rebuild 동안 수행되는 특정 확인 사항과 서비스 업데이트를 배포하는 스트림 라인 워크플로우에 대한 질문이 남아 있습니다. 전반적으로 저자는 NixOS를_promising_하다고 생각하지만, 구문 디버깅 및 학습에 직면하는 도전 과제를 경험했습니다.

올해 저자는 정수와 부동 소수점이 메모리에서 어떻게 표현되는지 설명하는 지네(zine)를 출판하는 작업에 집중했습니다. 또한 변수들이 메모리에서 어떻게 표현되는지 시각화하는 도구인 "메모리 스파이"를 만들었습니다. 정수 표현 실험을 위한 놀이터인 "정수.노출"도 출시되었습니다. 대규모 프로젝트에서 저자는 파이썬을 사용하여 네트워크 스택을 구현하는 방법을 보여주는 데 목표를 두었습니다. 이 프로젝트의 첫 번째 부분인 "주말에 DNS 구현"은 출시되어 다양한 언어에서 수많은 구현을 유발했습니다. 저자는 어려운 개념을 접근 가능하게 하는 방법에 대한 키노트 연설을 하였습니다. 또한 Git 관련 블로그 포스트와 프로토타입을 여러 개 개발했는데, "git-commit-folders"와 "git-oops"가 포함됩니다. 저자는 사업의 물류를 관리하는 운영 관리자를 고용하여 글쓰기와 코딩에 집중할 수 있었습니다. 또한 Mastodon으로 이주하여 기술적 논의에 더 적합한 플랫폼을 찾았습니다. 저자는 프로젝트를 완성하는 데 필요한 도전을 인정하면서, 프로젝트들이 예상보다 더 오래 걸리는 경우가 많음을 인정합니다. 저자가 이러한 독특한 작업을 추구할 수 있도록 지원하는 것에 대해 감사합니다.

- "git-commit-folders" 프로젝트는 Git 커밋을 폴더로 마운트하여 시각화하는 새로운 접근 방식을 제공합니다. - 지원되는 파일시스템은 FUSE, NFS 및 WebDAV이며, WebDAV는 심볼릭 링크를 지원하지 않기 때문에 NFS에 중점을 두고 있습니다. - 구현을 동기화하기 위해 NFS 및 WebDAV용 어댑터를 갖춘 핵심 FS 인터페이스가 만들어졌습니다. - 리포지토리의 수많은 커밋은 접두사별로 폴더로 구성하고 패킹된 커밋 해시를 캐싱하여 관리합니다. - 디버깅에는 Wireshark로 NFS 패킷을 분석하고 "디렉터리가 아님" 및 "오래된 파일 핸들"과 같은 오류를 처리하는 작업이 포함되었습니다. - 이노드 번호는 루프를 피하기 위해 파일 경로를 해싱하여 생성했습니다. - "branch_histories" 디렉터리에는 현재 각 브랜치에 대한 최신 커밋 100개만 표시됩니다. - 서브모듈은 현재 무시됩니다. - NFSv4 지원은 가능하지만 NFSv3에 비해 어떤 이점이 있는지 명확하지 않다. - 이 프로젝트는 커밋을 폴더로 표현하여 Git의 내부 구조를 보다 직관적으로 이해하는 것을 목표로 합니다.

많은 사람들이 직관적으로 Git 브랜치를 부모 브랜치에서 갈라진 것처럼 인지합니다. 그러나 Git은 내부적으로 브랜치를 이전 모든 커밋의 완전한 역사로 정의합니다. 즉, 모든 브랜치가 동일한 완전한 역사를 포함합니다. 내부적으로 브랜치는 최신 커밋 ID를 포함하는 텍스트 파일로 저장됩니다. Git은 브랜치 간의 관계 개념이 부족하지만, 리베이스, 머지 및 GitHub 풀 리퀘스트가 작동하는 방식과 직관적 모델이 일치합니다. 그러나 Git의 브랜치 간의 계층 구조 부족과 갈라진 커밋을 격리하는 비정규 UI는 혼란스러울 수 있습니다. GitHub의 기본 브랜치는 특별한 특권을 가지고 있으므로, Git의 계층 구조 중립성에도 불구하고 '특별한 브랜치' 개념을 강조합니다.

저자는 처음에는 Nix flakes에 대해 회의적이었지만, Docker 컨테이너와의 유사성을 통해 이해를 높이기 위해 여정을 시작했습니다. flakes의 재현성 및 의존성 관리에서 우수성을 인정하면서도, 저자는 중앙 집중식 시스템 패키지 목록을 유지하는 데 flakes를 사용하여 시스템 설정 및 소프트웨어 제거에서 이점을 찾고자 했습니다. Git 저장소의 추적되지 않은 파일, 자유롭지 않은 패키지 포함, 상대 경로 문제 해결 등 다양한 도전을 겪었습니다. 'nix develop' 및 'buildEnv'를 사용하여 원하는 패키지를 나타내는 심볼릭 링크 디렉터리를 성공적으로 생성했습니다. 그러나 이 과정은 쉽지 않았습니다. 빌드 후크와 관련된 오류가 진행을 방해했습니다. 어려움에도 불구하고 저자는 flakes를 더 잘 이해하고 Nix 패키지 관리 워크플로우를 개선하는 데 있어 더 나은 접근 방식을 찾고자했습니다. 저자는 flakes에 대한 기존 설명이 이해하기 어려웠고, 대신 실제 실험을 통해 이해를 높이게 되었습니다. 저자의 초기 flakes 탐험은 도전이 있었습니다. 그러나 Nix 패키지 관리 경험을 더 견고하고 효율적으로 만들고자 하는 열망을 보여줍니다.

저자는 초기에 git cherry-pick을 단순한 패치 적용으로 오해했지만, 실제로는 "3-way merge"라는 더 정교한 프로세스를 통해 작동하는 것을 알게 되었다. 패치 방법으로 병합 충돌을 해결하려고 했을 때 실패한 경험에서 이러한 오해가 발생했는데, 예상했던 git cherry-pick의 동작 방식과는 달랐다. 이를 조사하는 과정에서 git의 소스 코드를 살펴보게 되었고, cherry-pick이 3-way merge를 사용하는 것을 알게 되었다. 당시 저자는 3-way merge라는 개념에 익숙하지 않았다. 이러한 개념은 두 파일을 병합하는 데 사용되는 방식으로, 이를 통해 파일의 원래 버전(베이스)과 비교하여 병합을 수행하게 된다. 이러한 개념은 패치 적용에까지 확장되어, 커밋 전후의 파일 버전과 현재 파일이 병합에 사용되는 세 가지 버전을 구성하게 된다. Cherry-pick, rebase, revert 모두 이 3-way merge 전략을 사용하지만, 베이스와 타겟 버전의 순서와 해석 방식에서 차이가 있다. 저자는 이 기술을 "3-way 패치"라고 명명하여, 병합에 대한 더 많은 문맥을 제공하는 장점을 강조했다. 일반적인 패치를 처리하는 git apply도 --3way 플래그를 제공하여 3-way 병합을 수행할 수 있다. 이러한 탐험은 git에서 패치를 적용하는 데 사용되는 3-way 병합의 지혜를 강조하며, 사용자들이 익숙한 "패치 적용" 개념에 머물러 있으면서도 다양한 작업을 수행할 수 있는 통일된 접근 방식을 제공한다. 저자는 git의 병합 메커니즘의 복잡성을 인정하면서, 재귀적 병합 및 다중 병합 알고리즘과 같은 개념을 암시하고, 더 많은 탐험을 위해 "Building Git" 책을 추천했다. 마지막으로 저자는 git의 패치 메커니즘의 우아한 설계에 대한 감사를 표하며, 그 직관성과 효율성을 칭찬했다.