프론트엔드 Github Flow 관리

프론트엔드 Github Flow 관리

Github Branch 용도

1. 각 branch별 용도 설명
   1. release : 상용 배포용 브랜치. 사용시 release_frontend_20240813 등으로 별도 branch로 구분하여 사용
   2. develop : 개발 배포용 (현재 개인의 OCI) 브랜치
   3. feature : 로컬 작업용. 즉 로컬에서 작업하기 위한 환경 위주로 구성되어 있어야 함. 개인의 로컬 작업시에는 feature_dashboard , feature_publishing 등으로 별도 branch로 구분하여 사용
   4. 기타 feature_xxx : 로컬 작업이 끝난 개인의 feature branch

Git Action 관련 용어 설명

1. 내려받기 Action
   1. fetch : 대상 git의 모든 branch의 Log와 상태를 내려받습니다. Log와 상태만 내려받을 뿐 실제로 소스가 병합되지는 않으니 안심하셔도 됩니다.
   2. pull : 대상 git의 대상 branch를 설정하여 소스의 변경사항을 처리합니다. 충돌나는 파일이 없다면 smooth하게 변경사항이 로컬 소스에 적용됩니다.
2. 저장 및 올리기 Action
   1. commit : 현재 Local 소스를 자신의 feature branch에 저장합니다. Git의 장점으로, SVN에서는 오로지 서버 commit만 되었습니다. 때문에 서버가 날아가면 소스의 복구가 불가능했는데 Git을 사용함으로서 로컬이 괜찮다면 소스의 복구가 가능해진 면이 있습니다. 이렇게 상황에 맞춰 유동적으로 소스를 관리할 수 있어 Git의 사용이 일반화되었습니다.
   2. push : 현재 저장된 feature branch의 소스를 Git서버쪽으로 올립니다. 같은 이름의 branch로 올릴수도 있고 변경할 수도 있습니다.
3. 병합과 충돌 Action
   1. merge : 여러 branch에 따로 떨어져 있는 소스를 병합합니다. 보통 master가 되는 branch를 따로 두고 master에 각 feature의 변경 사항이 반영되는 것으로 처리를 합니다. 그러므로 관리자가 필요하며 보통 전담할 수 있는 한 명의 개발자가 관리하는 것이 일반적입니다.
   2. conflict : 소스를 병합하는 위 merge 과정이나 소스를 내려받는 pull 과정에서 같은 소스에 서로의 차이점이 동시에 병합 처리되면 충돌이 발생합니다. 이를 conflict라 하며 처리하기 위해서는 작업자 각자의 Log를 재확인해야 하고 어느 부분에서 충돌이 났는지, 그리고 최선의 처리 방법은 무엇인지가 고민되어야 합니다. 보통 위 merge에서 설명한 바와 같이 단일 관리자로 관리합니다.
   3. 즉 merge와 conflict는 휴먼 에러의 종류로서, 처리해본 경험이 충분해야 처리할 수 있는 사안들로 팀 내에서 관리에 대한 협의가 잘 되어야 합니다.

Github Flow (Merge, Pull, Push 등)

1. 개인의 로컬 작업이 완료되어 feature (이하 origin )에 병합이 필요할 경우
   1. 로컬 작업을 자신의 feature에 commit
   2. origin 과의 충돌 방지를 위해 fetch, pull - origin 에서 개인 feature branch로 향하도록 설정하시고 fetch, pull 을 실행하면 됩니다.
   3. Already Update (이미 업데이트 되었음) 이 뜨면 충돌이 날 염려가 없는 것이므로, 자신의 feature명과 같은 github branch에 push
   4. origin 과의 Merge(병합) 수행 - 작업 담당자 : 박정환 (고정)
   5. 병합 완료 후 전체 메세지로 완료 안내 및 pull 요청
   6. origin 병합 버전과 Sync하기 : 위의 b 작업을 한번 더 수행 (origin 과의 충돌 방지를 위한 fetch, pull 하면 됩니다.
   7. 로컬 정상 반영, 작업 지속
2. conflict (충돌) 발생할 경우
   1. 바로 호출해 주시기 바랍니다. 충돌 난 파일은 보통 revert처리를 하거나, 작업자 별로 확인해서 최신의 Log를 확인해 덮어쓰는 것으로 해결할 수 있으나 우선은 전후상황 대처를 위해 확인이 필요합니다.
3. 기타 평상시
   1. 출근 후 항상 origin 에 대해 개인 feature branch에 fetch, pull 을 실행하시는 것을 권장합니다.

Fetch와 Pull을 왜 같이 사용해야 하는가?

• Fetch, Pull을 항상 세트로 사용하시는걸 권장드립니다. 이유는 아래와 같습니다.
  1. Fetch를 먼저 수행하면 리모트 저장소의 최신 변경 사항을 로컬로 가져오지만, 로컬 작업 브랜치에는 바로 적용되지 않습니다. 이렇게 하면 변경 사항을 미리 확인하고 분석할 수 있습니다. (Log를 가져오는 것이라고 생각하시면 됩니다.)
  2. Fetch를 통해 최신 상태를 확인한 후, 문제가 없다고 판단되면 그때 Pull을 수행합니다. 이 방식은 예상치 못한 충돌을 최소화하며, 작업의 안정성을 높입니다.
  3. Fetch 없이 바로 Pull을 하면 리모트 변경 사항이 즉시 로컬에 적용되기 때문에, 예상치 못한 충돌이 발생할 수 있습니다. 이러한 충돌은 작업 흐름을 방해할 수 있으며, 예기치 않은 Merge Log가 생성될 가능성도 있습니다.