반응형
깃허브
깃허브는 프로젝트의 버전업 과정을 낱낱이 저장할 수 있는 서비스다.
정확히는, 그것은 깃(GIT)의 역할이고, 깃을 클라우드에 저장할 수 있는 서비스가 깃허브 되시겠다.
- 과거의 변천사에 대해 팔로우업이 필요하거나
- 여러 컴퓨터에서 작업을 해야하거나
- 백업 공간이 필요하거나
- 협업해야하는 경우
깃허브의 대안은 없다.
기본적인 구조
1. 저장구조 (게임에 비유)
: 아래에서 제시 된 저장소들을 하단에서 상단으로 저장하고 필요한 경우 상단에서 다시 로드해서 하단부터 작업한다.
- 원격저장소 vs 로컬저장소 : 원격저장소의 레포지토리, 브랜치를 로컬로 다운로드 받아서 작업 후 다시 원격저장소에 넣는다. - 세이브파일 로드, 플레이 후 다시 세이브
- (원격) REPOSITORY : 하나의 프로젝트에 대한 저장소 - 캐릭 1개에 대한 세이브파일 저장소(ex. 바바리안)
- (원격 / 로컬) BRANCH - 국면 세이브 (ex.적벽대전 클리어)
- (로컬) COMMIT - 하나의 국면 안에서 세이브 파일 (ex. 적벽대전 3번째 턴)
- (로컬) STAGING - 게임 플레이
- (로컬) WORKING DIRECTORY - 플레이 구상
구조에 따른 기본적인 명령어
- 원격저장소 vs 로컬저장소 - 세이브파일 로드, 플레이 후 다시 세이브
- 로컬저장소 시작하기 :
- 로컬저장소 만들기 git init
- 커밋하는 사람 이름 정하기 git config —global user.name "user-name"
- 커밋하는 사람 이메일 정하기 git config —global user.email "user-email@user-email.com"
- 원격~로컬 연결
- repo 주소 등록 (origin이라는 이름으로) : git remote add origin https://github.com/myName/myRepo.git
- repo 조회하기 : git remote show origin
- 로컬저장소 시작하기 :
- (원격) REPOSITORY : 캐릭 1개에 대한 세이브파일 저장소(ex. 바바리안)
- 레포지토리의 브랜치 가져오기 :
- git clone -b branch https://github.com/myName/myRepo.git . : 그냥 복제해오기
- git pull origin branch : 수정된 부분 자동 merge
- git fetch origin braanch : 수정된 부분 확인해가면서 merge
- 원격 레포지토리 조작하기 :
- 브랜치 생성 또는 저장하기 git push origin <branch-name>
- 브랜치 제거하기 git push origin —delete <branch-name>
- 레포지토리의 브랜치 가져오기 :
- (원격 / 로컬) BRANCH - 국면 세이브 (ex.적벽대전 클리어)
- 브랜치 생성하기 : git checkout -b <new-branch-name>
- 브랜치 제거하기 : git checkout -d <branch-name>
- 브랜치 전환하기 : git checkout <branch-name>
- 브랜치 이름바꾸기 : git branch -m <new-branch-name>
- 브랜치 목록 조회하기 : git branch
- (로컬) COMMIT - 하나의 국면 안에서 세이브 파일 (ex. 적벽대전 3번째 턴)
- 커밋하기 : git commit -m "commit message"
- 커밋한 내용 확인하기 : git log
- 제일 마지막 커밋으로 돌아가기 :
- git reset --hard 수정사항 없애고 마지막 커밋으로 돌아가기
- git reset --soft 수정사항은 staging으로 옮기고 마지막 커밋으로 돌아가기
- 커밋으로 돌아가기 (세이브파일 로드하기)에 관하여 가장 자세히 설명하고 있는 블로그는 하단에. https://medium.com/@kwoncharles/git-%EC%9D%B4%EC%A0%84-commit%EC%9C%BC%EB%A1%9C-%EB%8F%8C%EC%95%84%EA%B0%80%EA%B8%B0-cf6caed43ed5
- (로컬) STAGING - 게임 플레이
- staging 상태 확인하기 : git status
- (로컬) WORKING DIRECTORY - 플레이 구상
- working space에서 staging으로 옮기기 : git add .
&& 참고 &&
- workingdirectory → (add) → staging → (commit) → repository
- workingdirectory ← (reset) ← staging ← (reset) ← repository
저장해야 하는 타이밍
하나의 기능구현이 끝났을 때 !
(그래서 단위를 작게 저장하고 커밋메세지는 자세할 수록 좋다.)
예시1) (브랜치 : 버전마다) - (커밋 : 기능마다)
예시2 ) (브랜치 : 버전마다) -(폴더 : 기능마다) - (커밋 : 더 작은 기능마다)
참고하면 좋은 자료 :
깃허브 페이지에서 어떻게 하면 좋은지에 대해 잘 설명한다.
깃허브를 통한 협업방법에 대해서 설명한다. (필자 = 1인개발자 = 혼자일함 = 협업모름 ㅠ)
반응형
'1인개발자' 카테고리의 다른 글
<1인 개발자로 살아남기> 28일차 (2) : 할 일 작성 (1) | 2024.01.08 |
---|---|
<1인 개발자로 살아남기> 28일차 : 지난 한 달 반성 및 계획작성 (0) | 2024.01.08 |
<1인 개발자로 살아남기> 17일차 : 사이트 런칭 계획 작성하기 (0) | 2023.12.28 |
<1인개발자로 살아남기> 15일차 : 웹개발 커리큘럼 1회독 (0) | 2023.12.28 |
VSC에서 플러터 실행 시, 홈화면에서 안 넘어가질 때 (flutter FAILURE: Build failed with an exception, no pubspec.yaml) (0) | 2023.12.22 |