[git] Rebase이후 push Reject?
이전 포스팅에 rebase를 통해서 깔끔한 커밋 히스토리를 만들 수 있다라는 것을 강조했고,이를 주로 사용하여 깨끗한 커밋 히스토리를 관리하고 있었다.1️⃣"Rebase"로컬에서 main 브랜치에서 feat 브랜치를 생성하여 각자 개발을 진행하다 보면, 브랜치마다 commit에 따라서 HEAD가 달라지게 된다.이때 main 브랜치에 새로운 커밋이 추가되면,
관련 게시물
[Git] Gitflow , Github flow ... 브런치 전략..?
근래 Git에 중점을 두고 학습하고 있는데,이게 단순하게 "git push" , "git pull" 만 하여 git에 담기만 하다 본격적으로 브런치를 사용하고 있는데정말 오늘 머리 깨지는 줄 알았다.. 삽질을 제대로 하였다.현재 포트폴리오에 Coding Timer + schedule 을 개발 중인데 운영 버전에는 아직 미완성 이라 제외했어야했다.그렇기에 내
[GIt] branch 협업 플로우
Git은 코드의 버전 관리와 협업을 위해 설계된 분산 저장소 시스템이다.여러 개발자가 단위별로 나누어 동시 개발을 가능하게 하고 코드의 충돌을 효과적으로 관리할 수 있도록 해주는 'branch' 기능을 활용하는 것이 매우 중요하다.지난 번에 깃에 관해 설명한 포스팅을 이어, 이 기능을 "잘" 활용하여 더욱 체계적으로 작업을 진행하는 방법에 대해 포스팅을 남
[Git] 스테이징과 커밋 전략
깃에 대한 자료를 물색하다가 의문점이 드는 문장을 발견했다."깃 커밋 전략" 그러고보니 포트폴리오를 진행하면서 커밋에 큰 생각하지 않고 너무 무지성으로git add . git commit을 남발했던 것이 아닐까 라는 생각이 들었다.전 회사에서도 git은 리포지토리만 존재했지 99% svn을 주로 사용했고외주 인력들과도 형상관리를 SVN으로 진행했는데 커밋