Git 써야 된다는 이야기, 많이 들으셨죠? Claude한테 물어보니까 "commit 하세요", "push 하세요" 하고. 시키는 대로 따라 해봤어요.

git add .
git commit -m "작업 완료"
git push

여기까진 됐어요. 뭔진 모르겠지만 일단 저장되고 올라가는 것 같긴 해요.

근데 그 다음.

AI가 뭔가 수정을 하고 난 뒤에 어느 순간 잘 되던게 안되기 시작하고 이때 부터 뭔가 AI 가 말귀도 못알아 먹기 시작합니다.

코드를 되돌리기에는 어디서부터 돌려야하는지 모르겠고, 아 때려칠까 싶은 기분이 들때가 있습니다.

이런 상황 겪어보셨을 수 있습니다!

✅ "로그인 기능 추가해줘" → 성공

✅ "회원가입도 추가해줘" → 성공

❌ 근데 로그인이 안 됨

🔄 "되돌려줘" → 이거 아님

🔄 "다시 되돌려줘" → 이것도 아님

🔄 "아니 그게 아니라..." → ...

💀 포기

우리는 습관처럼 하나에 파일에 뭔가를 수정할때가 많습니다.

이걸 나중에는 의식적으로 분리하려고 하는데, 처음에는 그렇게 생각하기가 어렵습니다. 

그러다 보니, 뭔가 하나를 추가하면, 하나가 에러가 나고, 에러 하나를 고치고 나면, 또 확인하지 못했던 곳에서 문제가 터지고, 이 과정들이 반복이 되는 경우들이 많습니다. 

이때 브랜치라는 복사본을 만들면 작업을 편하게 할 수 있습니다!``` main (원본, 로그인 잘 됨) ───────────────── │ └── feature/회원가입 (복사본, 여기다 실험) ↑ 망하면 여기만 버림 원본은 무사

아까 그 상황이었으면요?

"회원가입 브랜치 버리고 main으로 돌아가줘" 

한 마디면 끝입니다!

로그인 잘 되던 상태로 바로 복구.

중요한 문서 수정해야 할 때, 다른 사람들이 다 같이 볼 수 있는 문서는 원본 바로 안 건드리고, 복사본 만들어서 수정했다가, 작업 완료하면, 원본에 붙여넣는 과정이랑 동일합니다!

원본(main 브랜치에서) 복사본 (development 브랜치)를 만들고, 다 수정하면 원본에 합치는 (merge)는 과정입니다!

그렇다면 브랜치 이름은 어떻게 정하는게 좋을까요?

어렵게 생각할 필요 없어요. 딱 3개만 기억하세요.

근데 왜 이렇게 나누냐고요?

혼자 작업할 때는 모를 수 있지만, 근데 누군가와 협업하는 순간, 이름이 중요해져요.

❌ 이름 대충 지으면
├── test
├── asdf
├── new-branch
└── branch2

팀원: "이거 뭐 하는 브랜치예요?" 나: "어... 뭐였지?" 😇

⭕ 규칙대로 지으면
├── feature/로그인
├── feature/회원가입
├── fix/버튼안눌림
└── main

팀원: (보자마자 이해) 나: (3개월 후에도 이해)

이름만 봐도 바로 알 수 있습니다.

• feature/ → "아, 뭔가 새로 만들고 있구나"
• fix/ → "아, 뭔가 고치고 있구나"
• main → "아, 이건 완성본이구나"

지금은 혼자 작업해도요. 미래의 나도 협업 대상입니다!. 우리는 일주일 뒤의 나는 지금 내가 뭘 했는지 기억 못해요.

브랜치 이름 잘 지어두면, 미래의 내가 고마워할거에요.

작업을 새롭게 시작할하거나, 이미 좀 복잡해졌다고 느껴졌을떄, AI에게 이렇게 이야기 하면 됩니다!

{기능이름} 기능 만들려고 해.
feature/{기능이름} 브랜치 만들어서 작업 해줘

작업 끝나면:

이 브랜치 main에 머지해줘.

망했으면:

이 브랜치 버리고 main으로 돌아가줘.

이것만 해도, "최종_진짜_마지막.py" 에서 해방되고, 여기서부터 아 git을 이래서 쓰는구나, 다른 기능들은 또 뭐가 있는지 궁금해지실 겁니다!

Git 써야 된다는 이야기, 많이 들으셨죠? Claude한테 물어보니까 "commit 하세요", "push 하세요" 하고. 시키는 대로 따라 해봤어요.

git add .
git commit -m "작업 완료"
git push

여기까진 됐어요. 뭔진 모르겠지만 일단 저장되고 올라가는 것 같긴 해요.

근데 그 다음.

AI가 뭔가 수정을 하고 난 뒤에 어느 순간 잘 되던게 안되기 시작하고 이때 부터 뭔가 AI 가 말귀도 못알아 먹기 시작합니다.

코드를 되돌리기에는 어디서부터 돌려야하는지 모르겠고, 아 때려칠까 싶은 기분이 들때가 있습니다.

이런 상황 겪어보셨을 수 있습니다!

✅ "로그인 기능 추가해줘" → 성공

✅ "회원가입도 추가해줘" → 성공

❌ 근데 로그인이 안 됨

🔄 "되돌려줘" → 이거 아님

🔄 "다시 되돌려줘" → 이것도 아님

🔄 "아니 그게 아니라..." → ...

💀 포기

우리는 습관처럼 하나에 파일에 뭔가를 수정할때가 많습니다.

이걸 나중에는 의식적으로 분리하려고 하는데, 처음에는 그렇게 생각하기가 어렵습니다. 

그러다 보니, 뭔가 하나를 추가하면, 하나가 에러가 나고, 에러 하나를 고치고 나면, 또 확인하지 못했던 곳에서 문제가 터지고, 이 과정들이 반복이 되는 경우들이 많습니다. 

이때 브랜치라는 복사본을 만들면 작업을 편하게 할 수 있습니다!``` main (원본, 로그인 잘 됨) ───────────────── │ └── feature/회원가입 (복사본, 여기다 실험) ↑ 망하면 여기만 버림 원본은 무사

아까 그 상황이었으면요?

"회원가입 브랜치 버리고 main으로 돌아가줘" 

한 마디면 끝입니다!

로그인 잘 되던 상태로 바로 복구.

중요한 문서 수정해야 할 때, 다른 사람들이 다 같이 볼 수 있는 문서는 원본 바로 안 건드리고, 복사본 만들어서 수정했다가, 작업 완료하면, 원본에 붙여넣는 과정이랑 동일합니다!

원본(main 브랜치에서) 복사본 (development 브랜치)를 만들고, 다 수정하면 원본에 합치는 (merge)는 과정입니다!

그렇다면 브랜치 이름은 어떻게 정하는게 좋을까요?

어렵게 생각할 필요 없어요. 딱 3개만 기억하세요.

근데 왜 이렇게 나누냐고요?

혼자 작업할 때는 모를 수 있지만, 근데 누군가와 협업하는 순간, 이름이 중요해져요.

❌ 이름 대충 지으면
├── test
├── asdf
├── new-branch
└── branch2

팀원: "이거 뭐 하는 브랜치예요?" 나: "어... 뭐였지?" 😇

⭕ 규칙대로 지으면
├── feature/로그인
├── feature/회원가입
├── fix/버튼안눌림
└── main

팀원: (보자마자 이해) 나: (3개월 후에도 이해)

이름만 봐도 바로 알 수 있습니다.

• feature/ → "아, 뭔가 새로 만들고 있구나"
• fix/ → "아, 뭔가 고치고 있구나"
• main → "아, 이건 완성본이구나"

지금은 혼자 작업해도요. 미래의 나도 협업 대상입니다!. 우리는 일주일 뒤의 나는 지금 내가 뭘 했는지 기억 못해요.

브랜치 이름 잘 지어두면, 미래의 내가 고마워할거에요.

작업을 새롭게 시작할하거나, 이미 좀 복잡해졌다고 느껴졌을떄, AI에게 이렇게 이야기 하면 됩니다!

{기능이름} 기능 만들려고 해.
feature/{기능이름} 브랜치 만들어서 작업 해줘

작업 끝나면:

이 브랜치 main에 머지해줘.

망했으면:

이 브랜치 버리고 main으로 돌아가줘.

이것만 해도, "최종_진짜_마지막.py" 에서 해방되고, 여기서부터 아 git을 이래서 쓰는구나, 다른 기능들은 또 뭐가 있는지 궁금해지실 겁니다!