Skip to content

Commit 3c5c31e

Browse files
Seony-YSeony-Y
committed
feat: posting
1 parent c21f24d commit 3c5c31e

10 files changed

+725
-22
lines changed

‎_config.yml‎

Lines changed: 15 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ theme: jekyll-theme-chirpy
99
lang: ko
1010

1111
# Change to your timezone › https://kevinnovak.github.io/Time-Zone-Picker
12-
timezone:
12+
timezone: Asia/Seoul
1313

1414
# jekyll-seo-tag settings › https://github.com/jekyll/jekyll-seo-tag/blob/master/docs/usage.md
1515
# ↓ --------------------------
@@ -28,17 +28,14 @@ url: "https://Seony-Y.github.io"
2828
github:
2929
username: Seony-Y # change to your GitHub username
3030

31-
twitter:
32-
username: seony # change to your Twitter username
33-
3431
social:
3532
# Change to your full name.
3633
# It will be displayed as the default author of the posts and the copyright owner in the Footer
37-
name: your_full_name
38-
email: example@domain.com # change to your email address
34+
name: seony
35+
email: seony1107@gmail.com # change to your email address
3936
links:
4037
# The first element serves as the copyright owner's link
41-
- https://twitter.com/username # change to your Twitter homepage
38+
# - https://twitter.com/username # change to your Twitter homepage
4239
- https://github.com/Seony-Y # change to your GitHub homepage
4340
# Uncomment below to add more social links
4441
# - https://www.facebook.com/username
@@ -109,7 +106,7 @@ toc: true
109106

110107
comments:
111108
# Global switch for the post-comment system. Keeping it empty means disabled.
112-
provider: # [disqus | utterances | giscus]
109+
provider: giscus # [disqus | utterances | giscus]
113110
# The provider options are as follows:
114111
disqus:
115112
shortname: # fill with the Disqus shortname. › https://help.disqus.com/en/articles/1717111-what-s-a-shortname
@@ -119,15 +116,15 @@ comments:
119116
issue_term: # < url | pathname | title | ...>
120117
# Giscus options › https://giscus.app
121118
giscus:
122-
repo: # <gh-username>/<repo>
123-
repo_id:
124-
category:
125-
category_id:
126-
mapping: # optional, default to 'pathname'
119+
repo: Seony-Y/Seony-Y.github.io # <gh-username>/<repo>
120+
repo_id: R_kgDOPnZClQ
121+
category: comments
122+
category_id: DIC_kwDOPnZClc4CuzbN
123+
mapping: pathname # optional, default to 'pathname'
127124
strict: # optional, default to '0'
128125
input_position: # optional, default to 'bottom'
129-
lang: # optional, default to the value of `site.lang`
130-
reactions_enabled: # optional, default to the value of `1`
126+
lang: ko # optional, default to the value of `site.lang`
127+
reactions_enabled: 0 # optional, default to the value of `1`
131128

132129
# Self-hosted static assets, optional › https://github.com/cotes2020/chirpy-static-assets
133130
assets:
@@ -153,9 +150,10 @@ paginate: 10
153150
baseurl: ""
154151

155152
# ------------ The following options are not recommended to be modified ------------------
156-
153+
markdown: kramdown
157154
kramdown:
158155
footnote_backlink: "&#8617;&#xfe0e;"
156+
input: GFM
159157
syntax_highlighter: rouge
160158
syntax_highlighter_opts: # Rouge Options › https://github.com/jneen/rouge#full-options
161159
css_class: highlight
@@ -223,4 +221,4 @@ jekyll-archives:
223221
tag: tag
224222
permalinks:
225223
tag: /tags/:name/
226-
category: /categories/:name/
224+
category: /categories/:name/

‎_posts/2025-09-01-Git-Flow.md‎

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
---
2+
title : Git Flow의 종류
3+
date : 2025-09-01 00:50:00 +9:00
4+
categories : [Git]
5+
tags : [Javascript, Git]
6+
---
7+
## Git Flow 란?
8+
### 소프트웨어 개발 시 브랜치 관리 전략 중 하나로, 프로젝트의 안정성과 효율적인 협업을 위해 여러 브랜치를 사용하며 5종류로 나뉜다.
9+
10+
### Master
11+
- 실제로 서비스에 배포되는 브랜치
12+
- production(운영) 출시 버전의 코드 모음집으로 프로젝트 시작시 생성
13+
- 주로 해당 브랜치는 릴리즈 태그가 된 커밋들만 포함됨
14+
- 모바일 어플리케이션의 경우, 주로 앱스토어에 출시된 버전별 코드들이 main 브랜치에 기록
15+
16+
### Develop
17+
- 새 버전에 대한 개발을 진행하는 브랜치
18+
- 지속적인 개발의 통합 브랜치로 브랜치로 기능별 커밋이 모이게 됨
19+
- 해당 브랜치는 main 브랜치에서 분기되며, 한 버전의 개발이 완료되면(출시 가능 상태가 되면) main 브랜치로 머지
20+
21+
### Feature
22+
- 개발의 기본 단위인 기능을 추가하기 위한 브랜치
23+
- 하나의 기능을 개발하기 위한 브랜치로 깃허브 이슈단위로 하나의 feature 브랜치가 생성
24+
- 기능별로 develop에서 분기되며, 기능 개발이 완료되면 다시 develop 브랜치로 머지
25+
- 기능별로 다른 feautre 브랜치로 분기해 작업함으로써, 여러 기능을 병렬적으로 작업할 수 있다.
26+
27+
### Release
28+
- Develop에서 새 버전에 대한 개발이 마무리되어 출시하기 위한 브랜치
29+
- 운영 버전으로의 출시 준비를 위한 브랜치로 develop 브랜치에서 한 버전에 대한 기능개발이 완료되었다고 판단되었을 때 분기 됨
30+
- 해당 브랜치의 코드로 운영 서버로 가기 전 최종 점검(QA)을 진행
31+
- QA에서 버그 발생시, 해당 브랜치에서 수정
32+
- QA 진행 완료 후, main 브랜치와 dev 브랜치로 머지
33+
34+
### Hotfix
35+
- 이미 출시된 버전에 버그가 발생 할 경우, 해당 버그를 수정하기 위한 브랜치
36+
- 말 그대로 빨리 고쳐야하는 버그
37+
- main 브랜치에서 분기되며, 버그 수정 후 main 브랜치와 dev 브랜치로 머지
38+
- 버그 수정 사항을 dev 브랜치에서도 반영해야 하기 때문
39+
40+
main, develop은 필수 브랜치이지만 나머지 브랜치는 유지 보수를 목적으로 하는 선택적인 브랜치이다.

‎_posts/2025-09-01-Git-Merge.md‎

Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,48 @@
1+
---
2+
title : Git_Merge의 종류
3+
date : 2025-09-01 00:40:00 +9:00
4+
categories : [Git]
5+
tags : [Javascript, Git]
6+
---
7+
## 1. Merge Commit(3-way merge)
8+
두 브랜치의 변경 사항을 모두 유지하며 메인 브랜치에 다른 브랜치를 merge하는 방식
9+
이 경우 각 브랜치의 변경 사항들이 과거의 커밋으로 보존되며, 병합 시 메인 브랜치에 새로운 'merge commit'이 추가되며 병합이 완료된다. feature 브랜치의 가장 최근 커밋이 메인 브랜치로 병합되는 것을 볼 수 있다.
10+
11+
### 특징
12+
- 프로젝트의 진행 상황을 명확히 추적할 수 있음
13+
- 브랜치 별 변경 사항이 유지되므로 커밋들의 아이디가 바뀌지 않음
14+
- 병합이 될 때마다 커밋이 생기므로 다양한 브랜치를 병합하면 커밋 로그가 매우 복잡해 질 수 있음
15+
- 대규모 인원이 참여하는 프로젝트에서는 복잡도가 빠르게 증가
16+
17+
## 2. Squash Merge
18+
병합할 브랜치의 모든 변경 사항을 하나의 커밋으로 합쳐 메인 브랜치에 병합
19+
이 경우 병합되는 브랜치의 변경 사항들은 사라지며, 모든 변경 사항이 합쳐진 한 개의 커밋이 새로운 아이디를 가지고 메인 브랜치에 추가되며 병합이 완료
20+
21+
### 특징
22+
- 커밋 히스토리를 간단하게 유지할 수 있음
23+
- 각 커밋들이 합쳐지며 가장 중요한 내용이 담긴 하나의 커밋으로 압축됨
24+
- 각 커밋에 담겨 있던 세부적인 작업 이력을 잃게 됨
25+
- 개별적인 맥락을 알 수 없으므로 문제가 발생한 부분을 찾기 어려움
26+
- 기존에 존재하던 커밋 아이디들이 하나의 새로운 아이디로 생성되므로 기존 브랜치를 기반으로 한 작업에 문제가 생길 수 있음
27+
- squash 방식을 사용한다고 해서 기존의 커밋 내역이 완전히 삭제되는 것은 아님
28+
- gitHub에는 기존의 커밋 내역들이 모두 남아있기 때문에 이전의 pull request를 찾아 해당 작업의 커밋 히스토리를 확인할 수 있다.
29+
30+
## 3. Rebase Merge
31+
현재 위치한 브랜치를, 병합시킬 타겟 브랜치에 재위치(rebase)시킨 뒤 병합
32+
기준이 되는 베이스 브랜치를 변경(re-base)한다고 생각하면 됨, 현재 위치한 브랜치의 모든 커밋을 타겟 브랜치로 옮기기 때문에 커밋 아이디가 변경, 브랜치가 분기되고 난 후에 발생한 커밋A, B가 각각 새로운 커밋으로 메인 브랜치에 병합
33+
34+
### 특징
35+
- 커밋 히스토리가 선형적으로 깔끔하게 유지됨
36+
- 깨끗한 히스토리 덕분에 변경 사항들을 쉽게 파악할 수 있음
37+
- 기존에 존재하던 커밋 아이디들이 각각 새로운 아이디로 생성되므로 기존 브랜치를 기반으로 한 작업에 문제가 생길 수 있음
38+
- 다양한 브랜치가 존재할 경우 병합이 어려움
39+
- 선형적이라는 특징으로 인해 특정 기능이 어디부터 어디까지의 커밋으로 구현되었는지 알 수 없음
40+
41+
## 4. Fast-forward Merge
42+
43+
- 새로운 merge commit을 생성하지 않고, 현재 위치한 브랜치의 최신 커밋 = HEAD가 가리키고 있는 커밋이 병합할 브랜치의 최신 커밋으로 이동하며 병합
44+
- 메인 브랜치에서 다른 브랜치가 분기되었지만, 다른 브랜치에서만 새로운 커밋이 생기고 메인 브랜치에서는 아무런 변화가 없는 경우 fast-forward merge가 발생, 분기된 후에 메인 브랜치에는 새로운 커밋이 생기지 않았으므로 메인 브랜치와 분기된 브랜치의 커밋 히스토리는 동일한 선 상에 위치하고 있다고 볼 수 있다.
45+
46+
### 특징
47+
- squash merge는 다른 브랜치의 커밋들을 합쳐서 하나의 커밋으로 만든 뒤 병합하지만, fast-forward merge는 기존의 커밋들이 유지
48+
- rebash merge는 메인 브랜치와 분기된 브랜치 둘 다에 새로운 커밋이 존재하는 상태에서 병합이 진행되지만, fast-forward merge는 메인 브랜치에는 변경 사항이 없는 상태에서 병합 됨.

‎_posts/2025-09-01-this와-렉시컬-스코프.md‎

Lines changed: 93 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,93 @@
1+
---
2+
title : 자바스크립트의 this와 렉시컬 스코프(Lexical Scope)
3+
date : 2025-09-01 00:50:00 +9:00
4+
categories : [Javascript]
5+
tags : [Javascript]
6+
---
7+
8+
## 1. 자바스크립트의 this
9+
- 자바스크립트에서 this는 함수가 호출되는 방식에 따라 달라지는 특별한 키워드이다.
10+
- this는 현재 실행 중인 컨텍스트(문맥)를 참조한다.
11+
12+
### 주요 특징
13+
- 일반 함수 호출 : 전역 컨텍스트에서는 this가 window(브라우저 환경) 또는 global(Node.js 환경)을 가리 킴
14+
- 메서드 호출 : 객체의 메서드로 호출하면, this는 그 객체를 가리 킴
15+
- 생성자 함수 : new 키워드로 호출하면, this는 새로 생성된 인스턴스를 가리 킴
16+
- 화살표 함수 : 화살표 함수는 자신만의 this를 가지지 않고, 상위 스코프의 this를 그대로 사용
17+
- 이벤트 핸들러 : DOM 이벤트에서 this는 이벤트가 바인딩된 요소를 가리 킴
18+
19+
```javascript
20+
function foo() {
21+
console.log(this);
22+
}
23+
foo(); // window 또는 global
24+
25+
const obj = {
26+
bar: function() {
27+
console.log(this);
28+
}
29+
};
30+
obj.bar(); // obj
31+
32+
function Person(name) {
33+
this.name = name;
34+
}
35+
const p = new Person('Tom');
36+
console.log(p.name); // Tom
37+
38+
const arrow = () => {
39+
console.log(this);
40+
};
41+
arrow(); // 상위 스코프의 this
42+
```
43+
44+
45+
## 2. 렉시컬 스코프(Lexical Scope)
46+
- 렉시컬 스코프(Lexical Scope)는 자바스크립트에서 변수의 유효 범위가 "코드가 작성된 위치"에 따라 결정되는 규칙이다.
47+
- 함수가 어디서 호출되는지가 아니라, 함수가 어디서 "정의"되었는지가 중요
48+
49+
### 동작 원리
50+
- 자바스크립트 엔진은 코드를 해석할 때, 각 함수가 어디서 선언되었는지 기준으로 스코프 체인을 만든다.
51+
- 함수 내부에서 변수를 찾을 때, 먼저 자신의 스코프(지역 변수)에서 찾고, 없으면 바깥(상위) 스코프로 올라가면서 찾음
52+
- 이 과정을 "스코프 체인"이라고 한다.
53+
54+
```javascript
55+
const a = 1;
56+
function outer() {
57+
const b = 2;
58+
function inner() {
59+
const c = 3;
60+
console.log(a); // 1 (전역 스코프)
61+
console.log(b); // 2 (outer의 스코프)
62+
console.log(c); // 3 (inner의 스코프)
63+
}
64+
inner();
65+
}
66+
outer();
67+
```
68+
69+
- inner 함수는 자신이 선언된 위치 기준으로 a, b, c 모두 접근할 수 있다.
70+
- 만약 inner를 다른 곳에서 호출하더라도, 선언된 위치의 스코프 체인을 따라 변수에 접근 함
71+
72+
### 호출 위치와의 차이
73+
74+
```javascript
75+
function foo() {
76+
const x = 10;
77+
function bar() {
78+
console.log(x);
79+
}
80+
return bar;
81+
}
82+
const baz = foo();
83+
baz(); // 10
84+
```
85+
86+
- baz는 bar 함수이지만, foo 함수가 끝난 뒤에 호출 됨
87+
- 그럼에도 bar는 x에 접근할 수 있는데, 이것이 렉시컬 스코프와 클로저의 특징
88+
89+
### 렉시컬 스코프의 장점
90+
- 코드의 가독성과 예측 가능성이 높아짐
91+
- 함수가 어디서 호출되는지 신경 쓸 필요 없이, 선언된 위치만 보면 변수 접근 가능 여부를 알 수 있음
92+
93+
- 렉시컬 스코프는 "함수가 선언된 위치"를 기준으로 변수의 접근 범위를 결정한다. 실행 시점이 아니라, 코드 작성 시점에 스코프가 정해지므로, 복잡한 코드에서도 변수의 유효 범위를 쉽게 파악할 수 있다.

‎_posts/2025-09-01-var-let-const-비교.md‎

Lines changed: 106 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,106 @@
1+
---
2+
title : var, let, const 를 중복 선언 허용, 스코프, 호이스팅 관점에서 서로 비교하기
3+
date : 2025-09-01 00:48:00 +9:00
4+
categories : [Javascript]
5+
tags : [Javascript]
6+
---
7+
8+
## 중복 선언 허용
9+
10+
- var은 중복 선언이 허용
11+
12+
```javascript
13+
var user = 1;
14+
console.log(user); // 1
15+
var user = 2; // JS에 의해 없는것 처럼 동작. 에러 또한 발생하지 않음
16+
console.log(user); // 2
17+
// 의도치 않은 변수값이 재할당되어 변경될 수 있다.
18+
19+
let, const는 중복 선언이 허용되지 않음
20+
let user;
21+
let user ; // SyntaxError: identifier 'user' has already been declared
22+
```
23+
24+
## 스코프
25+
- 함수 레벨 스코프 : 함수를 기준으로만 적용되는 스코프
26+
- 블록 레벨 스코프 : 코드블록({} 중괄호)을 기준으로 적용되는 스코프
27+
- var로 함수 내부에서 선언한 변수는 지역 스코프, 함수 외부에서 선언한 변수는 전역 변수이다. 블록 기준으로 스코프가 생기지 않기 때문에 블록 밖에서 접근 가능
28+
- if, for, while, switch 등 다양한 상황에서 전역 변수로 사용할 수 있다.
29+
30+
```javascript
31+
var c = 4;
32+
33+
if(true){
34+
var a = 11;
35+
console.log(a); // 11
36+
}
37+
function fnc(){
38+
var b = 55;
39+
var c = 44;
40+
console.log(b); // 55
41+
}
42+
console.log(a); // 11
43+
console.log(b); // ReferenceError: b is not defined
44+
console.log(c); // 44
45+
46+
let, const로 선언한 변수는 블록 레벨 스코프이다. 코드 블록 내에서만 유효하며 블록 외부에서는 참조할 수 없다.
47+
let a = 11; // 전역 변수
48+
49+
if(true){
50+
let b = 22; // 지역 변수
51+
console.log(b); // 22
52+
}
53+
console.log(a); // 11
54+
console.log(b); // ReferenceError: a is not defined
55+
```
56+
57+
## 블록 레벨 스코프의 중첩
58+
59+
```javascript
60+
let i = 10; // 전역 스코프
61+
function foo(){
62+
let i = 100; // 함수 레벨 스코프
63+
64+
for(let i = 1; i< 3; i++){ // 블록 레벨 스코프
65+
console.log(i); // 1 2
66+
}
67+
console.log(i); // 100
68+
}
69+
70+
foo();
71+
72+
console.log(i); // 10
73+
```
74+
75+
## 호이스팅
76+
- var로 선언한 변수는 호이스팅에 의해 변수 선언문이 스코프의 선두로 끌어 올려진 것처럼 동작
77+
- var로 선언한 변수는 변수 선언문 이전에 참조할 수 있다. 단 할당문 이전에 변수를 참조하면 undefined를 반환
78+
79+
```javascript
80+
// 이 위치로 호이스팅에 의해 a변수가 선언
81+
// 변수 a는 undefined로 초기화
82+
console.log(a); // undefined
83+
84+
// 변수에 값을 할당
85+
a = 50;
86+
87+
console.log(a); // 50
88+
89+
// 호이스팅에 의해 상단에 선언
90+
var a;
91+
```
92+
93+
- let, const로 선언한 변수는 호이스팅이 발생하지 않은 것처럼 동작
94+
- 스코프의 시작 지점부터 초기화 시작 지점까지 변수를 참조할 수 없는 구간을 일시적 사각지대라고 한다.
95+
96+
```javascript
97+
// 런타임 이전에 선언 단계가 실행 아직 변수는 초기화 되지 않음
98+
// 초기화 이전의 일시적 사각지대에서는 변수를 참조할 수 없음
99+
console.log(a); // ReferenceError: a is not defined
100+
101+
let a;
102+
console.log(a); // undefined
103+
104+
a = 1;
105+
console.log(a); // 1
106+
```

0 commit comments

Comments
 (0)