공부방/git (9) 썸네일형 리스트형 df git add 명령어로 staging 한 파일들을 다시 되돌리려면 git reset 을 사용해준다. Git(31) git add 취소하기 (staging 취소) 앗 ! 실수로 git add . 를 하여 변경한 전체 파일을 staging 했다. 😵💫 당황치 말고 git reset 으로 다시 unstaged 상태로 되돌리자 🤓 만약, 특정 파일만 unstaged로 되돌리고 싶다면 ? git reset 뒤에 파일경로를 적어주면 해결! Git의 Staging Area는 어떤 점이 유용한가 Git의 Staging Area는 어떤 점이 유용한가 Git에는 Staging Area라는 공간이 있다. 어떤 변경사항이 저장소에 커밋되기 전에, 반드시 거쳐야만 하는 중간단계이다. 다른 버전관리도구에는 이에 정확히 대응하는 것은 없다. 저장소가 추적하는(관심의 대상이 되는) 파일들의 목록을 유지하고, 그 파일들에 대한 메타데이터를 관리하는 것은 다른 저장소들도 하는 일이지만, Git 처럼 커밋될 예정인 파일의 내용들까지 기억하지는 않는다. 이 Staging Area의 존재는 처음 Git을 사용하는 입장에서는 그저 불편만 안겨주고 이해만 더디게 만들어주는 목적불명의 무언가에 지나지 않는다. 다른 SCM에선 파일을 고치고 바로 커밋하면 되었는데, Git은 반드시 그 전에 add를 해 줘야 한다. 이런 비용.. [Git] Git 3가지 영역 (Staging Area) - Commit 이해하기 Staging Area Commit을 할 때, 총 3가지 영역을 바탕으로 작동합니다. Working Directory : 내가 작업하고 있는 프로젝트의 디렉토리 Staging Area : 커밋을 하기 위해 $ git add 명령어로 추가한 파일들이 모여있는 공간 Repository : 커밋들이 모여있는 저장소 열심히 코드를 작성하다가 커밋을 해야하는 순간이 오면 git add .를 통해 커밋할 파일들을 추가합니다. 이 파일은 바로 Repository에 올라가지 않고, Staging Area에 올라가게 됩니다. Staging Area에 추가한 파일들을 Commit을 한다면 최종적으로 저장소(Repository)로 저장되게 됩니다. File Status LifeCycle File 관점에서는 다시 4가지 단계.. [Git] Git HEAD, reset 옵션 3가지 (hard, mixed, soft) HEAD 란? 현재 내가 위치해있는 커밋을 가리키는 식별자입니다. 보통 커밋을 가리킬 때에는 HEAD가 간접적으로 브랜치를 통해서 가리키게 되는데 아래의 형태가 바로 그 모습입니다. HEAD가 master 브랜치를 통해 간접적으로 세번째 커밋을 가리키고 있습니다. $ git reset --{option} {commit_id} HEAD가 가리키는 커밋에 따라 working directory의 형태도 바뀌게 됩니다. 한번 첫번째 커밋으로 이동해 보겠습니다. (옵션은 아래에서 설명하겠습니다.) $ git reset --hard {commit_id} 첫번째 커밋으로 이동했더니 두번째 커밋과 세번째 커밋이 없어졌습니다. 자 이제 다시 최신 커밋인 세번째 커밋으로 이동합시다. 어라, $ git log로 세번째 커밋.. Github을 잘 사용해보자! (Issue와 commit) 이번에는 github에 있는 기능들을 십분 활용해보자 또는 적재적소에 잘 사용하지 못하더라도 경험을 해 보자 하는 차원에서 시작해본 내용이다. github에는 내가 사용해보지 않은 많은 기능들이 있었다. 이번에는 그 중에서 Issue와 commit을 잘 사용해보자 라는 생각에서 시작하였다. issue와 commit을 잘 조합해서 사용한다면 어떤 기능을 어떻게 구현했는지 남들이 더 보기 좋게, 또는 동료들이 한눈에 파악하기 쉽게 만들 수 있을 것 같았다. issue와 commit을 살펴보던 중 project와 milestone이라는 것을 알게되었고 이것도 같이 사용을 해보면 좋겠다고 생각을 하여 팀원들과 의견을 공유하며 어떻게 사용할 지를 정하였다. Project 상단 메뉴바에 존재하며 Project는 I.. Git 작업관리 프로젝트를 진행함에 따라 git을 더 잘 써야할 것 같다는 의무감과 동시에 욕심이 생기기 시작하였다. main이 아닌 각자 branch에 push를 해달라고 요청을 하였지만, git이 아직 익숙하지 않아 그 마저도 어려워 하는 사람들이 있었기에 내가 욕심이 난다고 하여 무작정 추진할 수는 없는 노릇이었다. 이윽고 최종 프로젝트가 다가왔고, 이번에는 모두가 의욕적이었기에 많은 변화를 시도할 수 있었다. Git을 좀 더 잘 쓰기 위해서 우리는 어떤 전략이 있는지 살펴보았으며, git flow와 github flow 둘 중에 하나 고르면 되겠다는 생각을 하였다. git flow와 github flow 두개의 선택지 중에서 git flow를 선택하게 되었는데, 선택의 근거는 아래와 같습니다. 1. main br.. [git] 동시에 여러 작업하기 다중 branch 생성 테스트를 위하여 2개의 branch를 생성해 봅시다. git branch issue2 git branch issue3 issue2 branch로 이동 및 branch 확인 git checkout issue2 git branch issue2에서 파일을 변경하고 변경내역 저장 git add git commit -m "issue2에서 변경하였음" issue3 branch로 이동 후 변경 내역 저장 및 commit git checkout issue3 git add git commit -m "issue3에서 변경하였음" main branch로 이동 후 issue2 브랜치 병합 git checkout main git merge issue2 main branch에서 issue3 브랜치 병합 g.. [git] 브랜치 사용하기 브랜치란?? 브랜치란 독립적으로 어떤 작업을 진행하기 위한 개념입니다. 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있습니다. 또한 이렇게 만들어진 브랜치는 다른 브랜치와 병합(Merge)함으로써, 작업한 내용을 다시 새로운 하나의 브랜치로 모을 수 있습니다. 여러 명이서 동시에 작업을 할 때에 다른 사람의 작업에 영향을 주거나 받지 않도록, 먼저 메인 브랜치에서 자신의 작업 전용 브랜치를 만듭니다. 그리고 각자 작업을 진행한 후, 작업이 끝난 사람은 메인 브랜치에 자신의 브랜치의 변경 사항을 적용합니다. 이렇게 함으로써 다른 사람의 작업에 영향을 받지 않고 독립적으로 특정 작업을 수행하고 그 결과를 하나로 모아 나가게 됩니다. 이러한 방.. 이전 1 2 다음
