Built on the Apache Lucene library, it is primarily used for full-text search, log analysis, and application monitoring.

In this article, we will introduce how to install Elasticsearch from a compiled archive (.tar.gz) and set up a cluster.

Elasticsearch Installation​

Installation Environment and Elasticsearch Version

• OS: Ubuntu 24.04 LTS
• Elasticsearch: 8.17.2

For cluster configuration, prepare three virtual machines (VMs) as follows:

Download and Extract Archive​

First, download the Elasticsearch archive, extract it, and move it to the installation directory.

wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.17.2-linux-x86_64.tar.gz

tar -xzf elasticsearch-8.17.2-linux-x86_64.tar.gz
sudo mv elasticsearch-8.17.2 /opt/elasticsearch

cd /opt/elasticsearch

Create User and Set Permissions​

For security, create a separate user account and change the ownership of the Elasticsearch directory to that user.

sudo adduser elastic
sudo passwd elastic
sudo chown -R elastic:elastic /opt/elasticsearch

Systemd Service Configuration​

Create the /etc/systemd/system/elasticsearch.service file to register Elasticsearch as a service.

sudo vim /etc/systemd/system/elasticsearch.service

[Unit]
Description=Elasticsearch
After=network.target

[Service]
User=elastic
Group=elastic
ExecStart=/opt/elasticsearch/bin/elasticsearch
Restart=always
LimitMEMLOCK=infinity
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload

Firewall Configuration​

Allow the ports used by Elasticsearch and Kibana in the firewall.

sudo firewall-cmd --permanent --add-port=9200/tcp
sudo firewall-cmd --permanent --add-port=9300/tcp
sudo firewall-cmd --permanent --add-port=5601/tcp
sudo firewall-cmd --reload

Elasticsearch Cluster Configuration​

Generate & Deploy Certificates​

To secure inter-node communication, generate SSL/TLS certificates and deploy them to each node:

Generate the CA certificate on one of the nodes:

sudo -u elastic ./bin/elasticsearch-certutil ca
sudo -u elastic ./bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12

Copy the generated elastic-certificates.p12 file to the /opt/elasticsearch/config directory on each node:

sudo -u elastic scp elastic-certificates.p12 elastic@192.168.234.129:/opt/elasticsearch/config
sudo -u elastic scp elastic-certificates.p12 elastic@192.168.234.130:/opt/elasticsearch/config
sudo mv elastic-certificates.p12 config/elastic-certificates.p12

Configure elasticsearch.yml​

Assign a unique node.name for each node and add the necessary cluster settings:

sudo vim /opt/elasticsearch/config/elasticsearch.yml

cluster.name: es-cluster
node.name: node-1
network.host: 0.0.0.0

path.data: /opt/elasticsearch/data
path.logs: /opt/elasticsearch/logs

# List of cluster node IPs
discovery.seed_hosts: ["192.168.234.128", "192.168.234.129","192.168.234.130"]

# Specify master-eligible nodes for initial cluster formation (remove or comment out after initial setup)
cluster.initial_master_nodes: ["node-1", "node-2","node-3"]

# SSL/TLS settings
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.client_authentication: required
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12

cluster.name: es-cluster
node.name: node-2
network.host: 0.0.0.0

path.data: /opt/elasticsearch/data
path.logs: /opt/elasticsearch/logs

# List of cluster node IPs
discovery.seed_hosts: ["192.168.234.128", "192.168.234.129","192.168.234.130"]

# Specify master-eligible nodes for initial cluster formation (remove or comment out after initial setup)
cluster.initial_master_nodes: ["node-1", "node-2","node-3"]

# SSL/TLS settings
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.client_authentication: required
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12

cluster.name: es-cluster
node.name: node-3
network.host: 0.0.0.0

path.data: /opt/elasticsearch/data
path.logs: /opt/elasticsearch/logs

# List of cluster node IPs
discovery.seed_hosts: ["192.168.234.128", "192.168.234.129","192.168.234.130"]

# Specify master-eligible nodes for initial cluster formation (remove or comment out after initial setup)
cluster.initial_master_nodes: ["node-1", "node-2","node-3"]

# SSL/TLS settings
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.client_authentication: required
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12

Note: The cluster.initial_master_nodes setting is only necessary during the initial cluster formation. After the cluster is established, this setting should be removed or commented out. (Refer to Bootstrapping a cluster)

Start Cluster and Verify​

Start the Elasticsearch service on each node and then verify the cluster status.

Start the service:

sudo systemctl start elasticsearch

Reset the password for the elastic account:

sudo bin/elasticsearch-reset-password -u elastic -i

Check the node status:

curl -u elastic:your_pass http://192.168.234.128:9200/_cat/nodes?v

ip              heap.percent ram.percent cpu load_1m load_5m load_15m node.role   master name
192.168.234.130           19          89  88    1.30    0.80     0.37 cdfhilmrstw -      node-3
192.168.234.129           24          89   9    0.29    0.17     0.13 cdfhilmrstw -      node-2
192.168.234.128           10          90  17    0.00    0.00     0.00 cdfhilmrstw *      node-1

Check the cluster health:

curl -u elastic:your_pass http://192.168.234.128:9200/_cluster/health?pretty

{
  "cluster_name" : "es-cluster",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 3,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 3,
  "active_shards" : 6,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "unassigned_primary_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}

Kibana Integration​

For security reasons, the elastic account cannot be used with Kibana; instead, the built-in kibana_system account is utilized.

Reset the password for the kibana_system account:

cd /opt/elasticsearch
sudo bin/elasticsearch-reset-password -u kibana_system -i

Install Kibana​

wget https://artifacts.elastic.co/downloads/kibana/kibana-8.17.2-linux-x86_64.tar.gz
tar -xzf kibana-8.17.2-linux-x86_64.tar.gz
sudo mv kibana-8.17.2 /opt/kibana

Configure kibana.yml​

sudo vim /opt/kibana/config/kibana.yml 

server.port: 5601
server.host: "0.0.0.0"
elasticsearch.hosts: ["http://192.168.234.128:9200","http://192.168.234.129:9200","http://192.168.234.130:9200"]
elasticsearch.username: "kibana_system"
elasticsearch.password: "your_pass"

Kibana Startup​

cd /opt/kibana
nohup bin/kibana &

Now, access http://192.168.234.128:5601 (or the IP address of the node where Kibana is installed) in a web browser and log in with the elastic account.

Today, we introduced a simple way to install Elasticsearch and Kibana and set up a cluster.

The archive installation method is easy to install and manage, making it useful in various environments. Hope you find it helpful.

Today, I’m sharing how to use an AI editor for free by combining the VS Code Cline extension with ollama and DeepSeek R1.

Cline is an open-source AI coding assistant extension available for VS Code. It offers a variety of features that help with user commands and code generation, significantly boosting development productivity.

Other VS Code extensions offering similar functionalities include Continue and Roo Code. All of these are fairly well-tested tools with active communities.

Their basic setup procedures do not differ much, so you can choose the program that best suits your personal workflow. Note that Cline does not have a tab auto-completion feature, so combining Cline with Continue is also an option.

According to the token usage rankings on openrouter.ai , the token usage for Cline and Roo Code far exceeds that of others.

Cline,

• VS Code Marketplace
• Github (26.4k Stars)

Continue

• VS Code Marketplace
• Github (22.3k Stars)

Roo Code (prev. Roo Cline)

• VS Code Marketplace
• Github (4.9k Stars)

Running DeepSeek R1 Locally​

Why Run Locally?​

• Free and Low-Cost Operation: While Cursor AI incurs a monthly fee, Cline is available as open source and DeepSeek R1 can be run locally, allowing you to leverage powerful AI assistance without additional costs.
• Data Security: All AI computations occur on your local machine, ensuring that your code and related data are not transmitted to external servers, which greatly enhances privacy and security.
• Faster Response Times: Since DeepSeek R1 runs directly on your hardware, you avoid network latency and can expect lower delay compared to API call methods.

However, note that lightweight distilled models for local execution do not perform as well as full-parameter API models. For most developers, using an API platform—especially for non-English languages like Korean—might still be more practical. Running AI models locally should be approached with an experimental mindset.

Installing Ollama​

Ollama is a tool that makes it easy to run large language models like DeepSeek R1 locally.

• Download and install Ollama from the Ollama official website.

Downloading the Desired DeepSeek R1 Model​

Choose and download the model that suits your PC’s specifications.

For example, for the 7B model:

# https://ollama.com/library/deepseek-r1

# ollama run deepseek-r1:1.5b
ollama run deepseek-r1:7b
# ollama run deepseek-r1:8b
# ollama run deepseek-r1:14b
# ollama run deepseek-r1:32b
# ollama run deepseek-r1:70b

Once the model download is complete, it will automatically run locally.

pulling manifest
pulling 96c415656d37... 100% ▕████████████████████████████████████████████████████████▏ 4.7 GB
pulling 369ca498f347... 100% ▕████████████████████████████████████████████████████████▏  387 B
pulling 6e4c38e1172f... 100% ▕████████████████████████████████████████████████████████▏ 1.1 KB
pulling f4d24e9138dd... 100% ▕████████████████████████████████████████████████████████▏  148 B
pulling 40fb844194b2... 100% ▕████████████████████████████████████████████████████████▏  487 B
verifying sha256 digest
writing manifest
success
>>> hello?
<think>

</think>

Hello! How can I assist you today? 😊

>>>

You can access the locally running model at http://localhost:11434.

VS Code and Cline Setup​

Installing the VS Code Extension​

Search for Cline in the VS Code Marketplace and install it.

Connecting Cline to Ollama (Local DeepSeek R1)​

• Open Cline settings in VS Code.
• Select Ollama from the API Provider list.
• Enter http://localhost:11434 in the Base URL field and select the running DeepSeek R1 model (e.g., deepseek-r1:14b) from the model selection dropdown.

After successful local deployment of the DeepSeek model, a model selection window will automatically appear below the Model ID after entering the Base URL.

If you encounter an MCP hub not available error after sending a message, restarting VS Code should resolve the issue. Reference GitHub Issue

Testing​

Once setup is complete, test Cline by entering a prompt to confirm that it responds correctly.

If, after entering a prompt, your CPU is working at full throttle with a very slow or even no response, it indicates that your PC’s specifications might be insufficient for running that model. In such cases, we recommend testing with a lower model version.

API Integration Method​

• Obtain a DeepSeek API key from the DeepSeek official website.
• Open Cline settings in VS Code, select DeepSeek from the API Provider list, enter your API Key, and select the model deepseek-reasoner.

Now, you too can experience AI coding assistance at the level of Cursor—all for $0 a month! If you encounter any issues during setup, refer to the official Ollama documentation or the Cline GitHub issues page for help.

Particularly, DeepSeek R1 demonstrates performance comparable to OpenAI while causing market disruption through its cost-effective pricing and open-source distribution strategy.

In this article, we will explore how to integrate DeepSeek API with Spring AI in the simplest way possible and build a basic AI chatbot.

Spring AI: A Powerful Tool for AI Integration​

Spring AI is a project designed to integrate generative AI capabilities into the Spring ecosystem, making it easier for developers to incorporate AI models into their applications.

Key Features of Spring AI:

1. Standardized API: Provides a consistent interface for various AI providers (Anthropic, OpenAI, Microsoft, Amazon, Google, Ollama, DeepSeek, etc.).
2. Modular Architecture: A flexible structure that is not tied to a specific AI provider.
3. Easy Integration: Seamless integration using Spring Boot’s auto-configuration.
4. Extensibility: Support for custom models and options to handle advanced use cases.

Spring AI is particularly well-suited for enterprises looking to quickly adopt and scale AI functionalities.

DeepSeek: High Performance, Affordable Pricing​

DeepSeek, a previously lesser-known company, has gained significant recognition with the release of DeepSeek R1. Offering performance comparable to OpenAI’s models at a lower price, along with an open-source distribution strategy, the company has even shaken up the U.S. capital market.

Key Features of DeepSeek:

• High-performance LLM: Advanced language model matching OpenAI-o1 capabilities
• OpenAI-compatible API: Full compatibility with existing OpenAI-based applications
• Cost Efficiency: More affordable pricing than OpenAI

Prerequisites​

• Java 17+ installed
• Gradle 8+ installed
• DeepSeek API key obtained (Get your key from DeepSeek)
• Environment variable setup (It is recommended to store the API key as an environment variable instead of directly in application.yml.)

Implementation​

1. build.gradle Configuration​

Create a Spring Boot project and configure dependencies in build.gradle:

plugins {
    id 'java'
    id 'org.springframework.boot' version '3.4.2'
    id 'io.spring.dependency-management' version '1.1.7'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}

repositories {
    mavenCentral()
    maven { url 'https://repo.spring.io/milestone' }
    maven { url 'https://repo.spring.io/snapshot' }
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.ai:spring-ai-openai-spring-boot-starter:1.0.0-M5'
//    implementation 'org.springframework.ai:spring-ai-ollama-spring-boot-starter:1.0.0-M5'
}

The spring-ai-openai-spring-boot-starter dependency is compatible with all services that follow OpenAI’s API standard.

2. application.yml Configuration​

Next, configure application.yml to connect to the DeepSeek API and set model options.

By simply changing the values of base-url, api-key, and model, you can integrate with other language models as well.

spring:
  application:
    name: spring-ai-deepseek
  ai:
    openai:
      base-url: https://api.deepseek.com
      api-key: ${DEEPSEEK_API_KEY}
      chat:
        options:
#          model: deepseek-chat
          model: deepseek-reasoner
          stream-usage: false

#    ollama integration
#    ollama:
#      base-url: http://localhost:11434
#      chat:
#        options:
#          model: deepseek-r1:7b

3. Implementing the Controller​

Now, let's create a Spring Boot REST Controller to interact with DeepSeek API using Spring AI.

@RestController
@CrossOrigin(origins = "*")
public class ChatController {

    private final ChatClient chatClient;

    public ChatController(ChatClient.Builder builder) {
        chatClient = builder.build();
    }

    @PostMapping("/chat")
    public ChatResponse chat(@RequestParam String prompt) {
        return chatClient.prompt().user(prompt).call().chatResponse();
    }
}

API Testing​

Due to a surge in users, the Deepseek API service is still unstable. In case of API errors, please check the service status at the following link:

Check service status: https://status.deepseek.com/

Implementing a Chat UI​

I used Cursor to create a simple UI for testing, I encourage you to use any AI tools that work best for you to build a UI that fits your needs.

Conclusion​

In this guide, we explored how to integrate DeepSeek API with Spring AI and build a simple AI chatbot.

As DeepSeek continues to emerge as a strong competitor to OpenAI, it is expected to significantly impact the AI market in the future.

Cursor AI는 단순한 코드 편집기가 아닙니다. AI의 강력한 자연어 처리(NLP)와 코드 이해 능력을 기반으로 한 다목적 도구로, 개발자부터 콘텐츠 크리에이터에 이르기까지 다양한 사용자에게 혁신적인 생산성 향상을 제공합니다.

참고로, 뒤에 업데이트 하는 내용이지만 이번 포스트도 Cursor AI를 활용해 작성해보았습니다. 그동안 VS Code로 블로그 글을 작성해왔던 터라 나름 친숙한 느낌이 들었습니다.

대부분의 단어에 제안 문장이 뜨다 보니 귀찮은 부분도 없지 않았지만, 글의 틀을 잡고 문맥을 다듬는 데 있어서는 많은 도움을 받을 수 있겠다는 생각이 들었습니다.

1. 개발자를 위한 최적의 AI 코드 편집기
Cursor AI는 개발자에게 꼭 필요한 기능을 제공합니다.

• 코드 자동 완성: AI가 코드의 맥락을 이해하고, 다음에 작성할 코드를 예측하여 빠르게 제안.
• 버그 수정 및 디버깅: 코드 내 잠재적인 오류를 실시간으로 탐지하고, 수정 방안을 제시.
• 코드 리팩토링: 더 효율적이고 가독성 높은 코드로 개선하는 방법을 제안.
• 문서화 지원: 코드에 대한 설명을 자동으로 생성하여 개발 생산성을 높일수 있음.

2. 콘텐츠 크리에이터를 위한 AI 글쓰기 도구
Cursor AI는 개발 영역을 넘어 글쓰는 사람들에게도 강력한 도구로 활용될 수 있습니다.

• 자연어 생성: 블로거, 작가, 콘텐츠 크리에이터를 위해 아이디어 구상부터 문장 작성까지 AI 도움을 받을수 있음.
• 문서 요약: 긴 글을 간결하게 요약하거나, 핵심 포인트를 추출.
• 스타일 맞춤화: 특정 톤이나 스타일에 맞춰 글을 작성하거나 수정 가능.
• 번역 지원: 다양한 언어로의 번역을 통해 글로벌 콘텐츠 제작에 도움을 줄수 있음.

3. 다목적 AI Assist 도구로서의 가능성
Cursor AI는 단일 영역에 국한되지 않고, 다양한 업무와 프로젝트에 적용할 수 있습니다.

• 프로젝트 관리: 작업 목록 생성, 일정 관리, 보고서 작성 등 지원.
• 학습 및 연구: 복잡한 개념을 쉽게 설명하거나, 연구 자료를 정리하는 데 활용가능.

아래는 간단한 스네이크 게임을 만들어본 결과입니다.

Cursor 핵심기능​

Tab 자동완성​

Cursor의 기본기능은 문장이나 코드 앞뒤 문맥을 파악하여 코드제안을 하게 되는데, 이때 Tab 키로 코드제안을 수락할수 있습니다.

GitHub Copilot, JetBrains AI와 같은 기타 AI툴에서도 지원되는 기능이죠? Cursor의 Tab기능은 이 외에도 아래와 같은 차별화 된 기능을 제공하고 있습니다.

1. 멀티라인 자동완성(Multi-line Completion)

Cursor는 아래와 같이 멀티라인의 코드 제안/자동완성이 가능합니다.

2. Smart Rewrite

소스의 오류를 인지하여 자동으로 보정작업을 해줄수 있습니다.

3. 커서 예측(Cursor Prediction)

Cursor는 사용자가 다음에 편집하려는 위치를 예측하여 마우스 커서를 자동으로 이동시킬 수 있습니다.

예를 들어, 제가 함수에 파라미터 하나를 추가했을 때, Cursor는 두 가지 예측을 합니다. 하나는 payload에 추가 작업을 할 수도 있다는 예측(커서 이동), 또 하나는 boolean 파라미터를 사용해 if문을 생성할 수 있다는 예측입니다.

Chat (Ctrl/⌘ + L)​

Cursor Chat 기능은 코드 편집기 내에서 AI와 대화하며 코드 관련 질문을 하거나 문제를 해결할 수 있는 기능입니다.

1. 다양한 컨텍스트지원

컨텍스트(Context)는 상황, 배경, 맥락 등을 의미하며 요즘 흔히 말하는 Prompt도 컨텍스트의 일종의라고 볼수 있습니다. 컨텍스트에 따라 답변의 정확성, 비용 등에도 영향줄수 있으며 AGI의 활용에 있어서 상당히 중요한 역할을 합니다.

Cursor는 아래와 같이 다양한 컨텍스틀 지원합니다:

• 현재 파일 컨텍스트: 기본적으로 현재 열린 파일의 내용을 컨텍스트로 포함합니다. 이를 통해 AI는 코드의 특정 부분을 이해하고 관련된 답변을 제공할 수 있습니다.
• 프로젝트 전체 컨텍스트: @Codebase를 사용하여 전체 프로젝트를 컨텍스트로 포함할 수 있습니다.
• 외부 문서 및 웹 검색: @Doc을 통해 기술 문서를 참조하거나 @Web을 사용해 웹 검색 결과를 포함할 수 있습니다

2. 코드 적용 기능 (Apply)

AI가 제안한 코드를 바로 편집기에 적용할 수 있습니다. 코드 블록 우측의 "Apply" 버튼을 클릭하거나 Ctrl/⌘ + Enter를 눌러 변경 사항을 적용할 수 있습니다.

적용된 코드는 편집기에서 diff형태로 표시되며, 코드 블록 단위로나 파일단위로 변경을 수락할수 있습니다.

3. 채팅 이력 관리

AI화의 대화 기록은 이력으로 관리가 됩니다.AI 패널의 오른쪽 상단에 있는 'Previous Chats' 버튼을 누르거나, Ctrl/⌘ + Alt/Option + L을 누르면 채팅 기록을 확인할 수 있습니다.

4. AI 모델 전환

Cursor Chat은 여러 AI 모델을 지원하며, Ctrl/⌘ /를 눌러 모델을 전환할 수 있습니다. 선택한 모델은 이후 세션에서도 유지됩니다

Inline Chat(Ctrl/Cmd K)​

시작에 이력서 샘플 생성하면서 사용했던 기능입니다. 조금 단순한 지시나, 블록단위의 코드 생성/변경은 Ctrl/Cmd K를 사용하는게 많이 편리합니다.

Ctrl/Cmd K를 누른후 뜨는 창을 프롬프트 바(Prompt Bar)라고 부르며 Chat기능과 마찬가지로 @Codebase, @Doc, @Web 등 기능을 사용할수 있습니다.

변경을 원하는 코드 선택해서 누르거나, 코드 선택을 하지 않은 상태로 눌러 새로운 코드를 생성할수 있습니다.

Composer (Ctrl/⌘ + I)​

Composer 기능은 Chat기능과 달리 에디터에 직접 작용되며, 긴 텍스트와 코드를 체계적으로 작성하고 편집하는 데 최적화 되어있습니다.

Composer vs Chat

Composer는 실험적인 기능으로, Rule이나 prompt를 잘 짜서 사용하면 의외의 효과를 볼수 있습니다.

일반적으로 구조적이고 잘 정리된 요구사항을 prompt로 활용할 때 Composer 기능이 더 적합하며, 프리스타일의 질문/요청에는 Chat 기능이 더 적합합니다.

아래와 같이 prompt 입력후, 변경내역이 실시간으로 에디터에 반영됩니다. (참고로, 시작에 보여드린 스네이크 게임도 Composer를 사용한 결과물입니다.)

Rules for AI​

Cursor Rules란 Cursor의 AI 어시스턴트가 코드를 해석하고, 제안을 생성하며, 질문에 응답할 때 그 동작을 맞춤화하는 사용자 정의 규칙들입니다. Cursor Rules에는 두 가지 유형이 있습니다:

• 전역 규칙(Global Rules): 이 규칙은 모든 프로젝트와 파일에 적용되며, AI의 전반적인 동작을 정의합니다.(Cursor Settings > General > Rules for AI)
• 로컬 규칙(Local Rules): 이 규칙은 특정 프로젝트 또는 파일에만 적용됩니다.(프로젝트 root에 .cursorrules파일로 정의)

Cursor Rules는 아래와 같은 효과를 낼수 있습니다:

1. 코딩 스타일에 맞게 AI 응답을 맞춤화

   • AI가 생성하는 코드나 제안이 개인 또는 팀의 코딩 스타일과 일치하도록 설정할 수 있습니다.
   • 예를 들어, 들여쓰기 방식, 변수 명명 규칙, 코드 구조 등을 지정할 수 있습니다.

2. 팀 전체에 걸쳐 코딩 표준 강제 적용

   • 팀 전체가 동일한 코딩 표준을 따르도록 AI를 설정할 수 있습니다.
   • 이를 통해 코드베이스의 일관성을 유지하고, 코드 리뷰 과정을 단순화할 수 있습니다.

3. 코드 일관성 및 품질 향상

   • AI가 생성하거나 수정하는 코드가 항상 일관된 품질을 유지하도록 지침을 제공할 수 있습니다.
   • 예를 들어, 특정 보안 규칙이나 성능 최적화 기준을 준수하도록 설정할 수 있습니다.

4. 개발 워크플로우 간소화

   • 반복적인 작업을 자동화하고, AI가 개발자의 작업 흐름에 더 잘 통합되도록 설정할 수 있습니다.
   • 예를 들어, 특정 유형의 코드 생성 요청에 대해 항상 동일한 형식으로 응답하도록 설정할 수 있습니다.

결론: Cursor AI, 다목적 AI 도구로의 진화​

오늘은 Cursor의 핵심 기능에 대해 정리해봤습니다. Cursor는 단순한 코드 편집기를 넘어, AI의 힘을 활용해 다양한 분야에서 활용 가능한 다목적 도구로 자리 잡고 있습니다.

처음 Cursor를 접했을 때는 개발자들을 위한 코드 편집기로만 생각했지만, 실제로 사용해보면 그 이상의 잠재력을 발견할 수 있습니다. Cursor는 AI의 자연어 처리 능력을 바탕으로, 코드 작성부터 복잡한 문제 해결, 글쓰기와 콘텐츠 생성에 이르기까지 다양한 작업을 지원하는 강력한 도구입니다.

Cursor는 단순히 도구를 넘어, 사용자의 창의성과 생산성을 극대화하는 파트너 역할을 합니다. 여러분도 Cursor를 통해 더 스마트하고 효율적인 작업 방식을 경험해보시길 추천합니다.

Git: 더 이상 개발자만의 도구가 아니다!​

과거에는 주로 개발자들이 사용하는 전문 도구로 여겨졌던 Git은 이제 블로거, 작가, 그리고 노트 정리를 좋아하는 사람들에게도 필수 도구로 자리 잡고 있습니다.

Git이란?

Git은 간단히 말해 버전 관리 시스템입니다. 컴퓨터 파일의 변경 사항을 기록하고, 필요할 때 특정 시점으로 되돌아갈 수 있게 도와주는 도구입니다. 먼저, Git은 코드나 파일의 변경 내역을 기록하고, 여러 사람이 함께 작업할 때 충돌을 방지하는 버전 관리 시스템입니다. 쉽게 말해, 모든 작업을 안전하게 "저장"하고 "공유"하는 디지털 작업 공간입니다.

예를 들어, 여러분이 소설을 쓰다가 내용이 마음에 들지 않아 "일주일 전 버전으로 되돌리고 싶다" 고 생각할 때, Git은 그런 마법을 가능하게 해줍니다.

요즘은 Obsidian, Logseq 같은 노트 관리 도구와의 조합으로 개인 지식 관리(PKM) 에도 많이 활용되고 있습니다.

초보자 분들은 GUI tool로부터 시작하는걸 권장 드립니다. (Sourcetree, GitKraken, GitHub Desktop, VS Code 등)

Git 개념잡기​

Git Workflow​

---- Git Workflow ---
[작업 디렉토리 (Working Directory)]  🖥️
        |
        |  파일 작업 (수정, 추가, 삭제)
        |    |
        |    |  git add <파일>  (변경 사항 스테이징)
        |    ↓
        v
[스테이징 영역 (Staging Area)]      📦
        |
        |  git commit -m "메시지"  (변경 사항을 로컬 저장소에 저장)
        ↓
[로컬 저장소 (Local Repository)]  🏠
        |
        |  git push origin <브랜치>  (변경 사항을 원격 저장소로 푸시)
        ↓
[원격 저장소 (Remote Repository)] 🌍
        |
        |  git pull origin <브랜치>  (git fetch + git merge)
        ↓
[협력자의 로컬 저장소]  🏠
        |
        |  git merge 발생
        |    |
        |    |  충돌 해결 (Conflict Resolution, 필요한 경우)
        |    ↓
        v
[협력자의 작업 디렉토리 (Working Directory)]  🖥️

Git 용어정리​

포인터의 중요성​

Git은 다양한 개념과 명령어를 기반으로 동작하지만, 그 핵심은 포인터(pointer)를 중심으로 이루어져 있습니다.

Git에서 포인터는 저장소 내의 특정 커밋이나 참조를 가리키는 핵심 메커니즘입니다. 포인터는 커밋의 해시값, 브랜치명, 태그명 등을 통해 특정 시점의 코드 상태를 참조할 수 있으며, 이를 기반으로 효율적인 버전 관리와 브랜치 관리가 이루어집니다.

1. HEAD 포인터

• 현재 작업 중인 브랜치의 최신 커밋을 가리키는 포인터
• .git/HEAD 파일에 저장되어 있으며, 해당 파일은 HEAD가 가리키는 브랜치 이름 또는 특정 커밋 해시를 기록함.
• 만약 특정 커밋을 직접 체크아웃하면, HEAD는 "분리된 상태(Detached HEAD)"가 됨. 이 경우 HEAD는 브랜치 대신 커밋 해시를 직접 가리킴.(ref: refs/heads/main -> 88f4bc..)

HEAD 표현법 HEAD와 관련된 커밋을 참조할 때는 ^와 ~ 기호를 사용합니다.

1. HEAD^: HEAD가 가리키는 커밋의 직전 부모 커밋을 참조합니다.
   • HEAD^: 첫 번째 부모 커밋
   • HEAD^^: 두 세대 전의 커밋
   • HEAD^2: 두 번째 부모 커밋 (병합 커밋에서 유용)
2. HEAD~: HEAD가 가리키는 커밋에서 첫 번째 부모를 기준으로 몇 세대 이전의 커밋을 참조합니다.
   • HEAD~: 첫 번째 부모 커밋
   • HEAD~2: 두 세대 전의 커밋
   • HEAD~10: 10 세대 전의 커밋

HEAD^와 HEAD~의 차이점

• 단일 부모를 가진 커밋의 경우, HEAD^와 HEAD~는 동일한 커밋을 참조합니다.
• 병합 커밋의 경우:
  • HEAD^: 첫 번째 부모 커밋을 참조하며, HEAD^2는 두 번째 부모를 참조합니다.
  • HEAD~: 항상 첫 번째 부모를 기준으로 세대를 거슬러 올라갑니다.

차이를 보기 위하여 아래와 같은 예시를 보겠습니다. 브랜치 feature가 브랜치 main에 병합되면서 병합 커밋 M이 생성된 상황입니다.

A---B---C---M (main)
     \     /
      D---E (feature)

1. git show HEAD^2

   • HEAD는 현재 커밋 M을 가리키며, HEAD^2는 병합 커밋 M의 두 번째 부모 커밋인 E를 참조합니다.

2. git show HEAD~2

   • HEAD~2는 HEAD에서 첫 번째 부모를 두 번 거슬러 올라간 커밋, 즉 B를 참조합니다.

2. 브랜치 포인터

• 각 브랜치의 최신 커밋을 가리키는 포인터
• .git/refs/heads/ 디렉터리에 브랜치별로 저장
• 새로운 커밋이 생성되면 브랜치 포인터가 자동으로 이동

3. 태그 포인터

• 특정 커밋을 영구적으로 가리키는 포인터
• .git/refs/tags/ 디렉터리에 저장
• 태그가 특정 커밋을 안정적으로 가리키기 위한 목적으로 사용됨, 하여 일반적으로 한번 생성되면 변경되지 않음.

4. 원격 브랜치 포인터

• 원격 저장소의 브랜치를 가리키는 포인터
• .git/refs/remotes/ 디렉터리에 저장
• fetch 명령으로 업데이트됨

이러한 포인터들은 Git의 핵심 메커니즘으로, 버전 관리와 브랜치 관리의 기반이 됩니다. 특히 HEAD 포인터는 현재 작업 중인 위치를 나타내는 중요한 역할을 하며, 브랜치 포인터와 함께 Git의 분산 버전 관리 시스템을 가능하게 합니다.

Git 명령어​

1. 저장소 설정​

git config​

git config는 Git의 설정을 관리하는 명령어입니다. 이 명령어를 사용하여 사용자 이름, 이메일, 에디터, 별칭 등을 설정하거나 확인할 수 있습니다. 설정은 전역(global), 로컬(local), 시스템(system) 레벨에서 관리됩니다.

Git config 파일의 종류:

• system 설정 파일: 모든 사용자에게 적용 (많이 사용되지 않음)
  • macOS/Linux: /etc/gitconfig ,macOS 같은 경우 Homebrew로 설치시 /usr/local/etc/gitconfig에 위치하기도 함.
  • Windows: C:\Program Files\Git\etc\gitconfig
• global 설정 파일: 사용자 전체에 적용, ~/.gitconfig에 위치.
• local 설정파일: 특정 저장소에만 적용, <repo>/.git/config에 위치하.

-e 옵션으로 config 파일 위치 확인가능(예:git config --global -e)

global 설정 vs. local 설정: 일반적으로 사용자 정보는 전역 설정으로, 프로젝트별 설정은 로컬 설정으로 관리합니다.

config 우선순위: local 설정 > global 설정 > system 설정 순으로 우선순위가 적용됩니다.

사용예시:

# 현재 적용된 모든 설정 확인
git config --list

# 전역 설정 확인
git config --global --list

# 전역 설정에 사용자 이름 추가
git config --global user.name "John Doe"

# 전역 설정에 사용자 이메일 추가
git config --global user.email "john@example.com"

# 특정 설정 값 확인 (예: 사용자 이름)
git config --get user.name

# 특정 설정 삭제 (예: 사용자 이름)
git config --global --unset user.name

# 설정 파일 편집기로 열기
git config --global --edit

# 설정 값의 출처 확인
git config --show-origin user.name

git alias​

git alias는 자주 사용하는 긴 명령어를 짧은 별칭으로 설정하여 편리하게 사용할 수 있도록 도와주는 기능입니다.git config 명령어를 통해 설정하거나, .gitconfig 파일을 직접 편집하여 설정할 수 있습니다.

1. git config를 사용하여 alias 설정하기

# alias 설정 (자주 사용하는 alias)
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.unstage 'reset HEAD --'  # 스테이징 영역에서 파일 제거
git config --global alias.last 'log -1 HEAD'      # 마지막 커밋 확인
git config --global alias.amend 'commit --amend'  # 마지막 커밋 수정

# alias 확인
git config --get-regexp alias
# alias 삭제
git config --global --unset alias.<별칭>

# 사용 예시
git co main          # `git checkout main`과 동일
git br               # `git branch`와 동일
git ci -m "메시지"   # `git commit -m "메시지"`와 동일
git st               # `git status`와 동일
git unstage file.txt # `git reset HEAD file.txt`와 동일
git last             # `git log -1 HEAD`와 동일
git amend            # `git commit --amend`와 동일

2. .gitconfig 파일을 직접 편집하여 alias 설정하기 .gitconfig 파일을 직접 편집하여 alias를 설정할 수도 있습니다. .gitconfig 파일은 일반적으로 사용자의 홈 디렉토리(~/.gitconfig)에 위치합니다.

[alias]
    co = checkout
    br = branch
    ci = commit
    st = status
    last = log -1 HEAD
    lg = log --oneline --graph --decorate --all

2. 저장소 초기화 및 클론​

git저장소를 만드는 방식에는 아래와 같이 git init, git clone 2가지 방식이 있습니다.

git init​

git init은 새로운 Git 저장소를 초기화하는 명령어입니다. 이 명령어는 현재 디렉토리 또는 지정한 디렉토리에 .git이라는 숨겨진 하위 디렉토리를 생성하여 Git 저장소로 만듭니다.

사용예시:

# 현재 디렉토리에 새로운 Git 저장소 초기화
git init

# 지정한 디렉토리에 새로운 Git 저장소 초기화
git init my-repo

# 작업 디렉토리 없이 베어 저장소 초기화
git init --bare

# 초기화 과정에서 출력 최소화
git init --quiet

# 초기 브랜치 이름을 지정하여 초기화
git init --initial-branch develop

git clone​

git clone은 Git 버전 관리 시스템에서 원격 저장소(remote repository)에서 로컬 저장소(local repository)로 프로젝트를 복제하는 명령어입니다. 이 명령어는 원격 저장소의 전체 히스토리와 파일을 로컬 저장소로 가져오는 데 사용됩니다.

사용예시:

# 기본적인 복제
git clone https://github.com/user/repo.git

# 지정한 디렉토리에 복제
git clone https://github.com/user/repo.git my-directory

# 특정 브랜치만 복제
git clone --single-branch --branch main https://github.com/user/repo.git

# 얕은 복제
git clone --depth 1 https://github.com/user/repo.git

# 서브모듈 포함하여 복제
git clone --recurse-submodules https://github.com/user/repo.git

# 작업 디렉토리 없이 베어 저장소로 복제
git clone --bare https://github.com/user/repo.git

# 원격 저장소를 미러링하여 복제
git clone --mirror https://github.com/user/repo.git

3. 변경 사항 추적 및 관리​

git status​

git status는 현재 작업 디렉토리와 스테이징 영역의 상태를 보여주는 Git 명령어입니다. 즉, 어떤 파일들이 변경되었는지, 변경된 파일들이 커밋될 준비가 되었는지 등을 한눈에 확인할 수 있습니다.

git status 상태값 설명:

git status 옵션:

사용예시:

# 기본 상태 확인
git status

# 짧은 형식으로 상태 확인
git status -s

# 브랜치 정보 확인
git status --branch

# 추적되지 않은 파일의 상태 확인
git status --untracked-files=all

# 상세한 상태 정보 확인
git status --verbose

git add​

git add는 작업 디렉토리의 변경 사항을 스테이징 영역(staging area)에 추가하는 명령어입니다. 이 명령어는 커밋할 파일을 준비하는 데 사용되며, 변경 사항을 Git이 추적할 수 있도록 합니다.

사용예시:

# 특정 파일을 스테이징 영역에 추가
git add file.txt

# 현재 디렉토리의 모든 변경 사항을 스테이징 영역에 추가
git add .

# 작업 디렉토리의 모든 변경 사항을 스테이징 영역에 추가
git add -A

# 추적 중인 파일의 변경 사항만 스테이징 영역에 추가
git add -u

# 변경 사항을 인터랙티브하게 선택하여 스테이징 영역에 추가
git add --patch

# 무시된 파일도 강제로 스테이징 영역에 추가
git add --force

git diff​

git diff는 Git에서 변경 사항을 비교하는 명령어입니다. 이 명령어는 작업 디렉토리, 스테이징 영역, 커밋 간의 차이를 확인할 때 사용됩니다. 파일의 추가, 삭제, 수정 사항을 라인 단위로 보여줍니다.

사용예시:

# 작업 디렉토리와 스테이징 영역의 차이 확인
git diff

# 스테이징 영역과 최신 커밋의 차이 확인
git diff --cached

# 작업 디렉토리와 최신 커밋의 차이 확인
git diff HEAD

# 작업 디렉토리와 특정 커밋의 차이 확인
git diff abc1234

# 두 커밋 간의 차이 확인
git diff abc1234 def5678

# 변경된 파일의 통계 확인
git diff --stat

# 변경된 파일의 이름만 확인
git diff --name-only

# 변경된 파일의 이름과 상태 확인
git diff --name-status

# 출력에 색상 적용
git diff --color

# 단어 단위로 차이 확인
git diff --word-diff

# 공백 변경을 무시하고 차이 확인
git diff --ignore-space-change

# 특정 상태의 파일만 확인 (예: 추가된 파일)
git diff --diff-filter=A

# 공백 오류 검사
git diff --check

# 차이가 있는지 여부만 확인 (출력 없음)
git diff --quiet

git stash​

git stash는 작업 중인 변경 사항을 임시로 저장하는 명령어입니다. 현재 작업 디렉토리의 변경 사항을 스택에 저장하고, 깨끗한 상태로 만들어 다른 작업을 수행할 수 있습니다. 나중에 저장한 변경 사항을 다시 적용할 수 있습니다.

• git stash는 작업 디렉토리의 변경 사항을 스택에 저장합니다.
• 스태시는 여러 개 저장할 수 있으며, 각 스태시는 고유한 식별자(stash@{n})를 가집니다.

사용 예시:

# 작업 중인 변경 사항을 임시로 저장
git stash

# 메시지와 함께 변경 사항을 임시로 저장
git stash save "WIP: Working on feature X"

# 저장된 스태시 목록 확인
git stash list

# 가장 최근의 스태시 적용
git stash apply

# 특정 스태시 적용
git stash apply stash@{1}

# 가장 최근의 스태시 적용 및 스택에서 제거
git stash pop

# 가장 최근의 스태시 스택에서 제거
git stash drop

# 모든 스태시 스택에서 제거
git stash clear

# 가장 최근의 스태시의 변경 사항 확인
git stash show

# 가장 최근의 스태시의 변경 사항을 패치 형식으로 확인
git stash show -p

# 추적되지 않은 파일도 함께 스태시에 저장
git stash --include-untracked

git commit​

git commit은 스테이징 영역(staging area)에 있는 파일 변경 사항을 로컬 저장소에 저장하는 명령어입니다. 한 번의 커밋은 변경 사항의 논리적 단위를 의미하며, 작업의 스냅샷으로 볼수 있습니다.

commit의 구성 요소:

• 커밋 해시 (Commit Hash): 커밋을 고유하게 식별하는 40자리의 SHA-1 해시 값.
  • 해시 값은 커밋의 내용(변경 사항, 작성자, 날짜 등)을 기반으로 생성됨.
• 트리 객체 (Tree Object): 커밋 시점의 작업 디렉토리 구조를 나타내는 객체입니다.
  • 트리 객체는 파일과 디렉토리의 구조를 저장하며, 각 파일의 해시 값을 포함.
  • 이를 통해 커밋 시점의 파일 상태를 재구성할 수 있음.
• 부모 커밋 (Parent Commit): 현재 커밋의 이전 커밋(부모 커밋)을 가리키는 해시 값.
  • 일반적으로 하나의 부모 커밋을 가지지만, 머지 커밋의 경우 두 개 이상의 부모 커밋을 가질 수 있음.
  • 부모 커밋을 통해 커밋 히스토리를 추적 가능.
• 작성자 (Author): 커밋을 만든 사람의 이름과 이메일.
• 커미터 (Committer): 커밋을 실제로 저장소에 기록한 사람의 이름과 이메일. (작성자와 커미터가 다른 경우가 있음)
• 커밋 날짜 (Commit Date): 커밋이 생성된 날짜와 시간.
• 커밋 메시지 (Commit Message): 커밋의 변경 사항에 대한 기술.
• GPG 서명 (GPG Signature) (선택 사항): 커밋에 GPG 서명을 추가하여(--gpg-sign 옵션 사용) 커밋의 무결성(변조 여부)을 보장 가능.

사용예시:

# 스테이징 영역의 변경 사항을 커밋 (커밋 메시지 편집기 열림)
git commit

# 커밋 메시지를 직접 입력하여 커밋
git commit -m "Add new feature"

# 추적 중인 파일의 변경 사항을 자동으로 스테이징하고 커밋
git commit -a -m "Update tracked files"

# 최신 커밋을 수정 (커밋 메시지 변경 또는 파일 추가)
git commit --amend

# 커밋 전 후크(hook) 스크립트를 실행하지 않음
git commit --no-verify -m "Bypass hooks"

# 빈 커밋 생성 (변경 사항 없이 커밋)
git commit --allow-empty -m "Empty commit"

# 커밋 메시지에 Signed-off-by 줄 추가
git commit --signoff -m "Add signoff"

# 커밋 메시지를 수정하지 않고 --amend 수행
git commit --amend --no-edit

# 특정 커밋을 수정하기 위한 커밋 생성
git commit --fixup=abc1234

# 특정 커밋과 병합하기 위한 커밋 생성
git commit --squash=abc1234

git log​

git log는 Git 저장소의 커밋 히스토리를 확인하는 명령어입니다. 이 명령어는 커밋의 해시, 작성자, 날짜, 커밋 메시지 등을 확인할 때 사용됩니다.

사용예시:

# 커밋 히스토리 확인
git log

# 최근 5개의 커밋만 확인
git log -n 5

# 커밋 정보를 한 줄로 간단히 확인
git log --oneline

# 커밋에서 변경된 파일의 통계 확인
git log --stat

# 커밋에서 변경된 내용을 패치 형식으로 확인
git log --patch

# 커밋 히스토리를 그래프 형식으로 확인
git log --graph

# 커밋 정보를 예쁘게(pretty) 출력
git log --pretty=oneline

# 특정 날짜 이후의 커밋만 확인 (예: 2023-10-01 이후)
git log --since="2023-10-01"

# 특정 날짜 이전의 커밋만 확인 (예: 2023-10-31 이전)
git log --until="2023-10-31"

# 특정 작성자의 커밋만 확인 (예: 작성자 이름이 "John")
git log --author="John"

# 커밋 메시지에서 특정 패턴과 일치하는 커밋만 확인 (예: "bugfix")
git log --grep="bugfix"

# 특정 파일 또는 디렉토리의 커밋 히스토리만 확인 (예: src/main.c)
git log -- src/main.c

# 머지 커밋을 제외하고 확인
git log --no-merges

# 브랜치와 태그 정보를 함께 확인
git log --decorate

# 커밋 해시를 짧게 표시
git log --abbrev-commit

# 변경된 파일의 이름만 확인
git log --name-only

# 변경된 파일의 이름과 상태 확인
git log --name-status

# 모든 참조(브랜치, 태그 등)의 커밋 히스토리 확인
git log --all

git show​

git show는 특정 커밋, 태그, 또는 트리의 상세 정보를 보여주는 명령어입니다. 이 명령어는 커밋의 변경 사항, 작성자, 날짜, 커밋 메시지 등을 확인할 때 유용합니다.

사용예시:

# 특정 커밋의 상세 정보 보기
git show abc1234

# 특정 태그가 가리키는 커밋의 상세 정보 보기
git show v1.0.0

# 특정 트리의 상세 정보 보기
git show HEAD:path/to/file

# 커밋 정보를 한 줄로 간단히 보기
git show --oneline abc1234

# 커밋에서 변경된 파일의 통계 보기
git show --stat abc1234

# 커밋에서 변경된 내용을 패치 형식으로 보기
git show --patch abc1234

# 변경된 파일의 이름만 보기
git show --name-only abc1234

# 변경된 파일의 이름과 상태 보기
git show --name-status abc1234

# 커밋 정보를 사용자 정의 형식으로 출력
git show --format="%h - %an, %ar : %s" abc1234

# 패치 정보 없이 커밋 메시지만 보기
git show --no-patch abc1234

# 출력에 색상 적용
git show --color abc1234

# 커밋 메시지만 출력
git show --quiet abc1234

5. 브랜치 관리​

git branch​

git branch는 Git에서 브랜치를 생성, 조회, 삭제하는 명령어입니다. 브랜치는 작업을 분리하고 병합하는 데 필수적인 기능으로, git branch를 통해 브랜치를 효과적으로 관리할 수 있습니다.

사용 예시:

# 로컬 브랜치 목록 확인
git branch

# 새로운 브랜치 생성
git branch feature-branch

# 브랜치 삭제 (병합된 브랜치만 삭제 가능)
git branch -d feature-branch

# 브랜치 강제 삭제 (병합되지 않은 브랜치도 삭제 가능)
git branch -D feature-branch

# 현재 브랜치의 이름 변경
git branch -m new-branch-name

# 모든 브랜치(로컬 + 원격) 확인
git branch -a

# 원격 브랜치 목록 확인
git branch -r

# 현재 브랜치에 병합된 브랜치 목록 확인
git branch --merged

# 현재 브랜치에 병합되지 않은 브랜치 목록 확인
git branch --no-merged

# 현재 브랜치의 업스트림 설정
git branch --set-upstream-to=origin/main

# 현재 브랜치의 업스트림 설정 해제
git branch --unset-upstream

# 각 브랜치의 최신 커밋 메시지와 함께 브랜치 목록 확인
git branch --verbose

git checkout​

git checkout은 Git에서 브랜치를 전환하거나, 특정 커밋이나 파일로 작업 디렉토리를 되돌리는 데 사용되는 명령어입니다. 브랜치 전환, 파일 상태 복원, 커밋 체크아웃 등 다양한 작업에 활용됩니다.

현재는 git --help에도 조회가 안되지만 많이들 사용하는 명령입니다.

The git-checkout(1) command is seen by many as hard to understand because it connects two somewhat unrelated features: switching between branches and restoring worktree files from arbitrary revisions. In 2019, we thus implemented two new commands git-switch(1) and git-restore(1) to split out these separate concerns into standalone functions. (참고: Commit 028bb23)

명령어 하나로 브랜치 전환, 파일 복구 두 무관한 기능이 연결된다는게 사용자한테 혼란을 주고있다는 얘기입니다. 그래서 Git 2.23 이후로 git checkout 명령어는, 아래서 나오는 git-switch, git-restore 두 명령어로 분리가 되었습니다.

그래도 아직까지 광범위하게 사용되고 있는 관계로 deprecate계획은 없다고 하죠.

사용 예시:

# 특정 브랜치로 전환
git checkout main

# 새로운 브랜치 생성 및 전환
git checkout -b feature-branch

# 특정 커밋으로 이동 (Detached HEAD 상태)
git checkout abc1234

# 작업 디렉토리의 특정 파일을 최신 커밋 상태로 되돌리기
git checkout -- file.txt

# 작업 디렉토리의 모든 변경 사항을 최신 커밋 상태로 되돌리기
git checkout .

# 강제로 작업 디렉토리를 최신 커밋 상태로 되돌리기
git checkout -f

# 변경 사항을 인터랙티브하게 선택하여 되돌리기
git checkout --patch

# 원격 브랜치를 추적하는 로컬 브랜치 생성 및 전환
git checkout --track origin/feature-branch

# 현재 브랜치를 Detached HEAD 상태로 전환
git checkout --detach

# 브랜치 전환 시 충돌이 발생하면 자동으로 병합 시도
git checkout --merge feature-branch

git switch​

git switch는 Git 2.23 버전부터 도입된 명령어로, git checkout의 브랜치 전환 기능을 더 명확하게 분리한 명령어입니다. git switch는 브랜치 전환에 특화되어 있으며, git checkout보다 더 직관적이고 안전하게 사용할 수 있습니다.

사용예시:

# 특정 브랜치로 전환
git switch main

# 새로운 브랜치 생성 및 전환
git switch -c feature-branch

# 특정 커밋으로 이동 (Detached HEAD 상태)
git switch --detach abc1234

# 원격 브랜치를 추적하는 로컬 브랜치 생성 및 전환
git switch --track origin/feature-branch

# 충돌이 발생해도 강제로 브랜치 전환
git switch --force feature-branch

# 브랜치 전환 시 충돌이 발생하면 자동으로 병합 시도
git switch --merge feature-branch

git merge​

git merge는 두 브랜치의 변경 사항을 하나로 합치는 명령어입니다. 주로 기능 개발이 완료된 브랜치를 메인 브랜치에 병합할 때 사용됩니다. 병합은 Fast-forward, 3-way merge, Conflict Resolution(충돌해결) 등 다양한 방식으로 이루어질 수 있습니다.

병합 방식:

Fast-forward merge: --ff vs --no-ff :

* main 브랜치에서 feature 브랜치를 병합할 때
  - main:    A --- B --- C
                      \
  - feature:           D --- E --- F

1. `git merge --no-ff feature` 실행
  - main:    A --- B --- C ------------------- M
                      \                     /
  - feature:           D --- E --- F ---
  - 병합 커밋(M)이 생성됨
  - feature 브랜치의 히스토리가 main 브랜치에 그대로 유지됨
2. `git merge --ff feature` 실행 (Fast-Forward 가능한 경우)
  - main:    A --- B --- C --- D --- E --- F
                      \
  - feature:           D --- E --- F
  - 병합 커밋이 생성되지 않음
  - main 브랜치가 feature 브랜치의 최신 커밋으로 이동함

사용 예시:

# 현재 브랜치에 특정 브랜치 병합
git merge feature-branch

# Fast-forward 병합 비활성화 (항상 새로운 병합 커밋 생성)
git merge --no-ff feature-branch

# Fast-forward 병합만 허용 (불가능하면 중단)
git merge --ff-only feature-branch

# 특정 브랜치의 변경 사항을 Squash하여 병합
git merge --squash feature-branch

# 병합 중 충돌 발생 시 병합 중단 및 되돌리기
git merge --abort

# 충돌 해결 후 병합 계속 진행
git merge --continue

# 병합을 수행하지만 커밋하지 않음
git merge --no-commit feature-branch

# 병합 후 변경 사항 통계 보기
git merge --stat feature-branch

# 병합 전략 지정 (예: recursive)
git merge --strategy=recursive feature-branch

# 병합 전략 옵션 지정 (예: ours)
git merge --strategy-option=ours feature-branch

6. 원격 저장소​

git remote​

git remote는 원격 저장소를 관리하는 명령어입니다. 원격 저장소를 추가, 조회, 삭제하거나, 원격 저장소의 URL을 변경하는 등의 작업을 수행할 수 있습니다.

사용 예시:

# 등록된 원격 저장소 목록 확인
git remote

# 등록된 원격 저장소 목록과 URL 확인
git remote -v

# 새로운 원격 저장소 추가
git remote add origin https://github.com/user/repo.git

# 등록된 원격 저장소 삭제
git remote remove origin

# 원격 저장소 이름 변경
git remote rename origin upstream

# 원격 저장소 URL 변경
git remote set-url origin https://github.com/user/new-repo.git

# 특정 원격 저장소의 상세 정보 확인
git remote show origin

# 원격 저장소에서 삭제된 브랜치를 로컬에서 정리
git remote prune origin

# 원격 저장소의 모든 브랜치와 태그 업데이트
git remote update

# 특정 원격 저장소의 URL 확인
git remote get-url origin

# 원격 저장소에서 추적할 브랜치 지정
git remote set-branches origin main

# 원격 저장소를 추가하면서 특정 브랜치 추적 설정
git remote add --track main origin https://github.com/user/repo.git

git pull​

git pull은 원격 저장소의 변경 사항을 로컬 저장소로 가져와 병합하는 명령어입니다. git fetch와 git merge를 합친 기능으로, 원격 브랜치의 최신 상태를 로컬에 반영할 때 사용됩니다.

사용 예시:

# 현재 브랜치의 원격 저장소 변경 사항을 가져와 병합
git pull

# 특정 원격 저장소와 브랜치의 변경 사항을 가져와 병합
git pull origin main

# 변경 사항을 가져온 후 리베이스 수행
git pull --rebase

# Fast-forward 병합만 허용 (불가능하면 중단)
git pull --ff-only

# Fast-forward 병합 비활성화 (항상 새로운 병합 커밋 생성)
git pull --no-ff

# 작업 중인 변경 사항을 임시로 저장하고 병합 후 다시 적용
git pull --autostash

# 병합을 수행하지만 커밋하지 않음
git pull --no-commit

# 원격 저장소의 모든 태그를 가져옴
git pull --tags

# 태그를 가져오지 않음
git pull --no-tags

git push​

git push는 로컬 저장소의 변경 사항을 원격 저장소에 업로드하는 명령어입니다. 주로 로컬에서 작업한 커밋을 원격 저장소와 동기화할 때 사용됩니다. 브랜치, 태그, 또는 특정 커밋을 원격 저장소로 푸시할 수 있습니다.

사용 예시:

# 현재 브랜치의 변경 사항을 원격 저장소에 푸시
git push

# 특정 원격 저장소와 브랜치에 변경 사항 푸시
git push origin main

# 특정 태그를 원격 저장소에 푸시
git push origin v1.0.0

# 모든 브랜치의 변경 사항을 원격 저장소에 푸시
git push --all

# 모든 태그를 원격 저장소에 푸시
git push --tags

# 강제로 변경 사항 푸시 (주의: 원격 저장소의 기존 커밋을 덮어씀)
git push --force

# 강제로 푸시하되, 원격 브랜치가 로컬과 동일한 상태일 때만 수행
git push --force-with-lease

# 원격 저장소의 특정 브랜치 삭제
git push --delete origin old-branch

# 현재 브랜치를 원격 저장소에 푸시하고 업스트림 브랜치로 설정
git push --set-upstream origin feature-branch

# 푸시를 시뮬레이션 (실제로 푸시하지 않음)
git push --dry-run

# 원격 저장소에서 로컬에 존재하지 않는 브랜치 삭제
git push --prune origin

# 푸시 전 후크(hook) 스크립트를 실행하지 않음
git push --no-verify

# 푸시할 때 자동으로 태그를 함께 푸시
git push --follow-tags

git fetch​

git fetch는 원격 저장소의 변경 사항을 로컬 저장소로 가져오는 명령어입니다. git pull과 달리, fetch는 가져온 변경 사항을 자동으로 병합하지 않습니다. 따라서 원격 저장소의 상태를 확인하고, 필요할 때 수동으로 병합할 수 있어 보다 안전한 명령입니다.

사용 예시:

# 원격 저장소의 모든 변경 사항 가져오기
git fetch

# 특정 원격 저장소의 변경 사항 가져오기
git fetch origin

# 특정 원격 저장소의 특정 브랜치 변경 사항 가져오기
git fetch origin main

# 모든 원격 저장소의 변경 사항 가져오기
git fetch --all

# 원격 저장소에서 삭제된 브랜치를 로컬에서 정리
git fetch --prune

# 원격 저장소의 모든 태그 가져오기
git fetch --tags

# 강제로 변경 사항 가져오기 (원격 브랜치가 강제로 없데이트 되어, 원격 참조(브랜치, 태그, HEAD등)가 변한경우)
git fetch --force

7. 태그​

git tag​

git tag는 특정 커밋에 태그를 추가하거나 관리하는 명령어입니다. 태그는 일반적으로 릴리스 버전(예: v1.0.0)을 표시하는 데 사용되며, 커밋을 쉽게 참조할 수 있도록 합니다. 태그는 Lightweight 태그와 Annotated 태그로 구분됩니다.

• Lightweight 태그: 단순히 커밋을 가리키는 이름입니다. 추가 정보(메시지, 서명 등)가 없습니다.(git tag <tagname>로 생성.)
• Annotated 태그: 태그 이름 외에 메시지, 서명, 작성자 정보 등을 포함합니다. 일반적으로 릴리스 버전을 표시할 때 사용됩니다. (git tag -a <tagname>로 생성.)
• 태그 푸시: 태그는 기본적으로 git push로 원격 저장소에 푸시되지 않습니다. 태그를 푸시하려면 명시적으로 지정해야 합니다.(git push참고 )
• 태그 삭제(-d) 후 원격 저장소에서 태그를 삭제하려면 git push <remote> --delete <tagname>을 사용해야 합니다.

사용 예시:

# 모든 태그 목록 확인
git tag

# 현재 커밋에 Lightweight 태그 추가
git tag v1.0.0

# 현재 커밋에 Annotated 태그 추가 (메시지 입력 필요)
git tag -a v1.0.0

# Annotated 태그 추가 및 메시지 지정
git tag -a v1.0.0 -m "Release version 1.0.0"

# 특정 커밋에 태그 추가
git tag v1.0.0 abc1234

# 특정 태그 삭제
git tag -d v1.0.0

# 특정 패턴과 일치하는 태그 목록 확인 (예: v1.*)
git tag -l "v1.*"

# 특정 커밋을 포함하는 태그 목록 확인
git tag --contains abc1234

# 특정 커밋을 가리키는 태그 목록 확인
git tag --points-at abc1234

# 태그 목록을 버전 순으로 정렬
git tag --sort=version:refname

# 태그 목록을 역순으로 정렬
git tag --sort=-version:refname

# 기존 태그 강제로 덮어쓰기 (주의: 공개된 태그는 덮어쓰지 않는 것이 좋음)
git tag -f v1.0.0

# 태그에 GPG 서명 추가
git tag --sign v1.0.0

8. 로그 및 변경이력​

🔗git log​

🔗git show​

git blame​

git blame은 특정 파일의 각 줄을 마지막으로 수정한 커밋과 작성자를 확인하는 명령어입니다. 이 명령어는 코드의 특정 부분이 누구에 의해, 언제 수정되었는지 추적할 때 유용합니다.

사용 예시:

# 특정 파일의 각 줄을 마지막으로 수정한 커밋과 작성자 확인
git blame README.md

# 특정 파일의 10번째 줄부터 20번째 줄까지 확인
git blame -L 10,20 README.md

# 파일 내에서 복사된 코드의 원본 커밋 추적
git blame -C README.md

# 파일 내에서 이동된 코드의 원본 커밋 추적
git blame -M README.md

# 공백 변경을 무시하고 코드 변경만 확인
git blame -w README.md

# 작성자의 이메일 주소 표시
git blame -e README.md

# 커밋 해시의 전체 길이 표시
git blame -l README.md

# 커밋의 타임스탬프 표시
git blame -t README.md

# 커밋 해시의 짧은 버전 표시
git blame -s README.md

# 특정 커밋을 무시하고 결과 표시
git blame --ignore-rev abc1234 README.md

# 특정 파일에 나열된 커밋을 무시하고 결과 표시
git blame --ignore-revs-file .git-blame-ignore-revs README.md

git reflog​

git reflog는 Reference Logs의 약자로, Git에서 HEAD와 브랜치의 이동 기록을 보여주는 명령어입니다. 이 명령어는 실수로 삭제한 브랜치나 커밋을 복구할 때 매우 유용합니다. reflog는 로컬 저장소에서만 유지되며, 원격 저장소와는 동기화되지 않습니다.

사용 예시:

# HEAD의 이동 기록 확인
git reflog

# 특정 브랜치의 이동 기록 확인
git reflog main

# 모든 참조(브랜치, 태그 등)의 이동 기록 확인
git reflog --all

# 날짜 형식을 지정하여 기록 확인 (예: ISO 형식)
git reflog --date=iso

# 특정 시간 이후의 기록만 확인 (예: 2주 전부터)
git reflog --since=2.weeks.ago

# 특정 시간 이전의 기록만 확인 (예: 1일 전까지)
git reflog --until=1.day.ago

# 특정 패턴과 일치하는 기록만 확인 (예: "merge"가 포함된 기록)
git reflog --grep=merge

9. 파일 복구 및 취소​

🔗git checkout​

git reset​

git reset은 Git에서 커밋 히스토리를 되돌리거나, 스테이징 영역 및 작업 디렉토리의 상태를 변경하는 데 사용됩니다. 이 명령어는 커밋을 취소하거나, 파일을 스테이징 영역에서 제거하는 등 다양한 작업에 활용됩니다.

리셋의 세 가지 모드:

• --soft: HEAD만 이동합니다. 스테이징 영역과 작업 디렉토리는 변경되지 않습니다.
• --mixed (기본): HEAD와 스테이징 영역을 리셋합니다. 작업 디렉토리는 변경되지 않습니다.
• --hard: HEAD, 스테이징 영역, 작업 디렉토리를 모두 리셋합니다. (주의필요: 변경사항 영구 삭제됨)

사용 예시:

# 현재 브랜치의 HEAD를 특정 커밋으로 이동 (기본: --mixed)
git reset abc1234

# HEAD를 특정 커밋으로 이동하지만, 스테이징 영역과 작업 디렉토리는 변경하지 않음 (--soft)
git reset --soft abc1234

# HEAD를 특정 커밋으로 이동하고, 스테이징 영역을 리셋하지만 작업 디렉토리는 변경하지 않음 (--mixed)
git reset --mixed abc1234

# HEAD를 특정 커밋으로 이동하고, 스테이징 영역과 작업 디렉토리를 모두 리셋 (--hard)
git reset --hard abc1234

# 특정 파일을 스테이징 영역에서 제거
git reset file.txt

# 변경 사항을 인터랙티브하게 선택하여 스테이징 영역에서 제거
git reset --patch

# HEAD를 특정 커밋으로 이동하지만, 작업 디렉토리의 변경 사항을 유지 (--keep)
git reset --keep abc1234

git restore​

git restore는 Git 2.23 버전부터 도입된 명령어로, 작업 디렉토리나 스테이징 영역의 파일을 복원하는 데 사용됩니다.

사용 예시:

# 작업 디렉토리의 파일을 최신 커밋 상태로 복원
git restore file.txt

# 스테이징 영역의 파일을 최신 커밋 상태로 복원
git restore --staged file.txt

# 특정 커밋의 파일 상태로 작업 디렉토리 복원
git restore --source=HEAD~2 file.txt

# 작업 디렉토리의 파일만 복원 (스테이징 영역은 변경되지 않음)
git restore --worktree file.txt

# 변경 사항을 인터랙티브하게 선택하여 복원
git restore --patch file.txt

# 복원 과정에서 출력 최소화
git restore --quiet file.txt

# 병합 충돌이 발생한 파일은 복원하지 않음
git restore --ignore-unmerged file.txt

# 서브모듈의 변경 사항도 함께 복원
git restore --recurse-submodules

10. 리베이스​

git rebase​