Git/Github 협업용 실전 사용법/README.md 작성법/커밋의 단위 기준
by 노실언니* 가로 900px 에 개행이 맞춰져 있습니다.
위 특강 내용을 복습할 겸, 그리고 이 지식이 필요할 때가 곧 올 것 같아서 TIL과는 따로 Git/Github에 대한 글을 팠습니다.
깁니다. 제가 나중에 다시 찾아볼 법한 모든 것을 적었습니다.
기본참고자료 ▶ git 공식 문서 GPT 내일배움캠프 예병수튜터님의 실시간 특강과 약 200p분량의 ppt 특강자료
- 깃 공식 문서는 가이드북과 레퍼런스가 잘 정리되어있습니다. 그러나, 이 문서로도 이해가 가지 않으면(저는 많았어요) Chat-GPT 선생님이 정말 잘 설명해주십니다. 와 진짜 감탄함 / GPT로도 이해 안가면 튜터님께 질문하려고 했는데 GPT 선에서 다 끝남
GPT님은 조교입니다👍
- Git은 독학으로 1부터 100까지 차근차근 배운 적이 있어 아예 모르는 것은 아니었습니다. 그렇지만, 제대로 사용하는 법을 몰랐던것 같아요. / 실시간 채팅으로 튜터님과 소통하면서 들은 특강덕분에 Git과 Github가 개발 및 협업에서 가지는 가치와 구체적으로 어떻게 사용해야 제대로 사용하는 것인지를 실전적인 관점으로 배울 수 있었습니다. 완전히 1부터 100까지 차근차근 배웠던 혼자서 공부한 것과는 다른 관점으로 Git과 Github가 와닿았습니다. 이렇게 해야 제대로 쓰는 거구나 !
README.md 작성에 도움되는 글
템플릿 [1 (깃헙 최多스타 영어)] [2(영어)] [3(한글설명)]
꾸미기 [1]
협업시 Git/Github 사용 흐름 - gitflow
0. 구현할 기능과 개발 담당자를 정하고 깃 컨벤션을 논의한다
① 구현할 기능과 개발 담당자를 정한다.
② 확정적으로 완성된 프로그램 코드를 담을, 최종 브랜치 이름(예: main),
각자 개발 작업을 진행하고 푸시할 때 PR이 발생하고 머지되는, 개발 브랜치 이름(예: dev),
개발 브랜치에서 분기되어 각자 맡은 기능을 개발할 기능 브랜치들의 이름(예: feat/기능간단키워드 or feature/기능간단키워드)
을 정한다.
③ 커밋 메세지 컨벤션을 논의한다. [참고] feat, fix, build, chore, ci, docs, refactor, test, perf, conflict
④ Pull request의 review 작성은 모두가 할지, 어떻게 할지 논의한다
⑤ PR타임(개발마감 및 PR, Review, 계획점검 시간)을 정한다.
- Pull & Push를 다같이 할지 혹은 생성된 Pull Request를 해결한 후 순서대로 다음사람이 Pull & Push를 할지
⑥ 모든 팀원이 잘 지킬 수 있도록, 깃 컨벤션을 명세화한다.
구분라벨: 커밋제목 // Header (대문자로 시작, 명령문, 마침표X, 50자 이내)
// 빈 행으로 구분
본문 // Body: Header에서 표현할 수 없는 상세 내용(무엇, 왜에 대하여)
// 빈 행으로 구분
바닥글 // Footer: 참조정보 (예: Issues # 21)
--예시--
git commit -m "fix: Safari에서 모달을 띄웠을 때 스크롤 이슈 수정
모바일 사파리에서 Carousel 모달을 띄웠을 때,
모달 밖의 상하 스크롤이 움직이는 이슈 수정.
resolves: #1137"1. 팀장이 먼저 기본적인 세팅을 한 후 팀원들을 콜라보레이터로 추가한다
팀장 초기 세팅
① 작업할 로컬 프로젝트 폴더를 만들고 VScode로 연다.
② 깃-배쉬/쉘/터미널 등에서 작업할 로컬 프로젝트 폴더를 만들고 워킹 디렉토리로 설정한다. (pwd cd ls mkdir)
③ 프로젝트 폴더의 깃 관리를 시작한다 → git init
④ (권장) 로컬 저장소의 기본 브랜치 이름을 master에서 main으로 변경한다 → git branch -M main
└ 브랜치 이름을 바꾸려면 → git branch (-m|-M) [<기존이름>]<새이름>
└ -m 과 -M의 차이 : --move 의 약자 VS --move --force 의 shortcut
⑤ README.md 파일을 만든다 → touch README.md
└ touch파일명 현 작업 위치 안에 새 파일 생성
⑥ README.md 파일로 첫 커밋을 한다 → git add README.md, git commit -m "First commit: Start this project"
└ git status (git이 바라보는 각 파일의 상태) 로 상태를 확인한 후 커밋해도 좋다
└ 상태 : Untracked 아직 관리대상X, Unmodified 관리대상이나 변경사항없음, Modified 변경사항있음, Staged 커밋할 대상
⑦ Github에 작업할 원격 레포지토리를 생성하고 https 주소를 복사한다
⑧ 내 로컬저장소와 원격저장소를 연결한다 / 원격저장소 이름은 origin (추천) → git remote add origin https://···.git
└ 로컬에 특정한 원격 저장소(레포지토리)를 연결하려면 → git remote add <원격저장소명> https://···.git
⑨ 현 로컬 브랜치(main)의 커밋을 원격 저장소(origin)의 같은 이름(main)의 브랜치에 푸시한다 → git push origin main
└ 로컬 커밋들을 원격 저장소에 업로드하려면 → git push <원격 저장소이름> <로컬 브랜치 명>[:<원격 브랜치 명 >]
└ [:<원격 브랜치명>]을 생략하면 → 로컬과 동일한 이름의 원격 브랜치를 찾는다 (없으면 생성함)
⑩ 앞으로 로컬, 원격 브랜치 main은 배포 단계의 최종 완성품을 업로드하는 곳이라는 것을 인지한다
⑪ 로컬 저장소에서 개발 브랜치를 생성하고 이동한다 / 개발 브랜치의 이름은 dev (추천) → git switch -c dev
└ 브랜치를 생성 → 작업 위치를 분기할 기준이 되는 브랜치로 이동한 후 git branch <브랜치명>
└ 작업 브랜치 이동 → git switch <이동할 브랜치명>
└ 브랜치를 생성 및 이동하려면 → git switch -c <생성및이동할 브랜치명>
⑫ 로컬 저장소의 개발 브랜치(dev)를 원격 저장소(origin)의 같은 이름(dev)의 브랜치에 푸시한다 → git push origin dev
⑬ 깃허브 레포지토리 settings의 general에서 Default branch 를 main에서 dev로 변경 후 Update한다
└ Default branch : 작업 흐름의 기본점
└ 원격 저장소를 처음 clone 하는 사용자는 default branch 를 기본 브랜치로 받아온다 (download & checkout)
└ Pull Request 생성 시,기본적으로 default branch가 병합 대상 브랜치로 설정된다
⑭ 팀원들을 Collaborator 로 등록한다 → settings - Collaborators - Add people
2. 팀원은 위 원격 저장소를 클론한 후 본인들의 기본적인 작업세팅을 한다
팀원 초기 세팅
① 깃-배쉬/쉘/터미널 등에서 '클론해 올 폴더를 보관할' 상위 폴더를 워킹 디렉토리로 설정한다. (pwd cd ls mkdir)
② 원격 저장소의 https 주소를 복사하여 클론한다 → git clone <https://원격저장소주소>
└ 명령어 맨 뒤에 . 을 붙이면 감싸는 폴더 없이 .git, README.md와 같은 내용물이 복붙된다
③ git remote -v 로 원격 저장소 연결이 제대로 되어있는지 확인하고, git branch -a 로 작업 브랜치도 확인한다
└ main 이 아닌 dev 가 현재 작업 브랜치인지 확인
④ 개발 브랜치(dev)에서 각자 본인이 맡은 기능을 개발할 브랜치를 생성 및 이동한다 → git switch -c <기능브랜치이름>
└ 기능 브랜치 이름은 팀 계획단계에서 정한 이름
⑤ 커밋과 푸시 → git commit --allow-empty -m "메세지" git push <원격브랜치이름(origin)><로컬기능브랜치이름>
└ 메세지 예시 : init: feature/기능간단키워드 개발시작
└ git commit --allow-empty -m "메세지" → 변경사항이 없는 빈 커밋을 만들 때 사용
└ push할 때, 로컬브랜치명:원격브랜치명의 :원격브랜치명을 생략하면, 로컬과 같은 이름의 브랜치를 찾아서 푸시한다
⑥ 각자 본인의 브랜치 생성에 대한 Pull request 를 생성한다
└ base:개발 브랜치(dev) ← compare: 기능 브랜치(feature/···) 인지 꼭 체크한다.
⑦ 본인 혹은 다른 팀원이 Github에서 각 Pull request를 merge 한다.
⑧ 브랜치를 dev로 이동한 후, PR이 반영된 원격 레포지토리의 dev 브랜치를 pull 한다. → git switch dev git pull origin dev
⑨ 다시 본인의 기능 브랜치로 이동해서 본격적으로 작업을 시작한다 → git switch <기능브랜치명>
3. 좋은 커밋, 개발 진행시 어디까지를 하나의 커밋으로 묶어야 하는가
- 계획단계에서 본인이 받은 역할을 해내기 위한, 작고 독립적인 단위(단일작업단위)의 실행계획을 작성
- 단일작업단위, 버그, 리팩토링, 의존성 변경 한 건당 하나의 커밋을 만든다.
- 한 커밋은 여러 문제를 해결하지 않고, 논리적인 경계가 존재한다.
- 커밋 메세지는 계획단계에서 정했던 커밋 컨벤션대로, 무엇을 왜했는지 명확히 적는다.
★ 따라서, 변경된 코드 중 일부 코드만 커밋 대상으로 지정하고 싶을 때 → git add -p (part)
└ hunk: 변경된 코드 블록 / y 지정 / n 지정X / s 모두 지정 / u 방금한 지정 취소 / q add -p 작업취소
4. 전부 모여서 하루 간의 했던 작업의 PR 타임을 가진다
① 정해둔 PR타임(개발마감 및 PR, Review, 계획점검 시간)에 모인다.
② 한명씩 혹은 한꺼번에 오늘 한 작업을 푸시하여 Pull request를 생성하고 리뷰를 요청한다.
- 코드리뷰하기
- 기준 개발 브랜치(dev)로 pull 되는 것이 허가된 경우, 깃허브에서 merge 를 클릭한다.(충돌시 버튼 비활성화)
- 충돌한 경우, 자신의 로컬 기능 브랜치에서 git pull origin dev 하여 충돌을 해결하고 add, commit, push 한다.
→ Pull request가 자동으로 업데이트 된다 !
③ 팀 개발 일정과 개별 개발 일정이 제대로 진행되고 있는지 점검하고, 해결해야 할 ISSUE를 논의 한 후 일정을 조정한다.
④ 해산 혹은 추가 개발
간단 정리
1. 개발단계의 원활함을 위해서 계획단계를 철저히 한다
2. git-flow 방식으로 개발/커밋을 진행한다
① 팀장이 개발 환경을 구축해서 푸시해두면, 팀원은 원격 저장소를 클론한다 git clone <https://원격저장소주소>
② dev 브랜치에서 자신의 브랜치(기능 브랜치)를 만들고 작업한다 git switch -c <기능브랜치명>
③ 작업내역(커밋)들을 원격 저장소의 같은 브랜치에 업로드하고 Pull request를 작성한다 git push origin <기능브랜치명>
3. Pull Request 시간을 진행한다
- Pull Request를 작성 리뷰어를 등록 → 리뷰어는 코드리뷰를 진행하여 머지여부를 판단한다
④ 충돌로 머지가 불가능한 경우, 원격 dev 브랜치를 내 로컬로 가져와 병합한 후 충돌을 해결한다 git pull origin dev
⑤ 충돌해결을 add, commit하고 다시 원격 저장소에 업로드한다 git push origin <기능브랜치명>
⑥ 충돌을 해결한 커밋까지 업데이트된 Pull request 를 승인하고 merge 한다.
re-① 수정된 dev브랜치를 내 로컬 dev브랜치에 반영한다 git pull origin dev
re-② 기존 기능 브랜치 선택 시, dev 를 기능 브랜치에 병합한 후 작업을 이어서 진행한다 혹은 새로운 브랜치를 만들고 작업한다
re-③~⑥ ③~⑥와 동일 이하 반복
4. 계획을 재조정한 후 3. 반복
Conflict의 원인과 해결법
원인: 겹쳐서 → 병합하려는 두 브랜치 모 같은 파일의 같은 위치(line)를 변경했을 때 발생
해결법
① <<<<< HEAD 겹치는 코드 ===== 켭치는 코드 >>>>> 커밋ID 를 참조하여 겹친 라인의 최종 코드를 다시 작성한다
② add & commit
+ pull에서 발생한 conflict라면, push 까지
기본 개념
Shell 명령어
pwd print working directory 현 작업 위치(경로) 알려줘 (~는 home)
ls list 현 작업 디렉토리 내 폴더와 파일 보여줘
ls -a all 숨긴 파일까지 전부 보여줘
cd 디렉토리명 change directory 작업위치를 변경해줘 ( .. 이전, . 현재, 절대경로, 상대경로OK)
mkdir 디렉토리명 make directory 현 작업 위치 안에 새 디렉토리 생성
touch 파일명 현 작업 위치 안에 새 파일 생성
└ touch가 touch인 이유 [출처] 파일내용에 접근하지 않고 최소한의 방식(터치하듯)으로 파일과 상호작용하는 명령어
touch는 겉을 톡- 친다는 정도의 느낌을 준다.
touch 명령어가 작동할 때는 파일을 열 필요가 없다, 즉 파일 내부로 들어가서 입력/수정하지 않는다.
밖에서 파일을 톡- 칠 뿐인데 메타데이터를 생성/수정하여 파일을 존재하게 만드는 명령어라는 것 :D
너무 이전 명령어들이랑 결이 달라서 넘눠무 궁금했다
Git/Github 간단 정의 및 명령어 정리
Git 이란
- 면접용: 소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 것
- 내식대로: 기록 저장/분석소 + 타임머신
Github 란
git 으로 관리되는 코드 내용을 업로드하는 온라인 저장소로 백업뿐만 아니라 공유도 가능하다 → 협업용이
특정 폴더, 그 아래 파일/폴더 전부 git의 버전관리영역으로 두고 싶을 때 → 프로젝트 폴더 안에서 git init
└ 마우스로 하는 방법도 있지만 키보드로 모든 걸 해결하는 므찐 개발자가 되고 싶다면
└ 꼭 pwd, ls, cd 명령어 사용하여 관리받고 싶은 폴더를 현재 작업 위치로 설정한 후 git init 합시다
왜 사진 캡션에 링크가 안 걸어지지? [출처링크]
[ Local ]
Git 의 버전관리를 원하는 폴더가 있다면 → git init
└ 버전관리를 원하는 폴더 내부를 working directory 로 설정한 후에 명령어를 입력하여야 한다
└ init를 하게되면 폴더 내부에 .git 파일이 생성되고 master 라는 기본 브랜치가 자동 생성된다
git 이 바라보는 각 파일의 상태를 알고 싶다면 → git status
└ 상태 : Untracked 아직 관리대상X, Unmodified 관리대상이나 변경사항없음, Modified 변경사항있음, Staged 커밋할 대상
각 파일의 생성/수정/삭제내역을 커밋할 대상으로 지정하려면 → git add <파일명> (git add . 모든 변경사항 선택)
└ add 실행 후 파일의 state 변화 : Untracked/Modified → Staged
└ 변경된 코드 중 일부 코드만 커밋 대상으로 지정하고 싶을 때 → git add -p (part)
└ hunk: 변경된 코드 블록 / y 지정 / n 지정X / s 모두 지정 / u 방금한 지정 취소 / q add -p 작업취소
git add를 통해 커밋할 대상으로 지정된 파일의 변경사항 즉 staged 된 내역을 실제로 커밋하려면 → git commit -m "메세지"
└ commit 실행 후 파일의 state 변화 : Staged → Unmodified
└ 닫는 " 를 쓰지 않고 엔터를 치면 커밋 메세지 개행이 가능하다
└ 커밋을 하기 위해서는 add를 통해서 커밋할 대상을 꼭 지정하는 사전 작업이 필요하다.
└ 변경사항이 없는 빈 커밋을 만들려면 → git commit --allow-empty -m "메세지"
커밋 내역을 확인하려면 → git log
브랜치를 생성하려면 → 작업 위치를 분기할 기준이 되는 브랜치로 이동한 후 git branch <브랜치명>
작업 브랜치를 이동하려면 → git switch <이동할 브랜치명> / 과거 유물 git checkout <동일>
브랜치를 생성 및 이동하려면 → git switch -c <생성및이동할 브랜치명> / 과거 유물 git checkout -b <동일>
* 특강을 기억하는 우리들만의 약속🤙 스위치 -창식 체크아웃 -병수
로컬 브랜치 리스트를 보려면 → git branch
└ 로컬/원격 전부 git branch -a (all)
└ 원격만 git branch -r (remote)
브랜치 이름을 바꾸려면 → git branch (-m|-M) [<기존이름>]<새이름>
└ 현재 작업 중인 브랜치 이름을 바꾸려면 → git branch -m <새이름>
└ 작업위치와 상관없이 브랜치 이름을 바꾸려면 → git branch -m <바꾸려는브랜치이름><새이름>
└ -m 과 -M의 차이 : --move 의 약자 VS --move --force 의 shortcut
여러 브랜치(a, b, c)가 있는 상황에서 a의 이름을 b로 바꾸려는 경우 즉,
새 이름(a→b)과 동일한 이름의 브랜치(b)가 이미 존재하는 경우에 두 옵션으로 인한 차이가 발생한다.
-m 은 에러를 만들어 이름 변경에 실패한다
-M 은 강제로 변경이 되는데,
문제는 a의 내용이 기존 b 브랜치의 내용 위에 덮어씌워지며 이름이 변경되는거라 기존 b 브랜치의 내용은 소실된다
따라서, -M의 사용은 최소화하는 것이 좋다
작업 되돌리기 → git reset -hard 커밋ID [참고자료]
특정 브랜치에 다른 브랜치의 커밋을 더하려면 → 병합 기준 브랜치로 작업 브랜치를 변경한 후, git merge <더할 브랜치명>
└ Fast-forward 병합 기준 브랜치로부터 작업 브랜치가 분기한 이후, 기준 브랜치는 변경되지 않아서 여전히 부모인 경우
└ 3-way 병합 기준 브랜치도 변경되는 경우 + 공통조상커밋 이후의 커밋들을 합친 후 새로운 Merge Commit 을 생성한다
└ rebase 병합 기준 브랜치도 변경되는 경우 + 작업 브랜치의 변경사항들을 기준 브랜치의 마지막 커밋 이후에 붙인다
* 내역이 남는 병합, 안 남는 병합이 있는데 초심자니까 깔끔함보다는 정직함으로 가자 (...)
[FAST-FORWORD]
1.
A ─ B ─ C (dev)
2. dev에서 git branch feat/login & feat/login에서 개발
A ─ B ─ C (dev)
＼
D ─ E (feat/login)
3. dev에서 git merge feat/login → Fast-forward 병합
A ─ B ─ C ─ D ─ E (dev)
A ─ B ─ C ─ D ─ E (feat/login)[3-WAY]
1. dev 작업 및 커밋
A ─ B ─ C (dev)
2. dev에서 git branch feat/login
A ─ B ─ C (dev)
＼
(feat/login)
3(1). feat/login 개발 및 커밋
3(2). dev도 변동생김
A ─ B ─ C ─ D ─ F (dev)
＼
E ─ G ─ H (feat/login)
4. dev에서 git merge feat/login → 3-way 병합
A ─ B ─ C ─ D ─ F ─ m (dev) * m은 merge 커밋
＼ │
E ─ G ─ H
A ─ B ─ C ─ E ─ G ─ H (feat/login)[REBASE]
1. dev 작업 및 커밋
A ─ B ─ C (dev)
2. dev에서 git branch feat/login
A ─ B ─ C (dev)
＼
(feat/login)
3(1). feat/login 개발 및 커밋
3(2). dev도 변동생김
A ─ B ─ C ─ D ─ F (dev)
＼
E ─ G ─ H (feat/login)
4. feat/login 에서 git rebase dev → rebase 병합 ★
① 커밋을 옮겨서 분기점 변경
A ─ B ─ C ─ D ─ F (dev)
→ ＼
E ─ G ─ H (feat/login)
② fast-forward merge (= dev에서 git merge feat/login)
A ─ B ─ C ─ D ─ F ─ E ─ G ─ H (dev)
A ─ B ─ C ─ D ─ F ─ E ─ G ─ H (feat/login)
* Rebase는 기존의 커밋을 그대로 사용하는 것이 아니라 내용은 같지만 다른 커밋을 새로 만든다.
* 이미 공개 저장소에 Push 한 커밋을 Rebase 하지 마라
* git branch -M main 에 대한 TMI / 난 정말 이 블로그에 토글기능이 없는게 슬퍼😢
이전에 서술했듯 git init로 버전관리를 시작하면 master 라는 이름의 브랜치가 default 로 존재한다.
github로 원격 레포지토리(저장소)를 만들 땐 master가 아닌 main 이라는 이름의 브랜치가 default 로 존재한다.
원래는 github의 init 후 기본 브랜치이름도 master 였는데 2020년에 바뀌었다.
그 이유는 ···
① git 이전의 코드관리 선두 주자는 BitKeeper 였고 Linux Torvalds좌 역시 리눅스커널을 개발할 때 이를 사용했는데 얘가 유료화를 함
└ 오픈소스 정신의 선구자 Linux Torvalds는 위 시스템보다 더 빠르고 무료👍인 분산형 버전관리시스템 Git을 직접 2주만에...개발 [출처]
└ BitKeeper는 하나가 다른 하나의 제어권을 갖는 버전관리 메커니즘에서 원본 저장소를 master - 사본 저장소를 slave repos로 불렀다.
└ Git은 위와 다른 구조를 사용하므로 slave 참조 없이 master 를 기본 브랜치명으로 사용하였다. + 코드의 master copy 라는 의미
└ 즉, git에 slave는 존재하진 않으나 master는 master/slave 관계에서 나온 것이라는 연관성이 있다. (무언가에 통달한 마스터가 아니라)
└ BitKeeper의 잘못도 아닌 것이 공학계에서는 한 요소가 다른 요소의 제어권을 몽땅 가지고 있는 관계를 Master/Slave 로 흔히들 말했다
② git 을 기반으로 하는 원격 저장소 서비스들(github, gitlab 등)도 자연스럽게 master 이라는 이름을 기본 브랜치명으로 사용하였다
③ 2020년, 무료 오픈 소스 소프트웨어 개발 프로젝트에게 주택이나 인프라, 법적지원을 하는 software freedom conservancy 에서
master 라는 이름이 누군가에게 상처를 줄 수 있다는 것을 언급, meaningful & inclusive 한 다른 이름으로 바꾸길 권장한다는 글을 발표하였다
④ github는 위 글을 발표한 software freedom conservancy의 지원을 받는 member project 중 하나였고 [공식문서] 이를 따랐다.
└ (그런데, 지금은 둘이 사이가 안 좋아진듯? [출처])
└ 뿐만아니라, 다른 원격 저장소 서비스들도 점점 위 문서를 따랐다. [GitLab]
③ github는 기본 생성 브랜치의 이름을 master → main 으로 바꾸는 것에 대한 글을 업로드하고 바꾸었다. [해당 깃허브 링크]
└ 대략 자신들을 비롯한 많은 그룹들이 master 라는 이름을 변경하려하며, 본인들은 짧고 직관적인 main으로 바꾸겠다는 내용
└ 뿐만아니라, 다른 원격 저장소 서비스들도 점점 이러한 경향성을 따랐다 [GitLab]
* '너무들 오바하는거같은데, 굳이 바꿔?' 라고 생각했던 사람의 생각 흐름이 담긴 글을 봤는데 참고자료가 전부 오피셜이었고 꽤 설득력있었다.
* 기본 브랜치 이름은 회사의 개발 컨벤션에 따르는게 베스트라고 생각한다 !
[Remote & Local]
원격 저장소 리스트를 보려면 → git remote 와 git remote -v (상세URL까지)
└ (예) git remote 실행 시
origin
backup└ (예) git remote -v 실행 시 / verbose(상세한, 구체적인)
origin https://github.com/user/repo.git (fetch)
origin https://github.com/user/repo.git (push)
backup https://bitbucket.org/user/repo.git (fetch)
backup https://bitbucket.org/user/repo.git (push)따라서, -v 옵션을 사용하면 원격 저장소 이름뿐만 아니라 fetch, push작업에 사용되는 구체적인 URL까지 파악 가능
로컬에 특정한 원격 저장소(레포지토리)를 연결하려면 → git remote add <원격저장소명> https://···.git
└ (예) git remote add origin https://···.git 해당 url을 원격 저장소 연결하고 저장소 이름은 origin으로 짓겠다
└ master, main : 로컬이든 원격이든 브랜치 기본 이름 | origin : 흔히들 설정하는 원격저장소 기본 이름 → 같은 레벨 X
로컬에서 특정 원격 저장소와의 연결 해제하려면 → git rm <원격저장소명>
└ 연결해제일뿐 내용이 지워지진 않는다 다행
원격 저장소 이름을 수정하려면 → git rename <기존 이름> <새 이름>
로컬 영역에서 브랜치를 생성하려면 → git branch <브랜치명>
현재 작업 브랜치 혹은 특정 브랜치의 이름을 수정하려면 → git branch (-m|-M) [<기존 이름>] <새 이름>
└ 로컬/원격 구분없이 브랜치라면 위 명령어로 수정가능 / M : 동일한 이름 존재하는 경우 강제덮쓰
로컬 커밋들을 원격 저장소에 업로드/동기화하려면 → git push <원격 저장소이름> <로컬 브랜치 명>[:<원격 브랜치 명 >]
└ 저 이름의 원격 저장소에 푸시를 할껀데, 이 이름의 로컬 브랜치를 : 저 이름의 원격 브랜치로 푸시해줘
만일 git push <원격 저장소 명> <로컬 브랜치 명> 만 쓰면→로컬과 동일한 이름의 원격 브랜치를 찾는다
만일 push 명령어에 의해 찾고자하는 이름의 원격 브랜치가 없다면 → 깃은 원격 브랜치를 새로 만든 후 푸시한다
계속 이 로컬 브랜치와 push, pull 할 원격저장소/원격브랜치 위치가 동일하다면 ? → 추적 관계 설정 후 git push
Tracking branch 설정 → 설정하고 픈 로컬 브랜치로 이동, git branch --set-upstream-to=<원격저장소>/<원격브랜치>
Tracking branch 설정과 push를 한번에 → git push (-u|--up-stream) <원격 저장소> <로컬 브랜치>[:<원격 브랜치 >]
└ -u 옵션에 의해 로컬 브랜치와 원격 브랜치 간의 추적관계가 설정된 후, push가 정상 진행된다
└ git push 명과 마찬가지로 원격브랜치명을 생략하면, 로컬 브랜치와 동일한 이름의 원격 브랜치를 찾는다/없으면 생성
Tracking branch 에 대한 목록을 보려면 → git remote -vv
(cf. git remote -v 는 최신커밋해시와 메세지만 출력하고 연결 원격 브랜치는 알려주지 않음)
명령
git branch -vv
결과
* main abc1234 [origin/main] 최신 커밋 메시지
feature-xyz def5678 [origin/feature-xyz] 다른 커밋 메시지
해석
* main : 현재 작업중인 로컬 브랜치는 main 이며 main의 최신 커밋 정보는 아래와 같다.
커밋 해시: abc1234
추적했던 원격브랜치: 원격 저장소origin의 main branch
메세지 내용내 원격 저장소 혹은 내가 콜라보레이터로 등록된 원격 저장소를 로컬로 가져오려면 → git clone <https://...주소>
└ git clone <https://원격주소> 워킹 디렉토리에 / 원격 저장소 이름과 동일한 폴더 생성 / 그 속에 .git을 포함한 모든 내용물 복붙
└ git clone <https://원격주소> . 워킹 디렉토리에 바로 .git을 포함한 모든 내용물을 복붙 (주의) 워킹 디렉토리가 비어있어야 함
└ git clone 한 직후에는 git pull을 따로 실행할 필요가 없다.
다른 사람의 원격 저장소를 내 로컬로 복사해오려면 → git fork
기본 작업 브랜치 default branch 설정 방법 → 깃허브 settings - general - default branch 에서 선택 - Update
└ Default branch : 작업 흐름의 기본점
└ 원격 저장소를 처음 clone 하는 사용자는 default branch 를 기본 브랜치로 받아온다 (download & checkout)
└ Pull Request 생성 시,기본적으로 default branch가 병합 대상 브랜치로 설정된다
Collaborator 등록 → settings - Collaborators - Add people - username, email 등 입력 후 Select a collaborator above
원격 저장소/특정 브랜치의 커밋들을 내 로컬 브랜치에 합치려면 → git pull <원격저장소이름> <원격브랜치이름>
└ pull 은 2개의 명령어가 합쳐진 명령어이다 → git fetch <원격저장소명> <원격브랜치이름> + git merge FETCH_HEAD
└ fetch 해당 저장소/브랜치의 변경사항을 로컬 저장소로 가져오는데 이 때 브랜치명은 원격저장소명/브랜치이름으로 저장된다.
└ merge 현재 작업 중인 로컬 브랜치에 fetch 해온 원격저장소명/브랜치명 브랜치의 변경사항을 병합한다(local에 자세히 씀)
git fetch <원격저장소명> [<원격브랜치명>] 란 ?
→ 로컬저장소에 이름이 '원격저장소명/원격브랜치명' 인 브랜치를 만들고 해당 저장소/브랜치의 변경 사항을 가져온다 병합❌
브랜치명 생략시 전부 저장소에 있는 전부의 변경 사항을 로컬로 가져온다
리마인드 QUIZ
1. 프로젝트를 생성하여 git으로 버전관리를 시작하고 싶을때?
2. 코드를 작성한 후 해당 작업을 하나의 단위로 저장하고 싶다면 사용해야하는 명령어?
3. 커밋 내역을 보고 싶다면?
4. 최신 커밋대비 파일들의 변경 상태를 확인하고 싶다면?
5. github에 코드를 업로드하고 싶을 때 간단히 사용하는 명령어는?
6. github의 프로젝트를 복제해오고 싶은 경우 사용하는 명령어는?
7. 연결된 원격 저장소에서 변경된 코드(커밋)을 내 로컬 저장소에 반영하려면?
git init 명령어는 개발 프로젝트 시작 시 딱 한 번만 입력하면 된다?
8. 충돌발생시 어떻게 해결할까?
9. git init 명령어를 입력하면 어떻게 되나요?
10. project-notice 라는 디렉토리 안에서 개발작업을 하고 버전관리를 할 생각입니다.
현재 작업하는 디렉토리가 위 디렉토리가 아닌 경우 git init 형식의 명령어를 사용해도 될까요?
11. git add와 git commit 의 차이?
12. git status 란?
답
1. 프로젝트 폴더를 워킹 디렉토리로 설정한 후 git init
2. git add . & git commit -m '메세지'
3. git log
4. git status
5. git push origin 로컬브랜치명
6. git clone <github주소> *끝에 .을 붙이면 폴더없이 .git을 포함한 내용물이 다운로드됨
7. fetch & merge 혹은 git pull origin 브랜치명
8. <<<< >>>> 속을 원하는 코드로 수정하고 <<<, ===, >>> 를 삭제/저장/add/commit/push
9. 워킹 디렉토리 내에 .git 폴더가 생성되며 해당 디렉토리 속에 있는 파일들의 변경이 전부 추적된다
10. git은 .git 폴더의 상위폴더 내의 모든 파일들을 추적하므로, 다른 디렉토리에서 git init을 사용하면 원하는 위치에서의 버전관리가 불가능하다. 안된다.
11. add 는 하나의 커밋캡슐(?)에 담을 변경 사항을 선택하는 명령어이고, commit 는 실제로 메세지와 함께 커밋하는 명령어이다
12. git 이 관리하는 폴더 내 파일들의 상태(Untracked/Unmodified/Modified/Staged) 를 확인하는 명령어
추가 유튜브 영상 정리 - Git flow
영상 출처 : [10분 테코톡] 렉스의 Git 브랜칭 전략] - 우아한테크 유튜브 채널
규모가 큰 프로젝트의 브렌치 양상을 설명하다보니, 브랜치의 구조가 더 다양하다.
주요 브랜치
- Master(Main)은 배포용 브랜치
- Develop(Dev) 브랜치는 개발용 브랜치
(예) git switch -c dev
보조 브랜치
- Feature 브랜치는 dev에서 분기되고 머지되는 / 하나의 새로운 기능 개발용 브랜치
- Release 브랜치는 dev에서 분기되고 main&dev에 모두 머지되는 테스트용 브랜치 (개발금지)
- Hotfix 브랜치는 배포중인 프로그램에서 버그가 터져서 main에서 분기되고 dev&main에 모두 머지되는 버그수정용 브랜치
아래 내용은 잘 모르겠다 git merge --no-ff 를 하자는 것 정도...
영상에서는 초반부에 설명해주시는 Git flow 설명
'Computer science : 컴퓨터과학 > Writings & Remarks : 💻' 카테고리의 다른 글
| [인프런스크랩] 인프런 최연소 지식공유자 서울대 컴공신입생 되다. - 두들낙서 (0) | 2022.01.07 |
|---|---|
| [인프런스크랩] BackEnd_당장 결과물이 안 나와도 기다릴 수 있는 사람 - 창천향로 이동욱 (0) | 2021.12.13 |
| [인프런스크랩] FrontEnd _ 결국에는 '같이 간다'는 마음으로 - 캡틴판교 (0) | 2021.12.13 |
| [오늘의 탐험] #Git #GitHub #Markdown #Notion (0) | 2021.07.21 |
| Slack(슬랙), 너는 누구니 (0) | 2021.07.19 |
블로그의 정보
노력하는 실버티어
노실언니