라벨이 git인 게시물 표시

개발을 시작할 때 git을 꼭 같이 시작했으면 하는 이유

이미지
개발을 시작하면 반드시 접하게되는 단어들이 있습니다. 그 중 하나는 git 입니다. 그렇다면 git을 왜 써야하고, 어느정도까지 써야하는 걸까요? 그에 대한 생각을 간단히 적어보겠습니다. git은 왜 써야 할까요? git은 크게 2가지의 이유로 사용한다고 생각합니다. 버젼관리 협업도구 그래서 우리는 우리의 코드가 잘 못 되었거나 과거의 코드로 되돌릴 때, git을 씁니다. 예를 들면, 내가 작성했던 코드가 문제가 생겼을 때 과거로 돌아갈 수 있다면 얼마나 좋을까요? 하나하나 되돌리기를 하는 것이 아니라 특정의 시점으로 돌아갈 수 있다면 나의 실수를 만회하기에 좋겠죠? 여러분의 실수를 되돌리기 위해 git의 사용방법을 익혀두세요! 다른 개발자와 협업을 해야할 때 협업의 도구로서 git을 사용합니다. 개발을 혼자하는 개발자도 있지만 많은 개발자들이 하나의 프로덕트를 만들기 위해 협업을 하고 있습니다. 서로 일할 범위를 나누고 따로 작업한 다음에 하나로 합친다면, 일을 효율적으로 할 수 있고, 결과물도 더 빠르게 만들 수 있겠죠? 생산성을 높이기 위해 git을 사용하세요! git 어느정도까지 써야하는 걸까요? 왜 써야하는지 알았으니 그러면 얼마나 써야하는지 이야기 해봅시다. 먼저 버전관리를 하기 위해서라면, commit을 꼼꼼히 하고 해당 커밋 때로 돌아가는 방법을 알면 좋을 것 입니다. 아니면 다른 사람이 작업한 내용 중 일부 혹은 내가 과거에 작업한 내용을 살리기 위한 cherry-pick 등과 같은 기능들을 알면 유용하겠죠? 다른 사람들과 협업을 하려면, git-flow는 이헤하고 사용해야 합니다. 나 혼자 git에 commit, push, pull을 한다고 git을 사용할 줄 안다고 생각한다면, 실제 협업을 하면서 많은 어려움이 있을 것 입니다. 어느 브랜치에서 개발을 해야하고, 어느 브랜치로 merge를 해줘야 하는지 알고 있어야 합니다. 더 나은 개발을 위해서 개발자로 시작하면서 git을 왜 해야하는지, 얼마나 해야하는지는 잘 공감

[git] git의 마지막 커밋 메시지 수정하기

이미지
[git] git의 마지막 커밋 메시지 수정하기 git을 쓰다가 보면 한참 커밋을 하고나서 푸쉬를 하고나니 의미없는 커밋 메시지가 많아서 커밋메시지를 위한 커밋 메시지를 커밋 하게되었습니다. 아무 의미 없는 커밋을 하나 늘리기는 싫어서 방법을 찾아보니 rebase를 쓰면 가능한 것을 찾았지만, 원래 기능이 아니기 때문에 다른 방법을 소개하려고 합니다. 아래와 같은 명령어를 입력합니다. git commit --amend 마지막 커밋 메시지가 뜨면서, 수정 후 저장할 수 있습니다. -m옵션을 주어 새로운 커밋 메시지를 바로 입력할 수 있습니다. git commit --amend -m "new message" push 하면 되지 않습니다. 왜냐하면 origin의 HEAD 보다 브랜치의 최신 커밋이 아니기 때문에 거절됩니다. 그러므로 우리는 강제로 push 해주어야 합니다. git push --force 하지만 이 때 주의해야 할 점이 있습니다. 누군가 이미 push 한 브랜치를 force push 하게 된다면, 같은 브랜치에 다른 이력이 쌓여 추후에 문제가 발생할 수 있습니다. force push 를 한다면 이렇게 꼬일 수 있는 상황에 대해서도 염두해 두어야 합니다.

[git] git의 upstream과 origin 헷갈리는 사람 손!

이미지
[git] git의 upstream과 origin git의 upstream과 origin upstream과 downstream 사전적인 의미를 파악해보면, upstream 이 상류, downstream 이 하류입니다. 물이 상류에서 하류로 흐르듯이 pull 하는 주최가 downstream 당하는 쪽이 upstream 입니다. 내 레포에서 다른 레포를 풀 해서 작업하고 있다면 다른 레포가 업스트림이 되겠군요! otherRepository(upstream) -> (git pull) myRepository(downstream) 이미지 출처 : https://aktiasolutions.com/upstream-kanban-business-agility/ upstream과 origin 그렇다면 업스트림과 오리진은 어떤 차이가 있는지 정리 하겠습니다. 보통은 다른 레포를 포크해서 내 레포를 만들어 놓고 내 레포를 클론, 풀 해서 작업합니다. 이때 가장 근본이 되는 레포를 upstream 이라고 부릅니다. 내가 fork해서 가져온 레포를 origin이라고 부릅니다. 그러므로 내가 로컬에 클론 해 놓고 작업할 때, origin/master에서 가져올지, upstream/master에서 가져와야 할지 생각해서 가져와야겠죠? otherRepository(upstream) -> (fork) myRepository(origin) otherRepository(upstream) -> (git pull) myRepository(local) myRepository(origin) -> (git pull) myRepository(local)

[git] git을 사용하는데 필요한 기본 개념과 기본 용어 정리

이미지
[dev] git 다루기 깃 개념 정리 깃을 알고 있다고 생각하고 쓰면서, 평소와 다른 문제가 일어나면서 깃에 대한 개념이 부족하다고 생각되어 찾아 본 내용들을 정리했다. 자세한 내용은 블로그 보다는 Git book 정독하는 것을 추천한다. 기본 사용 플로우 리모트에 있는 소스코드를 받거나(clone), 새로운 프로젝트를 시작한다. 변경사항을 저장(commit)하고, 리모트에 반영(push)한다. 이미 존재하는 소스코에서 독립적으로 작업을 진행해야 하는 경우에는 새로운 브랜치(branch)를 생성해 작업을 한다. 작업이 완료 된 후에, 갈라져 나온 origin branch에 merge되거나 rebase를 한다. Merge and Rebase mrege는 기존 존재하던 브랜치에 병합(merge)하는 기능이다. 기존 브랜치에 작업 내용이 없다면, fast-forward merge를 이용해 병합을 하거나 기존의 브랜치에도 작업 내용이 있다면, 3-way-merge 방식으로 각각의 브랜치의 작업 내용을 남겨놓고 하나의 브랜치로 병합한다. master 에서 slave를 merge해주면, master브랜치로 slave가 병합된다. rebase는 커밋 내역을 재정렬 해서 하나의 브랜치로 합쳐준다. 결과적으로는 한 갈래의 브랜치를 만들어준다. rebase해준 최신의 커밋으로 정렬되고 checkout 되어있던 브런치의 커밋이 먼저 정렬된다. slave 에서 master를 rebase해주면, master브랜치로 slave가 병합된다. Stash 아직 마무리 하지 않은 작업이 있지만, 다른 작업을 해야해서 변경사항을 저장해야 할 때는 어떻게 해야할까? 커밋해서 저장하기에는 내키지 않는다. 이럴 때 쓰는 명령어가 Stash 이다. 아직 마무리하지 않은 작업을 스택에 잠시 저장할 수 있도록 하는 명령어이다. 다음과 같은 파일을 Stash할 수 있다. Modified이면서 Tracked 상태인 파일 Stagi

[git] Github 이슈 라벨(issue labels)

이미지
[dev] Github issue labels Github에서 프로젝트의 문제점을 알리거나 기여를 할 때 이 issue label을 달거나 읽어야 할 일이 생긴다. 해당 이슈에 알맞은 라벨을 선택하고, 의미를 파악하기 위해 알아두자. keyword 의미 bug 예기치 않은 문제 또는 의도하지 않은 동작(버그)을 나타냅니다. documentation 문서를 개선하거나 추가 할 필요가 있음을 나타냅니다. duplicate 해당이슈 또는 PR이 기존에 있음을 나타냅니다. enhancement 새로운 기능 요청을 나타냅니다. good first issue 처음 기여해볼 사람에게 좋은 문제를 나타냅니다. help wanted 관리자가 문제 또는 PR 요청에 대한 도움을 원함을 나타냅니다. invalid 이슈 또는 PR 요청이 더 이상 관련이 없음을 나타냅니다. question 이슈 또는 풀 요청에 추가 정보가 필요함을 나타냅니다. wontfix 문제 나 PR 요청에서 작업이 계속되지 않음을 나타냅니다. 참고 : https://help.github.com/en/github/managing-your-work-on-github/about-labels