ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • git - Branch (with eclipse)
    궁금했던 것들/git 2021. 10. 31. 17:57

    개발을 하면서 SVN, GIT 이렇게 두가지 형상관리 프로그램을 사용해 봤다.

    이클립스(STS)에서 제공하는 기능으로만 사용했었고 내가 느꼈던 점을 각각 적어본다면

     

    SVN : override and update 기능 때문에 충돌(Conflict)를 훨씬 편하게 처리 가능했다.

    GIT : 전체적으로 SVN 보다 불편하다고 생각했다. 이클립에서 항상 문제가 많이 생겼고 충돌(Conflict) 때문에 애먹은 적이 많다.

     

    그러나 주변 사람들을 보면 git이 훨씬 좋다고 git을 통해 개발하니 너무 좋다 이런 이야기를 많이 하고 인터넷을 찾아봐도 git이 더 좋고 branch를 통해서 기능별로 따로 개발을 해서 master branch에 붙이고 이런 이야기들을 자주 들었다.

     

    나는 branch를 사용 해봤지만 그렇게 큰 장점을 느끼지 못했고 사실 제데로 사용 할 줄도 몰랐다...

    이번 포스팅을 하면서 git의 전체적인 구조와 branch를 사용 하는 이유, 장점, 단점 등을 알아보고 내가 개발하는 환경(STS) 에서 어떻게 사용하면 좋을지를 알아보겠다.

     


     

    Branch 종류와 사용 예

     

    우선 가장 중심이 되는 Branch를 Master Branch 라고 한다.

    일반적으로 개발을 시작한다고하면 Master Branch를 CheckOut 받아서 개발환경을 셋팅한다.

     

    그리고 나서 개발자 별로 또는 기능별로 Branch를 만들고 개발이 완료 되면 Merge를 통해서 Master Branch에 반영한다. 이런 개발자 별, 기능별 브랜치를 Feature Branch 라고 한다.

     

     


     

    이클립스에서 사용해보기

    우선, 완전 처음부터 하지 않고 Master Branch만 사용해 왔던 내 환경에서 브랜치 생성, 사용, 삭제 이렇게 다뤄 볼 것이다.

     

    1. 브랜치 생성

    (프로젝트 우클릭 - Team - Switch To - New Branch)

     

    New Branch 누르면 아래의 팝업이 나오는데 Branch name를 눌려주고 그대로 Finish 버튼을 누르자

     

    master 였던 브랜치가 새로만든 브랜치로 변경 된다.

     

    2. 변경된 브랜치로 commit and push

     

    단순 주석을 추가

     

    commit Message 입력 후 commit and push 클릭

     

    Branch가 freature_branch 인것을 확인하고 Preview 클릭

     

    Push 클릭

     

    Close 클릭

     

     

    3. Master Branch로 변경후 Merge 작업

     

    브랜치를 master 변경

     

    Merge 클릭

     

    Merge할 브랜치(featrue_branch) 선택후 Merge 클릭

     

    완료 되었다는 팝업!

    그리고 merge한 내용을 다시 Push 해주면 끝이다.

     

     

     

    순서를 다시 정리 하자면

     

    새로운 브랜치 생성(자동으로 브랜치 변경) > 변경된 브랜치에서 소스 수정 > 변경된 브랜치에서 소스 commit and push > master 브랜치로 변경 > master 브랜치에서 merge 작업 > master 브랜치에서 merge된 내용 push

     

     


     

     

    충돌(Conflict) 해결

    위에 한것 처럼 그냥 아무도 내가 만진 소스를 수정하지 않으면 아무 문제 없이 Merge가 된다.

    항상 이랬으면 좋겠지만 .... 우린 다 알고 있다.

    내가 만지는 소스를 누군가도 분명 수정을 한다는 사실을....

     

    아래와 같은 상황이라고 생각을 해보자.

     

    개발을 하다보면 위 사진처럼 공통 서비스 같은것을 둘다 동시에 수정하는 경우가 생긴다.

     

    각각의 브랜치의 입장에서 commit and push > merge 를 보자.

     

    Feature 1 : 아무런 문제 없이 그냥 commit push -> merge 작업이 이루어 졌을 것이다. 

    Feature 2 : 충돌이 발생했을 것이다. 브랜치를 만들었을 시점의 commonService와 Freautre1이 Merge한 commonService가 다르기 때문이다.

     

    ( 왜 항상 나는 Feature2 의 입장인지 모르겠다... 그래서 커밋을 자주 하라는 말을 선배들이 하나보다. )

     


    혼자서 위와 같은 상황을 만들어보자...

     

    1. 브랜치를 2개 생성

    2. 한 브랜치에서 파일 수정후 commit and push -> merge 진행

    3. 나머지 브랜치에서 같은 파일 수정후 commit and push -> merge 진행

     

     

    두번재 브랜치에서 내용을 수정하고 Master 브랜치에서 merge를 하고 나니 충돌이 생긴 파일에 아래와 같이 충돌된 소스를 보여준다.

    merge를 하니 충돌 생겼다.

     

    이때 소스를 원하는 소스로 수정 후 해당 파일을 저장하면 자동으로 Merge 상태가 된다.

    그러고 나서 원래 하는것 처럼 Commit and Push 해주면 끝이다...

     

    이렇게 파일이 한개면 그나마 괜찮은데 여러개거나 개행문자 차이 때문에 전체 파일들이 충돌로 나올 수 있다. 그럴때는 조심히 Reset을 하거나 하나하나 충돌을 해결 해 줘야한다.

     

    그리고 한번씩 이유를 알수 없게 fetch url 이 사라져버린다... 이상하다 항상...

     

    마지막으로 브랜치를 삭제하는 법을 알아보겠다.

     

     

     


     

    브랜치 삭제

     

    굳이 사용하지 않는 브랜치를 삭제하지 않아도 괜찮다. 하지만 브랜치 개수가 많아지고 하면 보기에도 않좋고 기능적으로 만든 브랜치가 아니라 내가 개인적으로 사용할 브랜치였다면 지우는게 맞다.

     

    그래서 로컬과 리모트 둘다 삭제하는 방법을 알아 보겠다.

     

     

    1. 로컬 삭제

     

    로컬에서 브랜치를 삭제하는것 매우 간단하다.

    아래 사진처럼 Git Repositories 탭에서 삭제할 브랜치 > Delete Branch를 하면 끝이다.

     

     

    2. 리모트 삭제

     

    아래의 사진처럼 Push 를 클릭해 준다.

     

    그리고 나서 아래와 같이 팝업이 뜨는 remote 주소를 확인하고 next를 눌려준다.

     

    Next를 누르면 아래와 같이 또 팝업이 뜬다.

    Remote ref to delete 를 클릭해서 삭제 할 브랜치를 선택하고 오른쪽의 Add Spec 를 클릭해준다.

     

    그럼 아래의 표에 삭제한다는 내용이 추가된다.

     

     

    그리고 Next를 눌려주자 그러면 아래의 사진 처럼 팝업이 나오고 Finish를 누르면 Remote에서도 삭제가 된다.

     

     

     


    마무리하며..

    일단 git을 사용 할 때는 같이 협업하는 사람들과의 분업이 중요할거 같다.

    최대한 충돌이 생기지 않도록 작업을 분배하고 그렇게 각자가 필요한 브랜치들을 만들어서 개발을 진행한다면 좋을거 같다.

     

    그렇게 큰 프로젝트에 참여해본적이 없어서(많으면 4명) 항상 마스터 하나에만 해왔다.

    근데 이제 조금 알았으니 혼자라도 로컬에서 브랜치를 생성하고 기능별로 만들어서 하는 연습을 차근차근 해야겠다...

    댓글

Designed by Tistory.