프로찍먹러

1. 로컬에서 브랜치명 변경하기

git branch -m oldname newname

git branch -m [기존브랜치이름] [새로운브랜치이름]

간단하다.

2. 원격저장소의 브랜치명까지 변경하기

로컬저장소에서는 브랜치 이름이 변경되었다.

이어서 이 변경사항을 원격저장소에도 반영해보자.

아까 로컬에서의 git branch -m옵션으로 oldname브랜치의 이름을 newname으로 바꿨기에

이 사항을 원격저장소에 push한다.

git push origin :oldname

이전 이름인 oldname 앞에 콜론(:)을 붙혀서 oldname 브랜치의 삭제사항을 푸시하는 것이다.

그러면

요렇게 나오면서 

원격저장소에 있던 oldname 브랜치가 사라진다.

이제 이름을 바꾼 브랜치를 푸시하면 된다.

git push --set-upstream origin newname

그러면 이렇게 나오면서

원격저장소에도 수정된 이름의 브랜치가 잘 반영됨을 확인할 수 있다.

꿀팁 한 가지.

변경내용이 없어도 커밋을 하고싶다면

git commit --allow-empty -m "Empty Commit Message"

하면 된다 !

참고:

1. 언제 사용할까

develop 브랜치에서 분기한 feat1 브랜치가 있다고 하자.

feat1 브랜치에서 작업을 하며 여러가지 변경사항들이 생겨나고있다.

이때 develop 브랜치나 다른 브랜치로 checkout 해야할 경우가 종종 생긴다.

이때 그냥 checkout을 시도하면 git은 commit을 먼저 하라는 경고를 뱉는다.

하지만 난 아직 feat1 브랜치에서의 작업이 끝나지 않아서 커밋하고 싶지 않다면?

이때 git stash 명령어를 사용할 수 있다.

2. 사용법

feat1 브랜치에서 

git stash

를 쳐주면 feat1에 내가 싸놓은 변경사항들이 스택으로 잠깐 이동된다.

즉 feat1과 내가 분기해서 가져온 로컬 develop 브랜치간의 차이가 없어지고 

다른 브랜치로 이동할 수 있게된다.

다른 브랜치에서 작업을 끝내고 다시 feat1로 돌아와서 내가 옮겨 두었던 변경사항들을 불러오고 싶다면

git stash apply

를 해주면 된다.

단, 이때 스택에 여러개의 stash된 내용들이 쌓여있다면 가장 최근에 stash된 내용이 꺼내와지며(이 경우 stash@{0})

꺼내와졌다고 자동으로 pop되지 않기에

git stash drop

을 통해 꺼내온 stash 내용을 지워주어야 한다.

참고:

이번에는 branch 생성/전환/삭제와 main 브랜치에서의 merge를 해보겠다.

1. 브랜치란

SW 개발 시 개발자들은 소스코드를 공유하게 된다. 이때, 여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어 주는 기능이 바로 브랜치(Branch) 다. 각자 독립적인 작업 영역(저장소) 안에서 마음대로 소스코드를 변경할 수 있다. 이렇게 분리된 작업 영역에서 변경된 내용은 나중에 원래의 버전과 비교해서 하나의 새로운 버전으로 만들어 낼 수 있다.

즉, 병렬적으로 작업할 수 있고 작업 후에 main으로 병합을 할 수 있는 서브 작업공간 같은 개념

2. Branch 국룰

변수명, 클래스명에서 암묵적인 규칙이 있듯 브랜치도 어느정도 정형화된 용도와 규칙이 있다. 처음 알았다.

• Main (Main Branch)
• Develop (Main Branch)
• Feature/<Issue_number> or <Feature_name> / <Short Description>
• Release/<version_number>
• Hotfix/<Issue_number> or Issue/<Issue_number>

Main Branch

메인 브랜치는 배포할 수 있는 브랜치다.

즉 최종적인 상태를 의미하는 공간으로 최상위 브랜치다.

명명규칙: 보통 main 그대로 쓴다고 한다.

Develop Branch

다음 출시 버전을 개발하는 브랜치

main에서 분기되어 기능 개발을 위한 브랜치들의 병합을 위해 사용됨.

이 브랜치에서 기능을 병합하고 버그를 수정하여 배포 가능한 상태가 되면 main으로 병합한다.

명명규칙: 보통 develop 그대로 쓴다고 한다.

Feature Branch

기능을 개발하는 브랜치

새로운 기능이나 버그 수정이 필요할 때마다 develop 브랜치에서 분기된다.

여기서의 작업은 공유할 필요가 없기 때문에 주로 자신의 로컬 저장소에서 관리한다.

명명규칙: feature/기능요약 (ex. feature/login)

Release Branch

이번 출시 버전을 준비하는 브랜치

feature 브랜치에서 기능 개발 후 develop 브랜치에서 병합을 하는 과정을 반복하여,

최종적인 버그 수정이나 문서 추가 등 실질적으로 Release하기 직전에 하는 단계를 위한 브랜치

명명규칙: release/X.X.X 혹은 release-X.X.X

Hotfix Branch

출시 버전에서 발생한 버그를 수정하는 브랜치

갑작스럽게 수정해야하는 경우에 main에서 수정하지 않고 Hotfix 브랜치로 분기하고 수정 후 main으로 병합한다.

main에서 다시 배포 후에는 develop 브랜치에도 병합해준다.

명명규칙: hotfix-X.X.X

3. 모범 예시

4. 실습

1. main 브랜치에 최초 커밋을 한다.

어차피 브랜치가 중점이기에 그냥 txt파일로 연습한다.

2. Develop 브랜치 추가하기

현재는 main 브랜치 뿐이다.

develop 브랜치를 만들어주자.

git branch "브랜치이름"

develop 브랜치에서 로그인 기능을 만든다고 가정한 feature 브랜치도 만들어 준다.

git branch feature/login

feature/login 브랜치에 로그인 모듈을 만들어서 푸시 후 develop 브랜치로 merge 해보자

feature/login 브랜치로 일단 push 하고

develop 브랜치로 이동하여 feature/login을 merge했다.

두번의 과정에서 모두 첫 커밋이라 upstream을 설정하라고 에러가 발생했다.

push 뒤에 -set--upstream 옵션을 붙혀주면 된다.

새로 생성한 브랜치에서 작업이 끝나면 

git branch -d feature/login

명령어로 브랜치를 제거해준다. 이때 merge되지 않은 정보들이 있다면 경고문이 뜨며 -D로 옵션을 바꿔서 진행하라고 알려준다.

5. 결과

브랜치 3개가 잘 만들어졌다.

develop 브랜치로 merge한 feature/login 브랜치의 내용도 잘 들어갔다.

참고:

어제 AWS 관련 인증 키들을 깃허브 리포지토리에 올려놓고 있었다는 사실을 알게 됐다. 깃허브에서 지우고 다시 커밋되지 않도록 .gitignore에 등록하였지만 리포지토리 히스토리상에는 이미 수 없이 남아있었다. 이를 해결하기위해 BFG Repo-Cleaner를 사용했다.

1. BFG Repo-Cleaner 설치

https://rtyley.github.io/bfg-repo-cleaner/

다운로드된 jar파일을 작업할 프로젝트의 로컬 최상위 경로에 저장했다.

2. 문제의 히스토리

이렇게 이미 삭제한 내용임에도 히스토리 상에서 공개가 되기에 이 부분을 제거해 주자.

git clone --mirror [리포지토리 주소]

java -jar [jar파일 경로] --delete-files [이 클래스에 연관된 커밋 히스토리를 제거]

git reflog expire --expire=now --all && git gc --prune=now --aggressive

git push -f origin main

나의 경우엔 다음과 같았다.

git clone --mirror https://github.com/llshl/fabinet.git

java -jar "C:\Users\lsh97\Desktop\IntelliJ WorkSpace\fabinet-gradle\bfg-1.14.0.jar" --delete-files AwsConfig.java

git reflog expire --expire=now --all && git gc --prune=now --aggressive

git push -f origin main

파일 경로상에 공백문자가 있을 경우 전체 경로를 ""로 감싸주면 된다.

이 결과 AwsConfig.java 파일에 관련된 히스토리는 삭제된다.

(사진은 AwsConfig가 아닌 다른 클래스긴 하지만 여기에도 인증코드가 있었고 잘 지워진 모습이다.)

참고:

오늘 깃을 만지다 실수로 졸업작품 코드를 몽땅 날려버릴뻔 했다. 

reset을 통해 복구를 했긴 했다만 참으로 아찔한 상황이었다.

고로 깃을 한번 체계적으로 짚고 넘어가볼까 한다. 

이 포스팅을 시작으로 여러 상황을 재현해보며 연습해보자.

1. 리포지토리 생성과 git init

CLI로 연습하는게 좋을 것 같아서 IDE의 git 플러그인을 사용하지 않고 깃배시를 설치했다.

최초 설치 후 계정설정이 필요한데 나의 경우는 먼 옛날에 해두었기에 생략한다.

echo "# git-test-repo" >> README.md
git init
git add README.md
git commit -m "first commit"
git branch -M main
git remote add origin [리포지토리 주소]
git push -u origin main

깃허브에서 리포지토리를 처음 생성하면 제시해주는 스크립트를 통해 Readme.md 파일을 생성하여 최초로 커밋 시켜준다.

이제 이 리포지토리에서 여러가지 깃 기능들을 시험해보자!

(simbean과 함께)