우아 한의원 | 조재성 원장의 한의학, 의학통계, 프로그래밍

• registry를 수정해야하는데 마침 해당 블로그에서 파일 제공중
  • 첨부파일 다운받아서 더블클릭하여 실행

1. 아래 첨부된 압축파일 다받아서 설치하기
 - 삼성PC아니면, MS store에서 다운안되는데, 크랙해 놓은 것임.

2. 설치 한뒤, 다시 한번 MS store의 [samsung note]검색해서 들어가 업데이트 진행

3. 설정에서 삼성계정로그인 + [동기화ON후 -> OFF] + [자동저장OFF] 선택하기
 - 동기화는 PC, 태블릿 중 1개에서만 해놓아야한다. PC버전은 꺼두고 최초or필요시 1번씩 해주자.
   - PC버전에서 자동저장 이용하다가 날아간 경우가 많다고 한다.
 - 태블릿에서 작성후 보기만 하자.

1. 리셋, 인터넷연결 끊은 컴퓨터에 WAN제외한 나머지 1개 선에 연결
 - reset시 admin/admin 
 
2. 관리도구 > 고급 설정 > 네트워크 관리 > 내부 워트워크 설정 > 내부 IP 주소 마지막 숫자를 1에서 편한 것(100)으로 변경 > 적용(저장x, 적용버튼)
 - 메인 공유기(192.168.0.1)과 겹치지 않게 하기 위해
 - 1분 정도 기다리면 재시작 완료됨.
 
3. 192.168.0.100으로 접속(변경된 admin으로 접속) > 관리도구 > 고급 > 네트워크 > 
 내 공유기) DHCP 서버 동작 [중지] > 적용 
 최근공유기) DHCP 서버 설정 > DHCP 서버 동작 [중지] > 적용 
 
4. 무선랜 관리 > 무선 설정/보안 > 와이파이 공유기 이름 변경 + 암호변경(권장설정WPA2PSK+AES) > 적용 

5. 무선랜관리 > 무선확장설정 > 멀티 브리지(리피터) 선택 > [AP검색]후 메인공유기 선택 + 암호입력 > 적용 
 - 무선 브리지 연결 확인하기 
 
6. 우측상단의 [저장] 누르기 

1. windows10 노트북에서 연결을 켠다
   

2. 태블릿이나 스마트폰(갤럭시)에서 SMART VIEW를 켠다

   • 현재는 노트북이랑 연결되어 DESKTOP-7KACME 라 표시되어있음. 비활성화된 SMART VIEW로 평상시 나와있는데 그것을 누르면, 노트북 중 연결대기 중인 기계목록이 뜬다.
     

3. 기기를 연결하면, 아래와 같이 쉽게 연동된다.
   

단축키

1. Ctrl + 1,2,3(숫자): 여러개 열린 탭에서 해당 탭으로 바로 이동!
2. Ctrl + T : 새 탭 열기
3. Ctrl + W : 탭 종료하기
4. Ctrl + Shift + T : 종료한 탭 복구하기

검색 꿀팁

XLHscroll.7z

엑셀이 설치된 컴퓨터에서 아래 압축파일의 압축을 풀고 설치만 해주면 끝!

사용법 : shift + 마우스 휠

순서대로

default

Django

RDark

Midnight

Emacs

FadeToGrey

Eclipse

티스토리 블로그에 SyntaxHighliter 적용

1. 위의 파일을 다운로드 받고 압축을 푼다.
   압축파일에서 scripts폴더 안의 파일 + styles폴더 안의 파일을 업로드할 준비
   
   

2. 블로그에서 [Q]를 눌러 관리자 모드로 진입 > 꾸미기 > 스킨 편집 선택
   

3. html 편집 선택 > 파일 업로드 선택 > 위에서 언급한 2폴더 다 업로드 후 > 적용
   
   
   

4. 다시 HTML 클릭 후, 코드가 끝나는 부분 찾기
   

5. \head 안쪽에다가 아래 코드들 집어넣기 > 적용
   https://gist.github.com/is2js/d12729a9d122b0ae5488276ddf0e467f#file-tistory_syntaxhighliter-js
   

syntaxhighliter 사용해보기

1. 테마 바꾸기
   shThemeEclipse.css (default 테마)가 있는 부분을 찾아서 아래 목록 중에 하나로 바꾸면 된다.
   
   

2. 글쓰기 사용법 : html 를 선택한 상태에서 < pre class= brush:언어명>

   코드

   형식으로 사용한다. 언어명 목록은 아래와 같다.
   

 def class
 

• 시작프로그램에서 cmd 검색 > 관리자 권환으로 실행
  
  
  
• net user administrator /active:yes
  
  
  
• 재부팅

기본적으로 제공되는 단축키

• Q : 블로그 관리홈 으로 전환
• W : 글쓰기

단축키 추가 방법

1. Q로 블로그 관리홈 으로 들어가기
   
   
2. 꾸미기 > 스킨 편집
   
   
   
3. HTML코드 중 //추가 단축키 부분 찾기
   
   
   
4. 아래 코드 추가해주기
   key['m'] = "/admin/entry/post/?id=" + location.pathname.split('/')[1]

원격저장소(github)
  - 가입 후 저장소를 만들고, 저장소 http를 복사해놓자
  - 소스트리에서는 Add Remote를 통해 로컬저장소에다가 원격저장소를 연결시킨다.(Remote-origin)
  - 소스트리에서 로컬저장소 내용은 Push해준다.

Clone : 새로운멤버가 프로젝트를 다운받는 것. 대신 폴더명에 작업자를 기재해준다.
  - 원격저장소(github)의 Repository의 Clone with HTTPS 주소 복사
  - 소스트리의 새 탭에 Clone - [ Url 복붙 ] + [ Destination - Browse]를 통해 로컬저장소의 <작업자명의 폴더 생성> / Open in Explorer를 통해 파일 확인

만약 같은 컴퓨터라서 Author를 다르게 지정하는 법
- git config user.name "new"
- git config user.email "new@gmail.com"

Pull : 원격저장소의 버전을 가져오는 것.
  - 작업시작하기 전 / 작업을 Push하기 전 2회에 걸쳐서 해줄 것.
  - 만약 pull안하고push해서 거절당하면, pull을 해서 병합 버전부터 만들어줘야한다.
  - 만약 pull시 충돌이 일어난다면, 충돌해결과정 [직접파일수정 -> Mark Resolved -> commit ]을 거쳐야한다.

----
기존 만들어진 안드로이드 프로젝트의 상위폴더에 github 연결방법
1. 소스트리에서 상위폴더를 생성 -> github저장소 생성 -> 상위폴더에 Add Remote로 연결 -> 각 하위폴더(프로젝트들)을 안스에서 Enable VCS 적용

기존의 상위프로젝트 전체를 github 연결방법

1. 상위프로젝트 우클릭> git Bash - git init 입력 -> 소스트리에서 Add가능 -> github에 저장소 생성 후 https복사 -> 소스트리에서 remote 연결
(상단 Repository > Repository setting > remote 

git 연결해제 및 히스토리 삭제

해당 폴더의 숨김폴더 .git을 삭제하면 됨

현재까지는 로컬에서 원격저장소로 파일을 업로드하는 Push를 했었다.

하지만 새로운 멤버가 프로젝트에 참여했다고 가정해보자. 그 멤버는 원격저장소에서 로컬저장소로 다운로드해야하는 Clone(복제)을 해야한다.

원격저장소의 소스코드를 Clone하여 --> 소스트리에서 Clone Respository를 통해 새로운 로컬저장소에 다운로드 하게 된다.

새로운 멤버가 Clone하기

• 소스트리에서 새로운 탭을 만들고, Clone을 선택하자.
  
  
  
• 원격저장소의 프로젝트에서, Clone with HTTPS 을 통해 https url를 복사해온 뒤, 첫번째 칸에 붙혀넣자
  
  
  
  
  
• Destination Path는 원격저장소의 프로젝트를 저장할 로컬저장소의 위치이다.
  이 위치를 지정하면서, 새로운 작업자의 이름을 붙힌 폴더명으로 수정해준다.
  Browse를 눌러서, 프로젝트를 모아둔 폴더에 간 뒤, 새로운폴더[opentutorials_new]를 만들어서 저장해주자.
  
  
  
  
  
• 원격저장소의 프로젝트를 Clone해서, 새로운작업자의 이름으로 복제하게 되었다.
  [ Open in Explorer ] 를 눌러서  Clone하여 가져온 파일들도 직접 확인해보자.
  

소스트리의 2개의 탭에서
open~ _git 은 내가 하는 작업
open~ _new는 새로운 멤버가 하는 작업이라고 가정하고 다음을 실습해보자.

하나의 원격저장소로 두 멤버간 협업하기

하나의 원격저장소에 새로운멤버가 push를 할 경우 , 컴퓨터의 이름에 해당하는 Author가 다르게 올라간다.
지금은 하나의 컴퓨터로 작업을 하므로, Author를 터미널에서 일부러 변경해주는 작업을 해보자.
[opentutorials_new]를 선택한 상태에서 우측상단의 [Terminal]을 클릭한 뒤, 아래와 같이 입력해준다.
- git config user.name "new"
- git config user.email new@gmail.com

• 먼저 git이라는 사용자가, 새로운 내용을 추가해보자.
  
  
  
  Push옆의 숫자는 원격저장소와 로컬저장소의 버전차이다.
  타임라인을 보면, 원격저장소를 의미하는 origin/master와 버전차이가 2개가 나는 것을 확인할 수 있다.
  
  
  
• 이제 push를 통해 원격저장소로 올려보자.
  원격저장소의 commits에 가보면, push해준 버전이 업로드 된 것을 확인할 수 있다.
  
  
  
  
  
  
• 이제 새로운멤버인 new가 작업을 시작해야한다.
  협업자는 새로운 작업을 시작하기 전에, 반드시 원격저장소에 새로운 내용이 있는지 없는지 확인해야한다.
  그 때 사용하는 기능이 [ Pull ]이다. 즉,  이전에 Clone을 통해 프로젝트를 다운받아놨다하더라도,
  새로운 내용을 Pull을 통해 다운로드 해야한다.
  
  
  
  원격에 있었던, [ git이 push 버전]이,  새멤버의 프로젝트로 가져와지는 것을 확인할 수 있다.
  
  
• 이제 new라는 새멤버가 작업을 해서 push를 해보자.
  
  
  
  push를 완료하면, 아래와 같이 원격저장소(origin/master)와 new라는 새멤버의 로컬저장소(master)가 버전이 같아진 것을 확인할 수 있다.
  
  
  
  
• 만약 git이라는 사람이,   원격저장소의 pull 없이 새로운 작업을 한다고 가정해보자.
  이 상황에서 원격저장소에 push를 하게 되면, 어떤 일이 일어나게 될까?
  
  git은 push를 거절한다.
  pull을 먼저하고 나서, push를 해야한다!
  
  
  
  이러한 상황에서는 Pull을 먼저해서, 충돌이 없다면 자동으로, 병합(merge)를 한 다음, Push를 해야한다.
  
  
• 먼저, 빠트린 Pull을 해보자.
  원격저장소의 버전을 가져와, 로컬저장소의 버전 과 병합(merge)가 된, 새로운 버전이 만들어지는 것을 확인할 수 있다.
  
  그래프를 보게 되면, 원격저장소의 new가 push한 버전(분홍색) 과, git이 새로운 작업을 한 버전(파란색) 사이에, pull을 통해  자동으로 병합된 것을 확인할 수 있다.
  git이 자동으로 병합하여, 별도의 버전을 만들어주는 것이다.

원격저장소가 있고, 협업하는 개발자가 있다면, push전에 무조건 pull을 하자!

[ Pull -> ~~~~~~~~~작업~~~~~~~ -> commit -> Push직전에 Pull한번더 -> Push ]이 작업이다.

같은 부분을 수정하여 충돌이 일어나는 경우

서로 같은 부분을 다른 작업자들이 작업할 때, 충돌이 일어나게 된다.

혼자 작업하는 경우에도, 실험적인 작업을 다른브랜치에서 작업하다가 같은 부분을 수정하여 충돌이 일어날 것이다.

• 먼저 충돌을 발생시키도록 만들어보자. 같은 ul태그 속 라인에서 li를 만들어보자.
  
  
  
  
• 이렇게 같은 부분(li마지막 라인)을 수정한 상태에서,
  new라는 사용자에서 먼저 push를 한다. (단, push전에는 pull을 먼저해야한다. 반드시)
  그리고, push를 하자마자, 1초만에 git이라는 사용자가 pull을 했다.
  
  그랬더니, Uncommited changes와 함께 느낌표의 충돌이 발생한 것을 알 수 있다.
  
  
  
  
• 충돌이 일어날 땐, 직접 파일을 수정해야했다.
  git이라는 사람은 push를 하기 직전에 pull을 했을 뿐인데, 같은 부분이 수정되어 충돌이 일어난 것이다.
  
  
  마찬가지로, ======위쪽의 HEAD는 git이 작업한 부분이고,
  =====아래쪽은 new라는 사람이 작업한 뒤 원격저장소에 올려놓은 코드이다.
  git입장에서는 같은 곳을 수정했기 때문에, 선택하지 않고, 사람에게 위임한 것이다.
  수정을 통해 정확한 코드만 남겼다고 가정하자.
  
  
  
  
• git이라는 사람이 직접파일을 수정하여 충돌을 해결했다면,
  Mark Resolved를 한 뒤, commit해야한다.
  commit하기 전에, Mark Resolved만 한 상태에서, 타임라인의 Graph를 먼저 살펴보자.
  
  
  충돌을 해결하고 난 뒤의 Working Copy의 부모를 보자.
  파란색 부모은 원격저장소(origin/master)이고, 분홍색 부모은 로컬저장소(master)이다.
  
  Pull 버튼을 통해서, 2개의 버전이 병합되었고, 아직 커밋되지않은 버전이 생긴 것이다.
  하지만 같은 부분수정으로 충돌이 발생했기 때문에--> 버전이 생성안되고, Uncommitted 형태로 주어진상태다.
  
  
  
• commit을 눌러서 충돌을 병합해보자.
  회색동그라미가, 버전이 생기면서 파란색으로 변한 것을 확인할 수 있다.
  
  
  
  
• 이제 Push를 통해서 원격저장소에 업로드 시켜보자.
  

이렇게 먼저 push한 new보다는, 나중에 push한 git에게 충돌해결의 임무가 주어진다.
그리고 원격저장소와 자주 동기화해야지만, 이러한 충돌을 해소할 수 있다.

원격저장소

현재까지는 로컬저장소(내 컴퓨터)만 이용했었다.
만약 버전관리도구(git)의 사용이 어렵다면, 반드시 다른 cloud에다가 자신의 소스코드를 백업해놓기를 권장한다.
이렇게만 한다면, 버전관리는 안될 것이다.
버전관리도구를 사용하면서, 원격저장소에 자신의 코드를 역사적인 버전을 남기면서 백업해야한다.

원격저장소의 종류

네트워크상의 저장소인 원격저장소에 , 현재 사용중인 로컬저장소를 연결한다음, 백업해놓는 기능이 주 기능이다.

직접 원격저장소를 만드는 것은, 서버를 구성할 줄 모르면 쉽지 않다.

그래서 사용하는 것이 github등의 git 서비스이다.
깃헙(github)의 경우에는, 공개버전이 아니라면 어느정도 돈을 내야한다.
깃랩(gitlab)의 경우에는, 깃헙을 벤치마킹 한 것으로, 자신의서버에 설치가능한 오픈소스였으나, 깃헙처럼 서비스로 제공하기 시작했다.
- 깃랩은 특이하게,, 깃헙에서 깃랩을 사용안내하고 있다..

깃헙을 이용해서 원격저장소 만들고 로컬저장소를 연결하기

github에서 아이디를 만들어 준비를 한다

• 먼저, repository를 public으로 만든다. repository명은 현재 사용하고 있는 프로젝트 폴더와 동일하게 만들어보자.
  
  
  
• 만들어서 나오는 상단의 HTTPS/SSH 는 방금 만든 원격저장소의 URL같은 것이다.
  그 아래 나오는 명령어들은 명령어기반으로 원격저장소에 로컬저장소를 세팅할 수 있다. 하지만 우리는 GUI환경에서 사용하므로 일단 보류한다.
  
  
  
  

현재까지는 로컬저장소에서 고립된 상태에서 작업을 해왔다.
이제 원격저장소와 로컬저장소를 연결 후 업로드 해야한다.

원격저장소는 Remote Repository라고 한다. 이제 소스트리로 돌아와서, 원격저장소를 연결해보자.

• 소스트리로 돌아와, 상단 메뉴 중 [ Repository - Add Remote... ] 로 진입해보자.
  (이미 원격저장소가 추가되어있다면 Repository - Repository Settings에서 수정할 수 있다)
  
  
  
  
  Add버튼을 눌러서 원격저장소를 추가해주자.
  
  
  
  이제 깃헙의 만든 레퍼지토리의 HTTPS주소를 복사한 뒤,  URL/ PATH 칸에 붙혀넣자.
  이 때, 기본 원격저장소로 설정하기 위해서 Default remote도 체크해주자.
  
  
  
  
• 소스트리의 왼쪽메뉴 Remotes를 보면, 우리가 추가해준 원격저장소의 remote name인 orgin이 등장하게 된다.
  
  
  origin은 우리가 추가해준 원격저장소의 별명같은 것이다.
  상단 Repository - Repository settings에 들어가보면 확인할 수 있다.
  
  
  여기까지만 하면, 로컬저장소 - 원격저장소는 연결만 된 상태다.
  즉, 아직 동기화= 업로드하기 전 상태다.
  
  
  
• 로컬저장소 --> 원격저장소 로 밀어내는 행위가 바로 Push이다.
  상단 버튼중 Push버튼을 클릭해보자.
  
  
  
  Push할 원격저장소의 별명을 선택할 수 있다.
  그리고 동기화(업로드)하고 싶은 로컬저장소의 여러 Branch를 선택할 수 있다.
  실험적인 업무를 노출하고 싶지 않다면, master 브랜치만 선택해준다.
  
  
  
  
  
  
  
• 깃허브로 돌아가 Reload를 해보자.
  연결된 로컬저장소로부터 push된 소스코드가 업로드되어, 코드가 나와있다.
  우리가 수정한 README.md의 내용이 메인설명으로 나온다.
  
  
  Commits 메뉴를 선택해보면, 로컬저장소에서 작업했던 버전들이 확인이 된다.
  

여기까지만 하면, 로컬저장소가 고장나더라도, 원격저장소에서 받을 수 있고 버전도 확인할 수 있다.
백업으로서의 의미가 가장 크다고 생각하면 된다.

이제 로컬의 파일을 수정 후, 버전을 만든 뒤 ---> 원격저장소로 업로드 해보자.

• 파일을 수정 후, 로컬에서 commit하자.
  
  
  
  그랬더니, 소스트리에서는 Push버튼에 1이라는 표시가 나타나있다.
  이것은 로컬저장소와 원격저장소간에 1개의 버전차이가 존재한다는 것을 의미한다.
  타임라인의 master는 로컬저장소의 최신버전을 <--> origin(별명)/master는 원격저장소의 최신버전을 의미한다
  
  
  
• 하나의 버전을 더 commit해보자.
  원격저장소에서는 아직 2개의 버전이 업로드 되지 않았다는 것을 직감적으로 확인할 수 있다.
  
  
  이제 2가지 버전을 추가한 프로젝트를 Push해보자.
  로컬의 master와 원격의 origin/master가 같은 버전에 위치하는 것을 확인할 수 있다.
  

브랜치 : 실험적인 수정이 필요할 때, 프로젝트를 2개로 복사한 것같은 효과를 내어, 실험적인 수정작업을 한 뒤, master에 병합하기 위함
  - 병합 : master를-> 실험으로 주기적으로 병합해주다가, 실험작업이 완료되면, 실험->master로 병합 or 실험 브랜치를 포기한다.
  - 충돌 : 병합시 충돌상황에서는
     (1)충돌난 파일직접수정 ->
     (2)Git에서는 우클릭 - Resolve Conflicts - Mark resolved ->
     (3)commit을 통해 병합버전을 완료한다

브랜치를 사용하는 가장 큰 이유는 마스터브랜치와 실험브랜치를 병합하는데 있다.

실험브랜치에서 만든 변경점들을--->  master브랜치에다가 병합merge하는 것이 목표이다.

브랜치 병합하기( 실험--> master로)

• master에다가 병합하기 위해선, 먼저 master브랜치라는 받는 쪽 branch를 선택한 상태여야한다.
  이것을 master브랜치로 checkout했다 라고 한다.
• 이제 [실험] branch에서 우클릭하여, current branch(체크아웃되어있는 matser브랜치)로 병합해보자.
  
  
  
  나는 merge했더니, conflicts가 발생했다.
  
  
  working copy로 가서, index.html을 commit 해주니까 merge된것을 확인할 수 있었다.
  
  위와 같이 Merge brach '실험'으로서, 실험branch를 master에  merge했다.
  
  
• 해당버전의 수정내용을 살펴보자.
  실험branch에서 실험적인 업무로서 했던, < head태그추가 > + <title태그추가> 부분이 +초록색으로 추가된 것을 확인할 수 있다.
  
  
  
  
  
  
• 파일을 보면, master브랜치의 일상적인 업무<ul,  li태그 추가> 와 실험 브랜치의 실험적인 업무<head, title태그 추가>가 한 파일에 합쳐져 있는 것을 확인할 수 있다.
  
  같은 부모인 <h1태그 추가>에서 시작한 것을 유념해두자.

브랜치 병합에 있어서 충돌(Conflict) 해결하고 최소화 하기

브랜치를 통해서, 해당시점에서 마치 프로젝트를 복붙하여 2개처럼, 일상적인 업무 <--> 실험적인 업무를 나누어서, 병합으로 합쳤다.
하지만, 두 branch에서 같은 곳을 수정하게 되면, 충돌(conflict)가 일어난다.

*** 어떤 항목에 대해, 각 브랜치가 하나는 위쪽을 하나는 아래쪽을 따로따로 수정했다면 git은 충돌이 없는 것으로 판단한다.

*** 성공적으로 병합이 끝난 실험branch는 우클릭으로 삭제해도 된다.

• 이전시간까지 병합이 완료된 master브랜치에서 새로운 브랜치 [ 실험2 ] 를 만들어보자.
  브랜치를 만들 때, 항상 그 시점의 버전을 확인하자.  Merge branch'실험' 버전에서 실험2브랜치를 추가하였다.
  
  
  
• 실험2 브랜치에서, li태그를 하나 더 추가한 뒤, commit해주자.
  
  
  이번에는 master브랜치에서 똑같은 위치에 li태그(다른이름)으로 추가해보자.
  
  
  
  
• 이제 master브랜치에 병합해보자.
  받을 쪽인 master브랜치로 checkout하고,  실험2 브랜치에서 우클릭> merge해준다.
  아래와 같은 경고창이 뜬다.
  
  
  충돌한 이유는 , 하나의 파일안에서 2개의 브랜치가 같은위치의 내용을 수정했기 때문이다.
  git의 입장에서는 누구의 코드를 우선할지 모르니까, conflict를 낸 뒤, 사람에게 처리를 위임한다.
  
  
  
• 이제 병합시 conflict가 난 파일로 가보자
  <<< HEAD  와 ===== 와  >>>> 실험2로 나뉘는 것을 알 수 있다.
  이 때, =====를 기준으로 위쪽 HEAD는 현재 선택된 branch 즉, master 브랜치에서 수정한 내용이고,
  =====기준 아래쪽은, 적혀있는 실험2 브랜치에서 수정된 내용이다.
  
  
  만약 다 필요한 코드이면,  주석같은 << ==== >>>를 다 제거해주고 저장한다.
  
  
  
• 이제 소스트리의 Log/History의 Uncommited changes를 살펴보자.
  [ 느낌표모양의 주황색 삼각형 ] 아이콘이 있다. 이 것은 conflict가 났으니, 코드를 보고 판단해달라는 내용이다.
  \
  
  
  
• 충돌이 난 파일에서  [ 우클릭 - Resolved Conflicts - Mark Resolved]를 통해서,
  충돌이 난 상황을 << === >>> 수정을 통해서 해결했다고 git에게 알려준다.
  그러면,  [느낌표 삼각형] --> [ 연필 네모]로 바뀌면서, Stage로 자동으로 올라온다. 아직, 병합이 완료되진 않는다.
  
  
  
  
  
  
• 이 상태에서, commit버튼을 눌러보자.  자동으로 충돌난 내용을 해결했다는 문구가 적혀져있다.
  즉, 실험2내용을 master브랜치에 병합해왔다는 내용과 함께, index.html의 충돌을 일어났었다는 정보를 자동기재해준다.
  
  
  
  
• 충돌내용 수정 후,  Mark해주고, commit을 끝내니,  병합된 git(소스트리)의 버전이 새로 생김을 알 수 있다.
  

충돌을 최소화하는 방법

실험브랜치에서 6개월간의 수정작업 끝에, master브랜치와의 병합하게 된다면,,, 그것은 현실적으로 어려울 수 있다.
이것을 최소화하는 방법은, 실험 브랜치에다가 master브랜치를 끊임없이 동기화하는 것이다.

• 다시한번, [실험3]라는 브랜치를 만들고, master브랜치로 와서 내용을 수정해보자.
  master브랜치에서 li 충돌이라는 태그를 추가하고 commit한다.
  
  
  
  
• 이제 다시, [실험3]브랜치로 와보자. master브랜치에서 추가한 충돌이라는 li태그가 없는 상태일 것이다.
  
  
  
  [실험3]라는 실험적인 branch는 언젠가는 master브랜치에 병합되어야한다.
  언젠가는 될것이므로, 충돌을 최소화하기 위해, master브랜치의 내용을----주기적으로---> 실험3 branch에 가져다놓자.
  즉, 실험3 브랜치를 checkout한 상태에서, master브랜치 우클릭 - merge를 해준다.
  master브랜치에서 수정한 li충돌 태그가 실험3에 병합된 것을 확인할 수 있다.
  
  
  
  
• 실험3branch에서 다른 작업을 해보자. li충돌해결을 추가하고 커밋해주자.
  master branch에서도 li원격저장소 태그를 추가하고 커밋해주자.
  
  
  
• master와 실험적인 branch 각각에서 작업을 해준 다음,  실험3에서 또다른 작업을 시작할 타이밍이다.
  이때, master의 내용을 가져와서 실험3에 병합해주자.
  같은 곳을 수정하였으니, conflict가 날 것이다.
  위에서 했던 것 처럼 [ 파일에서 conflict해결후 저장  =>  merge받는 곳에서 Mark Resolved => commit ]을 통해 병합을 완료하자.
  
  
  
  
  *** 이 때, Resolve Conflics  메뉴의 Reslove Using 'Mine' / 'Theirs'는 (직접 파일 수정 없이)
  checkout되어 병합받는쪽(실험3)을 채택 / 병합되는 쪽 (master)을 채택할 수 있다.
  직접 파일을 보고 수정한다면, Mark resolved를 하면 된다.
  이렇게 master의 수정내용을 계속해서 받아들이면서, 실험3의 작업을 계속 이어가게 되면, 충돌이 최소화 될것이다.
  
  
• 이제 실험3에서 하나의 작업만 더 해준 뒤,  master에 최종병합시켜보자.
  실험3 브랜치에서 meta태그를 하나 추가시켜준다.
  
  
  master브랜치를 체크아웃한 뒤, 실험3브랜치를 merge해보자.
  충돌이 발생하지 않고, 바로 병합이 된다.
  [ 충돌파일 수정 -> Mark Resolved -> commit]의 과정없이 바로 병합된 것을 확인할 수 있다.
  
  
  
  이러한 방식으로 한다면, 충돌이 발생하더라도 더 작은 충돌이 발생할 것이다.
  
  master의 입장에서는 한번도 실험3가 존재하지 않았다.
  만약 실험3의 브랜치가 drop되어 폐기되었다면, 그냥 삭제해주면 된다.
  만약 필요하다면 , 이러한 과정을 거쳐서 , 최소한의 충돌로 master로 병합해주면 된다.