Git 심층 분석: 주요 질문과 해답 컬렉션

Q&A 큐레이션

1. Javascript의 비동기방식 과 git

안녕하세요 대학교에서 개발공부중인 학생입니다. 프론트엔드 개발자가되는게 꿈입니다 개발공부를 하다가 비동기 방식과 git대해 궁금증이 생겨서 질문드립니다 1. 동기식 방식과 비동기식방식의 차이점 2. 비동기식 방식을 쓰는 이유 3. Git을 쓰는 이유와 장점과 단점등 입니다


답변

직접 찾아보시는게 좋을듯합니다 찾으면서 공부도 많이 되니까요 1. 동기 비동기 차이는 동기는 요청의 결과가 동시에 일어나는 것이고 비동기는 그 반대입니다. 2. 동기는 설계가 단순하지만 결과가 도착할때 까지 아무런 일을 못한다는 단점이 있고 비동기는 설계는 복잡하지만 자원을 효율적으로 다룰수있단 장점이 있습니다. 3. 깃은 버전관리와 협업을 위해 사용합니다

외 1개 답변 보러 가기

2. git 개행문자 에러 해결법

안녕하세요. 리액트로 간단한 웹을 만들고 있습니다. git에다가 업로드를 하려고 git add . 를 했는데 개행문자 에러가 떠서 인터넷에서 검색해보니 git config --global core.autocrlf true 를 하면 된다고 해서 했는데, 변화가 없고 똑같이 개행문자 에러가 계속 뜹니다. 그래서 git에 업로드를 못하고 있는 상황입니다. 추후에 포트폴리오용으로 사용하고자 개발중인 웹인데 제출이 불가능하게 되어 매우 곤란한 상황입니다ㅠㅠ 어떻게 하면 해결할 수 있을까요?


답변

안녕하세요! git add --renormalize . 위 커맨드를 한번 실행시켜주셔야 되는 것으로 알고 있습니다! 참고해보세요 (https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings#refreshing-a-repository-after-changing-line-endings)

이 질문 바로 가기

3. 레포지토리에 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' 푸시니까 조심하셔야 합니다..!

이 질문 바로 가기

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

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


답변

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

이 질문 바로 가기

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

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


답변

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

외 1개 답변 보러 가기

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

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


답변

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

외 1개 답변 보러 가기

7. Git 으로 데이터베이스 (SQLite) 를 관리해도 되나요 ?

현재 node.js 로 파일을 처리하는 스크립트 프로그램을 만들고 있습니다. 일부 문자 패턴을 찾아서 예외 처리 하는 로직을 추가하려고 하는데 패턴을 저장하는 방법에 대해서 고민중입니다. SQLite 로 저장해서 데이터 소스를 git 으로 커밋하는 방법을 사용해도 괜찮을까요 ? 이렇게 사용해서 발생하는 문제는 없는지, 다른 좋은 방법은 없는지 궁금합니다.


답변

패턴의 내용을 깃에 저장하는 것 자체에는 문제가 없을 것 같습니다. 하지만 질문자님 말씀을 들어보았을 때 패턴만 저장하시는 것으로 이해했는데 SQLite까지 써야 하는지가 궁금하네요! 단순히 파일로 저장해 사용할 때와 SQLite를 사용할 때를 비교한다면 질문자님께서 생각하시는 SQLite 사용의 장점이 어떤게 있을까요?

외 2개 답변 보러 가기

8. 협업할 때 git 사용 방법

협업하는 과정에서 헷깔리는 부분이 있어서 글 남깁니다. 제가 feature/a라는 branch 작업을 하고 있는데 팀원의 feature/b branch가 develop에 merge 되어서 develop에 반영된 팀원 코드를 제 feature/a branch에 적용하고 싶을 때 feature/a branch에 checkout 해서 git merge develop을 해야 하나요? 그 다음 작업이 끝나고 난 뒤에는 develop에 checkout 하고 git merge feature/a를 하면 되나요? 그리고 혹시 직장에서 협업하는 방식이 어떻게 되는지 이야기를 나누고 싶어요~!!


답변

안녕하세요! 팀원이 develop에 올린 코드를 feature/a에 반영하고 싶다. -> feature/a에서 develop을 merge하시면 됩니다! feature/a 작업을 develop으로 반영하고 싶다. -> 질문자님이 말씀하신 develop에서 feature/a를 merge하는 것도 방법이지만 보통은 pull request를 올립니다! 사용하고 계시는 git 레포 서비스에서 PR 생성을 할 수 있어요. 현업에서는 여러가지 Git 전략이 존재하고 팀 상황에 맞게 코드를 관리합니다. 다만 질문자님의 develop 브랜치처럼 공통으로 코드 수정사항을 올리는 브랜치로 작업 브랜치 (feature/a)를 올릴때는 PR을 생성해서 코드 리뷰 받고 이상없으면 merge하는 방식을 취하고 있어요! git 전략에 대해서 검색해보시면 도움이 될 것 같습니다. 참고해보세요 :) - https://hudi.blog/git-branch-strategy/ - https://blog.hwahae.co.kr/all/tech/9507 - https://inpa.tistory.com/entry/GIT-%E2%9A%A1%EF%B8%8F-%EA%B9%83%ED%97%99-PRPull-Request-%EB%B3%B4%EB%82%B4%EB%8A%94-%EB%B0%A9%EB%B2%95-folk-issue

이 질문 바로 가기

지금 가입하면 모든 질문의 답변을 볼 수 있어요!

현직자들의 명쾌한 답변을 얻을 수 있어요.

또는

이미 회원이신가요?

키워드로 질문 모아보기

실무, 커리어 고민이 있다면

새로운 질문 올리기

지금 가입하면 모든 질문의 답변을 볼 수 있어요!