모두를 위한 깃 & 깃허브

#0.1 Requirements

git 홈페이지 - 다운로드 - 시작 - iterm / 명령프롬프트 - ’git -v’ 또는 ‘git -version’ ‘git —version’ 입력

github desktop 다운로드(64 bytes만 지원)

#0.2 What is Git and Github

git : 파일들을 트래킹하는 방식. version control system. open source(무료)

repository에 있는 모든 파일들을 트래킹함. 파일이 변경된 시점.

distributed version control system.

파일들을 binary code로 읽음(0 또는 1)

github : git파일과 git 변경사항들을 업로드하는 곳. git provider

#0.3 First Steps with Github Desktop

github desktop과 git의 차이

git : version control system

프로그래머를 위해 만들어짐

github: git을 사용하는 장소

git을 위해 graphic user interface를 만듦

버튼을 클릭하면 컴퓨터가 그 커맨드를 실행하게끔 모든 커맨드를 전부 버튼으로 만듦.

github desktop : git을 위한 make up

Repository 생성하는 방법

로그인 : git desktop - preferences - Git - 이름과 github에서 쓰는 이메일 입력

1. Clone a Repository from the internet. 인터넷에 있는 저장소(repository) 하나를 클론한다.
2. Create a New Repository on your Hard Drive : 하드드라이브에 저장소 하나를 만듦.
3. Add an Existing Repository from your Hard Drive : 이미 있는 저장소를 추가함.

2번 클릭 - Repository 이름 입력 - 설명 입력 - local path(repository 위치)

Github desktop은 local path를 아주 깊은 file path에 넣기 때문에 미리 폴더 이름을 변경해두어야 한다.

#1 BASIC GIT CONCEPTS

#1.0 Repositories

Repositories : 파일들이 있는 폴더. git이 파일들을 보고 있는 것.

.gitattributes : .으로 시작하는 파일은 유저에게 보이지 않음.

terminal - new terminal - ‘l’ 입력 - gitattributes, .git 폴더 확인

.git 안에 모든 git commands와 history가 들어있음.

.git을 지우면 변경사항을 저장하지 않음.

cd .git 입력 - .git이라는 폴더에 들어감.

code . - visual studio code로 확인

hello.txt파일 생성 - github desktop에서 확인할 수 있음.

tracking - 이 폴더에서 하는 모든 변경사항

#1.1 Commits

commit : 기록. point in time. git에 어떤 변경사항이 있을 때 record를 세팅

record를 set하고 싶을 때. 그 시간대를 git에 저장하고 싶을 경우

initial commit : git 파일와 함께 git repository 생성. github desktop이 자동으로 initial commit을 생성한다.(첫 commit)

git 데이터베이스에 변경사항을 저장하기 위해서는 먼저 commit에 title을 주어야 한다.

우리가 빌드하는 모든 변경사항들이 나타날때 제목을 적는다.

history - 변경된 파일과 내용 확인

commit하려면 제목은 필수이고 설명은 선택.

commit하고 나면 no local changes라고 표시된다. (repository에 Uncommitted changes가 없음)

#1.2 Areas

1. working directory(working area) :작업하는 곳
2. stating area : 모든 수정사항 파일이 commit된 것. 한 파일이 commit되면 기본값으로 Github desktop에서는 모든 파일들이 staging area로 바로 가게 된다.
3. repository area(commit area) : 파일이 commit되고 우리가 그 수정사항의 스냅샷을 가지고 있는것. (수정사항, 시간, 수정한 사람 등). data file의 변화가 git에 추가 되는 것.

#1.3 Branches part One

branches는 main 또는 master branches의 마지막 commit으로부터 다른 타임라인을 가지게 될 부분이다. 독립적으로 어떤 작업을 진행하기 위한 개념으로, 필요에 의해 만들어지는 각각의 branches는 다른 branches의 영향을 받지 않기 때문에, 여러 작업을 동시에 진행할 수 있습니다.

https://www.nobledesktop.com/learn/git/git-branches

ipsum 더미 텍스트

http://www.ipsum.com

#1.4 Branches part Two

master는 메인 branches 이름

branches는 마스터의 마지막 commit에서부터의 다른 타임라인.

branch out을 하면 시작점은 master의 마지막 시작점이 된다.

update from default branch - 다른 타임라인에서 변경사항을 업데이트. (동기화)

1. branch 분리. 새 branch 생성.
2. branch 업데이트. 동기화
3. merge into current branch - 다른 branch를 master와 동기화

#1.5 Conflicts in Branches

branch - compare 클릭(파일들에 conflics들이 있기 때문에 자동으로 merge 불가)

다른 lines를 바꾸면 conflict가 없다. 같은 lines을 바꾸면 conflict가 생겨난다.

current change : 현재 있는 branch

incoming change : merge하고 싶은 branch에서 가져온 것.

#2 GIBHUB

#2.0 Trying out Github

우리는 아직 github에 publish를 안했기 때문에 repositories들은 아직 local에 있다.

publish repository 클릭 - 로그인 - Github.com - repository 이름, 설명 입력

모든 변경사항 업로드

public / readme my default / gitignore - none

github 기본설정은 readme.md라는 파일을 읽어온다. (마크다운)

#2.1 Forking and Cloning

전체 repository를 내 계정으로 복사한다.

fork를 클릭하면 어디에 fork할 건지 물어본다. React의 경우 organization을 가지고 있지 않기 때문에 물어보지 않는다.

fork : 한 repository를 가지고 project를 가져와서 내 계정으로 복사하는 것. github의 기능

github desktop에 들어오게 하려면 github profile에 있는 모든 것을 어떻게 가져오는지, 그게 실제 파일들로 가져와서 수정할 수 있는지 알 수 있다.

facebook에서 업데이트하면 같은 product가 아니기 때문에 fork를 업데이트 해야 한다.

github desktop - current repository - add - clone repository

github에 있는 repository를 가져온 다음 clone. 내 desktop에 복사본을 만듦.

#2.2 Pull Requests

작업한 내용을 베이스 코드 저장소인 nomadcoders/git-practice 저장소에 추가 요청

Added username이라는 제목으로 commit하고 푸쉬

베이스 코드 저장소로 가서 그 저장소가 내가 작업한 저장소의 코드를 당겨올 수 있는지 요청

베이스 코드 저장소에서 New pull request 클릭

compare across forks 클릭 : branch 간에 비교하는 대신 fork 된 저장소와 비교하는 기능 사용

pull request 클릭

베이스 코드 저장소에서 merge pull request를 클릭하면 코드가 합쳐짐

(그게 아니라면 Close pull request)

#2.3 Origing and Upstream

fork 한 후 베이스 코드 저장소의 코드가 변경될 경우

github desktop - 베이스 저장소의 master branches / upstream branches 두가지가 있음

upstream branches는 베이스 저장소의 마스터 branches와 커뮤니케이션 하는 것.

fork하면 기본적으로 upstream branches가 만들어진다.

upstream branches를 통해 베이스 저장소의 변경사항을 요청받을 수 있다.

작업중인 프로젝트가 뒤쳐져 있고 베이스 저장소가 더 많이 작업이 된 최신코드라고 생각해보자.

다른 사람들이 전부 upstream에서 코드를 fork하고 있다. upstream은 베이스 저장소이다.

upstream branches를 통해 베이스 저장소의 최신 코드를 가져올 수 있다.

upstream branches에서 fetch를 할 수 있다.

Fetch origin 버튼 클릭 - 이 저장소의 origin은 serranoarevalo/git-practice이다.

Fetch origin을 클릭하면 upstream에서 fetch를 하게 된다.

그 다음에는 upstream의 코드를 현재 branches에 병합하면 된다.

둘다 master지만 하나는 upstream/master이고 하나는 그냥 master이다.

베이스 저장소에서 fork할 당시의 commit에서부터 베이스 저장소의 최신 commit까지를 master로 병합하는 것이다.

#2.4 Issues

github, gitlab, bitbucket 같은 제공자들이 제공하는 ‘이슈’ 기능

이슈는 프로젝트가 해야 하는데 아직 하지 않은 일이나 사람들이 발견한 문제나 버그 같은 것을 기록하는 것

오픈 소스에서 작업할 때 보거나 테스터들이 문제를 찾아서 이슈를 적을 때 볼 수 있다.

new issue 클릭 - 제목, 설명 입력 - submit new Issue 클릭 - close issue 가능

프로젝트 관리 시스템을 위한 것이다.

이슈를 만든 후 pull request를 만들 때 이 pull request는 저 이슈를 해결하기 위한 것이라고 하면 된다.

라벨들 달 수 있다. - 버그, 문서화 등

큰 회사에는 큰 저장소가 있고 많은 테스터들, 소프트웨어 관리자들, 기술 리더들이 이슈를 만든다.

그리고 그 이슈들 중 일부가 pull request로 해결된다. 그리고 그 이슈가 닫힌다.

사람들은 이렇게 깃을 이용해 서로 피드백을 주고 받는다. 이메일이나 슬랙, 회의를 통해 이야기 하는 것 보다 더 조직적이다. 이슈를 만들고 라벨을 잘 달면 된다.

잘 작업된 프로젝트 중에 expo가 있다.

이렇게 프로젝트를 관리하면 잘 관리할 수 있고 매니저들이 슬랙 같은 도구보다 git을 활용한다면 더 잘 관리할 수 있을 것이다.

github, gitlab, bitbucket에서 많은 사람들이 문제를 다루기 위해 이슈를 활용한다.

이슈, pull request는 git의 기능이 아니라 github의 기능이다.

큰 회사에서 일하거나 프로젝트를 관리하는 방법을 아는 것은 중요하다.

milestone은 버전을 올릴 때 필요한 것들을 모아두는 것이다. - 제목, 날짜, 설명

milestone 안에 많은 이슈를 생성할 수 있는데 그 이슈들이 모두 해결되면 마일스톤이 달성되는 것이다.

이슈를 각각 만들고 이슈를 닫을 때마다 마일스톤에 가까워진다고 알 수 있다.

#3.0 CLI log, commit, push

콘솔, 터미널에서 작업하기

mac os나 윈도우즈에서 작업한다면, VS Code에서 View 메뉴를 누르고 Terminal을 선택하면 된다.

mac이나 윈도우즈에서는 iterm이나 terminal을 직접 열 수도 있다.

터미널에서 내가 git이 설정된 디렉토리에 있으면, git 설정이 되어 있다고 알려준다.

위에서 했던 내용을 콘솔로 하는 방법

vscode에 있는 소스 컨트롤 관련 기능

vscode로 git을 사용하는 방법

vscode git버튼 파란색은 수정 초록색은 추가되었다는 뜻이다.

파일부분에 M 아이콘은 이 파일이 수정되었다는 뜻이고 U 아이콘은 untracked의 약자로 아직은 git이 이 파일을 관찰하지 않고 있다, git에 아직 등록되지 않았다는 뜻이다.

untracked 상태에서 commit을 해야 한다. 작업 영역(working area) 내에서 변경 사항을 알 수 있다.

stage 영역에 파일을 추가하는 방법

• 아이콘을 누르면 STAGED CHANGED라는 영역이 새로 생긴다. 여기에 있는 파일들이 commit하게 될 파일들이다.

콘솔과 github desktop을 사용하고 싶지 않다면 이 아이콘의 기능을 사용하면 된다.

파일 두 개를 모두 stage에 둔 상태에서 chapter_two 파일을 stage에서 제거하면 다시 untracked 상태로 바뀐다. 추가(+)하면 다시 추가됨 상태가 된다.

왼쪽 창에 Commit title을 적고 Commit버튼(체크표시)을 누른다.

파일의 commit 이력을 보는 방법(변경된 파일 미리보기는 불가)

origin으로 코드를 푸시하는 방법

터미널에서 git log 명령어를 입력

HEAD → master : 컴퓨터에 commit된 것.

origin/master : github의 코드 저장소에 올라간 commit.

github의 commit이 내 컴퓨터에 있는 commit보다 더 뒤에 있다.

git으로 작업할 때는 log를 보고 origin과 commit을 확인하면 된다.

origin에 방금 내가 commit한 changed title을 푸시한다.

이미 vscode에서 git commit을 했으니까 git push만 하면 된다.

git push origin master 엔터

push를 하고 싶은 곳은 origin(원격 코드 저장소)이고 push를 하고 싶은 branches는 master이다.

콘솔에서 코드를 업로드한다. github desktop이 뒤에서 보이지 않게 처리한 것이다.

clear 내용 지우기

commit 이력을 확인하는 방법

먼저 git log로 확인을 해보자 HEAD와 origin/master가 모두 같은 commit에 있다.

git log를 하고 나면 닫기버튼도 없고 창버튼도 없고 타이핑도 할 수 없고 스크롤만 할 수 있다.

q를 타이핑하면 된다.

stage 영역에 추가하는 방법

+버튼을 클릭해서 선택

git add chapter_two.txt (파일명을 적으면 그 파일만 stage 영역에 추가하는 것)

대부분의 경우에는 모든 파일을 추가한다.

파일 하나가 아니라 모든 파일들을 추가하는 방법

‘git add .’ 명령어 입력

.은 현재 폴더를 뜻한다.(현재 폴더에 있는 모든 파일 포함)

‘git commit -m’ 명령어 입력

다른 옵션들이 어떤게 있는지 궁금하다 - ‘git commit -help’ 명령어 입력

‘git commit -m “commit title”’ 명령어 입력

‘git push origin master’ 명령어 입력 - github에 새 commit 올리기

#3.1 Checkout and Hard Reset

콘솔에서는 항상 작업하는 디렉토리에 있어야 한다. 그래야 git이 잘 작동한다.

git이 아닌 디렉토리에서 git명령어들을 실행한다면 에러가 뜨거나 실행되지 않는다.

아니면 다른 git 디렉토리에 파일들이 추가되어서 원하지 않던 일들이 생길 수도 있다.

‘git log’ 명령어 입력

전에 작업한 문장이 마음에 들지 않을 경우 (이전 commit으로 되돌아가고 싶을 경우)

마지막 commit에 있는 내용은 이전 commit의 내용들이 다 합쳐진 것이다.(HEAD. 지금 시점의 파일이 있는 위치) 지금 이 git 폴더의 HEAD를 여기 changed title commit에 둔다고 생각해보자.

그럼 우리가 보게 되는 파일을 Changed title 까지 변경된 내용이다.

HEAD는 파일 정보가 어디 있는 지를 나타내는 것이다.

HEAD를 수정해서 과거로 옮기는 방법

git checkout 사용

commit ~~ 이부분을 복사한다.(commit의 별명 같은 것)

git checktout을 입력하고 commit 별명을 복사 붙여넣기 한 후에 엔터

지금 HEAD를 옮기는 상태에 있다. 둘러보고 commit을 만들 수 있다.

다른 branches에 영향을 주지 않고 commit을 삭제할 수 있다.

git log를 해서 보면 HEAD가 여기 Changed title에 있는 것을 확인할 수 있습니다.

origin/master는 보이지 않는다. 우리가 뒤로 돌아온 것이다.

checkout만 하고 실제로 과거 commit을 수정하지는 않았다.

‘git checkout master’ 명령어 입력 - 다시 현재 상태로 돌아올 수도 있다.

이 commit을 삭제하고 이전 commit으로 돌아가고 싶을 경우

1. ‘git checkout’ 명령어 입력
2. ‘git reset —hard HEAD^’ 명령어 입력 - 이 commit을 완전히 삭제

—hard는 삭제한다는 뜻이다. HEAD^는 HEAD에서 얼마나 멀리 갈 지를 나타내는 것.

1. ‘git reset —hard HEAD’ - 같은 장소에 있고 아무것도 reset하지 않은 것.
2. ‘git reset —hard HEAD^’ - 한 commit 이전으로 돌아가는 것.

원격저장소인 origin에 내가 원하지 않는 commit이 더 있다면 git push master --force로 강제로 푸시를 해야 한다. 코드 저장소로 가면 commit이 삭제된 것을 확인할 수 있다. (컴퓨터, 깃허브 둘 다)

1. git add . - 현재 폴더의 모든 파일을 stage에 추가한다.
2. git commit -m “commit title”로 commit한다.
3. git push origin master로 코드를 저장소에 푸시한다.
4. git reset - hard reset이 아닌 soft reset - ‘—hard’ 옵션을 입력하지 않음. git log를 보면 HEAD가 이전으로 돌아간 것이 보인다.

#3.2 Mixed Reset

이전에 한 git reset HEAD^는 하드 리셋도 아니고 소프트 리셋도 아닌 복합 리셋이다.

소프트 리셋이 하고 싶으면 —soft 옵션을 붙여야 하고 하드 리셋이 하고 싶으면 —hard 옵션을 붙여야 한다.

hard 옵션 : 리셋하는 파일들을 삭제하는 것이다. (완전히 과거로 돌아가는 것)

이전 commit에서는 ‘chapter_two 파일을 생성했다.

이전으로 돌아간다면 Changed title commit으로 돌아가게 된다. 변경사항들은 만들지 않은 것이 된다.

복합 리셋을 하면 파일의 상태가 untracked로 바뀐다.

복합리셋 : 방금 commit한 변경사항들을 다시 stage 영역으로 옮기는 것이다.

마지막 commit, 혹은 내가 선택한 commit에서 변경 사항들을 unstage 영역(작업 영역)으로 옮기는 것.

이 파일은 untracked 상태로 바뀌고 파일 변경만 한 상태와 같다.

commit은 돌아가지만 변경된 파일은 그대로 두는 것이다.

하드 리셋 : 이전 commit으로 돌아가고, 파일 변경 내역을 유지하지 않는다.

커밋에서 작업한 파일 변경 사항을 완전히 다 삭제하는 것.

아직 완료되지 않은 파일을 commit하는 실수를 한 경우에, 파일 변경 내용은 그대로 유지하고 싶다면 복합 리셋을 하면 된다.

커밋만 삭제하고 파일 변경 사항은 그대로 둔다. 변경 사항들을 unstaged 영역에 두는 것이다.

1. 파일을 계속 편집하고 그 후에 commit을 하면 된다.

2. 실수를 한 경우에 복합 리셋을 해서 파일 내용을 유지한 다음 파일 내용을 수정한다.

3. ‘git add’로 파일을 stage에 추가하고 ‘git -m “commit title”’로 commit한다.

   원격 저장소의 최종 상태와 컴퓨터의 최종 상태가 다르다. ‘git remote -v’ 로 원격 저장소를 확인해서 이동하면 commit 이력에서는 확인할 수 있지만 git log에는 없다.

4. origin에 있는 코드가 어떤지 확인하기 위해 git push origin master —force 대신에 git pull origin master를 실행한다.

   • git pull origin master를 실행하면 코드 변경 사항 충돌이 생긴다.

5. 충돌을 해결하기 위해 github 코드 저장소에 있는 내용이 아닌 origin에서 새로 입력 중인 내용으로 입력하고 Accept Current Change 버튼을 누른다.

6. ‘git commit -m “Commit title”’으로 이 변경 사항들을 반영해서 commit한다. - 변경되지 않은 파일이 있어 commit할 수 없다.

   • 병합 시 충돌 사항을 해결해서 ‘git add .’을 하고 다시 commit을 해야 한다. 또는 대부분의 경우에는 새로 고친 코드를 받기 위해 ’git push origin master —force’로 push한다.

   • 컴퓨터에서만 실수로 commit을 했다면 github의 코드를 병합할 필요는 없다.

7. git push origin master를 실행한다. - 전에 작업했던 내용은 사라진다. 새로 고침하고 변경 사항을 확인한다.

#3.3 Soft Reset

소프트 리셋은 이전 commit에서 변경한 내역을 unstage 영역에 두지 않기 때문에 복합 리셋과는 다르다.

1. ‘git push origin master’를 한 후 ‘giit reset HEAD^^’로 두 commit 이전으로 돌아간다.

2. ‘git reset HEAD^^ —soft’ 명령어 실행

   소프트 리셋은 되돌릴 commit의 변경 사항을 unstage 영역에 추가하지 않고 stage 영역에 추가하기 때문에 지금 작업하는 내용과 섞이지 않는다.

   unstage 영역에 작업 중인 파일이 있을 때 섞이지 않고 싶으면 소프트 리셋을 사용하면 된다.

   ‘git reset’ 명령어 입력 - 과거로 돌아가 모든 파일을 없애버린다.

   복합 리셋은 변경 내역을 unstage 영역에 두지만 소프트 리셋은 변경 내역을 stage 영역에 둔기 때문에 내가 지금 작업 중인 파일과 stage 영역에 있는 파일로 구분할 수 있다.

대부분의 경우 하드 리셋으로 되돌려서 다시 시작한다. 혹은 어느 영역에 저장되는지는 신경 쓰지 않기 때문에 복합 리셋을 하기도 한다.

만약 stage 영역에 추가하고 싶다면 복합 리셋을 한 후에 add로 추가를 한다.

대부분의 경우 하드 리셋이나 복합 리셋을 사용하면 된다.

그리고 파일을 수정한 후에 다시 파일을 추가하고 commit하면 된다.

복합 리셋은 commit을 되돌리고 변경된 내역을 unstage 영역에 저장한다.

#3.4 Checkout Branches

git log로 확인

이전 commit으로 돌아가서 branches를 만드는 방법

1. git checkout 뒤에 commit 별명을 붙여 넣는다.

   HEAD를 옮기는 상태이다. 둘러보고 파일을 변경하고 commit을 할 수 있다.

   다른 branches에 영향을 주지 않으면서 commit을 삭제할 수 있다.

2. README를 생성한 commit을 그대로 유지하고 싶다면 ‘git checkout master’ 명령어 입력 후 ‘git log’로 README를 생성하기 이전의 commit을 확인한다.

3. ‘git checkout commit 별명’ 하면 README 파일이 사라진다.(과거로 돌아옴)

4. 이 파일들을 유지하면서 새 branches를 만들고 싶다면 ‘git checkout -b branches명’ 을 입력하면 된다.

   github desktop에서 새 branches를 클릭할 때 이 명령어가 실행된다.

   이렇게 하면 branches가 새로 만들어진다.

5. ‘git checkout -b no_readme_branches’ 실행

6. ‘git log’로 확인해보면 branches로 이동해 있고 이전 commit들은 잘 남아있다.

7. 마스터 branches로 돌아가려면 ‘git checkout master’를 실행하면 된다.

8. master로 옮긴 후 ‘git log’로 확인해보면 README를 포함해서 마스터에서 작업했던 내용이 그대로 잘 남아있다.

9. ‘git branch’ 명령어 입력 - branches 목록, 현재 보고 있는 branches 확인

10. ‘git log’에서 commit 별명 복사하고 ‘git checked commit별명’ 실행하면 그 commit으로 돌아가게 된다.

11. ‘git checkout -b with_main’을 실행하면 이 지점에서 branches를 새로 만든다.

더 간단하게 하는 방법

1. ‘git checkout master’ - master로 돌아간다.

2. ‘git checkout commit별명 -b with_main’ 실행

   과거의 commit으로 checkout하는 것과 with_main branches로 이동하는 것을 한꺼번에 한 것이다.

3. ‘git branch’로 확인

   master에서 checkout과 branches 생성을 한번에 할 수 있다.

4. with_main branches를 github에 올리려면 ‘git push origin with_main’을 실행하면 된다.

#3.5 Amending Commits and Ignoring Files

branches 삭제하는 방법

‘git branch -d branch이름’ 명령어 입력

추가하는 것을 깜빡하고 잊은 파일을 commit에 추가, commit 메세지 수정하는 방법

1. 파일 내용을 변경하고 ‘git add .’ 명령어 입력 - 변경 사항을 git에 추가
2. ‘git commit -m “commit title”’ - commit
3. ‘git push origin master’ - github에 push
4. ‘git log’에서 commit 별명 복사
5. ‘git commit —amand’ 명령어 입력 - 커밋 수정(amend)으로 마지막 commit에 파일 추가 및 내용 수정
6. ‘git commit —amand -no-edit’ 옵션 추가 - commit 메세지 수정하지 않음.
7. ‘git push origin master’

git 여러가지 기능

1. ‘git status’ - commit할 때 파일들의 상태를 볼 수 있다. - 수정된 사항, stage에 있지 않은 파일은 빨간색으로 표시, 일일이 클릭할 필요 없이 변경된 사항을 확인하고 내가 커밋하게 될 파일을 확인할 수 있다.

2. ‘git add .’ - 현재 영역의 변경 사항 추가

3. ‘touch .gitignore’ 명령어 입력 - git에 추가하고 싶지 않은 파일이나 폴더를 .gitignore 파일에 입력하면 된다. git add .와 git status를 실행하면 파일이 보이지 않는다. 폴더에도 같은 기능을 적용할 수 있다.(/폴더명)

   git rn -r images/ —cached - stage 영역에 추가 된 파일 제거(캐시에서 삭제처리, -r은 폴더라서 붙인 옵션)

   올리지 말아야 할 파일을 깃헙에 올리고 나서 파일을 숨기고 싶을 때 git에서 파일을 삭제하고 파일명을 gitignore에 추가한 다음, git의 stage 영역이나 원격 저장소에 추가한 파일을 제거해야 한다.

#3.6 Origins

https://bitbucket.org/product/

bitbucket 사용법

bitbucket에서는 mercurial도 사용할 수 있지만 git을 사용할 것이다.

버전 컨트롤에는 git말고 mercurial, svn 같은 다른 것들도 있다.

1. repository를 만들고 url을 복사한다.
2. 복사한 url을 내 컴퓨터의 git에 추가해야 한다.

remote : 컴퓨터와 깃헙 사이의 커뮤니케이션

컴퓨터의 깃 저장소가 원격(remote) 저장소에 연결되어 있다는 뜻이다.

1. remote 목록을 보고싶으면 git remote -v를 실행하면 된다.
2. remote에는 origin이 있다. origin에 fetch와 push를 할 수 있다. (데이터를 올리거나 가져올 수 있다)
3. ‘git remote add 이름 복사한url’ - 이름을 origin이 아닌 다른 것으로 해야 한다.
4. ‘git remote -v’로 확인
5. 두 remote에서 모두 fetch와 push를 할 수 있다.
6. ‘git remote remove 이름‘ 명령어 입력 - 삭제
7. ‘git push 이름 master’ - 코드 push
8. 로그인할지 물어봄.
9. 저장소에 가서 새로 고침하면 확인할 수 있다.

Boards 메뉴에서 Trello와 동기화 할 수 있다. 프로젝트 관리에 Trello를 사용할 수 있다. 코드를 수정하면 카드가 움직이고 이걸로 사람들과 함께 프로젝트를 관리할 수 있다.

gitlab 사용법

https://about.gitlab.com/

프로젝트에 ssh key를 추가하지 않으면 pull이나 push를 할 수 없다.

1. 프로젝트 url 복사
2. ‘git remote add gitlab 복사한url’ 명령어 입력
3. ‘git remote —v’로 확인
4. ‘git push gitlab’
5. 로그인 - username/password
6. 저장소에 가서 새로고침

지속적 통합(CI) 기능이 잘 되어 있다. gitlab에 코드를 푸시할 때마다 테스트가 실행되고, 파이프라인을 설계하고 무언가를 압축할 수 있다.

#3.7 Clone

github desktop에서 했던 것 중에 예를 들어 facebook/react에 코드를 기여하고 싶다고 생각해보자. 이 저장소를 fork하고 github desktop에서 무언가를 하면 같이 협업할 수 있게 된다.

fork 한 후에 github desktop을 사용하지 않고 콘솔을 이용해 코드 저장소에서 코드를 가져오는 방법

1. 우선 저장소를 fork한다. (gitlab에 있는 코드 저장소를 fork하고 싶으면 gitlab으로 가야한다.)
2. fork한 저장소 url을 복사한다.
3. iterm / 명령프롬프트 - ‘git clone 복사한url’ 입력(내 fork저장소를 clone), react라는 이름의 폴더를 만들고 여기 있는 모든 파일들을 react 폴더에 복사해준다.
4. ‘git clone 복사한url 저장할폴더이름’ - 저장할 폴더 이름 변경
5. 내가 fork하지 않은 코드 저장소를 clone하면 파일을 내려받을 수는 있지만 작업한 내용을 업로드할 수 없다.
6. ‘code 폴더이름’ - 폴더 열기
7. 내용 수정 - ‘git add .’ - ‘git commit -m “commit title”’ (커밋) - ‘git push origin master’ (푸쉬)
8. fork한 저장소에 가서 새로고침 후 확인
9. Pull request 생성 가능

협업할 때 fork는 해야 하지만 github desktop을 사용할 필요는 없다. fork 한 후에 콘솔을 이용해 fork한 저장소를 clone하면 된다. 작업내용을 push하고 pull request를 만들면 된다. github desktop 보다 이런 방식으로 일하는 회사가 훨씬 더 많다.