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..e228f3e 100644 --- a/README.md +++ b/README.md @@ -1,38 +1,59 @@ -# 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 추천) +mkdir ~/repositories +cd ~/repositories + +# 현재 리포의 우측 상단에서 git clone URL 복사 후 붙여넣기 +git clone + +# 클론된 폴더로 이동 +cd study-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`로 변경 + - 채우면서 최소 5개의 커밋 쌓기 +```bash +# /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) \ No newline at end of file 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/README-jdk.md b/git-basics/README-jdk.md new file mode 100644 index 0000000..a283f2d --- /dev/null +++ b/git-basics/README-jdk.md @@ -0,0 +1,89 @@ +# 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 repository와 remote repository라는 두 개의 저장소를 갖고 있습니다. +로컬 저장소는 자신의 작업 컴퓨터에 저장하는 저장소이고, 원격 저장소는 네트워크에 연결된 서버에 저장하는 저장소입니다. +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 : local repository에 저장하는 행위 +Git Push : local repository에 저장된 변경 사항을 remote repository에 보내는 행위 +Git pull : 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 생성 및 삭제, 이동 커맨드 등 자유롭게 내용을 추가해주세요. + +Master branch는 프로젝트의 메인 진행 줄기입니다. +Feature branch는 개개인이 들고와서 수정하는 줄기입니다. +HEAD는 Feature branch 중 가장 최신 버전입니다. +git checkout은 프로젝트 기록의 특정 시점으로 이동하는 명령어입니다. + + +## clone, init, origin +리포지토리를 로컬에 생성하는 방법은 clone, init이 있습니다. 다음을 포함하여 작성 바랍니다. +- git clone과 git init의 차이점, 이용방법 +- origin이란 키워드는 무엇인지, 어떻게 설정하는지 + +git init은 새로운 git 저장소를 만드는 명령어이고, git clone은 remote repository를 local repository로 복제하는 명령어 +origin은 remote repository를 통제하기 위한 대명사입니다. + +## reset +![reset](https://user-images.githubusercontent.com/51331195/160235594-8836570b-e8bf-484a-bb92-b2bd6d873066.png) +reset에는 3가지 타입이 있습니다. +각 타입에 대해 작성 바랍니다. + +1. git reset -soft : commit된 파일을 초기화하고 staging area로 돌려놓는 명령어 +2. git reset -mixed : commit된 파일을 초기화하고 staging area도 초기화하는 명령어 +3. git reset -hard : commit된 파일과 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 : Feature branch를 Master branch에 합병하는 것을 요청 +Merge : 합병 + +## rebase +![rebase](https://user-images.githubusercontent.com/51331195/160234052-7fe70f85-5906-4474-b809-782adae92b3c.png) +rebase란 무엇인지, 어떤 때에 유용한지 등에 대해 적어주세요. + +rebase : branch의 분기점을 변경하는 행위 +특정 브랜치 A에서 다른 브랜치 B를 파서 작업 중이었는데 A 브랜치에 다른 사람이 추가로 commit을 올리면 B 브랜치를 merge 하려고 할 때, conflict가 발생하므로 +분기점을 변경하여 원활하게 merge될 수 있도록 도와줍니다. + +## stash +![stash](https://d8it4huxumps7.cloudfront.net/bites/wp-content/banners/2023/4/642a663eaff96_git_stash.png) +git stash를 활용하는 방법에 대해 적어주세요. + +A 브랜치에서 작업 중에 B 브랜치를 통한 작업을 해야하는 상황에서 stash를 이용하면 기존에 작업 중이던 변경 사항을 잠시 치워두고 B 브랜치에서 작업을 마친 후에 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 +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요. +merge의 두 타입에 대해 이해가 잘 되지 않습니다. \ No newline at end of file diff --git a/git-basics/README.md b/git-basics/README.md new file mode 100644 index 0000000..d0aec18 --- /dev/null +++ b/git-basics/README.md @@ -0,0 +1,57 @@ +# 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 +다음 주제는 더 조사해볼만한, 생각해볼만한 것들입니다. +- `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 +조사/실습하면서 생긴 궁금점이 있다면 여기에 적어서 공유해주세요.