github

Google, Meta, Amazon 등은 각자 자체적인 도구를 쓰기도 하지만, 기본 철학은 "Git Flow" 또는 "Trunk-Based Development"와 유사하며 GitHub의 Pull Request(PR) 시스템을 핵심으로 사용합니다.핵심 프로세스는 다음

팀 프로젝트에서는 main 브랜치를 신성한 곳으로 취급하여 절대 바로 수정하지 않습니다.핵심 흐름:1\. 작업 공간(Branch) 따로 만들기2\. 작업 후 내 공간만 GitHub에 올리기3\. "내 거 합쳐줘"라고 요청서(PR) 보내기4\. 승인되면 합치기(Merge

git push origin [브랜치이름] 명령어는 "어디로(origin), 무엇을(branch) 보낼지" 명확하게 지정 GitHub에는 아직 브랜치가 없다. 본인의 컴퓨터에서 feat/dataloader 라는 브랜치를 새로 만듦 하지만 GitHub(원격)에는 아직

GitHub에는 아직 없고, 오직 내 컴퓨터(서버)에서만 존재하는 방을 먼저 만들어야 함.👉 이 시점에서는 나만 feat/dataloader라는 브랜치를 가지고 있고, GitHub는 이 존재를 전혀 모릅니다.이제 내가 만든 방을 GitHub에도 똑같이 만들어달라고 요

커밋을 잘못했을 때 확인하고, 취소(삭제)하는 방법내가 뭘 잘못했는지, 돌아갈 지점이 어디인지 확인.\--oneline: 복잡한 정보 빼고 "커밋ID + 메시지"만 한 줄로 깔끔하게 보여줍니다.출력 예시맨 위에 있는 게 가장 최신 커밋.상황에 따라 두 가지 방법 중 하

main: 프로젝트의 기본 줄기.feat/new_feature: main에서 새로운 기능을 만들기 위해 딴 브랜치.feat/new_feature_subtask_1: feat/new_feature 브랜치에서 작업하던 중, 더 작은 단위의 작업(subtask_1)을 위해