Github 실전가이드: 자주 묻는 Github 질문과 답변

1. 소규모 프로젝트 관리할 때 gitlab vs github actions??

안녕하세요, 이번에 소규모 프로젝트를 맡아 진행하게 되었습니다. 프로젝트에서 CI/CD를 처음 해달라고 해서 gitlab과 github actions 중에 어떤 게 더 좋을지 고민이 됩니다. 선배님들의 고견 부탁드립니다.

답변

깃헙액션 추천합니다. 깃랩과 대응 스택이이야 유사하지만 ms가 인수하면서 팀관리 지원및 프라이빗저장소지원,패키지(모듈관리),action 등 소규모로 시작시 모두 무료입니다. 중간규모여도 무료로 어느정도 커버가 가능합니다. 빌드를 위한 다양한 os또한 무료선택이입니다 -빌드타임 제약있긴하지만 넉넉함 코드를 어느정도 구성하고 나면 AI가코드 분석해서 초기 자동빌드 스크립트도 어느정도 구성해주며 자동빌드까지 액션에 통합되어 손이 덜갑니다. 보안이 중요한 인하우스 프로젝트인 경우 설치형 깃랩이 선호되기도합니다. (클라우드가 보안이 취약하다란 의미는 아니며~ 특정기관의 경우해당됩니다.)

2. git, github 브랜치 히스토리 관련 질문 있습니다.

안녕하세요 git, gitHub 사용관련해서 질문이있습니다. 사용 github repository에서 기능완성한 branch 를 지워주고, 로컬에서도 branch를 지 운후, 나중에 repository에 같은 이름으로 브랜치를 만들면 새로운 branch로 생성될까요 아니면 기존에 썼던 이력을 가진 branch로 생성되나요?

답변

원격 저장소와 로컬 저장소 모두에서 브랜치를 삭제하시면 해당 브랜치에 대한 이력은 어디에도 남지 않게 됩니다. (다른 개발자가 의도적으로 삭제된 브랜치를 본인의 로컬 저장소에서 원격 저장소로 다시 올리지 않는 한) 따라서 동일한 이름으로 다시 브랜치를 만드시면 현재 HEAD가 가리키고 있는 커밋을 기준으로 완전히 새로운 브랜치가 생성됩니다.

3. 다른사람이 github 프로젝트를 다운받아서 사용할때 자동으로 Contributors에 추가할 수 있는 방법이 있나요?

그리고 Contributors에 추가되는것 이외에도 누가 다운받으면 표시되는 기능도 있는지 궁금해요~

답변

안녕하세요! git clone할때 자동으로 contributors에 추가할 수 있는 방법은 따로 없는 것 같아요. 여기 참고해보세요! - https://docs.github.com/ko/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/inviting-collaborators-to-a-personal-repository#inviting-a-collaborator-to-a-personal-repository 클론 수 표시는 깃허브 레포지토리 > Insights > Traffic 탭 보시면 나오긴합니다 :)

4. 레포지토리에 draw.io 파일 추가 후에 git push 가 안되는 경우..!

수업용 레포지토리인데 프로세스 구조도를 draw.io에서 그린 후 이 레포지토리에 저장을 했는데 그 뒤로 git push가 되질 않습니다 ㅠㅠ! ! [rejected] main -> main (fetch first) error: failed to push some refs to 'https://github.com/레포지토리주소.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. 이런 오류가 계속 깃배쉬에 뜨는데 어떻게 해결해야 할지 모르겠어요... 혹시나 해서 저 draw.io 파일을 지우고 시도해보았지만 결과는 같더라구요..! 레포지토리를 삭제하고 다시 만들어서 올리는 수밖엔 없을까요 ㅠㅠ?!

답변

음 느낌상 로컬에 있는 것과 remote에 있는게 서로 맞지 않는게 있나보네요! 레포지토리 만드실 때 readme 생성을 하고 만들었는데 로컬에서 clone이 아닌 git init 부터 해서 remote 설정하고 초기세팅부터 다 한 다음 push를 한다면 저 상황을 마주하실 수 있으십니다. 질문에 대한 답변으로 stackoverflow 링크를 하나 가져왔는데요. 포시 푸시에 대한 이야기도 했고 remote origin 설정이나 커밋했는지 체크해보란 이야기도 있고 remote랑 local 사이 머지해서 해결하는 방법도 있네요! 여러 답변 참고하시면서 본인의 상황에 맞는 것 적용해 해결하면서 공부하시면 좋을거 같아요! https://stackoverflow.com/questions/20939648/issue-pushing-new-code-in-github 근데 한 가지 주의할 점! 링크의 답변들에선 git push -f origin master 즉, 포스 푸시를 답변으로 두고 있는데 그러면.. 이제 remote에 있는걸 강제로 덮어쓸 것이다! 라고 보면 됩니다. 혹시 remote에 있는 레포지토리 내용이 중요하다던지 한다면 신중하게 시도해보세요..ㅎㅎ + 그리고 마지막으로 노파심에 남기는 말인데 현업에서 만약 협업하시면서 프로젝트 운영/개발 하실텐데 포스 푸시 남발하시면 안되어요! ㅋㅋㅋㅋ 말 그대로 'force' 푸시니까 조심하셔야 합니다..!

5. github 이메일 변경할 수 있나요?

github 이메일을 추가하고 그걸 primary로 사용할 수 있는 방법이 있을까요 ?

답변

네 변경 가능합니다. 깃허브 공식페이지 가이드를 참고하셔서 설정 하시면 됩니다. https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/changing-your-primary-email-address

6. Git 레포지토리 관리는 보통 어떻게 하시나요?

새로운 회사로 이직 한지 얼마 안된 3년차 주니어 웹 개발자입니다. 현재 회사가 IT 업체가 아니라 모든 개발과 운영을 개발 업체에 맡긴 상태입니다. 회사에서는 인하우스 개발자의 필요성을 느껴 구인을 했고, 제가 들어왔는데 모든 프로젝트 소스를 인수인계 받음에 앞서 형상 관리에 대한 의견 충돌이 생겨 질문 드립니다. 현재는 운영 중인 여러개의 웹 프로젝트를 같은 레포지토리에 관리 하고 있습니다. 보통 기능 개발 같은게 들어오면 웹 별 비슷한 기능을 어차피 한꺼번에 반영해야해서 한번에 수정 후 1 commit을 하고 있다고 합니다. 충돌날 일도 거의 없다고 브랜치는.. 나누지 않는다고 합니다. 이것부터 이해가 안되긴 합니다. 저는 이전 회사에서 프로젝트 별 레포지토리를 생성하여 관리 했었습니다. 물론 기능 추가를 하더라도 유의미한 커밋은 여러번 했었고요. 그냥 그런 방식이 당연하다고 생각했습니다. 저는 이전 경험처럼 형상 관리를 나눠서 하고 싶은데 개발업체 개발자가 납득할만한 설명이 바로 떠오르지 않았습니다. 그래서 일단 보류해둔 상태입니다. 뭔가.. 이상한 것 같은데 어떤 근거를 들어가며 설득해야할지 모르겠습니다. 이미 그런 방식으로 계속 개발/운영 해오던 거라 그 쪽도 현재 관리 방법을 고수하고 싶은 것 같습니다. 위 내용에 대해 조언을 주신다면 감사하겠습니다. 혹시나 제 질문이 이해가 안 되신다고 해도 댓글 부탁드리겠습니다. ㅠㅠ 현재 회사에 입사한지도 얼마 안됐고 개발자가 저 한 명이라 도움 구할 사람이 없네요..

답변

레포지토리 관리는 회사별로 혹은 프로덕트별로 전략을 다르게 가져갈 수 있는 부분이라 반드시 어느 쪽이 더 낫다고 말하기는 어려울 것 같습니다. 다만 장기적으로 볼 때 프로젝트 규모는 일반적으로 계속 커질 것이고, 그럴 수록 모노레포 전략의 단점이 두드러질 수 있겠죠. 커밋은 저도 그렇고 주변 사람들도 보면 어느 정도 나눠서 올리는 게 일반적인 것 같습니다. 적당히 semantic한 기준으로 나눌 때도 있고요. 기능 하나를 개발하더라도 기본적인 컴포넌트를 만들고 로직을 구현하고, 디자인적인 부분을 리터칭하여 수정하는 등 여러 가지 단계가 있다보니, 커밋이 세분화되어 있는 것이 문제를 찾아 해결하기 훨씬 용이하다고 생각되더라고요. 모쪼록 협의점을 잘 찾으실 수 있으면 좋겠습니다.