여러 개발자가 하나의 저장소를 사용하는 환경에서 저장소를 효과적으로 사용하기 위해 효율적인 브랜치 관리를 돕고, 협업의 복잡성을 줄이며, 코드의 안정성을 유지하는 데 중요한 역할을 한다.

브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론을 말한다.

신입 개발자로 회사에 입사해 실무를 들어가면 "어떤 브랜치가 최신 브랜치인지" "배포 버전은 어떤 걸 골라야하지" "완성된 작업물을 어디에 push 해야하지" 당황스러울 것입니다. 바로 이런 상황을 최소화하기 위해 만들어진 방법론이 git flow 브랜치 전략이다.

특징

1. 용도에 맞게 브랜치를 분리해서 사용 단, master, develop 브랜치는 중심이 되는 브랜치라서 무조건 존재해야한다.
2. 명확한 릴리즈 버전 관리를 위한 브랜치를 따로 관리하기 때문에 한 버전에 대한 유지보수가 용이하다.
   
   

각 브랜치 설명

master(main): 배포 가능한 상태만을 관리하는 브랜치 develop: 다음에 배포할 것을 개발하는 브랜치 feature: 추가 기능을 개발하기 위한 브랜치 release: 다음 버전 출시를 준비하는 브랜치 hotfix: master 브랜치에서 발생한 버그를 수정하는 브랜치

git flow 흐름

실제 git 브랜치 전략의 흐름을 크게 3가지 경우로 정리하면 아래와 같다.

*5가지 중 항상 유지되는 메인 브랜치(2) : master(main), develop

1. 기능 개발

(1). 새로운 기능을 구현하기 위해 Develop 브랜치로부터 Feature 브랜치를 생성한다. (2). Feature 브랜치에서 기능을 개발한다. (3). Feature 브랜치의 기능 구현이 완료되면 Develop 브랜치에 병합하기 위한 PR을 작성한다.

2. 라이브 서버로 배포

(1). Dvelop 브랜치에 Feature 브랜치가 병합되었다면, QA를 위해 Develop 브랜치로 부터 Release 브랜치를 생성한다. (2). QA 테스트를 통과했다면 Release 브랜치를 Develop, master 브랜치에 병합한다.

3. 배포 후 발생한 오류 대처

(1). 만약 master 브랜치에서 버그가 발견된다면, master 브랜치에서 Hotfix 브랜치를 생성한다. (2). 버그를 해결하고 Hotfix 브랜치를 Develop, master 브랜치에 병합한다.

(출처) https://amaran-th.github.io/Github/[Github]%20Git%20%EB%B8%8C%EB%9E%9C%EC%B9%98%20%EC%A0%84%EB%9E%B5/
https://parkstate.tistory.com/33
https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-github-flow-git-flow-%F0%9F%93%88-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EC%A0%84%EB%9E%B5

하나의 branch를 이용하면 편리하지만, 정상 서비스 운영중인 main branch에서 새로운 기능 추가나 버그 수정을 할수없다.

그래서 해결방안으로 각각의 브랜치에서 개발한 후, 현재 브랜치를 다른 브랜치로 합칠 때 사용한다. 특정 브랜치로 합치게 해달라고 요청하는 pr(pull request)에도 세가지 merge 방법이있다.

Create a merge commit

일반적인 merge commit을 만들며, 각각 브랜치에 남은 커밋을 히스토리에 그대로 남겨서 상세한 작업파악이 가능하다.

모든 commit과 분기했던 브랜치 히스토리가 굉장히 자세히 남아서 다소 보기 어려울 수 있다는 단점이 있다.

명령어: git merge [머지할 브랜치]

Squash and merge

squash: 짓누르다, 으깨다

선택한 브랜치의 모든 커밋을 하나의 커밋으로 합쳐서 중앙 브랜치에 하나의 커밋으로 저장하는 전략이다.

앞선 Create a merge commit의 모든 기록이 남아 기존 변경사항들이 어떻게 변했는가를 집중적으로 보여주기 보다 merge 되었다에 집중해 commit 히스토리가 간결하다는 장점이 있다.

하지만, 개별 커밋들이 사라져서 언제 어떤 코드를 바꿨는지에 대한 정보를 잃을 수 있다는 단점이 있다.

명령어: git merge -squash[머지할 브랜치]

Rebase and merge

선택한 브랜치의 commit들이 main 브랜치 위로 위치를 직접 옮겨서 처리하는 방식이다.

다른 브랜치에서 변경한 내용을 main 브랜치에서 변경한 것처럼 바꿔서 병합 commit이 생성되지 않아 commit 히스토리가 깔끔하고 일직선으로 이어진다. 팀 내에서 병합 기록을 최소화하고자 할 때 유용하다.

하지만, merge commit 기록되지 않기에 어느 시점에서 merge 되었는지 판단하기 어렵고 충돌이 발생한다면 충돌 해결 과정이 복잡해질수 있다.

rebase는 다른 브랜치의 커밋을 가져와서 현재 브랜치 위에서 다시 적용할때 커밋 히스토리가 재작성되므로, 원래 커밋 순서가 변경된다. 또한 각 커밋을 차례대로 재적용하는 방식이기 때문에 중간 중간 커밋마다 충돌이 발생할 수 있는데 각 커밋의 충돌을 해결해야 하므로 시간이 오래 걸릴수 있다

명령어: git rebase -i HEAD~

(출처) https://velog.io/@jeris/Git%EC%97%90%EC%84%9C-branch-merge-%EB%B0%A9%EB%B2%95%EB%93%A4%EA%B3%BC-%EA%B0%81-%EB%B0%A9%EB%B2%95%EC%9D%98-%ED%8A%B9%EC%A7%95
https://ssocoit.tistory.com/273

1. 상대적인 단위 사용(em, rem)
em: 부모 요소의 폰트 크기를 기준으로 설정
rem: 최상위 HTML 요소의 폰트 크기를 기준으로 설정


html { 
    font-size: 16px;}

.box {
    width: 10rem; //HTML 폰트 크기의 10배로 지정 }




2. 미디어 쿼리 활용
폰트 크기가 변경되었을 때 레이아웃이나 요소 크기를 다르게 설정하고 싶다면 미디어 쿼리 사용

@media screen and (min-width: 600px) {
.box {
  font-size: 1.2rem;
      }}


해석)화면 너비가 600px 이상일 때, .box의 요소 폰트 크기를 1.2 rem으로 설정한다.
    600px 미만일 때는 쿼리 내부의 스타일 적용이 아닌 기본 폰트 크기가 적용된다.


 3.Flexbox 또는 css grid 레이아웃 사용

(1) flexbox는 1차원 레이아웃 시스템으로, 가로 or 세로로 배치하는 데 적합하다.
(2) css grid는 2차원 레이아웃 시스템으로, 행과 열을 배치하는 데 적합하다
    복잡한 레이아웃에서 더욱 강력한 제어를 할수 있다.

-semantic: 의미의, 의미론적인 
-웹 기술이 발전함에 방대한 웹 문서가 생기면서 우리는 원하는 정보를 찾을때 어려움을 겪고있다.
이에 따라서 태그의 내용은 정보로서 높은 가치를 포함하기위해 노력해야 한다.
-시맨틱 태그란 포함된 콘텐츠의 특정 의미를 정의하고 목적을 갖는 태그
-태그의 의미를 부여함으로서 웹사이트의 구조를 파악하기 쉽게 도와줘서 
 명시적이면서 직관적인 구조의 설계가 가능해진다. 
-시맨틱 태그를 사용함으로서 사람들은 코드를 읽는 것이 쉬워지고 컴퓨터 입장에서는 콘텐츠를 더 쉽게 이해할 수 있다. 
-궁긍적으로 SEO (검색엔진 최적화)성능과 코드를 읽는 사람의 가독성 향상, 유지보수 용이하다.



*SEO(Search Engine Optimization)의 약자로 검색 결과 페이지에서 
잘 노출 되도록 웹페이지의 태그와 링크 구조를 개선하여 오가닉트래픽(Organic Traffic)을 늘리는 방법론

<nav>
같은 사이트 안의 문서나 다른 사이트로 연결하는 링크를 나타낸다.
<section>
기본 콘텐츠 내의 특정 주제 또는 부제목과 관련된 주제별 콘텐츠 그룹을 정의한다.
<article>
독립적인 글을 다루는 데 사용한다.
ex) 블로그 게시물, 뉴스 기사, 제품 리뷰 등 
<aside>
본문 내용 외에 주변에 표시되는 기타 내용들 필수요소가 아니기에 영향을 미치지 않는 것들을 넣을때 사용한다.

CSS : -Cascading style sheet의 약자로 웹 페이지의 디자인, 레이아웃, 스타일링을 정의하기 위해 사용하는 스타일 시트 언어. -여기서 첫번째 단어 Cascading은 '폭포, 위에서 아래로 쏟아지는'이라는 단어 뜻을 가짐 -언어 특성 상 하나의 tag에 중첩해서 동일한 속성 적용되어야 할때 어떤 속성을 우선순위로 보여줄지를 표현

우선순위

:3가지에 의해 결정된다.

1.중요도(Important) 2.명시도(Specificity) 3.코드 순서

1.중요도(Important)

스타일이 선언된 위치에 따라 우선순위 결정 기본적으로 프로그래머의 스타일 시트에 우선권을 부여하고 사용자와 브라우저의 스타일 시트 우선순위 낮음

[브라우저 CSS < 사용자 CSS < 프로그래머 CSS]

** !important

동일 <h1> 이라고 가정시
<head>
  <style>
  h1 {
  color:blue !important;
  }

  h1 {
  color:red;
  }
    </style>
</head>
<body>
    <h1> cascading은 우선순위를 결정한다. </h1>
</body>

=> 해당하는 h1 부분 글 색상 : blue 적용
=> 의도적으로 중요도를 끌어올리지만 스타일 시트 내 정해진 우선순위를 깨버려 디버깅을 어렵게 하기에 좋지 않은 습관

2.명시도(Specificity)

선택자(selector)에 따라 우선순위 다름 포괄적일수록 우선순위가 낮아지고 명시적이고 구체적인 속성일수록 우선순위가 높아짐.

[태그 < class < id < 인라인(style 내부 존재)]
*인라인은 하나의 태그 안에서만 적용되므로 가장 높은 순위

<a href="    " style="color:gray">  

3. 코드순서

같은 속성이 선언된다면 마지막에 나온 코드를 최우선으로 적용

<style>
    p {
      color: blue;
      color: red;  
  </style>

=>글 색상 : red 적용