2019.08.20 Git 튜토리얼 보며 따라하기 - Branch(2), Rebase

1. git remote

git remote show [Remote NAME] → 원격 저장소의 정보를 보여줌. 보통은 origin이 Remote Name에 들어갈테고 origin 저장소의 정보 (로컬/원격 브랜치 정보, 그 브랜치가 포인팅하고 있는 원격 브랜치)를 나타낸다.

clone을 하고나면 origin/master는 origin 저장소의 최신 커밋을 포인팅한다. 그리고 로컬의 master브랜치는 origin/master 를 가리키게 된다.

origin/master에서 파생 된 브랜치에서 작업을 했는데 이 때 누군가가 master 브랜치를 업데이트 했다고 하자. 그러면 내 로컬의 origin/master 커밋 포인터는 예전 커밋을 가리키게 되는데 이때 comes in to play 하는 것이 fetch 명령어다.

현재 내가 작업중인 브랜치에서 단순히 git fetch origin 을 하게 된다면 현재 로컬의 저장소가 갖고 있지 않은 새로운 정보가 있으면 모두 내려받고, 받은 데이터를 로컬 저장소에 업데이트하고 나서, origin/master 포인터의 위치를 최신 커밋으로 이동시킨다.


git remote add [REPONAME] 으로 원격 저장소를 등록할 수 있다고 하는데 이미 origin 이라는 원격 레포가 있는 상태에서 실행하니까 똑같은 레포지토리를 가리킨다.

$ git remote add teamone <https://github.com/hyungjunk/Study.git>
$ git remote show
origin
teamone
$ git remote -v
origin <https://github.com/hyungjunk/Study.git> (fetch)
origin <https://github.com/hyungjunk/Study.git> (push)
teamone <https://github.com/hyungjunk/Study.git> (fetch)
teamone <https://github.com/hyungjunk/Study.git> (push)
$ git push teamone master
Everything up-to-date


2. Rebase

Rebase를 하든지, Merge를 하든지 최종 결과물은 같고 커밋 히스토리만 다르다는 것이 중요하다.
Rebase 의 경우는 브랜치의 변경사항을 순서대로 다른 브랜치에 적용하면서 합치고 Merge 의 경우는 두 브랜치의 최종결과만을 가지고 합친다.

git rebase : <현재 브랜치에 다른 브랜치의 변경사항을 머징하되, 히스토리를 일자 선형으로 관리하는 것>

브랜치가 뻗어나온 조상으로부터 변경사항이 여러개 생겼는데 동시에 다른 브랜치에서도 변경사항이 생겼다면 merge 하거나 rebase 하는 옵션이 있다. 

merge는 아주 명시적으로 다른 브랜치의 내용을 현재 브랜치에 가져왔다고 히스토리에 보여준다.
(현 브랜치의 커밋에 다른 브랜치의 화살표가 가리키는 것을 볼 수 있음)

반면 rebase는 다른 브랜치의 변경사항을 병합하지만, 브랜치 히스토리에 다른 브랜치의 개입을 볼 수 없다. 아니 개입은 있지만, 좀 더 정확히 말하자면 현 브랜치의 커밋을 다른 브랜치가 가리키는 것을 볼 수 없다. 왜냐하면 현 브랜치의 일자로 쭈욱 이쁘게 뻗어온 히스토리 안에 다른 브랜치의 커밋 내역도 포함되기 때문이다.

만약 A 브랜치 rebase onto B 브랜치를 한다면, A 브랜치에서 rebase를 할건데 (쉽게말해, 히스토리 예쁘게 만들건데) B 브랜치를 내 일자형 히스토리 안에 집어넣을것이다. 라고 선언하는 것이다.

물론 이 뒤에 다른 브랜치에서 머징은 필요하다.

A브랜치, B브랜치 모두 마스터 브랜치는 아닐 것이며 마스터에 병합하기 전에 아마 정리하는 용도로 사용할 것이다.

용례: 자식 브랜치에서 쭉 커밋을 해왔는데 그 동안에 master 브랜치도 많이 업데이트 되었다.
그럼 자식 브랜치에서 master branch를 onto대상으로 두고 리베이스를 하면, 마스터의 내용이 머징이되는 동시에 커밋 히스토리도 선형적으로 변한다. 컨플릭은 날 수 있으므로 체크해줘야 한다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

로컬 Tomcat 서버 실행속도 개선

Eclipse에 Tomcat 8.5를 연동한 후에 서버를 실행할 때마다 속이 터지는 줄 알았다. 한 번 실행하면 근 10초를 넘게 기다려야 하니 습관적으로 코드를 수정하면 계속해서 10초씩 날려먹는게 너무나 아까웠는데.. 인터넷 서핑하며 방법을 찾아보고 적용하니 성공적! 평소 실행속도 16~18초 걸리던 것이 이제 1초 이하로 나온다. 수정한 항목은 총 3개이다. 먼저 Tomcat 서버 폴더\apache-tomcat-(버전)\conf로 진입 1. catalina.properties 파일 수정 파일을 열고 보면 tomcat.util.scan.StandardJarScanFilter.jarsToSkip=.............// 굉장히 긴 코드가 있다. 아래처럼 모든 jar파일을 Skip하도록 바꿔주자. tomcat.util.scan.StandardJarScanFilter.jarsToSkip= *.jar * 18/8/1 추가 : 당시에는 jar가 뭔지도 모르고 속도 개선만을 위해 저렇게 모든 jar Scanning을 Skip하도록 변경했는데 사용하는 jar가 util에 있다면 주의해야 할 것 같다. 하지만 가끔씩 util에서 불러오는 라이브러리를 소스코드에서 import 하면 정상작동한다. 2. Context.xml 파일 수정 파일 내 Context 태그 안에 <JarScanner scanClassPath="false"/>를 아래와 같이 추가한다. <Context>     <JarScanner scanClassPath="false"/>     <!-- Default set of monitored resources. If one of these changes, the    -->     <!-- web application will be reloaded.      ...
자세한 내용 보기

2019.05.23 - SQLAlchemy 의 객체 상태 관리 (expire, refresh, flush, commit) 에 관한 이해

SQLAlchemy에서 모델을 다루는 stage에 대해 알아보았다. Expire I've made some changes to an object and don't need it immediately but don't want any subsequent methods to use stale values. db.session.expire(Model) Refresh I've made some changes to an object and need its updated values immediately. Costs extra database call as it expires and reads from database immediately. Flush Push changes from memory to your database's transaction buffer. No database statements are issued yet. If Session has autocommit: False, must still call commit() to persist the changes or rollback() to discard changes. If Session has autocommit: True and you are not explicitly in a transaction, commit() will be automatically called. Commit Persist changes in your database's transaction buffer to the database. Database statements are issued. Automatically expires objects. Merge Used when you may have more than 1 in-memory objects which map to the same database record with some ke...
자세한 내용 보기

2020.02.17 Python의 multiprocessing 중 Pool.map(), chunksize에 관한 내용

먼저 동시성에 대한 개념, 쓰레드, 프로세스, 비동기에 대한 내용은 알고 있다고 가정하고 실제 코드 사용법에 대해 적어두었습니다. * Pool.map()  def _map (): pool = multiprocessing.Pool() pool.map(summing , [ 10_000_000 + i for i in range ( 5 )]) pool.close() pool.join() # optional (하단에서 설명) 위에서 볼 수 있듯이 map() 함수는 - Python의 빌트인 함수 map처럼 인자로 실행할 함수, 인자(iterable) 를 취한다. - 프로세스에게 함수와 iterable의 인자를 분배하고 각 프로세스가 그 함수를 처리하도록 한다. 사람 언어로 표현하면 일감을 처리하는 방법과 일감에 필요한 재료를 각 일꾼에게 분배하는 것이라고 생각하면 된다. - pool을 생성하면 최초에 프로세스의 개수를 지정하거나 위 예시처럼 비어있도록 둘 수 있는데 그냥 비어있도록 두는 경우에는 현재 코드가 돌아가는 machine의 CPU core 갯수만큼의 process가 생성된다. * 예시) 3곳의 레스토랑에 전화해서 예약을 하려고 하는데 직원 3명(프로세스 3개)에게 이를 시키는 상황을 코드로 표현하면 아래와 같다. def call_restaurant (phone_num): print ( f'Calling { phone_num } to make a reservation!' ) def make_reservations (): pool = multiprocessing.Pool() pool.map(call_restaurant , [ 1 , 2 , 3 ]) # 전화번호는 귀찮으니 1,2,3이라고 가정했다. pool.close() 1) A에게 (전화해서 식당 예약하기, 전화번호1) 2) B에게 (전화해서 식당 예약하기, 전화번호2) 3)...
자세한 내용 보기