Git 개인 작업 흐름 훈련

Git와 그 작업 절차는 처음에는 우리가 이해하기 어려울 수도 있다.
Git는 버전 제어 시스템으로 코드의 역사를 추적하고 관리할 수 있습니다.Github는 클라우드 기반 관리 서비스로 Git 저장소(Repo)를 관리합니다.
Git는 지점 모델을 기반으로 하고 대부분이 현지의 멋진 부분들이 있다.다른 한편, Github는 완전히 원격/클라우드를 바탕으로 서로 다른 사람들이 우리의 코드를 보고 복제하며 협업할 수 있도록 한다.

Git 및 Github 데이터 스트림 사용
Github 히스토리를 통해 원격 변경 사항을 저장하는 Git를 통한 시스템 및 관리 서비스 간의 상호 작용을 추적합니다.
간단히 말하자면, 지금부터 우리는 '로컬' 과 '원격' 키워드를 사용하여 우리의 로컬 기기와 원격 저장소/지점을 가리킬 것이다.
데이터는 두 가지 범주로 나눌 수 있습니다.
(a) 코드 파일과 그 내용과 같은 동적 실례 데이터
(b) 정적 메타데이터, 예를 들어 사용자 정보(또는 "git"데이터)가 있는 지점과 제출
높은 수준에서 우리는 우리의 데이터가 로컬 위치에서 원격 위치로 이동했다고 말할 수 있고, 반대로도 마찬가지다


개인 업무 프로세스 연습
지금 우리가 로컬에서 변경할 때 무슨 일이 일어날까요? 우리는 어떻게 이 점을 할 수 있습니까?git clone을 사용하여 원격 저장소를 복제한 후에는 Git의 로컬 지사 시스템에서 작업할 수 있습니다.git pull을 사용할 때 특정 지점의 복사본을 원격 저장소에서 로컬 작업공간으로 끌어오고 있습니다.원격 저장소가 변경되지 않은 경우 git pull에 "이미 최신"메시지가 표시됩니다.

user@ repo-name % git pull origin main
From github.com:adelinealmanzar/repo-name
 * branch            main       -> FETCH_HEAD
Already up to date.

현재 존재하는 로컬 지점과 일치하는 원격 지점 이름 git pull만 사용해야 합니다.
우리는 git branch을 통해 현재 우리가 있는 지점을 조회할 수 있다.

user@ repo-name % git branch
* master

당신의 주지나 줄기가 나무의 줄기라고 상상해 보세요.우리가 이 주간에서 만든 모든 지점은 거의 초고 지점과 같다. 왜냐하면 그들은 우리의 로컬 작업 구역에만 존재하고, 최종적으로 우리의 로컬 저장소에 들어가기 때문이다. 그곳에서 초고 지점들은 심사되고 편집될 것이다.git checkout -b any-new-branch-name에서 Primary/Primary 브랜치를 기반으로 새 로컬 브랜치를 생성하여 해당 브랜치로 이동합니다.

user@ repo-name % git checkout -b any-new-branch     
Switched to a new branch 'any-new-branch'

우리는 git branch을 다시 한 번 해서 우리가 새로운 지점에 있는지 검사할 수 있다

user@ repo-name % git branch
* any-new-branch
  master

우리의 새 지점은 최종적으로 제출을 통해 변경된 버전의 역사를 추적할 것입니다.그러나 정식 원격 저장소 기록을 제출하기 전에 인덱스에서 변경해야 합니다.우리는 git status을 통해 어떤 서류가 임시 저장되었는지 검사할 수 있다.git status에는 작업 디렉토리와 임시 저장 디렉토리에서 변경되거나 변경되지 않은 파일이 표시됩니다.
만약 우리가 어떤 파일도 변경하지 않았다면,git status를 실행하면, 우리에게 깨끗한 작업 트리가 있다는 것을 알려줄 것이다

user@ repo-name % git status
On branch any-new-branch
nothing to commit, working tree clean

코드 변경을 추가한 다음git 상태가 어떤지 봅시다.

user@ repo-name % git status
On branch any-new-branch
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   src/components/Header.js
        modified:   src/components/MainContainer.j

no changes added to commit (use "git add" and/or "git commit -a")

"파일에 대한 수정 사항은 작업공간 아래에 표시됩니다(""제출되지 않은 변경 사항""빨간색 이후).이 변경 사항을 색인에 추가하기 위해서 git add <file-name>을 실행해야 합니다.

user@ repo-name % git status
On branch any-new-branch
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   src/components/Header.js

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   src/components/MainContainer.js

git add은 작업공간에서 새로 또는 수정된 파일을 임시 저장소에 추가합니다("제출할 변경 사항"녹색 이후).git add에서 제출할 파일과 변경 사항을 선택할 수 있습니다.Github의 Git 가이드라인에 따르면 제출은 논리적이고 원자적인 변경 단원이어야 한다.기술팀은 일반적으로 그들의 조직/회사 실천의 논리 규칙에 따라 그들의 약속을 조직한다.하나의 예시 규칙은 제출마다 하나의 파일에 대한 모든 변경 사항을 포함해야 하거나, 제출마다 특정한 값을 보존해야 한다는 것이다.왜 제출을 위해 논리 규칙을 실현해야 합니까?깨끗한 제출 기록은 보통 읽기 쉽고 디버깅에 도움이 되며, 어떤 변경 사항이 최종적으로 복구되어야 하는지 이해하는 데 도움이 된다.
변경 사항을 단일 제출에 추가하고 이해하기 쉬운 제출 메시지를 만들려면 git commit -m "any commit message"을 실행합니다

user@ repo-name % git commit -m "perf: cleanup/removed debugging comments"
[any-new-branch 71a72da] perf: cleanup/removed debugging comments
 1 file changed, 1 insertion(+), 1 deletion(-)

메시지를 제출하려면 코드에 대한 변경 사항을 설명해야 합니다.위의 예시에서, 우리의 제출 메시지는 우리의 변경 사항은 더 이상 필요하지 않은sudo 코드를 삭제하는 파일 정리를 포함한다는 것을 보여 준다.perf 제목은 변경 사항이 삭제되었음을 나타냅니다.이 perf페이지는 우리가 제출 메시지에 추가할 수 있는 몇 가지 의미의 발표 페이지와 페이지 꼬리 중 하나로 코드에 대한 변경 형식 (추가, 삭제, 수정, 복구, 중단) 을 표시합니다.의미 제목에 대한 자세한 내용은 read more here을 참조하십시오.
변경 사항을 제출하면 git log에서 제출 기록을 확인하고 제출이 기록에 정확한 위치에 있는지 확인할 수 있습니다.로그 제출은 최신부터 최신까지 순서대로 배열되어 있기 때문에, 우리의 최신 제출은 맨 위에 있어야 합니다. 아래 코드에서 이 점을 볼 수 있습니다.

commit 71a72da43ca6cdd9774c8abf00a96fb3f6c6d0b9 (HEAD -> any-new-branch)
Author: Adeline Almanzar <[email protected]>
Date:   Sun Feb 13 11:31:50 2022 -0800

    perf: cleanup/removed debugging comments

commit 84c056344662503041c6fd3d5365f805dfca08e8 (master)
Author: Adeline Almanzar <[email protected]>
Date:   Mon Feb 7 20:38:54 2022 -0800

    third deliverable

로그의 각 커밋에는 커밋 ID, 작성자 정보, 커밋 날짜 및 시간, 커밋 메시지가 있습니다.
이제 변경 사항을 제출하고 건전성 검사를 마쳤습니다. 변경 작업 흐름을 계속 실행하고 변경 사항을 로컬 저장소에 제출할 수 있습니다.
로컬 저장소가 준비되면 팀 검토 및/또는 공동 작업을 통해 변경 사항을 원격 저장소로 푸시할 수 있습니다.

user@ repo-name % git push origin any-new-branch
Enumerating objects: 29, done.
Counting objects: 100% (29/29), done.
Delta compression using up to 8 threads
Compressing objects: 100% (28/28), done.
Writing objects: 100% (28/28), 286.05 KiB | 3.11 MiB/s, done.
Total 28 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:adelinealmanzar/repo-name.git
   84c0563..71a72da  any-new-branch -> any-new-branch

git push origin <branch-name>은 로컬 저장소의 모든 제출과 지점을 원격 저장소(Github)로 보냅니다.Github에 로그인하고 원격 저장소에 접근할 때, 새로운 pull 요청 (PR) 을 만들 수 있어야 합니다.우리는pull 요청을 하나의 표로 보고 우리 팀에 제출할 수 있으며, 우리의 변경 사항을 우리의 최초 지점의 원격 지점에 정식으로 통합할 것을 요청할 수 있습니다.PRs를 사용하면 코드 변경의 목적을 문외한으로 공유할 수 있습니다.또한 팀 구성원이 변경 사항을 검토하고 직접 변경할 수 있도록 합니다(공동 작업 흐름에 대한 다음 블로그 기사를 참조하십시오).

TLDR:개인 워크플로우 요약

git push: 원격 저장소의 클론/로컬 복제본을 만들어

으로 이동

git clone repo-link && cd repo-name: 현재 지점 보기 & 로컬 저장소의 모든 지점 보기

git branch: 원격 마스터 데이터를 로컬 마스터

으로 확장

git pull origin master: 새 로컬 브랜치를 생성하여 해당 브랜치

으로 이동

git checkout -b new-branch-name: 새로운 분기

이 올바른지 확인

코드 변경

git branch: 변경된 파일을 표시하고 파일이 임시로 저장되었는지 표시합니다(녹색 예 빨간색 아니요 표시).

git status: 파일 경로를 통해 파일을 임시 저장/인덱스 영역에 추가

git add filePath/wanting/toStage.txt: 선호하는 파일만 임시로 저장/인덱스

에 추가할지 확인

git status: 스냅샷은 현재 간단한 제출 및 쓰기 메시지

을 통해 변경 사항을 수행합니다.

git commit -m "any commit message": 최근 제출이 기록 목록의 맨 위에 있는지 확인하기 위해 제출 기록을 확인합니다.

git log: 로컬 신규 브랜치와 그 데이터를 원격 공간(Github)으로 푸시

Github에서 Pull Request 생성

git push origin new-branch: 현재 지점이 여전히 새로운 지점인지 확인

git branch: 끌어오기(로컬 새 지점으로) 원격 새 지점에서 추가할 수 있는 변경 사항

(a) 동일한 브랜치를 변경할 경우 6-12 단계를 반복합니다.
(b) 다른 분기를 변경하려면 5-12

단계를 반복합니다.

리소스:

Another git workflow & commands explanation

A git commands cheat sheet

Git Guides