쟈쟈의 코딩일기

오늘의 계획

1. 캐릭터 움직임 애니메이션

- 여유가 된다면 DOTween 활용해보기

2. onclick.AddListner()을 통해 버튼에 이벤트 할당하기

Button 컴포넌트 대신 AddListener를 이용하는 이유

Button 컴포넌트는 할당된 메서드가 visual studio에서 레퍼런스 참조가 안되고 미리 할당해놨기 때문에 유동적으로 버튼의 동작을 바꿀 수 없다. 이를 해결하기 위해 AddListener를 사용한다.

...할 예정이었는데 Git과 GitHub에 대해 강의를 듣고 팀원들과 맞춰보다가 하루를 보냈다.

Git이란?

VCS(Version Control System 버전을 관리하는 시스템) 중 하나
1. 형상[버전]관리
2. 협업을 위한 원격저장소
- 작업을 관리하고 공유하기에 용이하다.

Commit: 로컬에 저장[캡쳐]. 원격으로 올리는 것이 아닌 내 로컬에만 올린다.

- Amend: 제목 및 설명 수정

- Undo: 커밋 되돌리기

Discard: 수정사항 되돌리기

Stash: 수정사항 임시보관

Pull: 원격저장소로 커밋 올리기

Push: 원격저장소에서 커밋 받아오기

Checkout: 원하는 시간선으로 이동. 새 브랜치

2023.11.01 - [부트캠프] - Git과 GitHub 추가 설명

혹시 모를 사고를 방지하기 위해 Main이 아닌 Develope에 Branch를 따로 만들어서 작업하기로 했다. 따로 만든 Branch는 작업한 뒤, 삭제하고 다시 새로 만들어 작업하는 방식으로 Develope에 Merge(병합)하여 나중에 한 번에 Main에 합치는 방식이다.

Mac과 Window 간의 작업이라 그런지 오류도 자주 나고, 한 명씩 연습해보느라 시간이 조금 걸렸다.

나의 경우, 다른 파일에서 미리 작업한 것을 Export하여 새로 만든 공동 프로젝트에 Import 해서 수정했다.

소스 반영하는 법

1. remote add origin

원격저장소와 연결시킨다.

$ git remote add origin <원격저장소 주소>

로컬에서 원격 저장소의 이름과 경로를 등록한다.

모든 컴퓨터 자원들은 주소를 가지고 있기 때문에 목적지를 정확한 타겟팅을 해주어야 한다. 원격 저장소 주소 역시 마찬가지이다. origin은 저장소의 이름을 뜻한다. 실제로 원격 저장소를 활용할 때는 원격 저장소의 주소를 직접 입력하는 것이 아니라 

origin이라는 이름을 활용한다. 즉, 원격 저장소 이름과 주소가 매칭 되어있는 것이다. 깃허브(Github)에서 저장소를 만들고 등록하는 명령어가 바로 git remote add origin이다.

2. push

원격 저장소로 프로젝트를 push하면 깃허브에서 코드와 코드를 변경 했던 이력을 확인 할 수 있다.

$ git push -u origin <브랜치명>

원격 저장소의 로컬 소스를 실제로 반영한다.

최초에 push 작업을 하는 경우

$ git push -u origin main

위 코드의 main은 원격 저장소의 브랜치를 뜻한다. 즉, 같은 저장소 안에서도 다수의 브랜치를 병렬 작업 중인 소스를 관리 할 수 있으며 원격 저장소에도 동일하게 반영된다. push 뒤의 -u 옵션은 --set-upstream이라는 옵션을 축약해서 사용하는 것이다. 내가 위치한, 현재 작업하고 있는 브랜치와 origin 뒤의 원격 저장소에 있는 브랜치를 맵핑 해주는 역할을 한다.

나중에 push를 또다시 사용해야 할 때(수정하거나 변경되었거나 등) 전에 -u 옵션을 쓴 경우

$ git push

git push 명령어만으로도 원격 저장소에, 작업했던 브랜치에 push 작업을 수행 할 수 있다.

push 명령어가 바로 수행 안되는 이유

깃허브 원격 저장소의 경우에는 인증 받은 사용자, 인증 받은 Host(컴퓨터)만 push를 허용한다. 이전에는 다소 복잡한 방법으로 계정정보를 인증 했지만 현재는 git credential manager를 통해서 손쉽게 브라우저에 연동하여 로그인 정보를 가져올 수 있게 되었다. Windows는 깃을 설치하면 기본적으로 같이 설치 할 수 있는 옵션이 있는데 Mac은 수동으로 설치하여 따로 세팅해야한다.

협업하는 법

1. clone

원격 저장소에서 Local 환경(내 컴퓨터)에 가져와야한다.

$ git clone <원격저장소 주소>

깃허브 원격 저장소에 업로드 된 프로젝트를 가져오려면 저장소의 페이지에 들어가서 HTTPS에 나와있는 주소를 가져온다.

*깃으로 저장소가 되어있는 주소는 .git으로 끝나는 것이 특징이다. .git으로 끝나지 않으면 클론으로 불러올 수 없기 때문에 확인해보는 것이 좋다.

ZIP 파일을 다운 받아 쓰지 않는 이유는 Git Clone을 통해 프로젝트를 받으면 commit 이력이나 설정 정보들이 담긴 .git이라는 숨김폴더가 함께 포함되어 받아지지만 Download ZIP 파일로 프로젝트 파일을 받으면 .git 파일이 포함되지 않는다. 소스를 수정하는 것을 반영하기 위해 클론을 하는 것인데 단순히 파일만 받으면 수정을 반영 할 수 없기 때문에 협업에 적절하지 않다.

$ git clone https://github.com/[계정명]/[프로젝트명].git

명령어를 실행하면 프로젝트명의 폴더를 만들고 웹페이지에서 확인할 수 있었던 코드를 다운 받는다.

2. checkout

브랜치를 설정 할 수 있다. main이라는 중심 줄기에서 새로운 가지를 뻗어나가 나만의 작업공간 혹은 특정 기능을 만드는 기능이다.

$ git checkout -b <브랜치명>
$ git checkout <브랜치명>

최초에 브랜치를 할당 받으면 main에서 시작하는데 새로운 기능을 만들거나 수정 할 때는 main이 아닌 복사본을 만들어서 작업 후, test를 끝마치고 main에 합쳐주는 것이 일반적인 협업 과정이다.

$ git checkout -b feature-1

-b 옵션은 브랜치명을 입력했을 때, 신규로 만들면서 바로 그 브랜치로 이동 할 수 있다.

feature-1에서 작업하고 commit 후, 변경사항을 main으로 반영한다.

$ git commit -m "<message>"

feature-1에서 새로운 버전을 찍은 후

main과 합치기 위해 main으로 이동한다.

$ git checkout main

3. merge

main과 합치는 merge 작업을 해준다. 

$ git merge <브랜치명>

만약 서로 다른 브랜치의 같은 곳에 위치한 코드가 다르다면 병합이 실패하게 된다. 동일한 곳에서 소스가 달라서 conflict가 발생했기 때문이다.

남길 코드를 선택하고 HEAD와 feature-1 부분을 포함하여 모두 지운 뒤, 다시 commit하면 된다.

Local

우리가 사용하고 있는 각각의 컴퓨터. 즉, 자기 자신을 가리킨다.

Working Directory(폴더)

현재 작업 중인 프로젝트가 위치한 디렉토리

Staging

commit 할 파일의 예비 저장소

commit이란 소스가 변경되거나 새로 작성되면 local 저장소에 저장하는 액션을 말한다. 한 건의 commit으로 발생된 변경사항을 버전이라고 한다.

Local Repository

각 컴퓨터의 git이 관리하는 로컬 저장소

Working Directory로부터 commit한 내용들이 버전으로 저장되는 곳이다. commit이 된 순간의 파일과 내용들을 가지고 있기 때문에 언제든지 commit 했던 지점으로 돌아갈 수 있다.(복원 가능)

remote

Remote Repository - Github

github 등 외부에 위치한 원격 저장소

여러 명이 함께 소스를 수정하고 개발하기 위해 외부 저장소로 보낸다.

로컬 Git 저장소 생성

1. git 영역으로 초기화 수행

$ git init

깃(Git)에서 폴더 안에 있는 파일들에 대해 이력을 관리하기 위해서 init 명령을 통해 초기화 해야한다. 초기화가 되면 .git이라는 숨김 폴더가 생성되고 해당 폴더에 대한 모든 데이터가 저장된다.

*현재 깃을 초기화 하려는 경로가 내 프로젝트가 위치한 곳이 맞는지 확인. 위치가 올바르지 않은 경우, 불필요하거나 보안상 민감한 파일들이 깃의 관리영역에 포함 될 수 있다.

2. .gitignore 파일 추가

신분증이나 신용카드 번호 등 민감한 개인정보를 구글 드라이브나 Dropbox에 저장하는 것은 매우 위험한 행위이다. 시스템적으로 보안조치가 강하게 걸려있다고 하더라도 근본적으로 민감 정보는 외부 저장소에 저장하지 않는 것이 좋다.

소스 또한 마찬가지이다. 데이터베이스 계정이나 클라우드 시크릿 키, 각종 민감 정보는 저장소에 반영되어서는 안된다.

깃으로 초기화 된 폴더에 .gitegnore라는 파일을 만들고 깃에서 무시해야할 파일의 이름을 작성하면 폴더 내 해당 파일은 더이상 깃에 의해 탐지되지 않는다.

깃에서 일반적으로 무시하는 파일은 보안상 민감 정보, 각종 설정 파일, compile 언어들의 빌드 산출물, 개발용 데이터베이스 등 이다.

3. 파일 확인

$ git status

현재 어떤 파일들이 추적되고 있는지, 특히 Staging area에 어떤 파일들이 들어있는지 확인하는 명령어이다.

4. Staging Area 생성

나의 프로젝트 중 버전관리에 반영할 파일 지정한다. 버전관리에 반영된 파일의 영역이 Staging Area가 된다.

$ git add .
$ git add "<파일명>"

$ git add. 현재 위치에 있는 모든 파일들을 add 한다. *commit 되면 안되는 파일이 있는지 반드시 확인

$ git add "<파일명>" 특정 파일만 add 한다.

원치 않는 파일을 add 했을 경우

$ git rm/reset

5. commit 작업

Staging area에 있는 것들을 로컬 저장소에 변동 기록(버전)으로 관리 할 수 있도록 남기기 위해 commit을 실행한다.

$ git commit -m "<message>"

메세지를 입력하지 않으면 에러가 발생한다. 이 프로젝트, 혹은 수정 사항에 대해 문제가 생겼을 때 빠르게 대응 할 수 있도록 commit에 대한 정보를 기록한다.

6. branch(필수x)

$ git branch -M main

최신 버전의 깃에서는 기본 branch 이름이 main으로 정해져 있다.

branch란 동일한 저장소 내에 소스에 대해 서로 영향을 받지 않는 독립적인 공간이다. 여러 개발자들이 동시에 소스가 덮어씌워질 염려 없이 다양한 작업을 할 수 있도록 한다.

보통 크게 3가지 (혹은 이상)의 branch로 프로젝트가 관리된다.

• main / master

즉시 운영 배포할 수 있는 버전. 사용자가 지금 이용 중인 코드이다.

모든 작업상이 합쳐지는 곳이기 때문에 토이프로젝트 등 가벼운 코드가 아니라면 main에서 작업하는 것은 위험 할 수 있다. 깃에서 최초로 init 명령어로 초기화 했을 때 생성되는 기본 branch 명이다.

인종차별/주종관계를 드러내는 용어를 수정하는 문화가 프로그래밍 전반에 확산되면서 master가 아닌 main을 사용하게 되었다.

main -> master
master slave -> primary
blacklist whitelist -> blocklist allowlist

• stagging

상용에 반영하기 전 테스트 버전

• feature

새로운 기능 추가 개발. 서로 꼬이지 않도록 병렬 작업 한다.

Git & Github의 등장

개발을 진행하다 보면 HTML, CSS, Python, Java 등 수많은 파일들을 맞닥뜨리게 된다.

파일을 수정하거나 다수의 공동 작업을 하면 파일이 복잡해지고 누가 작업한지 알 수 없게 된다. 웹 서비스는 다양한 파일이 유기적으로 결합된 서비스이다. 우리가 사용하는 파일 시스템으로는 안정적이고 일관성 있는 관리가 쉽지 않다.

SCM(Source Code Management)

저장소와 저장된 소스의 변경 사항과 작업자를 추적 가능

현재 소스 코드 관리(SCM)가 활용되는 대표적인 도구는 깃 & 깃허브(Git & GitHub)이다.

Git

소스 이력 추적을 위한 버전 관리 시스템

수정된 내용을 반영하면 버전별로 누가 반영했는지 관리해주는 SCM의 구현체이다.

Github

git 프로젝트를 관리하는 저장소 제공

현재 수많은 서비스들이 Github 저장소에 업로드 되어있으며, 오픈소스 프로젝트를 자유롭게 수정해서 재배포 할 수 있다.