침착하게 차분하게

Apache Tomcat 9.0 서블릿/JSP 컨테이너 실행

Apache Tomcat 9.0에는 Java Standard Edition Runtime Environment(JRE 버전 8 이상)이 필요합니다.

JRE 8 이상으로 실행

1. JRE(Java SE Runtime Environment) 다운로드 및 설치

• 자바 SE 런타임 환경(JRE) 다운로드, 릴리스 버전 8 이상
• 패키지에 포함된 지침에 따라 JRE를 설치합니다.
• JRE 대신에 JDK(Java Development Kit)를 사용할 수도 있습니다.

2. 아파치 톰캣 다운로드 및 설치

• Tomcat의 바이너리 배포판을 다운로드합니다.
• 바이너리 배포판의 압축을 풀어 줍니다. (관습적으로 "apache-tomcat-[version]" 이름을 가집니다.)
• 이 문서의 나머지 부분에서 "CATALINA_HOME" 환경 변수는 해당 파일("apache-tomcat-[version]")의 전체 경로를 참조하는 데 사용됩니다.

3. 환경 변수 구성

Tomcat은 Java 애플리케이션이며 환경 변수를 직접 사용하지 않습니다.
환경 변수는 Tomcat startup 스크립트에서 사용됩니다.

스크립트는 Tomcat을 시작하는 명령을 준비하기 위한 환경 변수를 사용합니다.

• CATALINA_HOME(필수) 및 CATALINA_BASE(선택) 설정하기
  
  • CATALINA_HOME 환경 변수는 Tomcat의 "바이너리" 배포판의 루트 디렉토리 경로를 설정한다.
  • Tomcat startup 스크립트는 위 환경 변수가 설정되지 않았을 경우, startup 스크립트의 경로를 기반으로 환경 변수를 자동으로 설정하는 몇 가지 논리가 있습니다. 모든 상황에서 논리가 작동하지 않을 수 있기 때문에 변수를 명시적으로 설정하는 것이 좋습니다.
  • CATALINA_BASE 환경 변수는 Tomcat의 "active configuration" 루트 디렉토리의 위치를 ​​지정합니다. 선택 사항이며 기본은 CATALINA_HOME과 동일합니다.
  • CATALINA_HOME 및 CATALINA_BASE 변수에 별개의 값을 사용하는 것은 추가 업그레이드 및 유지 관리를 단순화하기 위해 권장됩니다.
• JRE_HOME 또는 JAVA_HOME 설정(필수)
  
  • 이 변수는 Tomcat을 시작하는 데 사용되는 Java Runtime Environment 또는 Java Development Kit의 위치를 ​​지정하는 데 사용됩니다.
    JRE_HOME 변수는 JRE의 위치를, JAVA_HOME 변수는 JDK의 위치를 ​​지정하는 데 사용됩니다.
  • JAVA_HOME을 사용하면 추가적인 시작 옵션을 제공합니다. JRE_HOME이 사용될 때는 허용되지 않습니다.
  • JRE_HOME과 JAVA_HOME을 모두 지정하면 JRE_HOME이 사용됩니다.
  • 이러한 변수를 지정하기 위해 권장되는 위치는 "setenv" 스크립트입니다. "setenv" 스크립트는 아래에서 설명 합니다.
• 기타 변수(선택 사항)
  
  • 위에서 설명한 네 가지 외에도 다른 환경 변수가 존재합니다. 각각의 목록과 설명을 보려면 catalina.bat 또는 catalina.sh 스크립트 상단의 주석을 참조하세요.
  • 자주 사용되는 변수 중 하나는 CATALINA_OPTS입니다. Tomcat을 시작하는 java 명령에 대한 추가 옵션을 명시합니다.
  • 자세한 내용은 Tomcat 구성 참조의 "system properties" 페이지를 참조하세요.
  • 유사한 변수는 JAVA_OPTS입니다. 자주 사용되지는 않습니다. 이 변수는 Tomcat을 시작하고 중지하는데 사용되는 옵션 사양 입니다.
  • 참고: JAVA_OPTS를 사용하여 메모리 제한을 지정하지 마세요. 메모리 제한 설정은 CATALINA_OPTS에 속합니다.
  • 자주 사용되는 또 다른 변수는 CATALINA_PID(*nix 전용)입니다. 이 변수는 Tomcat의 프로세스 ID가 있는 파일의 위치를 ​​지정합니다. 이 설정은 선택 사항입니다. 다음 기능이 활성화됩니다:
    * 중복 시작 시도에 대한 더 나은 보호
    * Tomcat 프로세스가 일반적인 shutdown 명령에 반응하지 않을 때 강제 종료
    
    
• "setenv" 스크립트 사용(선택, 권장)
  
  • CATALINA_HOME 및 CATALINA_BASE를 제외한 모든 환경 변수는"setenv" 스크립트에 지정해야 합니다. 스크립트는 CATALINA_BASE/bin 또는 CATALINA_HOME/bin 디렉터리로 이동하고 환경에 맞기 이름을 지정합니다. setenv.bat(Windows) 또는 setenv.sh(*nix).
  • 기본적으로 setenv 스크립트 파일은 없습니다. CATALINA_BASE와 CATALINA_HOME 모두에서 스크립트 파일이 있는 경우 CATALINA_BASE에 있는 것을 우선으로 선택합니다.
    예를 들어 JRE_HOME 및 CATALINA_PID 변수를 구성하려면 다음을 수행합니다. 다음 스크립트 파일을 만듭니다.
• Windows의 경우, %CATALINA_BASE%\bin\setenv.bat:

set "JRE_HOME=%ProgramFiles%\Java\jre8"
exit /b 0

• *nix의 경우, $CATALINA_BASE/bin/setenv.sh:

JRE_HOME=/usr/java/latest
CATALINA_PID="/run/tomcat.pid"

• CATALINA_HOME 및 CATALINA_BASE 변수는 해당 파일을 찾는 데 사용되기 때문 setenv 스크립트에 구성될 수 없습니다.
  여기에 설명된 모든 환경 변수와 "setenv" 스크립트는 표준 스크립트를 사용하여 Tomcat을 시작하는 경우에만 사용됩니다. 
• 예를 들어, Windows에 Tomcat을 서비스로 설치했다면, 서비스 래퍼는 Java를 직접 실행하고 스크립트 파일을 사용하지 않습니다.

• 톰캣 시작하기
  
  • 다음 명령 중 하나를 실행하여 Tomcat을 시작할 수 있습니다.
  • Windows에서:
    %CATALINA_HOME%\bin\startup.bat 또는 %CATALINA_HOME%\bin\catalina.bat start
    
    *nix에서:
    $CATALINA_HOME/bin/startup.sh 또는 $CATALINA_HOME/bin/catalina.sh start

• 톰캣 종료
• 다음 명령 중 하나를 실행하여 Tomcat을 종료할 수 있습니다.
  Windows에서:
  %CATALINA_HOME%\bin\shutdown.bat 또는 %CATALINA_HOME%\bin\catalina.bat stop
  
  *nix에서:
  $CATALINA_HOME/bin/shutdown.sh 또는 $CATALINA_HOME/bin/catalina.sh stop
  
  

멀티 톰캣 인스턴스 구성

많은 상황에서 동일한 서버의 여러 사용자가 톰캣 바이너리 배포판의 단일 복사본을 공유하는 것은 바람직합니다.

이를 가능하게 하기위해 CATALINA_BASE 환경 변수를 '개인' Tomcat 인스턴스에 대한 파일이 포함된 디렉토리로 설정할 수 있습니다.

별도의 CATALINA_HOME 및 CATALINA_BASE로 실행하면 파일과 디렉토리는 다음과 같이 분할됩니다.
CATALINA_BASE에서:

* bin - 다음 파일만:
    * setenv.sh (*nix) 또는 setenv.bat (Windows),
    * tomcat-juli.jar

* conf - 서버 구성 파일(server.xml 포함)

* lib - 아래에 설명된 라이브러리 및 클래스

* 로그 - 로그 및 출력 파일

* webapps - 자동으로 로드되는 웹 애플리케이션

* work - 웹 애플리케이션을 위한 임시 작업 디렉토리

* temp - JVM에서 임시 파일용으로 사용하는 디렉토리(java.io.tmpdir)

CATALINA_HOME에서:

* bin - 시작 및 종료 스크립트

          다음 파일이 CATALINA_BASE/bin 경로에 없는 경우에만 사용됩니다.
          setenv.sh(*nix), setenv.bat(Windows), tomcat-juli.jar

* lib - 아래에 설명된 라이브러리 및 클래스

기본 구성에서 CATALINA_BASE/lib 및 CATALINA_HOME/lib에 있는 JAR 라이브러리와 클래스는 모두 공통 클래스경로에 추가됩니다. CATALINA_BASE에 있는 것이 먼저 추가되므로 먼저 검색됩니다.

CATALINA_HOME/lib에는 표준 Tomcat 라이브러리를 남겨두고 CATALINA_BASE/lib에는 데이터베이스 드라이버와 같은 다른 라이브러리를 추가할 수 있습니다.

일반적으로 웹 애플리케이션 간에 라이브러리를 공유하지 않고 응용 프로그램 내부의 WEB-INF/lib 디렉토리에 두는것이 좋습니다.

CATALINA_HOME 및 CATALINA_BASE 값은 Tomcat에 의해 각각 ${catalina.home} 및 ${catalina.base}로 처리되어 XML 구성 파일에서 참조될 수 있습니다.

예를 들어 표준 관리자 웹 애플리케이션은 CATALINA_HOME/webapps/manager 위치에 보관하고, 해당 배포 설명자를 원하는 가상 호스트로 복사하여 CATALINA_BASE에 로드합니다.

* CATALINA_HOME/webapps/manager/META-INF/context.xml파일을CATALINA_BASE/conf/Catalina/localhost/manager.xml로 복사 합니다.

 * 아래와 같이 docBase 속성을 추가합니다.

<?xml version="1.0" encoding="UTF-8"?>
<Context docBase="${catalina.home}/webapps/manager" antiResourceLocking="false" privileged="true" >
    <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.0\.0\.1" />
    <Manager sessionAttributeValueClassNameFilter="java\.lang\.(?:Boolean|Integer|Long|Number|String)|org\.apache\.catalina\.filters\.CsrfPreventionFilter\$LruCache(?:\$1)?|java\.util\.(?:Linked)?HashMap"/>
</Context>

참조:

https://tomcat.apache.org/tomcat-9.0-doc/RUNNING.txt

https://lilo.tistory.com/115

https://www.slideshare.net/ienvyou/v13-122857784

실행 환경

• Apple M1 Pro (mac OS Ventura 13.2.1)
• homebrew 4.0.6
• JDK 11, 17

1. 자바 설치하기

Homebrew가 설치되있다고 가정합니다.

1.1 Homebrew 업데이트

$ brew update

1.2 설치 가능한 openjdk 찾기

$ brew search openjdk                                                                                                                                       ✔  19:37:06 
==> Formulae
openjdk ✔                      openjdk@11 ✔                   openjdk@17 ✔                   openjdk@8                      openj9                         openvdb

1.3 openjdk@17 설치하기

$ brew install openjdk@17

==> Fetching dependencies for openjdk@17: giflib, libpng, freetype, fontconfig, glib, xorgproto, libxau, libxdmcp, libxcb, libx11, libxext, libxrender, lzo, pixman, cairo, graphite2, icu4c, harfbuzz, jpeg-turbo, lz4, xz, zstd, libtiff, and little-cms2
==> Fetching giflib
==> Downloading https://ghcr.io/v2/homebrew/core/giflib/manifests/5.2.1
######################################################################## 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/giflib/blobs/sha256:ced5a24b12f7057504aa8821a81c03c4d83ff6ba861487e25eba34b863237c20
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:ced5a24b12f7057504aa8821a81c03c4d83ff6ba861487e25eba34b863237c20?se=2023-03-12T06%3A45%3A00Z&sig=bKi
######################################################################## 100.0%

... 일부 생략

==> Fetching openjdk@17
==> Downloading https://ghcr.io/v2/homebrew/core/openjdk/17/manifests/17.0.6
######################################################################## 100.0%
==> Downloading https://ghcr.io/v2/homebrew/core/openjdk/17/blobs/sha256:aea96c54a5b8ca246bf78c973875468e16c5c3f4f5bd33ec10cc0a60df266351
==> Downloading from https://pkg-containers.githubusercontent.com/ghcr1/blobs/sha256:aea96c54a5b8ca246bf78c973875468e16c5c3f4f5bd33ec10cc0a60df266351?se=2023-03-12T06%3A45%3A00Z&sig=mFv
######################################################################## 100.0%
==> Installing dependencies for openjdk@17: giflib, libpng, freetype, fontconfig, glib, xorgproto, libxau, libxdmcp, libxcb, libx11, libxext, libxrender, lzo, pixman, cairo, graphite2, icu4c, harfbuzz, jpeg-turbo, lz4, xz, zstd, libtiff, and little-cms2
==> Installing openjdk@17 dependency: giflib
==> Pouring giflib--5.2.1.arm64_ventura.bottle.tar.gz
🍺  /opt/homebrew/Cellar/giflib/5.2.1: 19 files, 540.2KB
==> Installing openjdk@17 dependency: libpng

... 일부 생략

Pruned 0 symbolic links and 2 directories from /opt/homebrew
==> Caveats
==> openjdk@17
For the system Java wrappers to find this JDK, symlink it with
  sudo ln -sfn /opt/homebrew/opt/openjdk@17/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk-17.jdk

openjdk@17 is keg-only, which means it was not symlinked into /opt/homebrew,
because this is an alternate version of another formula.

If you need to have openjdk@17 first in your PATH, run:
  echo 'export PATH="/opt/homebrew/opt/openjdk@17/bin:$PATH"' >> ~/.zshrc

For compilers to find openjdk@17 you may need to set:
  export CPPFLAGS="-I/opt/homebrew/opt/openjdk@17/include"

openjdk@17 설치에 필요한 의존 관계까지 같이 다운로드 됩니다.

1.4 openjdk@17은  keg-only 입니다 . macOS java wrapper가 찾을 수 있도록 심볼릭 링크를 생성해야 합니다.

$ sudo ln -sfn /opt/homebrew/opt/openjdk@17/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk-17.jdk

1.5 완료. 버전 확인

$ java --version

openjdk 17.0.6 2023-01-17
OpenJDK Runtime Environment Homebrew (build 17.0.6+0)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.6+0, mixed mode, sharing)

여러 자바 버전을 설치하면 기본적으로 가장 최신 버전의 자바 버전으로 세팅된다.

2. JAVA_HOME  OS 환경 변수 설정하기

2.1 Mac OS X 10.5 이상에서 기본 JDK의 위치 조회

// 기본 JDK 위치
$ /usr/libexec/java_home

/opt/homebrew/Cellar/openjdk@17/17.0.6/libexec/openjdk.jdk/Contents/Home

// 설치된 모든 JDK 
$ /usr/libexec/java_home -V

Matching Java Virtual Machines (2):
    17.0.6 (arm64) "Homebrew" - "OpenJDK 17.0.6" /opt/homebrew/Cellar/openjdk@17/17.0.6/libexec/openjdk.jdk/Contents/Home
    11.0.15 (arm64) "Homebrew" - "OpenJDK 11.0.15" /opt/homebrew/Cellar/openjdk@11/11.0.15/libexec/openjdk.jdk/Contents/Home
/opt/homebrew/Cellar/openjdk@17/17.0.6/libexec/openjdk.jdk/Contents/Home

// 특정 JDK 
$ /usr/libexec/java_home -v17

/opt/homebrew/Cellar/openjdk@17/17.0.6/libexec/openjdk.jdk/Contents/Home

2.2 macOS 10.15 Catalina 이상에서는 zsh이 기본 터미널 셸이며 또는 $JAVA_HOME에서 환경 변수를 설정

zsh 쉘 수정

vi ~/.zshrc

사용 할 JDK 버전에 따라 아래 내용을 추가한다.

// JDK 11 
export JAVA_HOME=$(/usr/libexec/java_home -v11)

// JDK 17
export JAVA_HOME=$(/usr/libexec/java_home -v17)

2.3 변경사항 반영 하고 확인

source ~/.zshrc

$ echo $JAVA_HOME
/opt/homebrew/Cellar/openjdk@11/11.0.15/libexec/openjdk.jdk/Contents/Home

$ java --version
openjdk 11.0.15 2022-04-19
OpenJDK Runtime Environment Homebrew (build 11.0.15+0)
OpenJDK 64-Bit Server VM Homebrew (build 11.0.15+0, mixed mode)

3. 다른 JDK 버전 간 전환

3.1 macOS의 모든 JDK 버전 확인

// 설치된 모든 JDK 
$ /usr/libexec/java_home -V

Matching Java Virtual Machines (2):
    17.0.6 (arm64) "Homebrew" - "OpenJDK 17.0.6" /opt/homebrew/Cellar/openjdk@17/17.0.6/libexec/openjdk.jdk/Contents/Home
    11.0.15 (arm64) "Homebrew" - "OpenJDK 11.0.15" /opt/homebrew/Cellar/openjdk@11/11.0.15/libexec/openjdk.jdk/Contents/Home
/opt/homebrew/Cellar/openjdk@17/17.0.6/libexec/openjdk.jdk/Contents/Home

3.2 ~/ .zshrc 에 아래 function 추가

jdk() {
      version=$1
      unset JAVA_HOME;
      export JAVA_HOME=$(/usr/libexec/java_home -v"$version");
      java -version
}

3.3 JDK 버전 전환 확인

$ jdk 17
openjdk version "17.0.6" 2023-01-17
OpenJDK Runtime Environment Homebrew (build 17.0.6+0)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.6+0, mixed mode, sharing)

$ jdk 11
openjdk version "11.0.15" 2022-04-19
OpenJDK Runtime Environment Homebrew (build 11.0.15+0)
OpenJDK 64-Bit Server VM Homebrew (build 11.0.15+0, mixed mode)

참고 

https://mkyong.com/java/how-to-install-java-on-mac-osx/

https://mkyong.com/java/how-to-set-java_home-environment-variable-on-mac-os-x/

용어설명

워킹트리(working tree)

워크트리, 워킹 디렉토리, 작업 디렉토리, 작업 폴더 모두 같은 뜻으로 사용됩니다. 일반적으로 사용자가 파일과 하위 폴더를 만들고 작업 결과물을 저장하는 곳을 Git에서는 워킹트리라고 부릅니다.

로컬저장소(local repository)

git init 명령으로 생성되는 [.git] 폴더가 로컬저장소입니다. 커밋, 커밋을 구성하는 객체, 스테이지가 모두 이 폴더에 저장됩니다.

원격저장소(remote repository)

로컬저장소를 업로드하는 곳을 원격저장소라고 부릅니다. GitHub, GitLab, Bitbucket  등

Git 저장소

Git 명령으로 관리할 수 있는 폴더 전체를 일반적으로 Git 프로젝트 혹은 Git 저장소라고 부릅니다. 공식문서에서는 Git 저장소와 로컬저장소를 같은 뜻으로 사용하고 있습니다.

기호 설명

[옵션인자] 처럼 대괄호로 둘러싸인 부분은 생략 가능

<필수인자> 처럼 부등호로 둘러싸인 부분은 필수 입력

$ 기호는 입력하지 않습니다.

시작하기

$ git init

현재 폴더에서 Git 저장소를 생성합니다. 현재 폴더에는 [.git]이라는 숨김 폴더가 생성되는데 사실 이 폴더가 로컬저장소입니다.

$ git status

Git 워킹트리의 상태를 보는 명령, 워킹트리가 아닌 폴더에서 실행하면 오류가 발생.

$ git status -s

git status 명령보다 짧게 요약해서 상태를 보여주는 명령, 변경된 파일이 많을 때 유용하다.

$ git diff

워킹 디렉토리에 있는 것과 스테이지 영역에 있는 변경사항을 비교합니다.

그래서 수정하고 아직 스테이징하지 않은 것을 보여줍니다.

$ git diff --staged

커밋하려고 스테이징 영역에 넣은 파일의 변경 부분을 보고 싶을 경우 사용합니다.

이 명령은 저장소에 커밋한 것과 스테이징 영역에 있는 것을 비교합니다.

옵션 설정

--local, --global, --system

지역, 전역, 시스템 옵션을 나타냅니다.

$ git config --global <옵션명>

 지정한 전역 옵션의 내용을 살펴봅니다.

$ git config --global <옵션명> <새로운 값>

 지정한 전역 옵션의 값을 새로 설정합니다.

$ git config --global --unset <옵션명>

 지정한 전역 옵션을 삭제합니다.

$ git config --list

현재 프로젝트의 모든 옵션을 살펴봅니다.

기본적인 명령어

$ git add

파일들을 스테이지에 추가합니다.

새로 생성한 파일을 스테이지에 추가하고 싶다면 반드시 add 명령을 사용합니다.

$ git reset [파일명]...

스테이지 영역에 있는 파일들을 스테이지에서 내립니다(언스테이징).

워킹트리의 내용은 변경되지 않습니다. 옵션(soft, mixed, hard)을 생략할 경우 스테이지의 모든 변경사항을 초기화합니다.

$ git restore [파일명]...

언스테이지 영역에 있는 파일의 모든 수정사항을 되돌립니다. 

추적하지 않는 파일에는 영향이 없습니다.

$ git commit

스테이지에 있는 파일들을 커밋합니다.

$ git commit -a

add 명령을 생략하고 바로 커밋하고 싶을 때 사용합니다. 변경된 파일과 삭제된 파일은 자동으로 스테이징되고 커밋됩니다. 주의할 점은 untracked파일은 커밋되지 않는다는 것입니다.

$ git commit -amend

완료한 커밋을 수정할 때 사용합니다. 다시 커밋하고 싶으면 파일 수정 작업을 하고 Staging Area에 추가한 다음 --amend 옵션을 사용하여 커밋을 재작성 할 수 있습니다.

만약 마지막으로 커밋하고 나서 수정한 것이 없다면(커밋하자마자 바로 이 명령을 실행하는 경우) 커밋 메시지만 수정합니다.

$ git commit -amend -m <커밋 메시지>

완료한 커밋의 메시지를 수정할 때 사용합니다.

$ git rm <파일명>

Git에서 파일을 삭제할 때 사용합니다. 

삭제한 파일은 Staged 상태가 되며 커밋하면 파일은 삭제되고 Git은 이 파일을 더는 추적하지 않는다.

이미 파일을 수정했거나 스테이지 영역에 추가했다면 -f 옵션을 주어 강제로 삭제해야 한다.

$ git rm --cached <파일명>

스테이지 영역 에서만 제거하고 워킹 디렉토리에 있는 파일은 지우지 않고 남겨둘 때 사용합니다.

하드디스크에 있는 파일은 그대로 두고 Git만 추적하지 않게 합니다.

.gitignore 파일에 추가하는 것을 빼먹었거나 대용량 로그 파일이나 컴파일된 파일인 .a 파일 같은 것을 실수로 추가했을 때 사용합니다.

$ git merge 브랜치이름

지정한 브랜치의 커밋들을 현재 브랜치 및 워킹트리에 반영합니다.

로그 살펴보기

$ git log

현재 브랜치의 커밋 이력을 보여줍니다.

$ git log -n<숫자>

전체 커밋 중에서 최신 n개의 커밋만 살펴봅니다. 

$ git log -p -<숫자>

-p, -patch 옵션은 각 커밋의 diff 결과를 보여줍니다.

-<숫자> 옵션을 사용하면 최근 <숫자> 만큼 커밋된 결과만 보여줍니다.

$ git log -S <텍스트>

-S 옵션은 코드에서 추가되거나 제거된 내용 중에 <텍스트> 가 포함되어 있는지 검색합니다.

$ git log --oneline --graph --all --decorate

자주 사용하는 옵션으로 간결하고 멋지게 보여줍니다.

--oneline: 커밋 메시지를 한 줄로 요약해서 보여줍니다. 

--graph: 커밋 옆에 브랜치의 흐름을 그래프로 보여줍니다.

--all: 옵션이 없을 경우 HEAD와 관계없는 옵션은 보여주지 않습니다.

--decorate: 원래는 --decorate=short 옵션을 의미한다. 브랜치와 태그 등의 참조를 간결히 표시합니다.

도움말 기능 사용하기

$ git help <명령어>

해당 명령어의 도움말을 표시합니다.

원격저장소 관련 명령어

$ git remote add <원격저장소 이름> <원격저장소 주소>

원격저장소를 등록합니다.

원격저장소는 여러 개 등록할 수 있지만 같은 별명의 원격저장소는 하나만 가질 수 있습니다. 통상 첫 번째 원격저장소를 origin으로 지정합니다.

$ git remote -v

원격저장소 목록을 살펴봅니다.

$ git push [-u] [원격저장소 별명] [브랜치 이름]

현재 브랜치에서 새로 생성한 커밋들을 원격저장소에 업로드합니다. -u 옵션으로 브랜치의 업스트림을 등록할 수 있습니다. 한 번 등록한 후에는 git push만 입력해도 됩니다.

$ git push [원격저장소 별명] -d [원격 브랜치 이름]

원격 저장소의 브랜치를 삭제합니다.

$ git pull

원격저장소의 변경사항을 워킹트리에 반영합니다. git fetch + git merge 명령입니다.

$ git fetch [원격저장소 별명] [브랜치 이름]

원격저장소의 브랜치와 커밋들을 로컬저장소와 동기화합니다. 옵션을 생략하면 모든 원격저장소에서 모든 브랜치를 가져옵니다.

$ git clone <저장소 주소> [새로운 폴더명]

저장소 주소에서 프로젝트를 복재해 옵니다. 이때 새로 생길 폴더명은 생략 가능하며 폴더명을 생략하면 프로젝트 이름과 같은 이름의 폴더가 새로 생성됩니다. 저장소 주소는 꼭 원격일 필요가 없으며 로컬저장소도 git clone 명령으로 복제할 수 있습니다.

$ git revert HEAD

원격저장소 브랜치의 커밋을 될돌리고 싶을때 사용합니다. 

커밋을 되돌리는 새로운 커밋을 추가해줍니다.

주의) git reset 명령어는 git 히스토리에서 커밋을 완전히 없었던 일처럼 지워버리기 때문에 원격저장소의 공동 작업브랜치에 있는 커밋을 지우면 해당 커밋을 기준으로 작업하던 동료의 히스토리가 꼬일 수 있다.

브랜치 관련 명령어

$ git branch [-v]

로컬 저장소의 브랜치 목록을 보는 명령으로 -v 옵션을 사용하면 마지막 커밋도 함께 표시됩니다. 표시된 브랜치 중에서 이름 왼쪽에 *가 붙어 있으면 HEAD 브랜치입니다.

$ git branch [-f] <브랜치 이름> [커밋체크섬]

새로운 브랜치를 생성합니다. 커밋체크섬 값을 주지 않으면 HEAD로부터 브랜치를 생성합니다. 이미 있는 브랜치를 다른 커밋으로 옮기고 싶을 때는 -f 옵션을 줘야 합니다.

$ git branch -r[-v]

원격 저장소에 있는 브랜치를 보고 싶을 때 사용합니다. 마찬가지로 -v 옵션을 추가하여 커밋 요약도 볼 수 있습니다.

$ git checkout <브랜치 이름>

특정 브랜치로 체크아웃할 때 사용합니다. 브랜치 이름 대신 커밋 체크섬을 쓸 수 있습니다. 하지만 브랜치 이름을 쓰는 방법을 강력히 권장합니다.

$ git checkout -b <브랜치 이름> <커밋 체크섬>

특정 커밋에서 브랜치를 새로 생성하고 동시에 체크아웃까지 합니다. 두 명령을 하나로 합친 명령이기 때문에 간결해서 자주 사용합니다.

$ git merge <대상 브랜치>

현재 브랜치와 대상 브랜치를 병합할 때 사용합니다. 병합 커밋(merge commit)이 새로 생기는 경우가 많습니다.

$ git rebase <대상 브랜치>

내 브랜치의 커밋들을 대상 브랜치에 재배치시킵니다. 히스토리가 깔끔해져서 자주 사용하지만 조심해야 합니다.

$ git branch -d <브랜치 이름>

특정 브랜치를 삭제할 때 사용합니다. HEAD 브랜치나 병합이 되지 않은 브랜치는 삭제할 수 없습니다.

$ git branch -D <브랜치 이름>

브랜치를 강제로 삭제하는 명령입니다. -d 로 삭제할 수 없는 브랜치를 지우고 싶을 때 사용합니다. 역시 조심해야 합니다.

$ git reset --hard <이동할 커밋 체크섬>

현재 브랜치를 지정한 커밋으로 옮긴다. 작업 폴더의 내용도 함께 변경된다.

$ git tag -a -m <간단한 메시지> <태그 이름> [브랜치 또는 체크섬]

-a 로 주석 있는(annotated) 태그를 생성합니다. 메시지와 태그 이름은 필수이며 브랜치 이름을 생략하면 HEAD에 태그를 생성합니다.

$ git push <원격저장소 별명> <태그 이름>

원격 저장소에 태그를 업로드합니다.

HEAD~<숫자>

HEAD~은 헤드의 부모 커밋, HEAD~2는 헤드의 할어버지 커밋을 말한다. HEAD~n은 n번째 위쪽 조상이라는 뜻이다.

HEAD^<숫자>

HEAD^은 똑같이 부모 커밋이다. 변면 HEAD^2는 두 번째 부모를 가르킨다. 병합 커밋처럼 부모가 둘 이상인 커밋에서만 의미가 있다.

HEAD

1. HEAD는 현재 작업 중인 브랜치를 가리킵니다.

2. 브랜치는 커밋을 가리키므로 HEAD도 커밋을 가리킵니다.

3. 결국 HEAD는 현재 작업 중인 브랜치의 최근 커밋을 가리킵니다.

새로운 커밋을 생성하면

1. 새로 커밋을 생성하면 그 커밋의 부모는 언제나 이전 HEAD 커밋입니다.

2. 커밋이 생성되면 HEAD는 새로운 커밋으로 갱신됩니다.

3. HEAD가 가리키는 브랜치도 HEAD와 함께 새로운 커밋을 가리킵니다.

Git 내부 동작 원리

1. git add 명령을 수행하면 워킹트리의 내용을 스테이지에 추가한다.

2. git commit 명령을 수행하면 스태이지의 내용으로 새로운 커밋을 만든다.

3. 커밋 이후 git status 명령을 내리면 clean한 상태임을 표시해 주는데, 이 상태는 워킹트리, 스테이지, HEAD 커밋들이 모두 동일한 내용을 담고 있다는 뜻이다.

4. 커밋 객체는 트리 객체와 blob 객체들의 조합으로 이루어져 있다.

5. 커밋 객체는 부모 커밋에 대한 참조를 가지고 있다.

6. 브랜치를 생성하면 단순히 브랜치 파일 하나를 추가한다.

7. git add 명령을 수행하면 워킹트리의 내용을 스테이지에 추가한다.

기본 에디터 확인하기

# 지역 옵션 확인
$ git config core.editor

# 글로벌 옵션 확인
$ git config --grobal core.editor

# 시스템 옵션 확인
$ git config --system core.editor

Git의 옵션에는 지역, 전역, 시스템 환경 옵션의 세 종류가 있습니다. 

시스템 환경 옵션: PC 전체의 사용자

전역 옵션: 현재 사용자

지역 옵션: 현재 Git 저장소

환경에 맞는 기본 에디터 설정을 확인 합니다. 기본 에디터가 설정되지 않거나 vs code가 아니라면 설정 작업을 합니다.

기본 에디터 설정하기

방법1: Git 설치(재설치) 과정에서 기본 에디터 등록

Git 설치 과정에서 기본 에디터를 선택이 나오는데 VS Code를 선택 합니다. Git이 이미 설치되어있다면 재설치 과정을 진행해도 됩니다.

물론 VS Code가 이미 설치되어 있어야합니다.

방법2: Git 기본 에디터 설정 명령어를 사용

VS Code가 PATH에 설정이 되어 있는지 확인. 다음 명령어가 실행되는지 확인 합니다.

$ code -v

만약 오류가 발생한다면 VS Code 경로를 PATH에 넣어주는 작업을 합니다.

VS Code를 실행하고 Command Palette를 열기(Mac OS 단축키: Command + Shift + p)

shell command를 입력하면 나오는 "Shell Command: Install 'code' command in PATH"를 선택합니다.

다시 한번 터미널에서 code -v 명령어를 실행하여 확인합니다.

명령어가 정상적으로 실행됬다면 이제부터 Git 기본 에디터 설정을 합니다.

# 글로벌 옵션으로 설정
$ git config --global core.editor "code --wait"

기본 에디터로 설정됬는지 확인 합니다.

$ git config --global core.editor
code --wait

커밋하여 VS Code가 실행되는지 확인하기

# git 저장소 초기화
$ git init

# "hello git" 내용을 가지는 file.txt 파일 생성
$ echo "hello git" > file.txt

# file.txt 파일을 스태이지에 추가
$ git add file.txt

# file.txt 파일 커밋 실행, VS Code가 열리면 커밋 메시지 입력 후 저장 & 닫기
$ git commit

여기까지가 Git 기본 에디터 설정하기 였습니다. 

VS Code 에서 한글로 커밋 메시지를 작성할 때 ’50/72 규칙’ 도움받기

VS Code를 실행하여 설정(Mac OS 단축키: Command + ,) 실행

UI모드로 열렸다면 Json모드로 변경하고 설정 페이지를 다시 오픈한다.

아래 내용을 추가하고 저장한다.

"[git-commit]": {
        "editor.fontFamily": "D2Coding",
        "editor.rulers": [
            50,
            72
        ]
}

커밋 메시지를 작성해보자.

한글이 포함된 커밋 메시지를 작성할 때 D2 Coding 글꼴과 눈금자의 도움을 받아 ’50/72 규칙’을 쉽게 지킬 수 있다.