[완료] github에서 코드 contribute 할때 말인데요.
글쓴이: nomail / 작성시간: 일, 2014/03/16 - 8:13오후
git과 github을 배우고 있는 초보입니다.
하나 궁금한게 있어서 잘 아시는 분들께 여쭤볼려는데요.
github에서 어떤 프로젝트를 fork하여 수정한 코드를 contribute를 할려고 합니다.
최종 작업 후 원저작자에게 pull request 할때,
제쪽 저장소의 master 브랜치를 보내줘야 하는지(master에는 원저작자의 master/develop 브랜치에 제가 작업한 결과물을 rebase 함)
아니면 다른 topic브랜치를 만들어 거기서 작업 후 topic 브랜치를 알려줘야 하는지요?
보통은 어떤 방식으로 진행되는지 궁금합니다.
Forums:
포크가 순전히 그 풀리퀘스트를 위한 거라면 마스터로
포크가 순전히 그 풀리퀘스트를 위한 거라면 마스터로 해도 문제는 없는데, 이 마스터가 계속 작업해야하는 거라면 따로 브랜치를 만드는게 좋습니다. 한번 풀리퀘스트를 하면 그 풀리퀘스트가 닫힐때까지 해당 브랜치에 커밋되는 내용들까지 자동으로 갱신되어 풀리퀘스트에 포함되기 때문입니다.
답변 주셔서 고맙습니다. 관심있는 프로젝트가 있어서
답변 주셔서 고맙습니다.
관심있는 프로젝트가 있어서 git이랑 github을 배우고 있는데요.
pull request 받는 쪽에서는 아무래도 merge 히스토리가 있는 것보단 최종 rebase 된 브랜치를 받는것이 좋겠단 생각이 들었습니다.
여유가 되면 계속해서 contribute를 할 예정인데 그럼 프로젝트 fork 하고나서 제 쪽의 master브랜치는 원본 저장소와 merge하는 용도로 두고
제가 작업하는 develop브랜치, 그리고 작 작업들 히스토리를 남길 topic브랜치들.. topic브랜치는 코드 수정이 완료 될때마다 develop브랜치에 merge 하고
그리고 최종적으로 pull request 보낼 때는 topic브랜치로 rebase한 master브랜치를 보내줄려고 합니다.
제가 답변을 잘 이해한게 맞는지요?
보통은 마스터가 주작업 공간이 되고(말그대로
보통은 마스터가 주작업 공간이 되고(말그대로 마스터), 풀리퀘스트를 날릴 필요가 있을 때마다 정리해서 브랜치를 만들어서 날립니다.
그리고 작업 내용은 자동으로 기록되어 남으므로 단순히 작업 히스토리를 위해서 브랜치를 나눌 필요는 없습니다.
무엇보다 그냥 한번 해보시면 바로 감이 올겁니다. 풀리퀘스트 잘못 날린다고 성질내는 개발자는 (별로) 없습니다.
실수로 잘못 날렸으면 그냥 닫고 다시 날리면 됩니다.
그리고 최종적으로 등록하기 전에 어떤 내용의 풀리퀘스트가 날아가는지 커밋 로그와 파일 변경 사항까지 깃헙에서 전부 확인 가능하니까 전부 완벽하게 계획하고 하시려하지 말고 일단 이것저것 눌러보면서 해보시는게 좋습니다.
네 말씀 고맙습니다. pro git 책 내용중에
네 말씀 고맙습니다.
pro git 책 내용중에 오픈소스 프로젝트에서는 원 저작자의 커밋 룰을 지켜야 욕을 안 먹는다는 얘기가 있었는데.. 우선 말씀대로 한번 도전해봐야 겠습니다.
친절한게 많이 알려주셔서 정말 고맙습니다^^
댓글 달기