KOMAS

Data

Docker에서 볼륨을 지정할 때, -v 옵션 뒤에 경로가 아닌 단순한 문자열(예: myvolume)을 지정하면, 

Docker는 이를 네임드 볼륨(named volume)으로 간주합니다. 반면에 슬래시(/)를 포함한 경로 형태(예: /path/on/host:/path/in/container)를 지정하면 바인드 마운트(bind mount)로 간주합니다.

예를 들면:

네임드 볼륨:
docker run -v myvolume:/path/in/container my_image
위의 명령어는 myvolume이라는 네임드 볼륨을 컨테이너의 /path/in/container 위치에 마운트합니다.

바인드 마운트:
docker run -v /path/on/host:/path/in/container my_image
위의 명령어는 호스트의 /path/on/host 디렉토리를 컨테이너의 /path/in/container 위치에 마운트합니다.

결론적으로, 슬래시(/)가 없는 단순한 문자열을 지정하면 Docker는 이를 네임드 볼륨으로 인식합니다.

바인드 마운트

호스트의 특정 디렉토리를 컨테이너에 마운트합니다.
-v 왼쪽경로디렉토리(로컬):오른쪽 경로디렉토리(컨테이너)
이 명령어를 사용하여 호스트의 디렉토리를 컨테이너에 마운트합니다.
주의점으로 bind mount가 컨테이너 내부의 폴더에 우선시 되므로, 기존에 컨테이너 안에 있던 데이터가 덮어쓰일 수 있습니다.
로컬 디렉토리가 우선되며, 로컬을 변경하면 컨테이너에 즉시 반영

도커 파일 캐싱

Docker는 이미지를 빌드할 때 효율적으로 처리하기 위해 캐싱 메커니즘이 있습니다.

Dockerfile의 각 줄은 독립적인 레이어로 생성되며, 이전에 빌드했을 때 변경되지 않은 레이어는 캐싱되어 재사용됩니다.

이 Dockerfile을 처음 빌드할 때, 모든 단계가 실행되어 새 이미지가 생성됩니다. 

하지만 COPY 단계에서 소스 코드에 변경사항이 발생하면, 이후의 모든 단계는 캐시를 사용하지 않고 다시 실행됩니다.

캐싱 전략
변경 빈도가 높은 단계는 Dockerfile의 하단에 위치시키는 것이 좋습니다. 

그렇게 하면 변경 빈도가 낮은 단계는 최대한 캐싱을 활용할 수 있습니다.

예를 들어, 애플리케이션의 종속성을 설치하는 단계와 소스 코드를 복사하는 단계가 있다면, 

종속성 설치 단계를 먼저 위치시키고 소스 코드 복사 단계를 그 이후에 위치시키는 것이 좋습니다. 

그러면 종속성 변경이 없는 경우에는 캐싱을 효율적으로 활용할 수 있습니다.

도커 컴포즈의 목적

다중 컨테이너 관리: docker-compose는 여러 서비스로 구성된 애플리케이션을

각 서비스의 이미지, 환경 변수, 포트, 볼륨 등을 설정

의존성 관리: 서비스 간의 의존 관계를 정의

예를 들어, 백엔드 서비스가 데이터베이스 서비스를 필요로 할 경우,

docker-compose를 사용하여 백엔드가 데이터베이스가 준비된 후에 시작

일관된 환경: 개발, 테스팅, 스테이징, 프로덕션 등 다양한 환경에서

동일한 docker-compose.yml 파일을 사용하여 애플리케이션을 실행

한 번의 명령으로 서비스 관리: 

docker-compose up 명령을 사용하여 모든 서비스를 시작하거나 

docker-compose down 명령을 사용하여 모든 서비스를 종료

이미지 다운로드: docker-compose를 사용하면 docker-compose.yml에 정의된 모든 이미지를 

한 번의 명령으로 다운로드 (docker-compose pull). 

배포 순서: ci.yml build -> docker-compose.yml -> cd.yml deploy

윈도우에서 리눅스를 사용할 때 윈도우 데스크탑으로 이동하는 명령어를 쉘 스크립트로 저장해서 사용

bash 실행 하면 동작하지 않는데,

새로운 쉘을 띄워서 사용하고 종료 후 원래의 쉘로 돌아와서, 경로를 이동하지 못한다고 한다.

source 실행 명령어를 사용하면

현재 쉘을 사용한다.

[ local 작업 ]
1. jar 파일 만들기
2. dockerfile 작성
3. docker 이미지 만들기
4. docker push

[ server 작업 ]
5. docker pull
6. docker run

1. jar 파일 만들기

Gradle bootJar로 jar 파일을 만든다.

build/libs 경로에 jar파일이 생성된다.

2. dockerfile 수정

FROM adoptopenjdk/openjdk11:alpine-slim

WORKDIR /chat

COPY build/libs/map-chat-v1.jar .

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "map-chat-v1.jar"]

도커 파일을 작성하여 이미지를 생성할 준비를 한다.

컨테이너 구동시 jar파일이 실행되도록 했다.

3. docker 이미지 만들기

docker build

-t 저장소명:태그

.

경로를 못찾는다고 할 경우

docker build

-f dockerfile경로

-t 저장소명/이미지명:태그

4. docker push

docker hub push가 간혹 안되는 경우가 있는데,

docker hub repository 이름과, push할 이미지 이름이 같아야 한다.

docker push 저장소명:태그

[ 여기서부터는 서버에서 작업 ]

5. docker pull

docker login -u 아이디

docker pull 저장소명:태그

6. docker run

docker run

-p 80:8080

저장소명:태그

도커

도커는 컨테이너때문에 쓰는 것이다.

컨테이너는 어느 환경에서건 같은 환경을 구축할 수 있다.

기존 가상머신 방식이 비효율적인 이유

하나의 운영체제에 여러 가상머신을 설치해서 각 가상머신마다 다른 버전, 다른 구성으로 software 구축할 수 있다.

하지만 각 가상 머신 마다 OS가 필요하므로 메모리, 드라이브 공간을 낭비한다.

컨테이너 방식이 효율적인 이유

하나의 운영체제에 하나의 docker engine을 설치하여 여러 컨테이너를 도커가 관리한다.

docker engine에서 동작하는 컨테이너들은 가상 머신보다 빠르고 효율적이다.

이미지로 만들어서 어떤 환경에서든 이미지가 같으면 같은 컨테이너가 생성된다.

공유, 재구축, 배포가 쉬워진다.

설치

window10 pro 이상이면 docker desktop (window10에서 제공하는 가상 머신 사용)

linux는 도커 엔진 설치가 간단하다.

이미지와 컨테이너

이미지 -> 클래스

docker hub에 이미 만들어진 이미지 사용하거나 커스텀, 그 위에 레이어를 쌓는 방식

이미지는 빌드되면 닫힌다. ReadOnly . 

변경사항을 적용하려면 이미지를 다시 빌드해줘야 한다.

컨테이너 -> 인스턴스

컨테이너는 하나의 머신으로 생각, shell로 안에서 작업을 진행할 수 있다. 

하나의 이미지로 여러개의 컨테이너 인스턴스를 실행할 수 있다.

컨테이너끼리는 전혀 관계가 없다.

컨테이너마다 버전을 다르게 할 수 있다.

도커 이미지 만들기 [Dockerfile]

FROM   base 이미지 지정

ARG   이미지 빌드타임 KEY=VALUE로 사용할 수 있다.

ENV  PORT 80      환경 변수 설정, 사용시에는 $PORT, 런타임시에도 사용가능

WORKDIR   [컨테이너에서 작업폴더가 되는 곳    COPY, RUN 등은 이곳을 기준으로 동작]

COPY   [이미지에 들어갈 로컬 파일]  [WORKDIR이 기준] 

RUN   이미지를 빌드(생성)할 때 마다 실행할 명령어

컨테이너가 된 이후

EXPOSE $PORT         포트 80 노출, host와 포트 포워딩 필요

CMD 컨테이너가 실행될 때 동작할 명령어 [배열로 명령어 작성, shell이 있다면 string 가능]  

Dockfile 한줄 한줄이 layer다.

변경이 자주되는 layer를 아래에 두면, 윗 layer는 이전 레이어로 caching 된다.

변경 사항이 일어난 layer 밑은 전부 다시 빌드 작업을 진행한다.

역 슬래시를 이용해서 여러줄 작성이 가능.

데이터 volumes & bind mounts

데이터를 도커가 관리하고, 직접 접근은 할 필요가 없는 경우

✔ 익명 볼륨

컨테이너가 삭제되면 같이 제거된다.

하나의 컨테이너에서 데이터 사용

명령어: -v 볼륨경로 (볼륨명을 주지않는다. 컨테이너를 생성할 때 지정)

✔ 네임드 볼륨

컨테이너가 삭제되도 유지된다.

여러 컨테이너에서 데이터를 공유, 생성, 유지하고 싶을 때

명령어:-v 볼륨명:볼륨경로 (볼륨명을 준다. 컨테이너를 생성할 때 지정)

✔ bind mounts

host에서 직접 접근해서 사용할 필요가 있는 경우. 주로 편집을 위해 사용

도커와 host가 같이 사용하는 바인딩하여 관리하는 데이터

명령어: -v 왼쪽경로디렉토리(로컬):오른쪽 경로디렉토리(컨테이너)

bind mounts주의점

도커 컨테이너 내부 폴더보다, bind mount가 우선된다. (덮어씌운다)

컨테이너 내부가 bind mounts된 로컬 폴더로 뒤집어 씌어지면서 이미지 빌드할 때 설정한 종속성이 없어졌다.

덮어씌워지기 전에 이때 필요한 종속성 이미지 파일들을 익명 볼륨에 넣어 유지시켜줘야 한다.

도커파일에 설치명령은 먼저 동작하여 익명 볼륨에 관리시키고 (충돌이 발생하면 도커가 경로가 긴 볼륨을 먼저 보고 적용한다.)

로컬파일을 덮어씌우는 방식

컨테이너에서 유지되어야 하는 것

DB 데이터

서버 log 등...

네트워킹

✔ 컨테이너 app <ㅡ> host DB 연동

호스트 database와 컨테이너 app이 통신할 수 있다.

host.docker.internal

✔ 수동 컨테이너 app <ㅡ> 컨테이너 DB 연동

컨테이너 app에서 DB를 연동

database 컨테이너를 띄우고

docker container inspect로 [ip:port]를 확인한다.

✔ 더 개선된 컨테이너 app <ㅡ> 컨테이너 DB 연동

컨테이너들을 하나에서 네트워크로 사용하면 된다. 도커에서는 이러한 네트워크를 제공한다.

docker network create [네트워크명]

컨테이너를 생성할 때 --network [네트워크명]

컨테이너 app에서 DB를 연동하는 코드에 [ip]대신 [컨테이너DB명]:port 를 입력

도커 네트워크가 같다면 컨테이너 명으로 접근할 수 있다.

내부에서 사용되는 컨테이너 DB는 컨테이너 생성 명령어에서 -p 작업을 해주지 않아도 된다. 

외부에서 요청을 받게되는 컨테이너 app은 포트번호를 노출시켜줘야 한다.

docker compose

자체 네트워크로 여러 컨테이너를 동시에 띄우고 --rm default로 제거한다.

자체 네트워크를 사용하므로 네트워크를 지정해주지 않아도 된다.

이미지를 빌드하고, 컨테이너를 실행하는 과정을 한번에 과정으로 실행

docker-compose up

docker-compose down

docker-compose run [services 등록명]

일부만 컨테이너로 실행할 경우

docker-compose.yml

version: '3.4'

services:
  webmvc:
    image: eshop/webmvc
    environment:
      - CatalogUrl=http://catalog-api
      - OrderingUrl=http://ordering-api
      - BasketUrl=http://basket-api
    ports:
      - "5100:80"
    depends_on:
      - catalog-api
      - ordering-api
      - basket-api

  catalog-api:
    image: eshop/catalog-api
    environment:
      - ConnectionString=Server=sqldata;Initial Catalog=CatalogData;User Id=sa;Password=[PLACEHOLDER]
    expose:
      - "80"
    ports:
      - "5101:80"
    #extra hosts can be used for standalone SQL Server or services at the dev PC
    extra_hosts:
      - "CESARDLSURFBOOK:10.0.75.1"
    depends_on:
      - sqldata

  ordering-api:
    image: eshop/ordering-api
    environment:
      - ConnectionString=Server=sqldata;Database=Services.OrderingDb;User Id=sa;Password=[PLACEHOLDER]
    ports:
      - "5102:80"
    #extra hosts can be used for standalone SQL Server or services at the dev PC
    extra_hosts:
      - "CESARDLSURFBOOK:10.0.75.1"
    depends_on:
      - sqldata

  basket-api:
    image: eshop/basket-api
    environment:
      - ConnectionString=sqldata
    ports:
      - "5103:80"
    depends_on:
      - sqldata

  sqldata:
    environment:
      - SA_PASSWORD=[PLACEHOLDER]
      - ACCEPT_EULA=Y
    ports:
      - "5434:1433"

  basketdata:
    image: redis

Dockerfile을 만들어서 참조해서 사용해도 되고, docker-compose에 모든 내용을 작성해도 된다.

Docker util container

로컬에 환경설정을 하기 위해 사용되는 이미지와 컨테이너

도커 이미지를 기반으로 컨테이너화를 할 때,

이미지마다 해당되는 명령어를 사용하여, 추가적인 환경 설정과 툴을 설치해줄 수 있다.

바인드 마운트를 같이 진행하면 로컬에 환경 설정이 된다.

주의점

docker run ... [명령어] 를 실행하면

Dockerfile의 [CMD 명령어]를 덮어씌운다.

이를 방지하고자 [ENTRYPOINT 명령어]를 사용하면 ENTRYPOINT 명령어 뒤에 이어서 진행한다.

Docker 배포 시

도커를 이용해 배포할 때는 바인드 마운트 사용을 권장하지 않는다.

도커 컨테이너의 기본 아이디어는 컨테이너의 캡슐화이고,

바운드 마운트는 개발할 때의 편의성으로 사용한다.

AWS ECS를 이용하면 컨테이너가 동일 머신에서 동작할 것이 보장되지 않기 때문에,

도커 네트워크를 사용할 수 없다.

환경 변수 설정으로 ip를 지정하게 하자.

명령어

docker ps -a 모두 보기

이미지 명령어

docker build

-t repository명칭:tag명칭

-f 경로 

도커파일위치 보통 .

컨테이너 명령어

docker run   새로운 컨테이너 실행  

docker run -i   stdin 열린 상태로 사용

docker run -t   터미널을 생성

docker start    컨테이너를 재실행  

docker stop     컨테이너 중지

docker rm        컨테이너를 완전히 제거

--name      컨테이너 이름 지정

docker run -p 80:80 이미지명      포트연결

attach & detach

실행중인 컨테이너는 attach, detach 할 수 있다.

attach 모드면 실행중인 container log를 계속 수신

detach모드:   -d 추가

attach모드:   -a 추가

다시연결:   docker attach 컨테이너명

attach 컨테이너 종료시키지 않고 나오기:   ctrl + p + q

로그보기: docker [-f] logs 컨테이너명

interactive terminal

간단한 프로그램 실행

-it

shell로 접근

docker exec -it 컨테이너 bin/bash  

[1] goormide 에 가입하여 Blank를 선택하여 container를 만든다.

Blank를 선택하면 기본 Ubuntu만 제공된다.

[2] apache2 웹 서버를 설치한다.

sudo apt-get install apache2 

[3] apache2 웹 서버 start 

sudo service apache2 start

[4-1] 컨테이너 설정에서 URL과 PORT를 지정하여 접근할 수 있다.

해당 도메인 네임으로 접근할 수 있다.

[4-2] 포트 포워딩를 설정하여 외부에서 접근할 수 있다.

NAT: 클라우드 서버는 하나의 공인 ip에 여러 개의 사설 ip를 두고 사용자에게 하나의 사설 ip를 제공한다. 

ifconfig 으로 사설 ip 주소 확인

사설 ip는 외부에서 접근할 수 없으므로 포트 포워딩을 이용해 [공인 ip:port]로 [사설 ip:port]에 매핑시켜줘야 한다.

웹 서버를 로컬에 둘 경우 공유기의 설정을 변경하여 포트 포워딩하면 되지만,

goormide에서는 컨테이너 설정에서 포트 포워딩 설정이 가능

하나의 운영체제를 여러명의 유저가 사용

각각 권한이 있고 super user가 있다.

Kernel - 하드웨어의 자원을 관리, process, memory, IO system...

Shell - Kernel을 실행시키는 명령어 소프트웨어 [사용자와 커널의 인터페이스] 여러 종류가 있다.

리눅스의 특징

리눅스 명령어는 전부 하나의 process 프로그램이다.

** [명령어] [-간략]  [--풀네임] [내용]

옵션은 process에 인자를 주는 것이다.

IO redirection    [결과를 다른곳으로 out]

ls -l > hi.txt    화면결과를 hi.txt에 복사시켜놓음 [결과를 redirection]
1>     standard output 를 redirection
2>     standard error 를 redirection
<   input

>>  기존 내용에 추가로 append
<<문자  문자를 전부입력을 받다가 이 특정 문자가 나오면 입력이 끝난다.

package manager  

apt 도구를 이용해서 linux package repository에서 가져와 사용한다.

일종의 앱스토어 역할과 같다.

파이프 라인

명령어의 출력을 다른 명령어의 입력으로 사용해서 최종 출력을 내는 것

ls - al | grep 찾을단어

Job Controll

ctrl + Z      background에 올려둔다. 

jobs    background 실행중인 job 목록을 본다.

fg %N     foreground로 전환

bg %N    background의 stopped를 running으로 만든다.

kill %N   background 종료

daemon

항상 실행되어야 하는 프로그램

etc/init.d/ 에 위치한다.

sudo service 데몬 start

sudo service 데몬 stop

service --status-all

디렉토리

/home - 각 사용자를 위한 디렉토리

/bin - 실행 프로그램

/sbin - 시스템 프로그렘

/etc - 설정 파일

/var - 자주 변경되는 프로그램, 로그 파일

/tmp - 임시 파일, 자동 삭제

/opt - 옵션

/lib, /boot, /mnt, media 시스템 디렉토리들

웹서버 설정파일들은 설정파일이 있는 곳인 /etc에 있다.

설정파일을 보면 DocumentRoot가 요청에 대한 파일을 찾는 경로

로그는 /var에 담겨진다.

멀티 유저

sudo - super user do

superuser #

일반유저 $

최초 실행시 sudo passwd 유저 로 root의 비밀번호 설정, 일반 사용자 비밀번호 설정도 같은 명령어.

sudo useradd -m 유저명  /  유저 추가

su - 유저명  /  유저 변경

sudo usermod -a -G sudo 유저명 / 유저에게 sudo 권한 주기

chmod

type | user rwx,  group rwx, other rwx | 링크 수 | user, group | 파일사이즈 | 시간 | 파일명

chmod o-r 파일명   other에 read 권한이 없도록 한다.

chmod u+w 파일명   user에 write 권한을 추가한다.

chmod 771 파일명   rwx 8진수로 가능

그룹

groupadd 그룹명

/etc/group  에 추가된다.

usermod -a -G 그룹명 유저명   

유저 그룹에 추가

sudo chown [owner:group] .  

디렉토리 그룹 변경

명령어 모음

세미콜론 

여러 명령어를 이어서 실행

ls -al 현재 디렉토리의 목록들을 보여준다. [숨김파일, 형식]

cd 디렉토리 이동

mkdir 디렉토리 만들기

pwd 현재 위치 보기

rm 삭제

cat / head / tail 파일 보기

mv [현재경로] [이동할경로]   // 이름 변경도 가능
cp [현재경로] [이동할경로]

ps 실행중인 프로세스를 본다.

grep 문자열 검색

find / -name 파일명 파일 검색

who 접속 사용자 정보

whoami 내 정보

wget url 파일 다운로드

curl url 요청

intellij는 eclipse에서의 workspace가 없다.

workspace는 관련 없는 프로젝트들도 하나의 eclipse창만 띄우고 전부 볼 수 있었다.

intellij에서는 이 방식을 권장하지 않는다.

기본적으로 하나의 프로젝트에는 하나의 모듈을 권장한다.

연관있는 모듈일때만 프로젝트를 생성해서 멀티모듈로 구성한다.

New Project, New Module 화면

차이를 보면 New Project가 Empty Project를 제공해준다는 점만 빼면 똑같다.

멀티 모듈 설정

프로젝트를 gradle 프로젝트로 생성

각 모듈은 gradle 모듈로 생성

DSAL /

     DSAL_Algorithm

     DSAL_DataStructure

settings.gradle

rootProject.name = 'DSAL'
include 'DSAL_Algorithm'
include 'DSAL_DataStructure'

build.gradle

buildscript{ }: gradle 빌드전에 실행

allproject{ }: 모든 모듈에 적용

subproject{ }: 서브 모듈에만 적용

buildscript {
    apply plugin: 'java'

    ext{

    }

    repositories {
        mavenCentral()
    }

    dependencies {

    }

}

allprojects {
    apply plugin: 'java'

    group 'org.example'
    version '1.0-SNAPSHOT'
}

subprojects {
    repositories {
        mavenCentral()
    }

    dependencies {
        // 서브 모듈에 모두 추가할 라이브러리 설정

        testImplementation 'org.junit.jupiter:junit-jupiter-api:5.7.0'
        testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.7.0'
    }

    test {
        useJUnitPlatform()
    }
}

// 각 모듈별 라이브러리 설정
project(':DSAL_Algorithm'){
    dependencies {
        compileOnly 'org.projectlombok:lombok:1.18.12'
        annotationProcessor 'org.projectlombok:lombok:1.18.12'
    }
}

project(':DSAL_DataStructure'){
    dependencies {
    }
}

DSAL_Algorithm에 lombok은 테스트용도로 넣어둠

서브 모듈 build.gradle

dependencies {
    compileOnly 'org.projectlombok:lombok:1.18.12'
    annotationProcessor 'org.projectlombok:lombok:1.18.12'
}

프로젝트 build.gradle의 project(':subModule'){ } 로 사용하지 않고,

서브 모듈에 존재하는 build.gradle에 dependencies{ } 에 추가해도 동작한다.

프로젝트 build.gradle 한곳에서 관리해주는 것이 편리하니 project(':subModule'){} 를 사용하자.

참고

https://jojoldu.tistory.com/334

intellij

하나의 project안에서 여러개의 module로 프로젝트를 구성

gradle을 이용하여 jar파일 생성, 추가

jar 만드는 방법

gradle -> jar

build/libs에 jar파일이 만들어진다.

jar 파일 사용

다른방법

dependencies {
    implementation fileTree('libs')
}

Git 기본 사용법 및 명령어

git을 다운로드하여 프로그램을 설치한 후 $git --version 명령어로 git이 제대로 데스크톱에 설치되었나 확인한다.

git을 이용할 폴더에 들어가서 폴더 배경에서 오른쪽 클릭 - git bash here을 누르면 git이 사용 가능하다.

$git init하게 되면서 (.git)폴더가 생성된다.

Git의 특징

분산 버전관리 시스템

중앙 저장소뿐만 아니라 로컬 저장소에서도 history를 갖고 있다.

Git의 원리

변경이 일어날 때 마다 기존 파일들은 실제로 복사해서 갖고 있는 것이 아니라 기존 내역들을 참조하고 있다. , 해시코드 값을 참조

git init: 작업 영역 생성

git add: [새로 생성된 파일]을 등록한다. 기존 내역은 [기존 파일 참조(해시값)]

git commit: [새로 생성된 파일] + [기존 파일 참조] = 해시 코드 생성

기본 명령어

git 명령어 --help 도움말 보기

git log -> q 나가기

touch sample.txt 테스트할 때 빈 파일 만들기

$git config --global user.email 사용하는 이메일 commit 시 작성자로 등록됨

$git config --global user.name 사용하는 이름

github사이트에서 이용하는 이메일과 이름 [내 정보]를 등록하는 명령어이다.

$git init git 저장소 생성, 현재 폴더를 버전관리하겠다고 선언

$git status 폴더 안 파일들의 상태를 확인 [새로 만든 파일(untracked), 변경된 파일(modified)] 

$git add commit을 수행할 파일을 staging area에 추가한다. [새로 만든 파일(untracked), 변경된 파일(modified)]  둘다 add를 해줘야한다.

이전에 add로 추적을 시켰다 하더라도, 수정시에 새로 add를 해줘야한다.

add는 단순히 추적이 아닌 staging area에 올리는 것이다.

2가지 기능이 있다고 생각

(1) 새로운 파일을 staging area에 올린다.

(2) 변경된 파일을 staging area에 올린다.

$git commit -m "설명" 커밋할 때 구체적인 설명을 같이 입력한다. commit 명령어는 기록을 남긴다.

$git commit -am "설명" 모든 file을 자동으로 add하며 커밋도 진행한다. (단, untracked file은 커밋하지 않는다.)

staging area 에 올라온 file들을 기록시킨다.

$git log 커밋 기록을 보는 명령어이다.

$git diff 커밋번호..커밋번호 커밋간의 차이를 본다.

log화면에서 q를 누르면 나간다.

$git reset 커밋번호 커밋번호에 해당되는 버전으로 돌린다.

로컬 저장소일때만 사용 추천

gitignore 

gitignore 파일안에 git이 추적하지 않을 파일명을 등록하여 추적되지않게 할 수 있다.

"git add ." 해도 staging area에 등록되지 않는다.

$vim .gitignore gitignore 을 만든다.

*.파일형식 파일 유형 전체를 추적하지 않을경우 

주의점. 한번 추적된 파일은 gitignore에 등록해도 추적을 피할 수 없다. 

$git rm --cached 파일명 해당 명령어로 git cash를 지워주면 gitignore가 정상적으로 가능하다.

Git Branch

브랜치를 만드는 경우

• 테스트 기능을 만들어야하고, 결과적으로 원격저장소에는 올리지 않는 경우
• 기능이 사용될 가능성이 적은 경우
• 메인 프로젝트는 유지하며 커스텀 프로젝트를 만들 경우

이전 시점으로 돌아가서 브랜치를 만들지 않고  commit진행하고, 다른 브랜치로 이동하려고하면 불가능하다.

작업한 커밋에 대한 브랜치를 만들어줘야 다른 브랜치로 이동할 수 있다.

$git branch 현재 branch정보들을 볼 수 있다. (현재 check인 branch는 * 표시)

$git branch 브랜치 새로운 branch를 만든다.

$git branch -d 브랜치 branch를 삭제한다.

$git branch -D 브랜치 branch를 강제 삭제한다.

$git checkout 브랜치 현재 사용중인 branch를 checkout하고, 브랜치명 branch로 시점을 이동한다.

$git checkout -b 브랜치 브랜치를 만들면서 체크아웃도 진행

$git checkout 커밋 해시값 N자리

checkout 명령어는 HEAD 이동 명령어다. 커밋 번호가 존재하며 커밋번호 앞 N자리를 이용하여 시점을 이동한다.

$git log --branches --decorate --graph log들을 시각적으로 표현해서 보여준다.

$git diff 브랜치1..브랜치2 branch들 간의 차이를 본다. (윗 라인이 브랜치1, 아랫 라인이 브랜치2 / 브랜치2가 기준)

$git merge 브랜치2

현재 시점이 브랜치1인 상태라 가정한다.

merge하면 브랜치1로 브랜치2의 커밋들을 가져온다.

충돌이 없었다면 브랜치2의 커밋 내용이 브랜치1에 전부 merge되어 브랜치2는 삭제가 가능하다.

* 브랜치를 합치는게 아니라 해당 브랜치가 갖고 있는 커밋들을 합치는 것이다.

fast-forward

새로운 브랜치로 nb에서 commit을 진행하고 master에서 nb 커밋들을 이용하고자 할 때

(master는 commit진행을 하지않은 상황)

$git checkout master 

$git merge nb

master로 시점을 옮기고, nb를 merge하면 fast-forward가 진행된다.

3way-merge

[1 라인] 수정이 일어나지 않았으면 그대로 반영 (A A A) -> A

[2, 3 라인] 변경부분은 변경부분으로 반영 (H B B) -> H

[4 라인] 같은부분의 변경은 충돌을 직접 해결해줘야함 (H D T) -> 충돌 해결 필요

$git checkout master 

$git merge nb

master로 nb 커밋을 가져와서 merge완료함.

merge 충돌 해결

충돌이 일어나면 (브랜치|MERGING) 로 바뀐다

충돌이 일어난 파일을 수정해주고 commit을 해주면 된다.

$git stash 임시 저장을 만든다.

$git stash apply 임시 저장을 다시 불러와 적용한다.

원격 저장소 생성, fork, clone

로컬저장소 생성 후 원격 저장소(github) 생성

원격저장소 생성 - readme.md없이 만들어야 원격저장소 브랜치가 생성되지 않음

$git remote add origin 원격저장소주소 원격 저장소와 연결하며, origin이라는 명칭으로 사용하겠다.

$git push origin 브랜치명 브랜치 push

원격 저장소를 clone하여 가져오기

HTTPS 주소로 clone

$git clone HTTPS주소 [폴더명]

폴더명이 없다면 해당 폴더에, 있다면 추가로 폴더를 생성하고 그안에

원격 저장소에 대한 권한이 있다면 로컬 저장소 내역을 원격 저장소에 즉시 반영가능

브랜치 보호설정을 해놨다면 관리자의 PR허가필요

clone하면 기본적으로 master만 연동되고, 다른 원격 브랜치는 갖고 있기만 한다.

master가 아닌 브랜치는 따로 로컬에서 생성해 연결해주어야 한다.

원격 저장소를 fork하여 가져오기

fork 하게 되면 내 원격저장소에 프로젝트가 생성된다.

fork이후 clone을 통해 사용하면 된다.

fork한 프로젝트는 PR를 통해 기여할 수 있다.

Pull Request - 협력자가 원본 저장소의 관리자에게 merge를 요청하는 과정으로 협력자가 관리자에게 승인을 허가하도록 요청하는 것이다.

최종 merge는 원본 저장소의 관리자가 요청을 승인해야 merge 된다.

PR 방법

base: fork한 기존 프로젝트 / branch   <-----  head: fork한 내 저장소 프로젝트 / branch

브랜치를 새로 생성 후 commit 정리하고 PR요청

PR요청 전에  rebase dev 까지 해서 정리하고 PR. 바로 merge되도록.

요청하는쪽에서 정리하는 것이 바람직

PR이 허가되면 Main 브랜치에 merge된다.

원격 저장소 push & pull

$git ls-remote, git branch -r

원격저장소 branch를 보여준다.

Download

$git fetch --all
원격 저장소 모든 branch 다운로드

새로운 원격 branch가 있다면 알려준다.

$git fetch origin {원격브랜치}

원격 저장소 브랜치 하나만 다운로드

fetch한 branch로 checkout하고, 내용을 확인할 수 있다.

$ git merge {origin/원격브랜치}

다운로드한 브랜치와 merge한다.

$git pull origin {원격브랜치}

하나의 원격브랜치만 다운로드 & merge 하고자 할 때 사용한다.

기존 브랜치와 동기화를 해놨다면 merge된다.

* 주의: HEAD branch와 merge되므로 원하는 branch로 checkout한 후 진행해야 한다.

$git checkout {로컬브랜치} {origin/원격브랜치}

최초 동기화로 로컬 브랜치를 생성해서 원격 브랜치를 동기화

== git switch 원격브랜치

원격 저장소에 새로운 브랜치가 있을 때 로컬에도 새로운 브랜치를 만들어 동기화하여 사용하는 것이 정석

Upload

$git push origin {로컬브랜치 }

로컬 브랜치를 원격 저장소에 브랜치로 업로드

원격 저장소에 브랜치가 있다면 반영, 없다면 생성

$git push origin {로컬브랜치:원격브랜치}

브랜치이름이 다를 경우

$git push --all 

모든 브랜치를 원격 저장소에 올린다.

$git push origin --delete {원격브랜치}

원격 브랜치를 삭제한다.

$git push -f origin {브랜치}

로컬 브랜치에 맞게 원격 브랜치를 강제 수정할 때

리눅스 명령어

https://dora-guide.com/linux-commands/

[Git] Sourcetree rebase 재배치

rebase - 말 그대로 분기의 베이스(시작 위치)를 바꾸겠다는 말이다.

rebase와 merge는 브랜치를 합치는 역할이다.

merge를 쓰겠다면 굳이 쓰지 않아도 된다.

하지만 rebase만의 장점이 있다.

rebase가 merge보다 commit log가 깔끔해진다는 장점이 있다.

주의: 이미 공유된 커밋(main)은 리베이스하면 안된다. (커밋 해시 값이 변경됨)

main, newFunc 두 개의 브랜치가 있다.

base는 initial commit 이다.

브랜치 1, 브랜치 2가 각자 커밋이 진행하면

두 브랜치는 initial commit기점으로 하여 갈라지는 형태가 된다.

이 상태에서 rebase를 실행하려고 한다.

rebase를 하면 발생 문제 상황

 (1) 충돌이 나지 않는 경우

(2) 충돌이 나는 경우

(1) 충돌이 나지 않는 경우

rebase를 할 때는

현재 HEAD로 어떤 브랜치를 하고 있는지,

어떤 브랜치를 rebase로 사용할 것인지가 중요하다.

해당 사진은 브랜치 newFunc가 브랜치 main을 rebase 한 결과다.

newFunc(HEAD) -> rebase main

newFunc을 기준으로 main의 모든 커밋 내용들을 rebase됐다.

main에서는 newFunc까지 fast-forward 가능한 한줄기가 된다.

결과는 main commit내역이 밑으로 깔리고,

그 위로 newFunc가 이어서 작업한 것과 같은 형태가 된다.

rebase main

main의 마지막 commit을 새로운 base로 사용하겠다는 의미

main은 보통 공유하므로 rebase main을 하면 안된다.

rebase newFunc

newFunc의 마지막 commit을 새로운 base로 사용하겠다는 의미

rebase 대상을 HEAD branch 밑에 둔다

(2) 충돌이 나는 경우

충돌을 내기 위해 브랜치 newFunc와 브랜치 main이 같은 파일을 변경하고 커밋을 진행

이 상황에서 rebase를 하면 같은 파일을 변경했으므로 충돌이 일어난다.

newFunc(HEAD) -> rebase main

주의할 점은 newFunc(HEAD)에서 main을 rebase 했는데, 

병합 결과는 main(HEAD)로

HEAD가 바뀌어 나온다는 것이다.

이유는 rebase를 실행하면 HEAD가 main브랜치의 커밋 m1으로 이동한다.

그 후 지정하려는 main의 마지막 commit 부터 newFunc 브랜치의 커밋들을 위로 순차적으로 병합하게 된다.

현재 시점이 (m1)을 가르킨 상태에서 (1)을 병합하므로

HEAD(시점)은 (m1)이고 충돌은 (1)이 잡히는 것이다.

마찬가지로 (1)과의 병합을 마쳤다면 (2)를 병합을 해야한다.

cli 명령어

git rebase --continue

충돌이 발생하면 시점(HEAD)을 rebase로 하려는 브랜치로 옮기고 해당 위치부터

위로 순차적으로 기존 HEAD였던 브랜치의 커밋들을 병합하는 것이다. 

commit 로그 축약하기

interactive rebase

git rebase -i HEAD~3

커밋 3개 관리

명령어를 입력하면 나오는 화면

가장 최신 커밋 내용은 유지한채 최신 커밋을 줄인다. s (squash)

(pick)으로 3개의 커밋들을 병합

가장 아래가 최신 커밋 (내용은 유지하고, 커밋만 없앤다.)

https://meetup.toast.com/posts/39