(알아두면 개발팀장가능) GitFlow vs Trunk-based 협업방식

Рет қаралды 123,194

Күн бұрын

Пікірлер: 121

@SW-vc9jm 2 жыл бұрын

생활코딩님이 정석코스 밟아온 엘리트 개발자로서 강의하시는 느낌이라면 코딩애플님은 그냥 동네 공사장 막노동판에서 구르던 사람이 흥미로 시작해 독학하여 신의 경지에 이른 뒤 어둠의 버전으로 알려주시는 느낌이 들어서 좋아요. 이래서 여성분들이 나쁜남자에게 끌리나봐요.

@bloom6561 2 жыл бұрын

ㅋㅋㅋ 근데 신기한건 생활코딩님도 비전공자 흙바닥? 출신이시라는거

@xeropise 2 жыл бұрын

어둠 좋아

@raykim9760 2 жыл бұрын

생코는 찐 개발자는 아니십니다 ㅎㅎ 개발 강의를 초등학생이 봐도 이해하기 쉽게 전달하는 능력이 탁월하신 분..

@koineeulogia5168 2 жыл бұрын

비유 찰떡...

@성이름-i2b3e 2 жыл бұрын

나쁘다기 보다는 재미 등 매력이 더 있어서 그런 게 아닐까요

@averageguysnextdoor 2 жыл бұрын

오늘도 영혼없고 알찬 강의 감사합니다

@navidev2281 2 жыл бұрын

프로토타입부터 서비스 종료까지 마스터 하나로 써먹은 우리회사는 상남자 그자체

@ruse1501 Жыл бұрын

ㅋㅋㅋ

@하요-y4n Жыл бұрын

고인물만 있는거 아님?ㅋㅋ

@MN-do7hk Жыл бұрын

@@하요-y4nㄹㅇㅋㅋ

@계란찜-j8x Жыл бұрын

ㄹㅇ 강심장들만 모여있구만...

@slavetocode 9 ай бұрын

믿을건 revert 하나뿐이네 ㅋㅋ

@nananana0099 2 жыл бұрын

깃플로우 전략은 CICD가 갖추어져 있을때 더 효과적입니다 영상 내용과 동일하되 master와 develop은 무조건 중간에 release 브랜치를 거치는 형식의 깃플로우 전략을 사용중입니다. 깃플로우 전략은 CICD 환경이 갖추어져있을때 더욱 강력합니다. 크게 dev, stg, prd 환경을 각각 develop, release, master 브랜치와 접목시켜서 3단 테스트 구조를 갖출 수 있습니다. 단순 온프램 환경 뿐만 아니라 클라우드환경, 쿠버 환경에서 모두 통용되어서 되려 더욱 효과적입니다

@beepandbap. 2 жыл бұрын

주영이 똑똑하네 아주 칭찬해 정말 세상에서 제일 멋진 개발자야.

@오늘도공대생 2 жыл бұрын

혹시 develop, release, master 브렌치마다 다른 서버에 올려서 테스트 할 수 있다는 말씀이 맞을까요?

@Raul-bf8tr 2 жыл бұрын

아마 여기서 말씀하신 CICD환경에서 싫어한다는것은 이러한 환경분리가 안되어있고, main branch에서만 CICD를 수행하는 단순한 환경만을 말씀하시는 것 같아요.

@gaepopodong Жыл бұрын

주요 브랜치마다 CI/CD 환경설정해야하니 안좋아한다는 뜻 같아요😅

@hohodak4792 11 ай бұрын

CICD가 뭔가요..?

@Narimorihari 2 жыл бұрын

깃허브 시리즈 더 “해줘”

@성이름-i2b3e 2 жыл бұрын

응애

@rendarcb1908 2 жыл бұрын

예전부터 봤지만 진짜 짧게 쏙쏙 잘들어옴 ㅋㅋㅋ

@madhatter1282 2 жыл бұрын

자칫 지루할 수 있는 강의에 슨생님만의 유쾌한 유우머가 참 좃습니다.😉😉 항상 잘보고 있습니다.

@mwoleuba8430 2 жыл бұрын

실무에서는 대부분 test 브랜치나 qa 브랜치같은 거를 만들어서 해당 브랜치에 push 했을 때 테스트 서버, qa 서버에 배포해서 테스트 할 수 있도록 합니다. 저희 실무에서는 develop은 그저 master에 배포하기전 안전한 저장소로 사용만하네요. 이것도 각자 회사에서 정책 플로우가 다르니 입사하면 문조건 깃 플로우가 어떻게 되먹었는지 확인 꼭 하셔야됩니다~

@128beat Жыл бұрын

좋좋소 우물에서 혼자 코딩하는사람이라서 협업해본적 없어서 이직에 대한 두려움이 있었는데 큰 도움 되었습니다. 저는 브랜치따위는 필요 없겠네요.

@구름-f1z 2 жыл бұрын

2:40 ‘상남자’ 이 부분 ㅈㄴ 웃기네 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

@최강재-y9c 2 жыл бұрын

야가다 스타일 강의 너무 좋읍니다 ㅎㅎ 깃 머지 컨플릭션 관련 강의가 절실합니다!!

@cappuccino2345 2 жыл бұрын

미국 현직 개발자인데 이거 ㄹㅇ 꿀팁.

@파랑레몬캔디 8 ай бұрын

Git flow main : tag(이미 배포 된 플젝) develop : 배포 직전 완성된 플젝 브랜치 feature : 신기능 release: 배포 직전 플젝 임시 브랜치 hotfix: 버그 수정 급한 건 브랜치 Trunk based main 브랜치만 만들고 곁가지를 하나씩 생성 -> 소스 코드 여러개 관리할 필요 없음 테스트 빈번해야 함 소스가 안정화 되어 있는 경우

@ktm2718 2 жыл бұрын

상남자는 뭐든지 메인브랜치에 통합한다.

@김아무개-f9v Ай бұрын

프로젝트 시작 : (개발자들 다 모여서) 브랜치 전략 어쩌구. main, dev, feat 나누고 feat 브랜치 이름은 지라 티켓명으로. 커밋 컨벤션은 어쩌구. 모두가 의욕 뿜뿜 프로젝트 1개월 경과 : 다 경력인데도 누군가 하나 핫픽스 한다고 dev에 허락맡고 푸쉬하기 시작함 프로젝트 2개월 결과 : 모두가 dev에 푸쉬 ㅋㅋㅋㅋ 프로젝트 완성 후 git graph 보면 처음에만 복잡하고 나중엔 두줄 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋdev / main ㅋㅋㅋㅋㅋ

@zelda472 2 жыл бұрын

공부가 되었습니다. 개념 정리 언제나 감사합니다.

@yarn_dev 2 жыл бұрын

이번 강의만큼은 생활코딩님보다 더 이해하기 쉬웠다 ㅋㅋㅋㅋ

@DennisPark2220 2 жыл бұрын

진짜 개꿀잼이다 ㅋㅋㅋ 이렇게 유익하면서 재밌는 강의 처음인듯

@SeanPark7 2 жыл бұрын

회사에서 하고 있던 방식이 Trunk-based인지 몰랐었는데 확실히 알았네요!

@sweetman9138 Жыл бұрын

돈 무한 복사에서 라면 먹다 뿜었네요 유용하네요 잘 보고 갑니다

@pinblog1648 2 жыл бұрын

강의가 너무 웃겨서 머리에 쏙쏙 박히네요 ㅋㅋㅋㅋㅋ

@jooh_lee 2 жыл бұрын

팀장이거나 노예거나 ㅋㅋㅋㅋㅋ 왤케 극단적이에여 ㅠ

@wjdeh10110 2 жыл бұрын

설명 넘 깔끔하고 좋네요!!

@Qwertyuuipasdf 2 жыл бұрын

설명 깰끔! 잘들었습니다~

@28majon 2 жыл бұрын

형 넘 좋앙~ 꿀강의 떙큐

@YY-wh9ln 2 жыл бұрын

00:10 갑자기 내 생각이 화면에 써져서 놀랐네

@공중변소휴지도둑 2 жыл бұрын

보기편한 정리 감사합니다

@126gnuj 2 жыл бұрын

넘모 재밌네요☺️❤

@gkgkfkgmgg Жыл бұрын

ㅋㅋㅋㅋ말씀하시는게 너무 웃긴데 내용은 핵심만 콕콕이네요

@윤세희-l6o 11 ай бұрын

실수로 팀장님께 보내고싶은영상

@choyeonk3358 4 күн бұрын

ㅋㅋㅋ완성되면 메인에합침 > 시간되면으로 바뀌는게 개웃기넼ㅋㅋㅋ

@ExtremeSparkling 2 жыл бұрын

큰 도움이 됩니다!

@leejeff3949 2 жыл бұрын

2:49 애플 쌤 요즘것들은 상남자 반대말로 하남자 라는 말을 쓰는듯 합니다 (오늘도 젊음 1스택)

@chimsil_dev Жыл бұрын

전 지금 2번째 전략을 쓰고있습니다 ㅋㅋ 프로젝트 팀원이 저 포함 5명밖에 안되기때문에

@vvzmsqufvv 2 жыл бұрын

쌤 사랑해요.

@koineeulogia5168 2 жыл бұрын

사랑합니다.

@vagabond7199 Жыл бұрын

잘 봤습니다. 어떤 책을 보면 좋을 지 추천해 주세요.

@choummmm 2 жыл бұрын

그러니까 수퍼 겁쟁이 클럽 사람들이 하는 전략이다 이거죠?

@jm7783 2 жыл бұрын

감사합니다

@rudwnok 2 жыл бұрын

깃플로우 방식은 굉장히 많은 브랜치가 계속 생성이 되서 주기적으로 삭제가 되거나, 자동삭제를 시켜줘야되고, 단계가 많아서 손이 더 많이가긴 합니다. 테스트를 할수있는 여건이 된다면, 트렁크 방식이 훨씬 빠른 배포가 가능해서 서비스의 생산 속도가 높아집니다.

@linuxlinux7620 2 жыл бұрын

설명잘한다잉

@김정현-m1f 2 жыл бұрын

저희는 핫픽스 브랜치를 릴리즈브랜치에서 따고 완전히 핫픽스까지 다 완료되고난 후에 메인 브랜치로 머지해요

@ckstmznf 2 жыл бұрын

말 나온김에 CI CD도 한번

@HowlGH 2 жыл бұрын

상남자 겁쟁이 ㅋㅋㅋ

@sub-.-account Жыл бұрын

0:10 처음 보면서 든 생각) 난가?

@_namu__ 2 жыл бұрын

우리 아이가 좋아해요

@NastyPnk 4 ай бұрын

0:12라면 면발 튀기기전

@김창훈-l2l 2 жыл бұрын

궁금한 게 있습니당 새로운 기능이 필요할 때 브랜치를 새로 파서 사용한다면, 해당 기능을 개발하는 팀에서는 어떻게 저것을 협업하는건가요? 그냥 단순하게 새로 git을 하나 파서 거기서 branch 나누고 협업한 뒤에 완성물을 가져오는걸까요?

@shinex_car 2 жыл бұрын

보통 브랜치는 기능별로 나누게 됩니다. feature_기능명, feature/기능명 으로 만든 뒤, 그 브랜치에 대고 merge를 하면서 서로서로 협업 하는거죠. 하나의 git repository는 프로그램 하나를 의미합니다.

@zaely_o Жыл бұрын

감사하빈다.

@수경김-g7n 2 жыл бұрын

막노동공장일하는데 이거 잼나보인다

@idow4934 2 жыл бұрын

사실 팀장도 노예잖아 ㅋㅋㅋ

@StoneHeadKing 2 жыл бұрын

형님들 유니티도 깃허브 이용하는게 일반적인가요?

@jeffrey0208 Жыл бұрын

리마인더 감사 :)

@nas16 7 ай бұрын

코딩애플 만세~!

@원장-r6f 2 жыл бұрын

릴리즈는 안써봤는데 써보겠슴다

@argendarne8204 2 жыл бұрын

코딩애플 선생님은 어떤 방식 쓰세요

@everydaydueday 2 жыл бұрын

'이제' 없이 말 못하는건 모든 개발자 공통인가바여 ㅋㅋㅋㅋㅋㅋ

@superspeedmotor 2 жыл бұрын

유저들은 데이터 쪼가리 주면 좋아 한데 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

@happi1010 2 жыл бұрын

브랜치를 미리 만들어 놔야 하는거죠?

@8toshi 2 жыл бұрын

개웃기네 진짜 ㅋㅋㅋㅋ

@anen2909 2 жыл бұрын

두 방식 모두 메인 브랜치를 사본에 수시로 업데이트 해야하는건 동일한거죠?

@anen2909 2 жыл бұрын

그렇게하지 않으면 컨플릭트 에러가 많이 발생할것 같은데 제가 잘못알고있는 걸까요?

@d3v3r_ 2 жыл бұрын

main을 직접 건들지 않는 이상 충돌 날 일은 웬만해선 없겠죠. 어차피 사본 브랜치에서 main으로 최종적으로 머지해주는거니까요. 그리고 또 작업할때는 그 머지된 main에서 새롭게 브랜치를 만드는 방식이고요.

@anen2909 2 жыл бұрын

@@d3v3r_ @데버 예전에 작업물중 클래스가 많이있는 프로젝트를 작업한적이 있었는데, 클래스끼리도 관계가 많이있고 메인에서 싱글톤을 사용하는 클래스도 많이있는 프로젝트여서 예를들어 a라는 사람이 서로 관계되어있는 클래스인줄 모르고 해당 클래스를 수정했다가 이후에 b라는 사람이 a가 수정한지 모르고 업데이트 안하고 커밋을 진행하여 해당 클래스가 컨플릭트 에러나는 경우를 여럿봐서.... 업데이트는 무조건적으로 필요하다고 생각했었어요. 제가 툴을 잘못쓰는것도 있을것 같긴한데 아직 저에게는 어렵네요 ㅠㅠ

@lavivida9328 Жыл бұрын

@@anen2909동일한 메소드를 여러명이 수정하는 상황 자체가 문제인듯요

@존버장인-m1g 2 жыл бұрын

영상 개웃기네 ㅋㅋㅋㅋㅋㅋ

@cardician_kwon 2 жыл бұрын

4:40 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

@OrionAlpha 2 жыл бұрын

release 버전에서 main에 merge하고 develop 브런치에도 merge 하는 이유가 있나요? 긴급패치때 처럼 main에서 다시 브런치를 파는것과 다른가요?

@ktm2718 2 жыл бұрын

깊은 이해의 필요 없이도, 흐름을 맞추는 거라고 볼 수 있습니다. 특정 버전에서 이미 공개된 출시 버전을 내놓았는데 개발에서 특별한 이유가 없는데도 이전 버전으로 유지할 필요가 있겠냐는 의문이 답이 될 거라 생각합니다.

@hanbyullee 2 жыл бұрын

release 브랜치에서 버그 픽스 등을 위해 커밋이 더 쌓이면 그걸 develop 브랜치에도 merge 를 해줘야 그 이후로 develop 브랜치에서 생겨날 새 브랜치들에서도 release 에서 쌓은 버그 픽스 커밋이 반영이 된 채로 시작할 수 있으니까요. 또, 현재 release 브랜치가 아직 진행중일때, 그 다음 release 를 위해 작업하던 feature 브랜치가 develop 에 먼저 merge 된 경우, 현재 release 브랜치에서 develop 브랜치를 merge 할 때 생길 수 있는 conflict 를 resolve 할 수 있는 가장 적당한 시점이기 때문이기도 합니다.