그럴려면 branch를 생성했었어야 하고, 그 branch에서 코드를 개발해야 한다는 걸 의미한다고 생각한다.
그래야 나중에 merge를 요청하지 않을까. MR (Merge Request)
우선, branch를 새로 뻗고 기능 개발을 한 뒤에 MR 을 하기 전에,
아까 push 하려고 commit 했던 걸 없애버려야 한다.
git reset --hard HEAD~1
git reset --hard HEAD~1 명령어는 Git에서 이전 커밋 상태로 되돌리고, 현재 작업 중인 파일 변경 사항과 스테이징된 모든 변경 사항까지 모두 삭제하는 강력한 명령어입니다. 아래에서 자세히 설명하겠습니다.
명령어의 구성
git reset
커밋 기록, 스테이징 영역, 워킹 디렉토리(작업 중인 파일 상태)를 조정하는 명령어입니다.
옵션에 따라 작업 중인 파일과 커밋 기록에 대한 변경 범위가 달라집니다.
--hard
현재 커밋 이후의 모든 변경 사항을 완전히 삭제합니다.
변경 사항을 되돌릴 수 없으므로 신중히 사용해야 합니다.
HEAD~1
현재 커밋(HEAD)의 바로 이전 커밋을 가리킵니다.
HEAD~1은 "현재 커밋에서 한 단계 전"이라는 의미입니다.
숫자를 늘리면 더 이전 커밋으로 이동합니다. 예: HEAD~2는 두 단계 이전 커밋을 의미.
결과
이 명령어를 실행하면:
현재 커밋이 삭제되고, 이전 커밋 상태로 돌아갑니다.
예를 들어, 현재 커밋이 C3이라면:
C1 --- C2 --- C3 (HEAD)
git reset --hard HEAD~1 명령어를 실행하면:
C1 --- C2 (HEAD)
C3 커밋이 삭제됩니다.
워킹 디렉토리와 스테이징 영역도 이전 커밋의 상태로 강제 변경됩니다.
즉, 현재 작업 중인 파일에서 수정하거나 추가한 모든 내용이 영구적으로 삭제됩니다.
사용 시 주의점
이 명령어는 삭제된 변경 사항을 복구할 수 없기 때문에 매우 신중히 사용해야 합니다.
필요하면 명령어를 실행하기 전에 현재 상태를 백업하거나 커밋을 저장하세요.
실용적인 예시
상황:
test.txt를 수정한 후 커밋했지만, 실수로 잘못된 내용을 넣었다고 가정합니다.
이전 커밋 상태로 되돌리고 싶을 때:
git reset --hard HEAD~1
결과:
방금 한 커밋이 삭제됩니다.
test.txt는 이전 커밋의 상태로 되돌아갑니다.
수정했던 내용은 복구할 수 없습니다.
app.py 에서 수정했었던 게 사라지고 이전으로 돌아간 상태다.
이제 다시,
git pull 을 해서 혹시라도 변경된게 있는지 확인을 먼저 하고
그리고 이제 feature branch 를 만들도록 하겠다.
git branch [branch name] 으로 만들면 된다.
Git에서 git branch feature/message-update라고 입력하면 feature/message-update가 브랜치 이름입니다. 즉, 브랜치 이름에 /를 포함할 수 있으며, 이는 단순히 이름의 구조를 나타내는 것일 뿐, 특별한 동작을 의미하지는 않습니다. 그러나 이름에 /를 사용하는 것은 관례적으로 특정 의미를 담고 있습니다.
/의 의미
/는 브랜치 이름을 조직적으로 관리하기 위한 관례로 사용됩니다. Git은 이를 계층 구조로 인식하지는 않지만, 개발자들이 브랜치 이름을 구분하기 쉽게 도와줍니다.
일반적인 관례:
feature/
새 기능을 개발하기 위한 브랜치를 나타냅니다. 예: feature/login-page, feature/message-update.
많은 Git GUI 툴이나 웹 플랫폼(GitHub, GitLab, Bitbucket 등)은 /를 포함한 브랜치 이름을 계층 구조로 표시합니다.
브랜치 이름의 유효성
브랜치 이름에 /를 포함할 수 있지만, 다음과 같은 규칙은 지켜야 합니다:
공백(space)은 사용할 수 없습니다.
다음 기호는 사용할 수 없습니다: ~, ^, :, \, [, ].
이름은 HEAD, master, main 같은 예약어와 충돌하지 않아야 합니다.
요약
feature/message-update는 단순히 브랜치 이름입니다. /는 관례적으로 브랜치를 그룹화하거나 목적에 따라 구분하기 위해 사용됩니다. Git은 이를 계층적으로 처리하지 않지만, 사람이 읽기 쉽게 관리할 수 있도록 돕는 역할을 합니다.
git branch를 해서 branch 를 만들었다.
1. 브랜치를 만든 후에는 그 브랜치로 이동해야 합니다.
브랜치 생성만으로는 현재 작업 중인 브랜치가 바뀌지 않습니다. 새로운 브랜치에서 작업하려면 git switch 명령어나 git checkout 명령어를 사용해 브랜치를 전환하세요.
예시:
git branch feature/message-update # 브랜치 생성
git switch feature/message-update # 브랜치로 이동
참고: git switch는 더 직관적인 명령어로, 최신 Git 버전에서 권장됩니다. git checkout feature/message-update도 동일하게 동작하지만, 브랜치 생성과 전환 모두에 사용되기 때문에 상황에 따라 혼동될 수 있습니다.
2. 새로운 브랜치에서 작업을 진행합니다.
브랜치 전환 후 파일을 수정하거나 새로운 파일을 추가하고, 변경 사항을 커밋할 수 있습니다.
예시:
# 파일 수정
nano app.js # (또는 선호하는 텍스트 편집기 사용)
# 변경 사항 확인
git status
# 변경 사항을 스테이징하고 커밋
git add app.js
git commit -m "Add new feature for message update"
3. 브랜치를 **원격 저장소(remote)**에 푸시합니다. (필요한 경우)
새로 만든 브랜치를 팀원과 공유하거나 원격 저장소에 백업하려면, 원격 저장소에 브랜치를 푸시해야 합니다.
첫 번째 푸시:
git push -u origin feature/message-update
-u 옵션: 원격 브랜치와 로컬 브랜치를 연결하여, 이후에 git push만 입력해도 푸시가 가능합니다.
origin: 기본 원격 저장소 이름입니다.
이후부터는 간단히:
git push
4. 브랜치 작업이 완료되면 다른 브랜치와 병합(merge) 하거나 Pull Request(PR) 를 생성합니다.
작업이 완료되면, 보통 브랜치를 메인 브랜치(main 또는 master)에 병합합니다. 병합 과정에서 충돌이 발생할 수 있으니 주의해야 합니다.
1) 병합 (로컬):
# 메인 브랜치로 이동
git switch main
# 병합
git merge feature/message-update
2) Pull Request (원격):
GitHub, GitLab과 같은 플랫폼을 사용하는 경우, 원격 저장소에서 Pull Request를 생성하여 병합 요청을 진행합니다.
5. 브랜치 정리
작업이 완료되어 더 이상 필요 없는 브랜치는 삭제할 수 있습니다.
로컬 브랜치 삭제:
git branch -d feature/message-update
원격 브랜치 삭제:
git push origin --delete feature/message-update
요약
브랜치를 생성하고 이동: git branch → git switch.
작업을 진행: 파일 수정 → git add → git commit.
원격 저장소에 푸시: git push -u origin <branch-name>.
작업 완료 후 병합 또는 PR 생성.
불필요한 브랜치 삭제.
이제 이 상태에서 코드를 수정한다. app.py 에서 코드를 수정했다.
이제,
git status 로 확인해보면 수정된 걸 확인할 수 있고,
git add app.py
git commit -m "Update message, New Branch"
여기까지.
이제 git push 를 하면 되는데, git push 를 해보면,
git push --set-upstream origin feature/message-update 는 무슨뜻이야?
git push --set-upstream origin feature/message-update는 로컬 브랜치와 원격 브랜치를 연결하는 데 사용되는 명령어입니다. 이를 통해 이후에는 간단히 git push나 git pull 명령어만으로도 로컬 브랜치와 원격 브랜치 간의 작업을 동기화할 수 있습니다.
명령어의 구성
git push
로컬 브랜치의 커밋을 원격 저장소로 업로드하는 명령어입니다.
--set-upstream (또는 -u)
로컬 브랜치를 특정 원격 브랜치와 연결합니다.
한 번 설정하면 이후에는 git push와 git pull만으로 동작합니다.
origin
원격 저장소의 이름입니다. 보통 기본 원격 저장소는 origin으로 설정됩니다.
feature/message-update
원격 저장소에 생성하려는 브랜치 이름입니다.
동작 방식
로컬 브랜치인 feature/message-update를 원격 저장소의 같은 이름(origin/feature/message-update)의 브랜치와 연결합니다.
원격에 브랜치가 없으면 새로 생성하고 푸시합니다.
이후 이 브랜치에서 git push와 git pull을 사용할 때 원격 브랜치를 명시하지 않아도 됩니다.
왜 필요한가요?
Git에서 기본적으로 로컬 브랜치와 원격 브랜치가 자동으로 연결되지 않습니다. 이를 명시적으로 연결(tracking)해 주어야 합니다. --set-upstream은 이 연결 작업을 한 번에 처리하기 위해 사용됩니다.
연결(업스트림 설정)을 통해 어떤 원격 브랜치로 데이터를 보낼지 Git이 알 수 있습니다.
연결되지 않으면 매번 명령어에 원격 브랜치를 명시해야 합니다.
마지막 요약
[로컬 저장소] [원격 저장소]
main origin/main
feature/login origin/feature/login
로컬 저장소는 내 컴퓨터에서 작업 중인 Git 저장소.
원격 저장소는 GitHub 같은 서버에 저장된 Git 저장소.
두 저장소는 push와 pull을 통해 데이터를 동기화.
원격 브랜치 이름은 보통 origin/<branch-name> 형태.
내가 이해하기론, 모든 branch는 remote branch가 있어야, push pull 을 할 수가 있다는 걸로 이해가 되는데? 그러니까 새로운 branch를 만들었다고 치자고. 그러면 gitlab 같은 git 저장소에서도 branch가 만들어져야 하는데 만들어지지가 않아. 그러니까 gitlab 같은 git 저장소에도 새로운 branch가 생성되어야 하고, 로컬에서 새롭게 만든 branch와 gitlab 같은 git 저장소에서도 만들어진 branch를 연결을 해줘야 push/pull 을 통해서 동기화해서 사용할 수가 있다는 뜻이지?
네! 정확하게 이해하고 계세요! 정리하자면, 로컬에서 새로운 브랜치를 만들었다고 해서 자동으로 원격 저장소(GitLab, GitHub 등)에 브랜치가 생성되는 것은 아닙니다. 로컬 브랜치와 원격 브랜치를 연결하고 동기화해야만 push와 pull을 사용할 수 있습니다. 이 개념을 조금 더 명확히 정리해볼게요.
자주 묻는 질문
Q1. 새로운 브랜치를 만들 때 원격 브랜치도 자동으로 생성되나요?
아니요, 로컬 브랜치를 생성한다고 해서 원격 브랜치가 자동으로 생성되지는 않습니다.
원격 브랜치를 생성하려면 git push 명령어를 사용해야 합니다.
Q2. 로컬 브랜치와 원격 브랜치를 연결하지 않으면 어떻게 되나요?
연결되지 않으면 git push나 git pull 명령어를 실행할 때 매번 브랜치 이름을 명시적으로 적어야 합니다.
git push origin feature/new-branch
Q3. 로컬 브랜치와 원격 브랜치를 연결하는 이유는?
매번 원격 브랜치를 지정하지 않고도 git push와 git pull 명령어를 간단히 사용할 수 있기 때문입니다.
요약
로컬 브랜치 생성만으로는 원격 브랜치가 자동으로 생성되지 않습니다.
원격 저장소에도 브랜치를 생성하려면 git push를 통해 동기화해야 합니다.
로컬 브랜치와 원격 브랜치를 연결하려면 --set-upstream 옵션을 사용해야 합니다.
연결 후에는 간단히 git push와 git pull로 동기화 작업이 가능합니다.
이해는 되었으니 계속 나아가보자.
이렇게 해서 이제 이 feature/message-update branch 가 gitlab 저장소에 올라가있게 되었다.
이 branch에 대해서 merge 요청을 하러 gitlab 으로 가보자.
웹에 들어가니까 create merge request 버튼이 떠있다.
승인 요청서를 만드는 것이다.
승인을 해달라고 요청서를 작성하는 것이다.
저기 Switch to rich text editing 버튼을 눌러보면,
요렇게 바뀐다. 암튼,
Assignee - 승인 요청을 해줄 유저
Reviewer - 리뷰어도 신청할 수가 있다
Milestone, Labels는 여기서는 선택하지 않았다.
Merge options 에서 체크된 걸 읽어보면, merge request가 받아들여지면 feature branch 는 삭제해달라는것이 default로 체크가 되어 있다. 여기서는 체크를 해제를 일단 해놓겠다.
밑에 보면, 어떤 commits이 있었는지 확인이 가능하다.
changes 를 눌러보면 어떤 내용이 변경되었는지 미리 확인할 수 있는 것.
pipelines 을 눌러보면, pipeline이 실행이 된 걸 확인할 수 있다.
feature branch가 올라갔다는 건, feature branch에서도 변경이 있었다고 보는거니까
변경 감지하고 pipeline이 실행된것.
원래라면 pipeline이 실행되면 안 된다. main branch에서만 실행되어야 한다.
feature branch는 개발자 개인 환경에서 개발한 것이기 때문에 CI/CD (build, test, deploy)가 돌아가면 안 된다.
이런 경우에는, feature branch에서의 변경 내용은 감지가 되더라도 파이프라인을 돌리지마라는 예외 상황을 둘 수가 있다. (이건 나중에)
merge request 가 전송이 되었다.
이 요청이 관리자에 갔을 것이다.
확인해보자.
merge request가 도착한 걸 확인할 수 있다.
프로젝트를 눌러서 왼쪽 바에서도 merge request를 확인할 수 있다.
확인을 해보고 나서,
문제가 없다면 승인을 해주면 된다. (Merge)
Merge를 누르면 main branch에 merged 가 되는거고 그러면 CI/CD pipeline 이 작동할 것이다.
성공적으로 ECS까지 배포가 되었다.
그러면 웹브라우저를 확인해보면 된다. (약간 시간이 걸리니까 잠시 후에 확인하면 된다.)
접근을 하려면 load balancer의 url을 알아야 한다. (ec2 - load balancer - DNS name)
