실무에서는 대부분 test 브랜치나 qa 브랜치같은 거를 만들어서 해당 브랜치에 push 했을 때 테스트 서버, qa 서버에 배포해서 테스트 할 수 있도록 합니다. 저희 실무에서는 develop은 그저 master에 배포하기전 안전한 저장소로 사용만하네요. 이것도 각자 회사에서 정책 플로우가 다르니 입사하면 문조건 깃 플로우가 어떻게 되먹었는지 확인 꼭 하셔야됩니다~
깃플로우 전략은 CICD가 갖추어져 있을때 더 효과적입니다 영상 내용과 동일하되 master와 develop은 무조건 중간에 release 브랜치를 거치는 형식의 깃플로우 전략을 사용중입니다. 깃플로우 전략은 CICD 환경이 갖추어져있을때 더욱 강력합니다. 크게 dev, stg, prd 환경을 각각 develop, release, master 브랜치와 접목시켜서 3단 테스트 구조를 갖출 수 있습니다. 단순 온프램 환경 뿐만 아니라 클라우드환경, 쿠버 환경에서 모두 통용되어서 되려 더욱 효과적입니다
Git flow main : tag(이미 배포 된 플젝) develop : 배포 직전 완성된 플젝 브랜치 feature : 신기능 release: 배포 직전 플젝 임시 브랜치 hotfix: 버그 수정 급한 건 브랜치 Trunk based main 브랜치만 만들고 곁가지를 하나씩 생성 -> 소스 코드 여러개 관리할 필요 없음 테스트 빈번해야 함 소스가 안정화 되어 있는 경우
release 브랜치에서 버그 픽스 등을 위해 커밋이 더 쌓이면 그걸 develop 브랜치에도 merge 를 해줘야 그 이후로 develop 브랜치에서 생겨날 새 브랜치들에서도 release 에서 쌓은 버그 픽스 커밋이 반영이 된 채로 시작할 수 있으니까요. 또, 현재 release 브랜치가 아직 진행중일때, 그 다음 release 를 위해 작업하던 feature 브랜치가 develop 에 먼저 merge 된 경우, 현재 release 브랜치에서 develop 브랜치를 merge 할 때 생길 수 있는 conflict 를 resolve 할 수 있는 가장 적당한 시점이기 때문이기도 합니다.
@@d3v3r_ @데버 예전에 작업물중 클래스가 많이있는 프로젝트를 작업한적이 있었는데, 클래스끼리도 관계가 많이있고 메인에서 싱글톤을 사용하는 클래스도 많이있는 프로젝트여서 예를들어 a라는 사람이 서로 관계되어있는 클래스인줄 모르고 해당 클래스를 수정했다가 이후에 b라는 사람이 a가 수정한지 모르고 업데이트 안하고 커밋을 진행하여 해당 클래스가 컨플릭트 에러나는 경우를 여럿봐서.... 업데이트는 무조건적으로 필요하다고 생각했었어요. 제가 툴을 잘못쓰는것도 있을것 같긴한데 아직 저에게는 어렵네요 ㅠㅠ
프로토타입부터 서비스 종료까지 마스터 하나로 써먹은 우리회사는 상남자 그자체
ㅋㅋㅋ
고인물만 있는거 아님?ㅋㅋ
@@user-hd5yg5dx5yㄹㅇㅋㅋ
ㄹㅇ 강심장들만 모여있구만...
믿을건 revert 하나뿐이네 ㅋㅋ
생활코딩님이 정석코스 밟아온 엘리트 개발자로서 강의하시는 느낌이라면 코딩애플님은 그냥 동네 공사장 막노동판에서 구르던 사람이 흥미로 시작해 독학하여 신의 경지에 이른 뒤 어둠의 버전으로 알려주시는 느낌이 들어서 좋아요. 이래서 여성분들이 나쁜남자에게 끌리나봐요.
ㅋㅋㅋ 근데 신기한건 생활코딩님도 비전공자 흙바닥? 출신이시라는거
어둠 좋아
생코는 찐 개발자는 아니십니다 ㅎㅎ 개발 강의를 초등학생이 봐도 이해하기 쉽게 전달하는 능력이 탁월하신 분..
비유 찰떡...
나쁘다기 보다는 재미 등 매력이 더 있어서 그런 게 아닐까요
오늘도 영혼없고 알찬 강의 감사합니다
예전부터 봤지만 진짜 짧게 쏙쏙 잘들어옴 ㅋㅋㅋ
자칫 지루할 수 있는 강의에 슨생님만의 유쾌한 유우머가 참 좃습니다.😉😉
항상 잘보고 있습니다.
야가다 스타일 강의 너무 좋읍니다 ㅎㅎ
깃 머지 컨플릭션 관련 강의가 절실합니다!!
실무에서는 대부분 test 브랜치나 qa 브랜치같은 거를 만들어서 해당 브랜치에 push 했을 때 테스트 서버, qa 서버에 배포해서 테스트 할 수 있도록 합니다.
저희 실무에서는 develop은 그저 master에 배포하기전 안전한 저장소로 사용만하네요.
이것도 각자 회사에서 정책 플로우가 다르니 입사하면 문조건 깃 플로우가 어떻게 되먹었는지 확인 꼭 하셔야됩니다~
공부가 되었습니다. 개념 정리 언제나 감사합니다.
설명 넘 깔끔하고 좋네요!!
회사에서 하고 있던 방식이 Trunk-based인지 몰랐었는데 확실히 알았네요!
진짜 개꿀잼이다 ㅋㅋㅋ 이렇게 유익하면서 재밌는 강의 처음인듯
이번 강의만큼은 생활코딩님보다 더 이해하기 쉬웠다 ㅋㅋㅋㅋ
좋좋소 우물에서 혼자 코딩하는사람이라서 협업해본적 없어서 이직에 대한 두려움이 있었는데 큰 도움 되었습니다. 저는 브랜치따위는 필요 없겠네요.
설명 깰끔! 잘들었습니다~
보기편한 정리 감사합니다
깃허브 시리즈 더 “해줘”
응애
형 넘 좋앙~ 꿀강의 떙큐
미국 현직 개발자인데 이거 ㄹㅇ 꿀팁.
강의가 너무 웃겨서 머리에 쏙쏙 박히네요 ㅋㅋㅋㅋㅋ
깃플로우 전략은 CICD가 갖추어져 있을때 더 효과적입니다
영상 내용과 동일하되 master와 develop은 무조건 중간에 release 브랜치를 거치는 형식의 깃플로우 전략을 사용중입니다.
깃플로우 전략은 CICD 환경이 갖추어져있을때 더욱 강력합니다. 크게 dev, stg, prd 환경을 각각 develop, release, master 브랜치와 접목시켜서 3단 테스트 구조를 갖출 수 있습니다.
단순 온프램 환경 뿐만 아니라 클라우드환경, 쿠버 환경에서 모두 통용되어서 되려 더욱 효과적입니다
주영이 똑똑하네 아주 칭찬해 정말 세상에서 제일 멋진 개발자야.
혹시 develop, release, master 브렌치마다 다른 서버에 올려서 테스트 할 수 있다는 말씀이 맞을까요?
아마 여기서 말씀하신 CICD환경에서 싫어한다는것은 이러한 환경분리가 안되어있고, main branch에서만 CICD를 수행하는 단순한 환경만을 말씀하시는 것 같아요.
주요 브랜치마다 CI/CD 환경설정해야하니 안좋아한다는 뜻 같아요😅
CICD가 뭔가요..?
넘모 재밌네요☺️❤
궁금한 게 있습니당
새로운 기능이 필요할 때 브랜치를 새로 파서 사용한다면, 해당 기능을 개발하는 팀에서는 어떻게 저것을 협업하는건가요?
그냥 단순하게 새로 git을 하나 파서 거기서 branch 나누고 협업한 뒤에 완성물을 가져오는걸까요?
보통 브랜치는 기능별로 나누게 됩니다. feature_기능명, feature/기능명 으로 만든 뒤, 그 브랜치에 대고 merge를 하면서 서로서로 협업 하는거죠. 하나의 git repository는 프로그램 하나를 의미합니다.
큰 도움이 됩니다!
사랑합니다.
돈 무한 복사에서 라면 먹다 뿜었네요
유용하네요 잘 보고 갑니다
감사합니다
쌤 사랑해요.
2:40 ‘상남자’ 이 부분 ㅈㄴ 웃기네 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
ㅋㅋㅋㅋ말씀하시는게 너무 웃긴데 내용은 핵심만 콕콕이네요
설명잘한다잉
Git flow
main : tag(이미 배포 된 플젝)
develop : 배포 직전 완성된 플젝 브랜치
feature : 신기능
release: 배포 직전 플젝 임시 브랜치
hotfix: 버그 수정 급한 건 브랜치
Trunk based
main 브랜치만 만들고 곁가지를 하나씩 생성
-> 소스 코드 여러개 관리할 필요 없음
테스트 빈번해야 함
소스가 안정화 되어 있는 경우
상남자는 뭐든지 메인브랜치에 통합한다.
감사하빈다.
00:10 갑자기 내 생각이 화면에 써져서 놀랐네
0:10 처음 보면서 든 생각) 난가?
우리 아이가 좋아해요
전 지금 2번째 전략을 쓰고있습니다 ㅋㅋ 프로젝트 팀원이 저 포함 5명밖에 안되기때문에
잘 봤습니다. 어떤 책을 보면 좋을 지 추천해 주세요.
저희는 핫픽스 브랜치를 릴리즈브랜치에서 따고 완전히 핫픽스까지 다 완료되고난 후에 메인 브랜치로 머지해요
말 나온김에 CI CD도 한번
팀장이거나 노예거나 ㅋㅋㅋㅋㅋ 왤케 극단적이에여 ㅠ
2:49 애플 쌤 요즘것들은 상남자 반대말로 하남자 라는 말을 쓰는듯 합니다 (오늘도 젊음 1스택)
막노동공장일하는데 이거 잼나보인다
리마인더 감사 :)
릴리즈는 안써봤는데 써보겠슴다
0:12라면 면발 튀기기전
상남자 겁쟁이 ㅋㅋㅋ
실수로 팀장님께 보내고싶은영상
release 버전에서 main에 merge하고 develop 브런치에도 merge 하는 이유가 있나요? 긴급패치때 처럼 main에서 다시 브런치를 파는것과 다른가요?
깊은 이해의 필요 없이도, 흐름을 맞추는 거라고 볼 수 있습니다. 특정 버전에서 이미 공개된 출시 버전을 내놓았는데 개발에서 특별한 이유가 없는데도 이전 버전으로 유지할 필요가 있겠냐는 의문이 답이 될 거라 생각합니다.
release 브랜치에서 버그 픽스 등을 위해 커밋이 더 쌓이면 그걸 develop 브랜치에도 merge 를 해줘야 그 이후로 develop 브랜치에서 생겨날 새 브랜치들에서도 release 에서 쌓은 버그 픽스 커밋이 반영이 된 채로 시작할 수 있으니까요.
또, 현재 release 브랜치가 아직 진행중일때, 그 다음 release 를 위해 작업하던 feature 브랜치가 develop 에 먼저 merge 된 경우, 현재 release 브랜치에서 develop 브랜치를 merge 할 때 생길 수 있는 conflict 를 resolve 할 수 있는 가장 적당한 시점이기 때문이기도 합니다.
4:40 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
사실 팀장도 노예잖아 ㅋㅋㅋ
형님들 유니티도 깃허브 이용하는게 일반적인가요?
코딩애플 선생님은 어떤 방식 쓰세요
개웃기네 진짜 ㅋㅋㅋㅋ
브랜치를 미리 만들어 놔야 하는거죠?
코딩애플 만세~!
그러니까 수퍼 겁쟁이 클럽 사람들이 하는 전략이다 이거죠?
영상 개웃기네 ㅋㅋㅋㅋㅋㅋ
(겁쟁이)
4:42 R U SERIOUS?
보안문제는 없나요?
유저들은 데이터 쪼가리 주면 좋아 한데 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ데이터 쪼가맄ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
아 나도이제 팀장이다.
누구한테 배워서 이따위야? 이러면 코딩애플님이요 하면됩니다.
깃플로우 방식은 굉장히 많은 브랜치가 계속 생성이 되서 주기적으로 삭제가 되거나, 자동삭제를 시켜줘야되고, 단계가 많아서 손이 더 많이가긴 합니다.
테스트를 할수있는 여건이 된다면, 트렁크 방식이 훨씬 빠른 배포가 가능해서 서비스의 생산 속도가 높아집니다.
두 방식 모두 메인 브랜치를 사본에 수시로 업데이트 해야하는건 동일한거죠?
그렇게하지 않으면 컨플릭트 에러가 많이 발생할것 같은데 제가 잘못알고있는 걸까요?
main을 직접 건들지 않는 이상 충돌 날 일은 웬만해선 없겠죠. 어차피 사본 브랜치에서 main으로 최종적으로 머지해주는거니까요. 그리고 또 작업할때는 그 머지된 main에서 새롭게 브랜치를 만드는 방식이고요.
@@d3v3r_ @데버 예전에 작업물중 클래스가 많이있는 프로젝트를 작업한적이 있었는데, 클래스끼리도 관계가 많이있고 메인에서 싱글톤을 사용하는 클래스도 많이있는 프로젝트여서 예를들어 a라는 사람이 서로 관계되어있는 클래스인줄 모르고 해당 클래스를 수정했다가 이후에 b라는 사람이 a가 수정한지 모르고 업데이트 안하고 커밋을 진행하여 해당 클래스가 컨플릭트 에러나는 경우를 여럿봐서.... 업데이트는 무조건적으로 필요하다고 생각했었어요. 제가 툴을 잘못쓰는것도 있을것 같긴한데 아직 저에게는 어렵네요 ㅠㅠ
@@anen2909동일한 메소드를 여러명이 수정하는 상황 자체가 문제인듯요
'이제' 없이 말 못하는건 모든 개발자 공통인가바여 ㅋㅋㅋㅋㅋㅋ
java 프로잭트 maven string boot gradlea 여러가지 많은데 코딩애플님의 강이가 듣고싶습니다.
gradle 로 가세요 하나만 하시면 됩니다.
@@superspeedmotor ok
설명 ㅈ 나 잘 하셩
던공앤파이터 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
상남자 ㅋㅋㅋㅋㅋㅋ
상남자는 걍 부모브랜치에 바로적용ㅋㅋ
데이터 쪼가리…허…참…
ㅋㅋㅋㅋ 골드, 경험치 = 데이터쪼가리
뭐이딴걸 방법까지 만들어서 공유해야하나 ?
모바일 던파 하세요? ㅋㅋㅋ
항마 몇?
코딩노예 ㅋㅋㅋ 영상끄시면 되고요
강의끄래 ㅋㅋㅋ
웃겨서 집중이 안돼요
한국에서 무슨 대단한거 개발할꺼 있다고 ㅋㅋ개웃기네
감사합니다