archive 삭제

This commit is contained in:
2026-04-09 10:02:57 +09:00
parent ae55b4b130
commit 973af1937e
245 changed files with 0 additions and 3799 deletions
@@ -1,15 +0,0 @@
Repository
- 버전이 저장되는 저장소를 의미, 로컬과 원격 두 종류의 Repository가 존재
Working Dir (Working space)
- 작업을 수행하는 위치 경로, git이 동작해야하는 범위를 지정해주는 용도
HEAD
- 현재 Commit이 반영 될 위치
Origin
- 원격 저장소를 의미하며 Branch 앞에 Origin이 붙는 경우는 원격의 Branch를 의미
Conflict
- 동시 작업 후 병합을 진행 할 때 같은 변경 분으로 인한 충돌 상황
@@ -1,21 +0,0 @@
Git은 Linux 커널 Project를 지원하기 위해 만들어진 버전 관리 도구로써 시작되었음.
Git을 왜쓰냐 할 때
-> 너무 많이 사용되어진다. 지금 현재는 거의 대부분이 SVN대신 Git을 쓴다.
이것만으로도 Git을 써야하는 이유가 될 것 같다.
Git의 특장점
1. 빠른 속도 (버전을 만들어내는 속도)
2. ==자유로운 버전 생성과 공유==
( 로컬 저장소가 존재해서 로컬에 만들고 싶은 만큼 만들고 의미있는 버전만 리모트 저장소에 올릴 수 있다. )
( Work Branch를 여러개로 나누고 )
3. 원활한 복구
( 하나라도 repository가 남아있다면 나머지 모두가 삭제되어도 복구가 가능하다. )
SVN은 중앙 집중형, Git은 분산 관리형
SVN은 개인이 프라이빗한 버전을 만들 수 없다. (중앙 통제가 쉽다)
새로운 버전을 만들면 반드시 서버에 등록되게 된다.
1:N 환경
Git은 프라이빗한 버전을 만들 수 있다. 로컬에서 버전 생성 -> 원하면 push로 remote update.
N:N 환경,
@@ -1,11 +0,0 @@
```bash
git init --bare
```
하면 생성됨.
bare 저장소는 원격저장소 (Remote)를 의미하며 이 bare 저장소에서는
어떠한 깃 명령도 내릴 수 없다.
(단순 저장기능만 하는 저장소)
다만 이 bare 저장소를 clone해서 로컬에 git 저장소를 만들 수 있는데
이 clone 저장소에서는 git 명령어를 수행할 수 있다.
@@ -1,7 +0,0 @@
### 개발하고자 하는 기능을 관리하기 위한 branch.
- develop branch로 부터 가져와야 하며 다시 develop branch로 병합되야 한다.
- develop branch 이외의 브랜치와 병합하지 않는다.
- 일반적으로 개발자의 로컬에만 유지하고 origin에 푸시하지 않는다.
- develop branch에 병합하면 feature branch는 삭제한다.
![[Pasted image 20231207171556.png]]
@@ -1,5 +0,0 @@
### 긴급 버그 픽스를 위한 Branch
- master에서 가져오며 master와 develop branch로 병합한다.
- 핫픽스가 종료되면 branch를 삭제한다.
![[Pasted image 20231207171834.png]]
@@ -1,7 +0,0 @@
### 제품 또는 결과물을 Release 하기 위한 Branch
- develop branch에서 가져오며 develop과 master branch로 병합한다.
- 다음 릴리즈까지 개발이 최종 완료되었다고 판단하는 시점에서 branch를 생성한다.
- 설명을 보아하니 develop과 master 사이에 버퍼 브랜치 같은 느낌으로 활용해야 하는 것 같다.
release는 배포를 위한 브랜치이고 master는 root 같은 역할이랄까..
@@ -1 +0,0 @@
![[Pasted image 20231207171311.png]]
@@ -1,6 +0,0 @@
tag
stash
bundle
patch
apply
diff
@@ -1,34 +0,0 @@
형상관리 영역 중 Software의 버전을 관리
Who What When
-> 누가 언제 어떻게 바꾸었는가? 를 중점적으로 관리
(git의 영역이라 생각하면 될 듯)
버전관리를 하는 이유
1. 추적성 확보 및 가시화를 위함.
- Source code의 변경 이력을 구성
- 누가 언제 무엇을 변경했는지 이력 추적
2. 안정성 확보 및 자동화 (devOps)
- 모든 변경 내역을 보관/백업하며 잘못된 변경 내역을 빠르게 복구
- 변경 이력의 자동 관리부터 자동화 빌드/배포 등 자동화 구성을 위한 기본
3. 협업
- 동시 작업을 보다 안전하게 지원
- 공유 작업에 대한 변경 내용을 체계적으로 관리
버전관리의 형태
![[Pasted image 20231201134109.png]]
File 관리: 실제 파일단위로 관리, 동시접근 시 안전성을 보장해주지 않음.
내가 개발한 소스를 .zip파일 등으로 묶거나 해서 파일단위로 관리를 함.
Lock-Unlock: 누군가 파일을 수정하려고 하면 Lock이 걸리고 수정이 끝날때까지 다른사람은 접근할 수 없음.
Shared: 한 소스코드를 여러사람이 동시에 작업 가능, 코드 중복 시 conflict를 내는 식으로 관리됨
여기까지는 하나의 중앙 repository를 가지고 사용자가 Terminal 처럼 사용하였음.
DVCS: 분산형 버전 관리 시스템, Remote repository가 여러곳에 존재할 수 있음.
개인별 버전을 만들고 이것을 중앙 저장소에 전달하는 방식
Distributted Version Control System
일부는 여기에, 일부는 저기에, 또 어떤 일부는 다른곳에, 버전을 나눠가지는 스타일인모양
@@ -1,12 +0,0 @@
--squash 옵션을 쓴다.
```bash
git merge --squash br
```
하면 br에 있는 변경 내용 싹 다 가져오지만
커밋메시지는 가져오지 않는다.
이 상태에서 커밋을 새로하면 커밋 하나로 여러개의 커밋을 대신할 수 있다.
커밋은 하나하나의 작업단위로 묶어주는게 좋다.
@@ -1,8 +0,0 @@
원하는 커밋만 골라서 가져와 적용하는 명령어
```bash
git cherry-pick f0e434c // (7자리 혹은 commit id 전부 다)
```
용어 배경
수확자는 오직 가장 잘 익고 싱싱한 과일을 선택할 것이다. 선택된 과일을 보는 관찰자는 그러므로 과일의 대부분, 혹은 모두가 좋은 상태라고 결론 지을 것이다. 이는 관찰자가 나무에 있는 과일에 대해서 잘못된 인식을 갖게 한다
@@ -1,9 +0,0 @@
git reset --hard 커밋번호 다 적는거는 일반적은 git reset 사용법이 아닌가봄.
```bash
git reset --hard HEAD~2 // HEAD로 부터 2개의 커밋을 제거함.
```
이게 일반적인 사용법이라네..
--hard 하면 변경내용 파일들까지 다 제거하고
--soft 하면 커밋만 지우고 변경된 파일들은 staging된 상태가 된다.
@@ -1,12 +0,0 @@
Software Configuration Management
-> 이걸 왜 형상 관리라고 번역했을까?
소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 관리 방법
-> jira, git 등을 혼합해서 사용하는 프로젝트 진행 전반 과정 전체를 의미한다고 보면 될 듯
who what when how where why
버전관리는 형상관리에 포함됨
(형상관리를 한다 != 버전관린를 한다. 하지만 우리나라에서는 둘을 같게보는 경우가 많다)
계획부터 배포까지 모두를 의미함