Git

유요한·2022년 11월 23일
gitgithub
1

Git

목록 보기
1/2
post-thumbnail

Git이란?

Git은 소스 코드 버전 관리 시스템 나중에 현업 개발자로 실무에 투입되어 깃랩(GitLab) 또는 깃허브(GitHub)를 사용하게 되는 경우 커밋 메시지를 자세하게 (누가봐도 어떤 파일에 대한 커밋인지 알 수 있도록) 적는 것이 중요하다. 귀찮더라도 커밋 메시지를 잘 적는 습관을 들이는 것이 좋다.

Git이란 우리가 작업하는 파일의 모든 변화를 기록하는 시스템이다.
여기서 모든 것이란 누가 언제 어떤 파일 어떤 부분을 어떻게 했는가이다.
(지운 것도 포함)

  • Github, Gitlab
    Git의 인터페이스를 제공, 다양한 기능을 통한 편의성 제공

버전 관리 시스템 종류

1. 클라이언트 - 서버 모델

하나의 중앙 서버에서 여러 클라이언트들이 각자 필요한 데이터만 가져와 작업하고 다시 중앙으로 통합

2. 분산 모델

하나의 중앙 서버 존재, 그러나 여러 클라이언트(개발자)들이 각자의 컴퓨터에 복사본을 가지고 와서 작업 후 저장

→ 차이점은 클라이언트-서버모델 중앙 서버가 사라지면 모두 사라짐 그러나 분산모델은 각 개발자들이 코드를 가지고 있기 때문에 중앙서버가 사라져도 코드 손실의 위험이 적다.

Git을 사용하는 이유

1. 파일의 버전관리
소프트웨어에는 버전관리가 필요하다. 꼭 클라이언트 요청이 없더라도, 버전별로 이전 버전의 기능을 다시 가져올 수도 있고 누군가 잘못된 코드를 섞으면 복원해야될 때가 있다. 이럴때 필요한 것이 버전관리를 위한 툴, Git이다.

2. 다른 개발자와 협업
보통 여러명의 개발자와 협업을 하는데 개발자들이 각각 맡은 파트를 가져가서 작업하고 합치기 때문에 실시간으로 작업내역을 공유할 수 있는 원격 저장소가 필요하다. 이때 필요한 것이 협업을 위한 저장소 Github이다.

git의 장점

  1. 협업하는 개발자들끼리 소스코드를 주고 받을 필요가 없음
  2. 같은 파일을 여러명이 동시에 병렬 개발 가능
  3. 변동 과정을 체계적으로 관리할 수 있음(업데이트 히스토리 확인, 이전 버전 백업)
  4. 중앙 서버 데이터 유실 쉽게 복구 가능

git 설치

Git 운영법(GitFlow)

작업의 흐름

로컬 저장소는 git이 관리하는 세 그루의 나무로 구성되어 있다.

첫번째 나무인 작업 디렉토리(Working directory)는 실제 파일들로 이루어져 있다.
두번째 나무인 인덱스(Index)는 준비 영역(staging area)의 역할을 한다.
마지막 나무인 HEAD는 최종 확정본(commit)을 나타낸다.

Fork

내 개인 레퍼지토리 저장공간에 다른 레퍼지토리를 가지고 와서 작업, 사용법이 까다로움, fork를 해온 순간 내 레퍼지토리와 실제 레퍼지토리의 버전을 동기화

1. branch

나뭇가지, 나무에서 여러 갈래로 뻗은 줄기
하나의 배포중인 서비스 ← 나무
그리고 branch라고 하는 것은 특정 기능을 개발하거나 버그를 수정하거나 할 때 또 하나의 길을 만들어내는 것

branch 만들기

  1. 어떤 branch가 있는지 확인

git branch

  • 현재 사용하고있는 branch는 master.
  • 모든 branch를 *로 나타내고 그 중 현재 사용중인 branch를 초록색으로 보여준다.
  1. branch 만들기
 	git branch (`원하는 branch명`)
  1. 만든 branch 사용하기
    	git checkout (`만들어져있는 branch명`)

branch 만들고 switch하는 과정

branch 이름 변경

branch 생성과 체크아웃

branch 이동하기

branch 상태에서 push, pull 하기

push

  1. 임의로 README에 데이터 추가
  2. add, commit, push 하기

    이 때 add, commit은 동일한 방식 사용
    push는 맨 처음 할 때는

    	git push --set-upstream origin branch명

    를 사용해야 그 뒤부터는 그냥 push로 하면된다!

pull

branch상태에서 pull하기

	git pull origin main

master/main 상태에서 pull 하기

	git pull

branch 관리

branch 삭제

branch 병합

병합은 2가지 종류가 있다.

  1. fast-forward 방식
    빨기 감기 방식이다. 병합하려는 브런치의 현재 상태로 그대로 같은 위치로 이동하는 것이다.
  1. non-fast-forward 방식
    merge하려는 브런치와는 별개로 다른 버전을 만들어 새로운 병합본을 만든다.

가지(branch)치기

  • 가지는 안전하게 격리된 상태에서 무언가를 만들 때 사용한다.
  • 저장소를 새로 만들면 기본으로 master 가지가 만들어진다.
  • 이제 다른 가지를 이용해서 개발을 진행하고, 나중에 개발이 완료되면
    master가지로 돌아와 병합하면 된다.

git이 한 기록을 토대로 우리는 파일을 언제든지, 얼마든지 복구할 수 있다.
언제든지란 옛날버전을 불러올 수 있다는 뜻.
'얼마든지'란 권한을 가진 여러 개발자들이 같은 파일을 받아 각자 개발할 수 있다는 뜻.

→ 이렇게 나뉘는 걸 나뭇가지와 닮았다는 뜻에서 branch라 한다.
또한 변화된 부분만을 적용시켜 분산된 버전을 합치는 것도 가능하다.↓

2. add/commit

add. 스테이징, 깃에서 수정된 파일을 보내기 전에 준비
commit 깃에 파일을 보내는 것

git add <파일 이름>

위에서 생성한 README.md 파일을 git add 명령어를 통해 Staging Area 로 보내자.

   git add * : 새로 생성한 모든 파일을 Staging Area 로 보냄.
   git add 파일명 : 해당 파일명을 Staging Area 로 보냄.

이것이 바로 git의 기본 작업 흐름에서 첫 단계에 해당된다.
하지만 실제로 변경 내용을 확정하려면 아래 명령을 내려야 한다.

스테이징 영역(Staging Area):

작업 내역을 바로 Commit 하여 로컬 저장소에 저장하지 않고, 스테이징 영역에 저장했다가 Commit을 하는 이유는 스테이징 영역에서 작업 내용을 한 번 더 확인하여 선별적으로 로컬 저장소에 반영하기 위함이다. 이렇게 하면 시간은 더 소요되지만 좀 더 안정된 버전 관리 작업이 가능해진다.

git commit 컨벤션

git에 올릴 코드를 스테이징하고 커밋을 할 시 커밋의 상태를 나타내는 메시지를 함께 전달

ex)

  • Feat : 새로운 기능 추가

    feat : 로그인 기능 추가, [Feat] 로그인 기능 추가, [Add] 로그인 기능 추가

  • Fix : 버그 수정
  • Docs : 문서 수정
  • Style : 코드 포멧팅(코드의 스타일 수정, 코드 변경은 없어야 한다.)
  • Refactor : 코드 리펙토링
  • Test : 테스트 단위/코드 추가, 테스트 리팩토링
  • Chore : 패키지 매니저, 빌드 수정, 빌드 태스크 업데이트, 패키지 매니저 설정
  • Rename : 파일 혹은 폴더명을 수정하는 경우
  • Remove : 사용하지 않는 파일 혹은 폴더를 삭제하는 경우

여기까지는 commit할 때 제목에 들어갈 부분 즉, 헤더에 들어갈 부분입니다. git commit -m "[Feat] login추가" 이렇게 작성할 수 있지만 git commit을 해서 header, body, footer을 작성해서 자세히 commit을 나타내는 방법이 있습니다. 즉, 내가 작성한 코드를 설명해주는 것입니다.

하는 방법
1. git commit
2. 이제 작성하면 되는데 작성하는 방법은 다음과 같습니다. 다 작성하고 나면 esc → :wq(저장 + 창 닫기)를 하면 됩니다. 그리고 이 commit을 수정하려면 git commit --amend를 하면 가장 마지막에 commit한 내용을 수정할 수 있습니다.

제목은 어떻게 작성하는가

타입은 태그와 제목으로 구성되고, 태그는 영어로 쓰되 첫 문자는 대문자로 합니다.

"태그: 제목" 형태이며, :뒤에만 공백이 있다.

본문은 어떻게 작성하는가

꼬리말은 어떻게 작성하는가

3. push/pull

push : commit된 파일을 git에 있는 저장소(레퍼지토리)에 등록
pull : 업데이트 된 git 저장소의 코드(파일)을 내 파일에 가지고 오는 것(적용) 현재 배포된 버전과 내 컴퓨터에 존재하는 내 버전과 맞추는 것

pull

다른 팀원이 개발한 내역이 있어 원격 저장소의 작업 내역이 나의 로컬의 작업내역과 다를 때는 내 변경사항을 원격저장소에 업로드(Push)하면 충돌이 발생한다. 이럴 때는 원격저장소의 변경사항과 나의 로컬저장소의 간격을 없애야한다. 즉, 원격저장소의 최신 변경사항으로 맞추어야 내 로컬 변경사항을 업로드할 수 있다. 이를 위한 명령어가 fetch와 pull이다.

즉, git pull은 git fetch하고 git merge까지 해준다고 볼 수 있다.

git pull origin main
깃에 업데이트 된 내용을 내려받는 것
에러를 막기 위해 보통 push전 항상 pull을 받고 진행

4. pull request(pr)

허락, merge 실행 시 데이터가 바로 적용되는 것이 아니라 pull request에 등록하고 request에 등록된 사항을 허용 해주어야 기본 branch에 push가 되는 현상. 간단히 말하자면 코드를 수정했으니 컨펌좀 해주세요~

Git은 덮어쓰는 형식이 아니라 달라진 부분을 수정하는 방식이다.

merge 실행 시 데이터가 바로 적용되는 것이 아니라 pull request에 등록하고 request에 등록된 사항을 허용 해주어야 기본 branch에 push가 되는 현상

회사마다 다르겠지만 보통 branch에서 작업이 다끝나고 통과가 되면 에러가 발생하지 않는다. 그래서 작업이 다끝날때마다 PR을 날려준다.

pull request 날리기

pull request 작성하기


5. merge

새로 만들어지는 브런치와 기본 브런치를 합치는 것
dev branch를 가지고 기능을 추가하고 합치고 에러가 생기나 테스트를 해본다음 문제가 없으면 main/master에 합쳐주는것이 merge다.

issue tracker

개발 시 발생되는 버그와 논쟁, 논점(개발자끼리의 논쟁) 이러한 이슈들을 기록하고 해당 이슈가 되면 이슈를 닫음으로서 (닫힌 이슈는 히스토리에서 확인이 가능)

이슈 등록 시 이슈에 대한 내용과 앞에 번호를 붙여서 만들어줌
ex) 사용자 데이터를 받아왔으나 .... map is not function ... #10

해당 이슈가 되면 커밋 메시지

  • close
  • closed
  • fix
  • fixed
  • resolve

라는 깃 컨벤션과 앞에 이슈 번호를 붙여서 커밋
ex) close #10

Git 버전 되돌리기

Git 저장소에서 코딩을 하다보면 커밋을 아예 취소하거나(git reset), 커밋 내용을 되돌리거나(git revert), 기존 커밋을 덮어써야하는(--amend) 상황이 종종 발생합니다.

다음 명령어를 입력하면 commit이력을 확인할 수 있다.

git reset(커밋 취소하기)

아직 원격 저장소에 push하기 전이라면 reset을 사용할 수 있다. 작업을 하고 add or commit을 했는데 취소해야 하는 상황이 생길 수 있다. 그 때 되돌리기 원하는 만큼 옵션을 지정하여 git reset 명령어를 사용하여 되돌릴 수 있다.

  • git reset --hard
    돌아가려는 커밋 이후의 모든 내용을 지워 버린다. staging area와 working directory 모두 돌아가려는 커밋과 동일해진다. hard 옵션을 사용하면 돌아간 커밋 이후의 변경 이력은 모두 삭제합니다.

97f1e31 -> d678197 -> 12741e5 차례로 커밋을 했습니다.
이 때 마지막 커밋 12741e5을 취소하고 싶습니다. 이 때는 git reset --hard <COMMIT_ID> 명령어로 HEAD가 이전 커밋(d678197)을 가리키도록 합니다.


위처럼 실행할 경우 2, 3번 커밋 반영 내용은 모두 사라집니다. 물론 코드도 날라간다.

  • git reset --soft
    돌아가려는 커밋으로 되돌아가고, HEAD가 돌아가려는 커밋을 새롭게 가리키게 됩니다. staging area와 working directory는 아무런 변화도 없다. 변경 이력은 모두 삭제하지만 변경 내용은 남아있습니다. 그러나 stage 되어있습니다.


add명령어 필요없이 바로 commit 진행 가능합니다.

  • git reset --mixed
    변경 이력은 모두 삭제하지만 변경 내용은 남아있습니다.


위처럼 실행할 경우 이력은 날아가나 unStage 상태로 코드는 남아있습니다. 코드를 반영하려면 add 명령어로 stage에 반영하고 commit 합니다.

커밋과 푸쉬 작업중에 에러현상이 벌어졌을 경우(충돌)의 경우 해당 상태의 커밋이나 스테이징을 취소하거나 수정하기 위해 사용합니다.

git revert(커밋 내용 되돌리기)

이미 원격 저장소에 push한 상태라면 reset은 사용할 수 없고 revert를 사용해야 한다. git reset은 HEAD 위치를 바꿔버려서, 로컬 저장소의 상태를 커밋 이전 상태로 강제 변경해버립니다. 하지만 커밋을 협업중인 원격 저장소에 push해버린 경우, 로컬 저장소에서 커밋을 취소해버리면 원격 저장소와 상태가 틀어져버립니다. 특히 원격 저장소에서 force push를 금지하는 경우, 로컬 저장소의 변경사항을 push할 수 없게 되어버립니다. 이런 경우에는 git revert로 특정 커밋의 내용을 되돌리는 커밋을 하는 방법을 사용해야합니다.

97f1e31 -> d678197 -> 12741e5 차례로 커밋을 했습니다.
12741e5를 취소해서 커밋을 되돌려야할 경우

git log 찍고, 커밋이 다음의 commit1>2>3의 순서로 발생했다고 해보자.
오른쪽에 뜨는 것이 git hash이다.

내가 돌아가려는 커밋이 commit1이면, commit3를 먼저 revert하고 이후 commit2를 revert하는 방식으로 순차적으로 진행해야 한다.

이후 commit을 하면 끝이다.

git commit -amend(커밋 덮어쓰기)

커밋의 내용을 덮어쓸 때는 git commit의 amend 옵션을 사용합니다. 수정할 내용을 스테이징에 반영하고 다음 명령어를 실행해줍니다.

메시지 옵션을 사용하지 않으면 커밋 메시지 작성을 위한 에디터가 실행되고, 메시지를 작성 후 저장해줍니다.

amend의 옵션의 경우 스테이징에 추가된 내용을 반영해주는 동시에 커밋 메시지도 변경해줍니다. 따라서 변경할 내용이 없을 때도 커밋메시지를 변경하고 싶을 때 자주 사용합니다.

Git 저장소에 포함되지 않은 파일 삭제

git clean

Git을 사용해 소스코드를 관리하다 보면 변경 사항과 관련된 여러가지 작업을 해야하는 상황이 생깁니다. Git에서는 파일들을 크게 저장소에 포함된 커밋된 파일들과, 저장소에 포함될 예정인 스테이징 상태의 파일, 그리고 저장소에 포함되지 않은 파일들로 나눌 수 있습니다. 저장소에 포함되지 않은 파일들은 추적되지 않는(Untracked) 상태의 파일이라고 하며, 아직 저장소에서 관리하는 대상이 아닙니다. git status 명령어를 사용하면 추적되지 않는 파일들도 함께 알려줍니다. 나중에 커밋하거나 수정하기 위한 용도로 남겨둘 수도 있지만, 필요없는 파일들이 저장소 디렉터리에 포함된 경우 git clean 명령어로 한꺼번에 삭제해버릴 수도 있습니다.

Git으로 처음 코드 업로드

  1. 터미널 경로 명령어

cd 경로 → 해당 경로로 이동 (폴더명 → 하위폴더, 절대경로 → 절대경로)
cd .. → 경로 상위 폴더 이동

  1. 초기화

깃 올릴 폴더인것을 알려주는 명령어
숨김 폴더로 .git이라는 폴더가 생성

	git init
→ 새로운 git 저장소가 만들어진다.
→ git 폴더 생성 (터미널 경로 => cd.., cd 경로)

.gitignore
깃허브에 올리고 싶지 않은 파일을 정의


이렇게 하면 html 확장자인 것은 모두 안올린다는 뜻이다.
gitignore을 쓰는 이유는 보안정책상 올리면 안되는 것(데이타베이스 등)을 git에 올려주면 안되기 때문에 gitignore을 통해서 무시를 시켜줘서 안올라가게 해주는 것이다.

  1. Github repository랑 내 로컬 프로젝트랑 연결

예시

git remote add origin https://github.com/YuYoHan/Javascript.git

이 명령어는 github에서 복사해서 붙여와야 한다.

  1. 상태 확인(선택사항)
	git status


이런식으로 나온다.

  1. 추가할 파일 더하기
	git add .
→ 여기서 .은 모든 파일이라는 뜻이다.
  선택적으로 올리고 싶으면 add뒤에 파일 이름을 붙여주면 된다.
  
  ex)
  git add index.html
  1. 히스토리 만들기
	git commit -m "first commit"
→ -m은 메세지의 준말로 뒤에 ""안에 주고 싶은 히스토리 이름을 주면 된다.	
→ 커밋 메시지 [subject], [body], footer
→ 커밋 컨벤션

ex)
git commit -m "[Style] modify style index.html" -m "index.html의 login기능의 css를 수정하였습니다.
git commit -m "style: modify style index.html" -m "index.html의 login기능의 css를 수정하였습니다.

  1. 잘 연결되었는지 확인(선택)
	git remote -v

내가 연결한 주소값이 잘 뜨면 성공!🎇

  1. github으로 올리기
	git push origin main

main 자리에는 branch이름이 들어가면 됨 branch이름이 main라하면 git push origin main 이라고 써야함


이런 오류가 발생하면 두가지 원인이 있다.


다만 이 방법을 사용하면 커밋했던 코드를 날려버릴 수 있다.

Git으로 계속 업데이트 🤹‍♂️

  1. 추가할 파일 더하기
	git add .
  1. 히스토리 만들기
	git commit -m "first commit"
  1. Github로 올리기
	git push origin master

내 컴퓨터에 소스코드를 업데이트를 하고 싶으면 이 세개의 스텝만 계속 반복하면 됨.

Git으로 협업 하는법 👨‍👩‍👧‍👦

1. 함께 쓸 저장소를 만들고 초대하기


레포지토리에 들어가서 Settings로 들어간다.

그러면 Collaborators를 확인할 수 있는데 클릭을하면 비밀번호를 치라고 나온다. github 비밀번호를 친다면 초대를 할 수 있다.

이 버튼을 클릭하고 github아이디를 친다면 초대장이 가지는 것이다.
초대를 받으면 다음과 같이 뜬다.

2. Git 작업


먼저, git에 배포할 main브랜치에 readme.md파일 하나 만들어야 한다. 즉, 프로젝트 레포지토리를 만들 때readme.md를 추가해야 한다. 해당 레포지토리를 클론해서 만들 branch에 push해줘야 한다. 이 방법은 레포지토리를 팀원에게 공유하는 것이 아니라 아직 프로젝트를 만들기전에 다른 branch로 옮기고 작업하기 위한 것이다.

git으로 올려주기

  1. git init

  2. git remote add origin 주소

  3. git branch "브랜치이름"
    이제는 branch를 생성해줘야 한다. main에서 다 올리면 파일이 꼬일 수 있기 때문이다.

  4. git checkout "브랜치이름"

  5. git add .

  6. git commit -m " "

git push origin <가지 이름>

새로 만든 가지를 원격 저장소로 전송하기 전까지는 다른 사람들은 접근x

이제 해당 branch로 가준다.

branch 관리

feature : 기능을 구현을 담당한다.
→ 프로젝트의 기능을 구현하거나 view단을 만들고 할 때 여기서 만들어준다.
예를들어, 로그인 기능을 만들어 줬으면 [feature] login 이런식으로 기능을 구현해준다.

develop : 개발을 진행하는 branch
→ feature에서 기능을 구현할 때마다 여기 branch에서 merge로 합쳐주고 여기서 해당 기능을 다듬어 준다. 여기서 해당 기능을 전부 다듬어준다면 release branch로 보내준다.

release : 배포하기 위해 준비하는 브랜치
브랜치명을 release-1 같은 방식으로 지정해주고 여기서 테스트를 해주고 버그가 있다면 수정을 해주고 배포준비를 완료한다. 그리고 여기서 완료된 코드를 develop에도 push해주고 main에도 push해준다.

hotfix : 배포된 소스에서 버그가 발생하면 생성되는 브랜치
release에서 놓친 버그가 있어서 배포후에 버그를 발견하면 여기서 수정해준다. 수정이 완료되면 develop, release, main에 수정 사항을 반영해준다.

※요약
feature은 기능을 구현하는 브랜치로 feature에서 기능을 만들고 add . / commit을 해주고 add / commit을 적용해야할 브랜치로 이동해서 merge를 시켜준다는 것이다. git checkout develop로 가준다음 git merge feature으로 머지 진행을 해준다. 그러면 feature에서 만든 코드가 develop에 commit이 된것이다. git pull(원본과 동기화) 그리고 push를 해준다(수정 사항 적용). 이런식으로 진행하다 완성이 되면 안쓰는 branch는 삭제해준다.

Git 클론하기(이미 만들여져 있는 저장소 함께 쓰기) - 팀원


그리고 Git clone을 해준다. (자동으로 remote연결)

저장소 받아오기

● 로컬 저장소를 복제(clone)하려면 아래 명령을 실행
	git clone / 로컬 / 저장소 / 경로
● 원격 서버의 저장소를 복제하려면 아래 명령을 실행
	git clone 사용자명@호스트:/원격/저장소/경로

Github에서 저장소 내려받기(Clone)

내 저장소를 완전히 새로 내려받고 싶은 경우 혹은 남의 github 코드를 내 컴퓨터에 다운받아서 실행해보고 싶은 경우에 사용되며 git과 github을 알아야 하는 가장 큰 이유이다.

방법1. 직접 Download ZIP을 해서 다운

방법2. command line을 이용

Clone with HTTPS 밑에 보이는 주소를 이용할테니 클립보드에 복사해 둡시다. clone은 온라인 저장소를 local 컴퓨터에 저장하는 명령어 입니다. clone을 하고 나면 저장소 이름으로 하위폴더가 생성되고 그 폴더 안이 복사된 저장소입니다. 저장소 안에 들어가면 폴더 주소 오른쪽에 branch 이름(main)이 표시되는 것을 알 수 있고 git log --oneline를 입력하면 commit이 있는 것을 볼 수 있습니다.

fork

clone을 사용을 안할거면 fork를 해줘야 한다.

클론 or fork 후 작업


깃허브에서 협업할 때는 여러 사람이 함께 파일을 수정하고 푸시하기 때문에 반드시 작업하기 전에 깃허브 리포지토리의 최신 커밋을 풀한 다음 자신의 커밋을 푸시해야 합니다.

제이든이 새 커밋을 만들어 깃허브 리포지토리에 푸시하는 동안 YAMA가 YAMA의 컴퓨터에서 다른 커밋을 푸시한다고 가정해 보겠습니다. 야마의 컴퓨터에서 'yama.txt' 문서를 만들어 내용을 작성하고 저장한 후 add를 해주고 commit을 만듭니다.

여기서는 add . 가 아니라 추가한 txt만 하나만 올릴거라 add yama.txt로 해준다.

그럼 이제 YAMA가 생성한 커밋을 깃허브 리포지토리에 푸시하겠습니다.

YAMA도 깃허브 리포지토리로 커밋은 처음이니 처음에 remote add origin 명령을 사용해 주었습니다.

여기서 ! [rejected]라고 시작하는 오류 메시지가 뜬다!

이것은 깃허브 리포지토리에 있는 최신 커밋 정보가 YAMA의 컴퓨터에 저장되어 있지 않기 때문에 나타난 것입니다. 이런 오류가 생기지 않게 하려면 자신의 커밋을 푸시하기 전에 깃허브 리포지토리의 최신 커밋을 가져와야 합니다. 깃허브 리포지토리에 있는 최신 커밋을 가져오기 위해 git pull 명령을 사용합니다. 첫 원격 풀이니 로컬 브랜치가 리모트 브랜치를 추적하게 해 주기 위해 깃허브 리포지토리 주소 뒤에 옵션을 붙여줍시다.

$ git pull 깃허브 리포지토리 주소 master master --allow-unrelated-histories
↑ 위의 명령어를 쳐준다.

공용 저장소에 내 코드를 넣어달라 요청하기 (Pull Request) - 팀원

위의 방법을 다했으면 팀원을 초대를 했고 팀원들은 레포지토리 주소를 url로 가져와서 git clone을 하고 각자 branch로 가져와서 작업을 하고 자신의 main branch로 가져왔을 것이다. 리더도 자신의 레포지토리를 다른 branch에서 작업을 하고 테스트를 하고 자신의 main branch로 가져오고 다른 branch들을 제거했을 것이다.

이제는 팀원들이 PR을 할 차례이다.

공용 저장소와 브랜치 합치기(Git Merge)

Git 명령어

폴더에 Git 연동하기

이 부분은 여러명과 하는 작업이 아니어도 모두 동일하다.

1. 사용할 폴더에서 우클릭 → Git bash 열기

2. Git 연동하기
	임의로 README.md 파일을 연동한다고 하자!

위의 코드대로 README.md 파일이 만들어지고 # Git_One이 적힘

이 뒤부터는 동일
git init
git add .
git commit -m "`커밋할 내용`"
git remote add origin `Git repository 주소`
git push -u origin master

	git push -u origin master
● 위의 코드를 한 번 해놓으면 이후부터는 repository 주소를 origin에 
  기억을 해놓기 때문에 git push만 해줘도 바로 사용 가능하다.
  

3. Git push가 됐는 지 확인하기

Gitignore

https://www.gitignore.io/

Manage access설정

내가 만든 저장소에 팀원이 기여할 수 있도록 팀원에게 저장소 접근 권한을 부여해준다.

깃헙을 사용하다보면 내 Private Repository 를 다른 사람과 공유해야 하는 일이 있다.

1. private repository 페이지에서 settings 로 들어간다.

2. Manage access - Invite a collaborator 를 클릭

3. 검색창이 나타나면 유저네임을 입력해준다.

4. 검색 하면 유저가 나온다. 초록버튼을 클릭해주자

5. Manage access 에서 해당 유저가 등록된 것을 확인할 수 있다.

develop branch 생성

main에 바로 합치다가 문제가 발생하면 매우 난감해진다.
그렇기 때문에 안전하게 사용하기 위해서 develop branch를 만들어준다. 팀원들은 develop branch로 코드를 합칠 것입니다. 그리고 중간 중간 develop코드가 잘 돌아가는지 테스트 후에 main으로 합쳐준다.


commit & push

저장소 복제 - git clone

위에서 프로젝트를 share하고 새로운 branch를 만들고 push를 해줬다.
그것들을 팀원이 사용하려면 가져와야 한다. 그때 사용하는 것이 clone이다.

fork(optional)

github에 입력해둔 본인의 이메일에서 팀권한 수락

이클립스에서 Git Flow전략을 적용한 협업방법

협업(공통) 1. Issue

협업(공통) 2. Branch 생성 및 작업

협업(공통) 3. Commit & Push

4. Pull Request(PR)

5. 코드리뷰(선택사항)

6. Merge(코드병합)

7. Checkout branch develop


8. Pull

9. delete feature branch

10. 정리

github이란?

  • 개발자들의 간의 협력을 중점, 이슈 트래커 제공
  • 유료 계정이 없는 경우 모든 코드를 오픈 소스로 공개, 용량에 제한
  • 개인 유료 계정, 회사 단위의 유료 계정(인당)
  • 소스 코드, 프로젝트 코드, 라이브러리 참고 가능
● 먼저, github desktop을 다운받자
  https://desktop.github.com

● 실행하면 다음과 같이 화면이 뜬다.

● Sign in to GitHub.com 을 클릭하신 후 github 아이디로 로그인

● 아래 화면이 나타나면 개나리색 주황 박스를 클릭해 새로운 프로젝트를 만들 것입니다.

● 새롭게 만들 프로젝트에 이름과 경로를 지정 후 Create repository를 클릭

●  Create repository를 클릭

● github desktop을 확인해보시면 index.html 파일이 새로 올라온 것을 
  확인해보실 수 있습니다.
● 노란색으로 밑줄 친 곳에 업로드 할 파일에 설명을 간단하게 적어주자.
● Commit to master를 클릭하신 후에 Publish repository를 클릭

● Publish repository를 클릭하시면 아래와 같은 창이 뜨는데 
  Keep this code private에 체크 박스를 풀어주시고
● Publish repository 버튼을 클릭해주세요.

커밋(commit)

● 이 파일의 수정이 끝났다는 의미로 로컬저장소에 저장하는 것

Pull

● 이후 해당 주소에서 변경된 자료들은 Repository 탭의 Pull을 이용하여 
  내 컴퓨터로 간편하게 가져올 수 있다.

푸시(push)

● 로컬 Staged에 저장된 파일을 원격 저장소(깃허브 사이트)에 저장하는 것입니다.
●  GitHub DeskTop 프로그램의 Pull을 이용하여 GitHub 서버에서 자료를 
   가져오는 방법과 Push를 이용하여 서버로 자료를 보내는 방법
   
(1) 기본적으로 내 컴퓨터에서 GitHub와 연동된 폴더에서 변화가 일어나면, 
    좌측의 Change에 변경된 내용이 표시된다. 
    History의 경우, 해당 서버에서 변경된 내용을 모두 추적할 수 있다.   

(2) 내 컴퓨터에서 변경된 사항을 최종적으로 확정(Commit)하는 단계이다. 
    1번 영역에는 변경 사항을 요약하는 제목을, 2번 영역에는 변경사항에 대한 
    설명을 작성해준다. 작성을 완료하였으면, Commit to main버튼을 눌러 
    변경 사항을 확정한다.

(3) Commit이 완료 되었으면, 아래 그림과 같이 Push버튼이 활성화된다. 
    Push 버튼을 누르면 서버에 내가 변경한 사항이 업로드 된다.

Clone

Clone은 쉽게 말해 GitHub(Server)에 저장된 내용을 내 컴퓨터(Local)로 가져오는 작업이다.

(1) 먼저, 아래 그림과 같이 GitHub DeskTop의 파일 탭에서 Clone repositor를 선택한다.

(2) 나타나는 창에서 URL을 클릭하고, 1번 영역에는 자료를 가져올 GitHub의 주소를, 2번 영역에는 해당 파일을 내 컴퓨터에 저장할 경로를 입력한다.
이때, GitHub의 주소는 해당 프로젝트 우측 상단에서 아래와 같이 복사해오면 된다.
작성을 완료했으면, Clone 버튼을 누른다. 내 컴퓨터에 자료가 다운로드 된 것을 확인할 수 있다.

▲ 원하는 프로젝트의 좌상단에 위치한 녹색 버튼을 누르고 나타나는 주소를 복사한다.
  • 1) 파일연동
    깃허브 데스크톱에서 file→ new repository → 연동할 곳에 파일만들기 → 깃허브 홈페이지에서 체크
  • 2) 깃헙 홈페이지에서 만들고 가져오기
    위에서 만든 이름으로 들어가서 Add file로 추가하기 → 깃허브데스크톱에서 pull 클릭
    → 연동한 파일 체크(만들어졌는지)
  • 3) 만든 파일 데스크톱을 통해서 깃허브 홈페이지에 올리기
    연동한 파일에 올릴 파일들 올리기 → 설명 적은 후 commit to main하기 → push origin클릭(파란버튼)
    → 그러면 pushing중이라고 뜨면서 업로드함 → Fetch origin이라고 뜨면 올라간것 → 홈페이지에서 체크

폴더 구조로 들어가거나 finder로 들어가서 자신의 repsitory를 만든곳으로 가보자
그러면 거기에 만든 repsitoty가 생성된 것을 볼 수 있다.
근데 폴더에 들어가보면 아무것도 안나오는데 윈도우 같은 경우 숨겨진 폴더를 보이게
하면 된다. 여기에 있는 .git 폴더 안에 여러가지 파일들이 있는데 이것들이 있어야
git이 내 repository를 보고 감시한다. 만약 이걸 지우게 된다면 깃은 날 더이상 보지 않게
되는 것이다.

github는 자바, 자바스크립, 파이썬 등과는 관련이 없습니다. 즉 개발 언어(프로그래밍)이 아닙니다.
단지 우리가 그동안 사용한 구글 드라이브(원격 저장소)의 일종입니다.
부연 설명을 하자면 우리가 작성한 코드들 어떤 언어와 관계없이
그리고 작성한 코드가 아니더라도 문서, 파일, 이미지 등등 관계없이
소스코드를 저장하고 히스토리를 관리하는 저장소입니다.
이 저장소의 가장 큰 장점은 여러 개발자가 협업하는 상황에서
각각의 개발자들이 작성한 코드가 다른 개발자들이 작성한 코드와
잘 합쳐지도록 그리고 문제 발생시 롤백(이전으로 복구) 등이
잘 이루어 지도록 하기 위한 협업 도구의 일종입니다.

파일삭제

1. repository 내 파일(README.md) 선택 -> 파일 내용의 우측 상단 쓰레기통 버튼 클릭
2. 화면 하단 "commit changes" 클릭
3. repository에서 "README" 파일이 사라진 것 확인

Repository 삭제

1. Repository "Settings" 
2. 아래쪽으로 스크롤하면 "Danger Zone"
3. "Delete the repository" 클릭
4. 다음과 같은 창이 트면 입력 칸에 입력하라는 문자 입력
5. 아래 "I understand the consequences, delete this repository" 버튼 클릭
6. 자신의 github 비밀번호 입력하고
7. "confirm password"
8. 정상적으로 repository가 삭제됨
(상단 파란색 상태바 "Your repository "Gina-IT/test" was successfully delted.)
9. 좌측에 Repositories 리스트를 보면 test라는 repository는 없는 것 확인 가능

무료 웹호스팅

● GitHub에는 무료 웹호스팅을 지원해주고 있는데 레지스토리에서 세팅으로 들어가서 
  두번째로 Make private에 체크되어있걸 Make public으로 공개해주며
  자신의 프로젝트명을 입력 후 바꿔주신다면 무료로 웹호스팅을 사용할 수 있습니다.

Branches(브랜치)

● 소프트웨어 개발은 현재 출시하고 있는 버전의 유지 보수를 하면서 새로운 기능추가 및 버그 수정을
  할 수 있습니다. 이러한 병렬로 수행되는 여러 버전 관리를 위해 GitHub에는 브랜치라는 기능이
  있습니다.
● 지점은 역시의 흐름을 분기하여 기록 해 나가는 것입니다.
  분기의 한 지점은 다른 지점의 영향을 받지 않기 때문에 같은 저장소에서 각 개발을 해 나갈 수 있다.

Github Desktop 에 들어가서 Current Branch를 클릭하면
현재 어느 브렌치에 위치하고 있는지 알려주고 새로운 브랜치를 만들 수 있다.
New Branch를 클릭하고 새로운 브렌치를 만들어보자. bye-world 브렌치를 만들어 주었다.
브랜치는 마스터의 마지막 commit에서부터의 다른 타임라인을 뜻한다.
만들어주면 비주얼 스튜디오도 자동으로 브랜치를 bye-world로 바꿔준다.!!
이는 대단한 기능이다.... 비주얼 스튜디오의 왼쪽 하단의 구석에 어떤브렌치를 보고있는지 알려준다.

Github 프로세스

  • 다음이 일반적으로 깃허브가 사용되는 과정이다.
    1. 팀장은 기본 설정을 완료한 폴더를 깃허브의 새로운 저장소에 등록한다.
    2. 팀원들은 그 저장소의 주소를 clone하여 자신의 컴퓨터에 저장한다.
    3. 팀장은 팀원들을 collaborate 설정해서 깃허브 저장소에 접근할 수 있게 한다.
    4. 팀원들은 자신들의 branch를 생성한다.
    5. 코드를 수정하면 branch로 commit, push해서 자신의 branch에 업로드한다.
    6. 팀장에게 자신의 코드를 master에 병합해 달라고 pull request를 요청한다.
    7. 팀장은 pull request를 확인하고 코드리뷰후 수락하여 master와 병합한다.
    8. 다른 팀원들은 병합된 master를 자신의 branch에 merge한다.

github 에 이미 올라가 있는 repository clone 하기

1. clone 하려는 github의 repository url을 복사합니다.
2-1. GitHub Desktop 에서 add -> Clone repository 를 클릭합니다.
2-2. URL 탭에서 , url 을 붙혀넣기 하면, Local path 에 해당 repository name 으로 폴더가 생깁니다. 
      이 폴더명은 변경해도 됩니다.
3-1. 이제 저 소스를 이클립스 등으로 수정하면 changes 탭에 뭐가 생긴다.
3-2. 초록생 +는 추가된 내용, 핑크색- 는 삭제된 내용
4. commit, push하기

원격 저장소와 로컬 저장소

	저장소(Git repository)란 말그대로 파일이나 폴더를 저장해 두는 곳이다.
    이 Git 저장소의 큰 특징은 내가 파일을 수정하면 수정된 파일의 히스토리를 저장할 수있다. 
    (commit)

Git은 원격 저장소와 로컬 저장소 두 종류의 저장소를 제공한다.

● 원격 저장소(Remote Repository): 
	파일이 원격 저장소 전용 서버에서 관리되며 여러 사람이 함께 공유하기 위한 저장소
● 로컬 저장소(Local Repository): 
	내 PC에 파일이 저장되는 개인 전용 저장소

Github readme 꾸미기

본인의 깃 활동도를 볼 수 있는 툴

![YuYoHan's GitHub stats](https://github-readme-stats.vercel.app/api?username=본인깃계정명&show_icons=true&theme=radical)


본인의 메일, 블로그 등을 아이콘 혹은 배지로 깔끔하게 보여줄 수 있다.

>
```Git
<a href="mailto:본인메일"><img src="https://img.shields.io/badge/Gmail-D0A9F5?style=flat-square&logo=Gmail&logoColor=white&link=mailto:본인메일"/></a>

자신이 공부한 언어나 툴을 배지로 보여주기

<img src="https://img.shields.io/badge/기술명-색상코드?style=flat-square&logo=로고&logoColor=색상"/>

사용언어 비율

[![Top Langs](https://github-readme-stats.vercel.app/api/top-langs/?username={깃헙 이름(string)})](https://github.com/anuraghazra/github-readme-stats)

Velog 보여주기

[![Velog](https://img.shields.io/badge/Velog-20C997?style=flat-square&logo=Velog&logoColor=black)](velog 링크)

접속 기록

[![Hits](https://hits.seeyoufarm.com/api/count/incr/badge.svg?url=https%3A%2F%2Fgithub.com%2FYuYoHan&count_bg=%2379C83D&title_bg=%23555555&icon=&icon_color=%2335DFF1&title=hits&edge_flat=false)]()

gitlab이란?

  • github와 항상 같이 대립되는 클라우드(저장소)
  • 비공개 버전의 github, 무료로 비공개, 용량을 넉넉히 사용할 수 있음
  • 개발자들을 위한 도구들이 모두 설치되어 있다.
  • 자체 호스팅 지원
  • 이런 도구들을 이용하면 유료 계정으로 전환

보통 개발자라면 github, 회사라면 gitlab을 사용

profile
유요한
발전하기 위한 공부
다음 포스트

프로젝트시 Git readme에 넣어야할 것

0개의 댓글