5월 23, 2024

Git 환경설정하기/ git config/ git 환경 재설정/--global/--local

1. GIT 환경설정하기

git을 처음 사용하기 전에 해야 할 것으로 git 환경설정이 있다.

이 설정은 처음 한번만 해주면 다음부터는 해주지 않아도 되니, 시작하기 전에 설정을 잘 해보자.

 

굉장히 간단하다. 

 

2. GIT config 명령어


다음과 같이 명령어를 입력해주자.

 

$ git config --global user.name "설정하려는 이름"
$ git config --global user.email "설정하려는 이메일 주소"

 

설정하려는 이름과 이메일 주소 앞뒤로 " " 따옴표를 써주면 된다. 

여기서 --global 옵션이라는 것은 현재 사용하고 있는 컴퓨터 안의 모든 저장소에서 입력한 사용자 정보를 사용하겠다는 뜻이다. 즉 특정 저장소뿐 아니라 모든 저장소에 global 하게 적용된다는 뜻으로 이해하면 된다. 하지만 이렇게 global하게 사용하지 않고 특정 저장소에서만 해당되는 다른 설정을 해주고 싶다면it을 처음 사용하기 전에 해야 할 것으로 git 환경설정이 있다.

 

이 설정은 처음 한번만 해주면 다음부터는 해주지 않아도 되니, 시작하기 전에 설정을 잘 해보자.

 

 

하지만 이렇게 global하게 사용하지 않고 특정 저장소에서만 해당되는 다른 설정을 해주고 싶다면

$ git config --local user.name "설정하려는 이름"
$ git config --local user.email "설정하려는 메일주소"

위와 같이 --local의 옵션을 붙이거나, 

 

혹은 단순히 --global을 빼주면 된다. 

$ git config user.name "설정하려는 이름"
$ git config user.email "설정하려는 이메일 주소"

위와 같이 --global option을 쓰지 않으면 해당 저장소에서만 user configuration을 사용하겠다라는 뜻이다.



3. 사용자 정보 파악하기

만약 내가 설정한 사용자 정보를 알기 위해서는 다음과 같이 입력해보면 된다.

$ git config --list

이렇게 입력어를 친다면 

user.name=~

user.email=~ 

이런식으로 사용자 정보가 출력될 것이다. 


4. 사용자 정보 다시 설정하기

다음으로 만약 내가 설정한 사용자 정보를 다시 설정하고 싶다면 어떻게 하면 될까?

바로 --unset을 사용하면 된다.

 

$ git config --unset --global user.name
$ git config --unset --global user.email

위와 같이 명령어를 입력한 다음에 위에서 했던 것처럼 다시 재설정을 해주면 된다.

$ git config --global user.name "설정하려는 이름"
$ git config --global user.email "설정하려는 이메일 주소"

이런 식으로 말이다. 


3월 11, 2024

마크다운 문서 작성이 어렵다면? Typora 추천

1. Github markdown 작성

github readme를 작성하거나, 문서를 깔끔하게 작성해야 하는 경우 모두 한번쯤 마크다운 문서 작성법에 대해 검색해 본 적이 있을 것이다. 

마크다운 작성시에 태그를 적절히 넣어 문서를 작성해야 하기 때문에 작성법이 익숙하지 않은 사람들은 예상과 다르게 보여지는 화면을 보고 수정을 해야 하는 경우도 종종 있었을 것이다. 


2. Typora란?

그런 사람들을 위해 Typora는 아주 편리한 기능을 제공한다. 

바로 우리가 워드나 한글 문서를 작성하는 것처럼 메뉴를 제공하는 것이다.



예를 들어 위와 같이 Typora가 제공해주는 메뉴가 원래는 모두 코드로 작성해주어야 했던 것이다. 


3. Typora 다운로드 방법

Typora는 나같은 경우에도 며칠 전에 알게 되었는데 매우매우 편리해서 추천이다. 

 

다운로드 방법도 간단하다.

https://typora.io/


위 홈페이지에 방문해서 링크를 따라 쭉 내리다보면,



이 부분에서 자신의 컴퓨터에 맞는 버전을 다운받으면 된다. 


그러면 바탕화면에 



Typora가 잘 생긴 것을 알 수 있다. 



4. Typora 기능들

굵게, 기울이기, 밑줄과 같은 기능들도 문서처럼 자유롭게 활용할 수 있고,



또 실제 문서를 작성하는 것처럼 다른 이름으로 저장/ 저장을 하여 확장자 .md 인 파일을 내 컴퓨터에 자유롭게 저장할 수 있다. 

 

이렇게 저장한 markdown 문서를 나중에 github에 단순 업로드를 하면 되기 때문에 매우 편리하게 잘 사용하고 있는 서비스이다. 

특히나 markdown 문법에 익숙하지 않은 사람들에게 강력추천하는 바이다! 


3월 05, 2024

GIT branch 전환하기 , 새로운 branch 작성과 동시에 전환하기

1. Git Branch 전환하기

Git으로 코드를 작업하다 보면 branch를 여러 개 만들어서 코드를 용이하게 관리하곤 한다. 

 

오늘은 아주 간단하지만 외우고 있으면 유용한 Git branch 전환하는 방법에 대해 소개하도록 하겠다.


 2. git checkout

Git branch 전환에 있어 핵심 용어는 "checkout"이다. 
$ git checkout <전환하고자 하는 branch명>

위 명령어와 같이 git checkout 뒤에 전환하고자 하는 branch 명을 사용해주면 된다. 

 

예를 들어 내가 test1이라는 branch로 전환하고 싶다면 현재 존재하는 branch과 관계없이

$ git checkout <test1>

위와 같이 사용해주면 된다. 

 


3. 브랜치를 생성함과 동시에 branch 이동하기

만약 branch가 아직 만들어지지 않은 상황에서 새로운 브랜치를 생성함과 동시에 해당 branch로 이동하고 싶다면 어떻게 하면 될까? 

 

checkout 뒤에 -b 라는 옵션을 넣으면 된다. 

 

$ git checkout -b <새로 만들고 이동하려는 브랜치명>

 

checkout 할때와 동일하게 명령어를 쓰나 가운데 -b라는 옵션만 넣어주면 새로운 branch를 생성함과 동시에 전환할 수 있다. 


2월 25, 2024

마크다운 문서 작성 시 로컬에 있는 이미지 쉽게 올리기

1. Github readme 혹은 마크다운 문서 시 이미지 쉽게 올리기

Github readme를 작성하거나 마크다운 문서를 작성할 때 이미지를 쉽게 올리는 방법을 알아보자. 
이미지를 올릴 때 여러 가지 방법이 있는데 가장 정석인 방법은 github에도 img라는 폴더를 만들고 그 아래 올릴 이미지를 모두 업로드 한 뒤 img/해당 이미지로 경로를 설정해주는 방법이다. 하지만 이 방법은 img를 업로드해야 하기 때문에 나는 잘 사용하지 않는다. 
 


2. Github Issues 활용하기


그래서 단순히 이미지를 붙여넣기만 해서도 업로드가 가능한, 조금 더 쉬운 방법을 알아보도록 하자. 
물론, github readme를 작성하고 있다면 바로 readme.md에 복사, 붙여넣기를 하면 이미지 경로가 뜨지만 우리는 로컬에서 markdown문서를 만들고 있고, 해당 마크다운 문서를 이후에 github에 업로드 했을 시에도 이미지가 잘 나오게 하기 위한 경우를 보고 있는 것이다. 
 
방법은 간단하다. 바로 github에 "Issues" 부분을 활용하는 것이다. 



1) Issues 접속

github repository를 생성해준 뒤, Issues 부분에 들어간다. 



2) New issue 클릭

이후 New issue를 클릭해주면, 


위와 같은 부분이 나오게 될 것이다. 

3. 붙여넣기 후 경로 파악

다음으로 올리고 싶은 이미지를 복사한 뒤, Leave a comment라고 되어 있는 부분에 붙여넣기를 해보자. 
 
나 같은 경우에는 캡쳐한 이미지 파일을 자주 올리는데 그럴 때 굉장히 편한 방법이다. 
붙여넣기를 하면,


위와 같이 image 경로가 자연스럽게 나오게 되는데, 그러면 
<img src="https://user-images.githubusercontent.com/71162530/124603983-704d0d00-dea5-11eb-9b1f-e4541f9e0822.png"  />
위와 같이 적어주면 되는 것이다.
 
위에 Submit new issue는 누르지 않는다!! 
 
형식은
<img src="위에 나온 url"/>
이런 식으로 적어주면 된다. 
 

이런 식으로 작성해주면 로컬에 있는 이미지, 캡쳐 이미지, 다운받은 이미지에 관계없이 모두 다 git에서 잘 보여지는 것을 확인할 수 있다. 
 
readme를 github repository에서 바로 작성하는 경우에는 issues를 활용하지 않고 바로 이미지 붙여넣기를 하면 경로가 자동으로 나온다! 


2월 23, 2024

[Github] import repository 방법

Github import repository

Github에서 repository를 fork 하는 것이 아닌, 다른 repository에 있는 코드를 가져오고 싶다! 라고 할 때 우리는 import repository를 사용합니다. 

 

import repository 순서

Import repository는,



위와 같이 Github 오른쪽 상단에 + 를 클릭하면 보입니다. 여기서 New repository가 아닌, Import repository를 클릭하면 됩니다. 

 

클릭하면 아래와 같이,



clone 받을 이전 repository의 URL을 넣을 수 있는 칸이 나와있습니다. 이 URL은 복사하고자 하는 repository의 주소를 넣어주면 되는데요, 이 주소는 repository에 들어가서,



code를 누르시고, URL 옆에 버튼을 누르면 자동으로 복사가 됩니다. 


그런 다음에 다시 Import repository를 눌렀을 때 나오는 화면으로 돌아가서,

Repository Name을 적어주시면 됩니다.

 

여기서 Repository Name이란 import를 해서 나의 repository의 이름을 설정하는 것이죠. 


Repository Name을 설정한 이후에,

Public과 Private중에 공개범위를 설정해주고, 아래 Begin Import 버튼을 누르면 import respository가 완료됩니다.


2월 19, 2024

Github cloning 받기

깃허브에 있는 코드를 나의 local 환경으로 cloning 받고 싶을 때 아래와 같이 해주면 된다. 매우 간단하다. 

먼저 cloning을 받을 폴더로 이동해준다. vs 코드 terminal에 cd 라는 명렁어 뒤에 이동해줄 주소를 써주면 된다. 

 

내 경우에는 OneDrive/바탕 화면으로 이동해주었다. 이렇게 띄어쓰기가 주소에 포함 되어 있는 경우 " " 안에다가 적어주면 된다. 이렇게 이동해줄 폴더로 이동을 해준 뒤에 먼저 자신이 clone할 깃허브 주소에 가보자

 

그러면 상단에 code라는 부분을 클릭하면 자신의 clone하고 싶은 github 주소가 보일 것이다. 

 

이후 빨간색 부분을 클릭하면 자동으로 주소가 복사가 된다. 

 

그 뒤에 vs code로 다시 돌아와 터미널에 아래와 같이 적어주면 된다.

 

git clone 방금 복사한 주소 붙여넣기

그러면 위와 같이 잘 나오는 것이 알 수 있다. 이런 식으로 github의 코드를 나의 local 환경으로 cloning 하는 방법을 알아보았다. 지속적으로 업데이트를 하고 수정, 보완할 때 빠질 수 없는 기능이다.


2월 15, 2024

Github에서 repository 삭제하는 법

가끔 github의 repository를 생성하고 잘못 만들어 이를 삭제해야 하는 경우가 있을 텐데요, 이렇게 오늘은 Github에서 만들어진 repository를 삭제하는 법에 대해서 알아보도록 하겠습니다. 

 

먼저 자신이 삭제할 repository를 클릭해줍니다. 

그러면 아래와 같은 화면이 보일텐데요,

 


여기서 오른쪽 상단에 있는 Settings에 들어가도록 합시다! 

 



Settings에 들어가서 스크롤을 쭉 아래로 내려줍니다!

그러면 아래와 같이 Danger Zone이라고 표시된 부분을 볼 수 있어요.

 

Settings Danger Zone

여기서 가장 아래쪽에 있는 'Delete this repository'를 클릭해주시면 됩니다.

 

클릭을 하면 아래와 같은 경고창이 뜰텐데요, 이는 삭제를 정말 하겠냐라고 묻는 경고창이라고 보면 됩니다.

 

Github 삭제 경고창

여기서 삭제하려는 repository의 정식 이름은 나의 github id/Repository이름 이에요! 그래서 경고창에도 그런 식으로 나와있는 것을 알 수 있을텐데요,

 

여기서 화면에 표시된 'Github id/Repository이름'을 그대로 타이핑해준 뒤에 

 

아래 있는 'I understand the consequences, delete this repository' 버튼을 누르면 삭제가 됩니다. 


2월 11, 2024

[GIT] commit으로 issue 자동 close 하는 방법, issue close keywords

 Github에서 작업을 할 때 issue를 먼저 만들고 Pull Request 등의 작업을 통해서 issue를 close하는 경우가 많다. 

(참고로 Github issue에 관련해서는 첫 번째 포스팅에서 다루었으니 아래 링크를 참고하도록 하자. https://www.programmingstory.com/2023/08/github-issue-issue.html


오늘은 Github Commit을 통해 자동으로 issue를 close 하는 방법을 알아보도록 하겠다. 


우리가 Issue #3을 생성했고 위와 같이 Pull Request에 This close #3이라고 적으면 해당 Pull Request가 merge 될 때 Issue #3도 함께 close가 된다. 즉 issue와 Pull Request를 함께 묶을 수 있어 편리한 기능이다. 



Pull Request를 하면 위와 같이 close 아래 미세한 선이 보이는 것을 알 수 있고 #3에도 하이퍼링크가 생기는 것을 볼 수 있다. close 아래 마우스를 대 보면 


위와 같이 "This pull request closes issue #3" 라는 설명을 볼 수 있다. 

Pull Request가 생성되고 아래 "Confirm Merge" 까지 되어야 비로소 우리가 생성해주었던 issue 가 닫히는 것을 알 수 있다. 


close 이외에도 아래와 같은 키워드를 사용할 수 있다. 


close

- closes

- closed

- fix

- fixes

- fixed

- resolve

- resolves

- resolved


때로는 하나의 commit으로 여러 개의 issue를 close 할 필요도 있는데 나열 식으로 여러 개를 적어도 issue를 close 하는데 문제가 없다.


git commit -m "closed #30, #31, #33" 


이런 식으로 적어도 된다는 뜻이다. 

또한 다른 repository에 있는 이슈도 권한만 있다면 close 할 수 있다. 

git commit -m "close issue #40 and [repository_path]#2" 


이런 식으로 다른 repository path 이름 뒤에 issue number를 붙이면 가능하다. 


이런 github의 키워드를 사용하여 pull request와 issue를 match 하고 자동 close할 수 있는 기능을 적극 이용해보자. 


2월 10, 2024

[Github] Pull Request 이후 Merge된 Branch 자동으로 삭제 설정하기, protected branch 설정하기

 이전 포스팅에서는 Git Branch 전략의 종류를 알아보았다. (https://www.programmingstory.com/2024/02/git-git-flow-github-flow-gitlab-flow.html)


특히나 새로운 기능을 개발할 때 feature/ ~ 이런 식으로 branch 이름을 명명한다. 이슈를 만들고 feature/#이슈번호와 같이 브랜치를 새로 만드는데 issue가 해결되고 close 되면서, Pull Request도 머지되면 해당 branch를 삭제하는 것이 통상적이다. 신규 기능들을 개발하고 브랜치를 삭제하지 않으면 너무 많은 브랜치가 있어서 복잡하기 때문에 관리 차원에서도 개발 완료 후 merge 된 브랜치는 삭제하는 것이 통상적이다. 또한 다시 해당 브랜치를 사용하는 일이 생기더라도 branch를 restore하고 이전 commit으로 돌아갈 수 있기 때문에 삭제하더라도 문제될 일은 없다. 


Confirm merge 버튼 이후에 브랜치 삭제 버튼이 뜨는데 만약 매번 모든 Pull request에 대해 delete를 수작업으로 진행하고 싶지 않다고 한다면 Github의 setting을 통해 자동 삭제를 설정해줄 수 있다. 



Settings에 들어가서 Pull Requests가 보일 때까지 스크롤을 내려준다. 



스크롤을 내리다 보면 "Automatically delete head branches" 라는 문구가 보일 것이다. 만약 merge 된 후에 자동으로 해당 branch를 삭제하게 세팅하고 싶다면 해당 문구에 체크를 해주면 된다. 


이렇게 세팅을 해주면 Confirm merge를 통해 merge까지만 완료가 되면 해당 브랜치가 자동으로 삭제된다. 

하지만 만약 특정 브랜치는 merge가 되어도 삭제되지 않게 설정하고 싶다면 어떻게 하면 될까? branch는 protected로 설정되어 있지 않으면 위 설정을 통해 모두 삭제가 되므로 자동 삭제되게 하고 싶지 않은 branch들을 protected로 만들어주면 된다. 



Protected branch 설정은 Settigns > Code and automation > Branches > Add branch protection rule을 통해 설정할 수 있다. 


2월 10, 2024

[Github] use case 작성하기, diagrams.net Github와 연동시키기

어떤 프로젝트를 하기 전 Use Case를 먼저 작성하면 프로젝트의 전반적 flow뿐 아니라 요구사항, 기능들을 더 쉽게 이해할 수 있다. 

Use Case를 작성하기 위해 도움을 받을 수 있는 사이트는 대표적으로 diagrams.net이라는 사이트가 있다. 


위 사이트로 들어가면 된다. 이전에는 draw.io로 불렸었는데 현재는 diagrams.net이라고 불리고 있으며 온라인에서 간단하게 다이어그램을 그릴 수 있도록 도와주는 사이트이다. 

오늘은 이 사이트를 통해 Github와 연동하고 diagram을 그리는 방법에 대해 알아보도록 하자.


먼저 위 사이트에 들어가서 우측 상단의 Start Now 버튼을 클릭해주자

그러면 아래와 같이 다이어그램 저장 위치를 설정할 수 있는 창이 뜬다.

여기서 Github를 클릭해준다. 

그러면 Github로 결정이 된 상태에서 아래와 같이 새로운 다이어그램을 만들지, 기존 다이어그램을 열지에 대해 선택하게 된다.

여기서 새로운 다이어그램 만들기를 클릭해준다. 

그러면 위와 같이 diagram의 파일명과 템플릿을 선택할 수 있는 창이 나온다. Use Case에 100% 적합한 템플릿은 없어보이므로 빈 템플릿으로부터 만들어가면 된다. 

기본- 새 다이어그램을 선택해주겠다. 그런 다음 만들기를 누르면 원래 Github와 인증 연동이 되어 있을 경우에는 폴더 선택으로 바로 가게 되지만 처음에 Github 인증이 되어 있지 않으면 아래와 같이 Github 인증 절차를 한 번 더 거쳐야한다. 


여기서 이제 승인 버튼을 누르고 인증만 간단히 해주면 된다.


위와 같은 화면이 뜨면 'Authorize draw.io App'을 클릭해준다. 

만약 private repository로 설정해두었다면

폴더 선택하는 부분에서 repository가 보이지 않을 수 있다. 그럴 경우 위의 입력을 클릭해서 repository 명을 검색하고 이후에 Github에 연동되는 인증을 추가로 수행해주면 된다.

나는 Github에서 draw.io App Install하라는 페이지가 나와서 install 한 뒤 Repository Access를 "All Repositories"로 설정해주었다. 


위 install과 access 범위를 설정해주면 정상적으로 원하는 repository를 클릭할 수 있고, repository 안에서도 원하는 폴더를 선택해줄 수 있다. 

Commit Message

이후 Commit Message를 적고 확인을 눌러주면 된다. 


위 과정을 모두 잘 따라했다면 이런 식으로 다이어그램을 그릴 수 있는 페이지가 나온다. 

여기서 원하는 flow와 요구사항을 잘 정의하여 use case를 생성해주면 된다.

2월 10, 2024

[Windows] touch 명령어 대체하는 방법, fsutil과 touch의 다른점

1. Mac의 touch 명령어란? 

 MacOS에서는 새로운 파일을 특정 위치에 만들고 싶을 때 touch 명령어를 사용한다. 예시로 example.xml 파일을 만들고 싶을 때 아래와 같은 명령어로 새롭게 파일을 생성할 수 있다. 


touch example.xml


하지만 윈도우에서는 touch 명령어를 쓸 수 없다. 


이런 식으로 cmd에 해당 명령어를 쳐보면 'touch'은(는) 내부 또는 외부 명령, 실행할 수 있는 프로그램, 또는 배치 파일이 아닙니다. 라는 오류 메세지가 뜰 것이다. 


2. Windows에서 파일을 생성하고 싶을 때 사용할 수 있는 명령어는?

그러면 만약 윈도우 기반으로 touch 명령어를 대체하고 싶으면 쓸 수 있는 명령어는 무엇일까? 


바로 fsutil 명령어이다. 


fsutil file createnew [폴더/파일명.확장자] [파일사이즈]


이런 식으로 사용할 수 있다. 



fsutil file createnew example.txt 0

이라는 명령어를 통해 파일사이즈가 0 인 example.txt 생성하고 



실제 위 경로에 들어가보면 example.txt 파일이 생성된 것을 알 수 있다. 

3. touch와 fsutil의 차이점 


그러면 위 명령어가 MacOS의 touch 명령어를 완전히 대체하는 것인가? 라는 의문이 들 수 있다. 결론부터 말하자면 아니다. MacOS의 touch 명령어는 사실 파일의 생성뿐 아니라 파일의 날짜와 시간을 변경하는 데 사용되는 명령어이다. 특별한 옵션 없이 사용될 때는 서버의 현재시간으로 변경되고 만약 파일이 존재하지 않는 경우에 크기가 0인 파일이 생성되는 것이다. 

반면 windows의 fsutil의 경우 이미 존재하는 파일의 경우 fsutil 명령어를 사용하면 오류가 나며 시간을 바꾸지는 못한다. 



즉 이미 example.txt를 만들어준 다음에 똑같은 명령어를 친다면 "오류: 파일이 있습니다" 라는 메세지를 뱉는다. 


따라서 Mac의 touch 명령어를 fsutil이 완전히 대체하지는 못하며, 새로운 파일을 생성할 때 사용할 수 있다 정도로 정리하면 된다. 


2월 10, 2024

[GitKraken] terminal 사용해보기, gkc 명령어, git 명령어 자동완성

GitKraken은 이전 글 (https://www.programmingstory.com/2024/02/gitkraken-gitkraken-branch.html) 에서 살펴보았듯이 GUI 기반의 GIT Tool이다. 하지만 GUI 툴에서도 CLI 기반의 terminal 기능을 작성해볼 수 있다. 




우측 상단에 있는 "Terminal"을 클릭해주면 아래에 실제 terminal과 같이 CLI 기반으로 입력할 수 있도록 뜬다. 


이런 식으로 입력을 하면 git과 gkc 등 자동완성으로 명령어를 제안해준다. 


예시로 

gkc -h 

라는 명령어를 쳐보면 


위와 같이 help 문서를 보여준다. 

또한 README.md 라는 문서가 변경된 이력을 보기 위해서는 아래와 같이 명령어를 쳐줄 수 있다. 

gkc history README.md

그러면

이런 식으로 README.md 파일의 File History를 GUI 기반으로 보여준다. 여기에 Esc를 누르면 다시 terminal이 있는 창으로 돌아온다. 



또한 git 이라고 명령어를 치면 아래와 같이 실제 git에서 사용되는 명령어들을 추천으로 보여주어 더 쉽게 입력을 할 수 있도록 도와준다. 

이런 식으로 GUI 기반의 툴이지만 CLI Terminal도 쉽게 사용하면서 Git을 더 편리하게 이용할 수 있다. 

2월 08, 2024

Git 브랜치 전략 종류 (Git Flow, Github Flow, Gitlab Flow, Simple Branching Strategy)

1. Git 브랜치 전략의 의미와 필요성

 깃(Git) 브랜치 전략은 협업하는 개발자들이 프로젝트를 효율적으로 관리하기 위한 전략이다. 만약 branch 관리에 명확한 기준이 없으면 이 브랜치는 어떤 목적으로 생성되었으며, 새로운 브랜치를 생성할 때 어떤 명명규칙으로 생성해야 되고, 프로젝트에서 브랜치들을 어떻게 관리해야 하는지 혼란이 올 수 있다.

따라서, Git 브랜치를 효과적으로 관리하기 위한 work flow가 필요하고 이를 위해 Git 브랜치 전략을 수립한다.


2. Git Branch 전략의 종류

다양한 브랜치 전략이 있지만, 그 중에서도 가장 널리 사용되는 것 중 몇 가지를 살펴보겠다.


  1. 1) 기본 브랜치 전략 (Simple Branching Strategy):

    • 기본 브랜치 전략은 가장 기본이 되는 형태의 브랜치 전략으로, 주로 작은 규모의 프로젝트나 개발팀이 적은 경우에 사용된다.
    • 보통 master 브랜치를 메인 브랜치로 사용하고, 각 개발자는 feature 브랜치를 생성하여 작업을 진행한다.
    • 그리고 각 feature 브랜치에서 작업이 완료되면, 해당 기능이 master 브랜치에 통합된다 .



  2. 2) Git Flow:

    • Git Flow는 Vincent Driessen이 2010년에 그의 블로그 "A successful Git branching model" 이라는 글을 통해 제안한 모델로, 크고 복잡한 프로젝트에서 많이 사용된다.

    • - master branch

      • master 브랜치는 항상 배포 가능한 상태를 유지하며 master 브랜치에는 프로덕션 환경에서 실행 가능한 코드만 merge 된다.
      • 모든 기능이 개발 되고 QA(Quality Assurance)를 통과하고, 릴리스될 준비가 되면 develop 브랜치로부터 병합된다.
    • - develop branch
      • develop 브랜치는 다음 릴리스를 위한 개발이 진행되는 branch라고 할 수 있다. 새로운 기능이나 개선 사항이 개발되는 주요 브랜치이며 통상적으로 팀의 모든 개발자들이 develop 브랜치를 기반으로 작업을 진행한다.
    • -feature branch
      • feature 브랜치는 이름이 의미하는 바처럼 새로운 기능을 개발할 때 사용되는 브랜치이고 각 기능은 개별적인 feature 브랜치에서 개발된다. 흔히 우리가 feature/ ~ 이런 식으로 feature/기능이름으로 브랜치를 만들게 되는데, 해당 기능을 새로 개발할 때 feature branch도 생성한다. feature branch에서 개발이 완료되면 develop 브랜치로 병합된다.

      - release branch
      • release 브랜치는 다음 릴리스를 준비하는 동안에 사용되는 브랜치이다. 주로 develop 브랜치에서 분기되어, QA 테스트와 버그 수정이 함께 이루어진다.
      • 버전 번호를 업데이트하고, 릴리스 노트를 작성하며, 배포를 위한 최종적인 테스트를 진행하는 중요한 브랜치이다. 테스트와 버그 수정이 완료되면 masterdevelop 브랜치로 merge 된다. master 브랜치에는 태그를 생성할 수 있는데 release 브랜치에서 master branch로 머지되면서 릴리스를 마킹한다.

    • -hotfix branch
      • hotfix 브랜치는 배포된 소프트웨어에 긴급하게 버그 수정이 필요한 경우에 사용되는 브랜치이다. 배포된 소스에서 수정할 때 사용하기 때문에 master branch에서 분기된다.
      • 다른 브랜치와 동일하게 수정이 완료되면, masterdevelop 브랜치로 merge 되고 master 브랜치에 태그를 생성하여 새로운 버전을 마킹한다.


  3. 3) GitHub Flow:

    • 깃허브(GitHub)에서 제안된 간단한 협업 전략으로, 오직 master 브랜치만 사용한다. 빠른 릴리스와 지속적인 배포에 적합한 스타일이다.
    • GitHub Flow에서는 주로 하나의 메인 브랜치인 master 브랜치만을 사용하기에 별도의 브랜치가 필요하지 않지만 각 기능 또는 수정사항의 경우 master 브랜치에서 분기된 개별 브랜치에서 개발되며 "feature" 또는 "bugfix"와 같은 이름으로 명명한다. - Master branch:

        • master 브랜치는 메인 브랜치로서 배포 가능한 상태를 유지해야 하며 리뷰 등을 통해 승인된 코드는 이 브랜치로 병합된다.
      1. - Feature branch (Bugfix branch):

        • 새로운 기능 또는 버그 수정을 위한 개별 브랜치를 생성한다.
        • 보통 feature/기능이름 또는 bugfix/bug번호 와같은 형식으로 브랜치가 생성되고 해당 기능이나 수정이 완료되면, 해당 브랜치가 master 브랜치로 Pull Request를 통해 merge 된다.

      팀이 소규모의 agile 팀이고 하나의 release 버전만을 관리한다면 github flow가 적합한 스타일이다. 하루에도 변경사항을 주기적으로 merge/ release 하기에 적합한 branch 전략이다.



  4. 4) GitLab Flow:

    • GitLab Flow는 GitLab의 기능인 CI/CD (Continuous Integration/Continuous Deployment)와 연계하여 사용된다는 것이 가장 큰 특징이다.
    • GitHub Flow에서새로운 변경 사항이 master 브랜치에 병합될 때마다 자동으로 배포되었다면 GitLab Flow에서는 릴리스 브랜치를 사용하여 배포를 준비하고, CI/CD pipeline을 통해 배포를 자동화한다는 것이 차이점이다. 특히 gitlab flow에서는 staging/ production 과 같은 환경을 나누어 테스트와 배포를 관리할 수 있다.

3. Git Branch 전략 종류 선택

각 종류별로 장, 단점이 모두 존재하기 때문에 조직, 프로젝트, 구성원 등에 따라서 가장 적합한 브랜치 전략을 수립하여 적용시키는 것이 중요하다.