Git, GitHub 그리고 Commit

Git 공식문서

https://git-scm.com/docs

Git 사용한 비즈니스 플로우

Gitflow :  https://techblog.woowahan.com/2553/

Github flow vs Gitflow : https://velog.io/@gmlstjq123/Git-Flow-VS-Github-Flow

Git 설치 (MAC)

1. 터미널 실행
2. brew intall git 입력
3. git ‒version 입력해 확인
4. Config 설정 (User Name / User Email 설정)

5.설치완료

Git 초기설정

로컬에서 사용할 Git 사용자 이메일과 이름을 설정한다. 이메일을 세상에 단 한가지만 존재할 수 있기때문에 효과적인 Identification 기호이다. 해당 설정을 바꾸면 git을 통해서 적용되는 commit들에 본인의 email이 tag된다. 

 

GIT config에 이름와 메일 초기설정하기

• git config : Git에 관한 설정을 추가/변경/삭제하는 명령어
  •  System 설정 파일 : 모든 시스템 사용자에게 적용 (git config --system) ; 컴퓨터 내 모든 사용자에 적용
  • Global 설정 파일 : 한 사용자의 전치 Git Repository에 적용 (git config --global) ; 컴퓨터 내 특정 사용자에 적용
  • Local 설정 파일 : 하나의 Repository에만 적용 (git config --local) ; 프로젝트 별로 적용
    • user.email "email@emial" : 유저의 이메일정보를 정의
    • user.name "name" : 유저의 이름정보를 정의
• git config --list : config정보를 나열하여 리스트로 출력한다.

 

GIT 초기화

GIT 초기화란 폴더 안의 문서를 Git으로 버전 및 이력관리를 하겠다는 선언이며 localRepository를 만드는 것이다.  Git 초기화 시 폴더 안에 숨김 폴더로 .git 폴더 생성함 (Local Config 등으로 구성). 만약, Git 관리를 삭제하고 싶으면 단순히 .git 폴더를 삭제하면된다. 

 

• CLI 명령어 : git init, 초기화 할 대상 폴더에서 명령어 (git init) 입력

• 폴더를 삭제하는 명령어 입력 : rm ‒rf .git

   

SSH key 생성하여 key로 Github연동하기

git문서에서 ssh key 공개키 생성하기 방법을 알려주고있다. 

 

https://git-scm.com/book/ko/v2/Git-%EC%84%9C%EB%B2%84-SSH-%EA%B3%B5%EA%B0%9C%ED%82%A4-%EB%A7%8C%EB%93%A4%EA%B8%B0

 

1. CLI : cd ~/.ssh : 홈 디렉토리의 ssh라는 숨김 디렉토리로 이동한다.

2. CLI : ssh-keygen : Mac CLI의 ssh key생성 명령어 실행하여 ID와 PW를 생성한다

3. CLI : cat ssh.pub파일경로 : ssh.pub의 공개키를 확인함

4. Github 접속 후 오른쪽 상단 프로필 클릭 Setting -> SSH and GPg Keys

5. New SSH Key 클릭해 Title과 복사한 Key 입력 후 Add SSH Key 클릭, 파일 내 전문 입력.

 

SSH란?

SSH, which stands for Secure Shell, is a cryptographic network protocol used for securely accessing and managing remote computers and servers over a network, typically the internet. 비대칭키 방식으로 클라이언트와 서버 간의 최초인증을 진행하고 있다. 서버와 클라이언트는 각자의 private key를 가지고 있고 public key를 교환한다. 이 비대칭적 암호는 암호화는 공개키를 통해서, 해독은 비공개키를 통해서 가능하다. 비대칭키 방식으로 최초 인증을 한 후에, 대칭키를 활용하여 서로 통신을 진행한다. 

 

• Private Key: This is kept secret and should never be shared. It stays on your local machine and is used to decrypt messages encrypted with your public key.
• Public Key: This key can be shared freely. It is placed on the remote server or service that you want to access.

 

Git 개념

용어정리

Working Directory :  OS 레벨에서 파일을 수정하고 편집하는 실제 폴더, 작업하는 파일이 있는 디렉토리. 
Staging Area : Git 내부의 영역으로, Git이 관리하는 가상 공간입니다. Staging Area는 커밋하기 전에 변경 사항을 모아두는 역할을 하며, 커밋할 준비가 된 파일을 올려두는 공간.
Local Repository : 로컬 Git 프로젝트의 메타데이터와 데이터 정보가 저장되는 영역. Local Branch와 Remote-Tracking Branches가 존재한다. Remote라고 표기되어있어도 Local Repository에 저장된 Remote Repository의 정보이므로 주기적으로 Fetch를 해야 최신으로 업데이트 된다.

Remote Repository : Github 등의 서비스를 통한 온라인 상의 저장소. 다른사람들이 코드를 사용하기 위해서는 remote까지 올라가야.

• origin : remote repository에 있는 코드
• head : 내가 지금작업하고있는 로컬브랜치
• commit :Add로 등록된 파일들을 한 덩어리로 만들고 메시지 추가해 Staging Area에 등록된 파일을 Local Storage로 등록
  • Commit Message : commit 시 함께 작성해 저장하는 메시지 (메모)
• push : Local Storage에서 변경된 파일들을 Remote Repository로 등록
• fetch : Local Repository의 Remote-Tracking Branches에 Remote Repository의 변경된 파일들 업데이트
• Pull : fetch + merge. Remote-Tracking Branches를 원격 저장소(Remote Repository)의 변경 사항을 업데이트 한 후에, 로컬 저장소(Local Repository)로 가져오는 작업입니다
• merge : 기존 로컬 브랜치에서의 작업사항을 원격 브랜치와 병합하는 것.
• Branch : 독립적으로 어떤 작업을 따로 진행하기위한 가지
• checkout : 여러브랜치가 있는 가운데 현재 사용할 다른 브랜치를 지정
• rebase : merge의 경우 각 branch의 history를 별도로 보관하지만 rebase는 각 branch의 history를 하나로 일괄 합친다.
• clone : git clone은 원격 저장소의 내용을 가져와 새로운 로컬 저장소를 생성하고, 기본 브랜치를 체크아웃하는 과정입니다.

 

clone/merge/pull의 차이 정리

• pull은 기본적으로  fetch와 merge를 합친 것임. 반면 clone은 로컬 브랜치를 새로 만들고 git repo에 있는 내용을 모두 이전하는 것.

 

 

 

Local Repository

파일이나 폴더를 저장하는 곳. Git저장소는 파일 전체를 저장하는 것이아니라 파일에서의 변경정만 이력별로 구분되어 저장. Snapshot (파일이나 폴더를 사진을 찍듯 순간의 상태를 저장한다.)기법을 사용. Local Repository 생성은 해당폴더에서 git init 명령어 입력으로 이루어진다.

 

Remote Repository
파일이 전용 서버(Github)에서 관리되며 여러 사람이 함께 공유

 

Branch

Git은 결국 코드의 변화를 하나의 Commit으로 관리하고 여러 Commit을 Branch로 관리하여 Review하고 rollback하는 어플리케이션이다. main에서 new Branch를 만듬으로써 기존의 N개의 Commit과 독립적인 M개의 Commit들이 생기고, new Branch를 Pull Request함으로써 M개의 코드만 집중적으로 Review를 받을 수 있다.

 

 Rebase

 Rebase takes your commits and replays them on top of another branch (Rewrites history) There is no merge commit; instead, the history is "rewritten" to show that feature-B was built on top of the latest main. Main과 feat을 각각의 branch로 commit을 독립적으로 관리하며 오직 merge commit만 접점으로 남기는 것이 아니라 feat의 모든 commit을 main으로 넘기는 작업으로 merge와 다르다. 

 

CherryPicking

Merge나 Rebase 행위 없이 다른 Branch의 특정 Commit을 내 Branch로 가져오는 행위. to take a specific commit from one branch and apply it to another. This is useful when you want to move specific changes (instead of the entire branch) to a different branch. 체리픽킹을 당한 브랜치에는 변화가 없다.

 

Stash

A stash is a way to temporarily save your uncommitted changes without committing them. Think of it like a temporary storage area where you can "shelve" your work if you need to switch branches or perform other Git operations without losing your progress.

 

A WIP (Work-in-Progress) PR is a pull request that is still under development and not yet ready for final review or merging. It's a way to signal to your team (or yourself, if you’re working solo) that the PR is not complete but provides a snapshot of the work in progress. Here’s how it’s useful and commonly used:

Commit Message 작성법

 

https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/

How to Write Better Git Commit Messages – A Step-By-Step Guide

why care?

  By writing good commits, you are simply future-proofing yourself. You could save yourself and/or coworkers hours of digging around while troubleshooting by providing that helpful description.

when to commit?

 

what to think? 

• Why have I made these changes?
• What effect have my changes made?
• Why was the change needed?
• What are the changes in reference to?

what to write? : Conventional Commits

• feat – a new feature is introduced with the changes
• fix – a bug fix has occurred
• chore – changes that do not relate to a fix or feature and don't modify src or test files (for example updating dependencies)
• refactor – refactored code that neither fixes a bug nor adds a feature
• docs – updates to documentation such as a the README or other markdown files
• style – changes that do not affect the meaning of the code, likely related to code formatting such as white-space, missing semi-colons, and so on.
• test – including new or correcting previous tests
• perf – performance improvements
• ci – continuous integration related
• build – changes that affect the build system or external dependencies
• revert – reverts a previous commit

 

Convention

• Hierarchical Naming Convention:  develop이라는 브랜치가 존재하면 develop~이라는 브랜치는 생성할 수 없다. 접두사가 겹치면 부모-자식 관계가 존재하는 것으로 오해할 수 있기때문

 

 

CLI에서의 Git 사용

 

GUI툴을 다운로드하여 사용하면 모든 것을 CLI로 운영할 필요가 없다. 더 직관적이고 이용이 편리하다. 다만, 서버컴퓨터를 다룰때는 CLI만 사용할 수 있어서 간단한 CLI는 인지하고 있어야한다.

• Cloning a Repository : git clone https://github.com/your-username/your-repo.git
• Fetch the Other Branches : git fetch --all
• Checkout the Other Branch : git checkout master

 

 

Intellij 에서의 Git 사용

 

Visual Cue

새로 추가후 VCS에 미등록 클래스 : DIR에서 붉은 색으로 표기

기존 클래스에 변화가 있음 : DIR에서 파란 색으로 표기

새로 추가된 코드라인 : 코드라인에 초록줄로 표기 (변경사항 전부 원복 가능)

 

코드라인우클릭 - Annotate with gitBlame : 각 코드별로 누가 언제 수정했는지 표기됨

Annotation with gitBlame - 더블클릭 : 각 코드가 언제 어떤 코드와 함께 Push되었는지 확인가능

 

Clone : file - new - projectFromVersionControl - URL 입력

 

 

 

 

GitHub에서의 Git 사용

Branch Merge : Branch가 생겼을 때 Pull Request를 통해서 변경점을 확인한 후에 두개의 Branch를 하나로 합치는 방법이 권장된다.

 

 

 

GitHub에서의 기타기능

Pull Request template : pull_request_template.md라는 파일을 생성하면 pull request를 생성할때마다 해당 포맷을 사용할 수 있게 해준다. 이는 default branch에 적용된 버전이 적용된다.

 

 

 

Stacked PR Strategy

A series of dependent branches (or "stacked branches") where each branch builds on the previous one, creating a "stack" of pull requests.