분류 전체보기

[Git] 2. Git 기본 명령어

2021. 11. 10. 22:39
728x90
반응형

Git 관련 용어

Git을 사용하게 되면, 여러가지 용어들과 마주치게 됩니다. 이번에는 Git 사용시 알아두어야 할 기본적인 용어에 대해서만 간략하게 정리하려고 합니다. 

 

 

 

대표적인 Remote Repository 에는 GitHub가 있다.

Repository

기본적으로 저장소를 나타내는 용어 입니다. SVN은 Remote Repository 만 존재하는 반면, Git의 경우에는 Local Repository 와 Remote Repository 가 둘다 존재합니다.

작업을 할 경우에는 Local 저장소에서 진행하고, 협업이 필요할 경우, 혹은 개발이나 수정작업이 완료되었을 경우 Remote 저장소에 Push 함으로서 자료를 공유할 수 있습니다.

 

 

Checkout

특정 시점이나, Branch 소스 코드로 이동할때 사용하는 과정을 의미한다.

 

 

 

Stage

저장소에 커밋하기 전에 커밋을 준비하는 위치.

작업한 내용이 올라가는 임시 저장 영역이며, 이 영역을 이용하여 작업한 내용 중 커밋에 반영할 파일만 선별하여 커밋을 수행할 수 있습니다.

 

 

출처 : https://dev.to/shahabbukhari/git-simplified-working-collaboratively-with-gitgithub-5349

 

 

Commit

현재 변경된 작업 상태를 점검을 마치면 확정하고 저장소에 저장하는 작업.

각각의 커밋은 의미 있는 변경 단위 이고, 그에 대한 설명을 커밋 로그에 남깁니다.

 

 

Push

로컬 저장소에서 작업한 내용중 원격 저장소에 반영되지 않은 커밋된 내용을 원격 저장소로 보내는 과정을 의미한다.

 

 

Pull

원격 저장소에 있는 내용 중 로컬 저장소에 반영되지 않는 내용을 가져와서 로컬 저장소에 저장하는 과정을 의미한다.

 

 

Fetch

원격 저장소의 변경 사항을 가져오기만 하고, 현재 Branch에 병합은 수행하지 않는다.

 

 

Branch

커밋을 단위로 구분된 소스코드 타임라인에서 분기해서 새로운 커밋을 쌓을 수 있는 가지를 만드는 것, 혹은 그 가지를 브랜치라 합니다

Git에서는 여러개의 로컬 브런치를 가질 수 있으며, 그 로컬 브런치들은 서로 완벽하게 독립적이기 때문에 개발 중 수행하는 생성, 머지, 삭제 명령도 독립적으로 수행된다.

 

 

 



 

 

Merge

Branch와는 반대되는 개념으로, 하나의 Branch를 다른 Branch와 합치는 과정을 의미한다.

즉, 두개의 Branch를 하나로 합치는 것을 의미한다.

 

 

Tag

커밋의 정해진 위치에 쉽게 찾아 갈 수 있도록 붙여넣은 이정표를 태그라고 합니다.

태그로 지정한 커밋 내용에 쉽게 체크아웃해서 변경 할 수 있습니다.

 

 

Cherry-Pick

다른 Branch에 있는 Commit을 선별적으로 현재 Branch에 반영하기 위한 명령어입니다.

체리 나무에 달려 있는 체리를 하나씩 골라 따듯이, 커밋들이 달려 있는 커밋 나무(?)에서 필요한 커밋들을 하나씩 선별해서 가져 오기 위한 명령어가 바로 cherry-pick입니다.

 

 

 

 

 

 

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받고 있습니다.

 

 

 

 

728x90

[Git] 1. Git 개요

2021. 11. 9. 14:04
728x90
반응형

 

Git이란?

Git은 Linux 커널 소스 코드를 관리에 사용하기 위해 Linus Torvalds 가 직접 개발한 분산형 버전 관리 도구이며,

소스코드를 효과적으로 관리하기 위해 개발된, '분산형 버전 관리 시스템' 입니다.

깃(Git)은 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템이다.
- 위키백과

 

버전관리란?

여기서 말하는 버전관리란? 파일 변화를 시간에 따라 기록했다가, 나중에 특정 시점의 버전을 다시 꺼내올 수 있는 시스템이다.

우리는 일상생활에서도 꼭 버전관리 시스템을 사용하지 않더라도, 하나의 파일을 버전 혹은 날짜를 기입해서 사용했던 경험이 있을겁니다.

이 또한 버전관리의 일부이다.

 

버전관리 시스템

버전관리 시스템은 크게 두가지로 구분됩니다.

  1. 중앙 집중식 버전관리 시스템 (CVCS)
    • 프로젝트를 진행하다 보면 다른 개발자와 함께 작업해야 하는 경우가 많다. 이럴 때 생기는 문제를 해결하기 위해 CVCS(중앙집중식 VCS)가 개발됐다.
    • CVS, Subversion, Perforce 같은 시스템은 파일을 관리하는 서버가 별도로 있고 클라이언트가 중앙 서버에서 파일을 받아서 사용(Checkout)한다.
    • 이 CVCS 환경은 몇 가지 치명적인 결점이 있다. 가장 대표적인 것이 중앙 서버에 발생한 문제다. 만약 서버가 한 시간 동안 다운되면 그동안 아무도 다른 사람과 협업할 수 없고 사람들이 하는 일을 백업할 방법도 없다.
    • 그리고 중앙 데이터베이스가 있는 하드디스크에 문제가 생기면 프로젝트의 모든 히스토리를 잃는다.
    • 물론 사람마다 하나씩 가진 스냅샷은 괜찮다. 로컬 VCS 시스템도 이와 비슷한 결점이 있고 이런 문제가 발생하면 모든 것을 잃는다.
    • Subversion, CVS
  2. 분산 버전 관리 시스템 (DVCS)
    • DVCS에서의 클라이언트는 단순히 파일의 마지막 스냅샷을 Checkout 하지 않는다.
    • 그냥 저장소를 히스토리와 더불어 전부 복제한다.
    • 서버에 문제가 생기면 이 복제물로 다시 작업을 시작할 수 있다.
    • 클라이언트 중에서 아무거나 골라도 서버를 복원할 수 있다.
    • Clone은 모든 데이터를 가진 진정한 백업이다.
    • Git, Mecurial, Bazaar, Darcs

 

Git의 장점

  1. Local 영역과, Remote 영역이 분리되어 관리될 수 있다.
  2. 소스 코드를 주고 받을 필요 없이, 같은 파일을 여러 명이 동시에 작업하는 병렬 개발이 가능하다.(브랜치를 통해 개발한 뒤, 본 프로그램에서 합치는 방식(Merge)으로 개발을 진행할 수 있다.)
  3. 분산 버전 관리이기 때문에 인터넷이 연결되지 않은 곳에서도 개발을 진행할 수 있고,중앙 저장소가 날라가 버려도 원상복구할 수 있다.
  4. 팀 프로젝트가 아닌, 개인 프로젝트일지라도 Git을 통해 버전 관리를 하면 체계적인 개발이 가능해지고, 프로그램이나 패치를 배포하는 과정도 간단해진다.

 

Git 특징

  • 소스코드 주고받기가 필요 없고, 같은 파일을 여려 명이 동시에 작업하는 등 병렬 개발이 가능해지며, 버전 관리가 용이해져 생산성이 증가합니다.
  • 소스코드의 수정 내용이 커밋 단위로 관리되고, 패치 형식으로 배포할 수 있기 때문에 프로그램의 변동 과정을 체계적으로 관리할 수 있고, 언제든지 지난 시점의 소스코드로 Checkout 할 수 있습니다.
  • 새로운 기능을 추가하는 Experimental version을 개발하는 경우, 브랜치를 통해 충분히 실험을 한 뒤 본 프로그램에 합치는 방식(Merge)으로 개발을 진행할 수 있습니다.
  • '분산' 버전관리이기 때문에, 인터넷이 연결되지 않은 곳에서도 개발을 진행할 수 있으며, 중앙 저장소가 폭파되어도 다시 원상복구할 수 있습니다.

 

 

참고

https://linked2ev.github.io/devlog/2018/08/27/Git-1.-What-is-Git/

https://goddaehee.tistory.com/91

https://git-scm.com/book/ko/v2/시작하기-버전-관리란%3F

 

 

 

 

 

 

 

 

 

 

 

 

 

 

728x90
728x90
반응형

한번 설치하게 되면, 계속해서 사용하고 있기 때문에, 간혹 Redis의 설치 위치를 까먹는 경우가 있어서

기본적인 위치만 정리해서 남겨놓으려고 합니다.

 

서비스파일은 

/etc/init.d

경로에 위치하고 있으며, 기본적으로 설치하셨다면 redis_6379 파일에 기본적인 서비스 정보가 기입되어 있습니다. 

해당  경로에 있는 redis_6379 파일을 vim 명령어로 열어보면, 기본적으로 어떤 구성으로 되어 있는지 확인 할 수 있습니다.

아래 내용은 생략하고, 

서버 : /usr/local/bin/redis-server

클라이언트 : /usr/local/bin/redis-cli

등등 기본적인 파일 위치를 확인 할 수 있습니다. 

 

 

버전확인

root@localhost:/:] /usr/local/bin/redis-cli --version

 

728x90
728x90
반응형

 

Jenkins를 사용하다보면, cmd 및 batch script 를 이용해서 여러가지 프로세스를 제어하는 방법을 사용합니다. 

그중에 가장 많이 사용하는 것중에 하나가, 프로세스를 실행하고 죽이능 script가 아닐까 싶은데요.

물론 개인적인 의견입니다.

 

비교적 batch script 작성이 쉬운 것중에 하나가 taskkill 명령어를 이용해서 프로세스를 정지하는 것인데요.

그냥 taskkill만 사용하다 보면, 프로세스가 의도치 않게 정지된 경우, 젠킨스(Jenkins)에서 오류로 인식하는 경우가 발생합니다. 이를 해결하기 위해서 tasklist 명령어를 이용해서 사용하는 방법을 정리 하였습니다. 


 

 

 

방법 1

@echo on

tasklist /fi "imagename eq notepad.exe" |find ":" > nul
if errorlevel 1 taskkill /f /im "notepad.exe"

EXIT /B 0

 

 

방법 2

@echo off
tasklist /fi "imagename eq notepad.exe" | find /i "notepad.exe" > nul
if not errorlevel 1 (taskkill /f /im "notepad.exe") else ( echo not working process )
exit

 

 

방법 3

tasklist | find /i "notepad.exe" && taskkill /im notepad.exe /F || echo process "notepad.exe" not running.

 

 

방법 4

@echo off
set run=
tasklist /fi "imagename eq notepad.exe" | find ":" > nul
if errorlevel 1 set run=yes
if "%run%"=="yes" echo notepad is running
if "%run%"=="" echo notepad is not running
pause

 

 

 

 

참고

https://stackoverflow.com/questions/15449034/batch-program-to-to-check-if-process-exists

 

728x90
728x90
반응형

 


GitLab을 이용해서 Webhooks Push 이벤트 등록할 때, 아래와 같은 오류 메시지를 만나는 경우가 있습니다. 

로컬 네트워크에 대한 요청이 허용되지 않았다는 메시지 인데요.

 

 

Url is blocked: Requests to the local network are not allowed

 

 

아래의 Setting을 통해서 해결이 가능합니다. 

 

 

Gitlab 버전에 따라 상이하겠지만, 

Outbound requests 에 Allow requests to the local network form hooks and services 를 체크해줍니다.

 

이후 Webhooks를 등록할때, 정상적으로 등록이 되었습니다!!

 

 

 

 

 

 

 

 

728x90

'Git, SVN' 카테고리의 다른 글

[Git] 2. Git 기본 명령어  (0) 2021.11.10
[Git] 1. Git 개요  (0) 2021.11.09
[SVN] SVN Log 명령어  (0) 2021.05.13
[SVN] TortoiseSVN 설치하기  (0) 2020.04.08
[Git] Windows Tortoisegit 설치하기 - 거북이git 설치  (0) 2020.01.16
728x90
반응형

 

코로나 19 로 인해서 재택근무가 길어짐에 따라서, 회사내 PC 에 원격을 접속해서 근무하는 환경으로 업무를 진행하고 있는데요. 어느 순간부터 간헐적으로 원격 데스크톱이 멈추는 현상이 발생하였습니다.

재택의 인터넷이 느리다면... 주로 발생하는데요

아직까지 기가망을 사용하고 있지 않다보니, 자주 발생하였습니다. 

코로나 때문에 인터넷 망을 바꿔야 하나 심각하게 고민했었죠;;

 

일단 느린건 감안을 하더라도, 원격 데스크톱이 멈추고 다시 연결이 안되는 이슈가 발생하는것은 이상하다고 생각되서 해결 방법을 공유합니다.

 


원인

Windows 내 RDP v8 부터 UDP를 사용했는데, Windows 10의 특정 버전에서 TCP 와 UDP 프로토콜 사이를 원활하게 전환 할 수 없는 이슈가 있다고 합니다.

MS 공식적인 버그로 확인되었으며 2021년 6월 14일에 Patch를 발표하였다고 합니다.

 

 

https://support.microsoft.com/ko-kr/topic/2021%EB%85%84-6%EC%9B%94-21%EC%9D%BC-kb5003690-os-%EB%B9%8C%EB%93%9C-19041-1081-19042-1081-%EB%B0%8F-19043-1081-%EB%AF%B8%EB%A6%AC-%EB%B3%B4%EA%B8%B0-%EB%A7%8C%EB%A3%8C-11a7581f-2a01-47d5-ba12-431709ee2248

 

https://support.microsoft.com/ko-kr/topic/2021%EB%85%84-6%EC%9B%94-15%EC%9D%BC-kb5003698-os-%EB%B9%8C%EB%93%9C-18363-1645-%EB%AF%B8%EB%A6%AC-%EB%B3%B4%EA%B8%B0-1ecf117e-1f89-40f9-a0a5-ed5766737620

 

 

가급적 최신 버전으로 Windows 업데이트를 진행하면 해결되는것 같으나, 

아래 사항을 다시 한번 체크해보는 것도 좋을 것 같습니다.

 

Windows의 버전은 

제어판 -> 시스템 -> 정보 탭에서 확인 가능합니다.

 

저의 경우는 Windows 10 Pro의 21H1 버전이네요. 

그래도, 아래의 사항을 추가적으로 체크해서 해결하였습니다. 

 

 


해결방안 1

Windows 10 1909 이상 사용자

 

Windows 업데이트를 통해서 최신 버전으로 진행

  1. Windows 설정
  2. 업데이트 및 보안
  3. Windows 업데이트

 

 

 


해결방안 2

※ Windows 10 1903 이하 사용자 (Windows 10 Pro)

 

  • 윈도우키 + R (실행)
  • gpedit.msc 입력
  • 컴퓨터 구성
  • 관리템플릿
  • Windows 구성요소
  • 터미널 서비스
  • 원격 데스크톱 연결 클라이언트
  • Turn Off UDP On Client 사용으로 변경

 

 

 


해결방안 3

※ Windows 10 1903 이하 사용자 (Windows 10 Home)

 

  1. 윈도우키 + R (실행)
  2. regedit
  3. HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client
  4. 마우스 오른쪽 버튼 클릭 -> 새로 만들기
  5. DWORD(32비트)
  6. 새 DWORD 이름을 fClientDisableUDP 로 지정
  7. 10진수 선택 후 값 1로 설정

 

 

728x90

+ Recent posts