1. 원작자가 초기 세팅한 후 깃허브 업로드 및 협업자 콜라보레이터 등록

2. 브랜치 분할(master/develop)

git branch '브랜치명' 명령어를 이용하여 브랜치를 분할한다.

 

3. 브랜치 분할이 끝났으면 동료가 로컬에 클론을 뜸

 

4. 브랜치 분할 후 클론 뜬 레포지토리에서 master 브랜치만 보인다면 로컬에서 git branch -r을 하면 빨간색으로 보임

위와 같이 develop 브랜치가 있는 것을 확인할 수 있다.

checkout 명령어를 이용하여 develop 브랜치로 잡아준다.

이슈 탭에서 각자 할 작업을 작성해준다.

위와 같이 이슈 번호가 생성된 것을 확인할 수 있다.

develop 브랜치로 잡혀 있는 상태에서 feature/3라는 브랜치를 분할해준 후 해당 브랜치로 잡아준다.

수정(파일 추가) 후 add, commit, push를 진행해준다.

위와 같이 브랜치가 추가된 것을 볼 수 있고, 내가 작성한 feature/3로 가보면 수정사항이 잘 올라간 것을 확인할 수 있다.

풀 리퀘스트 탭에서 위와 같이 feature/3 브랜치를 develop 브랜치로 머지 요청을 진행한다. 

동료가 승인하면 Open 부분이 Merge로 변경된다.

issue 탭에서 완료 처리를 진행한다.

'네트워크캠퍼스 > GIT, GITHUB' 카테고리의 다른 글

풀 리퀘스트  (0) 2024.02.20
Github CLI  (0) 2024.01.31
.gitignore 파일의 필요성  (0) 2024.01.12
  (0) 2024.01.12
클론  (0) 2024.01.11

타겟 저장소에서 Fork 버튼 클릭

위 과정을 통해 상대방 레포지토리와 내 레포지토리의 버전이 같은 상태가 된다.

위와 같이 현재 내 계정에 fork된 것을 확인할 수 있고, 해당 주소를 이용하여 clone을 진행한다.

파일 수정 후 add, commit, push를 진행한다.

이제 개선된 내 코드의 버전이 앞서므로 내 코드를 pull로 받아가라고 요청해야 한다.

이는 Pull requests로 요청할 수 있다. 

위와 같이 New pull request와 Create pull request를 진행해주면 풀 리퀘스트가 요청된다.

이 후 원작자의 알림창에 풀리퀘스트 요청이 들어오고, 마음에 든다면 Merge pull request 버튼을 클릭하여 받거나 거절할 수 있다.

 

※ 이 방식은 실수로 커밋될 일이 없다는 장점이 있지만, 풀 리퀘스트가 올 때마다 원작자가 매번 확인해야 한다는 단점이 있다.

'네트워크캠퍼스 > GIT, GITHUB' 카테고리의 다른 글

git-flow  (0) 2024.02.20
Github CLI  (0) 2024.01.31
.gitignore 파일의 필요성  (0) 2024.01.12
  (0) 2024.01.12
클론  (0) 2024.01.11

먼저, 해당 폴더에서 CLI 창 열어주고 init으로 초기화 (.git 폴더 생성)

config로 깃허브 계정 연결

깃허브에서 레포지토리 생성

레포지토리 생성 후 해당 주소 복사

remote로 origin이라는 이름의 원격 저장소 추가

add와 commit, push 진행

Settings에서 Default branch 설정 가능

clone할 때는 마지막에 . 붙여서 현재 디렉토리에 받아주기

받아올 때마다 git pull 원격저장소명으로 풀해주기 

 

'네트워크캠퍼스 > GIT, GITHUB' 카테고리의 다른 글

git-flow  (0) 2024.02.20
풀 리퀘스트  (0) 2024.02.20
.gitignore 파일의 필요성  (0) 2024.01.12
  (0) 2024.01.12
클론  (0) 2024.01.11

1. .gitingore 파일

→ git으로 저장소를 관리할 때 필요 없는 파일들(개인적 설정을 위한 파일 등)에 대해 업로드를 원천적으로 막도록 세팅하는 파일

 

먼저, .gitignore.txt 파일을 생성해준다.

 

위와 같이 metadata를 추가해주고 txt 확장자를 없애준다.

 

add와 commit을 진행하면 .gitignore에 작성된 파일명이나 폴더명에 해당하는 것들은 대상에서 제외된다.

즉, .metadata 폴더를 제외한 내용들만 안전하게 업로드할 수 있게 된다.

 

 

'네트워크캠퍼스 > GIT, GITHUB' 카테고리의 다른 글

풀 리퀘스트  (0) 2024.02.20
Github CLI  (0) 2024.01.31
  (0) 2024.01.12
클론  (0) 2024.01.11
로컬 저장소 내역 깃허브 업로드  (0) 2024.01.10

1. pull

→ 원격 저장소의 버전이 로컬 저장소의 버전보다 앞서는 경우 원격 저장소의 갱신 내역을 로컬 저장소에 반영해주는 것

 

1) 소스트리에서 pull

 

먼저, 해당 경로에 파일을 생성한다.

 

다운받고자 하는 주소 복사

 

위와 같이 클론해주면 커밋 내역까지 잘 불러온 것을 확인할 수 있다.

 

해당 파일 생성해주고

 

add와 commit을 진행해준다.

 

위와 같이 푸시해준 후

 

깃허브 확인 시 위와 같이 잘 추가된 것을 확인할 수 있다.

 

git_sourcetree 로컬 저장소에서 원격저장소(깃허브)를 이용하여 pull을 진행한다.

 

해당 폴더를 확인해보면 위와 같이 회사에서 작업한 코드가 추가된 것을 확인할 수 있다.

 

※ 즉, clone은 최초 한 번만 실행해준 후 pull을 이용하여 여러 PC에서 같은 버전의 코드를 유지할 수 있다.

 

2) CLI에서 pull

마찬가지로 먼저 pc2_git_cli 폴더를 생성해준다.

 

깃허브에서 클론할 주소 복사 후

 

위와 같이 클론을 진행한다. (주소 뒤에 . 붙여주는 거 잊지 말기!)

 

이와 같이 잘 추가되어 있는 것을 확인할 수 있다.

 

새로운 파일 생성 후

 

이와 같이 add, commit, push를 차례대로 수행해주면

 

깃허브에도 해당 파일이 잘 추가되어 있는 것을 확인할 수 있다.

 

다시 git_cli 저장소에서 pull 명령어를 수행해주면

 

마찬가지로 해당 파일이 추가된 것을 볼 수 있고, 두 대의 PC가 같은 환경이 되었다고 할 수 있다.

'네트워크캠퍼스 > GIT, GITHUB' 카테고리의 다른 글

Github CLI  (0) 2024.01.31
.gitignore 파일의 필요성  (0) 2024.01.12
클론  (0) 2024.01.11
로컬 저장소 내역 깃허브 업로드  (0) 2024.01.10
병합  (0) 2024.01.05

1. clone

→ 다른 PC에 업로드했던 원격저장소의 코드를 로컬저장소에 내려받는 행위

→ 여러 PC에서 파일을 한 버전으로 유지할 수 있다.

 

git_cli와 git_sourcetree 폴더의 내용물을 지운 상태에서 진행 (.git도 지우기)

1) 소스트리에서 클론하기

내려받고자 하는 repository의 코드 주소를 복사한다.

 

위와 같이 복사한 주소와 내려받을 폴더 경로를 지정해준 후 클론한다.

 

위와 같이 잘 복사된 것을 확인할 수 있다.

 

2) CLI에서 클론하기

CLI에서도 마찬가지로 받고자 하는 repository의 주소를 복사한다.

 

git clone 주소 . 명령어를 통해 복사한다.

※ 이때 주소 뒤에 .을 반드시 붙여주어야 한다.

 

이와 같이 잘 복사된 것을 확인할 수 있다.

'네트워크캠퍼스 > GIT, GITHUB' 카테고리의 다른 글

.gitignore 파일의 필요성  (0) 2024.01.12
  (0) 2024.01.12
로컬 저장소 내역 깃허브 업로드  (0) 2024.01.10
병합  (0) 2024.01.05
브랜치  (0) 2024.01.04

1. push

→ 로컬저장소의 저장소(repository)를 원격저장소의 저장소로 복사하는 것

 

1) repository 추가

 

위와 같이 추가해주면 원격저장소 생성이 완료된다.

 

원격저장소를 연결하는 위의 명령어를 복사한다.

 

2) 깃허브 인증 추가 (토큰 생성)

repo는 필수, 나머지는 선택

 

3) 소스트리에서 깃허브 업로드

 

위에서 발급받은 토큰으로 인증

 

설정 탭에서 사용자 정보에 이름과 이메일 추가

 

전역 사용자 설정을 체크하면 global, 아니라면 local로 설정

컴퓨터를 나만 쓰는게 확실하다면 global로 설정하는 것이 편함, 여기서는 강의장 PC이므로 local로 설정

 

※ git global과 git local

- 특정 폴더에 대한 유저정보를 저장하고 싶다면 local 방식을 써야 한다.

- 컴퓨터 전체에서 공용으로 쓰는 계정을 사용하고 싶다면 global 방식을 써야 한다.

 

[저장소] - [저장소설정] 탭에서 위와 같이 생성했던 원격 저장소 정보 추가

 

위와 같이 브랜치를 선택하여 업로드할 수 있다.

 

푸시가 완료되면 위와 같이 원격 저장소의 모든 브랜치가 업로드된 것을 확인할 수 있다.

 

4) CLI에서 깃허브 업로드

→ CLI에서는 git config 명령어를 사용한다.

 

- 글로벌 설정 시

git config --global user.name"유저명"

git config --global user.email"이메일"

 

- 로컬 설정 시

git config --local user.name"유저명"

git config --local user.email"이메일"

 

 

먼저, 레포지토리를 생성한다.

위와 같이 원격저장 소 주소를 복사해둔다.

remote : 깃이 아닌 깃허브 관련 설정

add : 깃허브 관련 설정 추가

origin : 변수명 origin에 주소 저장 (가장 기본적인 이름)

 

git remote 명령어를 통해 원격 저장소 주소가 origin이라는 이름에 매칭된 것을 확인할 수 있다.

 

git remote show 명령어를 통해 제대로 등록이 되었는지 확인할 수 있다.

 

git push 명령어를 사용하여 모든 브랜치 업로드

 

위와 같이 잘 업로드 된 것을 확인할 수 있다.

'네트워크캠퍼스 > GIT, GITHUB' 카테고리의 다른 글

  (0) 2024.01.12
클론  (0) 2024.01.11
병합  (0) 2024.01.05
브랜치  (0) 2024.01.04
커맨드라인을 활용한 깃  (0) 2024.01.03

1. 병합

→ 특정 브랜치의 변경내역을 다른브랜치로 가져오는 것. 즉, 두 브랜치의 코드가 하나로 합쳐짐

 

1) 소스트리에서 브랜치 병합하기

master 브랜치에는 무조건 돌아가는 최종 코드만 커밋해야 하기 때문에 feature;a에 먼저 머지를 해보고 문제가 없다는 것을 검증해야 한다.

 

feature;a로 체크아웃한 후 master 우클릭에서 현재 브랜치로 master 병합을 클릭한다.

 

master에서 작업한 메인기능 2번기능 추가가 feature;a에 추가되어 있어야 한다.

 

해당 파일을 확인해보면 2번 기능 추가 내용이 잘 들어있는 것을 확인할 수 있다.

 

master를 체크아웃한 후 확인해보면 master 브랜치는 5번 커밋에 머물러 있기 때문에 feature;a에서 만든 a.txt는 확인할 수 없다.

 

master를 체크아웃한 상태에서 feature;a를 병합한다.

 

위와 같이 양쪽 브랜치가 동등해진 것을 확인할 수 있다. → 하나의 기능 개발이 완료된 것을 의미

 

2) CLI에서 브랜치 병합하기

기본적으로 master보다는 feature;a에 먼저 머지를 해야 하므로 feautre;a 브랜치로 체크아웃을 한다.

 

git merge 타겟브랜치명을 통해 병합을 할 수 있다.

 

위와 같은 화면이 나온다면 esc 키 누른 후 :q!를 입력해서 빠져나온다.

 

위와 같이 feature;a에 마스터에 추가된 내용을 끌고 온다.

 

위와 같이 feature;a 체크아웃 상태에서 gittest.txt 파일에 2번 기능이 추가되어 있는 것을 확인할 수 있다.

 

master 체크아웃 상태에서는 아직 머지를 하기 전이므로 a.txt 파일을 확인할 수 없다.

 

master 브랜치에서 feature;a를 merge 해준 후 확인해보면 위와 같이 잘 병합된 것을 확인할 수 있다.

 

 

2. 충돌 문제 해결하기

같은 파일에 대해 각 브랜치에서 새 브랜치를 생성한 이후 새롭게 같은 파일을 수정하고 병합하는 경우 충돌이 발생한다.

 

1) 소스트리에서 충돌 문제 해결하기

master로 체크아웃 한 후 gittest.txt에 3번 기능을 추가한 후 add, commit을 진행한다.

 

위와 같이 잘 커밋된 것을 확인할 수 있다.

 

feature;a로 체크아웃한 후 파일을 확인해보면 위와 같은 상태이다.

 

같은 위치에 위와 같은 내용 추가 후 add, commit 진행한다.

 

위와 같이 gittest.txt 3번 기능, 즉 동일한 지점에 두 브랜치에서 작업한 경우 merge를 진행하면 오류가 발생할 것이다.

 

이처럼 머지하려고 하면 master의 코드가 옳은지, feature;a의 코드가 옳은지 모호한 상황이 발생하기 때문에 충돌이 일어난다.

 

충돌난 파일을 더블클릭에서 연 후 위아래 코드를 적절하게 반영하고 다시 병합하면 충돌이 해결된다.

 

위 내용은 충돌 발생 시 자동으로 작성된다.

 

수정 후 다시 커밋해보면 위와 같이 병합이 잘 된 것을 확인할 수 있다.

 

2) CLI에서 충돌 문제 해결하기

먼저, feature;a 브랜치에서 gittest.txt 파일에 3번 기능을 추가한다.

 

add와 commit을 진행해준다.

 

마스터 브랜치로 체크아웃한 후 같은 지점에 3번 기능을 추가해준다.

 

add와 commit을 진행해준다.

 

feature;a 브랜치로 체크아웃 후 master와 병합하려고 하면 위와 같이 충돌 에러가 발생하는 것을 확인할 수 있다.

 

위와 같이 충돌난 파일을 열고 수정해준다.

 

다시 머지를 진행해보면 먼저 커밋을 하라는 메시지가 나온다.

 

add와 commit을 진행한 후 다시 merge를 해보면 위와 같이 이미 병합이 완료된 것을 확인할 수 있다.

'네트워크캠퍼스 > GIT, GITHUB' 카테고리의 다른 글

클론  (0) 2024.01.11
로컬 저장소 내역 깃허브 업로드  (0) 2024.01.10
브랜치  (0) 2024.01.04
커맨드라인을 활용한 깃  (0) 2024.01.03
소스트리를 활용한 깃  (0) 2024.01.02

+ Recent posts