GITBOOK-140: SVN 관련 정리

developLog/SUMMARY.md

@@ -147,6 +147,7 @@
   * [OAuth 앱에 대한 범위 및 gitbook과 github.io를 자동화를 위한 작업 1탄](ci-cd/github-action/oauth-gitbook-github.io-1.md)
   * [gitbook과 github.io를 자동화를 위한 gitaction 연동 - 워크플로우 작성과 문제](ci-cd/github-action/gitbook-github.io-gitaction.md)
 * [docker](ci-cd/docker.md)
+* [SVN](ci-cd/svn.md)
 
 ## 📔 Book
 

developLog/ci-cd/svn.md

@@ -0,0 +1,116 @@
+---
+description: 회사에서 사용하기에 적는 SVN 관련 지식
+icon: code-fork
+---
+
+# SVN
+
+## 1. svn 있잖아 그거에 구조에 대해서 그림 그려주고 설명해줘 특히 trank와 브랜치 등등
+
+SVN(서브버전)은 버전 관리 시스템으로, 소스 코드의 변경 사항을 기록하고 여러 개발자들 간의 협업을 지원합니다. SVN의 구조는 일반적으로 다음과 같은 디렉토리 구조로 관리됩니다:
+
+#### SVN의 일반적인 구조
+
+```
+/
+├── trunk
+├── branches
+└── tags
+```
+
+각각의 디렉토리 역할을 설명하겠습니다.
+
+1. **trunk**:
+   * `trunk`는 SVN 저장소의 메인 개발 라인입니다.
+   * 프로젝트의 가장 최신 버전의 코드가 이곳에 저장되며, 주로 개발자들이 최신 기능을 개발하고 수정하는 기본적인 브랜치라고 생각하면 됩니다.
+2. **branches**:
+   * `branches`는 `trunk`에서 파생된 기능 또는 실험적인 개발을 위한 별도의 작업 공간입니다.
+   * 큰 기능을 개발하거나 안정적인 릴리즈를 준비하는 경우 `branch`를 사용해 독립적으로 개발을 진행할 수 있습니다.
+   * 브랜치는 트렁크와 독립적으로 개발되며, 이후에 필요에 따라 `trunk`로 병합(Merge)할 수 있습니다.
+3. **tags**:
+   * `tags`는 특정 시점의 코드를 스냅샷처럼 저장하는 디렉토리입니다.
+   * 일반적으로 릴리즈나 마일스톤을 기록할 때 사용하며, 태그는 코드가 변경되지 않도록 읽기 전용으로 관리됩니다.
+   * 예를 들어, 버전 1.0의 릴리즈 코드를 기록하고 싶다면, `tags` 디렉토리 아래에 `v1.0`이라는 디렉토리를 만들고 그 시점의 코드를 복사해둡니다.
+
+이제 간단한 다이어그램을 통해 이 구조를 시각적으로 설명하겠습니다:
+
+```
++---------------------------+
+|        SVN Repository      |
++---------------------------+
+           |
+    +------+------+
+    |             |
++-------+     +-------+
+| trunk |     | tags  | 
++-------+     +-------+
+    |             |
++-----------+     +-----------+
+| branches  |     |  v1.0     |
++-----------+     +-----------+
+    |             |  v1.1     |
++------------+
+| feature-1  |
++------------+
+| hotfix-1   |
++------------+
+```
+
+#### 작업 흐름 예시:
+
+* **trunk**: 계속적으로 기능 추가와 수정이 일어나는 곳입니다.
+* **branches**: 예를 들어, 새로운 기능(feature-1)을 추가하기 위해 별도의 브랜치를 만들고 작업을 진행할 수 있습니다. 작업이 완료되면 trunk로 병합(Merge)합니다.
+* **tags**: 릴리즈가 되면, 그 시점의 trunk 코드를 tags 디렉토리에 저장하여 버전 관리를 합니다. 예를 들어 `v1.0` 릴리즈가 완료되면, tags/v1.0 아래에 코드를 보관하게 됩니다.
+
+이런 구조는 여러 개발자가 동시에 작업을 할 수 있도록 하면서도, 각 기능이나 릴리즈를 명확하게 분리하여 관리할 수 있는 장점이 있습니다.
+
+## 2. 깃은 보통 브랜치에 trunk가 연결되어 있지 않아?
+
+Git에서는 SVN과는 조금 다른 방식으로 브랜치 관리를 합니다. 그래서 일반적으로 **Git에는 'trunk'라는 개념이 없습니다**. 대신, **기본 브랜치**(default branch)가 존재하며, 그 이름은 대부분 **`main`** 또는 예전에는 \*\*`master`\*\*라고 불렸습니다.
+
+#### Git과 SVN의 차이점
+
+**1. trunk와 기본 브랜치**
+
+* **SVN의 trunk**: SVN에서는 `trunk`가 메인 개발 라인으로, 이곳에서 코드가 주로 관리됩니다.
+* **Git의 기본 브랜치**: Git에서는 이와 같은 역할을 하는 브랜치가 **`main`** 또는 예전의 \*\*`master`\*\*입니다. 그러나 Git에서는 `trunk`라는 이름을 사용하지 않고, 브랜치 이름은 커스터마이징 가능합니다. 기본적으로 저장소가 처음 생성되면, `main` 브랜치가 생성됩니다.
+
+**2. 브랜치 관리 방식**
+
+* **SVN**: SVN에서 브랜치는 독립된 디렉토리(`branches` 폴더)에서 관리됩니다.
+* **Git**: Git에서는 브랜치가 단순히 커밋을 가리키는 포인터로 작동하며, 전체 프로젝트 내에서 독립적인 디렉토리가 필요하지 않습니다. 브랜치끼리 빠르게 전환할 수 있으며, 새로운 브랜치를 만드는 비용이 매우 적습니다.
+
+#### Git에서의 기본 브랜치와 트렁크 개념
+
+Git에서는 기본적으로 다음과 같은 브랜치 구조가 있습니다.
+
+```
++---------------------------------+
+|          Git Repository         |
++---------------------------------+
+           |
+        +-------+
+        | main  |   <-- 기본 브랜치 (SVN의 trunk와 유사한 역할)
+        +-------+
+           |
+    +-------------+
+    | feature-1   |   <-- 새로 만든 기능 브랜치
+    +-------------+
+    | feature-2   |   <-- 또 다른 기능 브랜치
+    +-------------+
+```
+
+* **`main` 브랜치**: 프로젝트의 기본 브랜치이며, 보통 안정적인 코드를 유지하는 곳입니다. 대부분의 프로젝트에서 이 브랜치가 SVN의 `trunk`와 동일한 역할을 합니다.
+* **기능 브랜치**(feature branch): Git의 일반적인 워크플로에서는 각 기능이나 버그 수정에 대해 새로운 브랜치를 생성하여 작업하고, 완료되면 다시 `main` 브랜치에 병합(Merge)합니다.
+
+**3. 브랜치와 병합 전략**
+
+* **Git**: Git은 다양한 병합 전략을 지원합니다. 예를 들어, `rebase`나 `fast-forward` 병합 등이 있습니다. 이는 SVN과 달리 Git이 브랜치 간의 작업을 매우 유연하게 처리할 수 있게 해줍니다.
+* **SVN**: SVN에서는 병합이 Git에 비해 덜 유연하며, 브랜치끼리의 차이를 관리하고 병합하는 과정이 비교적 복잡할 수 있습니다.
+
+#### 요약
+
+* **SVN의 `trunk`**: 메인 개발 라인을 의미하며, 이곳에서 주로 작업이 진행됩니다.
+* **Git의 `main` (또는 `master`)**: Git에서는 `trunk`라는 용어를 사용하지 않지만, `main` 또는 `master` 브랜치가 SVN의 `trunk`와 유사한 역할을 합니다.
+
+따라서 Git에서는 **trunk가 별도로 존재하지 않으며, 브랜치와 관련된 모든 작업은 `main` 또는 사용자 정의 브랜치에서 이루어집니다**.