[Git] 깃 초보, 깃 브랜치 전략 - main, develop, feature 그리고 충돌(2)

이전 글에 이어서 작성한다.

https://strolrol.tistory.com/93

[Git] 깃 초보, 깃 브랜치 전략 - main, develop, feature 그리고 충돌(1)

1. 이 글의 목적 및 실습 내용

이전 글에서는 main, develop을 만드는 깃 브랜치 전략과 실습을 했고, 현재 글은 feature 브랜치를 만들어서, 충돌 해결까지 실습한다.

 

해당 내용은 (코딩알려주는누나) https://youtu.be/tkkbYCajCjM?feature=shared 에서 학습한 내용이다.

2. 깃 브랜치 실습

2-1. feature 브랜치 만들기

현재까지는 main 브랜치를 만들고 main 브랜치와 똑같은 develop 브랜치를 만들어 놓은 상태이다.

 

이제 할 일은 feature 브랜치를 만드는 것이다. 즉 이제부터 우리가 해야할 영역이다.

 

팀으로 작업할 경우 위 Project를 눌러서

 

Team planning으로 작업을 기록할 수 있다.

 

아래와 같이 만들어야 할 기능을 적는다.

 

대체로 할 일은 내가 정하는게 아니라 팀에서 정하고 Assign으로 기능을 작업해야 할 사람이 정해져 있다. 우리가 해야 할 일은 'Convert to issue'를 클릭해서 이슈를 만든다.

 

이슈에서 많이 사용 하는 것이 브랜치를 만드는데, 로컬에서 브랜치를 만들어서 원격과 연결을 할 수 있지만 해당 버튼을 누르면 해야하는 작업의 이슈와 연결되어서 내가 다 작업이 끝나 develop에 머지를 하면 해당 이슈도 동시에 closed된다.

 

이해가 안될 수 있는데 위와 같이 완료된 이슈는 보라색으로 Merged되었다고 나오고 끝난 작업으로 Closed 된다.

 

이슈 메뉴에서 New issue를 클릭해서 이슈를 생성할 수 있고 이슈 내용에 마크다운 문법으로 내용을 작성하거나, 모든 사람이 공통으로 양식을 사용할 수 있도록 이슈 템플릿도 만들 수 있다. 하여튼

 

브랜치를 만드는데 여기서 중요한 것은 절대로 main이 아니라 develop에서 브랜치를 만들어야 한다. 안하면 무서운 일이 생긴다. 그리고 브랜치 컨벤션도 따로 있는데 아무튼 많이 사용하는 국룰이 있다.

 

 

브랜치를 생성하면 친절하게 해당 내용 복붙하라고 알려준다.

 

위 내용은 Chat-gpt에게 물어보자.

 

이 두 명령어는 원격 저장소로부터 데이터를 가져오고, 특정 브랜치로 이동하는 작업을 수행한다.

 

1. git fetch origin:

• 이 명령어는 원격 저장소(origin)에서 최신 변경 사항을 가져오는(fetch) 역할을 한다.
• 로컬 저장소의 브랜치나 파일을 업데이트하지 않고, 원격 저장소의 최신 상태만 로컬 Git의 리모트 트래킹 브랜치로 가져와 확인할 수 있도록 한다.
• 예를 들어, origin/main, origin/develop 등의 원격 브랜치에서 새로운 커밋이나 업데이트가 있을 경우, 그 정보를 로컬로 다운로드해 저장해둔다. 그러나 이 작업은 로컬 작업에 직접 영향을 주지는 않는다.

2. git checkout feature/gallery-menu:

• 이 명령어는 로컬 Git에서 feature/gallery-menu 브랜치로 전환한다는 뜻이다.
• 만약 로컬에 이미 해당 브랜치가 존재한다면 바로 그 브랜치로 이동하며, 만약 존재하지 않으면 오류가 발생한다.
• 브랜치 전환은 현재 작업 중인 브랜치를 feature/gallery-menu로 바꾸는 것이며, 이때 해당 브랜치에서 작업한 내용을 보고 새로운 커밋 등을 추가할 수 있다.

 

코드를 입력하면 로컬에 feature/gallery-mene가 생긴다.

 

브랜치가 생겨난 것을 볼 수 있다. 이제 여기서부터 개발의 시작이다.

 

2-2. feature -> develop에 merge 하기

깃 클론을 떠서 다른 사람이 작업한다고 가정한다.

 

exam2로 이동하면 main으로 되어 있는데 절대 여기서 작업하면 안된다. 위와 동일하게  [FEAT] 갤러리 게시글 정렬 기능 만들기를 progress로 옮긴 후에 issue로가서 branch를 만들면된다.

 

짜란~ feature/gallery-sort에서 작업해야한다.⭐⭐⭐ 진짜 매우 중요하다. 

 

인텔리제이가 친절하게 해당 branch가 어디인지 알려주고, 기능을 만든다. 

 

 

git push를 하면 자동으로 원격 레파지토리에 올라간다.

원래 pull request를 날릴 수 없게 만들어야 하는데 지금은 연습이니까,,,

feature/gallery-sort를 보면 커밋 메세지가 잘 들어갔다.

 

 

full request를 날릴 때 빨간색 친 부분을 살펴보면, 병합할 곳이 develop이어야 한다. main이면 절대 안된다.

 

현재는 충돌날 것이 없기 때문에 Merge pull request 버튼이 활성화 되어 있다.

 

File changed에서 변경된 내용을 보고 코멘트를 남길 수 있다.

 

오른쪽 내용은 Chat-gpt님께 부탁했다.

 

이 메시지는 GitHub에서 **Pull Request(PR)**에 대한 피드백을 제공할 때 선택할 수 있는 세 가지 옵션을 설명하고 있다. 각각의 의미를 아래에서 설명한다.

 

1. Comment (코멘트):

• PR에 대한 일반적인 피드백을 제공할 수 있는 옵션이다. 코드에 대한 코멘트를 남기지만, PR을 승인하거나 변경을 요청하지는 않는다.
• 이 옵션을 선택하면, 코드의 특정 부분에 의견을 남기거나 설명을 덧붙이는 등의 방식으로 협업할 수 있다.
• 코멘트를 남기는 것은 피드백 제공의 일환일 뿐, 코드를 승인하거나 변경을 요구하는 행위는 아니다.

2. Approve (승인):

• PR이 문제없이 코드베이스에 병합될 준비가 되었음을 승인하는 옵션이다.
• PR 작성자는 본인의 PR을 승인할 수 없다. 즉, 팀원들이 작성한 PR에 대해 리뷰하고, 문제가 없다고 판단되면 이 옵션을 선택하여 해당 변경 사항이 병합될 수 있도록 한다.

3. Request changes (변경 요청):

• PR에서 특정 수정이 필요하거나, 개선해야 할 점을 발견했을 때 변경을 요청하는 옵션이다.
• 이 옵션을 선택하면 PR 작성자에게 수정을 요청하게 되며, 변경 사항을 적용한 후에 다시 리뷰를 요청할 수 있다.
• PR 작성자는 본인의 PR에 대해 변경 요청을 할 수 없다. 이는 다른 팀원들이 수정사항을 요구할 수 있도록 설정된 제한이다.

암튼 str3라고 하니까 str3로 바꾸고 다시 push 하자

 

push하면

 

쓴 Review도 같이 닫힌다.

 

Merge pull request하면 feature/gallery-sort가 develop에 merge가 되었다.

 

develop 브랜치에 변경된 것을 확인할 수 있다.

 

2-3. 깃 충돌 해결하기

feature/gallery-menu는 현재 merge된 상태를 모르고 작업을 진행한다.

 

git push 한다.

 

당연히 충돌이 나기 때문에 full request를 날리지 못한다.

 

command line을 누르면 해결 방법을 알려준다.

 

Step 1: Clone the repository or update your local repository with the latest changes.
git checkout develop
git pull origin develop

Step 2: Switch to the head branch of the pull request.
git checkout feature/gallery-menu

Step 3: Merge the base branch into the head branch.
git merge develop

Step 4: Fix the conflicts and commit the result.
See Resolving a merge conflict using the command line for step-by-step instructions on resolving merge conflicts.

Step 5: Push the changes.
git push -u origin feature/gallery-menu

위대로 실행하면 된다.

 

첫 번째 단계는 원격 저장소의 develop 브랜치에서 최신 변경 사항을 가져와 로컬 브랜치 develop을 업데이트 하란 말이다. 현재 작업하는 곳에는 develop의 최신 버전이 없다.

 

두 번째 단계는 'git checkout feature/gallery-menu'을 입력해서 원래 브랜치로 돌아오는 것인데 위와 같이 'git checkout -'를 입력하면 이전 branch로 돌아온다.

 

세 번째 단계는 업데이트한 develop과 내 브랜치를 합치는 작업이다.

 

인텔리제이에 위와 같은 상황이 발생하는데 HEAD는 실제로 존재하는 것은 아니고 현재 내 위치를 알려준다. 즉 내 대가리가 향하고 있는 곳을 의미하면 된다. 이때, 에러가 발생하는 팀원과 의논을 통해 뭘 선택할 것인지 결정해야 한다.

 

현재는 둘 다 살린다. 고칠 때는 그냥 지우고 저장하면 된다.

 

다시 push 한다.

 

Merge pull request 버튼이 활성화 된다.

 

바뀐 내용을 확인하고 리뷰를 남길 수 있다.

 

merge를 하면 해당 pull request가 closed 된다.

 

완료된 작업은 Project 메뉴에서 옮겨준다.

 

그러면 해당 issue도 closed 된다.

 

2-4. develop -> main으로 merge하기

실제로 배포하는 단계로 이 작업은 짧아야 2주정도 걸린다고 한다. release를 담당하는 개발자가 한다고 한다.

 

New pull request를 살포시 누른다.

 

원래는 block이 걸려야 한다.^^;;; 지금은 연습이니까,,, 이 작업에 관련된 사람이 Review를 통해 approve를 하면 Merge 버튼이 활성화 된다.

 

Develop이 closed되고 유저에게 배포되었다.

 

실제 main에 코드가 반영된 것을 확인할 수 있다.

 

[결론] : 이제서야 제대로 된 충돌을 해결할 수 있을거 같다. 깃도 하다보면 나름 재미있고, 기능이 정말 많다. 모르면 외워