컨벤션(Convention)이란?

(...in 위키백과)

컨벤션(convention)이란 용어는 cum이라는 라틴어(together를 의미)에서 con과, 라틴어 venire(to come의 의미)에서 vene이라는 말에서 유래한 것으로 '함께 와서 모이고 참석하다'의 의미를 가지고 있다. 즉 컨벤션이란 다수의 사람들이 특정한 활동을 하거나 협의하기 위해 한 장소에 모이는 회의(meeting)와 같은 의미라 할 수 있으며 전시회를 포함하는 좀 더 포괄적인 의미로 쓰이기도 한다. 콘퍼런스(Conference)라고도 한다.

 

그렇다면, 개발 컨벤션이란 뭘까?

개발 컨벤션은 코드 작성 시 지켜야 할 규칙과 스타일을 정의한 것!!

 

개발 컨벤션, 즉 개발 규칙은 개발자들끼리 원활한 협업을 하기 위한 중요한 규칙이다.

개발자들마다 코드 스타일이 제각각인데, 서로의 코드를 클린하게 이해하기 위해서는 필수적인 요소이다.

혹은, 본인이 작성한 코드더라도 오랜만에 그 코드를 까봤을 때 낯설게 느껴지는 경우도 많다.

 

개발 컨벤션은, 개발에 `이름표(식별표)`를 붙이는 것이나 다름없다!

 

그 중, 커밋 메시지에 대한 컨벤션을 포스팅해보려 한다.

 

커밋 메시지 컨벤션의 구조

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
  • type: 이 커밋이 어떤 목적의 변경인지
  • scope (선택): 어떤 파일/모듈/기능 범위인지
  • subject: 한 줄 요약
  • body (선택): 상세 설명 (무엇을 왜 바꿨는지)
  • footer (선택): 관련된 이슈나 breaking change 정보

 

1. 커밋 Title

커밋 타이틀은 `type : Subject` 의 형식을 따른다.

Type은 영어로 쓰되, 첫문자는 대문자로 한다.

Subject는 최대 50문자를 넘기지 않으며, 특수문자를 사용하지 않는다. 동사는 원형으로만 작성한다.

// 대표적인 Type 의 종류

feat	 새로운 기능 추가
fix	 버그 수정
docs	 문서 수정 (코드 변경 X)
style	 포맷, 세미콜론, 들여쓰기 등 순수 스타일 변경
refactor	 리팩토링 (기능 변화 없음)
test	 테스트 코드 추가/수정
chore	 빌드, 설정, 라이브러리 등 변경
perf	 성능 개선
build	 빌드 시스템 또는 외부 종속성 변경
ci	 CI 관련 설정 변경 (GitHub Actions, Jenkins 등)

 

2. 커밋 Body

본문의 경우 한줄당 72자 내로, 양에 구애받기보다는 최대한 상세히 적도록 해야한다.

How 보다는 What 과 Why 에 초점을 맞춰서 작성해야 한다.

(즉, 코드 자체를 설명하기보단, 어떤 요구사항에 의해 개발한건지, 어떤 버그에 의해 수정된건지 작성한다.)

 

3. 커밋 Footer

꼬리말은 선택사항이다.

이슈 트래커 ID를 작성할 수 있다. 이슈트래커 ID는 `#이슈 번호` 형식으로 작성한다.

`유형:#이슈 번호` 의 형식으로 작성하는데, 유형은 다음과 같다.

 

이슈 트래커 유형은 다음 중 하나를 사용한다.

  • Fixes: 이슈 수정중 (아직 해결되지 않은 경우)
  • Resolves: 이슈를 해결했을 때 사용
  • Ref: 참고할 이슈가 있을 때 사용
  • Related to: 해당 커밋에 관련된 이슈번호(아직 해결되지 않은 경우)
  • (ex) Fixes: #45 Related to: #34, #23

 

사용 예시

// 가장 기본적인 커밋
feat: 로그인 버튼 클릭 시 로그인 API 연동



// 기능 범위를 포함한 커밋
fix(login): 토큰 저장 오류 수정



// 본문과 이슈 연결까지 포함한 커밋

// 한 줄 요약 + 상세 설명 + 관련 이슈 연결
// GitHub PR이나 이슈에서 자동으로 #42 이슈를 닫아줌
feat(account): 비밀번호 변경 기능 추가

- 기존 API 명세에 따라 변경 요청 및 확인 로직 구현
- 버튼 클릭 시 확인 팝업 추가

Closes #42

 

 

커밋 메시지에 이모지를 사용할 수도 있다?!

https://gitmoji.dev/

 

gitmoji

:truck: Move or rename resources (e.g.: files, paths, routes).

gitmoji.dev

다음 사이트는 여러 이모지를 제공하는데, 이 이모지들은 커밋 메시지에서 사용이 가능하다! (!)

문자보다 더 직관적이게! 이모지로 커밋메시지의 타입을 구분할 수 있는 것이다!!!

 

깃 이모지 사용법에 대해서는 다음 블로그를 참고해보자. (너무 잘 정리되어 있다...)

https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-Gitmoji-%EC%82%AC%EC%9A%A9%EB%B2%95-Gitmoji-cli

 

⚡️ Gitmoji 사용법 정리 (+ 깃모지 툴 소개)

Gitmoji 란? gitmoji란 git + emoji를 합쳐서 부르는 말로 emoji를 이용하여 commit message를 작성하는 tool이라고 보면 될 듯하다. 지금까지 그냥 글로만 커밋 메세지를 써왔겠지만, 메세지에 이모지(이모티

inpa.tistory.com

 

 

 

 

 

그외 참고 블로그

https://m.blog.naver.com/so_no7/223507064379

 

GraduART [트러블 슈팅(1)] - 협업 시 개발 컨벤션 정리하기(코드, 커밋, PR, Git 브랜치 전략)

오늘은 GraduART 팀프로젝트에서 개발을 진행하기 전에 개발 컨벤션에 대해 고민했던 부분들을 정리하...

blog.naver.com

 

'DevOps > Git' 카테고리의 다른 글

git fetch VS git pull  (0) 2021.07.10
git push 할 때 conflict 해결 방법  (0) 2021.07.10
git push origin master 에서 origin 의 의미  (0) 2021.07.10
git merge 할 때 발생한 conflict 를 해결하는 방법  (0) 2021.07.09
git checkout VS git switch/restore  (0) 2021.07.09

Blue-Green 배포가 필요한 이유 : 무중단 배포(Zero Downtime Deployment)

무중단 배포란, 서비스를 사용하는 사용자가, 서비스의 새로운 버전으로 교체되는 와중에도 서비스의 중단을 경험하지 않는 것을 말한다. 새로운 기능을 배포할 때마다 기존 사용자 경험을 해치게 된다면 사용자의 서비스에 대한 신뢰도도 떨어지고 자꾸만 끊기는 서비스 가용성에 불편함을 느낄 것이다. 그러니까 우리의 목표는, 서비스의 구동이 끊기지 않으면서 안정적으로 서비스를 전환하는 것이다.

 

왜 Blue-Green 일까?

먼저 블루, 그린이란 각각 두 개의 운영 환경을 말한다. 그렇다. 블루와 그린 둘다 운영 환경이다. 다만 중요한 것은 두 환경은 정확히 동일하다는 것이다.

 

완벽히 동일한 환경이 일란성 쌍둥이처럼 두 개로 나뉘어져 있다고 이해하면 된다.

  • Blue (현재 운영 중인 버전 ex.v1 배포전 기존 환경) : 현재 사용자가 접근하고 있는 환경
  • Green (새로운 배포 버전 ex. v2) : 새로운 버전을 배포하고 테스트할 수 있는 환경

 

배포 과정에 대하여

  1. 새로운 버전을 Green 환경에 배포한다. (현재 Blue 환경이 운영중이다.)
  2. Green  환경에서 새로운 버전을 배포 후 , 충분히 테스트 해본다.
  3. 테스트가 실패하면 롤백한다. Green 을 이전 버전으로 돌린다. (다운타임없이 빠른 롤백 가능)
  4. 테스트가 성공하면 트래픽을 Blue 환경에서 Green 환경으로 전환한다.

 

GitLab 에서 무중단 배포를 실현하는 방법.

 

1. 먼저 Nginx 를 이용한 Reverse Proxy 서버가 필요하다.

upstream backend {
    server backend-v1:8083 backup;
    server backend-v2:8084;
}

upstream frontend {
    server frontend-v1:3000 backup;
    server frontend-v2:3001;
}

server {
    location /api/ {
        proxy_pass http://backend;
    }
    location / {
        proxy_pass http://frontend;
    }
}

 

참고로 예시로 든 환경은, 백엔드 서버와 프론트 서버가 각각 두개씩 구동중인 서비스이다.

 

 

2.GitLab CI/CD 파이프라인 설정

stages:
  - build
  - deploy-blue
  - deploy-green
  - switch-traffic

# 애플리케이션 빌드
build:
  stage: build
  script:
    - echo "Building application..."
    - ./gradlew build  # Spring Boot 빌드 예제
    - npm run build    # React 빌드 예제
  artifacts:
    paths:
      - build/

# Green 환경에 배포
deploy-green:
  stage: deploy-green
  script:
    - echo "Deploying to Green environment..."
    - ./deploy_backend.sh --green
    - ./deploy_frontend.sh --green
  only:
    - main

# 테스트 단계 (선택 사항)
test-green:
  stage: test
  script:
    - echo "Running tests in Green environment..."
    - ./run_tests.sh
  only:
    - main

# 트래픽 전환
switch-traffic:
  stage: switch-traffic
  script:
    - echo "Switching traffic from Blue to Green..."
    - ./switch_traffic.sh --green  # Nginx 설정 변경
  only:
    - main

 

Nginx 리버스 프록시를 설정한 후, GitLab CI/CD를 활용하여 Blue-Green 배포를 자동화할 수 있다.
GitLab에서는 .gitlab-ci.yml을 이용하여 여러 개의 스테이지를 정의하고, 배포 프로세스를 구성할 수 있다.

 

3. Nginx 에서 트래픽 전환 방법.

#!/bin/bash
echo "Switching traffic to Green..."

# 기존 Nginx 설정 백업
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

# Nginx 설정 변경 (Green 환경으로 트래픽 전환)
sed -i 's/backend-v1:8083 backup/backend-v1:8083;/' /etc/nginx/nginx.conf
sed -i 's/backend-v2:8084;/backend-v2:8084 backup;/' /etc/nginx/nginx.conf

# Nginx 재시작
nginx -s reload

echo "Traffic successfully switched to Green!"

 

sed -i 는 텍스트 파일을 직접 수정하는 리눅스 명령어이다.

sed -i 를 사용하면 Nginx 설정 파일(nginx.conf) 에서 특정 내용을 자동으로 변경할 수 있다.

s/찾을문자열/바꿀문자열/ 패턴을 사용하여 특정 내용을 변경한다.

 

Blue-Green 배포를 적용해야 하는 이유.

무중단 배포(Zero Downtime Deployment) 실현 → 사용자가 서비스 중단을 경험하지 않는다
빠른 롤백 가능 → 문제가 생기면 즉시 이전 버전(Blue)으로 되돌릴 수 있다.
실제 운영 환경에서 미리 테스트 가능 → Green 환경에서 충분히 테스트 후 트래픽을 전환할 수 있다.
부하 분산 및 확장 가능 → 여러 개의 인스턴스를 운영하며 부하를 나눌 수 있다.

 

 

그렇다고 무중단 배포가 무조건 정답은 아니다.

무중단 배포는 인프라의 복잡성을 증가시킬 수 있다. 예를 들어, 로드 밸런서, Nginx 리버스 프록시, 배포 자동화 도구 등의 설정이 필요하다. 이러한 인프라가 없거나, 배포 다운타임이 길지 않은 경우, 무중단 배포를 도입하는 것이 오히려 복잡한 문제가 될 수 있다.

 

서버 비용도 증가한다. Blue-Green 배포를 위해서 두 개의 운영 환경을 유지해야 하므로 인프라 비용이 두 배로 들 가능성이 있다. 스타트업이나 소규모 프로젝트에서는 유지 비용이 부담이 될 수 있다.

 

마지막으로 실은, 완벽한 무중단 배포는 거의 불가능하다. 프론트, 백, 디비까지 모두 신경써야하고 구버전 환경으로 롤백될 수 있는 가능성까지 전부 고려한 예외처리도 필요하기 때문이다.

'DevOps > CICD' 카테고리의 다른 글

[GitLab] 내장 CI/CD 사용방법  (1) 2025.02.01
[GitLab] 깃허브와 다른점이 뭘까?  (0) 2025.02.01

CI/CD ?

  • CI : Continous Integration (지속적 통합)
  • CD : Continuous Deployment/Delivery (지속적 배포)

개발자가 코드를 더 빠르고 안정적으로 빌드, 테스트, 배포할 수 있도록 도와주는 소프트웨어 개발 프로세스 자동화 기법을 말한다. 개발자가 코드를 Push(서버에 올리면) 자동적으로 해당 코드를 빌드하고 테스트 해주는 과정을 일컫는다.

 

또한, 작은 코드의 변경 사항을 주기적으로 통합해서, 버그를 초기에 미리 잡고 품질을 유지하는 것을 목표로 한다. 다른 개발자의 코드와 나의 코드가 원활히 병합되는 것을 지켜보고, 만약 실패한다면 개발자에게 알림을 보내는 것이다.

 

이때 CD 의 개념이 두가지로 나뉘는데,

 

첫번째, Continuous Delivery 로서는

코드가 안정적으로 지속적이게 배포되는 것을 Pipeline 자동화라고 하는데, CI 이후에 배포 준비까지 완료를 하지만, 운영 서버의 경우 개발자의 승인(Approve)해야 프로덕션 배포가 진행된다.

 

두번째, Continous Deployment 로서는

CI/CD 의 완전 자동화 버전이라고 하는데, 모든 변경 사항이 자동으로 프로덕션(운영 서버에) 배포되는 것을 말한다. 개발자의 별도 승인 과정 없이 코드가 Push 되자마자 배포까지 자동적으로 일어난다. 다만, 이 경우 서버에 올린 코드의 테스트가 잘 되었어야 할 것이다.

 

즉, 코드를 빠르고 안전하게 빌드, 테스트, 배포하는 자동화 프로세스를 위해서 만들어진 개념이다.

CI/CD 파이프라인으로 GitHub Actions, GitLab CI/CD, Jenkins 등이 존재한다.

다음으로 구성 요소에 대해서 알아보자.

GitLab Runner

GitLab CI/CD 파이프라인을 실행하는 프로그램이다. GitLab 의 경우 직접 CI/CD 를 실행시키지 않고, GitLab Runner 가 독립적으로 작업을 수행한다.

 

GitLab 은 '.gitlab-ci.yml' 파일을 올려놓으면, 해당 스크립트를 실행해서 CI/CD 파이프라인을 실행하는데, 이 설정 파일을 실행하는 역할을 하는 것이 바로 GitLab Runner 이다.

 

GitLab 에는 Runner 가 기본적으로 내장되어 제공되지만, 자체 서버에 GitLab Runner 를 설치하여 운영할 수도 있다. 그 설치 방법은 다음과 같다.

// Bash

// GitLab Runner 설치
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
sudo apt install gitlab-runner

// GitLab Runner 등록
sudo gitlab-runner register

// GitLab Runner 실행
sudo gitlab-runner start

 

Pipeline

Git 저장소에 Push 될 때(코드가 변경되었을 때) 자동으로 실행되는 자동화 프로세스, 즉 작업 흐름을 말한다.

 

코드가 Push 되거나 Merge Request(MR)가 발생하면 실행된다. 하나의 파이프라인은 여러 개의 스테이지들(Stages)과 작업들(Jobs)로 이루어진다.

 

Stage

파이프라인의 작업 단계를 의미한다.

일반적으로 build(빌드) - test(테스트) - deploy(배포) 의 단계로 순차적으로 실행된다.

이전 스테이지가 성공해야 다음 스테이가 실행된다.

 

Job

특정 스테이지에서 실행되는 개별 작업을 의미한다.

각 작업들은 특정 스크립트를 실행하고 결과를 반환한다.

잡들은 같은 스테이지 내에서 병렬적으로 수행된다.

 

예시

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "🔨 빌드 실행 중..."
    - mvn package

test-job:
  stage: test
  script:
    - echo "🛠️ 테스트 실행 중..."
    - mvn test

deploy-job:
  stage: deploy
  script:
    - echo "🚀 배포 중..."

 

이제 본격적으로 어떻게 GitLab 에서 CI/CD 를 구현할 수 있을지 단계적으로 알아보자.

 

GitLab Runner 등록 (gitlab-runner register)

1. GitLab Instance URL 입력

이는 깃랩이 어디에서 운영되고 있느냐에 따른 서버 주소를 지정해주는 것이다.

 

GitLab 공식 사이트를 사용할 경우는 https://gitlab.com 을 작성해주면 되고,

기업/조직에서 자체적인 서버에서 호스팅할 경우에는 해당 도메인을 작성해주면 된다.

 

즉, GitLab 이 실행되고 있는 서버의 URL 을 입력하면 된다.

 

2. 등록 토큰(Registration Token) 부여

이는 GitLab Runner 가 특정 GitLab 프로젝트 또는 그룹에 등록되려면 필요한 인증 정보같은 개념이다. 해당 토큰이 등록되어야 Runner 가 특정 프로젝트에 연결될 수 있다.

 

.gitlab-ci.yml 파일 추가

이 파일이 가장 핵심적이라고 할 수 있다. 이 설정 파일에 작성된 대로 파이프라인이 실행되기 때문이다.

 

다음과 같이 브랜치를 분리하여, 개발/운영 서버가 다른 브랜치에서 실행하도록 설정할 수도 있다.

 

다음 코드는

build 작업은 main 브랜치에서 운영 서버 1 - aws(Runner) 에서만,

deploy 작업은 main 브랜치에서 운영 서버 2 - 특정 서버(Runner) 에서만,

test 작업은 dev 브랜치에서 개발 서버 - 특정 서(Runner) 에서만 실행되도록 설정한 코드이다.

stages:
  - build
  - deploy

build-job:
  stage: build
  script:
    - echo "빌드 실행 중..."
  only:
    - main
  tags:
    - aws  # 운영 서버에서 실행

deploy-job:
  stage: deploy
  script:
    - echo "AWS 운영 서버에 배포 중..."
  only:
    - main
  tags:
    - production  # 운영 서버에서 실행

test-job:
  stage: test
  script:
    - echo "개발 서버에서 테스트 실행 중..."
  only:
    - dev
  tags:
    - dev  # 개발 서버에서 실행

 

 

실행 로그 확인

생각보다 단순하쥬?

'DevOps > CICD' 카테고리의 다른 글

[GitLab CI/CD] Blue-Green 배포 방식  (0) 2025.03.10
[GitLab] 깃허브와 다른점이 뭘까?  (0) 2025.02.01

GitHub, 전 세계적으로 인기있는 소스 코드 VCS

VCS는 Version Control System; 버전 관리 시스템을 말한다.

전 세계 대부분의 개발자들이 이 저장소를 가지고 있고, 협업 시에 활용하곤 한다.

Fork 와 FullRequest 가 주된 협업 방식으로 보여지는 플랫폼이다.

 

그렇다면 GitLab은 뭘까?

보안 이슈, 클라우드보다는 온-프레미스로 관리하고 싶어.

GitLab 은 특히 기업에서 많이 쓰인다. GitHub 에 비해 폐쇄적인 느낌이 있다.

 

GitHub 는 중앙 저장소를 두고, 클라우드 기반으로 운영된다. 그러나 기업이나 정부 기관의 경우는 공개된 클라우드에 회사의 자산을 함부로 저장하기에는 망설여지는 부분이 많았을 것이다. 이러한 요구에 맞춰서 나타난게 GitLab 이다. GitLab 은 회사가 소유한 서버에 저장소를 운영할 수 있다. 

자체적인 CI/CD 제공

GitLab 은 CI/CD 가 내장되어 있다. GitHub 의 경우에도 GitHub Actions 가 존재하지만, 따로 설정이 필요하다. 그러나 GitLab 은 애초에 처음부터 CI/CD 가 가능한 것이다. 마치 SpringBoot 에 톰캣 서버가 내장되어 있는 느낌인가..

 

버전관리 + CI/CD + 셀프 호스팅이 가능한 엔터프라이즈 DevOps 플랫폼

GitHub 가 버전관리와 오픈소스 협업에 있어서 정체성을 가지고 있다면,

GitLab 은 좀더 기업적이고 보안적인 관점이 크다.

'DevOps > CICD' 카테고리의 다른 글

[GitLab CI/CD] Blue-Green 배포 방식  (0) 2025.03.10
[GitLab] 내장 CI/CD 사용방법  (1) 2025.02.01

후.. Java version 맞춰놨더니 또 다른 오류가 뜬다..

인텔리제이에서 Spring Boot 프로젝트를 ./gradlew build 하다가 뜬 오류이다.

 

java.lang.NoSuchMethodError at SpringExtension.java:381

 

결론은 

Spring boot starter 가 이미 가지고 있는 라이브러리를 또 build.gradle에 추가해놔서

library끼리 충돌한 것으로 보인다.

 

나의 경우에 문제가 되었던 library는

test junit
  testImplementation 'org.junit.jupiter:junit-jupiter-api:5.8.2'
  testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.8.2'

 

이었고, 해당 코드를 build.gradle에서 주석 처리하고보니 해결이 되었ㄷ ㅏ ㅎㅎ

 

참고 블로그

https://mystria.github.io/archivers/fail-case-java-no-such-method-error

 

금주의 실패사례 - NoSuchMethodError의 정체 « Personal Tech Note

NoSuchMethodError 해결 잘 동작하던 Spring Boot Web Application에서 실행 중 NoSuchMethodError가 발생하기 시작했다. 에러 발생 개요 NoSuchMethodError는 없는 메소드를 호출할 때 발생한다. 그런데 그렇다면 compile

mystria.github.io

 

'DevOps > Build 도구' 카테고리의 다른 글

- Incompatible because this component declares a component, compatible with Java 17 and the consumer needed a component, compatible with Java 8  (0) 2024.03.16

해당 오류는 인텔리제이에서 Spring Boot를 build 하다가 생긴 오류이다.

오류 내용을 다시 읽어보자.

 

- Incompatible because this component declares a component, compatible with Java 17 and the consumer needed a component, compatible with Java 8

 

핵심은 Incompatible, 호환되지 못한 것 같다.

무엇이 호환되지 못했을까?

 

component가 Java 17 version에 맞게 선언을 하였는데,

소비자는 Java 8 version과 호환되어 있다고 하는 것이다.

 

그러면 Java version을 17로 올려서 호환을 해주어야 해결이 되는 오류일 것이다.

 

다음 명령어를 통해 Gradle version 을 확인해보자.

./gradlew build

 

1. 시스템 환경 변수를 바꿔준다 %JAVA_HOME%

2. intellij 에서 Gradle version 과 Project SDK를 확인해서 변경한다

 

1번으로 해결했따.ㅎ

'DevOps > Build 도구' 카테고리의 다른 글

java.lang.NoSuchMethodError at SpringExtension.java:381  (0) 2024.03.16

git fetch 와 git pull 의 차이점은?

 

 

fetch 의 경우

나의 로컬 HEAD 에 원격저장소의 변경내용을 붙여주는 형식으로 가져오게 된다.

 

 

 

pull 의 경우

나의 로컬 HEAD 와 원격저장소의 변경내용을 merge를 동시에 하면서 가져오게 된다.

'DevOps > Git' 카테고리의 다른 글

[Git] Commit Message Convention  (0) 2025.04.15
git push 할 때 conflict 해결 방법  (0) 2021.07.10
git push origin master 에서 origin 의 의미  (0) 2021.07.10
git merge 할 때 발생한 conflict 를 해결하는 방법  (0) 2021.07.09
git checkout VS git switch/restore  (0) 2021.07.09

0. 사건의 발생

원격저장소에서, 그리고 내 로컬저장소에서 둘다 같은 파일을 수정하게 되었다.

이러한 상황에서 내가 푸시를 하게 된다면 어떻게 될까?

그렇다! 컨플릭트가 발생할 것이다!

같은 파일을 수정했는데 각자 수정한 내용이 달랐기 때문이다.

이런 상황에서 해결할 수 있는 방법 몇 가지를 소개하고자 한다.

 

1. 원격저장소의 내용은 무시해버리기

// 강제로 내 로컬저장소의 내용만을 남기는 방법이다.
// -f 는 force 의 약자인 옵션이다.
git push -f

 

2. merge 처럼 처리하기

mergetool 을 이용하여 conflict 난 부분을 수정해주는 방법

 

3. 애초에 원격저장소에서 내 로컬로 pull 할시에 rebase 이용하기

git pull --rebase

위와 같은 명령어를 실행하게 되면 원격저장소에서 내 로컬로 파일을 가져올 때,

원격저장소에 내 현재 HEAD 커밋을 붙여주는 형식으로 가져오게 된다.

conflict 를 해결해주고 나면, merge로 처리했을 때처럼 지저분하지 않고, 깔끔하게 push를 진행할 수 있다.

'DevOps > Git' 카테고리의 다른 글

[Git] Commit Message Convention  (0) 2025.04.15
git fetch VS git pull  (0) 2021.07.10
git push origin master 에서 origin 의 의미  (0) 2021.07.10
git merge 할 때 발생한 conflict 를 해결하는 방법  (0) 2021.07.09
git checkout VS git switch/restore  (0) 2021.07.09

0. 질문의 발생

어느정도 깃허브를 사용할 줄 알게 되면, 이제 궁금증이 생기게 된다.

그냥 습관적으로 사용하던 push 에서 origin 은 도대체 왜 붙이는 거지?

git repository 에 존재하는 master branch 에 push 하는 명령어인건 알겠는데, origin 은 뭐지?

 

 

 

1. origin 의 정체

origin 은 바로 (어느정도는 눈치챘듯이) 원격저장소의 이름이다!

그러나 왜 origin 으로 이름을 지정하였는가 하면 통상적으로 첫 주인의 원격저장소는 그렇게 지정하기 때문이다.

 

 

 

2. 그렇다면, 다른 원격저장소도 추가할 수 있는 건가?

그렇다.

 

 

2-1. 현재 연결되어있는 원격저장소 확인하기

// 연결된 원격저장소의 목록을 확인할 수 있는 명령어
git remote

// 연결된 원격저장소의 주소까지 확인할 수 있는 명령어
git remote -v

 

 

 

2-2. 연결시킬 원격저장소 추가하기

git remote add (원격저장소명) (원격저장소url)

새로운 원격저장소 명을 만약에 server 로 하게 된다면,

이후에 git remote 명령어를 실행했을 때 실행결과는 다음과 같이 나올 것이다.

> git remote

origin
server

 

 

 

3. 특정 원격저장소의 정보를 더 자세하게 조회하는 방법

git remote show (원격저장소명)

// 예시
git remote show origin

'DevOps > Git' 카테고리의 다른 글

git fetch VS git pull  (0) 2021.07.10
git push 할 때 conflict 해결 방법  (0) 2021.07.10
git merge 할 때 발생한 conflict 를 해결하는 방법  (0) 2021.07.09
git checkout VS git switch/restore  (0) 2021.07.09
git tag 이용해서 특정 commit 에 북마크(책갈피) 추가하기  (0) 2021.07.09

0. 전통적인 방법

// 수동적 방법 : 해당 파일 직접 열어서 수정해주기
open (컨플릭트난 파일)

 

1. visual studio code 이용하기

// git config 파일에 다음과 같은 코드를 추가해준다.
[merge]
	tool = vscode
[mergetool "vscode"]
	cmd = code --wait $MERGED

다음과 같은 명령어를 실행하면 vscode 가 자동적으로 실행되면서

수정할 수 있는 창이 뜬다.

git mergetool

 

 

2. p4merge 툴 이용하기

>> 현업 개발자들이 많이 사용하는 p4merge 툴 다운받는 링크
https://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge		 

// git config 파일에 다음과 같은 코드를 추가해준다.
[merge]
	tool = p4merge
[mergetool "p4merge"]
	path = C:/Program Files/Perforce/p4merge.exe
[mergetool]
	prompt = false

다음과 같은 명령어를 실행하면 p4merge 가 자동적으로 실행되면서

수정할 수 있는 창이 뜬다.

git mergetool

 

'DevOps > Git' 카테고리의 다른 글

git push 할 때 conflict 해결 방법  (0) 2021.07.10
git push origin master 에서 origin 의 의미  (0) 2021.07.10
git checkout VS git switch/restore  (0) 2021.07.09
git tag 이용해서 특정 commit 에 북마크(책갈피) 추가하기  (0) 2021.07.09
git log 명령어로 commit 내용 한 번에 살펴보기  (0) 2021.07.09

+ Recent posts

티스토리툴바