상세 컨텐츠

본문 제목

git stash (feat. 내가 왜 마스터 브랜치에 있지) & pull request (feat. 로컬, 리모트 개념)

TIL (deeply)

by NayC 2022. 1. 13. 14:46

본문

728x90

따로 branch를 만들어주지 않고 clone 받음
-> local 환경 설정을 해주면서 변경한 것들이 꽤 많아가던 시점에서야 master를 망치고 있었다는 점을 깨달음

1. stash에 내가 수정한 것들 보내고, master 원상 복귀
2. git flow 이용해서 새로운 브랜치를 만들고, 거기에다가 내가 unstash해주자
(1) brew install git-flow-avh
(2) git flow init
(3) cf) git branch -r 로 이전에 브랜치 이름들은 어떤 통일성을 지니고 있는지 확인해주기
(3) git flow feature start 원하는 브랜치 이름으로 새로운 브랜치 만들어주기 (이러면 'feature/원하는 브랜치 이름' 이런식으로 형성됨)
- feature는 어디서 왔다? develop
(개념적이기도 하지만 계속 이렇게 만들어왔다는거)
https://techblog.woowahan.com/2553/
(4) 이제 unstash해줘서, 결국 새로 만든 브랜치에 내가 원하는 내용을 넣어줌
(5) develop에 commit, push해주기
- git push origin develop


(5)는 '완전히' 잘못 생각한 부분임
- 내가 master 원상 복귀 해준다고 새롭게 만든 브랜치 이름을 A라고 하자.
(5)처럼 해버리면 A를 만들어준 의미가 없음. 어디에도 A 흔적은 없이 develop만 남음.

다행히 지금 local에서만 발생하여 (master에서 나온 '찐' develop에는 push가 안 된 사항)

 

Q. 어떻게 복구를 해야할 것인가.

지금 내가 원하는거 : (로컬) develop 브랜치에 push 전 브랜치인 A로 되돌아가서, A의 '리모트' 브랜치를 만든 후에, pull request로 develop가 pull을 받을 수 있게 하는 것 ('찐' develop에 merge하는건 최후 단계. 회사 다니면 보통 merge는 내가 안 할 가능성이 큼)
- A의 흔적을 만드는 것 (소명을 다하고 develp가 pull을 받게 해줬다는 그 흔적)

1. (5) 때문에 지금 브랜치가 A가 아니라 develop지.
-> git flow feature start 원하는 브랜치 이름
- 자동으로 해당 브랜치로 checkout 됨

2. (로컬이긴 하지만 그래도) develop는 merge로 접근해줘야 하는거였는데, 나는 그냥 바로 push 해버려서는 내용이 바뀌었지
-> git checkout develop
-> git pull (다시 정상적으로 만들어주고)

3. (우선) 흔적을 만들어주자 = pull request 하게 해주자.

-> 가장 먼저 해야할 일. pull request 할 수 있도록 '리모트에 브런치 생성' 해주기

현재 브랜치를 살펴보기 위해 git branch 하니 develop에 *
-> A로 수정. git checkout A


A 브런치를 리모트에 생성하기 위해서는?
-> A를 push 하면 됨. (push 과정 동일하게 하고) git push 만 하면 됨

//

이러면 pull request 할 수 있는 준비가 만들어진 것.
- 만약 로컬 A에서 수정이 일어나면 리모트 A로 push 해주면 됨
-> 이전에 pull request 잘 연결만 해놓았더라면 저절로 develop에도 pull request 되어 반영된다.

cf) 리모트에 있는 브런치들 확인하려면 : git branch -r (여기서 r은 remote)
- : 표시가 enter 누르면 더 나오게 되어있다는 표시 (enter 계속 누르면 브랜치들 계속 검색되어 나옴)

p.s
뭔가 새로 clone 받으면 브랜치부터 파는 습관을 들여도 좋을 것 같다.
(1) 수정 안할 거 같은거 - develop... (브랜치 이름은 통일성 가지게)
(2) 수정 할 거 같은거 - featrue... (브랜치 이름은 통일성 가지게)

 

 

 

 

 

 



cf) 이해하기 좋은 자료들 - 튜토리얼 b

https://git-scm.com/docs/git-branch

 

Git - git-branch Documentation

If --list is given, or if there are no non-option arguments, existing branches are listed; the current branch will be highlighted in green and marked with an asterisk. Any branches checked out in linked worktrees will be highlighted in cyan and marked with

git-scm.com

https://git-scm.com/docs/git-checkout

 

Git - git-checkout Documentation

When there is only one argument given and it is not -- (e.g. git checkout abc), and when the argument is both a valid (e.g. a branch abc exists) and a valid (e.g. a file or a directory whose name is "abc" exists), Git would usually ask you to disambiguate.

git-scm.com

https://danielkummer.github.io/git-flow-cheatsheet/index.ko_KR.html

 

git-flow cheatsheet

 

danielkummer.github.io

(이거! 직관적이고 알록달록하게 잘 정리되어있다.)

 

https://techblog.woowahan.com/2553/

 

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

{{item.name}} 안녕하세요. 우아한형제들 배민프론트개발팀에서 안드로이드 앱 개발을 하고 있는 나동호입니다. 오늘은 저희 안드로이드 파트에서 사용하고 있는 Git 브랜치 전략을 소개하려고 합

techblog.woowahan.com

 

728x90
반응형

'TIL (deeply)' 카테고리의 다른 글

js) Destructuring  (0) 2022.02.11
코드 '제대로' 읽기  (0) 2022.01.20

관련글 더보기