diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000..45867fe Binary files /dev/null and b/.DS_Store differ diff --git a/README.md b/README.md index fcd44c6..6bdd03e 100644 --- a/README.md +++ b/README.md @@ -1,38 +1,67 @@ -# Git Study -- [1️⃣️ Git 기초](#1️⃣️-git-기초) -- [2️⃣️ Git 협업](#2️⃣️-git-협업) -- [3️⃣️ 협업 중 문제상황](#3️⃣️-협업-중-문제상황) -- [4️⃣️ 동아리 협업](#4️⃣️-동아리-협업) -- [🔗️ 참조](#️-참조) - - -![learn-git](https://i0.wp.com/blog.nextstacks.com/wp-content/uploads/2021/11/Reasons-to-Learn-Git-as-a-Developer-New.png?fit=1280%2C720&ssl=1) - 동아리 Git 스터디/워크샵을 위한 리포지토리입니다. 스터디는 실습 형식으로 총 4단계로 구성되어 있으며 2~3일에 걸쳐 진행합니다. git 커맨드라인 환경에서 진행하므로 사전에 [동아리 개발환경 설정](https://github.com/ApptiveDev/.github/blob/main/docs/Dev%20Environment%20Setup.md) 문서를 따라주시기 바랍니다. 또, 스터디를 진행하면서 부족한 부분은 계속 보완해주시기 바랍니다. -- 개인의 선호에 따라 GUI 툴 활용 가능 (GitKraken, SourceTree, Github GUI 등) - -## 1️⃣️ Git 기초 -### 🎯️ 목표 -git과 github의 차이점, git이 동작하는 과정, git 기본 명령어를 알아봅시다! -### 📜️ 진행 -- `step-1` 브랜치로부터 자신의 브랜치를 생성합니다. -- `README`에 주어진 키워드를 조사하고 본인의 README를 작성합니다. -- 작성 후 `step-1` 브랜치로 Pull Request를 올립니다. - -## 2️⃣️ Git 협업 -### 🎯️ 목표 -앞서 익힌 git 명령어를 활용해 간단한 협업을 진행해봅니다. - -### 📜️ 진행 - -## 3️⃣️ 협업 중 문제상황 -### 🎯️ 목표 -협업 중 맞닥뜨릴 수 있는 다양한 문제상황을 git 명령어로 해결해봅니다. -### 📜️ 진행 - -## 4️⃣️ 동아리 협업 -### 🎯️ 목표 -[동아리 브랜치 관리전략](https://github.com/ApptiveDev/.github/blob/f9a2f448b57225c3921dc774e8b7800c3289e878/docs/CONTRIBUTING.md)을 지키며 협업을 진행해봅니다. -### 📜️ 진행 - -## 🔗️ 참조 -- [누구나 쉽게 이해할 수 있는 Git 입문](https://backlog.com/git-tutorial/kr/) +# 1️⃣️ Git 기초 +![git-basics](https://digitalvarys.com/wp-content/uploads/2019/06/Git-Basics-and-Beginners-Guide-1.png) +Git과 Github 사용의 첫 단계입니다. + +## 🎯️ 목표 +- [ ] git의 동작 과정 이해 +- [ ] rebase와 reset 이해 +- [ ] Github 저장소 clone 하기 +- [ ] 브랜치를 만들고 커밋 쌓기 +- [ ] Pull Request와 Merge +- [ ] Markdown 문서 작성 + +## 📜️ 진행 +1. 이 리포지토리를 로컬에 clone 합니다. +```bash +# 적당한 폴더 생성 및 이동 (linux의 경우 ~/repositories 추천) +# Window의 경우 아래 명령어 실행 시, 기본적으로 C:\Users\사용자 계정명\repositories로 생성됩니다. +mkdir ~/repositories +cd ~/repositories + +# 현재 리포의 우측 상단에서 git clone URL 복사 후 붙여넣기 +git clone https://github.com/ApptiveDev/workshop-git.git + +# 클론된 폴더로 이동 +cd workshop-git +``` + +2. 이 브랜치(`step-1`)에서 본인의 브랜치를 만듭니다. + - 브랜치명은 `step-1-이름`으로 생성 +```bash +# step-1 브랜치로 이동 +git checkout step-1 + +# 본인 브랜치 생성 및 이동 +git checkout -b step-1-이름 +``` + +3. `/git-basics/README.md`를 복사하고, 빈 항목들을 조사해 채워넣습니다. + - 복사한 파일명은 `/git-basics/<기수>/REAMDE-<이름>.md`로 변경 + - ex) `git-basics/22rd/README-WONSEOK.md` + - 채우면서 최소 3개의 커밋 쌓기 +```bash +# <기수> 폴더 생성하기 (없다면) +# 1은 뒤에 st, 2는 nd, 3은 rd로 붙이기 (ex - 21st, 22nd, 23rd, 24th, ...) +mkdir git-basics/<기수> + +# /git-basics/README.md 복사 +cp git-basics/<기수>/README.md git-basics/<기수>/README-<이름>.md + +# (README-<이름>.md를 채우면서) +git add . +git commit -m "<커밋 메시지>" +``` + +4. 본인 브랜치를 push하고 `step-1` 브랜치로 Pull Request를 올립니다. +```bash +# 브랜치를 처음 push하는 경우 원격 브랜치 등록 +# 현재 브랜치를 origin의 step-1-<이름> 브랜치와 연동한다. +# step-1-<이름> 대신 다른 브랜치명을 사용하면 해당 원격 브랜치와 연결됨. +git push --set-upstream origin step-1-<이름> +# 첫 push 이후에는 git push만 사용하면 됨 +git push +``` + +## ➕️ 추가 목표 +이제 Markdown 문서를 작성할 수 있게 되었으니, 본인의 Github 프로필을 꾸며봅시다. 아래 참고 블로그나 잘 꾸며진 프로필을 보면서 본인의 프로필을 만들어보세요. 연습을 위해 로컬 git에서 작업하시기 바랍니다. +- **참고**: [(노션) 깃허브 프로필 꾸미기!](https://80000coding.oopy.io/865f4b2a-5198-49e8-a173-0f893a4fed45) diff --git a/git-basics/.DS_Store b/git-basics/.DS_Store new file mode 100644 index 0000000..b7e4a13 Binary files /dev/null and b/git-basics/.DS_Store differ diff --git a/git-basics/19th/.DS_Store b/git-basics/19th/.DS_Store new file mode 100644 index 0000000..000a9af Binary files /dev/null and b/git-basics/19th/.DS_Store differ diff --git a/git-basics/19th/README-JinSeoHyun.md b/git-basics/19th/README-JinSeoHyun.md new file mode 100644 index 0000000..7654589 --- /dev/null +++ b/git-basics/19th/README-JinSeoHyun.md @@ -0,0 +1,441 @@ +노션 링크 첨부 +https://www.notion.so/Git_Hub-Study-09e13a1415214a4f9523a1e63071b7cd + +### **1️⃣️ Git 기초** + +🎯 스터디 목표 + +- git과 github의 차이점 +- git이 동작하는 과정 +- git 기본 명령어 + +## 📌 Git이란? + +```kotlin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 +``` + +--- + + 🔖 **Git** + +개인 컴퓨터에서 돌아가는 `분산 버전 관리 시스템`이다. + +> **“버전 관리 시스템”** +> +> - 파일 변화를 시간에 따라 기록했다가 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템이다 +> +> **“분산 버전 관리 시스템”.** +> +> - 저장소 자체를 히스토리와 더불어 전부 복제한다. + +🔖 **Github** + +Github는 Git 소프트웨어를 지원하는 **일종의 클라우드 서비스**이다. + +> 🤔 단순히 고양이 클라우드 서비스인 줄 알았는데 분산 처리 구조와 협업에서 병합 문제를 해결할 수 있는 도구로 깃허브가 필수인 이유를 알게 되었다. +> + +[➕ Git에서 병합 충돌을 해결하는 방법](https://docs.github.com/ko/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github) + +📍 Git은 병렬 개발이 가능하다. 👉 `branch` + +## 📌 **Git 동작흐름** + +![Untitled](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/0a7c3af7-4db2-4864-827b-443f9a368543/Untitled.png) + +```kotlin +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. +``` + + 📒 **Working Directory**  + +작업할 파일이 있는 디렉토리이다. **** + +- untracked - 정보가 아직 없고 트래킹하지 않은, +- tracked - (수정된/수정된) + + 📒 **Staging Area**  + + ****커밋(Commit)을 수행할 파일들이 올라가는 영역이다. + +- 고유한 해시코드 , 작성시간, 작성자의 정보를 가진다. + + 📒 **Local repository** + +개발자는 로컬 저장소에서 작업한다. 로컬저장소는 개발자 개인의 작업 공간이다. + + 📒**Remote repository** + +원격저장소는 인터넷 상의 서버에 위치한 Git 저장소이다. 여러 개발자가 협업을 위해서 사용하고, 코드의 변경사항을 받아올 수 있다. + +### ⌨️ 명령어 설명 + +- ✍️ `git add 명령어` + + 작업 디렉토리상의 변경내역을 스테이징 영역에 추가하기 위해 사용하는 명령어이다. + + ```bash + git add + + git add * + + git add . (모든 파일을 포함해서) + + git add *.css (css파일들만) + ``` + + > 다음 변경을 기록할 때까지 변경분을 모아놓는 작업으로 `git commist`명령어를 통해 명시적으로 기록을 남기기 전까지는 Git 저장소의 변경 이록에 아무런 영향을 줄 수 없다. + > + +- ✍️ `git status 명령어` + + 작업 디렉토리(working directory)와 스테이징 영역(staging area)의 상태를 확인하기 위해서 사용하는 명령어이다. + + ```bash + git status + ``` + + > **Changes to be committed** + > + > + > 이 영역은 스테이징 영역에 넘어가 있는 변경 내용을 보여줍니다. + > + > **Changes not staged for commit** + > + > 이 영역은 아직 워킹 디렉토리에 있는 변경 내용을 보여줍니다. + > + > **Untracked files** + > + > 이 영역도 아직 워킹 디렉토리에 있는 아직 한 번도 해당 Git 저장소가 관리한 적이 없는 새로운 파일을 보여줍니다. + > + +## 📌 **Branch, HEAD** + +```kotlin +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. +``` + +--- + +📒 **Commit** + +코드의 변경 사항을 저장하는 작은 단위이다. + +🧾 Commit 메시지 + +- 변경사항을 간결하고 명확하게 설명해야한다. + +```bash +git commit -m "Commit message" +//커밋 메시지를 지정하는 옵션입니다. 커밋 메시지는 해당 커밋의 변경 사항을 간결하게 설명하는 역할을 합니다. 메시지는 반드시 작성되어야 한다. + +git commit -a -m "Commit message" +//-a: 변경된 모든 파일을 자동으로 스테이징하고 커밋하는 옵션입니다. 이 옵션을 사용하면 git add 명령을 사용하여 파일을 스테이징할 필요 없이 수정된 파일들이 자동으로 커밋됩니다. 하지만 새로 생성된 파일은 스테이징되지 않으므로 주의해야 합니다. + +git commit --amend +//--amend: 이전 커밋을 수정할 때 사용하는 옵션입니다. 만약 이전 커밋의 메시지를 수정하거나 변경 사항을 추가하려면 이 옵션을 사용합니다. 이 경우, 변경 사항을 스테이징하고 --amend 옵션을 사용하여 커밋을 수정합니다. + +git commit --amend -m "New commit message" +//--amend -m "New commit message": 이전 커밋의 메시지를 수정할 때, 새로운 커밋 메시지를 지정하는 옵션입니다. + +``` + +📒 **Branch** + +Branch는 코드 변경 사항을 분리하여 관리하는 방법입니다. + +- 기본적으로 'main' 또는 'master'라는 기본 브랜치가 있으며, 새로운 브랜치를 만들 수 있습니다. + +```bash +//새로운 브랜치 생성 +git branch + +//브랜치 삭제 +git branch -d + +//브랜치 이동 +git checkout + +//브랜치 생성 후 이동 +git checkout -b +``` + +📒 **HEAD** + +현재 작업 중인 Commit을 가리키는 포인터이고, 현재 체크아웃된 브랜치의 가장 최신 커밋을 가리킨다. + +[더 알아보기](https://charles098.tistory.com/24) + +## 📌 **clone, init, origin** + +```kotlin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 +``` + +--- + +📒 **`git clone`과 `git init`의 차이점과 이용 방법** + +- **`git init`** + - 새로운 디렉토리를 Git 리포지토리로 초기화하는 명령어입니다. 이 방법은 기존 프로젝트를 버전 관리하려는 경우에 유용합니다. 초기화 후에는 **`git add`**, **`git commit`** 등의 명령어를 사용하여 변경 사항을 관리할 수 있습니다. + +- **`git clone`** + - 원격 저장소에서 전체 리포지토리를 복제하여 로컬 환경에 가져오는 명령어입니다. 다른 사람이나 팀과의 협업이나 기존 프로젝트의 포크(Fork)를 생성할 때 주로 사용됩니다. + +📒 **`origin`이란 키워드와 설정 방법** + +- **`origin`** + + 리모트(원격) 저장소의 닉네임으로, 원격 저장소의 URL을 가리킵니다. 기본적으로 Git에서 원격 저장소를 참조할 때 사용되는 이름입니다. + + **`origin`** 설정 방법 + + - **`origin`**을 설정하려면 **`git remote add`** 명령을 사용합니다. 이 명령을 통해 원격 저장소의 URL과 **`origin`**이라는 이름을 연결합니다. + + ``` + git remote add origin + ``` + + 이후에는 **`git push`**, **`git pull`**, **`git fetch`** 등의 명령을 사용하여 원격 저장소와의 데이터 교환을 할 때 **`origin`**을 사용합니다. **`origin`**은 원격 저장소의 URL과 닉네임을 편리하게 관리하도록 도와줍니다. + + +[더 알아보기](https://git-scm.com/book/ko/v2/Git%EC%9D%98-%EA%B8%B0%EC%B4%88-%EB%A6%AC%EB%AA%A8%ED%8A%B8-%EC%A0%80%EC%9E%A5%EC%86%8C) + +> ➕ **`git clone`** 명령어를 실행하면, 원격 저장소의 URL을 **`origin`**이라는 이름으로 자동으로 설정해줍니다. 이렇게 함으로써 나중에 원격 저장소와의 상호작용 시 간편하게 사용할 수 있습니다. +> + +## 📌 **reset** + +![Untitled](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/49b458e8-7f71-4ab8-a1a9-2a6dd6a0e9e0/Untitled.png) + +```markdown +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. +``` + +--- + +**`reset`** 명령은 커밋을 조작하거나 작업 디렉토리의 상태를 변경하는 데 사용되는 중요한 명령어입니다. + +| HEAD | 마지막 커밋 스냅샷, 다음 커밋의 부모 커밋 | +| --- | --- | +| Index | 다음에 커밋할 스냅샷 +git commit 명령을 실행하면 Index는 새 커밋으로 변환된다. | +| 워킹 디렉토리 | 샌드박스 | + +📒 **Mixed Reset (`git reset [--mixed] `)** + +![Untitled](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/c3f6abe1-b581-4759-940b-710f8c9bccb7/Untitled.png) + +```bash +git reset +``` + +- 가리키는 대상을 가장 최근의 `커밋` 으로 되돌리는 것은 같다. 그러고 나서 ***Staging Area*** 를 비우기까지 한다. `git commit` 명령도 되돌리고 `git add` 명령까지 되돌리는 것이다. + +📒 **Soft Reset (`git reset --soft `)** + +![Untitled](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/097ef8bb-24ca-4641-a404-712e2d71b71a/Untitled.png) + +```bash +git reset --soft +``` + +- 이 리셋은 **`-mixed`**와 유사하지만, 변경 사항을 스테이징 영역에 남겨둡니다. 이전 커밋으로 되돌아가기 위해 사용됩니다. +- 선택한 커밋으로 돌아가고, 해당 커밋 이후의 변경 사항을 스테이징 영역에 남겨둡니다. + +📒 **Hard Reset (`git reset --hard `)** + +![Untitled](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/3521e3be-79cb-40cb-b568-56b4b6450e21/Untitled.png) + +```bash +git reset --hard +``` + +- `reset` 명령을 통해 `git add` 와 `git commit` 명령으로 생성한 마지막 커밋을 되돌린다. 그리고 **워킹 디렉토리의 내용까지도 되돌린다.** +- 변경 사항이 모두 제거되고, 선택한 커밋의 상태로 작업 디렉토리와 스테이징 영역이 강제로 덮어씌워집니다. +- 주의: 이 모드는 변경 사항을 완전히 삭제하므로 조심해서 사용해야 합니다. + +## 📌 **Pull Request, Merge** + +![Untitled](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/afa84c89-23f6-4e84-9603-4a7aea7a279b/Untitled.png) + +```kotlin +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. +``` + +--- + +📒 **Pull Request (풀 리퀘스트)** + +Pull Request는 코드 변경 사항을 다른 브랜치에 병합하도록 요청하는 기능입니다. + +1. 개발자는 자신의 변경 사항이 포함된 브랜치에서 작업을 완료하고 커밋합니다. +2. 원격 저장소에 해당 브랜치를 푸시합니다. +3. 해당 브랜치에서 GitHub, GitLab, Bitbucket 등의 웹 기반 플랫폼에서 Pull Request를 생성합니다. +4. 다른 팀원들은 Pull Request를 검토하고 논의할 수 있습니다. 변경 사항이 품질과 표준을 준수하는지 확인합니다. +5. 리뷰가 완료되면 Pull Request를 병합(Merge)할 수 있습니다. + +📒 **Merge (병합)** + +Merge는 두 개의 다른 브랜치의 변경 사항을 하나의 브랜치에 통합하는 작업입니다. 주로 Pull Request를 통해 수행되며, 두 가지 주요 Merge 타입이 있습니다. + +🗒️ **Fast-Forward Merge** + +- Fast-Forward Merge는 히스토리 분기가 없을 때 사용됩니다. 즉, 브랜치가 포인터처럼 일렬로 나열되어 있는 상황입니다. +- 변경 사항을 통합하기 위해 기준 브랜치(주로 **`main`** 또는 **`master`**)를 병합하려는 브랜치의 최신 커밋으로 이동시킵니다. +- 이로써 변경 사항이 기준 브랜치에 빠르게 통합됩니다 + +🗒️ **3-Way Merge (3-way 병합)** + +- 3-Way Merge는 두 브랜치가 서로 다른 변경 사항을 가지고 있을 때 사용됩니다. +- 기준 브랜치, 통합하려는 브랜치, 그리고 공통 조상 커밋을 비교하여 변경 사항을 통합합니다. +- Git은 변경 사항을 가능한 한 자동으로 병합하고, 충돌(conflict)이 발생하면 사용자에게 해당하는 부분을 해결하도록 안내합니다. + +## 📌 **rebase** + +```kotlin +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. +``` + +--- + +📒 **rebase** + +Git에서 브랜치의 커밋 히스토리를 다시 구성하거나 변경하는 작업을 의미합니다. 주로 브랜치를 다른 브랜치에 더 적절하게 통합하거나 더 선형적인 히스토리를 유지하기 위해 사용됩니다. + +✅ **Rebase의 기본 작동 방식** + +1. 현재 브랜치에서 다른 브랜치의 변경 사항을 가져옵니다. +2. 현재 브랜치의 커밋 히스토리를 다른 브랜치의 커밋 히스토리 위로 이동시킵니다. +3. 충돌이 발생하면 충돌을 해결하고 계속 진행합니다. +4. 브랜치의 히스토리가 재정렬되고, 변경 사항이 적용됩니다. + +✅ **Rebase가 유용한 상황** + +1. **브랜치 통합**: 다른 브랜치에서 작업한 변경 사항을 현재 브랜치에 더 효율적으로 통합하고 싶을 때 사용됩니다. **`merge`** 대신 **`rebase`**를 사용하여 더 선형적인 히스토리를 유지할 수 있습니다. +2. **커밋 히스토리 정리**: 커밋 히스토리를 깔끔하게 유지하기 위해 사용됩니다. 커밋 메시지를 수정하거나 불필요한 중간 커밋을 합치는 등의 작업을 수행할 수 있습니다. +3. **충돌 해결**: 충돌이 발생할 경우, **`rebase`**를 통해 충돌을 더 명확하게 보면서 해결할 수 있습니다. +4. **Upstream 변경 통합**: 원격 저장소의 변경 사항을 받아오거나 업스트림 변경을 반영할 때 사용됩니다. 기존 커밋 히스토리 위로 변경 사항을 적용할 수 있습니다. + +> ⚠️ 주의할 점 + **`rebase`**를 남들과 함께 작업하고 있는 브랜치에서 사용할 때, 히스토리가 변하기 때문에 주의해서 사용해야 한다. +> + +## 📌 **stash** + +```kotlin +git stash를 활용하는 방법에 대해 적어주세요. +``` + +--- + +📒 **stash** + +Stash 명령을 사용하면 워킹 디렉토리에서 수정한 파일들만 저장한다. Stash는 Modified이면서 Tracked 상태인 파일과 Staging Area에 있는 파일들을 보관해두는 장소다. + +아직 끝내지 않은 수정사항을 스택에 잠시 저장했다가 나중에 다시 적용할 수 있다(브랜치가 달라져도 말이다). + +**✅ git stash 활용 방법** + +**1. 변경 사항 저장:** + +```bash +git stash +``` + +이 명령을 실행하면 스테이징 영역에 있는 변경 사항과 작업 디렉토리의 변경 사항이 모두 저장됩니다. 작업 디렉토리는 이전 커밋 상태로 되돌아가며, 변경 사항은 일시적으로 스태시(stash) 스택에 저장됩니다. + +**2. 스태시 리스트 확인:** + +```bash +git stash list +``` + +이 명령을 실행하면 스태시 스택에 저장된 스태시들의 리스트를 확인할 수 있습니다. + +**3. 스태시 적용:** + +```bash +git stash apply +``` + +가장 최근에 저장한 스태시를 현재 브랜치에 적용합니다. 스태시는 스택에 남아있으므로 나중에도 다시 적용할 수 있습니다. + +➕ Git은 Stash를 적용할 때 Staged 상태였던 파일을 자동으로 다시 Staged 상태로 만들어 주지 않는다. 그래서 `git stash apply` 명령을 실행할 때 `--index` 옵션을 주어 Staged 상태까지 적용한다. 그래야 원래 작업하던 상태로 돌아올 수 있다. + +**4. 특정 스태시 적용:** + +```bash +git stash apply stash@{n} +``` + +특정 스태시를 적용할 때는 위와 같이 스태시 인덱스(**`stash @{n}`**)를 명시합니다. + +**5. 스태시 적용 및 제거:** + +```bash +git stash pop +``` + +가장 최근에 저장한 스태시를 적용하고, 스태시 스택에서 제거합니다. + +**6. 스태시 제거:** + +```bash +git stash drop stash@{n} +``` + +`apply` 옵션은 단순히 Stash를 적용하는 것뿐이다. Stash는 여전히 스택에 남아 있다. `git stash drop` 명령을 사용하여 해당 Stash를 제거한다. + +특정 스태시를 제거할 때는 위와 같이 스태시 인덱스(**`stash@{n}`**)를 명시합니다. + +**7. 모든 스태시 제거:** + +```bash +git stash clear +``` + +스태시 스택에 있는 모든 스태시를 제거합니다. + +> **`git stash`**를 활용하면 현재 작업 중인 변경 사항을 임시로 저장하고 나중에 다시 적용할 수 있어 편리합니다. 이를 통해 다른 브랜치로 이동하거나 작업을 정리하는 동안 변경 사항을 보존하면서 유연하게 작업할 수 있습니다. +> + +[더 알아보기](https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-Stashing%EA%B3%BC-Cleaning) + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push/pull --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 `parent/child-1`, `parent/child-2`는 가질 수 있지만 `parent`, `parent/child`는 가질 수 없다. 무슨 이유 때문인지. +- 리포지토리의 두 타입인 bare, non-bare + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push/pull --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 `parent/child-1`, `parent/child-2`는 가질 수 있지만 `parent`, `parent/child`는 가질 수 없다. 무슨 이유 때문인지. +- 리포지토리의 두 타입인 bare, non-bare + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. \ No newline at end of file diff --git a/git-basics/19th/README-LeeJiEun.md b/git-basics/19th/README-LeeJiEun.md new file mode 100644 index 0000000..7293237 --- /dev/null +++ b/git-basics/19th/README-LeeJiEun.md @@ -0,0 +1,182 @@ +# Git 기초 + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. +- git + - local에서 프로젝트 기록을 스스로 관리할 수 있다. + - 다른 개발자와 코드를 실시간으로 공유할 수 없다. + - **버전 관리 '프로그램'** +- github + - 클라우드 서버를 사용하여 local에서 버전 관리한 코드를 업로드하여 공유 가능하다. + - **버전 관리, 소스 코드 공유, 분산 버전 제어 등이 가능한 원격 저장소** + + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. +- Working Directory + - 실제 코드를 수정&추가하여 변경이 이루어지는 영역 + - git 이력과 관련된 정보가 저장되어 있는 .git 을 제외한 모든 영역 +- git add + - 현재 Working Directory 상의 변경 내용을 Staging Area로 이동시키는 명령어, 새로운 파일이 생겼다는 것을 알리는 행위 + - Staging Area : Working Directory 에서 Repository로 정보가 저장되기 전 준비 영역 + +- git commit + - 파일 및 폴더의 변경 사항을 Local Repository에 기록하는 명령어 + - 특정 작업이 완결된 상태로 바뀌었다는 것을 의미함 + +- git push + - 변경 사항을 Remote Repository에 기록하는 명령어 + + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. +- branch : 독립적으로 작업을 진행하기 위한 개념 +- HEAD : branch의 가장 최신 commit을 가리키는 포인터 +- branch와 HEAD + - commit을 하면 HEAD가 가리키는 branch가 최신 commit으로 이동한다. + - + + - 여기서 highlevel branch를 만들면 highlevel branch은 HEAD가 가리키던 커밋을 가리키게 된다. + - + + - **git checkout highlevel**을 입력하면 HEAD가 highlevel branch를 가리키게 된다. + - + + - 여기서 commit을 2번 진행하면 아래와 같이 된다. + - + +- [출처 : https://charles098.tistory.com/24] + + + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 + - git clone : 저장소로부터 프로젝트를 복제하는 명령어 + - git init : 해당 폴더를 git으로 관리할 수 있게 해주는 명령어 + - git clone은 **기존 저장소를 복제하는 것** / git init은 **기존에 사용하던 디렉토리를 Git 저장소로 만드는 것** +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + - origin : 깃허브 저장소 주소를 가리키는 키워드 + - git remote add origin {원격 저장소 주소} : 로컬 저장소에 원격 저장소를 등록 + - git remote remove origin : 원격 저장소를 git의 설정에서 삭제 + + + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. +- git reset <커밋ID> : 과거 commit 지점으로 이동하고, 이동된 이후의 commit은 삭제하는 명령어 + 1. git reset –hard : 해당 커밋ID의 상태로 이동하고, Working Directory와 Index영역 모두 초기화한다. + 2. git reset –mixed : 해당 커밋ID의 상태로 이동하고, Index영역은 초기화되고 Working Directory는 변경되지 않는다. + 3. git reset –soft : 해당 커밋ID의 상태로 이동하고, Index영역과 Working Directory 모두 변경되지 않고, commit된 파일들을 staging area로 돌려놓는다. + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. +- Pull Requst(PR) + - 사용자가 원격 저장소에 push했을 때, 다른 사용자에게 push된 상황을 알리는 것을 말한다. + - PR를 보내면 여러 동료들에게 리뷰를 받을 수 있고, 내가 올린 코드에 동료가 병합하여 진행할 수도 있다. +- Merge + - git branch를 다른 branch로 합치는 과정 + - 기본 단위는 branch + - 종류 + - Fast-Forward + - ![fast-forward](https://wikidocs.net/images/page/153693/05.03.01.jpg) + - Fast-foward 상태 : master와 dev1이 각각 가리키는 commit은 동일 선상에 위치하고 있다. 이때 두 branch는 Fast-foward 상태에 있다고 한다. + - 새로운 commit을 만들지 않는다. + - 빨리 감기(fast-forward) : 뒤에 쳐진 branch(master)의 참조 개체가 앞서있는 branch가 가리키는 개체를 참조하도록 이동한다.(마치 브랜치가 점프 하듯) + - 사용 예 : master로 개발을 진행하다 어떤 내용을 수정해야 하는데, master에서 테스트하기 힘든 경우 다른 branch로 해당 내용을 수정하고 후에 합병할 때 사용 + - 3-Way Merge + - ![3-way merge](https://wikidocs.net/images/page/153693/05.03.03.jpg) + - 두 브랜치 모두 base에서 commit을 진행해서 분기해 나간 상태가 되었다. 두 브랜치 중 어느 것도 base에 위치하지 않는다. + - 새로운 commit을 만든다. + - 3-way : 내용을 병합할 때, base와 각 브랜치 2개가 참조하는 commit을 기준으로 병합을 진행하기 때문이다. + + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. +- rebase + - git rebase [브랜치명] : 현재 브랜치가 해당 브랜치(브랜치명)에부터 분기하도록 재배치 + - 새로운 commit을 만들지 않는다. + - commit 이력을 명확하게 남기고자 한다면 merge, 간결하게 정리된 것을 원한다면 rebase를 사용하면 좋다. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. +- git stash + - 파일의 변경 내용을 일시적으로 기록해두는 영역 + - 명령어 + - git stash save "message" : 메세지O + - git stash : 메세지X + - 활용 : 현재 내가 하고 있는 업무보다 우선순위가 높은 새로운 업무를 받거나, 버그를 당장 고쳐야할 때 + - 다시 불러오는 명령어 : + - git stash pop : 목록에서 사라지고 불러옴 + - git stash apply : 목록에서 사라지지 않고 불러옴 + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? + - 이미 커밋한 히스토리를 변경하거나 또는 삭제하거나, 내용을 추가해야하는 상황에 사용 + - git rebase -i ${수정할 커밋의 직전 커밋} + - vim 에디터로 로그 메시지를 수정 +- branch의 upstream이란? + - upstream : 물줄기가 위에서 밑으로 내려올 때, 그 위에서 원천이 되는 source + - ![upstream, orgin](https://velog.velcdn.com/images/rkio/post/013929f9-e277-48d7-bd6d-0bae04291209/image.png) + - git push --set-upstream : 위계 질서를 정립하기 위해서 origin을 main 브랜치의 upstream으로 설정하는 명령어 + - == git push -u origin main + - 매번 -u를 할 필요없이 처음 push에만 해주면 된다. +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. + - fork + - 다른 사람의 레포지토리에서 어떤 부분을 수정하거나, 추가 기능을 넣고 싶을 때 사용한다. + - fork 한 저장소는 원본 레포지토리(내가 연결한 레포지토리)와 연결되어 있다. + - clone + - 원본 레포지토리의 내용을 내 로컬 레포지토리로 완전히 복사한다. + - clone한 프로젝트는 원본 레포지토리의 로그를 볼 수 없다. + - 원본 작업의 변화를 알고 싶거나 원본 작업을 수정해서 반영하고 싶다면 fork, 단순히 원본의 코드를 복사해서 작업하는 것이라면 clone +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 + - git pull + - 원격 서버에서 최신 커밋들을 내려받아서 현재 로컬 브랜치와 자동 병합 + - pull 자동 병합이 문제가 발생할 때, fetch 방식을 사용해야 한다. + - git fetch + - 원격 저장소에서 커밋된 코드를 임시 브랜치로 다 내려받고, merge 명령어를 이용해서 수동 병합한다. + - 현재 브랜치와 자동 병합 X +- `reset --hard`와 `push/pull --force`의 적절한 사용법 + - git reset --hard + - 파일과 커밋 모두 명시된 시점으로 돌리는데, 파일을 되돌릴 수 없다. + - soft: uncommit changes, changes are left staged (index). (과거로 돌아가서 Staging Area도 현재와 같이 유지하고 싶을 때. git add 안해도 돼서 편하네) + - mixed (default): uncommit + unstage changes, changes are left in working tree. (과거 시점으로 돌아가고 Staging Area에 있는 파일도 모두 제거하고 싶을 때. git add도 내가 다시 할래) + - hard: uncommit + unstage + delete changes, nothing left. (현재의 코드, 커밋에 미련없이 과거로 돌아가고 싶을 때. 현재에 미련없음. 나 돌아갈래.) + - push --force + - 원격 저장소와 호환이 되지 않아 오류가 생겼을 때, 원격 저장소의 내용이 로컬 저장소의 내용과 일치하도록 원격 저장소의 내용들을 강제로 덮어쓰게 하는 명령어 + - 사용을 지양하라 + - 변경된 내용들을 현재 사용자 이외에는 pull 할 경우가 없을 때(원격 저장소를 혼자서 사용할 때) 사용하는 것이 좋다. + - pull --force + - local이 날라가도 괜찮을 때 +- `.gitignore` 사용법 + - git init 을 한 폴더에 .gitignore 이라는 이름으로 파일을 하나 만든다. + - 그 안에 한 줄씩 제외할 파일 혹은 폴더 이름을 쓴다. +- 브랜치 이름은 `parent/child-1`, `parent/child-2`는 가질 수 있지만 `parent`, `parent/child`는 가질 수 없다. 무슨 이유 때문인지. + - 슬래시로 계층적인 구조로 만들어서 사용할 수 있는데 + - parent를 생성한 후 parent/child를 생성하면 브랜치가 아닌 child라는 파일이 생성된다. +- 리포지토리의 두 타입인 bare, non-bare + - bare repository + - (벌거 벗은) + - 작업 공간이 없고 변경 사항만 추적하는 저장소 + - git init --bare + - non-bare repository + - git clone, git init을 하게 되면 기본적으로 생성되는 repository + - 작업 공간을 함께 생성 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. \ No newline at end of file diff --git a/git-basics/19th/README-LeeJisu.md b/git-basics/19th/README-LeeJisu.md new file mode 100644 index 0000000..fec73f9 --- /dev/null +++ b/git-basics/19th/README-LeeJisu.md @@ -0,0 +1,113 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. +### git +- 오픈 소스 '버전 관리' 시스템 +- local에서 버전 관리 +- branch 생성 및 이전 branch로 복구, 삭제, 병합 가능 +- 로컬 저장소를 사용하기 때문에 **다른 개발자와 실시간으로 작업 공유 불가능** +### github +- git repository를 위한 웹 기반 '호스팅' 서비스 +- 클라우드 서버를 사용해서 local에서 버전 관리한 소스 코드를 업로드하여 **공유 가능** + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. +### Working Directory +개발하는 위치(=어떤 프로젝트를 진행할 때 그 프로젝트가 위치하고 있는 공간)이다. +### Staging Area +commit을 수행할 대상 파일들이 위치하는이다. Working directory에 존재하는 파일을 'git add [파일명]'을 통해서 Staging Area으로 위치시킨다. +### Local Repo +로컬에 존재하는 Git directory(.git 폴더)로, 프로젝트의 메타 데이터나 commit 등의 정보가 저장되는이다. +### Remote Repo +실제 Github에 존재하는 Repository이다. + +### Git Add +다음 변경(commit)을 기록할 때까지 변경분을 모아놓는 작업이다. +### Git Commit +Staging Area에 저장되어 있는 변경 사항들을 로컬저장소에 등록하는 것이다. => 변경사항 확정 +### Git Push +commit된 파일들을 원격(remote) 저장소에 모두 업로드하는 것이다. + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. +### branch +branch는 독립적으로 어떤 작업을 진행하기 위한 개념이다. 필요에 의해 만들어지는 각각의 branch는 다른 branch의 영향을 받지 않기 때문에 여러 작업을 동시에 진행할 수 있다. 다른 branch와의 병합(Merge)을 통해 작업한 내용을 다시 새로운 하나의 branch로 모을 수도 있다. +- 생성 : git branch [브랜치명] +- 삭제 : git branch -D [브랜치명] +- 이동 : git checkout [브랜치명] +- 생성 + 이동 : git checkout -b [브랜치명] + +### HEAD +HEAD는 현재 checkout된 branch의 '가장 최신' commit을 가리킨다. 따라서 branch를 변경하게 되면 변경한 branch의 가장 최신 commit을 가리키게 된다. + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +### git init +기존 프로젝트에 git을 초기화하는 명령으로, 로컬 저장소가 생기며 원격 저장소에 대한 정보(remote)는 없다. + +### git clone +반대로 'git clone'은 원격 저장소의 정보를 불러와 로컬 저장소를 생성하는 것이기 때문에 원격 저장소에 대한 정보가 있다. + +### origin +원격 저장소를 의미한다. + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. +### git reset –hard +- Working Directory와 Staging Area 모두 초기화 + +### git reset –mixed +- Working Directory 변경 X +- Staging Area 초기화 O + +### git reset –soft +- Working Directory와 Staging Area 모두 변경 X + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. +### Pull Request +사용자가 원격 저장소에 push하여 새로운 사항이 적용됐을 경우, 이를 다른 사용자에게 알리는 것을 말한다. + +### Merge +git branch를 다른 branch로 합치는 것이다. +- Fast-Forward : +- 3-way Merge : + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push/pull --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 `parent/child-1`, `parent/child-2`는 가질 수 있지만 `parent`, `parent/child`는 가질 수 없다. 무슨 이유 때문인지. +- 리포지토리의 두 타입인 bare, non-bare + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. \ No newline at end of file diff --git a/git-basics/19th/README-parkjunhyeong.md b/git-basics/19th/README-parkjunhyeong.md new file mode 100644 index 0000000..ff53d69 --- /dev/null +++ b/git-basics/19th/README-parkjunhyeong.md @@ -0,0 +1,141 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +# git +git은 본인의 코드와 그 수정내역을 기록하고 관리하도록 돕는 버전 관리 프로그램이다 로컬에서 프로젝트의 기록을 스스로 +관리할 수 있도록 해준다 git을 통해 브랜치를 생성하고 이전 브랜치로 복구, 삭제 병합이 가능하다 하지만 +로컬 저장소를 사용하기 때문에 다른 개발자와 실시간으로 작업을 공유할 수 없다 + +# git hub +gihub는 git 저장소를 관리하는 클라우드 기반 호스팅 서비스이다 git 저장소 호스팅 서비스는 클라우드 기반으로 다른 +사람과 소스코드 공규가 가능하며 git의 기본적인 기능을 확장하여 제공한다. +github같은 클라우드에 저장하는 git을 remote git이라고 부른다. + + + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +## git 동작 + +working directory는 작업 공간으로 아직 git에 기록될 준비가 되지 않은 파일들이 위치하는 공간
+Staging Area는 대기 공간으로 Git에 기록될 준비가 된 파일들이 위치하는 공간
+Logal Repository는 .git폴더이다.
+Remote Repository는 원격 저장소이다 github라고 생각하면 된다.
+git add를 하면 Staging Area에 올라간다. 여기서 git commit을 하면 Local Repository에 저장된다 commit만 하면 자신의 컴퓨터 자체에만 기록되고 Remote Repository에는 저장이 안된다
+push를 해주면 Remote Repository에 저장이 된다.
+ + + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +**브랜치란** 독립적으로 어떤 작업을 진행하기 위한 개념 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있다. +여러명이 동식에 작업을 할 때 다른 사람의 작업에 영향을 주거나 받지 않도록, 메인 브랜치에서 자신의 작업 전용 브랜치를 만들고 각자 작업을 진행한 후 작업이 끝난 사람은 메인 브랜치에 자신의 브랜치의 변경 사항을 적용한다. +**HEAD란** 해당 브랜치의 마지막 커밋을 뜻한다. +``` +git checkout -b test 는 test 브랜치를 생성후 바로 test브랜치로 이동 +git checkout main은 main브랜치로 이동하고 +git branch -d test를 하면 test 브랜치를 삭제한다. +``` + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +**git init**을 하면 .git이라는 하위 디렉토리를 해당 디렉토리 위치에 만든다. +init은 아직 버전관리를 하지 않은 로컬 디렉토리 하나를 선택해서 Git저장소를 적용하는 방법이다 +`사용법 : git init` +**git clone**이란 이미 만들어진 git 저장소를 복사하고 싶을 때 사용한다 저장소로 부터 프로젝트를 복제한다. +`사용법 : git clone <저장소 위치>` + +**origin**이란 원격 저장소의 이름을 뜻한다. +`git remote add origin <주소>` + + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +## git reset +**git reset**은 과거의 commit으로 돌아가고 이후의 커밋은 삭제하는 명령어 이다.
+`git reset-hard : 해당 커밋ID의 상태로 이동하고, Working Directory와 index영역 모두 초기화`
+`git reset-mixed : 해당 커밋ID의 상태로 이동하고, Index영역은 초기화되고 Working Directory는 변경되지 않음`
+`gir reset-soft : 해당 커밋ID의 상태로 이동하고 Index영역과 Working Directory 모두 변경되지 않고 commit된 파일들을 staging area로 돌려놓는다.`
+ +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. + +**pull request**는 저장소를 fork한 뒤, 포크한 저장소에서 변경 사항을 가지고 원래 저장소의 소유자에게 병합 해달라고 요청하는 것이다. + +여기서 fork는 다른 사람의 깃허브 저장소에서 내 깃허브 저장소로 그대로 복제하는 기능이다. +fork한 저장소는 원본 저장소와 연결되어 있다. 연결 되어 있다는 의미는 original repository에서 새로운 commit이 생기면 이는 그대로 forked된 repository로 반영할 수 있다. 이 때 fetch나 rebase의 과정이 필요하다. + +**Merge**란 git branch를 다른 branch로 합치는 과정이다.
+### Fast Forward Merge +커밋이 생기지 않고 현재 브랜치의 HEAD가 대상 브랜치의 HEAD까지로 옮기는 merge이다 +어떤 경우에 사용 할까? +예로 들자면 master vranch에서 새로운 브랜치 하나를 생성 한 후에 master branch는 더이상 커밋하지 않고, 생성된 +브랜치에서만 커밋을 하는경우 merge하면 master브랜치의 Head가 새로운 브랜치 Head commit 이후로 이동된다. + +### 3 way merge +병합하려는 두개의 브랜치의 공통 조상을 base로 두고 base와 다른 두개를 비교하며 충돌하거나 병합 시켜준다. + +![스크린샷 2023-08-13 012841](https://github.com/ApptiveDev/study-git/assets/64734115/e914759d-155a-43d8-ba54-1126b10cb266) + +1. 위 사진에서 Base를 기준으로 Me와 other을 비교한다 A는 Me와 base가 같으므로 수정된 Other을 사용해서 자동으로 삭제 시켜주고 +2. B는 셋다 같으므로 B +3. C는 Me와 other,base다 다르므로 충돌 +4. D는 Base와 Other이 같고 Me에서만 다르므로 병합할 때 D코드는 삭제한다 + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +**rebase**란 말 그대로 재설정한다는 의미로, 하나의 브랜치가 다른 브랜치에서 파생되서 나온 경우, 다른 브랜치에서 진행된 커밋을 다시 가져와서 base를 재설정하는 것이다. 새로운 커밋을 기반으로 작업을 함으로써 파생된 브랜치는 병합시에 conflict없이 자신의 브랜치에 진행된 커밋을 반영할 수 있다. +### rebase의 장점 + 커밋 히스토리가 시간순서대로 반영되어 시간순서대로 관리하거나 merge를 통해 발생하는 불필요한 병합 커밋을 제거할 때 사용하면 좋다. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +### stash란 +자신이 어떤 작업을 하던 중에 다른 요청이 들어와서 하던 작업이 완료되지 않앗지만 잠시 멈추고 다른 브랜치로 변경할 일이 있으면 완료되지 않은 일을 commit하기엔 껄끄러울 때 잠시 스택에 저장할 수 있도록 하는 명령어이다.
+`git stash 또는 `
+`git stash save를 하면 된다.`
+`git stash list를 하면 stash 목록을 확인할 수 있다.`
+`git stash apply를 가장 최근의 stash를 가져와 적용한다.`
+`git stash apply [stash 이름] 해당 stash를 적용한다.`
+`git stash drop 가장 최근의 stash를 제거한다.`
+`git stash drop [stash 이름] 해당 stash를 제거한다.`
+ +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push/pull --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git "a/git-basics/19th/README-\352\271\200\353\257\274\354\232\261.md" "b/git-basics/19th/README-\352\271\200\353\257\274\354\232\261.md" new file mode 100644 index 0000000..86154ff --- /dev/null +++ "b/git-basics/19th/README-\352\271\200\353\257\274\354\232\261.md" @@ -0,0 +1,278 @@ +# Git 기초 + +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github + +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +**개인 컴퓨터에서 사용하는 git을 local git이라 부르며, github나 gitlab과 같은 클라우드에 저장하는 git을 remote git이라고 한다.** + +### Git + +git은 본인의 코드와 수정내역을 기록하고 관리하는 버전 관리 프로그램으로 로컬에서 프로젝트의 기록을 스스로 관리할 수 있도록 해줌
+git을 통해 브랜치 생성, 삭제, 복구, 병합이 가능하지만 로컬 저장소를 사용하기 때문에 협업시 사용이 불가능함 + +### GitHub + +github는 git저장소를 관리하는 호스팅 서비스로 다른 사람과 소스코드 공유가 가능하며 한 프로젝트에 여러 명의 사람이 참여하여 버전 제어 및 공동 작업이 가능하다.
즉, git으로 관리하는 프로젝트를 올려둘 수 있는 사이트로 github외 gitlab, bitbucket 등 여러가지 사이트가 있다. + +## Git Workflow + +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +### Working Directory + +사용자의 현재 작업 공간으로 실제 파일을 수정하거나 생성하는 공간 + +- 2가지 상태 + +1. untracked - 아직 tracking이 되지 않은 파일 : 새로 생성한 파일이거나 변경된 상태가 없는 파일 +2. tracked - unmodified/modified로 나눌 수 있음 : modified는 수정사항이 있지만 스테이지 영역으로 옮겨지지 않은 파일로 modified된 파일만 스테이징 영역으로 갈 수 있다. + +### Git Add + +Working Directory상의 변경 내용을 스테이징 영역에 추가한다. + +### Git Commit + +현재 버전의 코드(스테이징 되어 있는)를 로컬 저장소에 기록한다. + +### Git Push + +로컬 저장소에 저장된 변경 이력을 원격 저장소에 반영한다. + +## Branch, HEAD + +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +### Commit + +git에서 commit은 프로젝트의 현재 스테이징된 변경 사항의 스냅샷을 캡처한 것이다. + +### branch + +branch는 독립적으로 특정 작업을 진행하기 위해 하나의 버전에서 분기되어 생성된 것으로 여러 작업을 동시에 진행 할 수 있게 한다. + +- branch 생성 + git branch [branch 이름] + git checkout -b [branch 이름] +- branch 삭제 + git branch -d [branch 이름] +- branch 이동 + git checkout [branch 이름] + +### HEAD + +모든 branch에는 HEAD가 존재하는데, HEAD는 해당 브랜치의 마지막 commit을 가리킨다. + +## clone, init, origin + +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. + +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +
+ +**git 저장소 생성 방법에는 git init과 git clone이 있음** + +### git init + +현재 디렉토리를 git local 저장소로 설정하는 명령어
+local -> remote 방향
+이용 방법: git으로 관리하기를 원하는 디렉토리에서 $git init + +### git clone + +이미 만들어진 remote 저장소를 들고오는 명령어
+remote -> local로 git repository를 복제해온다.
+이용 방법: $git clone [로컬 저장소 경로] + +### origin + +origin은 원격 저장소의 경로 이름을 의미한다.
+git remote add origin [url]형식으로 원격 저장소를 추가하거나
+git clone을 통해 원격저장소를 복사하면 자동으로 origin이라는 이름의 원격 저장소가 등록된다. + +## reset + +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +**사용법: $ git reset [commitId]** + +### --hard + +해당 commitId의 상태로 이동하고, **Working Directory와 스테이징 영역을 모두 초기화**한다. 해당 commitId 이후의 모든 내용을 지운다. + +### --mixed + +해당 commitId의 상태로 이동하고, **스테이징 영역은 초기화되고 Working Directory는 변경되지 않는다.** 즉 **git add가 실행되기 직전의 상태**로 돌아간다. + +### --soft + +해당 commitId의 상태로 이동하고, **스테이징 영역과 Working Directory모두 변경되지 않는다.** 즉 **git add가 실행된 직후의 상태**로 돌아간다. + +## Pull Request, Merge + +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. + +### Pull Request + +Pull Request란 다른 사용자가 작성한 저장소에서 변경 사항을 병합(merge)하기 위한 요청을 의미한다. + +Pull Request는 다음과 같은 기능을 제공한다. + +- 원본 저장소 소유자에게 코드 변경 사항을 알린다. +- 변경 사항의 리뷰를 받는다. +- 코드 변경 사항이 다른 사람들과 공유될 수 있다. + +### Merge + +git branch를 다른 branch로 합치는 과정이다. + +1. Fast Foward Merge
+ 가장 기본적인 merge로 현재 branch의 HEAD를 대상 branch의 HEAD까지 옮기는 merge이다.
+ 사용 방법:
+ git switch [현재 branch]
+ git merge [대상 branch] + ![Alt text](images/image.png) + 사진의 bugfix 브랜치의 이력은 master branch의 이력을 모두 포함하고 있기 때문에 master branch 상태가 변경되어 있지 않으면 master branch는 단순히 이동하기만 해도 bugfix branch의 내용을 적용할 수 있다. + ![Alt text](images/image-1.png) + + 하지만 bugfix branch로 분기한 후에 master branch에 여러 변경 사항이 적용되는 경우 master branch의 변경 내용과 bugfix branch의 변경 내용을 하나로 통합해야 한다. + ![Alt text](images/image-3.png) + 따라서 양쪽의 변경을 가져온 merge commit을 실행하게 된다. (이게 3-Way-Merge로 진행되는 것인가...?) + ![Alt text](images/image-4.png) + + 만약 두 branch가 같은 부분을 수정했다면 conflict가 생기게 되는데
+ ![Alt text](images/image-2.png)
+ conflict를 해결하기 위해 변경 사항을 잘 반영해서 commit을 해주어야 한다. + +2. 3-Way Merge
+ merge할 때 각 branch의 마지막 commit과 branch의 공통 조상(base) commit 총 3개의 commit을 비교하여 새로운 commit을 만들어 병합을 수행한다.
+ 하나의 branch와 다른 branch의 모든 변경 이력을 합치는 방식으로 진행된다.
+ base를 기준으로 변경사항이 있는 파일들을 merge commit에 반영한다. 만약 두 commit 모두에서 변경사항이 발생하여 충돌이 발생하면 충돌을 해결한 후 commit 해주면 된다. + +## rebase + +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +Git에서 한 branch에서 다른 branch로 합치는 방법은 Merge와 Rebase가 있다.
+Rebase는 두 개의 공통 base를 가진 branch에서 한 branch의 base를 다른 branch의 최신 commit으로 base를 옮기는 작업이다.
+Merge와 Rebase의 실행 결과는 같지만 commit 히스토리가 달라진다.
+Merge는 쉽고 안전하지만 commit 히스토리가 지저분할 수 있다. Rebase를 사용하면 commit 히스토리를 깔끔하게 관리할 수 있다. 특히 분기한 branch가 많을수록 commit 히스토리를 심플하게 유지하여 commit 추적을 용이하게 한다.
+ +Rebase의 위험성 +사람들이 사용하고 있는 commit을 Rebase하면 문제가 생긴다.
+push하기 전에 로컬에서만 rebase를 사용하자. + +## stash + +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +**하던 작업을 스택에 임시로 저장하고 나중에 다시 꺼내올 수 있다.** + +어떤 작업을 하던 중 다른 요청이 들어와 작업을 멈추고 브랜치를 변경해야 하는데 아직 완료되지 않은 경우 commit을 하지 않고 stash를 사용할 수 있다. (checkout을 하기전에 꼭 commit을 해야하기 때문)
+ +사용 방법 + +- $ git stash: 변경 내용 임시 저장하기 +- $ git stash list: stash한 list 보기 +- $ git stash apply: 가장 최근 stash 가지고 오기 +- $ git stash apply [stash 이름]: 특정 stash 가지고 오기 +- $ git stash drop: 가장 최근 stash 지우기 +- $ git stash drop [stash 이름]: 특정 stash 지우기 +- $ git stash clear: stash 모두 지우기 +- $ git stash pop: 가장 최근 stash를 적용하고 동시에 stack에서 지우기 (apply + drop) +- $ git stash pop [stash 이름]: 특정 stash를 적용하고 동시에 stack에서 지우기 (apply + drop) +- $ git stash save [stash 이름]: stash 이름 지정하여 저장하기 + +## Advanced + +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. + +- `git rebase --interactive`란?
+ + 불필요한 commit 이력을 제거하여 commit 추적을 용이하게 한다.
+ +- branch의 upstream이란? (`git push --set-upstream`)
+ + upstream은 local 저장소와 연결된 remote 저장소를 의미한다.
+ $ git push --set-upstream A B: 로컬 A 저장소의 원격 저장소를 B로 지정하여 B에 push + +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지.
+ + fork를 하면 원본 저장소의 복사본이 만들어지고 복사본에서 작업을 하기 때문에 branch를 새로 만들지 않고 master에서 작업이 가능하다.
+ 원본 저장소에 변경분을 반영하기 위해 PR을 요청하고 승인되면 원본 저장소에 기여자로 등록된다.
+ +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지
+ + fetch는 원격 저장소에 변경사항이 있는지 확인만 하고 변경된 데이터를 로컬로 가져오지 않음 - 원격 저장소에서 commit된 코드를 임시 branch로 모두 내려받은 후 해당 branch로 checkout하여 변경된 내용을 확인, Working Directory에 변화X
+ pull은 원격 저장소에서 변경된 메타데이터 정보 확인과 최신 데이터를 복사하여 로컬로 가져옴. (fetch + merge)
+ +- `reset --hard`와 `push/pull --force`의 적절한 사용법
+ + **push -f**
+ 원격 저장소의 내용을 로컬 저장소의 내용과 일치하도록 강제로 덮어쓴다. 원격 저장소에 저장된 commit 내용 중 일부가 유실될 수 있음.
+ 적절한 사용법 + + - 덮어쓰기 하려는 변경사항을 현재 사용자 외에 다른 사람들이 pull하지 않은 경우
+ - push -f를 수행한 이후, 모든 사용자로 하여금 pull하여 변경 사항을 새로운 버전으로 재적용하기로 합의가 된 경우
+ - -force-with-lease 옵션 사용 : 덮어쓰기 하기 전 수정사항이 없을 때만 덮어쓰기가 수행된다.
+ + **pull -f**
+ 로컬 branch의 변경 사항을 무시하고 원격 저장소의 최신 변경사항으로 로컬 branch를 강제로 업데이트하는데 사용
+ + **reset --hard를 사용하여 덮어쓰기와 같은 효과를 만들 수 있다**
+ + 1. git fetch --all : git pull 받을 목록을 저장소에서 업데이트
+ 2. git reset --hard origin/[작업중인 branch 이름]: git reset --hard로 head를 최신 버전으로 가리킨다
+ 3. git pull
+ +
+ +- `.gitignore` 사용법
+ + git에 추가되지 말아야 할 파일을 정의한다.
+ [folder name]/ : 특정 폴더에 있는 전체 파일 무시
+ \*.[확장자] : 특정 확장자 전체 무시
+ [디렉터리명]/[파일명] : 특정 파일 무시
+ +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지.
+ + git은 파일시스템과 유사한 계층 구조를 가지고 있다.
+ branch는 파일로 존재하는데, 만약 parent/child인 branch가 있고, parent인 brach를 생성하려고 한다면 parent라는 파일이 생성되어야 하는데 디렉토리 이름과 겹치기 때문에 생성할 수 없다. + +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지 + **detached HEAD**
+ https://devcamus.tistory.com/6 - 그림으로 이해하기 쉬운 설명이 있어서 참조하였습니다.
+ head가 branch로부터 떨어져 있는 상태를 뜻한다. branch를 통해서가 아니라 head가 직접 commit을 참조하고 있는 상태.
+ (보통 attacehd 상태이면 head -> branch -> commit의 참조 순서를 가진다.)
+ git checkout [revision number]명령어를 사용해, 특정 commit으로 checkout하여 head가 변경된 경우 detached head 상태가 된다.
+ + **detached HEAD상태에서 commit**
+ detached HEAD 상태에서 commit을 하면 어떤 branch도 commit을 가리키지 않으므로 branch로부터 분리된 상태로 남게된다.
+ 이 commit에 접근하기 위해서 git branch -f [branch 명] HEAD 와 같이 branch를 HEAD가 가리키는 commit으로 강제 이동시키고 git checkout [branch 명]을 하여 head가 해당 branch를 참조하게끔 checkout 해주면 된다.
+ 즉, 핵심은 head -> branch -> commit의 참조 순서를 만들어주면 된다!
+ +## Questions + +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. + +git에 대해 잘 모르고 있다는 것을 느낄 수 있었다.
+특히 Rebase부분은 아직 잘 이해가 안된 것 같다. 스터디를 진행하면서 더 이해를 해봐야겠다. diff --git "a/git-basics/19th/README-\354\235\264\354\204\270\355\230\225.md" "b/git-basics/19th/README-\354\235\264\354\204\270\355\230\225.md" new file mode 100644 index 0000000..da2fc3b --- /dev/null +++ "b/git-basics/19th/README-\354\235\264\354\204\270\355\230\225.md" @@ -0,0 +1,237 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +> git은 로컬 소스코드의 버전 관리 시스템이다. github은 git으로 관리하는 소스코드를 업로드하여 +> 다른 사용자와 공유할 수 있는 원격 저장소이며, PR, Fork, Clone 등 협업에 필요한 기능을 제공하는 서비스이다. + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +> __Working Directory__: 현재 작업 중인 로컬 git 프로젝트의 디렉토리 +> __Staging Area__: commit 이전에 변경 사항을 임시로 저장하는 공간. +> +> __Local Repo__: 사용자의 개인 컴퓨터에 위치한 git 저장소. +> +> __Remote Repo__: 원격 서버에 위치한 git 저장소. +> +> __Git Add__: Working Directory에서 변경 사항이 있는 파일들을 commit 이전에 Staging Area에 추가하는 것. +> +> __Git Commit__: Staging Area에 추가된 변경 사항을 Local Repo에 영구적으로 저장하는 것. 변경 사항을 저장하는 하나의 기본 단위이다. +> +> __Git Push__: Local Repo의 commit을 Remote Repo에 업로드하는 것. +> +> __Git Pull__: Remote Repo의 최신 commit들을 Local Repo에 불러와 변경 사항을 합치는 것. + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +> __commit__ 은 프로젝트의 변경 사항을 저장하고 관리하는 기본 단위. 현재 작업 중인 커밋의 지시자를 HEAD라고 한다. +> __branch__ 는 코드의 특정 commit을 가리키는 지시자이자, 배포 가능한 코드의 안정성을 유지하면서 독립적인 개발 흐름을 만들 수 있도록 해준다. +> +> 프로젝트를 진행하던 도중 새로운 기능을 만들어야 하는 경우를 가정해보자. +> 기존 프로젝트에 새로운 기능을 추가하려면, 배포 가능한 현재 코드와 독립된 개발 흐름을 만들기 위해 브랜치를 생성해야 한다. +> feature/new-feature (이하 feature 브랜치) 이라는 이름의 브랜치를 생성하려면 Working Directory에서 해당 명령을 실행하면 된다. +> ```bash +> git branch feature/new-feature +> ``` +> 브랜치를 생성했다면, master브랜치가 아닌 new-feature 브랜치에 변경 사항(커밋)을 저장하기 위해 feature 브랜치로 이동해야 한다. +> 아래 명령어를 통해 feature 브랜치로 이동할 수 있고, 이동한 시점 이후의 커밋은 모두 feature 브랜치에 쌓인다. +> ```bash +> git checkout feature/new-feature +> ``` +> +> 위의 과정을 한 번에 통합할 수도 있다. +> ```bash +> git checkout -b feature/new-feature +> ``` +> 새로운 기능이 완성되고 변경사항을 모두 커밋했다면, 안정성 테스트를 거친 후 master 브랜치로 다시 돌아와 feature 브랜치와 병합하여 +> 변경 사항을 적용할 수 있다. +> +> ```bash +> git checkout master(main) +> git merge feature/new-feature +> ``` +> 위 명령어가 실행되면 HEAD에 해당하는 feature 브랜치의 모든 변경사항이 master브랜치에 적용된다. +> 기능구현이 모두 끝난 후 생성했던 브랜치를 삭제할 수 있다. 이는 권장 사항이며 필수는 아니다. +> +> ```bash +> git branch -d feature/new-feature +> ``` + + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +> __git init__ 은 현재의 디렉토리를 git 레포로 초기화하는 것이다. +> 주로 빈 git 프로젝트를 새로 생성하거나 기존의 프로젝트를 git을 사용하여 관리하고 싶을 때 사용한다. +> +> __git clone__ 은 이미 존재하는 원격 git 레포를 복제하여 로컬에 저장하는 것이다. 이때의 원격 저장소를 origin이라고 하고, +> origin은 git clone 명령어를 실행한 시점에 자동으로 설정된다. +> +> origin이 지정되지 않은 로컬 저장소의 경우 아래 명령어로 프로젝트에 origin을 추가할 수도 있다. +> ```bash +> git remote add origin <원격 레포 url> +> ``` +> +> 또는 기존에 존재하던 origin이 다른 url을 가리키도록 변경할 수도 있다. +> ```bash +> git remote set-url origin <새로운 원격 리포지토리 url> +> ``` +> +> 변경 사항을 조회하려면 `git remote -v` 명령어를 사용할 수 있다. + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +> git reset 명령어는 기본적으로 HEAD를 특정 커밋으로 이동시키는 명령어이다. +> +> ```bash +> git reset [] [] +> ``` +> git reset의 mode 인자에는 세 가지 값이 들어갈 수 있는데, --hard, --soft, --mixed이다. +> 지정되지 않은 경우 기본값으로 --mixed가 적용된다. +> commit 인자는 이동하려는 커밋 식별자(커밋 해쉬, 브랜치, 태그 이름)를 값으로 가진다. 기본값은 HEAD이다. +> +> `--soft`는 HEAD를 지정된 커밋으로 이동시켜 현재 작업중인 커밋을 해당 커밋으로 설정하지만 Staging Area와 Working Directory의 +> 변경사항은 그대로 남는다. 예를 들어, HEAD A라는 시점으로 --soft 모드를 사용하여 이동한 경우 A 이후의 변경 사항이 Staging Area에 올라간 +> 상태가 되고, 그 상태에서 커밋할 경우 A 시점 이후의 커밋들이 하나로 합쳐지게 된다. +> +> `--mixed`는 HEAD와 Staging Area를 지정된 커밋으로 이동시키지만 Working Directory의 변경사항은 그대로 유지된다. 따라서 +> Working Directory의 변경사항은 Unstaged 상태가 된다. +> +> `--hard`는 HEAD와 Staging Area, Working Directory를 모두 지정된 커밋의 상태로 이동시킨다. 로컬에서 지정된 커밋 이후의 +> 모든 변경 사항은 삭제된다. + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. + +> __Pull Request__ 는 하나의 브랜치에 다른 브랜치를 병합(Merge) 하기 위해 요청하는 기능이다. 주로 Github, GitLab등의 서비스에서 제공하는 +> 기능이다. +> +> __Merge__ 는 서로 다른 두개의 브랜치를 합치는 것이다. Fast-Forward Merge, 3-Way Merge라는 병합 방식이 사용된다. +> +> __Fast-Forward__ 는 기존 브랜치보다 병합하려는 브랜치의 커밋이 더 앞서는 경우 사용되는 방식으로, 별도의 병합 커밋이 생성되지 않고 +> 변경 사항이 그대로 브랜치에 적용된다. +> +> 3-Way Merge는 병합하려는 두 브랜치에서 특정 시점 이후로 서로 다른 변경사항이 발생한 경우 사용하는 병합 방식이다. +> 가장 최근의 _공통된_ 커밋을 기준으로 두 브랜치의 변경 사항을 비교하여 병합된 하나의 새로운 커밋을 생성한다. +> 두 브랜치에서 서로 같은 파일의 같은 라인을 다르게 수정했거나, 한 브랜치에서 삭제한 파일을 다른 브랜치에서 수정한 경우에는 충돌이 발생하게 된다. +> +> 충돌이 발생한 경우 git은 병합을 중지하고 개발자에게 수정을 요청한다. Staging 영역에 수정이 완료된 파일을 올리고 commit하면 병합 과정이 완료되고 +> 병합 커밋이 생성된다. + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +> __rebase__ 는 한 브랜치의 커밋을 다른 브랜치 위로 적용하는 과정이다. merge의 경우 변경사항이 한 번에 통합되지만, rebase는 +> 변경 사항까지의 커밋 내역이 대상 브랜치의 최신 커밋 위에 순차적으로 적용된다. +> +> a라는 브랜치를 생성하여 로컬에서 작업하던 도중 다른 브랜치인 b에서 변경 내용이 발생했고 a 브랜치에 적용해야 하는 경우, +> rebase 명령어를 통해 로컬의 작업 내용을 유지한 채로 b 브랜치의 커밋을 하나씩 적용할 수 있다. +> +> 위에서 설명한 Merge와 마찬가지로 충돌이 발생할 수 있다. Merge의 경우 두 브랜치를 병합하는 도중 한 번만 충돌이 발생하지만, Rebase의 경우 +> 순차적으로 커밋을 검토하므로 충돌이 여러 번 발생할 수 있다. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +> git stash는 Git에서 제공하는 임시 저장 기능으로, Staging Area와 Working Directory에 저장된 변경 사항을 임시로 저장하고 +> HEAD 상태로 되돌리는 기능이다. +> +> 이 기능은 특정 브랜치에서 작업하던 도중 다른 브랜치로의 전환이 필요한 경우 유용하게 쓰일 수 있다. +> 가령 a 브랜치에서 작업하던 도중 b 브랜치에서 수정해야 할 부분이 생긴 경우, a의 변경 사항을 stash로 임시 저장하고 +> b 브랜치로 이동해서 작업할 수 있다. 작업이 끝나면 a 브랜치에서 stash를 통해 임시 저장된 내용을 복원하여 계속 작업할 수 있다. +> +> git stash : 현재의 변경 사항을 스택에 저장 +> git stash list: 저장된 stash 목록을 보기 +> git stash apply: 가장 최근에 저장된 stash의 변경 사항 적용. 적용된 stash는 스택에서 제거되지 않음 +> git stash pop: 가장 최근에 저장된 stash의 변경 사항을 적용하고 해당 stash를 스택에서 제거 +> git stash drop [stash@{n}]: 지정된 stash를 스택에서 제거 +> git stash clear: 스택에 존재하는 모든 stash 제거 +> git stash branch : 새로운 브랜치를 생성하고 해당 브랜치에 stash의 변경 사항 적용 + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push/pull --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 `parent/child-1`, `parent/child-2`는 가질 수 있지만 `parent`, `parent/child`는 가질 수 없다. 무슨 이유 때문인지. +- 리포지토리의 두 타입인 bare, non-bare + +### ChatGPT를 통해 생성한 답변을 바탕으로 이해한 내용 +> **`git rebase --interactive`:** +> - interactive rebase는 사용자가 커밋의 순서를 변경하거나, 커밋을 합치거나, 커밋을 삭제하거나, +> - 커밋 메시지를 수정하는 등의 작업을 수행할 수 있게 해주는 도구입니다. +> +> **branch의 upstream:** +> - 브랜치의 upstream은 로컬 브랜치가 추적하는 원격 브랜치를 의미합니다. `git push --set-upstream` (또는 `-u` 옵션)을 사용하여 +> 로컬 브랜치와 원격 브랜치 간의 추적 관계를 설정할 수 있습니다. +> +> > 원래라면 자동으로 origin/branch-1이라는 원격 브랜치와 branch-1이라는 로컬 브랜치가 연결되어 있지만, 자동으로 연결된 브랜치 외의 +> > 다른 브랜치로 변경 사항을 커밋하고 싶다면 upstream을 변경하면 되는 것 같다. 근데 안써봐서 와닿지는 않는다. +> +> **Fork와 PR:** +> - Fork는 다른 사람의 리포지토리를 자신의 계정으로 복사하는 것을 의미합니다. Fork는 원본 리포지토리에 직접적인 변경 권한이 없을 때 유용하며, +> - Fork한 리포지토리에서 변경 사항을 만든 후 원본 리포지토리에 Pull Request를 통해 변경 사항을 제안할 수 있습니다. +> +> > push/merge 권한이 없는 제 3자가 자신의 계정으로 레포를 복제하여 +> > 개발을 이어나갈 수 있도록 하는 중요한 기능이라고 알고 있다. +> +> **`git fetch` vs `git pull`:** +> - `git fetch`는 원격 리포지토리의 변경 사항을 로컬로 가져오지만 자동으로 병합하지 않습니다. +> > 궁금해서 찾아본 결과, git fetch로 가져온 변경 사항은 Staging area나 Working directory에는 영향을 주지 않고 +> > 로컬 레포의 원격 브랜치 참조에 저장된다고 한다. +> +> > 원격 브랜치 참조는 원격 레포의 상태를 로컬에서 추적하기 위해 있는 포인터라고 하는데 써본적이 없어서 왜 있는지 와닿지는 않는다. +> +> - `git pull`은 `git fetch`와 `git merge`의 조합으로, 원격 리포지토리의 변경 사항을 가져와서 자동으로 현재 브랜치에 병합합니다. +> - `git fetch`는 원격 변경 사항을 확인하고 싶지만 아직 병합하고 싶지 않을 때 사용됩니다. +> +> **`reset --hard`와 `push/pull --force`:** +> - `git reset --hard`는 HEAD, Staging Area, Working Directory를 특정 커밋 상태로 되돌립니다. +> - `--force` 옵션은 Git의 안전 장치를 무시하고 강제로 push나 pull을 수행합니다. 주의해서 사용해야 합니다. +> +> > `git reset --hard`는 특정 시점 이후의 모든 것이 완전히 잘못돼서 정말 복구할 수 없게 됐을 때 써본 경험이 있다. +> > 특정 커밋 이후의 모든 변경 사항이 사라지므로 주의해서 사용해야 한다는 것은 이미 알고 있었다. +> +> **`.gitignore`:** +> - `.gitignore` 파일은 Git이 추적하지 않아야 할 파일 또는 디렉토리 패턴을 지정하는 데 사용됩니다. +> +> > 변경 사항이 있는 모든 파일을 스테이징 영역에 추가하는 git add -A를 실행하더라도, .gitignore에 존재하는 패턴을 갖는 파일 또는 디렉터리는 +> > 스테이징 영역에 추가되지 않는다. +> +> > node로 채팅봇을 개발하던 도중 .gitignore에 node_modules 폴더를 깜빡하고 추가를 안 한 채로 모든 파일을 스테이징 영역에 추가한 후 +> > 커밋했다가 변경 사항에 파일 수백개가 있었던 경험이 있었다. 끔찍했다. +> +> **브랜치 이름 제한:** +> - `parent/child-1`와 같은 브랜치 이름은 가능하지만, `parent`와 `parent/child`를 동시에 가지는 것은 불가능합니다. +> - 이는 `parent`가 파일로도, 디렉토리로도 해석될 수 있기 때문에 혼란을 초래할 수 있습니다. +> +> **리포지토리의 두 타입: bare, non-bare:** +> - **bare 리포지토리**: 워킹 디렉토리가 없는 Git 리포지토리. 주로 서버에서 사용됩니다. +> - **non-bare 리포지토리**: 워킹 디렉토리가 있는 일반적인 Git 리포지토리. 개발자들이 일반적으로 사용하는 리포지토리 형태입니다. + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git a/git-basics/19th/images/image-1.png b/git-basics/19th/images/image-1.png new file mode 100644 index 0000000..6c55a1d Binary files /dev/null and b/git-basics/19th/images/image-1.png differ diff --git a/git-basics/19th/images/image-2.png b/git-basics/19th/images/image-2.png new file mode 100644 index 0000000..eec9eb4 Binary files /dev/null and b/git-basics/19th/images/image-2.png differ diff --git a/git-basics/19th/images/image-3.png b/git-basics/19th/images/image-3.png new file mode 100644 index 0000000..f2f5e60 Binary files /dev/null and b/git-basics/19th/images/image-3.png differ diff --git a/git-basics/19th/images/image-4.png b/git-basics/19th/images/image-4.png new file mode 100644 index 0000000..ebd31d7 Binary files /dev/null and b/git-basics/19th/images/image-4.png differ diff --git a/git-basics/19th/images/image.png b/git-basics/19th/images/image.png new file mode 100644 index 0000000..5c2d244 Binary files /dev/null and b/git-basics/19th/images/image.png differ diff --git a/git-basics/19th/images/img.png b/git-basics/19th/images/img.png new file mode 100644 index 0000000..f567d7c Binary files /dev/null and b/git-basics/19th/images/img.png differ diff --git a/git-basics/19th/images/img_1.png b/git-basics/19th/images/img_1.png new file mode 100644 index 0000000..28155ac Binary files /dev/null and b/git-basics/19th/images/img_1.png differ diff --git a/git-basics/19th/images/img_2.png b/git-basics/19th/images/img_2.png new file mode 100644 index 0000000..49a22f6 Binary files /dev/null and b/git-basics/19th/images/img_2.png differ diff --git a/git-basics/19th/images/img_3.png b/git-basics/19th/images/img_3.png new file mode 100644 index 0000000..a3420ad Binary files /dev/null and b/git-basics/19th/images/img_3.png differ diff --git a/git-basics/20th/README-ChaGiEun.md b/git-basics/20th/README-ChaGiEun.md new file mode 100644 index 0000000..7948302 --- /dev/null +++ b/git-basics/20th/README-ChaGiEun.md @@ -0,0 +1,134 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. +

+- local Repository : 개발자의 컴퓨터에서 작업되는 프로젝트 저장공간 +- remote Repository : 클라우드 서비스(ex)GitHub)를 통해 인터넷 서버에 저장된 공간 +
+*Git*은 주로 **로컬 컴퓨터**에서 작업할 때 사용됩니다. +사용자는 로컬 컴퓨터에서 Git을 사용하여 프로젝트의 변경 사항을 추적하고 관리할 수 있습니다. +Git을 사용하면 로컬 저장소를 생성하고, 변경 사항을 커밋하고, 브랜치를 만들고 병합하는 등의 작업을 수행할 수 있습니다. +
+*GitHub*은 **리모트 저장소**를 제공하여 여러 사용자가 소스 코드를 공유하고 협업할 수 있습니다. +사용자는 GitHub을 사용하여 리모트 저장소를 만들고, 다른 사용자와의 협업을 위해 변경 사항을 푸시하고 풀 리퀘스트를 만들 수 있습니다. + + + + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. +

+- **Working Directory**
+ - 사용자의 작업 공간으로써, 로컬 저장소에 접근할 수 있으며 실제 파일을 수정하거나 생성하는 공간입니다. + - 현재 작업 중인 소스코드들을 담고 있으며, 운영체제도 워킹 디렉토리 내부의 파일들만 접근하거나 수정할 수 있습니다. + - 작업 폴더에서 .git 디렉토리를 제외한 나머지 부분입니다. +- **Git Add**
+ - commit의 전단계입니다. + - commit을 하고자 하는 파일들은 commit하기 전에 add를 해줘야 commit 할 수 있습니다. +- **Git Commit**
+ - git에 저장하는 단계입니다. + - commit을 해주면 commit을 한 곳으로 언제든지 다시 돌아올 수 있기때문에 코드의 추가, 삭제가 자유로워집니다. +- **Git Push**
+ - git push를 하게되면 로컬 저장소에 있는 변경 이력이 원격 저장소에도 반영됩니다. + + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. +

+- commit은 Git 저장소(원격 저장소)에 우리의 디렉토리(로컬 저장소)에 있는 모든 파일에 대한 스냅삿을 기록하는 것입니다. +- branch는 그저 commit 노드를 참조하는 것입니다. +- HEAD란 현재 checkout된 브랜치의 마지막 commit에 대한 포인터입니다. +- git checkout은 branch 혹은 commit을 전환하거나, 내용을 되돌리는 기능을 합니다. + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 +

+- **git init과 git clone의 차이** + - git init : 빈 git 저장소를 만들거나 기존 저장소를 다시 초기화하는 명령어 + - git clone : git clone에 해당하는 저장소를 복제해 새 디렉터리로 가져오는 명령어
+-> git init은 프로젝트 자체를 처음부터 시작하는것이고, git clone은 프로젝트 내에 중간 투입이 가능하며 clone 시 inti을 다시 해줄 필요가 없습니다. +- **이용방법** + - git init + - git clone +- **origin** + - remote 저장소를 가리키는 별칭입니다. + - 새로운 프로젝트를 clone할 때 : git clone <원격 저장소 URL> <디렉토리 이름> + - 기존 저장소에 새로운 원격 저장소를 추가할 때 : git remote add origin <원격 저장소 URL> + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. +

+git reset은 HEAD의 위치를 현재 커밋에서 +1. 과거의 커밋으로 이동시킬 수도 있고 +2. 미래의 커밋으로 이동시킬 수도 있습니다. + +- **--soft--** + HEAD가 특정 커밋을 새롭게 가리키게 됩니다. 대신 현재 작업 중인 working directory와 staging area는 아무런 영향을 받지 않습니다. +- **--mixed--** + HEAD가 특정 커밋을 새롭게 가리키게 됩니다. 그리고 staging area도 해당 커밋의 모습과 동일하게 변합니다. 하지만 현재 작업 중인 working directory는 아무런 영향을 받지 않습니다. +- **--hard--** + HEAD가 특정 커밋을 새롭게 가리키게 됩니다. 그리고 staging area와 현재 작업중인 working directory도 해당 커밋의 모습과 동일하게 변합니다. + +*staging Area : 커밋을 하기 위해 $git add 명령어로 추가한 파일들이 모여있는 공간
+**working directory** --$git add--> **staging area** -- $git commit --> **repository** + + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. +

+- Pull Request : '코드를 수정했는데 당신도 코드를 수정했다면 제 수정한 내용도 적용시켜 주세요'라는 의미입니다. +- Merge : git branch를 다른 branch로 합치는 과정을 merge라 합니다. merge의 기본 단위는 브랜치이며, git merge 명령어로는 커밋 단위로 합치기가 불가능합니다. + - Fast-Forward : 현재 브랜치의 HEAD가 대상 브랜치의 HEAD까지로 옮기는 merge입니다. 대신 중간에 변경이 없을 때만 동작합니다. + - 3-Way Merge : 두 브랜치가 동일 선상이 아닐 때 3-way Merge가 발생합니다. 서로 다른 브랜치에 공통되는 base branch를 기점으로 충돌을 최소화 시키는 방법입니다. + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. +

+두개의 공통 Base를 가진 Branch에서 한 Branch의 Base를 다른 Branch의 최신 커밋으로 branch의 base를 옮기는 작업입니다. 용어 그대로 베이스를 다시 설정하는 작업입니다.
+Git에서 한 브랜치에서 다른 브랜치로 합치는 방법은 Merge와 Rebase입니다. Merge와 Rebase의 실행결과는 같지만 커밋 히스토리가 달라집니다. Merge는 쉽고 안전하지만 커밋 히스토리가 지저분할 수 있는 반면, Rebase는 잘 모르고 사용할 경우 위험할 수 있어 까다롭지만 커밋히스토리를 깔끔하게 관리할 수 있습니다. +
+공유 branch에 대한 최신 commit을 반영하면서 작업을 해야할 때 git rebase를 사용한다면 작업 branch에서 항상 최신 변경사항을 적용한 commit을 유지할 수 있습니다. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. +

+작업 중에 갑작스럽게 다른 작업을 진행해야 할 때, 작업중인 사항을 잠시 치워두는 방법입니다. stash를 사용해서 잠시 코드를 다른 곳에 보관한 후에, 내가 원하는 branch에 적용할 수 있습니다. +- git stash : 현재 적용된 ccommit 이후로 변경된 모든 사항들이 stash 공간으로 이동됩니다. +- git stash pop : 다른 브랜치의 commit에 stash로 따로 저장해둔 코드들을 적용합니다. +- git stash -p : hunk를 기준으로 변경사항을 하나씩 확인하며 원하는 변화만 stash에 담을 수 있습니다. +*hunk : 깃에서 하나의 변경사항이 담긴 단위입니다. +- git stash -m "다음 스태시하는 이유" : 어떤 이유로 stash했느지를 메시지로 남기고 stash 할 수 있습니다. +- git stash list : 리스트상의 번호로 apply, drop, pop을 적용할 수 있습니다. (ex) git stash apply stash@{1}) +- git stash branch "브랜치명" : 새로운 브랜치를 만들어서 pop(적용 및 삭제)를 진행합니다. 기존 작업 내용과 stash한 내용이 충돌할 가능성을 염두해 두고 새로운 branch를 만들어서 테스트해볼 수 있습니다. + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git a/git-basics/20th/README-Hwanginseop.md b/git-basics/20th/README-Hwanginseop.md new file mode 100644 index 0000000..206a118 --- /dev/null +++ b/git-basics/20th/README-Hwanginseop.md @@ -0,0 +1,154 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git: 소스 코드 및 파일 관리 시스템으로 + git을 이용하여 파일의 변화를 저장 및 추적이 가능하며 원하는 시점으로 되돌리거나 타인과 공유하는 것이 가능하다. + +github: 작업물을 온라인으로 저장하고 공유하는 공간. + +로컬 컴퓨터에서 git을 이용하여 작업하고 저장하여 github에 공유하고 이를 통해 github에서 협업하는 것이 가능하다. + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) + +Working Directory는 현재 내 작업물(소스코드)을 이야기 하며 +이를 Git add를 통해 원하는 파일을 선택하고 staging area에 두며 +이를 다시 git commit을 통해 로컬 컴퓨터의 저장소(Rocal repository)에 커밋메세지와 함께 저장. +로컬 레포지토리에 있는 변경사항을 git push를 통해 원격 저장소(remote repository)에 전송하고 git hub를 통해 공유된다. + +git pull은 git fetch와 git merge를 병합한 과정으로 +fetch를 통해 원격저장소에 있는 변경사항을 로컬로 가져오고 merge를 통해 로컬에 병합시킨다. + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +branch: 프로젝트의 특정 작업이나 기능을 독립적으로 분리하여 개발하기 위한 개념 + 각 브랜치는 프로젝트의 특정 상태를 나타내며, 독립적으로 변경되고 관리된다. + +commit: 소스 코드의 변경 사항 + +Head: 현재 작업중인 브랜치의 가장 최근 커밋, 즉 현재 작업중인 커밋 + +Git Checkout: 특정 브랜치로 이동할 때 사용되는 명령어로 "git checkout git-test-file"명령어 사용 시 git-test-file브랜치로 이동. + +git branch: 새로운 브랜치를 생성할 때 사용합니다. +"git branch git-test-file" 명령어를 사용하여 git-test-file라는 새로운 브랜치를 생성 + +git checkout -b new-branch: 새로운 브랜치 생성 후 해당 브랜치로 이동 + +git branch -d: 브랜치 삭제. 예시로 git branch -d git-test-file로 git-test-file삭제 + + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. + +git clone: 이미 존재하는 원격 저장소의 내용을 복제하여 로컬에 새로운 디렉토리를 생성. + 즉, 원격 저장소의 모든 내용을 가져와 로컬에 복사 + + 사용법 : git clone <원격 저장소 URL> + +git init: 현재 디렉토리나 새로운 디렉토리에 새로운 Git 저장소를 초기화 + (아무런 내용도 없는 새로운 저장소를 생성) + 이후에 파일을 추가하고 커밋할 수 있다. + + 사용법 : git init + +origin: 원격 저장소의 이름으로 git clone을 통해 원격 저장소 복제시, + origin이라는 이름으로 원격 저장소 생성 + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) + + +Soft Reset: + Soft reset은 커밋을 되돌리고 인덱스(Staging Area)에 있는 변경 사항을 유지 + + 가장 최신의 커밋을 취소하고, 그 변경 사항을 다시 스테이징 영역에 추가 + 실제로 작업 트리의 파일은 변경되지 않음 + + 사용법: git reset --soft HEAD~1 + +Mixed Reset: + Mixed reset은 커밋을 되돌리고 인덱스(Staging Area)에 있는 변경 사항을 취소 + + 최신 커밋을 취소하고, 그 변경 사항을 스테이징 영역에서 제거 + 작업 트리의 파일은 변경 내용이 그대로 유지 + + + 사용법: git reset HEAD~1 + +Hard Reset: + Hard reset은 커밋을 되돌리고 작업 트리와 인덱스에 있는 변경 사항을 모두 삭제 + + 최신 커밋을 취소하고, 그 변경 사항을 스테이징 영역과 작업 트리에서 모두 제거 + + 이 명령어를 사용하면 작업 트리에 있는 모든 변경 사항이 사라지므로 주의 필요 + + 사용법: git reset --hard HEAD~1 + +간단히 나타내어 상술한 워킹 디렉토리(1)-인덱스(2)-로컬 리포지토리(3) 관계에서 +soft는 3->2, mixed는 3->1, hrad는 3->0 + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) + +Pull Request: 다른 사용자가 작성한 저장소에서 변경 사항을 병합하기 위한 요청 + +Merge : Merge는 두 개 이상의 다른 브랜치의 변경 사항을 하나의 master branch에 통합하는 작업. + master브랜치에서 분기해 나가는 지점(commit)을 base라 함 + -Fast Forward Merge: 병합 과정에서 새로운 commit을 생성하지 않고 이전 변경사항을 + 참조하여 쌓아 나가는 것 + -3-Way Merge: base와 그곳에서 뻗은 두 brach, 총 세 커밋을 비교하여 변경사항을 병합 + + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) + +Rebase : base를 재설정한다는 의미로, + 하나의 브랜치가 다른 브랜치에서 파생되서 나온 경우, 다른 브랜치에서 진행된 커밋을 가져와서 base를 재설정하는 것 + + rebase를 사용하면 브랜치의 커밋 히스토리를 깔끔하게 유지할 수 있고, 불필요한 머지 커밋을 방지하고 선형적인 히스토리를 유지할 수 있다 + + 적용 순서: + + 1. 현재 브랜치에서 베이스로 지정한 브랜치(대상 브랜치)의 최신 커밋을 + 가져옵니다. + + 2. 현재 브랜치에서 베이스로 지정한 브랜치까지의 커밋을 임시로 저장합니다. + + 3. 베이스로 지정한 브랜치의 최신 커밋을 가져와 현재 브랜치의 마지막 + 커밋으로 합칩니다. + + 4. 임시로 저장한 커밋을 다시 현재 브랜치 위에 적용하여 완료합니다. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) + +git stash: 현재 작업 디렉토리의 변경 사항을 임시로 저장 + + 변경 사항을 stash에 저장하기: git stash save "임시로 저장할 메시지" + + stash 목록 확인하기: git stash list + + stash에서 변경 사항을 적용하기: git stash apply stash@{n} + + stash에서 변경 사항을 적용하고 해당 stash 제거하기: it stash pop stash@{n} + + 특정 stash 삭제하기: git stash drop stash@{n} + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. + +Fast-Forward와 3-Way Merge의 이해가 맞는지 잘 모르겠습니다. \ No newline at end of file diff --git a/git-basics/20th/README-JangJinYoung.md b/git-basics/20th/README-JangJinYoung.md new file mode 100644 index 0000000..3b027fe --- /dev/null +++ b/git-basics/20th/README-JangJinYoung.md @@ -0,0 +1,172 @@ +# Git 기초 + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +먼저 Git 과 Github에 대해서 알아보겠습니다. + +Git +- 분산 버전 관리 시스템 +- 로컬 및 원격 저장소 모두에서 작동하며, 개발자는 로컬에서 변경 사항을 커밋하고, 이것을 원격 저장소에 푸시 할 수 있다. + +GitHub +- Git 저장소를 위한 클라우드 기반 플랫폼 +- 코드 공유 및 협업을 위한 다양한 기능 제공 + +정리를 하자면 Git은 소프트웨어 개발에서 코드 버전 관리를 위한 도구이고, GitHub은 Git 저장소를 호스팅하고, 협업 기능을 제공하는 서비스 + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) + +Git의 흐름을 이해하기 위해 각 정의를 알아봅시다. + +1. Working Directory +- 개발자가 실제 파일을 수정하고 있는 디렉토리 +- 말 그대로 현재 작업 중인 디렉토리 +- **add** 를 통해 수정된 파일을 Staging Area 에 저장한다. +2. Staging Area +- 파일들이 **commit** 되기 전에 대기하는 장소 +3. Local Repo (HEAD) +- Local Repo : 개인(Local) 저장 공간 +- HEAD : 현재 작업 중인 브랜치의 가장 최근 커밋을 가르키는 포인터 +4. Remote Repo (MASTER) +- 원격 저장소 : 예를들어 GitHub +- MASTER : 프로젝트에서 주요 브랜치로써, 최종적인 또는 안정적인 버전의 코드가 유지되는 곳 (최근엔 MASTER를 사용하지 않고 main이라는 이름 사용) +- Local Repo 에서 **push** 를 통해 원격 저장소에 저장 + +git pull : 원격저장소에 있는 프로젝트의 변경사항을 그대로 로컬저장소에 옮겨와 자동으로 병합 + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) + +commit +- 프로젝트의 소스 코드에 대한 변경 내용을 기록하는 행위 + +branch +- 독립적인 개발 라인 +- 생성 : git branch [branch 이름] +- 이동 : git checkout [branch 이름] +- 삭제 : git branch -d [branch 이름] + +HEAD +- HEAD : 현재 작업 중인 브랜치의 가장 최근 커밋을 가르키는 포인터 + +## clone, init, origin +git **clone** +- 원격의 Git 저장소를 로컬에 복제할 때 사용하는 명령어 + +git **init** +- Local 에서 Git 저장소를 생성할 때 사용하는 명령어 + +origin +- 원격 저장소를 의미 +- origin이란 이름은 관행적 이름이라서 변경 가능 +- 설정 : git remote add origin [URL] + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) + +reset +- 시간을 과거의 특성 사건(commit)으로 되돌린다. +- 현재를 없던것 처럼 한다. + +hard +- 지정된 커밋으로 HEAD를 이동시키고, 스테이징 영역, 작업 디렉토리 모두를 지정된 커밋의 상태로 되돌린다. + +mixed +- 지정된 커밋으로 헤드가 이동하고, 스테이징 영역도 초기화된다. 하지만 작업 디렉토리의 파일은 그대로 유지된다. +- 즉, 이전 커밋 이후의 변경사항들은 작업 디렉토리에 남아 있게 되고, 이를 다시 스테이징 할 필요가 있다. + +soft +- 지정된 커밋으로 HEAD를 이동시키고, 작업 디렉토리는 변경되지 않는다. +- 즉 이전 커밋 이후의 모든 변경사항들은 스테이징 여역에 남게 된다. + +명령어 +- git reset --[hard, mixed, soft] + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request +- 한 브랜치의 변경사항을 다른 브랜치에 병합하기 전에 리뷰와 토론을 요청하는 기능 +- 검토가 완료되면, Pull Request는 최종적으로 Merge 될 수 있다. + +Merge +- 두 브랜치를 하나로 합치는 과정 +- Fast-Forward Merge + - 병합하려는 브랜치의 모든 커밋이 병합 대상 브랜치의 Head 커밋으로 이동되는 방식 + - 즉 별도의 병합 커밋을 생성하지 않고, 대상 브랜치의 포인터만 병합하려는 브랜치의 최신 커밋으로 옮깁니다. +- 3-Way Merge + - 두 브랜치의 최신 커밋과 공통 조상 커밋을 사용하여 병합을 수행합니다. + - 필요한 경우 별도의 병합 커밋을 생성하여 두 브랜치의 변경사항을 통합합니다. + - 병합 과정에서 충돌이 발생할 수 있으며, 사용자가 수동으로 충돌을 해결해야 할 수 있습니다. + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase +- 두 개의 공통 Base를 가진 Branch에서 한 Branch의 Base를 다른 Branch의 최신 커밋으로 Branch의 Base를 옮기는 작업. + +장점 +- 공유 Branch의 최신 변경사항을 즉각 반영할 수 있다. +- commit History를 깔끔하게 관리 할 수 있다. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash +- 현재 작업 디렉토리의 변경 사항을 일시적으로 저장하고, 깨끗한 작업 트리로 돌아갈 수 있게 해주는 기능입니다. +- 즉 변경사항은 유지하고, 다른 Branch 로 이동하고 싶을때 사용하면 좋음 + +명령어 +- git stash +- git stash apply [stash_id] +- got stash drop [stash_id] + + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? + - git rebase 명령어를 대화형으로 실행 + +- branch의 upstream이란? (`git push --set-upstream`) + - 로컬 브랜치와 연결된 원격 브랜치를 의미한다. + +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. + - 1. 오픈 소스 프로젝트에 기여 : 원본 리포지토리에 대해 쓰기 권한이 없을 때 프로젝트를 Fork하여 변경한우 PR 요청 + - 2. 프로젝트의 안정성을 유지하며, 실험적인 기능을 개발할 떄 + +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +git fetch +- 원격 저장소의 최신 커밋, 브랜치, 태그 등의 정보를 로컬 저장소로 가져오지만, 실제 로컬 작업 디렉토리의 파일을 변경하지는 않습니다 +- 사용 시기 : 원격 저장소의 변경사항을 확인하고 싶지만, 바로 로컬 작업 디렉토리에 적용하고 싶지 않을 때 + +git pull +- git fetch + git merge 한 번에 실행 +- 사용 시기 : 원격 저장소의 최신 변경사항을 바로 로컬 작업 디렉토리에 적용하고 싶을 때 + +- `reset --hard`와 `push --force`의 적절한 사용법 +git reset --hard +- 현재 브랜치의 HEAD를 특정 커밋으로 이동시키고, 작업 디렉토리와 인덱스(스테이징 영역)를 그 커밋의 상태로 완전히 동기화합니다. 이 과정에서 지정된 커밋 이후의 모든 변경사항은 사라집니다 +- 사용 시기 : 로컬에서 실험적인 변경을 했지만, 이를 완전히 폐기하고 마지막 커밋 상태로 돌아가고 싶을 때 + +git push --force +- 로컬 브랜치의 현재 상태를 원격 저장소의 브랜치에 강제로 덮어쓰게 합니다. 이는 로컬의 히스토리가 원격 저장소와 다를 때 사용되며, 원격 저장소의 히스토리를 로컬의 것으로 대체합니다. +- 잘못된 커밋을 수정한 후, 이 변경사항을 원격 저장소에 반영해야 할 때 (공동으로 작업 시 조심해야함) + +`.gitignore` 사용법 + - '#'으로 시작하는 라인은 무시한다. + - 표준 Glob 패턴을 사용한다. + - 슬래시(/)로 시작하면 하위 디렉터리에 적용되지 않는다. + - 디렉토리는 슬래시(/)를 끝에 사용하는 것으로 표현한다. + - 느낌표(!)로 시작하는 패턴의 파일은 무시하지 않는다. + +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. + - parent/child/grandchild 와 더 깊은 계층을 가진 브랜치가 존재하므로 + - 파일구조를 떠올리면 쉬움 + +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + - Detached Head : detached HEAD 상태는 Git에서 현재 HEAD가 브랜치의 최신 커밋을 가리키고 있지 않고, 대신 특정 커밋을 직접 가리키고 있는 상태 + - 커밋을 하게 된다면? : 새 커밋은 현재 가리키고 있는 커밋을 부모로 하여 생성됩니다. 이렇게 생성된 커밋은 어떤 브랜치에도 속하지 않게 되며, 나중에 다른 브랜치로 체크아웃하면 이 커밋에 대한 참조를 잃어버릴 위험이 있습니다. + - 발생 할 수 있는 상황 + - 특정 커밋 체크아웃 + - 태그 체크아웃 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git a/git-basics/20th/README-LeeSiWoong.md b/git-basics/20th/README-LeeSiWoong.md new file mode 100644 index 0000000..b61c906 --- /dev/null +++ b/git-basics/20th/README-LeeSiWoong.md @@ -0,0 +1,95 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) + +### Git - 버전 관리 시스템 +1. 코드의 수정내역 열람 및 특정시점으로 되돌아가는 기능을 제공하는 버전관리 시스템 +2. local에서 동작해 내 코드의 버전들을 관리 +3. 그래서 Git 자체만으론 다른 사람들과의 협업이 어려움 + +### Github - 원격 저장소 +1. Git 사용 프로젝트를 지원하는 웹 호스팅 서비스 +2. local에서 작업한 코드를 깃헙의 remote 저장소에 업로드 +3. 또한 다른 사람이 remote에 올린 코드를 내 local로 받아올 수 있음 +4. 이를 통해 다른 사람들과의 협업이 수월해짐 + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +- 작업 디렉토리 코드는 아직 변경사항이 기록되지 않고있는 **untracked** 상태 +- **git add** 명령어를 통해 코드를 Staging Area로 옮겨 **tracked**되게 함 +- 스테이징 영역에 있는 코드들을 **git commit** 명령어로 커밋 +- 커밋된 코드들은 로컬 저장소에 모임 +- 이 로컬 저장소를 **git push** 명령어로 github등의 원격 저장소에 업로드 + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) + +![alt text](image.png) +- **git branch 브랜치명**으로 branch를 만들어 코드의 시점을 나눌 수 있다. +- **git checkout** 명령어를 통해 자유롭게 브랜치들을 오갈 수 있다. +- 이때 *HEAD*는 현재 사용자가 위치한 브랜치의 최신 커밋을 가리키는 포인터이다. +- **git branch -d 브랜치명**으로 브랜치를 삭제할 수도 있다. + +## clone, init, origin + +- git init은 로컬의 어떤 프로젝트를 git으로 관리하게 만드는 명령어 +- git clone <주소>는 저장소로부터 프로젝트를 복제(clone..)해오는 명령어 + - 클론해온 프로젝트엔 origin이라는 원격 저장소 디폴트명이 자동등록된다. + - origin은 원격저장소 URL을 내포하며 **git remote -v**로 확인 가능. + - **git remote add 단축명 url**로 원격 저장소를 추가할 수 있는데 이때는 origin 말고 다른 단축명을 사용할 수도 있다. + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +**git reset option(기본은 mixed) 커밋위치** 명령어는 단순하게 현재 HEAD가 가리키는 커밋을 옮길 수 있다. +이 때 옮기고 처리하는 방식에 따라 3가지로 나뉜다. +1. HEAD가 가리키는 커밋 위치를 옮긴다. (여기까지가 --soft 옵션) -> 아직 기존 코드 스테이징돼있음 +2. staging area를 HEAD가 가리키는 상태로 만든다. (여기까지가 --mixed 옵션) -> 아직 기존 코드는 작업폴더에 있음 +3. working directory를 staging area가 가리키는 상태로 만든다. (여기까지가 --hard 옵션) + +> A-git add수행-B-git commit ..수행-C 일때 soft는 B로, mixed는 A로, hard는 현재 HEAD 이후로 작성한 코드가 없는 시점으로 이동한다. + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) + +**PR**은 내가 짠 코드를 원격 저장소 관리자에게 검토를 요청하는 기능이다. + +검토 이후 승인이 난 코드가 담긴 브랜치를 원격 저장소의 브랜치에 반영해 두 코드를 합치는 것을 **merge**라 한다. +- 2종류의 merge가 있다. +![alt text](image-2.png) + 1. Fast-Forward + - 새 브랜치 hotfix를 만들어 작업하면 hotfix는 기존 브랜치의 모든 커밋 내역을 가지고 있다. + - 만약 기존 브랜치가 변동이 없다면 이 경우 hotfix로의 merge는 그냥 기존 브랜치가 가리키는 HEAD가 merge되는 hotfix의 HEAD로 옮겨진다. + 2. 3-Way + - hotfix 추가 후 기존 브랜치에서 작업을 해 변동이 있고 이 작업은 hotfix의 작업영역과 충돌하지 않는 경우이다. + - hotfix 브랜치는 기존 브랜치의 모든 커밋을 담고 있지 않는다. + - 따라서 각 브랜치의 HEAD 2개, 공통조상 커밋 1개 총 3개를 merge한 결과를 별도의 **merge commit**으로 만들어 HEAD를 여기로 옮긴다. + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +merge와 마찬가지로 브랜치를 합치는 결과를 만들어내나 중간과정이 다름. +1. main 브랜치에서 feature 브랜치로 rebase한다. +2. 이 말은 main 브랜치의 마지막 커밋에 feature 브랜치의 base가 달라붙는단 의미이다. +3. 이 경우 히스토리 구조가 선형이 되기 때문에 merge와 달리 불필요한 merge 커밋을 제거해 깔끔한 유지보수가 된다. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +작업중 다른작업을 진행할 때 기존 작업을 잠시 스택공간에 치워두는 방법이다. +1. **git stash**로 현재 적용된 커밋 이후 변경된 모든 사항들이 stash 공간으로 이동한다. -m 옵션으로 기록도 가능 +2. **git stash apply**로 했던 최근 작업을 다시 가져온다. 뒤에 이름을 붙이면 원하는 항목을 가져올 수 있다. +3. **git stash list**로 작업목록명 확인 가능하다. + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git a/git-basics/20th/README-dongin.md b/git-basics/20th/README-dongin.md new file mode 100644 index 0000000..225caa2 --- /dev/null +++ b/git-basics/20th/README-dongin.md @@ -0,0 +1,202 @@ +# Git 기초 🔥 + + +## 1️⃣ Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +**Git** +- 버전 관리 시스템. +- 하나의 프로젝트에 여러 사람이 작업할 때 작업의 히스토리(변경 사항)를 관리할 수 있게 해주는 도구이다. + +**Github** +- Git을 사용하여 관리되는 프로젝트를 올려두고, 협업을 쉽게 할 수 있도록 도움을 주는 웹 기반 플랫폼. +- 프로젝트의 버전을 관리하기 때문에 협업할 때 편리하다. + +**Repository** +- Local Repository는 자신의 컴퓨터에 있는 저장소를 의미하고, Remote Repository는 인터넷 상에 위치한 저장소를 의미한다. +- 보통, Local 저장소에서 Git을 통해 프로젝트를 작업한 후, Remote 저장소(Github)에 올려 다른 팀원들과 공유하는 방식으로 협업을 진행한다. + +> 이렇게, Git과 Github를 통해 코드의 변경 사항을 확인하고, 다양한 개발자와 원할한 작업이 가능하다. + + +## 2️⃣ Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) + +**Working Directory** +- 사용자가 실제로 작업하고 있는 로컬 파일 시스템의 디렉토리. +- 개발자가 코드를 수정, 생성하는 곳. + +**git add** +- Working Directory에서 변경된 파일들을 임시저장공간(Staging Area)로 이동시키는 명령어. +- Git이 추적해야 할 변경 사항을 선택하는 과정으로, 사용자는 commit할 파일들을 고를 수 있다. + +**git commit** +- Staging Area에 있는 변경 사항들을 Local Repository에 영구적으로 저장하는 명령어. +- 각 commit은 해당 프로젝트의 버전을 나타내며, 커밋 메시지를 통해 해당 변경 사항에 대한 설명을 추가할 수 있다. + +**git push** +- Local Repository의 commit을 Remote Repository (ex. Github)에 업로드하는 명령어. +- 코드의 최신 버전을 팀원들과 공유, 백업하는 데 사용된다. + +**git fetch** +- Remote Repository의 최신 변경 사항을 Local로 가져오는 명령어. +- 원격 저장소의 최신 상태를 확인하고 싶을 때 사용한다. git fetch 후, git merge나 git rebase를 사용해서 원격 변경 사항을 현재 작업 브랜치에 반영할 수 있다. + + +## 3️⃣ Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) + +**branch** +- 개발의 주 흐름에서 벗어나, 독립적으로 어떤 작업을 진행하기 위한 기능. +- 프로젝트의 한 부분에서 다른 부분으로 작업 범위를 옮길 수 있게 도와준다. +- 생성 : git branch <생성할 branch 이름> +- 삭제 : git branch -d <삭제할 branch 이름> +- 이동 : git checkout <이동할 branch 이름> + +**HEAD** +- 현재 작업 중인 branch의 가장 최신 커밋. +- Git이 어느 시점의 코드를 바탕으로 작업하고 있는지를 의미한다. 즉, 프로젝트의 현재 '상태'를 나타내는 포인터이다. + +**git checkout** +- 특정 branch로 전환하거나, 과거의 어떤 시점(버전)으로 작업 디렉토리의 상태를 되돌리는 명령어. +- 이전 버전의 파일을 복구하거나, 다른 버전 간의 차이를 비교할 수 있게 한다. + + +## 4️⃣ clone, init, origin + +**git clone** +- 기존에 존재하는 Git 저장소 (Repository)를 Local 컴퓨터로 복사해오는 명령어. +- Remote 저장소의 모든 데이터(코드, branch, 버전 기록 등)를 포함하여 복제한다. + +**git init** +- 새로운 Git 저장소를 만드는 명령어. +- Git이 작업 디렉토리를 Git 저장소로 초기화하고, 코드의 버전 관리를 시작할 수 있다. 새로운 저장소를 만들고, 프로젝트의 최초 버전을 관리하기 시작할 때 사용. + +**origin** +- 원격 저장소 (Remote Repository)를 나타내는 가장 일반적인 별칭. +- 프로젝트 초기에 `push, pull, fetch` 등의 명령어 사용 시, 원격 저장소를 지칭하는 별칭의 역할을 한다. +- 설정 방법 + 1. 원격 저장소 연결하기 + 2. 원격 저장소 확인하기 + - 현재 로컬과 연결된 모든 원격 저장소와 그들의 URL이 출력됨 + 3. 원격 저장소 별칭 변경, 제거 +```bash +# 원격 저장소를 새로 연결 +git remote add <별칭> <원격 저장소 주소> + +# 연결된 원격 저장소 확인 +git remote -v + +# 별칭 변경 +git remote rename <기존 별칭> <새 별칭> + +# 원격 저장소 연결 제거 +git remote remove <별칭> +``` + + +## 5️⃣ reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) + +**git reset** +- 주로 잘못된 commit을 취소하거나, 변경할 때 사용하는 명령어. +- 3가지 옵션을 통해 commit의 상태를 조절할 수 있다. +1. `--soft` + - 지정한 커밋으로 돌아간다. Staging Area(임시저장공간)의 상태는 유지한다. + - 커밋만 취소하고, 변경된 파일들을 다시 커밋할 때 사용 + - 즉, 가장 최근에 커밋된 내용이 사라지고, 변경 사항이 Staging Area에 남아 있어서 다시 커밋할 수 있다. +2. `--mixed` + - 기본옵션으로, 지정한 커밋으로 돌아가면서 Staging Area의 변경 사항도 취소한다. 작업 디렉토리의 파일 내용은 그대로 유지된다. + - 커밋을 취소하고, 변경 사항을 수정한 후, 다시 Staging 하고 싶을 때 사용 + - 즉, 지정한 커밋으로 되돌리는 동시에, Stage에 올라가 있던 변경 사항들이 작업 디렉토리에 남게 되어 수정 후 다시 Staging 가능하다. +3. `--hard` + - 지정한 커밋으로 돌아가고, Staging Area 및 작업 디렉토리의 변경 사항 모두를 취소한다. + - 잘못된 커밋을 완전히 취소하고, 이전 상태로 완벽하게 돌아가고 싶을 때 사용 + - 즉, 작업 디렉토리의 내용까지 완전히 되돌린다. 다시 되돌릴 수 없으므로, 사용에 주의해야 한다. + + +## 6️⃣ Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) + +**pull request** +- 코드 변경 사항을 검토/논의 후, 메인 프로젝트에 병합하기 위한 요청. +- 소스코드에 대한 변경 사항을 다른 사람들과 공유하고, 리뷰 받고자 할 때 사용하는 Github의 기능이다. +- 사용 과정 + 1. 자신의 Local에서 작업을 진행한 후, 변경 사항을 Github에 push한다. + 2. Github에서 메인 프로젝트 저장소로 pull request를 생성한다. + 3. 팀원/프로젝트 관리자가 이 pull request를 리뷰하고, 피드백을 제공한다. + 4. 모든 리뷰와 변경 요청이 완료되면, 메인 저장소의 관리자가 pull request를 merge하여 변경 사항을 프로젝트에 반영한다. + +**merge** +- 두 가지 branch의 변경 사항을 하나로 합치는 과정 +- 개발 과정에서 branch를 활용하여 기능 개발, 버그 수정 등을 진행한 수, 이를 다시 메인 코드라인에 병합해야 할 때 사용한다. +1. `fast-forward` +- 현재 branch의 HEAD가 병합하려는 branch의 히스토리에 이미 포함되어 있을 때, 단순히 현재 branch의 HEAD를 최신 commit으로 옮기는 방식 +- 별도의 commit이 생성되지 않는다. + +![fast-forward](https://abaft-chocolate-f90.notion.site/image/https%3A%2F%2Fprod-files-secure.s3.us-west-2.amazonaws.com%2F94628612-4999-4a9e-bd19-428a991f4eb4%2F07bf5db2-2482-457e-abea-7fff29726106%2FB1991810-9A2D-4C9B-A9AB-6134A6A0753E.jpg?table=block&id=f47f5bb3-c26e-471f-a9d9-0b509572734b&spaceId=94628612-4999-4a9e-bd19-428a991f4eb4&width=1500&userId=&cache=v2) +2. `3-way-merge` +- 두 branch의 기점부터 diverge(갈라진) 지전까지 고려하여 병합하는 방식 +- 병합된 새로운 commit이 생성되고, 이 commit은 두 branch의 각 최신 commit을 부모로 가진다. + +![3-way-merge](https://abaft-chocolate-f90.notion.site/image/https%3A%2F%2Fprod-files-secure.s3.us-west-2.amazonaws.com%2F94628612-4999-4a9e-bd19-428a991f4eb4%2Fb6a46e40-3024-4127-a4da-aa10af653a31%2F3F39365F-3CF4-419A-A822-76A79D49FAAB.jpg?table=block&id=e90ec2a9-b6d8-4f35-89a8-75d1a341ce69&spaceId=94628612-4999-4a9e-bd19-428a991f4eb4&width=1500&userId=&cache=v2) + + +## 7️⃣ rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) + +**rebase** +- 한 branch의 변경 사항을 다른 branch로 가져와서 두 branch의 공용 기저(base)를 다시 설정하는 과정 +- 즉, 기저 재설정을 의미하고, 복잡한 commit 히스토리를 깨끗하게 유지할 수 있는 방법이다. +- 장점 + - 공유하는 branch의 최신 변경 사항을 즉각 반영 + - commit 이력을 하나의 직선으로 관리 가능 (깔끔한 프로젝트 히스토리) +- 사용 시점 + - 자신의 작업 branch에 다른 branch의 최신 변경 사항을 반영하고 싶을 때 + - 병합 충동이 예상되는 상황에서 branch 충돌을 미리 해결하고 싶을 때 + - 단, 다른 사람과 공유하는 branch에서는 조심해서 사용 + +![rebase](https://abaft-chocolate-f90.notion.site/image/https%3A%2F%2Fprod-files-secure.s3.us-west-2.amazonaws.com%2F94628612-4999-4a9e-bd19-428a991f4eb4%2Fd8d9204a-5380-463b-bf7e-c7b7df15b75a%2F1928B19D-B305-4D8D-92C2-30615BFDEA56.jpg?table=block&id=9d289f35-9044-4087-afec-61e6858cfd4c&spaceId=94628612-4999-4a9e-bd19-428a991f4eb4&width=1500&userId=&cache=v2) + +## 8️⃣ stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) + +**git stash** +- 아직 마무리하지 않은 작업을 스택에 임시로 저장하는 명령어 +- 다른 작업을 수행한 후, 저장했던 변경 사항을 다시 적용할 수 있다. +- 수정한 파일만 저장한다 (Modified이지만 Tracked인 파일, Staged 파일 등) +- 활용 방법 + - 작업 중 급하게 다른 branch로 이동해야 하는 상황에서, 현재 branch의 변경 사항이 아직 commit할 준비가 안 되었을 때 + - 실험적인 변경을 해보고 싶지만, 현재 작업 내용을 잃고 싶지 않을 때 +```bash +# 현재 작업 중인 변경 사항을 임시 저장 +git stash + +# 가장 최근에 stash된 변경 사항을 다시 적용 +git stash pop + +# stash된 변경 사항을 적용하지만, stash 목록에서 제거 하지 않음 +git stash apply + +# 현재까지의 stash 목록을 보여줌 +git stash list + +# 모든 stash를 제거 +git stash clear +``` + + +## 9️⃣ Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +> [💡 git 연습 사이트 공유](https://learngitbranching.js.org/?locale=ko, "git 연습 사이트") + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git a/git-basics/20th/README-hyojun.md b/git-basics/20th/README-hyojun.md new file mode 100644 index 0000000..53c5bbd --- /dev/null +++ b/git-basics/20th/README-hyojun.md @@ -0,0 +1,138 @@ +# Git 기초 + +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github + +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +- git + 버전관리 소프트웨어 + 개인의 컴퓨에서 돌아간다. +- github + git 소프트웨어를 지원하는 일종의 클라우드 서비스 + 원격의 서버에 올라간다. + +## Git Workflow + +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +- Working Directory + 현재 작업하고 있는 영역, 작업을 하고 있는 프로젝트 디렉토리 + 아직 추적(track)하고 있지 않은 상태 +- Git Add + working directory상의 변경 내용을 staging area 추가하기 위해서 사용하는 git명령어 +- Git Commit + 의미있는 변경 작업들을 저장소에 기록하는 동작 + 코드 변경 시점을 저장했다가 잘못된 동작을 할 경우 돌아갈 수 있게함 +- Git push + 원격 저장소(remote repository)에 코드 변경분을 업로드하기 위해서 사용하는 git 명령어 + +## Branch, HEAD + +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +- branch + 독립적으로 어떤 작업을 진행하기 위한 개념 + 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행 +- HEAD + 현재 체크아웃된 브랜치의 가장 최신 커밋 +- checkout + 브런치 간의 switch를 하기 위한 명령어 + +## clone, init, origin + +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. + +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +- git init : 빈 git 저장소를 만들거나 기존 저장소를 다시 초기화하는 명령어 + > git init +- git clone : git 저장소를 복제해 새 디렉터리로 가져오는 명령어 + > git clone <원격 저장소 url> + +## reset + +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +- --soft 옵션 + 커밋 취소 + Staging 상태 유지(add) +- --mixed 옵션 + 커밋 취소 + Staging 취소 + local은 변경 상태로 유지 +- --hard 옵션 + 커밋 취소 + Staging 취소 + local 변경 상태 취소 + +## Pull Request, Merge + +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. + +- Pull Request + 사용자가 원격 저장소에 Push하여 새로운 사항이 적용됬을 경우, 다른 사용자에게 푸쉬된 상황을 알리는 것 +- Merge + 서로 다른 브랜치에서 작업한 내용을 합쳐야 하는 경우 사용 + - Fast-Forward방시 + branch간의 병합을 진행할 때 커밋이 생기지 앟고 merge 명령어를 실행하는 + branch의 Head Commit이 병합되는 branch의 Head Commit으로 이동 + - 3-Way Merge + 각 브랜치의 마지막 커밋 두 개와 공통 조상의 총 3개의 커밋을 이용하여 병합하는 방식 + 서로 다른 브랜치가 동일 선상이 아닐 경우 사용 + +## rebase + +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +- rebase + 공통 Base를 가진 두 개의 Branch에서 한 Branch의 Base를 다른 Branch의 최신 커밋으로 Base를 옮기는 작업 +- 유용한지 + 내가 작업하던 브랜치에 main 브랜치 내용이 필요해서 적용시키고 싶을 때 사용 + +## stash + +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +- stash + 작업중에 갑작스럽게 다른 작업을 진행해야 할 떄, 작업중인 사항을 잠시 치워두는 방법 + - git stash + 현재 적용된 commit 이후로 변경된 모든 사항들이 stash 공간으로 이동 + - git stash pop + 다른 브랜치의 commit에 stash로 따로 저장해둔 코드들을 적용 + - git stash -p + -p 옵션을 통해서 hunk 기준으로 변경사항을 하나씩 확인하며 원하는 변홤나 stash에 담을 수 있음 + - + +## Advanced + +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. + +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions + +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git a/git-basics/20th/README-hyunjin.md b/git-basics/20th/README-hyunjin.md new file mode 100644 index 0000000..33a5924 --- /dev/null +++ b/git-basics/20th/README-hyunjin.md @@ -0,0 +1,128 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) + + +⸰ Git은 개인 컴퓨터에서 돌아가는 Version Control System이다. 반면에 GitHub은 Github라 불리는 회사에서 서비스하고 있는 서버에 올라간 Git이다. + +⸰ 즉 개인 컴퓨터에서 사용하는 Git을 Local Git이라 부르고, Github이나 Gitlab과 같은 클라우드에 저장하는 Git을 Remote Git이라 부른다. + +⸰ 출처 : https://kotlinworld.com/265 + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. + + +⸰ Working Directory : 사용자의 작업 공간으로서, 로컬 저장소에 접근할수 있으며 실제 파일을 수정하거나 생성하는 공간이다.작업 폴더에서 .git 디렉토리를 제외한 나머지 부분. 파일들을 추적(tracked)/비추적(untracked) 상태로 구분한다. + +⸰ Staging area : commit이 가능한 영역으로, commit하기 전 파일을 담아두는 상자라고 볼 수 있다. + +⸰ Local repository : 본인의 컴퓨터에 저장된 로컬 버전의 프로젝트 저장소. + +⸰ Remote repository : Local repo와는 반대로 내 컴퓨터가 아닌 (일반적으로 원격 서버) 버전의 프로젝트 저장소. + +⸰ Working directory에 있는 작업물을 git add 명령어를 통해 staging area로 보내고, git commit 명령어를 통해서 간단한 코멘트를 남겨 라벨링 후, Local repo로 보낸다. 최종적으로 git push를 통해서 Local repo에 있는 파일을 Remote repo(github)로 보낸다. + +⸰ 출처 : https://m31phy.tistory.com/146 , https://ittrue.tistory.com/94 , https://dev-jacob.tistory.com/entry/Git-Repository%EB%9E%80 + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. + + +⸰ Branch : 커밋사이를 가볍게 이동할 수 있는 포인터이다. 기본적으로 Git은 master 브랜치를 만든다. 처음 커밋하면 이 master 브랜치가 생성된 커밋을 가리킨다. 이후 커밋을 만들면 master 브랜치는 자동으로 가장 마지막 커밋을 가리킨다. git branch <브랜치이름> 명령어를 통해서 생성가능하다. + +⸰ HEAD : 현재 작업하는 로컬 브랜치를 가리킨다. + +⸰ Git checkout : 다른 브랜치로 이동할 수 있는 명령어이다. 즉 HEAD가 가리키는 브랜치를 옮긴다. + +⸰ 출처 : https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%B8%8C%EB%9E%9C%EC%B9%98%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80 + + +## clone, init, origin + +⸰ Git init : 빈 git 저장소를 만들거나 기존 저장소를 다시 초기화하는 명령어이다. + +⸰ Git clone : git clone 과 같이 사용하며, url에 해당하는 저장소를 복제해 새 directory로 가져오는 명령어이다. + +⸰ Origin : 대표적으로 사용되는 원격 저장소의 별칭을 의미한다. + +별칭이란? - 로컬 저장소를 원격 저장소에 등록하기 위해서는 (git push) git 호스팅사 서버의 URL이 필요하다. github나 gitlab같은 호스팅사로 이용할 경우, 이 연결 URL은 프로토콜과 호스팅사 도메인으로 이루어진다. 즉 URL 주소가 길어진다. 그렇기 때문에 이 URL을 간략하게 특정 문자로 지정하는 것을 별칭이라고 한다. (별칭은 중복사용 불가능하다.) +별칭은 git remote <별칭> 로 지정하고 git remote rename <변경전> <변경후>로 바꿀수있다. 삭제는 git remote rm <별칭>으로 한다 + +⸰ 출처 : https://yoongrammer.tistory.com/21 , https://m.blog.naver.com/rinjyu/222180087428 + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) + +⸰ Reset : 총 3단계에 걸쳐서 이루어진다. (git reset 명령어) + +1. HEAD 이동 : reset 명령이 하는 첫 번째 일은 HEAD 브랜치를 이동시키는 것이다. checkout 명령처럼 HEAD가 가리키는 브랜치를 바꾸지는 않는다. HEAD는 계속 현재 브랜치를 가리키고 있고, 현재 브랜치가 가리키는 커밋을 바꾼다. (--soft 옵션을 주면 여기까지 진행.) + +2. Index(staging area) 업데이트 : Index를 현재 HEAD가 가리키는 스냅샷으로 업데이트 한다. 즉 git commit과 git add명령을 되돌리는 것이다.(--mixed 옵션을 주면 여기까지 진행. default는 --mixed 옵션) + +3. Working directory 업데이트 : working directory까지 업데이트 한다. 다시 말해 working directory파일을 강제로 덮어쓴다. 이 단계는 되돌리기가 불가능하기 떄문에 위험하다. (--hard 옵션을 주면 여기까지 진행) + +⸰ 출처 : https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-Reset-%EB%AA%85%ED%99%95%ED%9E%88-%EC%95%8C%EA%B3%A0-%EA%B0%80%EA%B8%B0 + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) + +⸰ Pull Request : Pull Request는 사용자가 원격 저장소에 Push하여 새로운 사항이 적용됐을 경우, 다른 사용자에게 push된 상황을 알리는 것을 말한다. 이를 줄여서 PR이라고도 한다.Pull request를 보내 놓으면 여러 동료들에게 리뷰를 받을 수 있고, 내가 올린 코드에 동료가 병합하여 진행할 수도 있다. + +⸰ Merge : 말 그대로 병합. git branch를 다른 branch로 합치는 과정이다. + +1. Fast Forward Merge : 가장 기본적인 Merge이다. 현재 branch의 HEAD가 대상 branch의 HEAD까지로 옮기는 Merge이다. git switch <현재 branch>와 git merge <대상 branch> 명령어로 사용가능하다. + +2. 3-way Merge : 동시간대에 두명 이상이 commit을 하면 Fast Forward Merge가 불가능하기 때문에, 내 branch commit과 다른 branch commit을 병합해서 새로운 커밋을 생성하는 방법이다. + +⸰ 출처: https://ittrue.tistory.com/93 , https://kotlinworld.com/277 , https://wonyong-jang.github.io/git/2021/02/05/Github-Merge.html + + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) + +⸰ Rebase : 두 branch를 합치는 방법으로, Merge와는 다르게 이름 그대로 branch의 공통 조상이 되는 base를 다른 branch의 commit 지점으로 바꾸는 것이다. + +기본 전략 - 먼저 Rebase 하려는 브랜치 커밋들의 변경사항을 Patch라는 것으로 만든 다음에 임시저장소에 저장해 둔다. 그리고 이를 master 브랜치에 하나씩 적용시켜 새로운 커밋을 만든다. (git checkout feature, git rebase master, git checkout master, git merge feature를 이용한다.) + +* Rebase를 위처럼 두 브랜치를 병합하는데 사용할 수도 있지만, 단일 브랜치 내에서 rebase를 사용하여 커밋 히스토리를 정리할 수도 있다. +즉, rebase를 이용하면 작업 도중 커밋 히스토리를 수정해야 하는 상황에서 유용하게 사용할 수 있다. + +⸰출처 : https://wonyong-jang.github.io/git/2021/02/05/Github-Rebase.html + + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) + +⸰ Stash : stash(git stash 명령어)는 작업중인 변경사항을 일시적으로 저장하고 branch전환, 또는 코드 commit 시점을 유연하게 다룰 수 있게 해준다. +변경사항을 commit하기에 이른 경우, 임시저장, 다른 branch로 체크아웃할때 변경사항을 유지하고 싶은 경우에 사용한다. + +* git stash(git stash save) - 현재 작업 중인 변경 사항을 일시적으로 저장하고, 작업 디렉토리를 깨끗한 상태로 만든다. 이 때, 저장한 변경 사항은 스택에 쌓이게 된다. + +* git stash pop(git stash pop ) - 스택에 쌓인 가장 최근의 변경 사항을 불러와 작업 디렉토리에 적용된다. 이 때, 스택에서 해당 변경 사항은 제거됨. + +* git stash apply - stash를 적용한 후에도 stash가 적용되어 있는 상태를 유지한다. 임시 저장공간에서 삭제되지 않는다. 이에 대해 추가 작업을 수행하려면 다시 git stash 명령어를 실행해야 함. +만약 branch마다 적용을 하고싶다면 git stash apply를 활용하면 된다. + +* git stash list - 현재 stash들의 목록을 확인할 수 있다. + +⸰ 출처 : https://velog.io/@fkszm3/Git-stash-%EB%9E%80-%EC%96%B8%EC%A0%9C-%EC%82%AC%EC%9A%A9%ED%95%A0%EA%B9%8C + + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git a/git-basics/20th/README-jusong.md b/git-basics/20th/README-jusong.md new file mode 100644 index 0000000..ca14027 --- /dev/null +++ b/git-basics/20th/README-jusong.md @@ -0,0 +1,198 @@ +# Git 기초 + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +### Git + Git은 소스 코드 버전 관리 시스템이다. + Local repository의 모든 변경사항을 기록하여 파일의 버전 관리를 용이하게 해준다. +### GitHub + GitHub은 Git 소프트웨어를 지원하는 클라우드 기반 호스팅 서비스이다. + Remote repository 기능을 제공해주는 서비스이다. + 여러 사람과 공유하고 협업할 수 있다. + + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +### Working Directory (Working Tree) + 현재 작업하고 있는 영역을 말한다. +### Staging Area + Repository에 commit하기 전에 commit을 준비하는 위치를 말한다. +### Repository + Working directory의 변경 이력들이 저장되어 있는 영역으로 commit들이 모여있는 저장소이다. +### Local Repo(HEAD) + 내 컴퓨터의 저장소, 즉 개인 전용 저장소를 말한다. +### Remote Repo(MASTER) + 원격 온라인 서버상의 저장소로 여러 사람이 함께 공유할 수 있다. +### Git 동작 방식 +1. Git Add + - 변경된 내용을 Staging area에 추가하는데 사용된다. +2. Git Commit + - Staging area에 추가된 변경 사항을 저장한다. +3. Git Push + - Local repository 내용을 Remote repository로 업로드 하는 데 사용된다. +4. Git Merge + - 다른 branch에서 변경 사항을 결합하는 데 사용된다. +5. Git Fetch + - Remote repository에서 변경 사항을 가져오지만 Local branch에 자동으로 병합하지 않는다. +6. Git Pull + - Git Fetch와 Git Merge의 조합으로 Remote repository에서 변경 사항을 가져와 현재 branch에 자동으로 병합한다. + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +### Branch + Branch는 동일한 소스 코드에서 다른 작업을 동시다발적으로 할 수 있게 해주는 기능을 말한다. + 코드 전체를 복사하고 난 후, 원래 코드와는 상관없이 독립적으로 개발할 수 있다. +### HEAD + HEAD란 해당 branch의 마지막 commit, 즉 현재 사용중인 branch의 선두 부분을 나타내는 이름을 뜻한다. + HEAD를 이동하면 사용하는 branch가 변경된다. +### git checkout + git checkout 명령어는 branch 간 전환하거나 파일을 이전 상태로 복원하는 명령어이다. +### Branch 관련 Git 명령어 + // Branch 생성 + $ git branch <새로운_브랜치_이름> + + // Branch 삭제 + $ git branch -d <삭제할_브랜치_이름> + + // Branch 이동 + $ git checkout <이동할_브랜치_이름> + + // 새로운 branch 생성 후 이동 + $ git checkout -b <새로운_브랜치_이름> + + +## clone, init, origin +### git init과 git clone +#### 공통점 + 리포지토리를 로컬에 생성하는 방법이다. +#### 차이점 +1. git init + - 기존의 Local directory를 Git 저장소로 변환한다. + - 이미 있는 directory를 Git으로 관리하기 시작할 때 사용한다. +2. git clone + - Remote repository부터 프로젝트를 가져온다. + - 이미 존재하는 Git 저장소를 복제해 local로 가져온다. + - 보통 다른 사람이나 팀의 프로젝트에 기여하기 위해 사용한다. +### origin + origin은 Remote repository의 이름이다. +#### 설정방법 + // 자동으로 origin으로 설정 + $ git clone <원격_저장소_URL> + + // 수동으로 origin으로 설정 + $ git remote add origin <원격_저장소_URL> + + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +### reset의 type + 1. soft + 2. mixed + 3. hard + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
softmixedhard
HEAD지정한 commit으로 이동한다.
HEAD가 가리키는 BranchHEAD와 같이 움직인다.
Staging area변화 X지정한 commit과 동일 내용지정한 commit과 동일 내용
Working directory변화 X변화 X지정한 commit과 동일 내용
주 용도branch 이동하기Staging area에서 빼기commit 되돌리기
+ + + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +### pull request + 협력자에게 branch 병합을 요청하는 메시지를 보내는 것을 말한다. +### merge + 서로 다른 branch를 하나의 branch로 합치는 과정으로 브랜치의 작업 내용을 병합하는 것을 말한다. +### merge type +1. Fast-foward Merge + - 분기한 branch의 commit 히스토리가 기존 branch의 commit 히스토리를 포함하고 있는 경우 사용된다. + - Merge commit이 따로 만들어지지 않고 HEAD의 위치만 이동한다. +2. 3-Way Merge + - 각 branch에 새 commit이 하나 이상 있는 경우 사용된다. + - 두 branch의 코드를 합쳐서 새로운 commit을 자동 생성한다 + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +### rebase + Branch의 시작점을 다른 commit으로 옮겨주는 행위이다. + Branch 수가 많은 경우, git log를 간단하게 해주기 위해서 rebase 명령어를 사용해 merge 한다. +### rebase 명령어를 사용하여 merge 하는 방법 + // 새로운 branch의 시작점을 main branch의 최근 commit으로 변경 + $ git switch <새로운_브랜치> + $ git rebase main + + // Fast-forward merge 진행 + $ git switch main + $ git merge <새로운_브랜치> + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +### stash + stash는 변경사항을 일시적으로 저장하는 기능이다. + 아직 commit하기에 이른 경우나 다른 branch로 checkout 할 때 변경사항을 유지하고 싶을 때 사용한다. +### stash 명령어 + // 현재 Working directory의 변경 사항을 일시적으로 저장 + Working directory를 깨끗한 상태로 변경 + $ git stash + + // 변경 사항을 특정 이름으로 저장 + $ git stash save <이름> + + // 가장 최근의 변경 사항을 가져와 Working directory에 적용 + 변경 사항을 stack에서 제거 + $ git stash pop [인덱스_번호] + + // stash를 적용하고 stash가 적용된 상태 유지 + 임시 저장 공간에 그대로 유지 + $ git stash apply + + // n번째 stash 가져와 적용 + $ git stash apply stash@{n} + + // 현재 stash 목록 확인 + $ git stash list + + // n번째 stash 제거 + $ git stash drop stash@{n} + + // 모든 stash 제거 + $ git stash clear +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions + diff --git a/git-basics/20th/README-kangsumin.md b/git-basics/20th/README-kangsumin.md new file mode 100644 index 0000000..7fabcc9 --- /dev/null +++ b/git-basics/20th/README-kangsumin.md @@ -0,0 +1,238 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +### Git과 GitHub의 의미 +- **Git**: local에서 소스 코드의 변경 사항을 추적하고, 버전을 관리하는데 사용되는 도구이다. + +- **GitHub**: Git 저장소를 클라우드(원격 서버)에 호스팅하고, 여러 사용자가 협업할 수 있게 하는 서비스이다. GitHub를 사용하면 로컬 시스템뿐만 아니라 원격 서버에도 Git 저장소를 보유할 수 있다. + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. +- **Working Directory**: 현재 개발자가 작업하는 공간으로 현재 프로젝트의 소스코드 및 파일이 저장되어 있는 로컬 시스템의 디렉토리이다. Git은 여기에 있는 파일들의 변경사항을 추적하고 관리한다. + +- **Git Add**: Working Directory에 있는 변경 사항 중 일부를 Staging Area에 추가하는 명령이다. 이는 Git에게 해당 변경 사항을 다음 commit에 포함하는 것임을 알려준다. + +- **Git Commit**: Staging Area의 변경 사항을 로컬 저장소에 저장하는 명령어이다. 이는 변경 사항을 영구적으로 기록하고, commit 메시지와 함께 변경 사항의 스냅샷을 생성한다. + +- **Git Push**: 로컬 저장소에 있는 commit을 원격 저장소(예: GitHub)로 전송하는 명령이다. 이는 다른 개발자들과 변경 사항을 공유하거나, 백업을 위해 사용된다. + +- **Git Merge**: 두 개의 다른 branch를 병합하는 명령어이다. branch는 개발의 흐름을 나누어 관리하기 위한 독립적인 작업 공간으로 사용되는데, 두 branch의 변경 사항을 합치는 작업을 수행한다. + +- **Git Fetch**: 원격 저장소에서 최신 변경사항을 가져오는 명령어이다. 이는 로컬 저장소에는 변경 사항을 적용하지 않고, 단순히 원격 저장소의 상태를 확인하는 역할이다. 이후에 필요에 따라 Git Merge나 Git Pull과 함께 사용하여 로컬 저장소에 변경 사항을 반영할 수 있다. + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +- **commit**: Git에서 변경 사항을 영구적으로 기록하는 작업이다. 각 commit은 파일의 변경 사항을 스냅샷으로 기록하고, 해당 지점의 상태를 저장한다. commit을 통해 이전 상태로 rollback하거나 변경 이력을 추정할 수 있다. + +- **branch**: Git에서 병렬적인 작업을 수행하기 위한 개념이다. 각 branch는 독립적인 작업 경로를 나타내며, 개발자는 여러 branch를 생성하여 동시에 여러 기능을 개발할 수 있다. + +- **HEAD**: 현재 작업 중인 branch의 가장 최근 commit을 가리키는 포인터이다. + +- **Git checkout**: Working directory의 HEAD와 branch 간의 이동을 담당하는 명령어이다. + +### branch 관련 명령어 + +- **branch 생성**: + ```bash + # 새로운 브랜치 생성 + git branch + + # 새로운 브랜치 생성 후 해당 브랜치로 이동 + git checkout -b + ``` + +- **branch 삭제**: + ```bash + # 브랜치 삭제 + git branch -d + + # 강제로 브랜치 삭제 (변경 사항이 포함되지 않은 경우) + git branch -D + ``` + +- **branch 이동**: + ```bash + # 특정 브랜치로 이동 + git checkout + + # 새로운 브랜치 생성 후 해당 브랜치로 이동 + git checkout -b + ``` + +- **branch 목록 보기**: + ```bash + # 브랜치 목록 보기 + git branch + ``` + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +### Git init, Git clone +- **git init**: 새로운 프로젝트 디렉토리를 Git 저장소로 만들거나 기존 프로젝트를 Git으로 변환할 때 사용된다. 이 명령어를 실행하면 해당 디렉토리 내에 Git 저장소가 초기화되며, 이후에 변경 사항을 추적하고 commit할 수 있게 된다. + ```bash + cd 내_프로젝트_디렉토리 + git init + ``` + +- **git clone**: 원격 Git 저장소의 프로젝트를 로컬 시스템으로 복제할 때 사용된다. 이 명령어를 실행하면 원격 저장소의 모든 파일과 히스토리가 로컬 시스템으로 복제되어 프로젝트를 가져올 수 있다. + ```bash + git clone 원격_저장소_URL + git init + ``` + +### origin +- **origin**: Git에서 원격 저장소를 가리키는 별칭이다. 원격 저장소의 URL을 `origin`이라는 이름으로 참조할 수 있다. + +- **origin 설정 방법** + - `git clone` 명령을 사용하여 원격 저장소를 복사하면 Git은 자동으로 `origin`이라는 이름의 원격 저장소를 설정한다. 따라서 별도의 설정이 필요없다. + + - `git remote add` 명령으로 원격 저장소를 직접 추가한다면 아래의 명령어를 사용하여 `origin`이라는 이름의 원격 저장소를 설정할 수 있다. + ```bash + git remote add origin 원격_저장소_URL + ``` + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +### git reset +- reset 명령어는 대표적으로 commit을 `취소`하는 명령어이다. 또한 Staging 취소가 가능하다. 옵션에 따라 디테일한 설정이 가능하다. + +- 옵션 + - `--soft`: commit 취소, Staging 상태 유지 + - `--mixed`: commit 취소, Staging 취소, local은 변경 상태로 유지(옵션이 없을 시 default로 설정된다) + - `--hard`: commit 취소, Staging 취소, local 변경 상태 취소 +- HEAD의 옵션 (위의 3가지 옵션 뒤에 사용한다) + - `HEAD^`: 최신 커밋 취소 + - `HEAD~(수량)`: 수량에 숫자를 적으면 최근 커밋부터 해당 숫자까지 커밋 취소 +- 사용 예시 + ```bash + # 소프트 리셋 + git reset --soft HEAD^ + + # 믹스드 리셋 + git reset HEAD^ + git reset --mixed HEAD^ + + # 하드 리셋 + git reset --hard HEAD^ + ``` + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. +- **Pull Request**: 한 브랜치에서 작업한 코드를 메인 프로젝트에 병합(Merge)하기 위해 레포지토리 관리자나 다른 팀원에게 요청하는 과정이다. + + - 시나리오 + - branch 생성 및 작업 + - 변경 사항 commit 및 push + - pull request 생성 + - 팀원들과 토론 및 수정 + +- **Merge**: Pull Request를 통해 검토된 변경 사항을 실제로 적용하여 branch를 병합하는 것이다. + - 종류 + - Fast-Forward: main branch에 신규 커밋이 없는 경우, 최신 커밋이 있는 branch를 main branch로 하는 것이다. + ![fast-forward-merge](https://codingapple.com/wp-content/uploads/2022/06/%EA%B7%B8%EB%A6%BC3-4.png) + + - 3-Way Merge: branch마다 신규 commit이 1회 이상 있는 경우, merge 명령을 내리면 두 브랜치의 코드를 합쳐서 새로운 commit을 생성한다. + ![3-Way-merge](https://codingapple.com/wp-content/uploads/2022/06/merge1.png) + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. +- **rebase**: 신규 branch의 시작점을 main branch의 최근 commit으로 옮긴 다음 fast-forward merge를 하는 것이다. +![rebase](https://codingapple.com/wp-content/uploads/2022/06/merge3.png) + +- **유용한 때** + - branch가 너무 많을 때, 간단한 branch들을 rebase하면 commit history를 훨씬 깔끔하게 정리할 수 있다. + +- **rebase & merge 방법** + - 새로운 브랜치로 이동한다. + - `git rebase main`을 한다. + - 그러면 branch가 main branch 끝으로 이동하는 데 그것을 fast-forward merge 하면 된다. + ```bash + # 새로운 브랜치로 이동 + git switch 새로운_브랜치 + + # main으로 rebase + git rebase main + + # main branch로 이동 + git switch main + + # fast-forward merge 적용 (신규 커밋이 있는 branch를 main branch로 적용) + git merge 새로운브랜치 + ``` + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. +- **stash**: 현재 작업 중인 변경 사항을 일시적으로 저장하는 Git의 기능이다. 작업 중인 변경 사항을 commit하지 않고 보관할 수 있어서 다른 작업을 할 대 유리하다. + +- **관련 명령어** + - 현재 작업 중인 변경 사항을 일시적으로 저장 + ```bash + git stash + + # staging 된 것이든 안된 것이든 추적중인 파일은 다 이동된다. + # 파일들이 최근 commit 상태로 되돌아 간다. + ``` + + - 현재 stash 되어있는 코드 목록 출력 + ```bash + git stash list + ``` + + - 보관했던 코드 다시 불러오기 + ```bash + git stash pop + + # git stash 했던 코드가 여러개 있으면 가장 최근에 보관했던 코드부터 불러온다. + ``` + + - stash 삭제 + ```bash + # 특정 stash 삭제 + git stash drop 삭제할_id + + # 모든 stash 삭제 + git stash clear + ``` + + - 일부 코드만 git stash 하기 + ```bash + git stash -p + + # 파일을 훑어주면서 stash 할 지 의견을 물어보는데 y/n으로 잘 대답하면 된다. + ``` +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. +- pull request는 레포지토리를 fork한 상태에서만 가능할까? 레포지토리를 clone만 한 상태에는 pull request가 불가능할까? \ No newline at end of file diff --git a/git-basics/20th/README-pakjeongwoo.md b/git-basics/20th/README-pakjeongwoo.md new file mode 100644 index 0000000..12f90f3 --- /dev/null +++ b/git-basics/20th/README-pakjeongwoo.md @@ -0,0 +1,83 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. +로컬 저장소는 개발자의 컴퓨터에 있는 Git 저장소입니다. +원격 저장소는 GitHub와 같은 원격 서버에 호스팅된 Git 저장소입니다. + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. +Working Directory : 개발자가 작업하는 로컬의 디렉토리 +Git Add : 작업 디렉토리에서 변경된 파일을 스테이징 영역에 추가하는 명령어 +Git Commit : 스테이징 영역에 있는 변경사항을 로컬 저장소에 기록하는 명령어 +Git Push : 로컬 저장소에 커밋된 변경사항을 원격 저장소에 업로드하는 명령어 +Git Merge : 다른 브랜치의 변경 사항을 현재 브랜치에 통합하는 명령어 +Git Fetch : 원격 저장소의 최신 변경 사항을 로컬 저장소로 가져오는 명령어 + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. +branch 생성 : git branch +branch 삭제 : git branch -d 강제삭제시 -D 옵션사용 +branch 목록확인 : git branch -r하면 원격 저장소의 브랜치 목록을 알수있음 +HEAD : 현재 작업중인 브랜치를 가리키는 포인터 일반적으로 HEAD는 브랜치의 최신커밋을 가리킨다 +git checkout : 명령어는 브랜치 간 전환이나 특정 커밋으로 이동할 때 사용된다 + + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 +git clone : 이미 존재하는 원격 리포지토리를 로컬 컴퓨터에 복제할 때 사용 +git init : 로컬 컴퓨터에 새로운 Git 리포지토리를 초기화할 때 사용 +orgin : Git에서 원격 리포지토리의 기본 별칭 +설정방법 : git init으로 초기화한 로컬 리포지토리에서는 git remote add origin +차이점 : git clone은 원격 리포지토리를 복제하여 로컬에 생성하는 반면, git init은 로컬에 새로운 리포지토리를 초기화합니다 +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. +soft : 브랜치가 가리키는 커밋을 변경하지만, 스테이징 영역과 작업 디렉토리는 그대로 유지합니다. +mixed : 옵션은 브랜치가 가리키는 커밋을 변경하고, 스테이징 영역을 해당 커밋과 동일한 상태로 만듭니다. 작업 디렉토리는 그대로 유지됩니다. +hard : 브랜치가 가리키는 커밋을 변경하고, 스테이징 영역과 작업 디렉토리를 해당 커밋과 동일한 상태로 만듭니다. +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. +Pull Request : 자신의 변경 사항을 원본 리포지토리에 통합하기 위한 요청 +Merge : 두 개의 브랜치를 통합하는 과정 +Fast-Forward Merge : 브랜치의 변경 사항을 master 브랜치에 적용할 때, master 브랜치의 포인터를 브랜치의 최신 커밋으로 이동시키는 것으로 병합이 완료 +3-Way Merge : 두 브랜치의 공통 조상 커밋과 각 브랜치의 최신 커밋을 사용하여 병합이 이루어집니다. + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. +rebase : 브랜치의 베이스를 다른 커밋으로 변경하는 과정 +커밋 이력을 수정하고 싶을 때, 브랜치를 최신 상태로 유지하고 싶을 때, 원격 저장소에 푸시하기 전에 로컬 브랜치를 정리하고 싶을 때 + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. +git stash : 현재 작업 중인 변경 사항을 임시로 저장할 수 있는 명령어 +변경 사항 임시 저장하기, 저장된 변경 사항 확인하기, 저장된 변경 사항 적용하기 +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git a/git-basics/20th/README-uicheol.md b/git-basics/20th/README-uicheol.md new file mode 100644 index 0000000..91ccd63 --- /dev/null +++ b/git-basics/20th/README-uicheol.md @@ -0,0 +1,204 @@ +# Git 기초 + +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github + +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +local(로컬): 개발자가 작업하는 자신의 컴퓨터 환경을 의미함. +remote(원격): 다른 컴퓨터에 위치한 git 저장소로 github같은 서비스를 통해 호스팅됨. 다른 개발자와 협업을 가능하게함. + +git: 분산 버전 관리 시스템으로 소스코드의 변경사항을 추적, 관리하는 도구임. 개발자는 git을 사용해 로컬에서 프로젝트를 관리할 수 있다. +github: git 저장소를 호스팅하고 협업하는 웹 플랫폼으로 원격 저장소를 만들고 프로젝트를 공유하며 협업할 수 있다. + +## Git Workflow + +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +1. working directory + +- 개발자가 실제 파일을 작업하는 디렉토리 + +2. staging area + +- 변경된 파일을 임시로 준비하는 공간, 차후 commit할 변경사항들을 담고있다. + +3. local repository + +- staging area의 변경사항을 저장하는 레포지토리, 개발자의 컴퓨터에 위치한다. +- git commit 명령어를 통해 staging area에 있는 변경사항을 로컬에 저장한다. + +4. remote repository + +- github의 레포지토리를 의미 +- git push 명령어를 통해 local repository에 저장해둔 변경사항을 remote repository(github)에 올려준다. + +1. `git add` + +- 변경사항을 staging area에 추가함. + +2. `git commit` + +- staging area에 추가된 변경사항들을 local repository에 저장함. + +3. `git push` + +- local repo에 있던 변경사항을 remote repo(github)에 올림. + +## Branch, HEAD + +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +1. branch + +- 코드의 분기를 나타내는 개념, 작업을 독립적으로 진행시키기 위해 브랜치를 생성한다. +- 브랜치는 만들거나 삭제, 이동이 가능함. + +생성: `git branch ` +삭제: `git branch -d ` +이동: `git checkout ` +생성 및 이동: `git checkout -b ` + +2. HEAD + +- 현재 작업중인 커밋의 상태를 가리키며, 변경사항을 추가하거나 커밋할 때 사용됨. + +## clone, init, origin + +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. + +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +1. `git clone` + +- remote repo(github)의 프로젝트를 local repo로 클론함. +- 이때 origin은 remote repo의 기본 이름임. + +2. `git init` + +- 새로운 local repo를 생성함. 이미 존재하는 프로젝트를 git으로 관리하려거나, 새로운 프로젝트를 시작할때 로컬 디렉토리를 git 저장소로 초기화할때 사용함. +- 현재 디렉토리를 git 저장소로 초기화하며, '.git'이라는 폴더가 생성됨. + +3. origin + +- git에서 remote repo의 기본 이름이다. git clone을 할 때 remote repo의 이름이 origin으로 자동 설정됨. +- origin은 remote repo의 url 변수이다. +- `git remote add origin ` 을 통해 remote repo url을 설정할 수 있다. + +## reset + +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +reset은 되돌아가는 것이다. +3가지는 working directory, staging area, repo가 어디까지 되돌아가는가에 따라 다르다. + +| | `git reset --soft` | `git reset --mixed` | `git reset --hard` | +| ----------------- | ------------------ | ------------------- | ------------------ | +| working directory | 그대로 남음 | 그대로 남음 | 이전 상태 | +| staging area | 그대로 남음 | 이전 상태 | 이전 상태 | +| repository | 이전 상태 | 이전 상태 | 이전 상태 | + +## Pull Request, Merge + +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. + +pull request + +- 다른 branch에서 작업한 내용들을 기존 코드에 병합하기 전 리뷰와 토론을 요청하는 기능. +- 변경사항에 대해 검토가 완료되면, 병합될 수 있다. + +merge + +1. fast-forward merge + +- main branch에 신규 커밋이 없는 경우, branch의 최신 커밋을 main branch으로만 바꿔주면 간단하게 merge를 진행할 수 있다. + +2. 3-way merge + +- main branch와 나의 branch에 각각 신규 커밋이 있을 때, main에 새로운 commit을 생성하면서 각 branch의 신규 커밋들을 합쳐준다. + +## rebase + +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +rebase + +- git에서 branch의 위치를 재정렬 하는 것을 말함. +- branch를 깔끔하게 정리하는데 좋다. +- rebase 후 fast-forward merge를 해서 branch를 정리한다. +- 아래 명령어로 branch를 main으로 rebase 후 fast-forward merge 할 수 있다. + ''' + git checkout + git rebase main + git checkout main + git merge + ''' + +## stash + +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +1. 임시로 변경사항을 저장하고 다른 작업 수행 + +- 현재 작업중인데 다른 branch로 이동해야하는 경우, 변경사항을 commit하지 않고 다른 branch로 이동가능. +- 'git stash'를 이용해 변경사항을 임시로 저장한 후 다른 branch로 이동하고, 작업 수행 후 stash에 있는 변경사항을 다시 가져올 수 있다. + +2. 작업중인 변경사항을 정리하고 임시로 저장 + +- 여러개의 파일을 수정하고 있을 때, 일부 변경사항을 commit 하기전 다른 변경사항을 진행해야하는 경우, 변경사항을 'git stash'를 사용해 작업중인 파일을 임시로 저장할 수 있다. + +3. 변경사항을 임시로 저장하고 충돌 해결 + +- merge나 rebase를 수행하는 동안 conflict가 발생하는 경우, 충돌을 해결하기 전 변경사항을 'git stash'로 임시로 저장할 수 있다. +- 충돌을 해결한 후 변경사항을 다시 적용할 수 있다. + +`git stash` +: 현재 작업 중인 변경사항을 스택에 임시로 저장 + +`git stash list` +: stash list 확인 + +`git stash pop` +: 가장 최근 stash를 pop해 적용함 + +`git stash apply ` +: 특정 stash를 적용 + +`git stash drop ` +: 특정 stash 삭제 + +`git stash clear` +: 모든 stash 삭제 + +## Advanced + +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. + +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions + +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git a/git-basics/20th/README-yongjin.md b/git-basics/20th/README-yongjin.md new file mode 100644 index 0000000..66a3aa9 --- /dev/null +++ b/git-basics/20th/README-yongjin.md @@ -0,0 +1,139 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. +Git은 분산 버전 관리 시스템이며, 코드를 추적하고 관리하는 데 사용됩니다. +GitHub는 Git 저장소를 호스팅하고 협업을 촉진하는 온라인 플랫폼입니다 + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. + Working Directory (작업 디렉토리): + 작업 중인 프로젝트의 실제 파일이 저장되는 디렉토리입니다. + 이 디렉토리 내에서 파일을 생성, 수정, 삭제 등의 작업을 수행합니다. + + Git Add: + 작업 디렉토리에서 변경된 파일을 스테이징 영역에 추가하는 명령입니다. + 변경 내용을 Git이 추적할 수 있도록 하며, 스테이징 영역에 추가된 파일은 다음 커밋에 포함됩니다. + + Git Commit: + 스테이징 영역에 있는 변경 사항을 로컬 저장소에 영구적으로 저장하는 명령입니다. + 변경 내용에 대한 설명과 함께 커밋 메시지를 작성하여 기록합니다. + 커밋은 프로젝트의 버전 히스토리를 관리하고 추적하는 데 사용됩니다. + + Git Push: + 로컬 저장소에 있는 변경 사항을 원격 저장소로 전송하는 명령입니다. + 다른 개발자와 변경 사항을 공유하거나, 백업을 만들기 위해 사용됩니다. + 원격 저장소로 푸시하면 다른 개발자가 변경 사항을 가져올 수 있게 됩니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. + Branch (브랜치): + + 프로젝트의 특정 작업이나 기능을 분리하여 독립적으로 개발하기 위한 개념입니다. + 기존의 커밋 기록을 기반으로 새로운 브랜치를 생성할 수 있습니다. + 각 브랜치는 프로젝트의 특정 상태를 나타내며, 독립적으로 변경되고 관리됩니다. + +HEAD: + + 현재 작업 중인 브랜치의 가장 최근 커밋을 가리키는 포인터입니다. + HEAD는 작업 디렉토리에서 작업하는 중인 커밋을 가리킵니다. + +Git Checkout: + + 특정 브랜치로 이동하거나, 커밋의 상태를 볼 때 사용하는 명령어입니다. + git checkout 명령어를 사용하여 다른 브랜치로 이동할 수 있습니다. + 또한 git checkout 를 사용하여 특정 커밋의 상태를 확인할 수도 있습니다. + + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. + Git Clone: + 기존에 원격 저장소에 있는 프로젝트를 로컬로 복제하는 명령어입니다. + 주로 GitHub, GitLab, Bitbucket 등의 원격 저장소를 복제할 때 사용됩니다. + 사용 방법: git clone <원격 저장소 URL> 명령어를 사용하여 실행합니다. + + Git Init: + 로컬 디렉토리를 Git 저장소로 초기화하는 명령어입니다. + 새로운 프로젝트를 시작하거나, 기존 프로젝트를 Git으로 관리하기 시작할 때 사용됩니다. + 사용 방법: git init 명령어를 사용하여 실행합니다. 이 명령어를 실행한 디렉토리가 Git 저장소로 초기화됩니다. + Origin + + Origin은 일반적으로 원격 저장소를 가리키는 단어입니다. 주로 Git에서 기본적으로 설정되는 원격 저장소의 별칭으로 사용됩니다. + 원격 저장소의 URL을 복제하거나 저장소에 푸시할 때 사용됩니다. + 원격 저장소를 설정할 때 보통 "origin"이라는 이름으로 설정됩니다. +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) + Soft Reset (소프트 리셋): + Soft Reset은 HEAD를 이전 커밋으로 이동시키지만, 변경 내용을 유지합니다. + 변경 내용은 스테이징 영역에 그대로 남아 있습니다. + 주로 최신 커밋을 취소하고, 변경 내용을 다시 스테이징 영역에 추가하기 위해 사용됩니다. + 사용 방법: git reset --soft HEAD~1 + + Mixed Reset (믹스드 리셋): + Mixed Reset은 HEAD를 이전 커밋으로 이동시키며, 변경 내용을 unstaged 상태로 되돌립니다. + 변경 내용은 로컬 저장소에는 그대로 남아 있지만, 스테이징 영역에서는 사라집니다. + 주로 최신 커밋을 취소하고, 변경 내용을 다시 수정한 후 다시 스테이징하는 경우에 사용됩니다. + 사용 방법: git reset HEAD~1 + + Hard Reset (하드 리셋): + Hard Reset은 HEAD를 이전 커밋으로 이동시키며, 변경 내용을 완전히 삭제합니다. + 변경 내용은 로컬 저장소와 작업 디렉토리에서 모두 삭제됩니다. + 주로 최신 커밋을 완전히 취소하고 이전 상태로 되돌리는 경우에 사용됩니다. 주의가 필요한 명령어입니다. + 사용 방법: git reset --hard HEAD~1 + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request (풀 리퀘스트): + + Pull Request는 코드 변경 사항을 다른 개발자들에게 검토하고 병합하기 위해 사용되는 기능입니다. + 주로 협업하는 프로젝트에서 개발자들 간에 코드 리뷰와 피드백을 주고받는 데 사용됩니다. + +Merge (병합): + + Merge는 두 개의 다른 브랜치를 하나로 합치는 것을 의미합니다. + 주로 Pull Request를 통해 코드 검토를 완료하고, 브랜치를 기존 브랜치에 병합할 때 사용됩니다. + +Fast-Forward Merge (패스트 포워드 병합): + + Fast-Forward Merge는 두 브랜치가 일직선적인 관계에 있을 때 발생하는 병합 방식입니다. + 즉, 기존 브랜치의 커밋 기록이 단순히 앞으로 이동하면 되는 경우에 사용됩니다. + 별도의 병합 커밋이 생성되지 않고, 단순히 HEAD를 이동시켜서 기존 브랜치의 커밋 기록을 통합합니다. + +3-Way Merge (3-way 병합): + + 3-Way Merge는 두 브랜치가 서로 다른 변경 사항을 가지고 있을 때 발생하는 병합 방식입니다. + 즉, 각 브랜치에서 변경된 내용을 비교하여 자동으로 최종 결과물을 생성합니다. + 병합 커밋이 생성되며, 충돌이 발생할 수 있으며 이를 해결해야 합니다. + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +Rebase (리베이스): + +Rebase는 Git에서 브랜치의 기록을 재배치하거나 합치는 작업을 의미합니다. 특히, 다른 브랜치의 변경 내용을 현재 브랜치의 기록에 적용할 때 사용됩니다. + + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +Git Stash 활용 방법: + +Git Stash는 현재 작업 중인 변경 사항을 임시로 보관하고, 깨끗한 작업 디렉토리에서 작업할 수 있도록 도와주는 기능입니다. 주로 작업 중에 갑작스런 다른 작업을 해야 할 때나, 브랜치를 변경해야 할 때 유용합니다 + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git "a/git-basics/20th/README-\354\213\240\354\230\201\354\204\234.md" "b/git-basics/20th/README-\354\213\240\354\230\201\354\204\234.md" new file mode 100644 index 0000000..c7ab75c --- /dev/null +++ "b/git-basics/20th/README-\354\213\240\354\230\201\354\204\234.md" @@ -0,0 +1,200 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +> * git = 소스 코드 버전 관리 시스템 입니다 +> * 버전 관리 = 내가 원하는 시점의 작업물로 이동할 수 있다는 것을 의미합니다 +> * 로컬 컴퓨터에서 실행되며 저장할 수 있는 공간이 있다면 어디에나 저장 할 수 있습니다 (로컬 컴퓨터, USB, 클라우드 서버, 인터넷 등) +> +> * github = 깃으로 관리하는 프로젝트를 온라인 상에 올려둘 수 있는 사이트 입니다 +> * 시간, 공간의 제약이 없습니다 + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +> ### Working Directory +> * 현재 작업하고 있는 영역. 즉, 작업을 하고 있는 프로젝트 디렉토리 +> * untrackted 상태 : 파일이 Git에 의해서 그 변동사항들이 추적되지 않고 있는 상태 +> +> ### Git Add +> * 작업 디렉토리(working directory) 상의 변경 내용을 스테이징 영역(staging area)에 추가하기 위해서 사용하는 Git 명령어 +> * staging 영역 - 커밋할 준비가 된 변경 내용이 Git 저장소에 기록되기 전에 대기하는 장소 +> * trackted 상태 +> * git add 명령어를 많이 실행해도 Git 저장소의 변경 이력에는 어떤 영향도 주지 않음 +> * 장점 : 작업 디렉토리에 있는 변경 내용을 한 번에 몽땅 기록하지 않고, 조금씩 나누어서 기록할 수 있다 +> +> ### Git Commit +> * 의미있는 변경 작업들을 깃(저장소)에 기록하는 동작 +> * 스냅샷 방식 - 새롭게 변경된 부분만 추출해서 저장 +> * HEAD 포인터 - 최종적인 커밋 작업의 위치 +> +> ### Git Push +> * 원격 저장소(remote repository)에 코드 변경분을 업로드하기 위해서 사용하는 Git 명령어 +> * 새로운 branch 최초 push 사용법 +> ``` git +> git push --set-upstream <저장소명> <브렌치명> +> ``` + + + + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +> ### branch +> 여러 개발자들이 각자 독립적인 작업 영역(저장소) 안에서 마음대로 소스코드를 변경 가능하도록 함 +> 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않음 +> ``` +>#생성 +> git branch <브랜치 이름> +> +>#이동 +>git checkout <브랜치 이름> +> +>#로컬 브랜치 삭제 (다른 브랜치로 이동 후) +>git branch -d <로컬 브랜치 이름> +> +>#원격 브랜치 삭제 +>git push <원격 저장소 이름> -d <원격 브랜치 이름> +>``` +> >Checkout +> >독립된 작업 공간인 브랜치를 자유롭게 이동할 수 있다. +> >``` +> >git checkout <브랜치 이름> +> >``` +> +> >Head +> >현재 사용 중인 브랜치의 선두 부분을 나타내는 이름 +> +> >Merge +> >여러 개의 브랜치를 하나로 모을 수 있음 +> >``` +> >git merge <합칠 브랜치 이름> +> >``` + + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +> ### git clone +> - 내 컴퓨터에 없는 Git 저장소를 복사해오는 명령어 +> ``` +> git clone <원격 저장소 url> +> ``` +> - 프로젝트에 대한 모든 데이터와 히스토리 가져옴 +> - 원격 저장소의 기본 브랜치만 확인할 수 있음 +> ### git init +> - 내 컴퓨터의 현재 디렉토리를 Git 저장소로 초기화하는 명령어 +> ``` +> git init +> ``` +> - 현재 디렉토리에 .git이라는 숨김 파일이 생성되고 Git의 내부 db가 생성 + +> ### origin +> - 원격 저장소(URL)의 단축 이름이다 +> - 저장소를 Clone하면 단축 이름이 자동으로 origin이라고 등록된다 +> - 존재 이유 - add,commit,push,pull을 통해 remote repository와 협업을 할 떄 remote repository의 URL을 일일이 입력하는 대신 별칭(alias)를 사용하는 것 + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. +>### git reset +>커밋을 되돌리거나 작업 디렉토리와 스테이징 영역을 조작하는 데 사용 +>HEAD의 위치를 현재 커밋에서 과거 커밋으로, 미래 커밋으로 이동시킬 수 있음 +> +>1. --hard 옵션 +>돌아간 시점의 커밋 바로 직후의 상태로 완전히 초기화하는 옵션 +>Working Directory에 생성한 파일까지 모두 삭제 +>--- +>2. --mixed 옵션 (default) +>Working Directory까지만 초기화하는 옵션 +>변경사항을 감지하지만, add와 commit이 되어 있지 않음 +>--- +>3. --soft 옵션 +>Staging Area까지 초기화하는 옵션 +>add는 되어있지만, commit이 되어있지 않는 상태 + + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. +>### Pull Request +>내가 수정한 코드가 있으니(push) 저장소 관리자에게 내 branch를 가져가 검토 후 병합해주라고(Merge) 요청 해주는 것 +> +>### Merge +> 서로 다른 브랜치에서 작업을 했거나, 작업 내용을 합쳐야 하는 경우 사용 +> 1. Fast-Forward 방식 +> merge 명령어를 실행하는 브랜치의 Head Commit이 병합 되는 브랜치의 Head commit으로 이동되는 방식 +> -> merge commit 이력이 남지 않음 +> master branch에서 새로운 브랜치 하나를 생성 한 후에 master branch는 더이상 커밋하지 않은 경우 사용 +> --- +> 2. 3-Way Merge 방식 +> 각 브랜치의 마지막 커밋 두 개와 공통 조상의 총 3개의 커밋을 이용하여 병합하는 방식 +> 공통 조상까지 비교해야 더 명확한 변경 상태를 알 수 있음 +> 서로 다른 브랜치가 동일 선상이 아닐 경우 사용 +> +> 충돌이 발생하면 일반적으로 <<<<<<<, =======, >>>>>>>와 같은 마커로 표시 + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. +> rebase란 공통 Base를 가진 두 개의 Branch에서 한 Branch의 Base를 다른 Branch의 최신 커밋으로 Base를 옮기는 작업이다 +> #### 장점 +> - 공유 branch의 최신 변경사항을 즉각 반영 +> - 커밋 이력이 남지 않을므로 commit history가 시간순서대로 반영되어 간단해짐 +> #### 유용한 경우 +> - 내가 작업하던 브랜치에 main 브랜치 내용이 필요해서 적용시키고 싶을 때 사용 + + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. +> git stash란 변경사항을 일시적으로 저장하는 기능 +> 커밋하기엔 이른 경우, 다른 브랜치로 체크아웃하는데 변경사항을 유지하고 싶을 경우 사용 +> +> ``` git stash ``` +> 현재 작업 중인 변경 사항을 일시적으로 저장하고 스택에 쌓음 +> 작업 디렉토리를 깨끗한 상태로 만듦 +> +> ``` git stash apply ``` +> 스택에 쌓인 가장 최근의 변경 사항을 불러와 작업 디렉토리에 적용, 스택에 남아있음 +> +> ```git stash drop ``` +> ```git stash drop [stash 이름] ``` +> 스택에 남아있는 stash 제거 +> +> ``` git stash pop ``` +> ``` git stash pop {index 번호} ``` +> 스택에 쌓인 가장 최근의 변경 사항을 불러와 작업 디렉토리에 적용, 스택에서 제거 +> +> ``` git stash list ``` +> 현재 stash들의 목록 + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. +> commit 만으로도 변경사항을 저장하고 버전관리가 가능한데 staging 영역이 있는 이유가 궁금합니다 \ No newline at end of file diff --git a/git-basics/20th/REAMDE-JANGHYUNTAE.md b/git-basics/20th/REAMDE-JANGHYUNTAE.md new file mode 100644 index 0000000..0420621 --- /dev/null +++ b/git-basics/20th/REAMDE-JANGHYUNTAE.md @@ -0,0 +1,201 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +★Git + +- 오픈 소스 버전관리 시스템 +-로컬에서 버전 관리 +- 소프트웨어 개발 및 소스 코드 관리에 사용 +git은 브랜치를 생성 이전 브랜치로 복구,삭제,병합 가능. +하지만 로컬 저장소를 사용하기 때문에 다른 개발자와 실시간으로 작업을 공유할 수 없습니다. + + +★Git hub +- Git을 사용하는 프로젝트를 지원하는 웹 호스팅 서비스 +- 클라우드 서버를 사용해서 로컬에서 버전 관리한 소스코드를 공유 가능 +- 분산 버전 제어, 액세스 제어, 버그 추적 작업 관리를 제공 + + +Git은 버전 관리 프로그램이고, Github는 버전 관리,소스코드 공유가 가능한 원격 저장소 입니다. + + + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. + +Git Merge, Git Fetch는 생략해도 됩니다. + +★Working Directory (작업 디렉토리): + + - 현재 작업 중인 프로젝트의 실제 파일이 저장된 디렉토리입니다. 작업 디렉토리 내에서 파일을 수정하고 변경을 추적하는 것이 Git의 주요 목적 중 하나입니다. + +★Git Add: +- Git Add 명령어는 작업 디렉토리에서 파일을 스테이징 영역(Staging Area 또는 Index라고도 함)으로 추가합니다. 이 단계에서 Git은 스테이징 영역에 추가된 파일의 변경 사항을 추적하게 됩니다. +★Git Commit: +- Git Commit 명령어는 스테이징 영역에 있는 변경 사항을 로컬 저장소에 영구적으로 저장합니다. 이러한 커밋은 프로젝트의 버전 히스토리를 만듭니다. 각 커밋은 메시지와 함께 설명되어야 합니다. + +★Git Push: +- Git Push 명령어는 로컬 저장소의 커밋을 원격 저장소로 전송합니다. +이것은 다른 개발자들과 작업을 공유하거나, +작업한 내용을 원격 저장소에 백업하는 데 사용됩니다. 주로 Git 서버에 변경 사항을 업로드하는 데 사용됩니다. +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +★커밋(Commit): + +- 커밋은 프로젝트의 변경 사항을 저장하는 기록입니다. +각 커밋은 고유한 해시값을 가지며, 변경된 내용, 작성자, 작성 일시 등의 정보를 포함합니다.\ +커밋을 통해 프로젝트의 특정 시점의 상태를 저장하고 관리할 수 있습니다. + +★브랜치(Branch): + +- 브랜치는 커밋의 참조로, 프로젝트의 특정 기능 또는 작업을 개발하는 독립적인 경로를 나타냅니다. +각 브랜치는 커밋의 연속으로 이루어져 있으며, 하나의 브랜치에서 다른 브랜치로 전환할 수 있습니다.\ +브랜치를 통해 여러 작업을 병렬로 진행하거나, 실험적인 변경을 테스트할 수 있습니다. + +★HEAD: + +- HEAD는 현재 작업 중인 브랜치를 가리키는 포인터입니다. +HEAD는 일반적으로 최신 커밋을 가리키며, 작업 디렉토리에 반영되는 변경 사항은 HEAD가 가리키는 커밋에 따라 결정됩니다. +★git checkout: + +- git checkout 명령어는 브랜치를 변경하거나 특정 커밋으로부터 파일을 되돌리는 데 사용됩니다.\ +브랜치를 변경할 때는 새로운 브랜치를 만들거나 기존의 브랜치로 전환할 수 있습니다.\ +특정 커밋으로부터 파일을 되돌릴 때는 해당 커밋의 상태로 작업 디렉토리를 복원합니다. + +브랜치 생성, 삭제, 이동 +- +브랜치 생성: git branch + +브랜치 삭제: git branch -d + +브랜치 이동: git checkout + + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +★git clone vs git init★ + +★git clone: +- 이미 존재하는 원격 저장소의 내용을 로컬로 복제합니다. 원격 저장소에서 모든 히스토리와 브랜치를 가져옵니다. +bash +Copy code +git clone + +★git reset --mixed +- 명령어를 사용합니다. (기본값) +이 명령어는 HEAD를 특정 커밋으로 이동시키고, 해당 커밋 이후의 변경 사항을 스테이징 영역에 유지하지 않습니다. +변경 사항은 작업 디렉토리에 유지되며, 스테이징 영역에서 삭제됩니다. +이후에 변경 사항을 스테이징하고 다시 커밋할 수 있습니다. + + +★git reset --hard +- 명령어를 사용합니다. +이 명령어는 HEAD를 특정 커밋으로 이동시키고, 해당 커밋 이후의 변경 사항을 모두 삭제합니다. +스테이징 영역과 작업 디렉토리의 변경 사항이 모두 제거되므로 주의해야 합니다. + 다시 되돌릴 수 없는 변경 사항을 삭제할 때 사용합니다. + + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. +★Pull Request (풀 리퀘스트): + +- Pull Request는 코드 변경 사항을 다른 개발자들과 검토하고 병합하기 위해 사용됩니다. +일반적으로 Pull Request는 원격 저장소(예: GitHub, GitLab)에서 생성되며, 코드 변경 사항을 포함한 특정 브랜치를 기준으로 다른 브랜치로 병합하고자 할 때 사용됩니다. +Pull Request를 생성하면 다른 개발자들이 변경 사항을 검토하고 논의할 수 있으며, 코드 변경 사항에 대한 피드백을 주고 받을 수 있습니다. + +Merge (병합): + +- Merge는 두 개의 다른 브랜치를 하나로 합치는 과정을 의미합니다. +Git에서는 주로 두 가지 타입의 Merge가 사용됩니다: + +★Fast-Forward Merge와 3-Way Merge. + +★Fast-Forward Merge: + +- Fast-Forward Merge는 브랜치 간의 차이가 없는 경우에만 발생합니다. +예를 들어, 특정 브랜치에서 작업한 변경 사항을 모두 커밋하고, 해당 브랜치가 기준 브랜치의 최신 커밋을 가리키게 될 때 Fast-Forward Merge가 발생합니다. +이 경우 Git은 단순히 브랜치 포인터를 앞으로 이동시켜 기준 브랜치의 최신 커밋을 가리키게 합니다. + +★3-Way Merge: + +- 3-Way Merge는 두 브랜치 간에 충돌이 발생할 때 사용됩니다. +예를 들어, 두 개의 브랜치에서 동일한 파일의 동일한 부분을 동시에 수정한 경우에 충돌이 발생합니다.\ +Git은 두 브랜치의 공통 조상 커밋을 찾아내고, 각 변경 사항을 비교하여 충돌을 해결합니다.\ +충돌이 발생한 파일에 대해 개발자가 직접 수정하고 충돌을 해결한 후, +수정 사항을 다시 커밋하여 Merge를 완료할 수 있습니다. +\ +Pull Request와 Merge를 통해 팀원들 간의 협업을 원활하게 할 수 있으며, 코드 변경 사항을 효율적으로 검토하고 병합할 수 있습니다. Fast-Forward Merge는 단순한 상황에서 사용되며, 3-Way Merge는 충돌이 발생한 경우에 사용됩니다. + + + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +★Rebase +- Git에서의 Rebase(리베이스)는 브랜치의 커밋 히스토리를 재정렬하거나 변경하는 작업을 의미합니다. 기본적으로 Rebase는 두 브랜치를 합치는 Merge 작업과 유사하지만,커밋 히스토리를 보다 깔끔하게 유지할 수 있도록 도와줍니다. + +★Rebase를 사용하는 경우에는 보통 다음과 같은 상황에서 유용합니다: + +★커밋 히스토리 정리: + +- 여러 개의 작은 커밋을 하나의 큰 커밋으로 합치거나, 불필요한 중간 커밋을 삭제할 때 Rebase를 사용할 수 있습니다. +이를 통해 브랜치의 커밋 히스토리를 보다 깔끔하고 의미 있게 관리할 수 있습니다. + +★베이스 변경: + +- 현재 브랜치가 다른 브랜치의 최신 상태를 반영해야 할 때 Rebase를 사용할 수 있습니다. +예를 들어, 기능 브랜치를 개발하는 동안 메인 브랜치가 업데이트된 경우, 기능 브랜치를 메인 브랜치의 최신 상태로 리베이스하여 충돌을 최소화하고 통합할 수 있습니다. + +★병합 충돌 최소화: + +- Rebase를 사용하면 Merge와 달리 두 브랜치의 공통 조상부터 변경 사항을 적용하기 때문에, 충돌이 발생할 가능성이 낮아집니다. +따라서 Rebase를 사용하여 병합 충돌을 최소화하고, 코드를 더 빠르고 쉽게 통합할 수 있습니다. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +★Stash +- 현재 작업 중인 변경 사항을 임시로 저장하고, 작업 디렉토리를 깨끗한 상태로 만들어주는 Git의 유용한 기능입니다. 변경 사항을 나중에 다시 적용하고 싶을 때 사용됩니다. + +★ 명령어 모음 +- $git stash +// git stash (변경 내용 임시저장하기) + +- $git stash list +(내가 stash 했던 내용 보기) + +- $git stash apply +(가장 최근 stash 가지고 오기) +- $git stash drop (가장 최근 stash 지우기) + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. \ No newline at end of file diff --git a/git-basics/20th/image-1.png b/git-basics/20th/image-1.png new file mode 100644 index 0000000..40c3a35 Binary files /dev/null and b/git-basics/20th/image-1.png differ diff --git a/git-basics/20th/image-2.png b/git-basics/20th/image-2.png new file mode 100644 index 0000000..9dcbb13 Binary files /dev/null and b/git-basics/20th/image-2.png differ diff --git a/git-basics/20th/image.png b/git-basics/20th/image.png new file mode 100644 index 0000000..f226978 Binary files /dev/null and b/git-basics/20th/image.png differ diff --git a/git-basics/22nd/README-BYENGCHAN.md b/git-basics/22nd/README-BYENGCHAN.md new file mode 100644 index 0000000..fb3f969 --- /dev/null +++ b/git-basics/22nd/README-BYENGCHAN.md @@ -0,0 +1,192 @@ +## Git 과 Github의 차이 + +### Git + +- 버전 관리 소프트웨어 + +프로젝트의 수정한 코드가 동작하지 않을 때 버전을 롤백 할 수 있음 + +로컬 저장소의 모든 변경사항을 기록하여 파일의 버전관리 + +### Github + +- Git을 사용하는 프로젝트를 지원하는 **웹 호스팅 서비스**이다. + +Git은 **로컬(local)** 저장소에서 작동하여 다른 개발자와 작업을 공유하고 협업하기 어렵다. + +Github은 웹 상에서 클라우드 서버(**원격(remote)** 서버)를 통해 **로컬(local)** 저장소의 코드를 업로드하고 공유할 수 있다. + +다른 사람들과 작업물 공유 및 사용할 수 있다. + +## Git Workflow + + + +### Git 파일의 상태 + +Git은 파일을 크게 `Commited`, `Modified`, `Staged`의 세 가지 상태로 관리함 + +| 상태 | 설명 | +| -------- | --------------------------------------------------- | +| Commited | 데이터가 로컬 저장소에 안전하게 저장됨 | +| Modified | 수정한 파일을 아직 로컬 저장소에 커밋하지 않은 상태 | +| Staged | 수정한 파일을 곧 commit 할 것이라고 표시한 상태 | + +Git Directory(Repostiry)는 현재 작업하는 디렉터리에서 파일을 가져와 **Working Directory**를 만듭니다. + +1. Working Directory에서 파일을 수정 +2. 수정한 파일을 git add 로 Staging Area에 올림 +3. Staging Area에 있는 파일들을 git commit으로 Repository에 영구적으로 저장 + +### add / commit / push 의 차이 + +| 명령어 | 설명 | +| ------------ | ---------------------------------------------------------- | +| `git add` | 다음 변경을 기록할 때 까지 변경 내용을 모아놓기 위해 사용 | +| `git commit` | 변경 내용을 로컬 repositry에 기록(내 컴퓨터의 로컬 저장소) | +| `git push` | 변경 내용을 원격 repositry에 기록 (github) | + +`git add` 명령어를 통해 Staging Area로 변경 내용의 일부 혹은 전부를 이동시킨다. + +`git status` 명령어를 통해 현재 Working Directory와 Staging Area의 상태를 확인할 수 있다. + +Staging Area에 들어간 변경 내용을 `git commit`으로 로컬 저장소에 기록한다. + +`git push`로 원격 저장소에 업데이트 할 수 있다. + +## Branch, HEAD + +- Branch: 특정 커밋을 가리키는 포인터 +- HEAD: 현재 작업 중인 브랜치를 가리키는 포인터 + - 일반적으로 현재 체크아웃된 브랜치를 나타냄 + +```cmd +git branch <생성할 브랜치명> +``` + +- 브랜치 생성 +- 브랜치명에는 공백이 들어가면 안된다. + +- 브랜치 전환 + +```cmd +git switch <전환할 브랜치명> +Git 2.23 이후 추천방식 +git checkout <전환할 브랜치명> +``` + +- 브랜치 전환 + +```cmd +git checkout -c <브랜치명> +``` + +- 브랜치 생성 후 바로 이동 + +```cmd +git branch -d <브랜치명> +강제삭제 +git branch -D 브랜치이름 +``` + +- 병합이 완료된 브랜치 삭제 +- 병합이 완료되지 않으면 -D 사용 + +## clone, init, origin + +git 저장소 생성 방법에는 `git init` 방식과 `git clone` 방식이 있다 + +| 명령어 | `git clone` | `git init` | +| ----------- | ---------------------------------------------- | --------------------------- | +| 용도 | 기존 원격 저장소를 복제 | 새로운 로컬 레포지토리 생성 | +| 동작방식 | 원격 저장소의 전체 데이터를 가져와 로컬에 복사 | 빈 Git 저장소를 생성 | +| origin 설정 | 자동으로 origin 설정 | 원격 저장소 없음(수동) | + +### origin 이란? + +- 원격 저장소의 기본 이름 +- `git clone`을 사용하면 자동으로 origin 설정 +- `git init`을 사용하면 직접 origin 설정 + +## reset + +### 1. `--soft` + +- HEAD가 특정 커밋(과거 또는 미래)을 새롭게 가리킨다. +- 현재 작업 중인 working directory, stagin area는 영향 받지 않음 X + +### 2. `--mixed` + +- HEAD가 특정 커밋(과거 또는 미래)을 새롭게 가리킨다. +- staging area도 해당 커밋의 모습과 동일하게 변한다. +- working directory는 영향 받지 않는다 X + +### 3. `--hard` + +- HEAD가 특정 커밋(과거 또는 미래)을 새롭게 가리킨다. +- staging area , working directory 모두 해당 커밋의 모습과 동일하게 변함. + +## Pull Request, Merge + +### Merge란? + +- 두 개의 브랜치를 합치는 과정 + - `git merge <브랜치명>` + - Fast-Forward Merge & 3-Way Merge 두 가지 방식이 존재 + +1. 3-way merge + +- 브랜치마다 신규 커밋이 하나 이상 있는 경우, 새로운 커밋을 생성하며 합쳐줌 + + + +2. fast-forward merge + +- 메인브랜치에 신규 커밋이 없는 경우, 그냥 브랜치의 최신 커밋을 main브랜치에 하기로 한다. + + + +### PR이란? + +- 코드 변경 사항을 병합(Merge) 하기 전 검토하는 과정 +- 병합 전 코드 리뷰 받을 수 있음 + +## rebase + +- Git에서 한 브랜치에서 다른 브랜치로 합치는 방법은 Merge와 Rebase 두 가지 있다. +- 둘 다 실행 결과는 같지만 커밋 히스토리가 달라짐. +- merge는 히스토리가 지저분함, But Rebase는 잘 모르고 사용하지만 않으면 히스토리를 깔끔하게 관리할 수 있다. +- base를 새롭게 설정한다. + +## stash + +- 작업중인 사항을 잠시 치워두는 방법 +- 잠시 코드를 보관한 후, 내가 원하는 branch에 적용할 수 있다 + +### 사용하는 이유 + +- 변경사항을 커밋하기엔 아직 이른 경우 +- 다른 브랜치로 체크아웃할 때 변경사항을 유지하고 싶은 경우 +- 변경사항을 일시적으로 저장하고 싶은 경우 + +## Advanced + +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. + +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions + +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. + +``` + +``` diff --git a/git-basics/22nd/README-SONJEONGHUN.md b/git-basics/22nd/README-SONJEONGHUN.md new file mode 100644 index 0000000..e64e8b4 --- /dev/null +++ b/git-basics/22nd/README-SONJEONGHUN.md @@ -0,0 +1,500 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. +Git (Local) +버전 관리 시스템: Git은 소스 코드의 변경 내역을 추적하고 관리할 수 있는 분산 버전 관리 시스템입니다. + +로컬 저장소: 개발자가 자신의 컴퓨터에 Git을 설치하고, 프로젝트의 버전 기록을 로컬 저장소에 저장합니다. 이로 인해 인터넷 연결 없이도 버전 관리 작업(커밋, 브랜치 생성 등)을 수행할 수 있습니다. + +GitHub (Remote) +원격 저장소 서비스: GitHub는 Git을 기반으로 하는 클라우드 기반 플랫폼입니다. + +협업 및 공유: 로컬에서 관리하는 Git 저장소를 원격 저장소로 업로드(push)하여 여러 개발자와 협업할 수 있으며, 다른 사람의 프로젝트를 복제(clone)하거나 기여(pull request)할 수 있습니다. + +추가 기능: 이슈 추적, 코드 리뷰, 위키, CI/CD 등 협업에 유용한 다양한 기능을 제공합니다. + +결론 +Local vs Remote: Git은 로컬에서의 버전 관리 도구이며, GitHub는 이러한 Git 저장소를 원격으로 관리, 공유 및 협업하기 위한 플랫폼입니다. 따라서 둘은 동일한 것이 아니라, Git이 로컬 작업에 중점을 둔다면 GitHub는 원격 협업 및 저장소 관리에 초점을 맞춘 서비스입니다. + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) + +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +Working Directory +정의: 프로젝트의 실제 파일들이 위치한 폴더입니다. + +역할: 개발자가 코드를 작성하고 수정하는 작업 공간입니다. + +특징: 파일을 편집하면 변경 사항이 바로 Working Directory에 반영됩니다. + +Git Add +정의: 변경된 파일을 스테이징 영역(Staging Area)에 추가하는 명령어입니다. + +역할: 작업 디렉토리의 변경 사항 중에서 어떤 파일을 커밋에 포함할지 선택합니다. + +특징: git add 파일명 명령어를 사용하여 특정 파일 또는 git add .로 전체 변경 사항을 스테이징 할 수 있습니다. + +Git Commit +정의: 스테이징 영역에 있는 파일의 변경 사항을 로컬 저장소에 저장하는 명령어입니다. + +역할: 현재까지의 작업 상태를 하나의 스냅샷으로 기록하며, 커밋 메시지를 통해 변경 내역을 설명합니다. + +특징: 커밋은 변경 사항의 기록으로서, 프로젝트의 이력을 관리하고 필요 시 이전 상태로 복원할 수 있는 기반이 됩니다. + +Git Push +정의: 로컬 저장소에 저장된 커밋을 원격 저장소(예: GitHub)로 전송하는 명령어입니다. + +역할: 여러 개발자와 협업할 때 로컬 변경 사항을 공유하고, 원격 저장소를 최신 상태로 유지합니다. + +특징: git push origin 브랜치명 형식으로 사용하며, 원격 저장소와 동기화를 통해 프로젝트의 버전 관리가 이루어집니다. + +이렇게 Git은 Working Directory에서 변경된 파일을 git add를 통해 스테이징하고, git commit으로 로컬 저장소에 기록한 후, git push를 통해 원격 저장소에 반영하는 과정을 통해 버전 관리와 협업이 이루어집니다. + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +Git은 commit과 branch를 기본 단위로 동작하며, 이 두 요소를 중심으로 다양한 명령어를 통해 버전 관리가 이루어집니다. + +Commit +정의: 프로젝트의 특정 시점의 상태(스냅샷)를 기록한 단위입니다. + +특징: 각 commit은 고유한 해시값을 가지며, 변경 사항과 커밋 메시지를 포함합니다. + +역할: 프로젝트 이력 관리 및 필요 시 이전 상태로 복원할 수 있게 해줍니다. + +Branch +정의: commit들을 가리키는 포인터로, 개발의 흐름(라인)을 의미합니다. + +역할: 여러 기능 개발이나 버그 수정을 동시에 진행할 때, 독립적인 작업 공간을 제공하여 주 작업(main/master branch)에 영향을 주지 않도록 합니다. + +생성: git branch 브랜치명으로 새로운 branch를 생성할 수 있습니다. + +삭제: 작업이 끝난 branch는 git branch -d 브랜치명 (안전 삭제) 또는 git branch -D 브랜치명 (강제 삭제) 명령어로 제거할 수 있습니다. + +HEAD +정의: 현재 작업 중인 branch 또는 commit을 가리키는 포인터입니다. + +역할: 현재 체크아웃된 상태를 나타내며, HEAD가 가리키는 branch의 최신 commit이 작업의 기준점이 됩니다. + +특징: HEAD가 branch를 가리키는 경우, 해당 branch의 최신 commit에 위치하게 되고, 특정 commit을 직접 가리키면 'detached HEAD' 상태가 됩니다. + +Git Checkout +역할: + +Branch 전환: 다른 branch로 이동할 때 사용합니다. 예를 들어, git checkout 브랜치명 명령어를 통해 다른 branch로 전환하면, HEAD가 해당 branch를 가리키게 됩니다. + +새로운 Branch 생성 및 이동: git checkout -b 새브랜치명 명령어로 branch를 생성하고 즉시 전환할 수 있습니다. + +특정 Commit 체크아웃: 특정 commit의 상태로 작업 디렉토리를 전환할 수 있으나, 이 경우 detached HEAD 상태가 되어 커밋을 직접 추가하면 branch와 연동되지 않습니다. + +주의사항: + +Detached HEAD 상태에서는 작업 후 별도의 branch를 생성하지 않으면, 이후 변경 내용이 반영되지 않을 수 있으니 주의해야 합니다. + +최근 Git 버전에서는 branch 전환에 특화된 git switch 명령어도 함께 제공되므로 상황에 맞게 활용할 수 있습니다. + +Branch 관리 커맨드 요약 +Branch 생성: + +git branch 새브랜치명 + +또는 git checkout -b 새브랜치명 (생성과 동시에 전환) + +Branch 목록 확인: git branch + +Branch 전환: git checkout 브랜치명 또는 git switch 브랜치명 + +Branch 삭제: + +안전 삭제: git branch -d 브랜치명 + +강제 삭제: git branch -D 브랜치명 + +결론 +Git에서 commit은 개별 작업의 단위를 기록하며, branch는 이러한 commit들의 흐름을 관리하는 역할을 합니다. HEAD는 현재 활성화된 branch나 commit을 나타내며, git checkout 명령어를 통해 branch 간 전환이나 특정 commit 상태로의 변경이 이루어집니다. 이들 명령어와 개념을 활용하면 여러 개발 작업을 독립적으로 진행하면서도, 전체 프로젝트의 이력을 체계적으로 관리할 수 있습니다. + + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +Git 리포지토리를 로컬에 생성하는 방법에는 크게 두 가지가 있습니다. 아래에서 **git init**과 **git clone**의 차이점 및 사용 방법, 그리고 **origin** 키워드에 대해 설명합니다. + +--- + +## git init vs git clone + +### git init +- **목적**: 현재 디렉토리를 새로운 Git 리포지토리로 초기화합니다. +- **사용 상황**: 새로운 프로젝트를 시작할 때 또는 기존 폴더를 버전 관리 대상으로 만들고 싶을 때 사용합니다. +- **동작 방식**: + - 명령어를 실행하면 해당 디렉토리에 `.git` 폴더가 생성되어, Git이 버전 관리를 위한 모든 메타데이터를 저장하게 됩니다. +- **사용 방법**: + ```bash + git init + ``` +- **추가 설정**: + - 초기화 후, 원격 저장소가 필요한 경우 `git remote add origin <저장소 URL>` 명령어로 원격 저장소를 설정할 수 있습니다. + +--- + +### git clone +- **목적**: 기존의 원격 또는 로컬 Git 리포지토리를 복제하여 새로운 로컬 리포지토리를 생성합니다. +- **사용 상황**: 이미 존재하는 프로젝트를 복사하여 작업을 시작할 때 사용합니다. +- **동작 방식**: + - 지정한 URL의 리포지토리를 그대로 복제하며, 커밋 내역과 브랜치 정보 등 모든 Git 기록을 함께 가져옵니다. + - 복제한 후, 기본 원격 저장소 이름으로 `origin`이 자동으로 설정됩니다. +- **사용 방법**: + ```bash + git clone <리포지토리 URL> + ``` +- **예시**: + ```bash + git clone https://github.com/username/project.git + ``` + +--- + +## origin이란 키워드와 설정 방법 + +- **origin의 의미**: + - `origin`은 Git에서 기본 원격 저장소의 별칭(alias)으로 사용됩니다. + - 클론 시, 자동으로 복제된 리포지토리의 원격 저장소가 `origin`으로 설정되며, 이후 `git push`, `git pull` 등의 명령어에서 기본 원격 저장소로 참조됩니다. + +- **설정 방법**: + - **자동 설정**: + - `git clone` 명령어를 사용하면, 원격 저장소 URL이 자동으로 `origin`이라는 이름으로 설정됩니다. + - **수동 설정**: + - 새로 생성한 로컬 리포지토리에서 원격 저장소를 추가할 때, 다음 명령어를 사용하여 `origin`이라는 이름을 지정할 수 있습니다. + ```bash + git remote add origin <원격 저장소 URL> + ``` + - **원격 저장소 확인**: + - 현재 설정된 원격 저장소 목록은 아래 명령어로 확인할 수 있습니다. + ```bash + git remote -v + ``` + +--- + +## 요약 + +- **git init**: 새로운 리포지토리를 로컬에서 시작할 때 사용합니다. 이후 필요에 따라 원격 저장소(`origin`)를 추가할 수 있습니다. +- **git clone**: 기존 리포지토리를 복제할 때 사용하며, 클론 시 원격 저장소가 자동으로 `origin`으로 설정됩니다. +- **origin**: 기본 원격 저장소의 별칭으로, `git clone` 시 자동 설정되거나 `git remote add origin `로 수동 설정할 수 있습니다. + +이와 같은 방식으로 로컬에서 Git 리포지토리를 생성하고 관리할 수 있습니다. + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +1. --soft +동작 방식: + +HEAD 포인터만 지정한 커밋으로 이동합니다. + +스테이징 영역(index)과 작업 디렉토리(working directory)는 그대로 유지됩니다. + +사용 예: git reset --soft <커밋 해시> + +마지막 커밋을 취소하고, 변경 사항을 그대로 스테이징 영역에 남겨두고 싶을 때 사용합니다. + +2. --mixed (기본 옵션) +동작 방식: + +HEAD 포인터를 지정한 커밋으로 이동합니다. + +스테이징 영역을 해당 커밋 상태로 재설정하지만, 작업 디렉토리의 파일은 그대로 남깁니다. + +특징: + +변경 사항은 작업 디렉토리에 남아 있으므로 다시 스테이징하거나 수정할 수 있습니다. + +별도로 옵션을 주지 않고 git reset <커밋 해시>로 사용하면 기본적으로 --mixed 모드가 적용됩니다. + +git reset --mixed <커밋 해시> + +3. --hard +동작 방식: + +HEAD 포인터, 스테이징 영역, 작업 디렉토리 모두를 지정한 커밋 상태로 되돌립니다. + +특징: + +변경 사항이 모두 삭제되므로, 작업 중인 내용이 모두 사라질 수 있습니다. + +되돌릴 수 없는 파괴적인(reset) 작업이므로 주의해서 사용해야 합니다. + +이와 같이, --soft는 커밋만 취소하고 스테이징 상태를 유지하며, --mixed는 스테이징 영역까지 초기화하지만 작업 내용은 보존하고, --hard는 모든 변경 사항을 완전히 제거하는 방식으로 작동합니다. + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. + +Pull Request (PR) +개념: + +Pull Request는 개발자가 특정 기능이나 버그 수정 작업을 완료한 후, 해당 변경 사항을 메인 또는 다른 기준 브랜치에 병합(merge)해달라고 요청하는 절차입니다. + +주로 GitHub, GitLab, Bitbucket 등의 원격 저장소 서비스에서 사용되며, 팀원 간의 코드 리뷰, 논의, 테스트를 거쳐 코드 품질을 보증하는 데 중요한 역할을 합니다. + +작업 과정: + +분기(Branch) 생성: 새로운 기능 또는 버그 수정을 위한 독립적인 브랜치에서 작업을 진행합니다. + +커밋: 작업 내역을 여러 커밋으로 기록합니다. + +PR 생성: 변경 사항이 반영된 브랜치를 기준 브랜치(예: main 또는 master)로 병합해달라고 요청합니다. + +리뷰 및 승인: 다른 팀원들이 코드 리뷰를 진행하며, 수정 및 토론을 거친 후 최종 승인이 이루어집니다. + +Merge: 승인된 PR은 Merge되어 기준 브랜치에 변경 사항이 반영됩니다. + +Merge +Merge는 서로 다른 브랜치의 변경 사항을 하나로 합치는 작업입니다. Merge에는 주로 두 가지 타입이 있습니다. + +1. Fast-Forward Merge +상황: + +병합 대상 브랜치가 기준 브랜치의 직계 후손인 경우 발생합니다. + +기준 브랜치에 변경 사항이 없고, 병합 대상 브랜치의 변경 사항만 추가된 상황입니다. + +동작 원리: + +기준 브랜치 포인터를 단순히 병합 대상 브랜치의 최신 커밋으로 "앞으로 이동"시킵니다. + +별도의 merge commit 없이 단순하게 브랜치 포인터가 이동되므로 커밋 기록이 깔끔하게 유지됩니다. + +명령어 예시: +git checkout main +git merge feature-branch + +위 명령어에서 만약 main 브랜치가 feature-branch의 부모라면, Fast-Forward Merge가 적용됩니다. + +2. 3-Way Merge +상황: + +기준 브랜치와 병합 대상 브랜치 모두에 독자적인 변경 사항이 있을 때 발생합니다. + +두 브랜치가 서로 다른 방향으로 발전하여 공통 조상(commit)이 존재하는 경우입니다. + +동작 원리: + +Git은 세 개의 지점을 사용합니다: + +공통 조상 (Common Ancestor) + +기준 브랜치의 최신 커밋 + +병합 대상 브랜치의 최신 커밋 + +이 세 지점을 비교하여 두 브랜치의 변경 사항을 통합한 새로운 merge commit을 생성합니다. + +이 merge commit은 두 부모(commit)를 가지게 됩니다. + +명령어 예시: +git checkout main +git merge feature-branch + +기준 브랜치와 feature 브랜치가 모두 변경 사항을 포함하고 있다면, Git은 3-Way Merge를 수행하여 새로운 merge commit을 생성합니다. + +요약 +Pull Request는 코드 변경 사항을 기준 브랜치로 병합하기 전, 팀원들과 리뷰 및 토론을 진행하는 협업 절차입니다. + +Merge는 두 브랜치의 변경 사항을 하나로 합치는 작업이며, + +Fast-Forward Merge는 병합 대상 브랜치가 기준 브랜치의 직계 후손인 경우 단순히 포인터를 이동하는 방식으로, + +3-Way Merge는 서로 다른 변경 사항을 통합하기 위해 공통 조상과 두 브랜치의 최신 커밋을 비교하여 새로운 merge commit을 생성하는 방식입니다. + +이와 같이 PR과 Merge는 팀 프로젝트에서 코드의 변경 사항을 효과적으로 통합하고 관리하기 위한 핵심 절차로 활용됩니다. + + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +Rebase의 정의 +Rebase란? + +Rebase는 한 브랜치의 커밋들을 다른 브랜치 위에 순차적으로 재적용하는 과정입니다. + +기존의 커밋 기록을 새로운 기반(commit) 위에 "붙여" 이력을 재구성합니다. + +Rebase의 동작 원리 +작업 방식: + +예를 들어, feature 브랜치가 있고 이 브랜치에서 여러 커밋을 진행한 상황에서, 기준 브랜치(main)에 새로운 커밋들이 추가되었다고 가정합니다. + +Rebase를 사용하면 feature 브랜치의 커밋들이 main 브랜치의 최신 커밋 이후에 순서대로 재적용됩니다. + +결과: + +커밋 기록이 선형화되어, 복잡한 병합 기록 없이 깔끔한 이력이 만들어집니다. + +Rebase가 유용한 경우 +이력 정리 (Clean History): + +여러 기능 브랜치에서 작업한 커밋들이 산재해 있을 때, rebase를 통해 선형적인 이력을 유지하면 코드 리뷰나 버그 추적이 용이해집니다. + +업스트림 변경사항 반영: + +팀원들이 기준 브랜치(main, master 등)에 새로운 커밋을 추가한 경우, rebase를 사용하여 자신의 작업을 최신 기준 위에 올림으로써 충돌 가능성을 줄일 수 있습니다. + +피쳐 브랜치 업데이트: + +병합 전에 최신 기준 브랜치의 변경사항을 피쳐 브랜치에 반영할 때 사용합니다. 이렇게 하면 나중에 병합 시에 불필요한 merge commit 없이 변경 사항을 반영할 수 있습니다. + +주의사항 +공유된 브랜치에서의 Rebase: + +이미 다른 팀원과 공유된 브랜치에서 rebase를 수행하면, 커밋 해시가 변경되어 협업에 혼란을 줄 수 있으므로, 주로 개인 작업이나 공유되지 않은 브랜치에서 사용하는 것이 좋습니다. + +충돌 해결: + +Rebase 도중 충돌이 발생할 수 있으며, 이 경우 충돌을 해결한 후 rebase를 계속 진행해야 합니다. + +결론 +Rebase는 브랜치의 커밋 기록을 재구성하여 선형적이고 깔끔한 이력을 만들고, 최신 기준 브랜치의 변경사항을 반영하는 데 유용한 도구입니다. 단, 공유된 브랜치에서는 사용에 주의해야 하며, 충돌 해결 과정이 필요할 수 있습니다. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +Git stash는 현재 작업 중인 미완성 변경 사항(수정된 파일, 추가된 파일 등)을 임시 저장해 두어, 워킹 디렉토리를 깨끗한 상태로 만들고 다른 브랜치로 전환하거나 긴급한 작업을 처리할 때 유용하게 활용됩니다. 아래에 git stash의 주요 활용 방법과 관련 명령어들을 정리했습니다. + +--- + +## 주요 명령어와 활용 방법 + +### 1. 변경 사항 임시 저장 +- **git stash / git stash push** + - 현재 작업 디렉토리와 스테이징 영역의 변경 사항을 임시 저장소에 저장합니다. + - 기본적으로 추적된(tracked) 파일의 변경 사항을 저장하며, 미추적(untracked) 파일까지 저장하려면 `-u` 옵션을 추가합니다. + - 예시: + ```bash + git stash + git stash push -u + git stash push -m "작업 중인 변경 사항 저장" + ``` + +--- + +### 2. 저장된 Stash 목록 확인 +- **git stash list** + - 저장된 stash들을 확인할 수 있습니다. + - 출력 예시: + ``` + stash@{0}: WIP on main: 1234567 작업 내용 메시지 + stash@{1}: WIP on main: 89abcd0 이전 작업 내용 + ``` + +--- + +### 3. Stash 적용 및 제거 +- **git stash apply** + - 지정한 stash(또는 기본으로 가장 최근 stash)를 현재 작업 디렉토리에 적용합니다. + - 적용 후에도 stash 목록에는 남아 있으므로, 필요에 따라 삭제할 수 있습니다. + - 예시: + ```bash + git stash apply stash@{0} + ``` + +- **git stash pop** + - 지정한 stash(또는 기본으로 가장 최근 stash)를 적용하면서, stash 목록에서 자동으로 제거합니다. + - 예시: + ```bash + git stash pop + ``` + +--- + +### 4. 특정 Stash 삭제 +- **git stash drop** + - 더 이상 필요 없는 특정 stash 항목을 삭제합니다. + - 예시: + ```bash + git stash drop stash@{1} + ``` + +- **git stash clear** + - 저장된 모든 stash 항목을 삭제합니다. + +--- + +## 사용 사례 + +- **브랜치 전환**: + 미완성 작업을 보류하고 다른 브랜치로 전환해야 할 때, + ```bash + git stash # 현재 변경 사항 저장 + git checkout 다른-브랜치 + # 긴급 작업 후 돌아와서... + git checkout 원래-브랜치 + git stash pop # 저장된 변경 사항 복원 + ``` + +- **긴급 수정**: + 작업 도중 버그 수정 등 긴급한 작업이 필요할 때, 현재 진행 중인 작업을 임시 저장한 후 수정 작업을 진행하고 나중에 다시 복원할 수 있습니다. + +- **작업 정리**: + 실험적인 코드나 아직 완성되지 않은 변경 사항을 커밋 전에 임시로 보관하여, 커밋 기록을 깔끔하게 관리할 수 있습니다. + +--- + +## 주의 사항 +- **충돌 가능성**: + stash를 적용할 때 변경 사항 간 충돌이 발생할 수 있으며, 이 경우 수동으로 해결해야 합니다. + +- **임시 저장소 관리**: + 오래된 stash는 혼란을 줄 수 있으므로, 주기적으로 `git stash list`로 상태를 확인하고 필요 없는 항목은 `git stash drop` 또는 `git stash clear`로 정리하는 것이 좋습니다. + +--- + +Git stash는 이러한 명령어와 활용 방법을 통해 작업 흐름을 유연하게 관리하고, 임시 작업 보류나 브랜치 전환 시 유용하게 사용할 수 있는 도구입니다. + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? + +GitHub Flow는 빠른 개발 및 배포를 위해 단순한 브랜치 전략을 사용하여, 항상 프로덕션 배포 가능한 main 브랜치와 임시 feature 브랜치 중심으로 리포지토리를 관리합니다. + +Git Flow는 정교한 버전 관리를 위해 master, develop, feature, release, hotfix 등 여러 브랜치를 활용하며, 각 브랜치의 역할을 명확히 분리하여 대규모 프로젝트나 정해진 릴리즈 사이클에 적합한 전략입니다. + +- `git rebase --interactive`란? + +git rebase --interactive (또는 git rebase -i)는 Git에서 커밋 이력을 인터랙티브하게 수정할 수 있는 기능입니다. 이를 통해 다음과 같은 작업을 수행할 수 있습니다: + +커밋 순서 변경: 커밋 목록의 순서를 재배치하여 이력을 정리할 수 있습니다. + +커밋 합치기 (Squash/Fixup): 여러 커밋을 하나로 합쳐 이력을 깔끔하게 만들 수 있습니다. + +커밋 메시지 수정: 특정 커밋의 메시지를 변경하거나 수정할 수 있습니다. + +커밋 삭제: 불필요한 커밋을 제거하여 이력을 간소화할 수 있습니다. + +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git a/git-basics/22nd/README-YOONJUNG.md b/git-basics/22nd/README-YOONJUNG.md new file mode 100644 index 0000000..ffe87bc --- /dev/null +++ b/git-basics/22nd/README-YOONJUNG.md @@ -0,0 +1,81 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) + +- Git : 분산 버전 관리 시스템 +- Github : Git으로 관리하는 프로젝트의 공유 및 협업을 위한 플랫폼 +- 개인 컴퓨터의 저장소 : local / 서버의 원격 저장소 : remote +- local에서 작업한 프로젝트를 remote에 업로드하는 방식으로 변경 사항 반영 및 협업을 진행함. + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) + +- Working Directory : 사용자의 작업 공간. +- Git Add : 변경 사항을 임시 공간 stage에 올림. +- Git Commit : 변경 사항에 대해 저장 및 기록함. +- Git Push : 변경 사항을 remote로 업로드함. + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) + +- Branch : Commit을 가리키는 포인터 +- HEAD : Branch를 가리키는 포인터 +- HEAD가 가리키는 Commit에 따라 Working Directory가 달라지며, checkout을 통해 HEAD가 가리키는 Branch를 변경할 수 있음. + +---- +**# Branch Command** +- Branch 생성 : git branch [branch] +- Branch 삭제 : git branch -D [branch] +- Branch 이동 : git checkout [branch] + + +## clone, init, origin +- clone, init은 모두 Git 저장소를 만드는 Command이나, 방법의 차이가 존재함. +- git clone : 기존의 다른 Git 저장소를 복사하는 방법. +- git init : 버전 관리를 하지 않던 프로젝트 파일을 Git 저장소에 추가하는 방법. +- origin : 작업중인 local과 연결된 remote의 주소를 가리키는 단축 키워드. +- 일반적으로 origin은 git clone 할 때 자동으로 생성되며, origin이 가리키는 주소를 통해 데이터 동기화 및 업데이트가 가능함. + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +- reset : HEAD의 위치를 과거 혹은 미래의 commit으로 이동시킬 수 있음. +- type1) --soft : HEAD가 특정 commit을 새롭게 가리키지만, 작업 중인 working directory와 staging area는 영향을 받지 않음. +- type2) --mixed : HEAD가 특정 commit을 새롭게 가리키며 staging area도 동일하게 변하나, working directory는 영향을 받지 않음. +- type3) --hard : HEAD가 새롭게 가리키는 commit과 동일하게 staging area와 working directory가 모두 변함. + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +- Fork : 다른 사용자의 저장소를 복사하는 것. +- Pull Request : Rork를 통해 복사한 내용을 개인 작업 공간에서 업데이트 후, 원본 저장소에 적용되도록 다른 사용자에게 pull 요청을 보내는 것. +- -- +- Merge : 서로 다른 브랜치에서 작업한 내용을 합쳐야 하는 경우 사용. +- type1) Fast-Forward : merge commit이 생기지 않고, merge가 실행된 branch의 HEAD가 병합되는 branch의 HEAD commit으로 이동하는 방식. +- type2) 3-Way Merge : 두 branch가 commit history 상에서 분리된 2개의 선에 각각 존재할 때, merge commit을 새로 생성하는 방식. + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +- rebase : 서로 다른 branch에서 작업한 내용을 합칠 때 사용하는 것으로, branch의 base commit을 재설정함. +- 깃 히스토리가 직렬로 정리되어 깔끔한 관리가 가능함. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +- stash : 변경사항을 일시적으로 저장하는 기능. +- commit하기에 이르거나, 다른 branch로 checkout하면서 변경 사항을 유지하고 싶은 경우 사용함. 일시적 저장 후 나중에 다시 사용이 가능함. +- 작업 중인 변경 사항을 stack에 저장하고, working directory를 깨끗한 상태로 만듦. + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git a/git-basics/22nd/README-Yeochaeeon.md b/git-basics/22nd/README-Yeochaeeon.md new file mode 100644 index 0000000..de94ec6 --- /dev/null +++ b/git-basics/22nd/README-Yeochaeeon.md @@ -0,0 +1,155 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) + +- git + - 버전을 관리해주는 소프트웨어 + - local에서 작동하며 로컬 저장소상의 코드의 변경사항을 추적하고 관리하는데 사용한다. +- github + - git을 기반으로 한 원격(remote) 호스팅 웹 서비스이다. + - git 레포를 클라우드에 저장하고, 협업 및 코드 공유를 쉽게 할 수 있도록 돕는다. + - github는 원격 저장소(remote repository)를 관리하는데 사용된다. + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) + +- Working Directory + - 현재 작업중인 파일들이 위치한 디렉토리. 파일을 수정 및 생성하는 곳. + - Working Directory 에서는 파일을 tracked와 untracked로 구분한다. + > untracked 상태 + - 저장소 내의 모든 파일은 untracked상태로 시작하며 untracked 상태의 파일들은 git이 코드 변경 이력을 추적하지 않음. + > tracked 상태 + - tracked 상태의 파일들은 git에 의해 파일의 변경 이력이 추적된다. (ex.이전에 커밋된 파일) +- Git Add + - `git add` 는 Working Directory 에서 변경된 파일을 **staging area** 로 이동시킨다. + - 이 명령어를 사용하면 해당 파일을 tracked 상태로 등록한다. + - tracked 상태의 파일들을 임시로 저장하는 공간. + - `git add . `은 현재 디렉토리의 모든 변경 사항을 스테이징하는 명령어이다. +- Git Commit + - 스테이징 영역의 변경사항을 **로컬 레포**에 저장하는 명령어이다. + - 커밋은 변경 사항의 스냅샷을 따서 Git 히스토리에 저장한다. + - 커밋메시지를 함께 남겨 변경 사항에 대한 정보를 기록한다. + - 이 단계는 **로컬**에서 이루어지며, 원격 레포에는 아직 반영되지 않는다. +- Git Push + - 로컬 레포의 커밋을 **원격 레포로 전송**한다. + - github에 변경 사항이 반영된다. + - 로컬과 원격 간의 동기화를 해주는 역할을 한다. +- Git Merge + - 두 브랜치의 변경사항을 하나로 통합한다. +- Git Fetch + - 원격 레포의 최신 정보를 로컬로 가져온다. + - 그러나 로컬 브랜치에 바로 반영하지는 않는다. + - `git merge`나 `git pull`을 추가로 실행함으로써 변경사항을 반영할 수 있다. +- Git Pull + - `git fetch`와 `git merge`를 합친 명령어 + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) + +- Branch + - 브랜치 생성 후 전환 : `git checkout -b step-1-여채언` + - 브랜치 전환 : `git checkout step-1` +- HEAD + - HEAD는 현재 작업중인 커밋을 가리키는 포인터이다. + - 보통 현재 브랜치의 최신 커밋을 가리킨다. + - `git checkout`으로 브랜치를 전환하면, HEAD도 해당 브랜치로 이동한다. +## clone, init, origin + +### `git clone` vs `git init` +> `git clone` +- 원격 레포지토리를 로컬로 복사하여 로컬 레포를 생성하는 명령어이다. 원격 레포의 모든 커밋 기록, 브랜치, 파일을 가져온다. +- 데이터를 로컬로 복사하면서, 원격 레포와 자동으로 연결된다. +> `git init` +- 현재 디렉토리를 새로운 git 로컬 레포로 초기화하는 명령어. +- 빈 레포를 생성하고, 원격 레포와의 연결은 설정되지 않은 상태로 시작한다. +- init 으로 생성한 레포를 원격 레포와 연결하려면, +`git remote add origin <원격레포URL>` 을 사용한다. +### Origin 이란? +- 원격 레포 (Remote Repository)의 기본 이름름 +- origin은 원격 레포지토리의 URL을 가리키며, git push, git pull, git fetch 같은 명령어에서 사용됨. +- 원격 레포지토리의 브랜치는 origin/브랜치명 형식으로 표시됨(예: origin/step-0). +- 연결된 원격 저장소 확인 : `git remote -v` + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) + +> `git reset`은 git에서 커밋 히스토리를 되돌리거나 변경사항을 취소하는데 사용되는 명령어이고 세가지의 타입이 있다. +- ` --soft` + - HEAD를 지정한 커밋으로 이동시킨다. 하지만 스테이징 영역과 작업 디렉토리의 변경사항은은 그대로 유지된다. + - 커밋만 취소하고 변경된 파일들은 그대로 스테이징 영역에 남아있다.- HEAD를 바로 직전 커밋으로 이동하고자 할 때 : `git reset --soft HEAD^` +- ` --mixed` (default) + - HEAD를 지정한 커밋으로 이동시키고, 스테이징 영역을 초기화하지만 작업 디렉토리의 변경 사항은 유지한다. + - 즉, 커밋과 스테이징 상태를 되돌리지만 파일 자체의 변경 내용은 남아 있다. +- ` --hard` + - HEAD를 지정한 커밋으로 이동시키고, 스테이징 영역과 작업 디렉토리까지 모두 해당 커밋 상태로 되돌린다. + - 즉, 커밋, 스테이징, 작업 디렉토리의 모든 변경 사항이 삭제된다. +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) + +- Pull Request + - 한 브랜치의 변경 사항을 다른 브랜치에 병합하기 위해 요청하는 기능 + - PR에서 병합하기 전에 코드리뷰, 테스트 등을 거치고 협업을 용이하게 한다. + - 원격 레포에서 브랜치 간의 변경 사항을 비교하고 병합하는 과정을 제공한다. +- Merge + - 두 브랜치의 변경 사항을 하나로 통합한다. + > fast-forward Merge + - 새로운 브랜치에만 commit이 있고 기준 브랜치에는 신규 commit이 없을 때. + - 병합 커밋이 남지 않는다. + - 충돌 가능성 없다. + ![fast-forward](https://codingapple-cdn.b-cdn.net/wp-content/uploads/2022/06/%EA%B7%B8%EB%A6%BC3-4.png) + > 3-way Merge + - 브랜치에 각각 신규 commit 이 1회 이상 존재하는 경우 + - 두개의 브랜치 코드를 합쳐 새로운 commit이 생성된다. + ![3way](https://codingapple-cdn.b-cdn.net/wp-content/uploads/2022/06/merge1.png) + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) + +- `git rebase`는 현재 브랜치의 커밋을 떼어내어, 지정한 브랜치의 최신 커밋 위에 재적용한다. +- rebase또한 병합 방법 중 하나이나, merge에 비해 커밋 기록을 한 줄로 깔끔하게 관리할 수 있다. 그러나 충돌 발생 가능성이 있다. +- 병합 커밋이 생성되지 않는다. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) + +- `git stash`는 작업 디렉토리와 스테이징 영역의 변경 사항을 임시로 저장하고, 작업 디렉토리를 깨끗한 상태로 되돌리는 명령어. +- 변경 사항을 스택(stack)에 저장하고, 작업 디렉토리와 스테이징 영역을 마지막 커밋 상태로 되돌린다. +> 활용 예시 +- branch-a 에서 파일을 수정했지만, 커밋하지 않고 다른 브랜치로 전환하고자 할 때 +```bash +# 현재 작업 중인 변경 사항 저장 후 작업 디렉토리를 깨끗하게 한다 +git stash +# stash 목록을 확인한다 +git stash list +# 스택에 쌓인 가장 최근의 변경 사항을 불러와 작업 디렉토리에 적용하고 스택에서 제거된다. +git stash pop +# 변경사항을 불러와 적용하지만, 스택에서 제거는 하지 않는다 +git stash apply + +``` +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git a/git-basics/22nd/README-sinsehwan.md b/git-basics/22nd/README-sinsehwan.md new file mode 100644 index 0000000..50c83ac --- /dev/null +++ b/git-basics/22nd/README-sinsehwan.md @@ -0,0 +1,137 @@ +# Git 기초 + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) + +Git은 분산형 버전 관리 시스템. 로컬에서 코드의 변경 사항을 추적하기 위해 사용하는 도구이다. + +GitHub는 Git을 기반으로 한 원격 저장소 호스팅 서비스이다. + +Local : 사용자 컴퓨터에서 동작하는 Git저장소 +Remote : GitHub, GitLab, Bitbuchet과 같은 원격 저장소. + +로컬에서의 Git 저장소롤 원격 저장소에 push해서 공유하는 형태. + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. + +### Working Directory +소스 코드가 실제로 존재하는 작업 공간 + +### Git Add +git add를 사용하면 변경된 파일을 Staging Area로 올린다. + +### Staging Area +커밋 전 변경 사항을 저장하는 공간. + +### Git Commit +git commit -m ""형식. 변경 사항을 로컬 저장소에 저장한다. + +### Git Push +git push origin <브랜치> 형식. 로컬에서 커밋된 변경 사항을 원격 저장소에 업로드한다. + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +### Branch +독립적인 작업 공간. + +### HEAD +현재 작업 중인 브랜치를 가리키는 포인터 + +### 관련 명령어 +git branch <> : 새 브랜치 생성 +git checkout <> : 브랜치 변경 +git switch <> : 브랜치 변경 +git branch -d <> : 브랜치 삭제 +git merge <> : 현재 브랜치에 지정된 브랜치 병합 + +## clone, init, origin +1. git clone +원격 저장소를 복제해서 로컬 저장소를 생성한다. + +2. git init +새로운 Git 저장소를 로컬에서 초기화한다. + +3. origin +Git에서 원격 저장소의 기본 이름. git remove add origin 명령어로 설정 가능. + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +1. git reset --soft +HEAD를 이전 커밋으로 이동하지만, 변경 사항은 Staging Area에 남긴다. + +2. git reset --mixed +HEAD를 이전 커밋으로 이동하고 Staging Area를 초기화하지만, Working Directory에는 변경 사항이 남는다. + +3. git reset --hard +HEAD를 이전 커밋으로 이동하고, Staging Area와 Working Directory 모두 초기화한다. + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +1. Pull Request(PR) +협업할 때 다른 브랜치의 변경 사항을 병합하기 전에 검토 요청 + +2. Merge +(1) Fast-Forward Merge +변경 사항이 직선적인 경우 빠르게 병합된다. + +(2) 3-Way Merge +서로 다른 브랜치의 변경 사항을 병합할 때 공통 조상을 고려해서 새로운 커밋을 생성한다. + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +브랜치를 다른 브랜치의 최신 상태로 업데이트 하는 방법이다. +git rebase <브랜치> 형식. +커밋 히스토리를 깔끔하게 유지할 때 유용하다. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 사용하면 현재 작업 내용을 임시로 저장하고 나중에 복원할 수 있다. + +git stash save "메시지" : 변경사항 임시 저장 +git stash list : 저장된 stash 목록 확인 +git stash apply : 마지막 stash 복원 +git stash drop : stash 삭제 + +## Advanced +- GitHub Flow : 메인 브랜치에서 작업 후 바로 배포 +- Git Flow : feature, develop, release 브랜치를 활용해서 관리 + +- `git rebase --interactive`란? +커밋을 합치거나 수정하는 데 사용 + +- branch의 upstream이란? (`git push --set-upstream origin <브랜치>`) +기본 원격 브랜치를 설정한다. + +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +다른 사용자의 저장소 복제해서 독립적으로 개발할 때 사용. + +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +git fetch : 원격 저장소의 변경 사항을 가져오기만 하고 병합하지 않는다. +git pull : 원격 저장소의 변경 사항을 가져오고 자동 병합. + +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +제외시킬 파일 지정 + +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +Git에서 브랜치 자체를 디렉토리로 관리하기 때문이다. + +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 +브랜치 없이 특정 커밋을 Checkout한 상태. 이 상태에서 커밋하면 브랜치 없어서 사라질 수 있음. 이런게 왜 생기는거지 + +git log --oneline --graph --decorate --all +커밋 로그 확인 + +## Questions +1. git reset --soft +HEAD를 이전 커밋으로 이동하지만, 변경 사항은 Staging Area에 남긴다. + +2. git reset --mixed +HEAD를 이전 커밋으로 이동하고 Staging Area를 초기화하지만, Working Directory에는 변경 사항이 남는다. +이 둘의 차이가 체감이 잘 안됩니다. + +3. detached HEAD 발생상황 + +4. fetch에서 변경사항은 가져오는데 병합하지 않는다는게 잘 이해 안됨. \ No newline at end of file diff --git a/git-basics/22nd/README-soyoung.md b/git-basics/22nd/README-soyoung.md new file mode 100644 index 0000000..67ff3e7 --- /dev/null +++ b/git-basics/22nd/README-soyoung.md @@ -0,0 +1,58 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git a/git-basics/22nd/README-taeran.md b/git-basics/22nd/README-taeran.md new file mode 100644 index 0000000..675cb07 --- /dev/null +++ b/git-basics/22nd/README-taeran.md @@ -0,0 +1,116 @@ +# Git 기초 +Git 알아보기_김태란(개발) + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +Git : **local** 에서의 모든 변경사항을 기록하는(버전관리를 하는) **소프트웨어** +Github : 클라우스 서버를 통해 **local의 코드 -> remote** 로 업로드하고 공유할 수 있도록 하는 **서비스** + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +Working Directory : 내가 현재 작업하고 있는 디렉토리 (위치) + +**Git Add** : add를 해줘야만 **commit의 대상**으로 들어간다 (== Staging Area에 올라감) +ㄴ Git이 해당 파일의 버전관리를 시작함 +ㄴ git restore --staged ${filename} 을 해주면 Staging Area에서 제거 가능 +ㄴ add를 사용하면 어느 부분을 커밋할지 구체적으로 조정이 가능하다 + +**Git Commit** : commit을 해줘야만 **git에 저장**을 할 수 있다 (== Local Repo에 올라감) +ㄴ commit은 git log가 남음. add 한 것들에 스탬프를 찍는 과정. + +**Git Push** : 내가 commit 한 것들을 원격 저장소에 저장함 (== Remote Repo에 올라감) +ㄴ 하기 전에 원격 저장소와 연결이 되어 있어야 함 + +**Git Pull** : remote -> local 로 코드를 가져옴 & 더 최신 코드라면 merge 까지 진행 + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +*"HEAD와 branch는 포인터이다"* + +HEAD : 레포에서의 현재 사용자 위치(checkout을 하면 HEAD가 바뀜) +branch : 일종의 타임라인으로, 각 branch는 독립된 context를 가진다. (-> 다른 브랜치에 영향 x) + +git branch {브랜치명} : 새로운 브랜치 생성 가능(HEAD가 이를 가리키게 됨) +git checkout {브랜치명} : HEAD를 움직여서 다른 브랜치로 전환 가능 + + + +## clone, init, origin +#### git clone과 git init의 차이점, 이용방법 +git init : .git이라는 하위 폴더를 생성해 해당 폴더를 git으로 관리할 수 있게 해줌. +git clone : remote로부터 프로젝트를 local에 복제함. +ㄴ git clone {깃허브 코드 주소}.git + +#### origin이란 키워드는 무엇인지, 어떻게 설정하는지 +origin : 현재 git에서 작업하는 local과 연결된 **remote의 주소**를 가리킴. +git remote : origin 생성 +git remote remove origin : origin 삭제 + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +#### reset의 3가지 타입 +1. git reset --soft +ㄴ HEAD가 특정 커밋을 새롭게 가리킴 (working directory OR staging area 영향 x) +2. git reset --mixed +ㄴ HEAD가 특정 커밋을 새롭게 가리킴 (staging area도 해당 커밋의 모습과 동일하게 변함) +3. git reset --hard (주의 요망) +ㄴ HEAD가 특정 커밋을 새롭게 가리킴 (working directory & staging area 모두 변함) + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +#### Pull Request +협업을 할 때, push를 한 뒤에 변경사항을 기록하고 pull request를 요청한다. + +#### Merge +팀원의 PR(Pull Request) 내용을 확인한 후, 다른 코드에 영향을 미치지 않고 remote 저장소에 반영해도 된다면, 그때 merge를 진행한다. (-> 원본 저장소에 바뀐 내용이 반영되어 합쳐진다) + +##### Merge_Fast-Forward +현재 브랜치의 HEAD가 대상 브랜치의 HEAD로 옮겨지는 merge +```git switch [현재 브랜치]``` +```git merge [대상 브랜치]``` +But, 중간에 다른 커밋이 있다면 Conflict 발생 -> 동작 x + +##### Merge_3-way Merge +merge 할 때 두 브랜치가 동일 선상에 없을 때, **공통 조상**으로 merge 진행 +```git checkout master``` +```git merge {브랜치명}``` +공통조상 (Base)를 기준으로, merge의 결과로 채택한 후 +두 브랜치가 다른 변화를 발생시켰다면 이를 충돌로 판단하고 해결해야 merge 가능 + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase = base를 새롭게 설정한다 +```git checkout experiment``` +```git rebase main``` +아예 다른 브랜치로 이동해 main(master)를 base 삼아 rebase 하게 됨. +최근 두 브랜치의 차이를 Patch 라는 곳에 임시 저장해 둔 후에, +base가 되는 master에 Patch가 적용된다. +```git checkout main``` +```git merge experiment``` +이후, main브랜치를 fast-forward merge 한다. + +Fast-Forward merge를 하기 때문에 -> **깔끔한 커밋 히스토리를 유지**할 수 있다는 게 장점!! +But, 깃히스토리를 조작하고 강제 push가 동반되기 때문에 위험함!!! + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash : 작업중인 것을 잠시 치워두다(->스택에) +```git stash``` : 현재 적용된 commit 이후로 변경된 모든 사항들이 stash 공간으로 이동 +```git stash apply``` : 했던 작업 다시 가져오기 +```git stash drop``` : 스택에 남아있는 stash 제거하기 +```git stash list``` : stash 목록 보기 + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git "a/git-basics/22nd/README-\352\271\200\354\236\254\354\213\235.md" "b/git-basics/22nd/README-\352\271\200\354\236\254\354\213\235.md" new file mode 100644 index 0000000..18dd978 --- /dev/null +++ "b/git-basics/22nd/README-\352\271\200\354\236\254\354\213\235.md" @@ -0,0 +1,176 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +git을 통해 local에 저장, version 관리에 이용 + +github를 이용해 git이 local에 저장하는 데이터를 remote에 업로드, 온라인으로 공유, 협업을 지원 + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +Working Directory : 일반적으로 local의 실제 파일을 작업, 수정하는 공간 + +Git Add : 변경된 파일을 Staging Area에 올리기. git이 추적할 변경 사항을 지정 + +Git Commit : Staging Area에 추가된 변경 사항을 Local Repo에 저장. 새로운 version 추가 + +Git Push : local에 저장된 commit된 변경 사항을 github에 업로드 + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +commit : 개발과정에서 변경된 내용을 기록하는 version의 단위 + +branch : 파생된 독립적인 개발 라인 + +head : 현재 위치한 commit 또는 branch를 가리키는 pointer + + # 새로운 브랜치 생성 (feature 브랜치) + git branch feature-branch + + # 브랜치 목록 확인 + git branch + + # 현재 HEAD가 가리키는 커밋 확인 + git log --oneline --decorate + + # 특정 커밋으로 이동 (Detached HEAD 상태) + git checkout <커밋 해시값> + + # 특정 브랜치로 이동 (Checkout) + git checkout feature-branch + + # 다시 원래 브랜치로 돌아오기 + git checkout main + + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +git clone : remote Repo에서 local로 복사 + + #복사 + git clone + +git init : 새로운 git 저정장소 생성 + + # 현재 디렉토리를 Git 저장소로 만들기 + git init + + # 원격 저장소(origin) 연결 + git remote add origin + + # 변경 사항을 원격 저장소로 푸시 + git push -u origin main + +origin : remote Repo의 기본 이름 + + # 확인 + git remote -v + + # 설정 + git remote add origin + + # 삭제 + git remote remove origin + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + + # 최근 commit만 취소 + git reset --soft + + # 최근 commit 취소, staging area 비움 + git reset --mixed + + # local 포함, 모든 변경 사항 삭제. 이전 commit의 version으로 되돌림 + git reset --hard + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. + +PR : github에서 코드 리뷰, 병합을 요청하는 기능 + +Merge : 한 branch의 변경 사항을 다른 branch에 반영하는 과정. PR 승인 후 진행행 + +Fast-Forward : 새로운 branch에서 변경 사항만 추가된 경우, Git이 단순히 commit을 이동시키는 방식 + + # Fast-Forward 병합 실행 + git merge feature + +3-Way Merge : Git이 각 branch의 변경 사항을 비교하여 새로운 Merge Commit을 생성. +main과 feature가 서로 다른 변경 사항을 포함하고 있으면 3-Way Merge가 발생 + + # 3-Way Merge 실행 + git merge --no-ff feature + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +한 브랜치의 변경 사항을 다른 branch의 최신 commit 위로 재배치. +branch의 commit을 정리하고 히스토리를 깔끔하게 유지. 기존 commit 히스토리를 보존하고자 한다면 사용에 유의 + + # feature 브랜치를 main 브랜치의 최신 상태로 업데이트 + git checkout feature + git rebase main + + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +작업 변경 사항을 add, commit 없이 임시저장. + + # 임시 저장 + git stash + + # 최근 저장 불러오기 + git stash pop + + # 목록 보기 + git stash list + + # 지정 불러오기 + git stash apply stash@{0} + + # 지정 삭제 + git stash drop stash@{0} + + # 전체 삭제 + git stash clear + + # 메모 달아 저장하기 + git stash save "메모" + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git "a/git-basics/22nd/README-\352\271\200\354\236\254\355\230\225.md" "b/git-basics/22nd/README-\352\271\200\354\236\254\355\230\225.md" new file mode 100644 index 0000000..c841642 --- /dev/null +++ "b/git-basics/22nd/README-\352\271\200\354\236\254\355\230\225.md" @@ -0,0 +1,140 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +>* git은 local storage에서 동작 +> * 다른 개발자와 작업물을 공유하는 것은 어렵다. +>* github는 웹 상의 remote stroage에 작업물을 저장 +> * 다른 개발자와 작업물을 공유하기 편해진다. + +[참고자료](https://yeongjaekong.tistory.com/4) + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +>* Working Directory: 현재 작업을 하고 있는 디렉토리 +> * 이 디렉토리 안 모든 파일은 tracked(프로젝트 디렉토리에 존재하는 경우)/untracked(이 프로젝트 디렉토리에 없는 경우)로 나뉨 +> * tracked는 또 수정/커밋 유무에 따라 상태가 변화 +>* Git Add: working directory의 변경 사항을 staging area에 추가(add)하는 것 +> * 절대/상대 경로를 사용하여 파일,디렉토리를 추가할 수 있다. +>* staging area: git add를 통해 추가된 파일/디렉토리의 영역 +>* Git Commit: git add를 통해 staging area로 올린 작업물들을 commit하여 local repository에 변경사항을 반영 +>* local repository: git commit을 통해 변경이 확정되면 변경사항을 반영하고 버전을 매긴다. +>* Git push: git commit을 통해 변경사항을 반영한 작업물들을 remote storage에 저장되어있는 작업물들도 변경사항이 반영되도록 하는 작업 +>* Git pull: 다른 개발자가 github의 remote storage에 변경사항을 반영하였고 나의 local storage에는 변경사항이 반영되지 않은 경우, git pull을 사용하여 나의 local storage를 최신 버전으로 업데이트가 가능 + +[참고자료1](https://iseunghan.tistory.com/322) +[참고자료2](https://anerim.tistory.com/203) + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +>* git의 HEAD와 branch는 포인터 +>* HEAD는 branch를 통해 직접적으로 commit을 가리키고 있음 +> * commit을 할 때마다 가장 최근 commit을 가리키러 HEAD가 가리키고 있는 branch가 이동한다. +>* branch를 새로 생성하면, 이 branch는 마찬가지로 HEAD가 가리키고 있는 commit을 가리킨다. + +[참고자료](https://charles098.tistory.com/24) + +### branch관련 명령어 +``` +// Branch 생성 +$ git branch <새로운_브랜치_이름> + +// Branch 삭제 +$ git branch -d <삭제할_브랜치_이름> + +// Branch 이동, HEAD가 이동할 branch를 가리킨다. +$ git checkout <이동할_브랜치_이름> + +// 새로운 branch 생성 후 이동 +$ git checkout -b <새로운_브랜치_이름> +``` + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +> * git init: local에 git이 관리하는 빈 저장소를 새로 만드는 명렁어 +> * 새로운 프로젝트를 시작하기 전에 이 명령어를 사용하면 git이 해당 디렉토리를 관리해준다. +> * git clone: github의 remote repository를 그대로 복제하여 local에 해당 프로젝트 디렉토리를 만드는 방식이다. + +>* origin: remote repository의 주소를 키워드로 만들어서 대신 사용하는 것 +> * remote repository의 주소를 일일이 기억하고 입력하는 것이 불편하기 때문 + +``` +// 새로운 origin 설정 +$ git remote add origin 'remote repositroy 주소' +``` + +[참고자료](https://velog.io/@yejine2/git-%EC%A0%80%EC%9E%A5%EC%86%8C-%EC%83%9D%EC%84%B1-init-clone-%EB%B0%A9%EB%B2%95) + + + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +> * git reset은 soft,mixed,hard가 존재 +>* git reset --soft : 되돌아갈 commit의 hash값을 적으면 HEAD가 가리키는 branch가 가리키는 commit이 사용자가 되돌아가려고 하는 commit을 가리킴 (commit 취소) +>* git reset --mixed : soft 작업에서 staging area까지 비우는 작업을 수행 (commit 취소, add 취소) +>* git reset -- hard : mixed작업에서 이번엔 working directory에서 변경했던 데이터까지 되돌림 +> * 로컬에 저장된 데이터까지 롤백 +> * commit을 한 적이 없는 변경사항은 모두 덮어써져 복구가 되지 않음에 주의. + +[참고자료](https://git-scm.com/book/ko/v2/Git-%EB%8F%84%EA%B5%AC-Reset-%EB%AA%85%ED%99%95%ED%9E%88-%EC%95%8C%EA%B3%A0-%EA%B0%80%EA%B8%B0) + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. + +> * pull request(pr): branch를 새로 생성하고 checkout을 통해 HEAD가 가리키는 branch를 바꾼 후 수정한 작업물을 push하는 경우에 가능 +> * pr을 생성하게되면 main branch와 변경사항을 비교할 수 있으며, 변경을 확정하고 싶으면 merge, 아니라면 pr을 종료시킬 수 있다. + +> * Fast-forward: 기준 branch에는 신규 commit이 없고 새로운 branch에만 commit이 존재하는 경우, 새로운 branch를 그냥 main branch로 보고 병합해버리는 방식 +> * 3-way merge: 두 branch가 신규 commit이 1회 이상 있는 경우 merge를 진행하는 경우에 발생. 두 branch의 코드를 합쳐서 새로운 commit 생성하여 merge + + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +> * rebase: branch의 시작점을 다른 commit으로 옮겨주는 것 +> * 앞서 살펴본 merge방식을 branch의 시작점을 바꿈으로써 개발자가 제어 가능 + + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +> * git stash: 수정한 파일, add한 파일들을 스택에 저장해두는 명령어 +> * 하던 작업을 멈추고 다른 branch로 이동이 필요한 경우 stash를 이용하여 하던거 까지 저장 가능 + + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git "a/git-basics/22nd/README-\352\271\200\354\247\200\353\257\274.md" "b/git-basics/22nd/README-\352\271\200\354\247\200\353\257\274.md" new file mode 100644 index 0000000..34656fe --- /dev/null +++ "b/git-basics/22nd/README-\352\271\200\354\247\200\353\257\274.md" @@ -0,0 +1,183 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) + +Git은 버전관리 소프트웨어이다. 로컬 저장소의 모든 변겅사항을 기록하여 파일의 버전 관리를 한다. + +반면 Github는 Git 을 사용하는 프로젝트를 지원하는 웹 호스팅 서비스로, Git 은 로컬 저장소에서만 작동하기 때문에 다른 개발자와 작업을 공유하고 협업하기 어렵지만 Github를 사용해 로컬 저장소의 코드를 원격 저장소에 업로드 하고 공유하며 협업할 수 있다. + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. + +- **Working Directory** + + working directory 는 작업폴더로, 데이터를 불러오거나 외부로 저장하는 작업을 수행하는 기본 폴더이다. 실제 작업파일이 있는 곳이다. + +- **Staging Area** + + 스테이징 영역은 데이터가 변환되기 전에 윈시/처리되지 않은 데이터가 있는 영역을 말한다. + +- **Local Repo** + + 내 컴퓨터에 저장된 Git 저장소. 변경사항을 내 컴퓨터에서만 관리 가능하다. + +- **Remote Repo** + + GitHub 등의 클라우드 서버에 있는 Git 저장소. + 여러명이 협업할 수 있도록 온라인에 저장된다. + +- **Git Add** + + git add 는 작업 디렉토리 상의 변경 내용을 스테이징 영역에 추가하기 위해 사용하는 명령어이다. 커밋을 하기 전에 어떤 변경사항을 저장할지 선택한다. + git add 를 하면 변경된 파일이 스테이징 영역으로 올라간다(커밋 대기 상태) + +- **Git Commit** + + git commit 은 파일 및 폴더의 추가/변경 사항을 로컬 저장소에 기록하는 것이다. + 파일(폴더)의 버전에 변화가 발생했다는 것이고, 특정 작업이 완결된 상태로 바뀌었다는 것을 의미한다. 변경 내역에 대한 설명으로 커밋 메세지도 포함한다. + +- **Git Push** + + 로컬 저장소에 저장된 커밋한 작업 내용을 원격 저장소에 업로드 하기 위한 명령어. + + + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. + +- **Branch** + + Git 에서 독립적으로 개발을 진행할 수 있도록 만들어주는 분기 역할을 함. main 과 분리된 상태에서 새로운 작업을 할 수 있는 작업 공간이다. 커밋을 가리키는 포인터 역할을 한다. + 생성 및 삭제가 가능하다. + + 생성 : `git branch <브랜치이름>` + + 삭제 : `git branch -d <브랜치이름>` + +- **Head** + + 모든 브랜치에는 head 값이 존재하는데, 해당 브랜치의 마지막 커밋의 상태를 가리킨다. + (특정 브랜치의 마지막 커밋에 대한 포인터) + + +git checkout 명령어는 브랜치 간 전환 또는 현재 작업중인 파일들을 복원할 때 사용한다. +- 브랜치 이동 : `git checkout <브랜치이름>` +- 특정 커밋으로 이동 : `git checkout ` +- 작업 디렉토리에서 변경 내용 되돌리기 : `git checkout -- ` + + + +## clone, init, origin +Gir 저장소를 만드는 방법은 크게 두 가지가 존재한다. + +1. 아직 버전 관리를 하지 않은 로컬 디렉토리 하나를 선택해서 Git 저장소를 적용함. + -프로젝트의 디렉토리로 이동한 후 git bash here 기능을 이용해 아래의 명령을 실행 + `git init` + +2. 기존의 저장소를 Clone 함. + -다른 프로젝트에 참여하거나 Git 저장소를 복사하고 싶을 때 git clone 명령어를 사용해서 프로젝트 히스토리를 전부 받아온다. + `git clone ` + + +- **Origin** + + origin 은 대표적으로 사용되는 원격 저장소의 별칭을 의미함. + + 1. 별칭 등록 + `git remote add {별칭} {원격지 주소}` + + 2. 별칭 변경 + `git remote rename {변경전} {변경후}` + + 3. 별칭 삭제 + `git remote rm {별칭}` + + + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +git reset 은 HEAD 의 위치를 현재의 커밋에서 과거의 커밋으로, 미래의 커밋으로 이동시킬 수 있는 커맨드이다. + +reset에는 3가지 타입이 있습니다. + +1. soft + soft 옵션을 쓰면 HEAD가 특정 커밋을 새롭게 가리키게 된다. + 대신 현재 작업중인 working directory 와 staging area 는 아무런 영향을 받지 않음 + +2. mixed + 역시 HEAD 가 특정 커밋을 가리키게 되고 staging area도 해당 커밋의 모습과 동일하게 변함. working directory는 아무런 영향을 받지 않음. + +3. hard + HEAD 가 특정 커밋을 가리키게 되고, + staging area 와 현재 작업중인 working directoty 모두 해당 커밋의 모습과 동일하게 변함. + + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) + +- **Pull Request** + + pull request 란 다른 사용자가 작성한 저장소에서 변경사항을 병합(merge) 하기 위한 요청을 의미한다. + +- **Merge** + + Merge 는 합병이라는 뜻으로 서로다른 브랜치를 병합해서 작업한 내용을 합치는 것을 의미한다. + + 1. Fast-Forward Merge + 현재 브랜치의 HEAD가 대상 브랜치의 HEAD 까지로 옮기는 merge + `git switch <현재 브랜치>` + `git merge <대상 브랜치>` + + 중간에 변경이 없을 때만 동작함. + + 2. 3-Way Merge + 대부분의 협업에서 발생하게 되는 merge 방식 + 두 브랜치가 동일 선상이 아닐때 발생함 + + 두 브랜치가 분할되는 기점에서 공통조상을 찾고 두 브랜치 커밋과 공통조상의 커밋, 총 3개의 커밋이 관여하게 됨. + + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +### Git rebase란? +`git rebase` 는 두개의 공통 base 를 가진 branch에서 한 branch 의 base 를 다른 branch의 최신 커밋으로 branch의 base를 옮기는 작업이다. + +**장점** +1. 공유 branch의 최신 변경사항을 즉각 반영할 수 있다. +2. rebase 는 커밋 이력을 남기지 않으므로 commit history 가 깔끔해진다. + + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +stash를 이용해 작업중에 갑작스럽게 다른 작업을 진행해야 할 때, 작업중인 사항을 잠시 치워둘 수 있다. + +코드를 다른곳에 보관한 후에 내가 원하는 branch 에 적용할 수 있다. + +- git stash 로 변경사항들을 stash 공간으로 이동. + `git stach` +- stash 한 변경사항 다시 적용 및 삭제 + `git stach pop` +- stash 한 마지막 항목 적용(삭제) + `git stash apply(drop)` +- 새 브랜치 생성하여 pop + `git stash branch <브랜치명>` + + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git "a/git-basics/22nd/README-\352\271\200\355\203\234\354\232\260.md" "b/git-basics/22nd/README-\352\271\200\355\203\234\354\232\260.md" new file mode 100644 index 0000000..d7fd027 --- /dev/null +++ "b/git-basics/22nd/README-\352\271\200\355\203\234\354\232\260.md" @@ -0,0 +1,88 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +git - local에서 프로젝트의 작업 내용을 기록하고, 이전상태로 되돌리는 등의 역할을 한다. +github - git저장소를 온라인에서 관리하도록 하여 협업을 용이하게 해준다. 즉 remote 저장소 역할을 한다. + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +- Working Directory : 현재 작업중인 파일이 있는 공간, 코드작성 및 수정을 하는 공간이다. +- Git Add : git add 파일 , 커밋을 하기전에 어떤 파일을 변경사항에 포함할지 정하는 단계이다. git add를 통해 staging Area에 파일을 올린다. +- Git Commit : git commit -m "커밋내용" , staging Area에 올라와있는 변경사항을 locale에서 확정하는 단계이다. +- Git Push : git push origin 브랜치 , locale 레포에 있는 변경사항을 remote 저장소로 올린다. + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +-branch를 생성하고 이동하는 명령어 : git checkout -b 새로운-브랜치명 +-HEAD : 현재 작업 중인 브랜치를 가리키는 포인터이다. + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +- git clone : 이미 존재하는 원격 리포지토리를 로컬에 복제할 때 사용한다. 원격 저장소를 복제하여 폴더가 자동으로 생성되고, 해당 폴더에서 바로 Git이 활성화된다. +- git init : 완전히 새로운 Git 리포지토리를 로컬에서 처음부터 생성할 때 사용한다. 원격 저장소는 따로 설정되지 않아, 필요할 시 수동으로 추가해야한다. + +- origin : 기본적으로 원격 저장소를 가리키는 별칭이다. git clone을 하면 자동으로 설정되지만, git init을 사용한 경우 수동으로 설정해야한다. (git remote add origin <원격_저장소_URL> 명령어 이용용) + + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +- git reset --soft : 최근 커밋을 취소하고, 변경 사항을 Staging Area로 유지한다. 즉 커밋만 되돌리고, git add 한 상태는 유지하는 것이다. +- git reset --mixed : 최근 커밋을 취소하고, 변경 사항을 Staging Area에서도 삭제한다. 즉, git add한 것도 취소되지만 파일 자체는 working directory에 남아있다. +- git reset --hard : 최근 커밋을 취소하고, Staging Area와 Working Directory의 변경 사항도 모두 삭제한다. 즉 수정내용이 전부 완전히 삭제된다. + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. +- Pull Request : 브랜치에서 작업한 변경 사항을 메인 브랜치에 Merge하기 전에 검토 요청을 보내는 과정이다. +- Merge + - 다른 브랜치에서 작업한 내용을 현재 브랜치로 합치는 과정이다. + - 브랜치가 한 방향으로만 진행된 경우, 새로운 Merge 커밋을 생성하지않고 단순히 최신 커밋으로 이동하는데, 이를 Fast-Forward Merge라고한다. 이는 충돌이 발생할 확률이 거의없지만 기록유지는 힘들다. + - 브랜치가 서로 다른 커밋을 포함하고 있을 때 하는 Merge 방식으로 3-Way Merge가 있다. 독립적으로 진행된 변경 사항을 통합해야 하므로 충돌이 일어날 수 있고, 작업기록을 명확히 남긴다. + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. +- Git Rebase + -브랜치를 다른 브랜치의 최신 상태로 변경하는 작업이다. + -git merge를 이용해 병합할때 ,병합커밋으로 인해 복잡할 수 있는 기록을 rebase를 이용하여 커밋을 깔끔하게 관리한다. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. +- 현재 변경 사항을 Stash에 저장하고, working directory는 수정전으로 돌아간다. +- pull을 통해 최신 코드를 불러오고 stash에 저장해두었던 코드를 불러와 이전 변경 사항을 복원시킨다. + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git "a/git-basics/22nd/README-\353\260\225\354\206\214\354\230\201.md" "b/git-basics/22nd/README-\353\260\225\354\206\214\354\230\201.md" new file mode 100644 index 0000000..4f543f3 --- /dev/null +++ "b/git-basics/22nd/README-\353\260\225\354\206\214\354\230\201.md" @@ -0,0 +1,94 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +git은 local 저장소를 사용하기 때문에 다른 사람이 접근할 수 없다.
+github는 git을 기반으로 하는 remote 저장소이므로 다른 사람들이 공유하고 접근할 수 있다. + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +working directory는 git이 관리하는 프로젝트의 실제 파일이 위치하는 곳이다.
+staging area는 commit을 수행하기 전에 변경사항을 일시적으로 저장하는 영역이다.
+working area에서 파일을 수정하고 이를 git에게 알리기 위해 git add를 사용하여 staging area에 추가한다.
+staging area의 변경 사항을 local repo에 영구적으로 저장하기 위해 git commit 명령어를 사용한다.
+local repo의 변경사항을 remote repo로 업로드 하기 위해 git push를 사용하여 변경 사항을 공유한다.
+반대로 remote repo의 변경사항을 local repo로 가져 오기 위해서는 git pull을 사용한다 + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +commit을 branch가 가리키고 HEAD는 branch를 가리킨다.
+commit을 하면 HEAD가 가리키는 branch가 최신 commit으로 이동한다.
+git checkout <브랜치명>을 하면 해당 branch로 HEAD가 이동한다.
+git branch -b <브랜치명>을 사용하면 branch가 생성되고 git branch -d <브랜치명>을 사용하면 해당 branch가 삭제된다. + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +원하는 directory에서 git init을 사용하면 그 안에 빈 git 리포지토리를 만든다
+git clone 을 사용하면 현재 directory의 안에 url에 해당하는 리포지토리를 복제한다.
+origin은 현재 git에서 작업하는 local repo와 연결된 remote repo의 주소를 가리키는 단축이름으로 git 리포지토리를 복제할 때 자동으로 생성된다.
+새로운 remote repo를 추가하려면 git remote add origin <추가할 remote repo 주소>를 사용하면 된다.
+기존에 origin이 존재하는데 새로 추가하고 싶으면 git remote remove origin을 사용하여 기존 origin을 삭제하고 추가하면 된다. + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +soft에서 HEAD는 첫번째 commit을 가리킨다. 하지만 staging area와 working directory는 기존의 commit 상태로 유지된다.
+mixed는 soft 유형에서 staging area도 함께 첫 번째 commit의 상태로 변경된다.
+hard는 mixed 유형에서 working directory도 첫 번째 commit의 상태로 변경된다. + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. + +프로젝트 리포지토리에서 fork를 눌러 자신의 리포지토리로 가져온 후 로컬 리포지토리에서 clone한다.
+내용 수정 후 자신의 리포지토리에 수정 브랜치를 push한다. 그 후 pull request 버튼을 누르고 메세지 작성후 보낸다.
+프로젝트 리포지토리 관리자는 pr의 변경 내용을 확인 후 merge한다.
+fast-forward : 메인 branch에 변경 사항이 없다면 head가 병합하려는 branch의 마지막 commit으로 이동한다.
+3-way merge : 메인 branch에 변경 사항이 있다면 병합하려는 branch와의 공통 commit을 찾아 병합하고 새로운 commit을 생성하여 두 개의 branch와 연결한다. + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +rebase는 branch가 갈라질 때 메인 branch의 마지막 commit을 조상으로 하는 새로운 commit들을 생성하여 병합하려는 branch의 변경사항들을 차례대로 적용하는 것이다.
+commit history를 시간 순서대로 남길 수 있어서 과거 commit history를 수정하기 좋다. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +현재 작업하던 브랜치가 아닌 다른 브랜치에서 작업해야 할 때 git stash를 사용하여 변경 내용을 로컬 저장소에 임시로 저장할 수 있다.
+git stash list를 통해 저장된 내용을 볼 수 있고 git stash apply를 통해 치워둔 마지막 항목을 불러올 수 있다. 끝에 번호를 적으면 항목 지정이 가능하다. + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git "a/git-basics/22nd/README-\354\236\204\353\202\230\353\271\210.md" "b/git-basics/22nd/README-\354\236\204\353\202\230\353\271\210.md" new file mode 100644 index 0000000..9c4324a --- /dev/null +++ "b/git-basics/22nd/README-\354\236\204\353\202\230\353\271\210.md" @@ -0,0 +1,121 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +Git은 버전 관리 시스템이고 local에서 파일을 추적하고 관리합니다. Github는 Git을 기반으로 한 웹 호스팅 서비스로 remote repository를 관리할 수 있는 플랫폼이며 협업을 위해 공유하는 공간입니다 + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +- **Working Directory** : 실제 파일을 편집하는 작업 공간입니다. `git status`를 통해 변경된 파일을 확인합니다. +- **Git Add** : `git add` 명령어를 통해 변경사항을 Staging Area에 추가합니다. + - `git add [filename]` : 특정 파일을 추가 + - `git add .` : 모든 변경사항을 추가 +- **Staging Area** : 커밋할 파일이 임시로 저장되는 공간입니다 +- **Local Repo** : 로컬 저장소이며 커밋된 모든 기록이 저장됩니다 +- **Remote Repo** : 원격 저장소이며 `git fetch`로 Remote Repo의 변경사항을 Local Repo로 가져옵니다(merge는 X), `git pull`은 변경사항을 가져온 후 자동 병합합니다 (merge + fetch) + +- **Git Commit** : `git commit` 명령어를 통해 Local Repo에 변경사항이 저장됩니다. + - `git commit -m "commit message"` +- **Git Push** : `git push` 명령어를 통해 Local Repo의 변경사항을 Remote Repo로 업로드 합니다 + - `git push origin [branch_name]` + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +- **Branch** : 코드 변경 사항을 독립적으로 작업할 수 있도록 하는 기능. 서로 독립적으로 작업하면서 나중에 merge 할 수 있습니다. + - `git branch [branch_name]` : 브랜치 생성 + - `git branch -d [branch_name]` : 브랜치 삭제 + - `git checkout [branch-name]` : 브랜치 이동 +- **HEAD** : 현재 작업 중인 브랜치의 현재 위치를 가리킵니다. Head는 특정 커밋을 가리키고, 커밋을 업데이트 하거나 이동하면 움직입니다. + - `git checkout [commit-id]` : HEAD 이동 +- **git checkout** : 브랜치 변경, 파일 복원 등에 사용합니다 + - `git checkout feature-branch` + - `git checkout [filename]` + - `git checkout [commit_id]` + + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- **git clone** : 원격 저장소의 전체 내용을 로컬로 복제하는 명령어. clone을 사용하면 원격 저장소의 모든 커밋 기록, 브랜치, 태그 등이 로컬 저장소에 복사됩니다. + - `git clone [repository-url]` +- **git init** : 새로운 로컬 저장소를 생성하는 명령어. + - `git init` +- **origin** : 원격 저장소를 나타냅니다. origin은 URL을 가리키며 로컬 저장소와 원격 저장소를 연결할 수 있습니다 + - `git remote add origin [repository_url]` : 원격 저장소 설정 + - `git remote -v` : 원격 저장소 확인 + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +- **git reset** : 작업 중인 커밋을 되돌리는 명령어 + - `git reset -- soft [commit_id]` : HEAD 포인터를 이동시켜 지정된 커밋으로 되돌리지만, Working Directory와 Staging Area는 그대로 두고, 해당 커밋 이후의 변경 사항은 그대로 Staging 상태로 남겨둡니다 + + - `git reset --mixed [commit_id]` : HEAD 포인터는 지정된 커밋으로 이동하고 변경사항은 Working Directory에는 + 남아있으나 Staging Area에서만 제거됩니다 (기본 옵션) + - `git reset --hard [commit_id]` : HEAD 포인터를 지정된 커밋으로 이동시키고 Working Directory와 Staging Area 모두를 해당 커밋 상태로 되돌립니다 (이전 변경 사항이 모두 삭제됨) + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. +- **Pull Request** : 한 브랜치에서 다른 브랜치로 변경 사항을 병합하고자 할 때 리뷰를 요청하는 과정. PR을 통해 팀원들이 코드 변경을 리뷰하고 문제를 수정하거나 논의할 수 있습니다 + + 1. 브랜치에서 작업을 완료하고 커밋 push + 2. pr을 생성하여 리뷰 요청 + + 3. 변경 사항을 리뷰하고 피드백 제공 + 4. 리뷰가 완료되면 변경사항 merge + +- **Merge** : 두 개의 브랜치를 하나로 합치는 기능. PR을 통해 이루어 지며 Git에서 자동으로 병합을 시도하고 충돌이 있을 경우 수동으로 해결해야합니다. + + - Fast-Forward Merge : HEAD 포인터를 이동시켜 병합하는 방식으로 병합 커밋이 생성되지 않습니다 + - `git checkout main` + - `git merge feature-branch` + + - 3-Way Merge : 두 브랜치가 서로 다른 변경 사항을 포함하고 있을 때 발생합니다. + + 1. 두 브랜치가 갈라지기 전의 마지막 공통 커밋을 찾는다 + 2. 브랜치 A 변경사항 확인 + 3. 브랜치 B 변경사항 + 4. 병합이 완료되면 Git이 병합 커밋 생성 + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +한 브랜치의 변경 사항을 다른 브랜치의 맨 위로 적용하는 방법. +- `git checkout featchure-branch` +- `git rebase main` + + 1. feature-branch에 있는 커밋들이 main 브랜치의 최신 커밋 뒤에 재적용됨 (병합 커밋 생성X) + 2. 충돌이 발생할 경우 해결 후 `git rebase --coninue`를 실행하여 계속 진행 +- 병합 커밋 없이 커밋 히스토리를 관리할 때 유용합니다 + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +현재 작업 중인 변경 사항을 임시로 저장하고 Working Directory를 깨끗하게 되돌리는 기능. 다른 브랜치로 이동하거나 작업을 잠시 중단해야 할 때 사용됩니다. +- `git stash` +- `git stash list` : 저장한 목록 보기 +- `git stash pop` : 가장 최근 stash 복원 + +- `git stash apply stash@{idx}` : 특정 stash 복원 +- `git stash drop stash@{idx}` : 특정 stash 삭제 +- `git stash clear` : 모든 stash 삭제 + + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. + +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git "a/git-basics/22nd/README-\354\265\234\352\264\221\354\247\204.md" "b/git-basics/22nd/README-\354\265\234\352\264\221\354\247\204.md" new file mode 100644 index 0000000..a0564cf --- /dev/null +++ "b/git-basics/22nd/README-\354\265\234\352\264\221\354\247\204.md" @@ -0,0 +1,1020 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +Git과 GitHub는 같은 의미가 아니며, **Local(로컬)과 Remote(원격)** 개념과 관련이 있습니다. + +- **Git**: 분산형 버전 관리 시스템(DVCS)으로, **로컬(Local)에서 코드의 변경 이력을 추적하고 버전 관리를 할 수 있도록 해주는 도구**입니다. 개발자는 Git을 사용하여 변경 사항을 커밋하고, 브랜치를 생성하여 독립적인 개발을 진행하며, 필요에 따라 이전 버전으로 롤백할 수 있습니다. Git은 네트워크 없이도 사용할 수 있으며, 개발자의 **로컬 저장소(Local Repository)** 에 코드가 저장됩니다. + +- **GitHub**: Git을 기반으로 하는 **원격(Remote) 저장소 서비스**로, 로컬에서 관리하던 Git 저장소를 인터넷을 통해 **다른 사람과 공유하거나 협업할 수 있도록 지원하는 플랫폼**입니다. GitHub를 활용하면 원격 저장소(Remote Repository)에 코드를 푸시(Push)하여 백업할 수 있고, 팀원들과 Pull Request(PR) 및 코드 리뷰를 통해 협업할 수 있습니다. + +### **Git과 GitHub의 관계 (Local & Remote 연관)** +1. **Git은 로컬(Local)에서 코드 버전 관리를 담당하고**, GitHub는 원격(Remote)에서 저장소를 호스팅하여 협업할 수 있도록 돕습니다. +2. 로컬에서 `git add` → `git commit`을 수행하여 변경 사항을 기록한 후, `git push`를 사용하여 원격 저장소(GitHub)로 업로드합니다. +3. 반대로, 팀원이 업데이트한 코드가 원격 저장소에 있다면, `git pull`을 사용하여 로컬 저장소로 가져올 수 있습니다. + +즉, **Git은 버전 관리를 위한 도구이고, GitHub는 Git 저장소를 호스팅하는 원격 서비스**입니다. Git을 이용해 로컬에서 작업하고, GitHub를 통해 협업하는 방식으로 활용됩니다. 😊 + + + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +### **Git 동작 과정 설명 (다이어그램 기반)** + +Git은 코드의 변경 사항을 추적하고 버전 관리를 수행하는 도구입니다. 다이어그램을 기반으로 각 개념을 설명하겠습니다. + +--- + +### **1. Working Directory (작업 디렉토리)** +- 현재 작업 중인 디렉토리로, 프로젝트의 소스 코드 파일들이 위치하는 곳입니다. +- 새로운 파일을 생성하거나, 기존 파일을 수정하는 등 모든 변경 사항은 **Working Directory에서 발생**합니다. +- Git의 버전 관리에 포함되지 않은 상태이며, 추적되지 않은(Untracked) 상태일 수 있습니다. + +--- + +### **2. Git Add (스테이징 영역에 추가)** +- `git add` 명령어를 사용하면 **Working Directory에서 변경된 파일을 Staging Area로 이동**시킵니다. +- 변경 사항을 커밋하기 전에 확인하고 준비하는 과정으로, 아직 Git의 최종 버전에 기록되지 않은 상태입니다. +- 예제: + ```bash + git add 파일명 # 특정 파일 추가 + git add . # 모든 변경 사항 추가 + ``` + +--- + +### **3. Staging Area (스테이징 영역, 인덱스)** +- Git이 커밋할 파일을 임시로 저장하는 공간입니다. +- `git add`를 수행한 후 파일이 저장되며, 이후 `git commit`을 통해 로컬 저장소에 기록됩니다. +- 여러 개의 파일을 수정한 후, 원하는 파일만 선택하여 커밋할 수 있습니다. + +--- + +### **4. Git Commit (로컬 저장소에 기록)** +- `git commit`을 수행하면 **Staging Area의 변경 사항이 Local Repository에 저장**됩니다. +- 커밋은 특정 시점의 프로젝트 상태를 기록하는 스냅샷과 같으며, 이후 원격 저장소에 업로드할 수 있습니다. +- 예제: + ```bash + git commit -m "변경 사항 설명" + ``` + +--- + +### **5. Local Repo (HEAD) (로컬 저장소, HEAD 포인터)** +- `git commit`을 수행하면 변경 사항이 Local Repository에 저장됩니다. +- **HEAD는 현재 작업 중인 브랜치의 최신 커밋을 가리키는 포인터**입니다. +- 이 상태에서는 아직 원격 저장소에 업로드되지 않았으며, 다른 사람과 공유할 수 없습니다. + +--- + +### **6. Git Push (원격 저장소로 업로드)** +- `git push`를 사용하면 **Local Repository의 변경 사항을 Remote Repository(GitHub, GitLab 등)로 업로드**할 수 있습니다. +- 원격 저장소에 있는 팀원들이 내 변경 사항을 확인할 수 있도록 공유하는 과정입니다. +- 예제: + ```bash + git push origin main # main 브랜치에 업로드 + ``` + +--- + +### **7. Remote Repo (MASTER) (원격 저장소)** +- GitHub, GitLab, Bitbucket 등의 서비스에 저장되는 **원격 저장소**입니다. +- 여러 개발자가 협업할 때 변경 사항을 공유하는 공간입니다. +- 원격 저장소에 있는 코드를 내려받거나(`git pull`), 최신 내용을 가져올 수 있습니다(`git fetch`). + +--- + +### **8. Git Fetch (원격 저장소의 변경 사항을 가져오기)** +- `git fetch`는 **원격 저장소(Remote)에서 최신 변경 사항을 가져오지만, 자동으로 병합하지 않습니다.** +- 로컬 저장소에 영향을 주지 않으며, 단순히 최신 정보를 가져오는 역할을 합니다. +- 이후 `git merge`를 사용해 원격 변경 사항을 로컬에 반영할 수 있습니다. +- 예제: + ```bash + git fetch origin + ``` + +--- + +### **9. Git Merge (브랜치 병합)** +- `git merge`는 **다른 브랜치에서 가져온 변경 사항을 현재 브랜치에 병합**하는 명령어입니다. +- 일반적으로 `git fetch` 후 변경 사항을 로컬 브랜치에 적용할 때 사용됩니다. +- 예제: + ```bash + git merge origin/main + ``` + +--- + +### **10. Git Pull (원격 저장소의 변경 사항을 로컬에 반영)** +- `git pull`은 `git fetch` + `git merge`를 합친 명령어입니다. +- **원격 저장소(Remote)의 최신 변경 사항을 가져오고(Local), 자동으로 병합(Merge)합니다.** +- 팀원들의 코드 변경 사항을 받아올 때 사용됩니다. +- 예제: + ```bash + git pull origin main + ``` + +--- + +### **정리** +1. **Working Directory**: 실제 작업하는 공간 (파일 추가/수정/삭제 가능) +2. **Git Add**: 변경된 파일을 **Staging Area(스테이징 영역)** 에 추가 +3. **Staging Area**: 커밋할 파일을 준비하는 공간 +4. **Git Commit**: 변경 사항을 **Local Repository(로컬 저장소)** 에 기록 +5. **Git Push**: 로컬 변경 사항을 **Remote Repository(원격 저장소)** 로 업로드 +6. **Git Fetch**: 원격 저장소의 최신 변경 사항을 가져옴 (병합하지 않음) +7. **Git Merge**: 다른 브랜치 또는 원격 저장소의 변경 사항을 현재 브랜치에 병합 +8. **Git Pull**: 원격 저장소에서 변경 사항을 가져오고 자동으로 병합 + +--- + +이제 Git의 흐름을 정리하면 다음과 같습니다. +1️⃣ **파일을 수정/추가 (Working Directory)** +2️⃣ `git add` → 스테이징 영역에 추가 +3️⃣ `git commit` → 로컬 저장소에 기록 +4️⃣ `git push` → 원격 저장소로 업로드 +5️⃣ 다른 팀원의 변경 사항을 반영하려면 `git pull` + +위 내용을 바탕으로 추가 설명이 필요하거나 궁금한 점이 있다면 알려주세요! 😊 + + + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +### **Git의 기본 단위: Commit과 Branch** + +Git은 **Commit(커밋)**과 **Branch(브랜치)** 개념을 기반으로 동작합니다. +- **Commit**: 코드의 변경 사항을 저장하는 스냅샷으로, 특정 시점의 프로젝트 상태를 기록합니다. +- **Branch**: 독립적인 작업을 수행할 수 있도록 만든 **분기(branch)** 입니다. + +--- + +## **1. Branch (브랜치)란?** +브랜치는 **커밋의 흐름을 나누어 독립적인 작업을 진행할 수 있도록 돕는 기능**입니다. +- 여러 개발자가 동시에 작업할 수 있도록 분리된 작업 공간을 제공합니다. +- 기본적으로 Git은 `master`(또는 `main`) 브랜치를 생성하며, 새로운 브랜치를 만들어 병렬 작업이 가능합니다. + +💡 **브랜치를 사용하면 여러 기능을 동시에 개발하고, 이후 병합(merge)할 수 있습니다.** + +--- + +## **2. HEAD란?** +`HEAD`는 **현재 작업 중인 브랜치를 가리키는 포인터**입니다. +- 항상 최신 커밋을 가리키며, 브랜치를 이동하면 HEAD도 함께 이동합니다. +- 현재 작업 중인 브랜치가 어디인지 알려주는 역할을 합니다. +- 위 다이어그램에서는 `FEATURE BRANCH`에 `HEAD`가 위치해 있습니다. + +--- + +## **3. 브랜치 관련 Git 명령어** + +### 🔹 **(1) 브랜치 확인** +```bash +git branch # 현재 브랜치 목록 확인 +git branch -a # 로컬 + 원격 저장소 브랜치 확인 +``` + +### 🔹 **(2) 새로운 브랜치 생성** +```bash +git branch feature-branch # feature-branch라는 새 브랜치 생성 +``` + +### 🔹 **(3) 브랜치 이동 (checkout)** +```bash +git checkout feature-branch # feature-branch로 이동 +``` +- `checkout`을 사용하면 다른 브랜치로 이동할 수 있으며, HEAD도 해당 브랜치를 가리키게 됩니다. + +💡 **Git 2.23 이후 버전에서는 `git switch`를 사용할 수도 있습니다.** +```bash +git switch feature-branch +``` + +### 🔹 **(4) 브랜치 생성과 동시에 이동** +```bash +git checkout -b feature-branch # 새 브랜치를 만들고 바로 이동 +``` +또는 +```bash +git switch -c feature-branch +``` + +### 🔹 **(5) 브랜치 병합 (merge)** +```bash +git checkout main # 메인 브랜치로 이동 +git merge feature-branch # feature-branch를 main에 병합 +``` + +### 🔹 **(6) 브랜치 삭제** +```bash +git branch -d feature-branch # 병합된 브랜치 삭제 (안전한 삭제) +git branch -D feature-branch # 병합되지 않은 브랜치 강제 삭제 +``` + +--- + +## **4. Git에서 브랜치를 활용하는 기본적인 흐름** +1️⃣ `git branch feature-branch` → 새로운 브랜치 생성 +2️⃣ `git checkout feature-branch` → 브랜치 이동 +3️⃣ `git add . && git commit -m "작업 완료"` → 변경 사항 커밋 +4️⃣ `git checkout main` → 메인 브랜치로 이동 +5️⃣ `git merge feature-branch` → 브랜치를 병합 +6️⃣ `git branch -d feature-branch` → 병합된 브랜치 삭제 + +--- + +## **5. 추가적으로 알아두면 좋은 개념** +🔹 `git rebase` → 브랜치를 최신 커밋으로 정리할 때 사용 +🔹 `git stash` → 변경 사항을 임시로 저장하고 브랜치를 이동할 때 사용 +🔹 `git cherry-pick` → 특정 커밋만 선택하여 적용할 때 사용 + +--- + +### **결론** +- `HEAD`는 현재 작업 중인 브랜치를 가리킵니다. +- `git checkout` 또는 `git switch`를 사용하면 브랜치를 변경할 수 있습니다. +- 브랜치를 활용하면 독립적인 작업이 가능하며, 병합(merge)을 통해 코드 변경 사항을 반영할 수 있습니다. + +🚀 **Git 브랜치를 활용하면 여러 기능을 동시에 개발하고 안전하게 관리할 수 있습니다!** +추가 질문이 있다면 알려주세요. 😊 + + + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +## **Git 리포지토리 생성 방법: `git clone` vs `git init`** + +Git에서 로컬에 리포지토리를 생성하는 방법에는 **`git clone`**과 **`git init`** 두 가지가 있습니다. +이 두 가지 방법의 차이점과 함께, 원격 저장소를 의미하는 `origin`의 개념과 설정 방법도 설명하겠습니다. + +--- + +## **1. `git clone` vs `git init` 차이점** + +| 명령어 | 사용 목적 | 원격 저장소 연결 여부 | 기본 사용 예시 | +|--------|------------|----------------|----------------| +| `git clone` | **기존 원격 저장소를 로컬로 복제** | O (자동으로 `origin` 설정됨) | `git clone ` | +| `git init` | **새로운 로컬 저장소 생성** | X (별도로 원격 저장소 연결 필요) | `git init` | + +### **✅ `git clone`** +- **기존 원격 저장소(GitHub, GitLab 등)를 로컬에 복사**하는 명령어입니다. +- 원격 저장소가 있는 경우 사용하며, 자동으로 `origin`이라는 원격 저장소가 설정됩니다. +- 기본적으로 원격 저장소의 모든 내용(파일, 커밋, 브랜치 등)이 복사됩니다. + +#### **🛠 사용 예시** +```bash +git clone https://github.com/user/repository.git +``` +- 위 명령어를 실행하면 `repository` 폴더가 생성되고, 해당 저장소의 코드가 로컬로 복제됩니다. +- `git remote -v`를 실행하면 `origin`이 자동으로 설정된 것을 확인할 수 있습니다. + +--- + +### **✅ `git init`** +- **새로운 로컬 저장소를 생성**할 때 사용합니다. +- 기존의 원격 저장소가 없는 프로젝트에서 처음으로 Git을 사용하려 할 때 유용합니다. +- 원격 저장소(`origin`)와 연결되지 않으므로, 원격 저장소를 따로 설정해야 합니다. + +#### **🛠 사용 예시** +```bash +mkdir my_project +cd my_project +git init +``` +- 위 명령어를 실행하면 `.git` 폴더가 생성되며, Git으로 버전 관리를 시작할 수 있습니다. + +--- + +## **2. `origin`이란?** +- `origin`은 **로컬 저장소에서 기본적으로 가리키는 원격 저장소의 이름**입니다. +- `git clone`을 하면 자동으로 `origin`이 설정됩니다. +- `git init`을 한 경우에는 원격 저장소가 없으므로, `origin`을 직접 설정해야 합니다. + +--- + +## **3. `origin` 설정 방법** + +### **✅ `git clone`을 사용한 경우** +- `git clone`을 하면 `origin`이 자동으로 설정됩니다. +- 확인 방법: + ```bash + git remote -v + ``` + 예제 출력: + ``` + origin https://github.com/user/repository.git (fetch) + origin https://github.com/user/repository.git (push) + ``` + +--- + +### **✅ `git init`을 사용한 경우 (`origin` 직접 설정)** +- `git init`으로 생성한 로컬 저장소에 원격 저장소를 추가하려면 다음과 같이 설정합니다. + +#### **🛠 원격 저장소 추가하기** +```bash +git remote add origin https://github.com/user/repository.git +``` +- 이제 `git push origin main` 등의 명령어를 사용할 수 있습니다. +- `git remote -v`로 `origin`이 정상적으로 추가되었는지 확인할 수 있습니다. + +#### **🛠 원격 저장소 변경하기** +```bash +git remote set-url origin https://github.com/newuser/newrepository.git +``` + +#### **🛠 원격 저장소 삭제** +```bash +git remote remove origin +``` + +--- + +## **4. 실전 예제: `git init` + 원격 저장소 연결** +1️⃣ **새 프로젝트를 생성하고 Git을 초기화** +```bash +mkdir new_project +cd new_project +git init +``` + +2️⃣ **파일 추가 및 첫 커밋** +```bash +echo "# New Project" > README.md +git add . +git commit -m "Initial commit" +``` + +3️⃣ **GitHub 원격 저장소 추가 (`origin` 설정)** +```bash +git remote add origin https://github.com/user/new_project.git +``` + +4️⃣ **로컬 커밋을 원격 저장소에 푸시** +```bash +git push -u origin main +``` + +--- + +## **5. 정리** +| 명령어 | 설명 | +|--------|------------| +| `git clone ` | 원격 저장소를 로컬에 복제 (자동으로 `origin` 설정) | +| `git init` | 새로운 로컬 저장소 생성 (원격 저장소 미연결) | +| `git remote add origin ` | 원격 저장소를 `origin`으로 추가 | +| `git remote -v` | 현재 설정된 원격 저장소 확인 | +| `git remote set-url origin ` | `origin`의 URL 변경 | +| `git remote remove origin` | 원격 저장소 `origin` 삭제 | + +**🚀 `git clone`은 기존 원격 저장소를 복제할 때, `git init`은 새로운 프로젝트를 Git으로 관리할 때 사용됩니다.** +추가 질문이 있다면 알려주세요! 😊 + + + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +## **Git `reset`의 3가지 타입: `soft`, `mixed`, `hard`** + +Git의 `reset` 명령어는 특정 커밋으로 되돌아갈 때 사용됩니다. +이때 **되돌아가는 방식**에 따라 **`--soft`, `--mixed`, `--hard`** 세 가지 옵션이 있습니다. + +--- + +## **1. `git reset --soft`** +- **HEAD만 이동**, Staging Area(= Index)와 Working Directory는 그대로 유지 +- 되돌아간 커밋 이후의 변경 사항이 **Staging Area에 남아 있음** +- `git commit --amend` 또는 추가적인 수정 후 다시 커밋할 때 유용 + +### **🛠 사용 예시** +```bash +git reset --soft HEAD~1 +``` +- 마지막 커밋을 되돌리지만, 변경된 파일들은 여전히 **Staging Area**에 있음 +- 다시 `git commit`을 하면 기존 커밋을 수정할 수 있음 + +--- + +## **2. `git reset --mixed` (기본값)** +- **HEAD와 Staging Area(Index)만 이동**, Working Directory는 유지 +- 즉, 되돌아간 커밋 이후의 변경 사항이 **Unstaged 상태(Working Directory)로 이동** +- 기본 옵션이므로 `--mixed`를 생략하면 자동으로 적용됨 +- 수정한 내용을 다시 Staging하고 싶다면 `git add .`를 실행해야 함 + +### **🛠 사용 예시** +```bash +git reset --mixed HEAD~1 +``` +- 마지막 커밋을 되돌리지만, 변경된 파일들은 **Staging Area에서 빠지고(unstaged)**, **Working Directory에는 남아 있음** + +--- + +## **3. `git reset --hard`** +- **HEAD, Staging Area(Index), Working Directory 모두 되돌림** +- 되돌아간 커밋 이후의 변경 사항이 **완전히 삭제됨** (복구 불가!) +- 정말 되돌리고 싶은 경우에만 신중하게 사용 + +### **🛠 사용 예시** +```bash +git reset --hard HEAD~1 +``` +- 마지막 커밋을 완전히 삭제하고, 변경 사항도 모두 사라짐 +- 복구가 불가능하므로 **사용에 주의해야 함!** + +--- + +## **📌 `reset` 3가지 옵션 비교** + +| 옵션 | HEAD 이동 | Staging Area 영향 | Working Directory 영향 | 되돌린 후 변경 사항 | +|------|-----------|------------------|----------------------|----------------| +| `--soft` | ✅ 이동 | ❌ 유지 | ❌ 유지 | **Staged 상태 유지 (commit만 취소됨)** | +| `--mixed` | ✅ 이동 | ✅ 초기화 | ❌ 유지 | **Unstaged 상태로 이동** | +| `--hard` | ✅ 이동 | ✅ 초기화 | ✅ 초기화 | **모든 변경 사항 삭제 (복구 불가)** | + +--- + +## **🎯 실전 예제: `reset`을 활용한 커밋 취소** +```bash +git reset --soft HEAD~1 # 마지막 커밋 취소 (Staged 상태 유지) +git reset --mixed HEAD~1 # 마지막 커밋 취소 (Unstaged 상태로 이동) +git reset --hard HEAD~1 # 마지막 커밋 및 변경 사항 완전히 삭제 +``` + +--- + +## **🔹 추가 정보: `reset` 사용 시 주의할 점** +1. **`--hard` 옵션은 되돌릴 수 없으므로 신중하게 사용해야 합니다!** + - 실수로 실행했을 경우, `git reflog`를 통해 이전 상태를 확인하고 복구할 수 있음 + +2. **공유된 원격 저장소에서는 `reset` 대신 `revert` 사용을 고려** + - `reset`은 과거 커밋을 변경하기 때문에 협업 시 충돌이 발생할 가능성이 있음 + - `git revert`를 사용하면 **이전 커밋을 되돌리는 새 커밋을 생성**하여 이력을 유지할 수 있음 + +--- + +## **🔹 `git reset`과 `git revert` 차이점** +| 명령어 | 원격 저장소에서 사용 가능? | 기존 커밋 유지 여부 | 사용 목적 | +|--------|--------------------|--------------|------------| +| `git reset` | ❌ (공유된 브랜치에서는 사용 지양) | ❌ (커밋 삭제됨) | 특정 커밋 이후 변경 사항 제거 | +| `git revert` | ✅ (안전하게 사용 가능) | ✅ (이력을 유지하며 취소) | 특정 커밋을 취소하는 새로운 커밋 생성 | + +--- + +### **🚀 결론** +- `git reset --soft` → **최근 커밋을 취소하고, Staging Area 유지** +- `git reset --mixed` → **최근 커밋을 취소하고, 변경 사항을 Unstaged 상태로 이동** +- `git reset --hard` → **모든 변경 사항을 완전히 삭제 (주의!)** + +🔥 **원격 저장소와 협업할 때는 `reset`보다 `revert`를 고려하세요!** +추가 질문이 있다면 알려주세요 😊 + + + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. + +# **Pull Request와 Merge** + +## **1. Pull Request(PR)란?** +- Pull Request(이하 PR)는 **GitHub, GitLab, Bitbucket 등에서 코드 변경 사항을 병합하기 전 리뷰를 요청하는 기능** +- `feature` 브랜치에서 작업한 내용을 `main` 또는 `develop` 브랜치로 합칠 때 사용 +- PR을 통해 팀원들이 변경 사항을 검토하고, 코드 리뷰 후 승인되면 병합(Merge) + +### **🔹 Pull Request 과정** +1. `feature-branch`에서 새로운 기능을 개발 +2. 원격 저장소(Remote Repo)로 `git push` +3. GitHub(GitLab 등)에서 `main` 브랜치로 PR 생성 +4. 팀원들이 코드 리뷰 후 승인 (필요하면 수정) +5. PR을 `Merge`하여 변경 사항을 반영 + +--- + +## **2. Merge란?** +- Git에서 **두 개 이상의 브랜치를 하나로 합치는 과정** +- PR이 승인되면 `merge`를 수행하여 `feature` 브랜치의 변경 사항을 `main` 브랜치에 반영 +- Merge는 방식에 따라 **Fast-Forward Merge**와 **3-Way Merge**로 나뉨 + +--- + +## **3. Merge의 두 가지 타입** + +### **🔹 (1) Fast-Forward Merge** +- 새로운 브랜치에서 작업한 후, `main` 브랜치에 다른 변경 사항이 없는 경우 +- 브랜치의 HEAD가 단순히 앞으로 이동하는 방식 +- 커밋 그래프가 직선 형태로 유지됨 + +### **🛠 Fast-Forward Merge 예제** +```bash +# feature 브랜치 생성 후 작업 +git checkout -b feature-branch +# 작업 후 커밋 +git add . +git commit -m "Add new feature" +# main 브랜치로 체크아웃 +git checkout main +# Fast-Forward Merge 실행 +git merge feature-branch +``` + +### **✅ Fast-Forward Merge의 특징** +- **장점**: 커밋 기록이 깔끔하고 단순 +- **단점**: 브랜치가 독립적으로 존재하지 않으므로, 이력이 명확하지 않을 수 있음 + +--- + +### **🔹 (2) 3-Way Merge** +- `main` 브랜치가 변경된 후, `feature` 브랜치를 Merge하려고 하면 Fast-Forward가 불가능 +- Git이 **공통 조상(Common Ancestor) 커밋을 기준으로 세 개의 커밋을 비교하여 병합** +- 새로운 병합 커밋(Merge Commit)이 생성됨 + +### **🛠 3-Way Merge 예제** +```bash +# main 브랜치에서 변경 사항이 생김 +git checkout main +git pull origin main +# feature 브랜치에서 작업 후 main으로 병합 +git checkout feature-branch +git merge main +# main 브랜치로 돌아가서 병합 수행 +git checkout main +git merge feature-branch +``` + +### **✅ 3-Way Merge의 특징** +- **장점**: Merge 커밋이 남아 있어 변경 이력을 명확하게 확인 가능 +- **단점**: 불필요한 Merge Commit이 많아질 수 있음 + +--- + +## **4. Merge vs. Rebase** +- `git rebase`는 **브랜치를 병합하는 또 다른 방식** +- 기존 커밋을 재배열하여 깔끔한 히스토리를 유지 +- Merge와 비교하면 `git rebase`는 **브랜치 커밋을 새롭게 쌓는 방식**, Merge는 **Merge Commit을 생성** + +### **🛠 Rebase 예제** +```bash +git checkout feature-branch +git rebase main +``` + +### **✅ Merge vs. Rebase 비교** +| 방식 | 히스토리 유지 | 새로운 Merge Commit 생성 | 협업 추천 여부 | +|------|------------|-----------------|------------| +| `merge` | O | O (3-Way Merge) / X (Fast-Forward) | O | +| `rebase` | X (커밋이 새롭게 정렬됨) | X | X (협업 시 주의 필요) | + +--- + +## **🎯 결론** +1. **PR(Pull Request)**는 협업에서 변경 사항을 병합하기 전에 코드 리뷰를 거치는 과정 +2. **Merge**는 브랜치를 하나로 합치는 과정이며, **Fast-Forward Merge**와 **3-Way Merge**가 있음 +3. **Fast-Forward Merge**는 브랜치 HEAD가 단순 이동하는 방식으로 **히스토리가 깔끔** +4. **3-Way Merge**는 공통 조상을 기준으로 **Merge Commit이 생성**되며, **히스토리 보존** +5. **Rebase**는 커밋을 다시 정렬하여 히스토리를 깔끔하게 하지만 협업 시 주의 필요 + +🔹 **협업 시에는 PR을 활용하여 코드 리뷰 후 Merge하는 것이 베스트!** +추가 질문이 있다면 알려주세요 😊 + + + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +# **Rebase란?** + +## **1. Rebase란 무엇인가?** +`git rebase`는 브랜치의 기반(Base) 커밋을 변경하여 **커밋 히스토리를 다시 정렬하는 Git 명령어**입니다. +즉, 특정 브랜치에서의 변경 사항을 다른 브랜치의 최신 커밋 위에 다시 적용하는 방식입니다. + +**💡 간단히 말하면?** +👉 **"현재 브랜치가 마치 최신 브랜치에서 시작된 것처럼 보이게 만든다!"** + +--- + +## **2. Rebase의 동작 방식** + +### **🔹 Rebase 전 (기존 구조)** +```bash +A---B---C (main) + \ + D---E---F (feature) +``` +- `feature` 브랜치는 `main`에서 분기되어 독립적으로 진행됨 + +### **🔹 Rebase 후 (main 브랜치 기준으로 재배치)** +```bash +A---B---C (main) + \ + D'--E'--F' (feature) +``` +- `feature` 브랜치의 모든 커밋(D, E, F)이 `main`의 최신 커밋(C) 위로 다시 적용됨 +- 즉, **D, E, F 커밋이 새롭게 만들어진 것처럼 보이게 됨** + +--- + +## **3. Rebase 사용 방법** + +### **(1) 기본적인 Rebase 명령어** +```bash +git checkout feature +git rebase main +``` +- `feature` 브랜치를 `main` 브랜치의 최신 상태로 재배열 +- `feature` 브랜치에서의 변경 사항이 `main`의 최신 커밋 뒤에 다시 적용됨 + +### **(2) Rebase 충돌 해결 방법** +- Rebase 도중 충돌이 발생하면 Git이 경고 메시지를 표시하고 Rebase가 중단됨 +- 충돌을 해결한 후 다음 명령어를 실행하면 Rebase가 계속 진행됨 +```bash +git add . +git rebase --continue +``` +- 만약 Rebase를 취소하고 싶다면? +```bash +git rebase --abort +``` + +--- + +## **4. Rebase가 유용한 경우** + +### ✅ **1) 히스토리를 깔끔하게 유지하고 싶을 때** +- `git merge`를 사용하면 **Merge Commit**이 남게 되어 불필요한 커밋이 많아질 수 있음 +- `git rebase`는 **브랜치를 직선 형태로 정리**하여 **히스토리를 단순하고 깔끔하게 유지** + +### ✅ **2) 여러 개발자가 협업하는 프로젝트에서 최신 변경 사항을 반영하고 싶을 때** +- `main` 브랜치에서 새로운 변경 사항이 생겼다면, `feature` 브랜치를 최신 상태로 업데이트 +- `git pull --rebase`를 사용하면, 최신 변경 사항을 적용하면서 불필요한 Merge Commit 없이 유지 가능 + +```bash +git pull --rebase origin main +``` + +### ✅ **3) Feature 브랜치를 최신 상태로 유지하고 싶을 때** +- 여러 명이 공동 작업하는 경우, `git merge main`을 수행하면 불필요한 Merge Commit이 생성됨 +- `git rebase main`을 하면 `main` 브랜치의 최신 변경 사항을 반영하면서도 **커밋 히스토리를 깨끗하게 유지** + +--- + +## **5. Merge vs. Rebase 차이점** + +| 비교 항목 | Merge | Rebase | +|-----------|---------|---------| +| **커밋 히스토리** | Merge Commit이 생성됨 | 직선형 히스토리를 유지 | +| **사용 목적** | 협업 시 변경 사항을 명확히 남길 때 | 히스토리를 깔끔하게 정리할 때 | +| **충돌 처리** | Merge 시점에 한 번에 처리 | 각 커밋마다 개별적으로 충돌 해결 필요 | +| **커밋 순서 유지** | 유지됨 | 변경될 수 있음 | + +--- + +## **6. Rebase 사용 시 주의할 점** + +⚠ **🚨 이미 Push한 커밋을 Rebase하지 말 것! 🚨** +- **Rebase는 커밋을 새롭게 생성하는 것과 동일**하므로, 이미 원격 저장소(Remote Repository)에 Push한 후에 Rebase하면 문제가 발생할 수 있음 +- 다른 사람이 같은 브랜치를 사용 중이라면 **충돌 위험**이 있음 +- **해결 방법:** `git push --force`를 사용할 수 있지만, 이는 협업 프로젝트에서는 권장되지 않음 + +```bash +git push --force # 강제로 Push (주의!) +``` + +### **🔹 안전한 Rebase 사용 방법** +- `git rebase`는 **로컬에서 작업 중인 브랜치**에서만 사용 +- 이미 원격에 Push한 경우에는 `merge`를 사용하는 것이 더 안전함 + +--- + +## **🎯 결론: 언제 Rebase를 사용할까?** + +✅ **Rebase를 사용하면 좋은 경우** +- 커밋 히스토리를 깨끗하게 정리하고 싶을 때 +- 개인 작업을 정리하여 `main`에 반영하기 전에 깔끔한 히스토리 유지 +- `main` 브랜치의 최신 상태를 `feature` 브랜치에 반영할 때 + +❌ **Rebase를 피해야 하는 경우** +- 원격 저장소에 Push한 후 다른 사람이 같은 브랜치를 사용할 가능성이 있을 때 +- 협업 중인 브랜치에서 Rebase 후 `--force push`를 해야 하는 상황 + +--- + +## **📌 요약** +1. `git rebase`는 브랜치의 기반(Base) 커밋을 변경하여 **커밋 히스토리를 깔끔하게 유지**하는 Git 명령어 +2. `git merge`와 달리 **불필요한 Merge Commit 없이 직선형 히스토리를 유지** +3. `git pull --rebase`를 사용하면 최신 변경 사항을 반영하면서도 히스토리를 깨끗하게 유지 가능 +4. 하지만, **이미 Push된 커밋을 Rebase하면 충돌 위험이 커지므로 주의해야 함** +5. 협업 중이라면 `merge`를, 개인 브랜치 정리에는 `rebase`를 추천! + +💡 **협업 시에는 Merge, 개인 브랜치 정리에는 Rebase를 활용하면 최적의 Git 관리 가능!** 🚀 + + + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +# **Git Stash 활용 방법** + +## **1. Git Stash란?** +`git stash`는 **현재 작업 중인 변경 사항을 임시로 저장**하고, 작업 디렉터리를 깨끗한 상태로 만들 수 있는 Git 명령어입니다. +즉, **작업을 중단하고 다른 브랜치로 전환해야 할 때 유용하게 사용**됩니다. + +💡 **한마디로?** +👉 **"현재 작업 내용을 임시 저장해 두고, 나중에 다시 복구하는 기능!"** + +--- + +## **2. Git Stash 기본 사용법** + +### **🔹 Stash 저장하기** +```bash +git stash +``` +- **현재 변경된 파일과 Staging Area의 변경 사항을 모두 저장** +- 저장 후에는 `git status`를 확인하면, **작업 디렉터리가 깨끗한 상태**가 됨 + +💡 **Stash 저장과 동시에 메시지 추가하기** +```bash +git stash save "임시 저장 메시지" +``` +- 여러 개의 Stash를 저장할 경우 구분하기 쉽게 메시지를 추가할 수 있음 + +--- + +## **3. Stash 목록 확인 및 복원** + +### **🔹 Stash 목록 확인** +```bash +git stash list +``` +- 현재 저장된 Stash 목록을 확인 가능 +- 예제 출력: + ``` + stash@{0}: WIP on feature-branch: 123abc 작업 내용1 + stash@{1}: WIP on main: 456def 작업 내용2 + ``` +- `stash@{0}`이 가장 최근에 저장된 Stash + +### **🔹 Stash 적용 (복원하기)** +```bash +git stash apply +``` +- 가장 최근에 저장된 Stash를 적용하지만, **Stash는 삭제되지 않음** +- 만약 특정 Stash를 적용하려면? + ```bash + git stash apply stash@{1} + ``` + +### **🔹 Stash 적용 후 삭제까지 하기 (pop)** +```bash +git stash pop +``` +- Stash를 적용한 후, **적용된 Stash는 자동으로 삭제됨** + +--- + +## **4. 특정 Stash 삭제 및 전체 삭제** + +### **🔹 특정 Stash 삭제** +```bash +git stash drop stash@{0} +``` +- `stash@{0}` Stash만 삭제 + +### **🔹 모든 Stash 삭제** +```bash +git stash clear +``` +- **모든 Stash를 한 번에 삭제** + +--- + +## **5. Stash에 특정 파일만 저장하기** + +### **🔹 Untracked 파일 제외하고 Stash 저장** +```bash +git stash -u +``` +- **Tracked 파일만 저장 (Untracked 파일은 제외)** + +### **🔹 Untracked & Ignored 파일까지 Stash 저장** +```bash +git stash -a +``` +- **모든 파일(Untracked, Ignored 포함)을 Stash에 저장** + +--- + +## **6. Stash를 활용하는 실전 시나리오** + +### ✅ **1) 작업 도중 급하게 다른 브랜치로 이동해야 할 때** +```bash +git stash +git checkout main +git pull origin main +git checkout feature-branch +git stash pop +``` +- 변경 사항을 임시로 저장 후, `main` 브랜치 업데이트 후 다시 원래 브랜치에서 작업 재개 + +### ✅ **2) 여러 개의 Stash를 관리하며 특정 시점의 변경 사항 적용** +```bash +git stash list +git stash apply stash@{2} +``` +- 특정 Stash(`stash@{2}`)만 적용 가능 + +### ✅ **3) 특정 파일만 Stash에서 복구하고 싶을 때** +```bash +git checkout stash@{0} -- file.txt +``` +- `stash@{0}`에서 `file.txt`만 복구 + +--- + +## **7. Git Stash vs. Git Commit 비교** + +| 기능 | Git Stash | Git Commit | +|------|----------|------------| +| 목적 | 임시 저장 | 영구 저장 | +| 적용 대상 | 현재 작업 디렉터리 변경 사항 | 모든 변경 사항 | +| 히스토리 유지 | 유지되지 않음 (stash list에서만 조회 가능) | 유지됨 (Git Log에서 조회 가능) | +| 브랜치 전환 가능 여부 | 가능 | 불가능 (Commit 후에만 가능) | +| 삭제 가능 여부 | 가능 (`git stash drop`, `git stash clear`) | 가능 (`git reset`, `git revert`) | + +💡 **Stash는 임시 저장 용도로만 사용하고, 장기적인 변경 사항은 Commit을 활용하는 것이 좋음!** + +--- + +## **🎯 결론: 언제 Git Stash를 사용할까?** + +✅ **Git Stash를 사용하면 좋은 경우** +- **작업 중인데 급하게 브랜치를 변경해야 할 때** +- **Commit하기 애매한 작업 내용을 임시로 저장하고 싶을 때** +- **다른 작업을 먼저 해야 할 때 현재 진행 중인 변경 사항을 임시로 보관** +- **Untracked 파일까지 포함해 임시 저장하고 싶을 때 (`git stash -u` or `git stash -a`)** + +❌ **Git Stash를 피해야 하는 경우** +- 장기적으로 변경 사항을 저장하려면 **Commit을 사용하는 것이 더 적절함** +- 협업 중이라면 Stash보다는 **Branch를 활용하여 명확한 기록을 남기는 것이 좋음** + +--- + +## **📌 요약** +1. `git stash`는 **작업 중인 변경 사항을 임시로 저장하고, 나중에 다시 불러올 수 있는 Git 명령어** +2. `git stash list`로 Stash 목록을 확인하고, `git stash apply` 또는 `git stash pop`으로 복원 가능 +3. `git stash drop stash@{n}`으로 특정 Stash 삭제, `git stash clear`로 모든 Stash 삭제 가능 +4. `git stash -u`는 Untracked 파일 포함, `git stash -a`는 Ignored 파일까지 포함 가능 +5. Stash는 **임시 저장 용도로만 사용**하고, 변경 사항을 확정할 때는 Commit을 활용하는 것이 좋음 + +🚀 **Git Stash를 적절히 활용하면, 작업 흐름을 유지하면서도 유연하게 브랜치를 전환할 수 있음!** + + + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +좋은 주제들이네요! 각각의 개념을 깊이 있게 이해하면 Git을 보다 효과적으로 활용할 수 있습니다. 간략한 설명과 함께 더 깊이 조사할 수 있는 방향을 제시해볼게요. + +--- + +### **1. 브랜치 관리 전략: Github Flow vs. Git Flow** +- **Github Flow** + - `main` 브랜치에서 직접 feature 브랜치를 만들고 작업 후 PR을 통해 머지하는 방식 + - 단순한 워크플로우, CI/CD와의 연계가 쉬움 + - 작은 프로젝트, 빠른 배포가 필요한 경우 적합 + +- **Git Flow** + - `develop`, `feature`, `release`, `hotfix` 등의 여러 브랜치를 활용하는 방식 + - 배포 주기가 긴 프로젝트나 팀 단위 협업에서 적합 + - 브랜치 간 머지 전략이 중요 + +📌 **조사 포인트:** +- Github Flow에서는 `main` 브랜치에서 직접 배포하는데, Git Flow에서는 왜 `develop` 브랜치가 필요한가? +- 두 방식이 충돌하는 경우 어떻게 해결할까? + +--- + +### **2. `git rebase --interactive`란?** +- `git rebase -i HEAD~n`을 사용하면 최근 `n`개의 커밋을 수정, 병합, 삭제할 수 있음 +- `pick`, `squash`, `reword`, `edit`, `drop` 등의 옵션을 활용 가능 + +📌 **조사 포인트:** +- `squash`와 `fixup`의 차이 +- `edit`을 활용해 특정 커밋만 수정하는 방법 + +--- + +### **3. 브랜치의 upstream이란? (`git push --set-upstream`)** +- `git push --set-upstream origin feature-branch`를 실행하면 로컬 브랜치와 원격 브랜치를 연결 +- 이후 `git push`나 `git pull`을 별도의 옵션 없이 사용 가능 + +📌 **조사 포인트:** +- `upstream`을 변경하려면? (`git branch --unset-upstream` 활용) +- `git pull --rebase`와 함께 사용하면 어떤 이점이 있을까? + +--- + +### **4. Fork는 언제 유용한가?** +- `PR`은 같은 리포지토리의 브랜치뿐만 아니라 **Fork한 리포지토리**에서도 가능 +- **Fork가 유용한 경우:** + - 원본 프로젝트를 유지하면서 개인적으로 기능을 추가하고 싶을 때 + - 오픈소스 프로젝트에 기여할 때 + +📌 **조사 포인트:** +- Fork 후 원본 리포지토리(`upstream`)의 변경 사항을 동기화하는 방법 (`git remote add upstream`) +- PR을 보낼 때 내 브랜치와 원본 브랜치의 충돌을 해결하는 방법 + +--- + +### **5. `git fetch`와 `git pull`의 차이점** +- `git fetch`: 원격 저장소의 변경 사항을 가져오지만 **로컬 브랜치에는 반영하지 않음** +- `git pull`: `fetch + merge` (로컬 브랜치에 직접 반영됨) + +📌 **조사 포인트:** +- `git fetch --prune` 옵션을 활용하면 어떤 장점이 있을까? +- `git fetch`를 사용한 후 `git diff origin/main`으로 변경 사항을 확인하는 방법 + +--- + +### **6. `reset --hard`와 `push --force`의 적절한 사용법** +- `git reset --hard HEAD~1`: 가장 최근의 커밋을 삭제하고 변경 사항도 함께 제거 +- `git push --force`: 원격 저장소의 히스토리를 강제로 덮어씀 + +📌 **조사 포인트:** +- `--force-with-lease` 옵션은 어떻게 동작하는가? +- 협업 중에 `push --force`를 사용할 경우 생길 수 있는 문제 + +--- + +### **7. `.gitignore` 사용법** +- 특정 파일을 Git에 추가하지 않도록 설정하는 파일 +- 패턴 예제: + ``` + *.log # 모든 .log 파일 무시 + /node_modules/ # 특정 폴더 무시 + !important.log # 예외적으로 추가할 파일 지정 + ``` + +📌 **조사 포인트:** +- `.gitignore`을 프로젝트 초반에 설정하지 않고 후에 적용하면 어떻게 될까? +- `.gitignore`을 잘못 설정해서 커밋된 파일을 제거하려면? (`git rm --cached`) + +--- + +### **8. 브랜치 이름의 계층적 구조** +- 브랜치 이름에 `/`를 포함하면 계층 구조처럼 보이지만, 실제 Git은 폴더 개념이 아님 +- `parent/child/grandchild`와 `parent/child`를 동시에 가질 수 없는 이유: + - `parent/child`가 하나의 브랜치라면 `parent/child/grandchild`는 독립적인 브랜치로 인식되지 않음 + +📌 **조사 포인트:** +- Git의 브랜치 네이밍 규칙과 `refs/heads/` 내부 구조 +- Git에서 브랜치 삭제 시 주의할 점 + +--- + +### **9. Detached HEAD란?** +- 특정 커밋을 체크아웃하면 HEAD가 브랜치가 아닌 특정 커밋을 가리키는 상태 +- Detached HEAD 상태에서 커밋을 하면 임시 브랜치가 생기지만, 브랜치를 생성하지 않으면 커밋이 사라짐 + +📌 **조사 포인트:** +- Detached HEAD에서 만든 커밋을 유지하는 방법 (`git checkout -b new-branch`) +- `git switch -`를 활용한 빠른 브랜치 이동 + +--- + +이 주제들에 대해 직접 실습해보거나 공식 문서를 찾아보면서 학습하면 Git을 훨씬 더 깊이 이해할 수 있을 거예요! 🚀 + + + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git "a/git-basics/23rd/README-\353\260\225\354\236\254\355\231\215.md" "b/git-basics/23rd/README-\353\260\225\354\236\254\355\231\215.md" new file mode 100644 index 0000000..ee2bfc4 --- /dev/null +++ "b/git-basics/23rd/README-\353\260\225\354\236\254\355\231\215.md" @@ -0,0 +1,107 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +깃과 깃허브의 가장 큰 차이점은 깃이 소프트웨어이며, 깃허브가 서비스라는 점입니다. 깃은 개발자의 로컬(local) 컴퓨터에서 동작하며, 소스 코드의 버전 관리를 담당합니다. 반면, 깃허브는 깃 리포지토리를 호스팅하는 웹 서비스(remote)로, 프로젝트 협업을 위한 다양한 도구를 제공합니다. +-> GitHub는 Git 저장소를 호스팅하는 원격(remote) 저장소 서비스이다. + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +- Working Directory : 사용자가 작업하는 로컬 파일들이 위치한 영역으로 업로드 전의 작업한 파일입니다. +- Git Add : Working Directory에서 변경된 파일을 Staging Area로 추가하여 커밋 대상으로 만듭니다. +- Git Commit : Staging Area의 변경 사항을 코멘트와 함께 로컬 저장소(Local Repository)에 기록합니다. +- Git Push : 로컬 저장소에서 원격 저장소(GitHub)로 변경 사항을 업로드합니다. +- Git Fetch : 원격 저장소의 최신 변경 사항을 로컬로 가져오지만, 자동으로 병합하지는 않습니다. +- Git Merge : 다른 브랜치의 변경 사항을 현재 브랜치에 합칩니다.(수정사항을 적용하거나 기능을 업데이트 하는 과정) +- Git Pull : 원격 저장소의 변경 사항을 가져와 로컬 저장소와 자동으로 병합(Merge)합니다. + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +- Commit: 변경 사항을 기록하는 Git의 기본 단위로 각 commit은 고유한 해시값을 가집니다. +- Branch: 독립적으로 개발을 진행할 수 있는 작업 공간으로, 여러 브랜치를 만들어 병렬 작업이 가능합니다. 보통 기본 작업 파일을 살려두고 나머지 기능이나 수정사항을 점검한 후 적용하기 위해 사용합니다. +- HEAD: 현재 체크아웃(작업 중)된 브랜치를 가리키는 포인터로, HEAD가 가리키는 브랜치가 변경됩니다. (HEAD = 현재 작업중인 branch) +- git checkout [브랜치명]: 특정 브랜치로 이동하거나, 특정 커밋을 체크아웃할 때 사용합니다. +- git switch -c [새로운 브랜치명]: 새 브랜치를 생성하고 해당 브랜치로 이동합니다. +- git branch [새로운 브랜치명]: 새로운 브랜치를 생성하지만, 현재 브랜치를 변경하지 않습니다. +- git branch -d [브랜치명]: 로컬 브랜치를 삭제합니다. +- git push origin --delete [브랜치명]: 원격 브랜치를 삭제합니다. + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +- git init : 로컬 저장소에 새로운 Git repository를 생성합니다. Git Hub에는 따로 연동해줘야합니다. +- git clone : 원격 저장소에 있는 기존의 repository를 복제하여 로컬로 가져옵니다. 원격 저장소와 자동으로 연동됩니다. + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +- git reset --soft [커밋ID] : 지정한 커밋으로 HEAD만 이동하고, 변경 사항은 Staging Area(=index)에 유지됩니다. 최근 커밋을 수정할때 유용합니다. +- git reset --mixed [커밋ID] : 지정한 커밋으로 HEAD와 Staging Area를 이동하지만, Working Directory는 그대로 유지됩니다. 커밋은 취소되지만 파일 변경 사항은 남아있어 다시 커밋할 수 있습니다. +- git reset --hard [커밋ID] : 지정한 커밋으로 HEAD, Staging Area, Working Directory를 모두 이동시켜 변경 사항을 완전히 삭제합니다. + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. + +- Pull Request : GitHub, GitLab 등에서 사용하는 기능으로, 브랜치 병합을 요청하는 과정입니다. 협업을 하며 수정사항을 병합할지 검토한 후 진행할 수 있습니다. +- Merge : 한 브랜치의 변경 사항을 다른 브랜치에 적용하는 과정입니다. git merge [브랜치명] 명령어로 수행됩니다. +1) Fast-Forward Merge : 대상 브랜치가 병합하려는 브랜치의 최신 커밋을 그대로 따라갈 수 있을 때 발생합니다. 별도의 병합 커밋 없이 브랜치의 HEAD가 이동합니다. +2) 3-Way Merge : 두 브랜치가 서로 다른 변경 사항을 가질 때 발생하며, 공통 조상(ancestor)을 기준으로 병합합니다. 새로운 병합 커밋이 생성됩니다. + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +- rebase : 브랜치의 변경 사항을 다른 브랜치의 최신 상태 위로 이동시키는 명령어입니다. git merge와 달리 병합 커밋 없이 깔끔한 커밋 히스토리를 유지할 수 있습니다. + +<활용방법> +1) 협업 중 최신 코드 반영 +2) 불필요한 Merge Commit 방지 : 병합 커밋 없이 정리된 커밋 히스토리를 유지할 수 있습니다. +3) 커밋 순서 정리 및 수정 : git rebase -i HEAD~n을 사용하면 특정 개수의 커밋을 수정, 삭제, 합치기 할 수 있습니다. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +- git stash : 작업 중인 변경 사항을 임시로 저장하고, 작업 디렉토리를 깨끗한 상태로 되돌리는 기능입니다. + +<활용방법> +1) 커밋하지 않고도 다른 브랜치로 이동하거나, 코드를 테스트할 때 유용합니다. +2) 변경 사항 임시 저장 : Staging Area와 Working Directory의 변경 사항이 stash로 이동하고, 작업 디렉토리는 깨끗한 상태가 됩니다. +3) 임시 저장한 변경 사항 적용 : 가장 최근에 저장한 변경 사항을 다시 적용하고, stash 목록에서 제거합니다. +4) 저장된 목록 확인 : 여러 개의 stash를 저장할 수 있으며, 목록을 확인할 수 있습니다. +5) 특정 stash 적용 : stash@{n}에 해당하는 특정 stash를 적용하지만 목록에서 제거하지 않습니다. +6) 특정 stash 삭제 +7) 모든 stash 삭제 + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git "a/git-basics/23rd/README-\354\235\264\354\262\234\354\204\234.md" "b/git-basics/23rd/README-\354\235\264\354\262\234\354\204\234.md" new file mode 100644 index 0000000..a9a023a --- /dev/null +++ "b/git-basics/23rd/README-\354\235\264\354\262\234\354\204\234.md" @@ -0,0 +1,103 @@ +# Git 기초 + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +- Git: 분산 버전관리 도구, Local에서도 전 기능 동작. +- GitHub: Git 저장소를 호스팅하고 PR·리뷰·권한·CI 등을 제공하는 Remote 서비스 중 하나. + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +- Working Directory: 실제 파일이 있는 작업 폴더. 수정·생성·삭제 발생. +- Git Add: 작업 파일을 Staging Area에 올림. +- Git Commit: Staging Area의 스냅샷을 로컬 저장소에 새 커밋으로 기록. +- Git Push: 로컬 브랜치의 새 커밋을 원격 저장소로 전송. + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +- commit: 시점 스냅샷 + 부모 참조 + 메시지. 불변. +- branch: 어느 커밋을 가리키는 이동 포인터. 새 커밋이 생기면 브랜치 참조가 앞으로 이동. +- HEAD: 현재 체크아웃한 브랜치를 가리키는 특수 포인터. + +주요 명령 +- git branch: 목록 +- git branch : 생성 +- git switch : 이동 +- git switch -c : 생성+이동 +- git branch -d : 병합된 브랜치 삭제 +- git branch -D : 강제 삭제 + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +- git clone : 원격 저장소를 통째로 복제하여 새 폴더를 만들고, 기본 원격 별칭을 origin 으로 자동 등록. +- git init: 현재 폴더에 빈 Git 저장소 생성. 기존 코드에서 버전관리 시작할 때 사용. +- origin: 가장 일반적으로 쓰는 원격 저장소 별칭. 변경 가능. + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +- --soft: 브랜치 포인터만 되돌림. 스테이징은 유지, 워킹 디렉터리도 유지. +- --mixed: 브랜치 포인터 이동 + 인덱스 초기화. 워킹 디렉터리의 파일 변경은 남음. +- --hard: 브랜치 포인터 이동 + 인덱스/워킹 디렉터리 모두 되돌림. 로컬 변경 완전 폐기. + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. + +- PR: 한 브랜치의 변경을 다른 저장소/브랜치로 병합해달라고 요청. 코드리뷰, CI, 승인 규칙 등을 통과한 뒤 Merge 수행. + +Merge 유형 +- Fast-Forward: 대상 브랜치가 소스 브랜치의 조상일 때 참조만 앞으로 이동. +- 3-Way Merge: 히스토리가 분기되어 공통 조상이 존재하면 새 머지 커밋을 만들며 통합. + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +- rebase: 브랜치의 기반을 다른 커밋으로 바꾸면서, 내 커밋들을 다시 적용해 직선 히스토리를 만드는 작업. + +- 리뷰 전 커밋 정리 +- 오래된 분기를 최신 기반으로 업데이트하여 FF 머지 가능하게 만들 때 +- 히스토리를 깔끔하게 + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +- git stash : 현재 작업 변경(스테이지드/언스테이지드)을 임시로 치워 브랜치를 바꾸거나 풀/리베이스 등을 안전하게 수행. + +- 부분 적용 +- 인덱스 유지 테스트 +- 새 브랜치로 바로 빼기 +- 특정 경로만 스태시 + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git "a/git-basics/23rd/README-\354\240\225\354\234\240\354\247\204.md" "b/git-basics/23rd/README-\354\240\225\354\234\240\354\247\204.md" new file mode 100644 index 0000000..d0bd6b1 --- /dev/null +++ "b/git-basics/23rd/README-\354\240\225\354\234\240\354\247\204.md" @@ -0,0 +1,91 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +git은 "local 파일"의 변경 사항을 추적하고 관리하는 분산 버전 제어 시스템이고, +github는 "remote 저장소"에서 git을 기반으로 프로젝트를 인터넷에서 관리할 수 있는 온라인 플랫폼이다. + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +- Working Directory : 사용자가 작업하는 로컬 파일들이 위치한 디렉토리이다. +- Git Add : Working Directory에서 변경된 파일들을 Staging 상태(커밋 준비 상태)로 올린다. +- Git Commit : Staging 상태 파일들의 변경 사항을 로컬 저장소에 새 버전으로 기록한다. +- Git Push : 로컬 저장소에서 원격 저장소(GitHub)로 변경 사항을 업로드한다. +- Git Pull : 원격 저장소의 변경 사항을 가져와, 로컬 저장소의 작업과 합친다. + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +- Commit: 변경 사항을 기록해놓은 것으로, 각 commit은 고유한 해시값인 커밋 번호를 가진다. +- Branch: 독립적인 개발 라인으로, 기능 개발/버그 수정을 다른 작업과 분리하여 안전하게 진행하게 한다. +- HEAD: 특정 branch의 가장 최신(마지막으로 수행된) commit +- git checkout [브랜치명]: 특정 브랜치/커밋으로 전환 +- git switch -c [새로운 브랜치명]: 새 브랜치를 생성 후 해당 브랜치로 이동 +- git branch [새로운 브랜치명]: 새로운 브랜치를 생성하지만 그 브랜치로 전환하지는 않는다. +- git branch -d [브랜치명]: 로컬 브랜치 삭제 +- git push origin --delete [브랜치명]: 원격 저장소의 브랜치 삭제 + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +- git init : 현재 디렉토리를 Git 로컬 저장소로 만든다. +- git clone : 원격 저장소의 정보들을 내 로컬시스템으로 복제해온다. + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +- git reset --soft [커밋ID] : 지정한 커밋으로 HEAD만 이동하고, 변경 사항은 Staging Area(=index)에 유지됩니다. 최근 커밋을 수정할때 유용합니다. +- git reset --mixed [커밋ID] : 지정한 커밋으로 HEAD와 Staging Area를 이동하지만, Working Directory는 그대로 유지됩니다. 커밋은 취소되지만 파일 변경 사항은 남아있어 다시 커밋할 수 있습니다. +- git reset --hard [커밋ID] : 지정한 커밋으로 HEAD, Staging Area, Working Directory를 모두 이동시켜 변경 사항을 완전히 삭제합니다. + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. + +- Pull Request : 특정 branch의 코드 변경 사항을 원본 저장소의 다른 branch에 병합을 요청하는 과정이다. +- Merge : 2개 이상의 branch를 하나로 통합하는 과정이다. git merge [브랜치명] 명령어로 수행된다. +1) Fast-Forward Merge : 병합되는 branch에는 신규 commit이 없을 때, 별도의 병합 커밋 없이 브랜치의 HEAD만 이동해 병합한다. +2) 3-Way Merge : 각 branch에 신규 commit이 있을 경우, 새로운 병합 커밋이 생성되면서 병합한다. + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +- rebase : merge와 결과는 비슷하지만, merge와 달리 커밋 히스토리에 여러 갈래 branch를 남게 하지 않고 한 줄로 정리하는 기능이다. 커밋 히스토리를 깔끔하게 관리하고 싶을 때 유용하다. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +- git stash : 작업중인 파일의 변경 내용을 일시적으로 기록해두는 명령이다. 작업 중 갑작스럽게 다른 작업을 진행해야 할 때, 임시로 이를 저장하고 해당 작업이 끝난 후 저장한 작업을 진행하는 방식으로 활용할 수 있다. + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git "a/git-basics/23rd/README-\354\265\234\354\234\240\353\240\254.md" "b/git-basics/23rd/README-\354\265\234\354\234\240\353\240\254.md" new file mode 100644 index 0000000..cf1442f --- /dev/null +++ "b/git-basics/23rd/README-\354\265\234\354\234\240\353\240\254.md" @@ -0,0 +1,162 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + + +git은 분산 버전 관리 시스템이고, github는 원격 레포지토리 호스팅 서비스이다. 개발자가 local repo에서 작업한 이력을 git을 통해 관리할 수 있으며, 관리한 내역을 remote repo(github 등)로 업로드해 공유할 수 있다. 다른 개발자들은 업로드된 remote repo를 복제해 local repo에서 작업할 수 있다. + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + +- Working Directory : git이 파일을 추적하는 작업 공간 +- Staging Area : 커밋할 변경 사항들을 모아두는 임시 공간 +- Local Repo : 내 컴퓨터에 있는 버전 이력 저장소 +- Remote Repo : 원격 서버에서 공유되는 공용 버전 이력 저장소 (예: github) + +- `git add` : 커밋할 변경사항을 Staging Area로 추가 +- `git commit` : 선택한 변경사항을 Local Repo에 기록 +- `git push` : Local Repo에 기록된 변경이력을 Remote Repo로 업로드 +- `git pull` : Remote Repo의 변경이력을 가져와 내 Working Directory에 병합 시도 + + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +- Commit: 변경 사항을 기록하는 Git의 기본 단위로 각 commit은 고유한 해시값을 가집니다. +- Branch: 독립적으로 개발을 진행할 수 있는 작업 공간으로, 여러 브랜치를 만들어 병렬 작업이 가능합니다. 보통 기본 작업 파일을 살려두고 나머지 기능이나 수정사항을 점검한 후 적용하기 위해 사용합니다. +- HEAD: 현재 체크아웃(작업 중)된 브랜치를 가리키는 포인터로, HEAD가 가리키는 브랜치가 변경됩니다. (HEAD = 현재 작업중인 branch) +- git checkout [브랜치명]: 특정 브랜치로 이동하거나, 특정 커밋을 체크아웃할 때 사용합니다. + - git checkout -b [새로운 브랜치명] : 새 브랜치를 생성하고 해당 브랜치로 이동 +- git switch [브랜치명] : 특정 브랜치로 이동합니다. + - git switch -c [새로운 브랜치명]: 새 브랜치를 생성하고 해당 브랜치로 이동합니다. +- git branch [새로운 브랜치명]: 새로운 브랜치를 생성하지만, 현재 브랜치를 변경하지 않습니다. +- git branch -d [브랜치명]: 로컬 브랜치를 삭제합니다. +- git push origin --delete [브랜치명]: 원격 브랜치를 삭제합니다. + +### 사용 예시 +```bash +git switch -c new_branch # new_branch를 만들고 해당 브랜치로 이동 +# 변경사항을 만들었다고 가정 +git add . +git commit -m "new branch commit" +git switch main +git merge new_branch # main 브랜치에 merge +git branch -d new_branch # 필요 없으면 삭제 +``` + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +- git init : 로컬 저장소에 새로운 Git repository를 생성합니다. GitHub와는 따로 연동해줘야합니다. +- git clone : 원격 저장소에 있는 기존의 repository를 복제하여 로컬로 가져옵니다. 원격 저장소와 자동으로 연동됩니다. +- origin : git clone시 자동으로 생성되는 remote 저장소의 별칭(alias) + - 만약 따로 연동해줘야 할 경우.. + - `git remote add origin '저장소 주소'` + - `git push -u origin main` + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +- `git reset --soft [커밋ID]` : 지정한 커밋으로 HEAD만 이동하고, 변경 사항은 Staging Area(=index)에 유지됩니다. + - 최근 커밋을 수정할 때 유용 +- `git reset --mixed [커밋ID]` : 지정한 커밋으로 HEAD와 Staging Area를 이동하지만, Working Directory는 그대로 유지됩니다. 커밋은 취소되지만 파일 변경 사항은 남아있어 다시 커밋할 수 있습니다. + - git reset의 기본값 +- `git reset --hard [커밋ID]` : 지정한 커밋으로 HEAD, Staging Area, Working Directory를 모두 이동시켜 변경 사항을 완전히 삭제합니다. + - 실행하면 되돌리기 어려움 + +- 공유된 브랜치에 대해 reset을 사용하면 커밋이 꼬일 수 있으므로 주의해야 함 + - 대안: git revert 명령어 사용 (되돌린 것에 대한 커밋이 생성됨) + + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. + +- Pull Request : GitHub, GitLab 등에서 사용하는 기능으로, 브랜치 병합을 요청하는 과정입니다. 협업을 하며 수정사항을 병합할지 검토한 후 진행할 수 있습니다. + - Fork: repo에 대한 읽기 권한이 없을 경우, repo를 복제해 수정한 다음 pull request + - Branch 생성 : 새 branch에서 변경사항을 커밋하고, merge 요청 +- Merge : 한 브랜치의 변경 사항을 다른 브랜치에 적용하는 과정입니다. `git merge [브랜치명]` 명령어로 수행됩니다. + + + +1) Fast-Forward Merge : 대상 브랜치가 병합하려는 브랜치의 최신 커밋을 그대로 따라갈 수 있을 때 발생합니다. 별도의 병합 커밋 없이 브랜치의 HEAD가 이동합니다. + - 브랜치가 선형으로 병합 +2) 3-Way Merge : 두 브랜치가 서로 다른 변경 사항을 가질 때 발생하며, 공통 조상(ancestor)을 기준으로 병합합니다. 새로운 병합 커밋이 생성됩니다. + - 브랜치가 다이아몬드 모양으로 병합 + +### main 브랜치에서 sub 브랜치를 병합 +```bash +git switch main # 메인 브랜치로 이동 +git merge sub # sub 브랜치를 병합 +``` + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +- rebase : 브랜치의 변경 사항을 다른 브랜치의 최신 상태 위로 이동시키는 명령어입니다. git merge와 달리 병합 커밋 없이 깔끔한 커밋 히스토리를 유지할 수 있습니다. + +<활용방법> +1) 협업 중 최신 코드 반영 +2) 불필요한 Merge Commit 방지 : 병합 커밋 없이 정리된 커밋 히스토리를 유지할 수 있습니다. +3) 커밋 순서 정리 및 수정 : git rebase -i HEAD~n을 사용하면 특정 개수의 커밋을 수정, 삭제, 합치기 할 수 있습니다. + +### sub 브랜치를 main 브랜치로 rebase +```bash +git switch sub # sub branch로 이동 +git rebase main # main branch로 rebase +``` + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +- git stash : 작업 중인 변경 사항을 임시로 저장하고, 작업 디렉토리를 깨끗한 상태로 되돌리는 기능입니다. + +<활용방법> +1) 커밋하지 않고도 다른 브랜치로 이동하거나, 코드를 테스트할 때 유용합니다. +2) 변경 사항 임시 저장 : Staging Area와 Working Directory의 변경 사항이 stash로 이동하고, 작업 디렉토리는 깨끗한 상태가 됩니다. +3) 임시 저장한 변경 사항 적용 : 가장 최근에 저장한 변경 사항을 다시 적용하고, stash 목록에서 제거합니다. +4) 저장된 목록 확인 : 여러 개의 stash를 저장할 수 있으며, 목록을 확인할 수 있습니다. +5) 특정 stash 적용 : stash@{n}에 해당하는 특정 stash를 적용하지만 목록에서 제거하지 않습니다. +6) 특정 stash 삭제 +7) 모든 stash 삭제 + +### 사용 예 +```bash +git stash save "임시 변경사항" +# git switch, checkout 등 작업 수행 +git stash list +git stash pop +``` + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. +- Github는 수많은 양의 레포지토리들을 어떻게 감당할까 diff --git a/git-basics/README.md b/git-basics/README.md new file mode 100644 index 0000000..ff07a0d --- /dev/null +++ b/git-basics/README.md @@ -0,0 +1,65 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. +Git Merge, Git Fetch는 생략해도 됩니다. + + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. +branch와 HEAD, git checkout을 포함하여 작성 바랍니다. +branch 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. +특히 Merge의 두 타입인 Fast-Forward와 3-Way Merge를 포함해주세요. + + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- 브랜치관리전략에 대표적으로 Github Flow, Git Flow가 있습니다. 두 방식에서는 리포지토리를 어떻게 관리할까요? +- `git rebase --interactive`란? +- branch의 upstream이란? (`git push --set-upstream`) +- PR은 브랜치 뿐만 아니라 Fork한 리포지토리에서도 가능하다. fork은 언제 유용한지. +- `git fetch`와 `git pull`의 차이점, fetch는 언제 쓰는지 +- `reset --hard`와 `push --force`의 적절한 사용법 +- `.gitignore` 사용법 +- 브랜치 이름은 슬래시를 통해 계층적으로 가질 수 있다. 단, `parent/child-1`, `parent/child-2`는 동시에 가질 수 있지만 `parent/child/grandchild`, `parent/child`는 그러지 못한다. 무슨 이유 때문인지. +- detached HEAD란 어떤 상태인지, 이 상태에서 커밋을 하게 되면 어떻게 되는지, detached HEAD는 어떤 상황에서 발생할 수 있는지 + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. diff --git a/step-1-Haemi b/step-1-Haemi new file mode 100644 index 0000000..78a5af8 --- /dev/null +++ b/step-1-Haemi @@ -0,0 +1,126 @@ +# Git 기초 +Git을 사용하려면 알아야 할 기본 지식을 학습합시다. 아래 항목 위주로 조사하여 나름 이해한대로 채워주시기 바랍니다. 이 템플릿을 이용해도 되고, 자유 형식으로 정리하셔도 됩니다. 블로그 등에 정리한 경우 링크를 첨부해주세요. + +## Git != Github +![git-is-not-github](https://user-images.githubusercontent.com/51331195/160232512-3d6686ca-4ae3-4f11-a8d7-c893c0a7526a.png) +git과 github는 같은 의미가 아닙니다. +local, remote와 연관지어 적어주세요. + +Git은 버전 관리 시스템으로 파일의 변경 이력을 기록합니다. +Github는 Git 저장소를 인터넷에 올려 협업할 수 있게 해주는 서비스입니다. + +local은 내 컴퓨터, remote는 Github 서버입니다. +local에서 작업 후 commit하고 remote로 push합니다. + + +## Git Workflow +![git-workflow](https://cdn-media-1.freecodecamp.org/images/1*iL2J8k4ygQlg3xriKGimbQ.png) +위는 git이 어떻게 동작하는지 나타낸 다이어그램입니다. +Working Directory, Git Add, Git Commit, Git Push 등 각 항목에 대해 작성 바랍니다. + +Working Directory는 파일을 수정하는 공간입니다. +Git Add는 수정한 파일을 staging area에 올리는 과정입니다. +Git Commit은 변경사항을 기록으로 저장하는 단계입니다. +Git Push는 commit을 원격 저장소로 보내는 단계입니다. + +기본 흐름은 수정 → add → commit → push 입니다. + + +## Branch, HEAD +![branch-and-head](https://ihatetomatoes.net/wp-content/uploads/2020/04/07-head-pointer.png) +git이 동작하는 기본 단위는 commit과 branch입니다. + +branch는 작업을 나누는 기능으로, main과 별도로 작업할 수 있습니다. +HEAD는 현재 작업 위치를 가리키는 포인터입니다. + +git checkout을 사용하면 브랜치를 이동할 수 있습니다. + +- git checkout 브랜치이름 +- git checkout -b 새브랜치 +- git branch +- git branch -d 브랜치이름 + + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. + +- git clone과 git init의 차이점, 이용방법 + +git clone은 원격 저장소를 복사해오는 것이고, +git init은 새 저장소를 만드는 것입니다. + +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +origin은 원격 저장소의 기본 이름입니다. + +git remote add origin 저장소주소 + + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. + +soft: commit만 취소 +mixed: staging area 초기화 +hard: 모든 변경 삭제 + + +## Pull Request, Merge +![pull-request-merge](https://atlassianblog.wpengine.com/wp-content/uploads/bitbucket411-blog-1200x-branches2.png) +Pull Request와 Merge에 대한 내용을 적어주세요. + +Pull Request는 내가 작업한 브랜치를 합쳐달라고 요청하는 것입니다. +Merge는 브랜치를 합치는 작업입니다. + +Fast-Forward는 단순 이동 방식이고 +3-Way Merge는 새로운 commit을 만들어 합치는 방식입니다. + + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +rebase는 commit을 다른 브랜치 위로 옮기는 기능입니다. +히스토리를 깔끔하게 정리할 때 사용합니다. + + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +git stash는 작업 중인 내용을 임시 저장하는 기능입니다. + +git stash: 저장 +git stash pop: 다시 적용 + + +## Advanced +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. + +- Github Flow: main 브랜치를 중심으로 간단하게 운영하는 방식 +- Git Flow: develop, feature, release 등 여러 브랜치를 사용하는 복잡한 방식 + +- git rebase --interactive: commit을 수정하거나 합칠 수 있는 기능 + +- upstream: 원격 브랜치와 연결하는 개념 + git push --set-upstream origin 브랜치이름 + +- fork: 다른 사람의 저장소를 복사해서 사용하는 것 (오픈소스 기여할 때 유용) + +- fetch vs pull: + fetch는 가져오기만 하고, pull은 가져와서 merge까지 함 + +- reset --hard / push --force: 강제로 되돌리는 명령어 (협업 시 주의) + +- .gitignore: 특정 파일을 git 관리에서 제외 + +- 브랜치 이름 구조 제한: 내부적으로 파일처럼 관리되기 때문에 충돌 발생 + +- detached HEAD: 브랜치가 아닌 특정 commit을 가리키는 상태 + + +## Questions +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. + +- rebase와 merge의 차이가 아직 헷갈립니다. +- 협업할 때 branch를 어떻게 나누는 것이 좋은지 궁금합니다.