git을 그냥 클라우드에 코드를 올리고 이곳 저곳에서 코딩할 수 있는 용도로만 사용해오다가 git을 제대로 사용해봐야될거 같아서 간단한 Blazor 게시판 프로젝트에 brench 전략을 사용해보고 있습니다.
게시판 프로젝트의 구조는 BoardController에 게시판에 대한 데이터베이스 로직들이 들어있고 페이지에서는 HttpClient를 통해 api를 호출하고 결과를 받아온 다음 보여주기만 하려고 합니다.
이때 브랜치를 develop브랜치에서 feature/database와 feature/boardcontroller로 분기했는데 feature/database브랜치에서의 수정사항과 feature/boardcontroller의 수정사항이 게속 왔다갔다 해야해서 기능하나를 만들때 마다 머지하고 다시 분기해야되는 상황인데 이런경우 브랜치를 어떻게 구성해야 이런문제를 해결할 수 있을까요?
git활용법을 잘 모르다보니 그냥 git 없이 한번에 코딩하는게 더 빠를것같고 비효율적인 느낌이 듭니다…
3개의 좋아요
음… 구체적인 상황을 몰라서 답변하기가 조심스럽습니다.
git 없이 한번에 코딩하는게 더 빠를것같고 비효율적인 느낌
// 느낌으로는1인으로프로젝트를 짜고있는것 같은데 맞을까요?
협업에 굉장히 유리한 측면이라고 생각합니다.
git은 짧은 단위로 분기(Branch 생성)하여 히스토리를 남기는 것이 최대 장점이라고 생각합니다.
히스토리를 보고 협업을 하시는 분 또는 후에 작업하시게 될분에게 많은 도움이 되고,
도움을 받기가 편합니다.
해당 작은 분기(Branch)에서 하고자하는 목표가 뚜렷하다면 리뷰어가 의도를 파악하고 더 나은 방향 및 리펙토링이 쉬워집니다.
개인적인 측면(그리고 협업 모두)으로 유지보수에 좋습니다.
코드를 이해할 때 많은 도움이 됩니다.
예전에 작성한 코드가 기억이 나지 않아 다시 이해하는데 많은 도움이 됩니다.
feature/database브랜치에서의 수정사항과feature/boardcontroller의 수정사항이 게속 왔다갔다…
이 부분이 이해하기 어려운데, 수정하는 파트가 겹쳐서 문제가 생긴다는 것인지 Branch를 왔다 갔다하는 부분이 귀찮다?라는 건지 모호한 느낌입니다.
- 수정하는 파트가 겹친다면 가능한 겹치지 않게 분리해야합니다.
Branch를 왔다 갔다하는게 번거러운 것은 사실입니다. 가능한 왔다 갔다 시선을 뺏기지않게 하나의 분기에 집중하여 끝내고, 다음 분기를 생성하는 것이 좋아보입니다. (혼자서 진행한다면)
만약 다른 문제가 있다면 알려주세요.
기능하나를 만들때 마다 머지하고 다시 분기해야되는 상황인데
필수적이며 장점인 측면이라고 생각합니다.
기능 하나 만들때 마다 분기하고 머지하는 과정이 있기 때문에 히스토리로서 제 기능을 다한다고 볼 수 있습니다.
작은 단위에 분기 일수록 이해하기 쉽고 (나중에? 또는 리뷰어의)시간 절약이 됩니다.
분기해야되는 상황인데 이런경우 브랜치를 어떻게 구성해야 이런문제를 해결할 수 있을까요?
본인의 상항에 알맞는 git 전략을 채택하면 됩니다.
브랜치를 어떻게 구성하냐라는 문제라기 보다는 작은 단위의 분기가 계속해서 발생하는 형태가 좋습니다.
다만, 조금 더 이상적?이라는 말이지, 꼭 이렇게 해야할 필요는 없습니다.
큰 단위의 분기를하면 귀찮은, 번거러움이 줄지만 히스토리측면에서는 분명히 안좋다고 생각합니다.
이를 보안하기 위해서 : 하나의 분기 안에 의도를 명확한 작은 커밋들로 구성하면 좋습니다.
분기를 보고 한번에 파악하기는 힘들겠지만 머지한 PR의 커밋을 하나씩 살펴보는 방식으로 커버가 된다고 생각합니다.
=> 느낌이… 지금 편할 것이냐 나중에 편할 것이냐의 차이 인 것 같네요. (개인적인 측면에서)
git활용법을 잘 모르다보니
많은 경험이 필요한거 같아요.
이해하고 활용하는 것은… 저는 굉장히 어려웠습니다. 얼마되지 않았지만 지금도 여전히 어렵고,
계속해서 문제를 만들고 있습니다.
???
협업을하거나 할 계획이 있다면, 유지보수에 관심이 있다면 git을 활용하는게 좋아 보입니다.
[ 작은 분기의 히스토리 = 가독성 ] 둘의 관계가 끈끈합니다.
조심스럽지만 가독성이 좋은 코드, 가독성이 왜 필요하고 왜 좋은지에 대해 생각해보는게 좋을 것 같습니다.
마지막으로 좋은 의견 부탁드립니다.
6개의 좋아요
적용하기?, 심화과정?, Maui Github 파악해보기?
닫힌(+ 병합된) PR을 보면 무엇을하고자 했는지 파악이 됩니다.
제목 ProgressBar Handlers을 보면 ProgressBar Handler 관련된 수정사항이 있는 걸 파악할 수 있습니다. ( 너무 당연하죠 허허…)
PR 작성 내용을 보면 영향이 가는 곳 : Core, iOS, Android 가 나와있고
해당 PR에서 무엇을 하고자 했는지 CheckList가 작성되어 있습니다.
변경된 파일이 18개이고 글자 수? 202가 추가되었네요
커밋된 개수가 많은데, 커밋 내용을 보면 ProgressBar Handler에 대해 작업한 것을 볼 수 있습니다., 조금 더 분명하고 작은 단위로 보고 싶다면 커밋을 클릭해 확인 할 수 있습니다.
[커밋 세부사항 - Moved Maximum const to ProgressBarExtensions]
[ resolved된 comment ]
resolved된 comment 를 통해 이유를 파악하고, 커밋 내용을 보고 어떻게 변경 되었는지 알 수 있습니다.
ProgressBar - Maximum는 충돌 가능성이 있기 때문에 Extentions으로 뺀것으로 보입니다.
이 커밋의 교훈: 네이밍이 겹쳐 충돌 가능성이 있으며 이 때 Extentions로 빼는 방법으로 해결 할수도 있다.
/*
#### 만약에....
`ProgressBar`에 대해 수정사항이 있을 때
`Extentions`가 왜 있는지 궁금하다면 해당 PR로 확가능하겠죠?
만약에 '`Extentions` 가 왜 있는거야'라고 생각하고, `Extentions` 없애고 `ProgressBar`에 다 합쳐버린다면 문제가 생기겠죠?
이런 경우 히스토리를 보고 예방 및 문제 진단이 간단해집니다.
*/
/*
커밋을 `Removed ProgressColor property (for now)` 보면
`ProgressColor` 속성을 일시적`(for new)` 으로 제거한 것을 알 수 있습니다.`
*/
글 작성은 어렵습니다 
5개의 좋아요
오우… 정성스러운 답변 너무 감사합니다ㅠㅠ
1인으로 프로젝트를 하고 있고 수정하는 파트가 겹치는 상황입니다. 말씀하신대로 겹치지 않게 하려면 feature/database의 기능을 완벽하게 구현해놓고 feature/boardcontroller를 구현해야합니다.
아마 제가 기능정의서나 이런것들을 미리 정의해두지 않고 바로바로 기능을 구현하고 있는 상황이라 이러한 문제가 발생하는 것 같습니다…
3개의 좋아요
음… 겹치는 부분은 여러 방법이 있을 것 같은데,
제가 아는선에서 말씀 드리겠습니다.
겹치지 않게 작은 단위로 분리하는게 제일 중요하구요.
어쩔 수 없이 겹치게 되었다면
윗단?과 아랫단을 정하고 계속해서 Rebase과정을 통해 충돌을 해결 할 수 있을 것 같습니다.
마찬가지로 굉장히 번거롭고 실수가 빈번한 작업입니다.
그렇기 때문에 현재들이는 비용은 조금 더 늘어나지만 여러 이점 및 후에 비용을 줄 일 수 있기 때문에 작은 단위를 계속 강조 드립니다.
음… 간단하게 말하자면
Main에서feature/database를 생성합니다.feature/database를 기준으로feature/boardcontroller를 생성합니다.feature/database가 변경 될 때 마다feature/boardcontroller에서feature/database를 기준으로Rebase합니다.
그러면 사진과 같이 분기가?? 정렬??됩니다.
겹치는 파트가 있으니 Rebase 할 때마다 일일이 충돌(Conflict)를 해결해야 합니다.
다른 방법으로는 분기 및 커밋을 하지않고 작업하는 방법입니다.
현재 방식은 분기를하고 분기에 맞는 작업을 먼저하는 방식인데,
반대로 작업을 먼저하고 분기 및 커밋 날리기…
먼저 database, boardcontroller에 대한 작업을 모두 끝내고 branch를 생성하여 해당 파트만 커밋하는 방식이 있습니다.
- 추가로
파일 단위가 아닌줄 단위로 커밋이 가능합니다. 줄 단위로선택적으로 커밋 할 경우…branch와 관련 기능이 맞는지 확인하는 과정이 번거롭고 실수할 가능성이 높습니다…
[ Github Desktop ] 사진입니다.
왼쪽에 줄 번호를 보시면 파란색으로 나와있는데, 파란색으로 된 영역이 커밋으로 올라갈 영역입니다.
변경된 사항의 줄 번호를 클릭하면 파란색 영역이 해제 또는 활성화가 됩니다.
이러한 방법으로 하나의 파일 전체를 커밋하는게 아니라 파일 안에 줄 단위??로 커밋 할 수 있습니다
3개의 좋아요
프로젝트의 구성요소들의 역할에 대한 구분으로 브랜치를 분할하시고 쭉 개발하시려고 하신것 같아요.
깃과 어울리지 않는 의도이신 것 같습니다.
feature가 있는것으로 보아 git flow도 도입을 하신 것 같은데,
git flow는 저에겐 꽤나 복잡한 브랜칭전략이라서 추천드리기로는 git flow는 차후에 써보시는걸 추천합니다.
아무튼 feature 그룹이 있는 상태에서 feature라는 단어에 주목을 해보시자면 깃은 이슈? 뭐라고 해야할까요 단어를 생각하지 못하겠네요… 아무튼 건바이건으로 쪼개서 쓰는 성향?입니다.
그러니까 지금 개인프로젝트이시지만 협업프로젝트라고 상상을 해보자면
develop이나 master나 아무튼 중심이 될 수 있는 브랜치는 어떤 협업개발자가 체크아웃해서라도 바로 빌드? 사용?이 가능해야합니다.
말씀하신 상황에선 database나 controller 브랜치나 쭈욱 끌고 가시면
master든 database든 controller든 어떤 브랜치에서도 갈무리된 최신 최종 소스 상태를 아무도 가지고 있지 않게 됩니다.
깃은 권투 쨉처럼요, 건바이건으로, feature라는 이름처럼 작은 기능 단위 하나씩으로 짧게 치고 빠지는게 나아요. 그러니까… 예시를 어떻게 들어야할지 지식이 부족해서;;
controller의 전반적인 개발사항을 controller 브랜치가 끌고 가는게 아니라 controller 중 하나의 이슈만 feature 그룹의 한 개 브랜치로 develop이든 master에서 나왔다가 그 이슈가 마무리되는데로 다시 들어와야되요. 브랜치가 쭉 위로 가는게 아니라 짧게 튀어 나왔다가 들어오는 겁니다.
그래서 중심 가지에서는 항상 어느정도 갈무리된 최신, 최종 상태의 소스를 가용하게 되구요.
A라는 사람이 B라는 기능추가에 꽂혀서 협업프로젝트에 투입되었을 때
master에서 feature/B 라는 브랜치를 가지고 새로 빠져나와서 몇날 몇일을 B 라는 기능을 개발을 하더라도 프로젝트는 A 사람과 상관없이 계속 디벨롭 되어 가는 겁니다. 그러다가 A 사람이 B 기능 다 만들었다! 하면 중심 브랜치로 들어오구요.
2개의 좋아요
이미지 출처 : 아이소메트릭 출하 시 프로덕션 비디오 애니메이션 스톡 동영상 비디오(100% 로열티 프리) 23370043 | Shutterstock
공장의 공정처럼 앞에서 일 처리가 되지 않으면 뒤쪽 공정을 하는 사람은 그동안 대기를 해야 합니다.
초록색 및 노란색 공정에서는 앞에서 물건이 나오고 포장하며 배송하는 과정이 생깁니다.
물건 이동 - 포장 - 배송
총 3개의 프로세스인데, 물건이 레일을 통해 사람 앞으로 이동하지 않으면 포장이 불가능합니다.
포장이 안된 상태로는 배송도 안되구요.
즉 앞선 공정이 진행이 안되면 뒤에 공정이 불가능해서 대기해야합니다.
@신현뚜벅 님의 의견은 _____ 인 것 같습니다.
의사진의 빨간색 공정과 같이 어느 공정의 의존 없이 단독으로, 혼자서 공정이 가능한 형태가 되어야합니다.
그러기 위해서 작은 단위의 이슈들을 생성하고 하나씩 해결하는 방법으로 (건바이건 형태) 진행 해야 합니다.