cansto Programming

이전 포스팅 : Git branch (브랜치 생성 방법과 이해)  Referrence 참고자료 (1)~(3)을 확인하자 (1) 현재 아래와 같이 master 와 testbranch, 2개의 브랜치가 있다. (2) master 브랜치가 checkout된 상태에서 Working Directory 의 wow.java 파일이다. (3) testbranch 브랜치가 checkout된 상태에서 Working Directory 의 wow.java 파일이다. How to merge branches 1. master 브랜치에 testbranch 브랜치를 merge 하기위해 master 브랜치를 더블클릭하여 checkout 상태로 두고 testbranch 를 우클릭한다. 그리고  Merge testbranch into current branch 를 클릭한다. 2. Confirm Merge 확인 창이 뜨면  확인 을 클릭한다. 3. 그 결과, Graph가 합쳐지고  Merge branch 'testbranch' 라는 Commit이 생성되었다. 4. Merge 후, master 브랜치가 checkout된 상태에서 Working Directory 의 wow.java 파일이다. 5. Merge 후, testbranch 브랜치가 checkout된 상태에서 Working Directory 의 wow.java 파일이다. Merge 전후 파일 상태가 변경되지 않는다.(참고자료 3번과 소스코드가 동일함) 다음 포스팅 : Git resolving merge conflicts as Mark resolved (mark resolved 옵션으로 해결)

언제 브랜치를 사용하는 지 예를 들면, 프로젝트 디렉토리에 중요한 실험적인 일이 추가됐다고 치자. 이 실험적인 일은 미래가 불분명하다. 완성 가능성이 낮고, 상품성이 없다던가, 법적인 요건이 충족이 안되는 등 여러가지 불확실한 업무이다. 이러한 불확실한 업무는 언제든지 프로젝트에서 필요없어질 가능성이 있다. 만약 필요없어지면 revert나 reset을 통해 되돌리기를 하면된다. 하지만 그렇게 쉬운 작업이 아니다. 불확실한 작업과 현재 진행중인 안정적인 작업을 동시에 진행하는 경우 굉장히 어려운 작업이 될 것이다. 또 다른 방법은 디렉토리를 통채로 복사해서 작업한다. 그러면 불확실한 작업과 안정적인 작업(현재 진행중인 일)을 따로 진행할 수 있다. 하지만 불확실한 작업이 완료되고 안정적인 작업에 붙여넣기를 해야해서 번거롭다. 그러나 git을 사용하면 브랜치를 이용해서 마치 두개의 프로젝트 폴더를 따로 가지고 각각의 폴더에서 작업하는 것과 같은 효과를 내면서, 동시에 불안정 작업을 끝내고 안정 작업(원본)에 자동화해서 병합해주는 기능을 제공해준다. 글로 백번 설명하는 것보다 실제 예제를 통해 브랜치를 생성하고 사용하는 방법을 알아보자. How to Create Brunch and Understanding 1. 현재 Working Directory 에 있는 wow.java 파일이다. 2. 소스트리 상단에 Branch 를 클릭한다. 3. New Branch 입력란에 생성할 브랜치의 이름을 입력한다. Commit 부분은 Working copy parent 를 체크하면 현재 Working Directory와 동일한 커밋들이 생성되는 것같다.  Create Branch 를 클릭한다. 4. 왼쪽에서 새로 생성한 브랜치를 더블 클릭하여 체크된 상태로 전환한다. master 브랜치와 같은 인덱스가 적용되어 있는 상태이다. 5. 다시 왼쪽에 master를 더블클릭하여 체크된 상태로 만든다. 6. 소스코드 3~...

server.xml을 통해서 tomcat이라는 web application server를 이해해보고자 한다. server.xml 설정에 목적이 있는 포스팅이 절대 아니다. 참고로 WAS는 J2EE 스펙(Servlet Container와 EJB Container의 기능)을 구현한 서버이지만, tomcat은 Servlet Container만 구현하고 EJB Container 기능은 없어서 WAS가 아니라는 사람도 있다. 그래서 ' 톰캣 == 서블릿 컨테이너 '라고 알고있어도 좋다. 무엇이든 제대로 알려면 공식 문서를 보는 것이 신뢰성도 높고 마음도 편하다. 그래서 아래 아파치 톰캣 config doc을 참조하여 tomcat WAS(서블릿 컨테이너)의 구조를 파악하려고 한다. https://tomcat.apache.org/tomcat-9.0-doc/config/index.html Top Level Elements  -  <Server>  is the root element of the entire configuration file, while  <Service>  represents a group of Connectors that is associated with an Engine. Connectors  - Represent the interface between external clients sending requests to (and receiving responses from) a particular Service. Containers  - Represent components whose function is to process incoming requests, and create the corresponding responses. An Engine handles all requests for a Service, a Host handles all requests fo...

이번에는 되돌리기 두번째 revert에 관해 알아보려고 한다. The difference between Reset and Revert - reset은 버전을 지우지만, revert는 버전을 유지한다. - reset은 선택한 버전으로 돌아가지만, revert는 선택한 버전의 변경사항을 반대로 수행해서 이전의 버전으로 돌아간다. - reset은 mode에 따라 다르지만, revert는 Working Directory에 영향을 주지 않는다. Precautions for Revert - 선택한 버전을 revert할 때 순차적으로 하지 않고 여러 버전을 건너뛰면 conflict가 발생할 수 있다. Understanding Revert 1. pending files에  +  README.md 파일이 있는 것을 보면, 이전 버전에는 없던 README.md 파일이 추가되었고 그 내용은 'this is git!'임을 알 수 있다. 만약 README.md 파일이 추가되기 전의 버전으로 돌아가고 싶다면 revert(reverse)를 이용하면 된다. 2. revert 하려는 버전을 우클릭하고  Reverse commit...  을 클릭한다. 3. reverse 확인 창이 뜨면  Yes 를 클릭한다. 4. revert 가 완료되어서 README.md 파일이 삭제되었다. 5. revert 전의 Working Directory 파일들이다. 6. revert(reverse)는 Working Directory에 영향을 주지 않는다. Revert in sequence several times & Why use the word "Revert"? 최근 커밋부터 순서대로 Revert를 하면서, Revert의 의미를 이해해보자. 1. "hello 추가" 버전을 현재 버전으로 적용하기 위해, 앞선 예제에서 한 Revert "this is git...

이번 시간은 reset에 대해 알아보자. reset에는 3가지 mode가 존재한다. Hard - discard all working copy changes Mixed - keep working copy but reset index Soft - keep all local changes Hard reset mode는 Working Directory와 버전을 선택한 버전으로 되돌린다(재설정). - 선택한 버전 이후의 버전은 없어진다. Mixed reset mode는 Working Directory는 유지하고 index는 재설정한다. - Working Directory는 유지되고 index는 재설정되었으므로 Uncommitted changes을 인식한다. - 유지의 의미는 변경되지 않는 다는 것이다. - 커밋한 소스코드에 보안에 영향을 줄 수 있는 secret key와 같은 정보가 존재하는 해당 커밋한 버전들을 모두 삭제하고 현재 작업 중인 working directory를 유지해야 하는 경우에 사용하면 좋다. Soft reset mode는 모든 로컬 변경 사항을 유지한다. Hard 와 Soft mode 만 이번에 예제를 통해 알아볼 것이다. Try using reset : Hard mode 1. 먼저 hard mode 로 reset 하려는 버전을 우클릭한다.  그리고  Reset current branch to this commit 을 클릭한다. 2. Using mode :  Hard - discard all working copy changes 를 선택하고  OK  클릭 3. 'Hard' reset mode 사용시 로컬 working copy의 변경사항과 index(staging area)를 모두 되돌릴 것이라는 경고창이 뜬다.  Yes 를 클릭한다. 4. hard mode 결과, 선택한 버전이 최종 버전이 되고 선택한 버전 이후의 버전은 ...