XE 코어의 깃허브 저장소에 가서 브랜치 목록을 확인해 보세요.

보통 안정화 버전(master), 현재 개발중인 버전(develop), 그리고 그 밖에 PHP7 지원, 지금은 잠정 중단된 라우터 기능, UI 테스트 기능 등 큼지막한 변화의 가능성이 있는 부분마다 별도의 브랜치로 만들어 관리합니다. 급한 버그수정이 필요할 때도 임시 브랜치를 만들었다가 master로 합치곤 하죠.

그냥 커밋한 것을 원래 상태로 돌려놓고 싶으면 일일이 revert해야 하지만, 별도의 브랜치를 만들어서 작업했다면 그냥 다른 브랜치로 이동하기만 하면 됩니다. 중단했던 작업을 계속 하고 싶으면 그 브랜치로 다시 이동하면 되고요. 브랜치 수가 아무리 많아도 성능이나 관리상의 문제가 발생하지 않으므로 아무때나 브랜치를 만들었다 지웠다 해도 된다는 것이 git의 가장 큰 장점 중 하나입니다.

제가 fork한 xe-core는 새로운 기능이나 버그수정 하나를 제안할 때마다 새 브랜치를 만들었더니 벌써 브랜치가 수십 개나 되네요 ㅋㅋ

리쿠

2015.10.29 22:55:00
#comment_50082

Case-by-case이지만, 중요한건 커밋한걸 원래 상태로 돌려놓고 싶을 때 revert 해야 하는 부분에서 브랜치가 많으면 관리하는데 편한게 핵심이군요. ㅎㅎ

좋은 답변 감사합니다. 코어에서 브랜치 목록 보고 저도 저만의 방법을 찾아봐야겠네요 :)

루딩

2015.10.30 01:18:24
#comment_50244

만약에 따로 수정한 부분이 많아서

코어 기본 줄이 500줄이라 할 때 수정을 많이해서 800줄 이 넘어갈 때

git을 이용해서도 정상적으로 잘 패치해주나요..?

? ?

리쿠

2015.10.30 01:22:40
#comment_50248

오늘 잘못 삭제한 코드 300여줄가량 복원했는데, 별 문제 없었습니다 :)

기진곰

2015.10.30 09:10:02
#comment_50519

변경된 줄 수는 중요하지 않습니다. 한 쪽에서만 변경했다면 10만 줄, 100만 줄이 바뀌어도 상관없지만,
님이 수정한 부분 중 한 줄이라도 코어에서 또 수정되었다면

어느 쪽을 따를지 알려달라는 merge conflict (충돌) 메시지가 뜨죠.

수정내역이 많고 복잡해질수록 이런 충돌의 가능성이 높아지는 건 사실입니다.
이럴 때는 별도의 브랜치에서 충돌부분을 해결한 후 원래 브랜치로 다시 merge하는 등
약간의 우회책을 사용하는 것이 안전합니다.