core.autocrlf를 On 에서 Off로 바꾸기

  • #core_autocrlf
  • 일단 이 답변이 2010년에 답변되었고 2019년에 마지막으로 업데이트 된 것을 주의하자
  • First : git config --global core.autocrlf false 를 실행하라
  • 그 다음에..
    1. 새로운 config setting core.eol (1.7.2+) 를 사용하라
      • 1.7.2+ 는 Git 버전임 (2021년 현재 2.33.1 버전 배포중)
      • git 1.7.2+ 에서 새롭게 적용되는 core.eol 사양은 다음과 같다

        워킹 디렉토리의 텍스트 속성 set을 가진 파일에서 사용할 line ending type을 설정하라 설정가능한 옵션은 lf, crlf, native가 있으며, native는 플랫폼 고유의 line ending을 사용한다 디폴트 값이 native 이다

    2. .gitattribute 파일을 checkout/checking 한다?
      • .gitattrubite 을 경로별로 git 속성을 다르게 설정하는 파일이다

.gitattributes man page 번역

NAME

SYNOPSIS

DESCRIPTION

  • gitattributes 파일은 경로별로 (git의) attributes을 설정할 수있는 간단한 텍스트 파일이다
  • gitattributes 파일의 각 line별 형식은 다음과 같다: 
    

    1

    		

    pattern attr1 attr2 ...
  • 즉, 패턴에 attribtes 목록이 따라오는데, 공백문자로 구분된다
  • 앞쪽과 뒤쪽의 공백문자는 무시된다
  • #으로 시작된 줄 역시 무시된다
  • 이중 따옴표로 시작된 pattern은 C 스타일에서 따온것이다
  • pattern이 문제 경로와 일치하면, 그 줄의 나열된 attributes가 그 경로에 적용된다.
  • 각 attributes는 해당 경로에 대해 아래중 하나의 값을 가진다:
    • Set
      • 그 경로는 해당 attribute에 대해 특정값 true를 가진다
      • 이 경우는 목록에 attributes 이름만 나열함으로써 값이 지정된다
    • Unset
      • 그 경로는 해당 attribute에 대해 특정값 false를 가진다
      • 이 경우는 목록에 해당 attributes의 이름앞에 dash -를 붙여서 나열함으로써 값이 지정된다
    • Set to a value
      • 경로는 해당 attribute에 대해 특정 문자열 값을 가진다
      • 이 경우는 목록에 해당 attributes 명 뒤에 =과 값이 따라오도록 설정함으로써 값이 지정된다
    • Unspecified
      • 패턴과 일치하는 경로가 없고, 해당 경로에 attributes이 있는지 없는지 표시가 없을경우,
      • 해당 경로에대해 attribute는 특정되지 않는다(Unspecified)고 한다
  • pattern이 한 개 이상의 경로와 일치할 경우, 뒷 쪽의 line이 앞 쪽의 line을 덮어쓰는 것(override)으로 간주한다
    • 이 overriding은 attribute 단위로 동작한다
  • Pattern을 경로와 매치하는데 사용되는 규칙은, 몇가지 예외를 빼면 .gitignore 파일과 같다 (이쯤에 .gitignore man page 링크)
    • negative pattern은 금지된다
    • 한 directory에 match된 pattern은 그 directory 아래로 재귀적으로 match되지 않는다
      • 따라서, path/의 trailing-slash 문법은 attribute 파일에서는 의미가 없다; path/**를 대신 사용하라
  • 어떤 attributes 이 경로에 assign 될지 결정할때,
    • Git은 $GIT_DIR/info/attributes 파일을 참조하거나 ( 가장 높은 우선순위를 갖는다)
    • Question상의 경로와 같은 디렉토리의 .gitattributes 파일을 참조하거나
    • 워크 트리의 탑레벨까지의 parents 디렉토리들을 참조한다
      • .gitattributes에 포함된 디렉토리가 question 상의 경로로 부터 멀어질수록, 우선순위도 더 떨어진다
    • 최종적으로는 전역이나 시스템 영역을 파일들을 참조하게된다 (가장 낮은 우선순위를 가진다)
  • .gitattributes 파일이 작업 트리에 없을때는, 인덱스상의 경로가 기본값(fall-back)으로 사용된다
    • checkout 프로세스 동안, index상의 .gitattributes가 사용되고나서 working tree의 파일이 기본값으로 사용된다
  • 한 개의 디렉토리만 적용하고 싶다면 (즉, 한 유저의 workflow상의 특정 리포지토리로 제한된 파일들에 attributes을 지정하는 경우)
    • attribute는 $GIT_DIR/info/attributes 파일에 위치해야 한다
    • 버전 관리가 되야하거나 다른 리포지토리도 배포되어야하는 (즉, 모든 유저가 사용하는 attributes 일 경우) attributes는 .gitattributes 파일에 있어야 한다
  • 한 유저의 모든 리포지토리에 적용되어야 하는 attributes는 core.attributesFile configuration option ( git-config man page 링크 참조)에 설정한다
    • 디폴트값은 $XDG_CONFIG_HOME/git/attributes 이다
    • $XDG_CONFIG_HOME이 설정되지 않거나 비어있다면, $HOME/.config/git/attributes가 대신 사용된다
  • 시스템상의 모든 유저를 위한 Attributes는 $(Prefix)/etc/gitattributes 파일에 위치 한다

EFFECTS

Checking-out and checking-in

text

eol

(간추린 번역) Flutter Design patterns: 18 - Builder

개요

  • 앞선 시리즈에서 , 비교적 복잡하지만 매우 실용적이고 유용한 구조적인 디자인 패턴인 Bridge에 대해 분석했다
  • 이번에는 복잡한 object의 생성을 몇가지 분리된 step들로 나누는 디자인 패턴에 대해 공부한다.
  • 이 생산적인 디자인 패턴은 Buider라고 불린다

What is the Builder design pattern ?

  • GoF book 의 Builder 설명을 잠시 보자

    Separate the construction of a complex object from its representation so that the same construction process can create different representations.

  • 두 부분으로 나눠보자

    Seprate the constructuion of a complex object from its representation…

    • 앞선 디자인 패턴의 개요와 비슷한지만 약간 다르다는 것을, 당신은 눈치챘을 수 있다
      • 즉, abstraction을 representation 에서 분리한다는 것
    • 이번에는, complex한 object의 creation process(logic)을 object(data) 자체에서 분리하는 것이다
    • complex한 지 결정하는 명확한 기준은 없지만,
      • 객체 생성시 단순히 constructor만 호출하는 것으로 끝나지 않는다면 complex하다고 할 수 있다
      • 생성시 추가적으로 파라메터가 필요하거나 추가적인 method가 호출될 때도 complex하다
    • 그럼, 추가적인 parameter나 method가 필요한 complex한 object가 있다고 치고,
      • 도대체 왜, 그 위에 추가적인 추상화 단계가 필요한 거냐?
      • 왜 이 생성 프로세스를 object에서 분리해야 되는 걸까?

    … so that the same construction process can create differe:wnt representations.

    • 좀 더 잘 이해하기 위해 , 집 짓는 것을 예로들자
    • 집 (object)을 지을때, 모든 집의 건설 단계 (build logic)들은 하나같이 비슷하다
      • 모든 집은 기초공사가 필요하고, 층별 바닥, 벽, 문, 창문, 천장들이 필요하다
    • 하지만, 각 단계는 선호하는 방식으로 조정될수 있어, 각각의 최종 결과는 완전히 다르게 보인다
    • 이것이 Builder design pattern의 핵심이다
      • 서로 다른 representation (final result)를 제공하기 위해 생성과정이 조정할 수 있도록
      • 객체 생성 process를 추상화한다
  • Builder design pattern 은
    • object construction code를 해당 class로부터 builder라 불리는 별도의 객체로 이동한다
    • 이런 각각의 builder들은 같은 interface를 따르며 분리된 객체 생성 step들을 구현한다
  • 즉, 객체의 representation을 다르게 하고 싶다면,
    • 그냥 다른 builder class를 생성한후에 이런 생성 step들을 구현하면 된다.
  • 또한, Builder design pattern에는 layer가 하나 더있다 - Director 이다
    • Director는 Builder interface를 하는 간단한 class 이고
    • building step을 어떤 순서로 실행할지 결정한다
    • 이 class는 필수적인 것은 아니고, client code로 부터 제품 생성 세부 사항을 숨기는 역할을 한다
  • Builder design pattern이 꽤 복잡한 것을 알기에
    • 보다 잘 이해하기 위해, analysise와 implementation 단계로 넘어가 보자

Analysis

  • Builder design pattern의 일반적인 구조는 다음과 같다

! Structure of the Builder design patter

  • Builder