git (26) 썸네일형 리스트형 intelliJ에서 Develop 기준 공동 작업 브랜치 만들기 Develop 브랜치를 기준으로 공동작업 브랜치를 만들어야 해서 IntelliJ에서 이를 실행하였다. 1) 우측 하단 브랜치가 보이는 부분에서 New branch로 브랜치 생성 2) 해당 브랜치는 local 환경에서 만들어진것이므로 나밖에 보지 못한다. 공동 작업을 해야 하니까 이 브랜치를 remote(원격) 환경에 올려야 한다. 그래야 Remote Branches에서 다른 팀원도 내가 만든 브랜치를 checkout 하고 사용할 수 있다. 3) 터미널에서 내가 만든 feature/market-event 브랜치로 checkout 되어있는지 확인하고, 아래의 명령어를 입력한다 git branch -r 리모트 환경으로 가서 git push origin 만든 브랜치 이름 origin에 내가 만든 브랜치를 pus.. 하위 브랜치 이동 시에(develop > feature) 취해야할 행동 정리 Git을 사용하다보면 feature 브랜치에서 작업 후에 develop 내용을 Merge하여 사용해야 할 때도 있지만, develop 브랜치 하위의 feature 브랜치로 넘어가서 작업을 해야 할 때도 있다. 그렇다면 develop > feature 브랜치로 이동 시에 어떤 행동을 취해야 할까? 이에 대해 정리해보고자 한다. 나는 IntelliJ를 사용하고 있다. 1) develop 브랜치에서 우클릭 > Checkout 후 원하는 feature 브랜치로 이동한다. 2) Terminal을 열면 checkout한 브랜치로 경로가 이동해있다. 여기서 git pull origin develop 을 작성해준다. 3) 위의 코드를 입력하고 나면 azure에서(azure을 사용하고 있다) 비밀번호를 입력하라고 나오는.. Please enter a commit message to explain why this merge is necessary ~ 다른 feature 브랜치로 checkout 하고 develop 브랜치를 merge 해와서 써오려고 하던 중 (git pull origin develop) Please enter a commit message to explain why this merge is necessary ~ 라는 메시지가 터미널에 출력되었다. 해당 feature 브랜치로 develop 내용을 가져오려면 왜 merge를 해야 하는지에 대한 커밋 메시지를 작성하라고 하는데, 처음에는 좀 쫄았(?)다가 그냥 메시지 for merge 이렇게 쓰고 develop 내용 가져와서 push를 하니 정상적으로 해당 브랜치에 develop 최신 내용들이 반영되었다. 1) 터미널에서 위와 같은 메시지가 출력되면 i 를 누른다 (커밋 메시지 입력) 2.. Untracked Files Prevent Merge Git을 사용하던 도중 develop 브랜치를 Update 하려던 도중에 Untracked Files 때문에 최신 작업 사항 반영들이 Merge 되지 않았다. 내가 해결한 방법은 다음과 같다. 1) IntelliJ Terminal에서 git status로 Untracked Files들이 있는지 확인 -> 나의 경우에는 1개의 파일이 Untracked File로 확인이 되었다. 2) 다음의 명령어 입력 git clean -fd 다른 분들의 방법을 찾아보니 git clean -d -f -f 로도 삭제가 되는 것 같았다. 3) 다시 git status로 Untracked File이 제거되었는지 확인 4) develop 브랜치 Update로 최신 작업 사항들과 잘 Merge 되었다. git fetch 기능 이용하기(azure + intelliJ) git fetch란? 원격저장소(azure devops)의 데이터를 로컬에 가져오기만 하기 원격저장소(azure devops)에서 최신 메타데이터 정보를 확인하라는 명령 방법 1) IntelliJ에서 command + shift + a 후 Fetch 검색 2) azure devops에 로그인 후 fetching 되면, 원격저장소에 저장된 최신 git repo들을 확인할 수 있다. -> 크게 Local, Remote 2가지로 나뉜다. feature-branch 네이밍 방법 (develop에서 feature 브랜치 만들기) git flow 전략을 이용해서 Develop 브랜치로부터 파생된 feature-branch를 만들어야 해서 팀원들끼리 네이밍을 고민하던 중에 2가지 정도의 방안이 나왔다. 일단 git flow는 Git으로 협업을 할 때, 서로간의 약속인 방법론을 뜻한다. 5가지의 브랜치들이 존재한다. 1) main(master) : 기준이 되는 브랜치로 제품을 '배포'하는 브랜치 2) develop : 개발 브랜치, 각자 작업한 기능들을 합(Merge)하는 브랜치 3) feature : 단위 기능을 개발하는 브랜치. 기능 개발이 완료되면 develop 브랜치에 합침 4) release : 배포를 위해 main 브랜치로 보내기 전 QA를 하기 위한 브랜치 5) hotfix : main 브랜치로 배포를 했는데 버그가 생겼.. 이전 1 2 3 다음
