블로그 이미지
Every unexpected event is a path to learning for you.

카테고리

분류 전체보기 (2702)
Unity3D (793)
Programming (471)
Server (33)
Unreal (4)
Gamebryo (56)
Tip & Tech (224)
협업 (57)
3DS Max (3)
Game (12)
Utility (136)
Etc (96)
Link (32)
Portfolio (19)
Subject (90)
iOS,OSX (50)
Android (14)
Linux (5)
잉여 프로젝트 (2)
게임이야기 (3)
Memories (20)
Interest (38)
Thinking (38)
한글 (30)
PaperCraft (5)
Animation (408)
Wallpaper (2)
재테크 (18)
Exercise (3)
나만의 맛집 (3)
냥이 (10)
육아 (16)
Total
Today
Yesterday
12-08 12:53

달력

« » 2023.12
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

공지사항

최근에 올라온 글

반응형

Jenkins에서 두 브랜치를 매일 자동으로 Merge 하려고 찾아보면서 삽질하고 정리해 둠.

shall script로 해야되는건가 했는데 의외로 Jenkins에 관련 메뉴가 다 있는 것 같다.

Jenkins 메뉴로 git merge(소스 코드 관리-Merge before build 메뉴) 하고, git origin에 push(빌드 후 조치-Git Publisher 메뉴)까지 처리함.

 

----

 

To implement this task you can follow the below given steps.

  • Set your GitHub repo with credentials.

 

 

  • After that you have to set your branch name to merge. Go to source code management->Additional Behaviours->Merge before build.

 

 

  • Set your user name and user email. Go to source code management->Additional Behaviours->Custom user name and email.

 

 

Now your job is ready to merge your branch. You can also go through the below GitHub link to get more information.

https://github.com/nadim70/Newproject.git

 

GitHub - nadim70/Newproject

Contribute to nadim70/Newproject development by creating an account on GitHub.

github.com

 

 

[출처] https://www.edureka.co/community/68544/how-to-merge-two-branch-in-github-using-jenkins

 

How to merge two branch in GitHub using jenkins

Hi Everyone, I want to merge two branch in GitHub using jenkins. But I am not able to do this task. Can anyone help me to implement this task?

www.edureka.co

 

[참조] https://osc131.tistory.com/89

 

[jenkins] GIT Publisher

[jenkins] GIT Publisher 작성일자 : 2018년 10월 20일환경 : Jenkins 2.129, JDK 1.8.0_101목표 : Jenkins Build 작업 진행 후 Build에 사용됐던 GIT 버전을 Tags로 저장 ( 일종의 백업 ) * Jenkins - Git 연동 설정 및 GIT Plugin 설

osc131.tistory.com

 

반응형
Posted by blueasa
, |
반응형

Windows SourceTree에서 Merge 하는 중에 Conflict가 발생하고나서,

Resolve using Theirs 혹은 Resolve using Mine을 선택해도 제목과 같은 에러를 내면서 해결이 되지 않는다.

 

인터넷 검색해보니 Conflict 난 리스트 중에 삭제된 파일이 있어서 제대로 해결이 되지 않는 것 같다.

 

아래 [참조] 링크의 해결방법은 간단히 보면 아래와 같다.

 

[해결방법]

1) Conflict 난 리스트 전체 선택 후, '삭제(Remove)'.

2) 1)에서 '삭제(Remove)'해도 리스트는 여전히 Conflict 난 상태로 보인다.(우측 diff에서는 충돌난 정보가 사라짐)

3) 2)의 상태에서 그대로 'Mark as resolved'를 해서 Conflict 정보를 Commit/Push 하고 종료 시킨다.

 

[추가]

내 경우는 3)을 하고 해결이 된 것 같아 보이지만 소실된 파일들이 있었다.

새로 Merge를 해도 Resolved를 시켜버려서 그런지 갱신된 정보가 없어서 Merge 할 게 없는걸로 보인다.

별 수 없이 별도로 파일을 추가해서 다시 Commit/Push 시켰다.

 

[참조] https://stackoverflow.com/questions/53227144/cannot-resolve-conflictsapplication-is-locking-files

 

Cannot resolve conflicts(application is locking files)

I am trying to pull from another branch into mine, and I get merge errors. When I try to resolve them, I get this error from SourceTree: "Could not update one or more files, please check that no ot...

stackoverflow.com

 

반응형
Posted by blueasa
, |
반응형

[링크] https://mentum.tistory.com/421

 

소스트리 git 대소문자 변경 인식시키기

오른쪽 위의 터미널을 열어서 git config core.ignorecase false 를 입력. 이후 새로고침을 해보면 대소문자가 변경되도 인식된다. 해당 세팅은 컴퓨터 마다 따로 설정해야 함.

mentum.tistory.com

 

반응형
Posted by blueasa
, |
반응형

[링크] https://dev-syhy.tistory.com/44

 

[Git] git revert 에러 (merge but no -m option was given)

회사 팀에서 git을 사용하고 있는데 내가 커밋한 내역까지는 아무 이상 없던 코드가 팀원이 푸시한 코드를 풀로 받고나니 아뿔싸... 지금까지 만들었던 코드들이 다 날아가버렸다 얼마전에 블로

dev-syhy.tistory.com

 

[링크] http://www.codingswede.se/2017/05/revert-merge-commit-using-sourcetree.html

 

Revert a merge commit using SourceTree

Update 1 (no need to investigate the parents) The use case I need this for is when a feature branch has been merged to master, and after ...

www.codingswede.se

 

반응형
Posted by blueasa
, |
반응형

[링크] https://okayoon.tistory.com/entry/git-Stash-%EC%86%8C%EC%8A%A4%ED%8A%B8%EB%A6%AC%EC%97%90%EC%84%9C-%EC%82%AC%EC%9A%A9%ED%95%B4%EB%B3%B4%EA%B8%B0

 

git Stash 깃 스태시, 소스트리에서 사용해보기

pull 받기 전 충돌날 것 같으면 사용합니다. 1.커밋하지 않은채로 스태시 버튼 클릭 2.스태시 이름을 정해주고 확인클릭 3.스태시 하위에 내가 저장한 목록확인, 커밋해야하는 파일들 사라진것을

okayoon.tistory.com

 

반응형
Posted by blueasa
, |
반응형

[링크] backlog.com/git-tutorial/kr/

 

누구나 쉽게 이해할 수 있는 Git 입문~버전 관리를 완벽하게 이용해보자~ | Backlog

누구나 쉽게 알 수 있는 Git에 입문하신 것을 환영합니다. Git을 사용해 버전 관리를 할 수 있도록 함께 공부해봅시다!

backlog.com

 

반응형
Posted by blueasa
, |
반응형

유니티의 소스 파일들을 Git을 통해 버전관리 하고 있는데,
이상하게 몇 개 어셋들이 제대로 싱크가 되지 않는 문제가 있었습니다.

이 어셋들이 뱉어내는 에러는 공통적으로 .dll 파일이 없어져서 문제였는데,
이것 때문에 Git을 안 쓸 수는 없는 문제라서 한동안은 각 작업자마다 해당 어셋을 다시 import하거나 dll 파일을 복사해 주는 식으로 해결했습니다.

그러다가 오랜만에 소스를  다시 받을 일이 생겨서 clone을 했더니 같은 문제가 생겼는데 그 사이 사용하는 어셋들이 늘어나다보니 수작업은 너무 귀찮았습니다.
(벌써 오래전에 해결했어야 했는데 말이죠)

구글링을 해 보고는 이 문제는 Git 클라이언트로 SourceTree를 사용하기 때문이라는 점을 알아냈습니다.

http://stackoverflow.com/questions/15515729/git-repository-ignoring-all-dlls

핵심은 SourceTree에는 Global .gitignore를 기본으로 제공하는데 이 파일에 *.dll 이 포함되어 있는거죠. (왜죠??)

이 파일은 아래의 경로에서 찾을 수 있고요.

Tools=>Options=>Git then “Edit File”

  1. .dll 을 찾아서 라인 앞에 #을 붙여서 주석처리 해 줍니다.
  2. 해당 프로젝트 선택하고
  3. GitBash(터미널)을 연 후,
  4. git add .
  5. git commit -m ‘dll 파일 추가’
  6. git push

이렇게 진행해 주시면 해결됩니다.

SourceTree 문제일 거라는 생각은 못해 봤네요.

 

[출처] https://heartgamer.wordpress.com/2015/12/07/unity-git%EC%9D%84-%EC%97%B0%EB%8F%99%ED%96%88%EC%9D%84-%EB%95%8C-dll-%ED%8C%8C%EC%9D%BC%EC%9D%B4-tracking%EB%90%98%EC%A7%80-%EC%95%8A%EB%8A%94-%EB%AC%B8%EC%A0%9C-%ED%95%B4%EA%B2%B0/

 

Unity, Git을 연동했을 때 dll 파일이 tracking되지 않는 문제 해결.

유니티의 소스 파일들을 Git을 통해 버전관리 하고 있는데, 이상하게 몇 개 어셋들이 제대로 싱크가 되지 않는 문제가 있었습니다. 이 어셋들이 뱉어내는 에러는 공통적으로 .dll 파일이 없어져서 문제였는데, 이것 때문에 Git을 안 쓸 수는 없는 문제라서 한동안은 각 작업자마다 해당 어셋을 다시 import하거나 dll 파일을 복사해 주는 식으로 해결…

heartgamer.wordpress.com

 

반응형
Posted by blueasa
, |
반응형

[위치] C:\Users\(사용자계정)\AppData\Local\Atlassian\SourceTree

 

[삭제해야 할 파일] password, userhosts

 

[링크]

https://igotit.tistory.com/entry/Git-SourceTree-%EC%9B%90%EA%B2%A9%EC%A0%80%EC%9E%A5%EC%86%8C-%EB%B9%84%EB%B2%88-%EC%A0%80%EC%9E%A5%EB%90%9C%EA%B2%83-%EC%82%AD%EC%A0%9C%ED%95%98%EA%B8%B0

 

Git. SourceTree. 원격저장소 비번,아이디 저장된것 삭제하기.

문제상황. SourceTree 에서 원격저장소에 푸시하는 초기 단계에서 아래와 같은 창에서 원격저장소 아이디와 비번 기록하고 붉은 박스의 Remember Password 체크 선택된 상태에서 Login 시도하면 해당 정��

igotit.tistory.com

 

[for Mac] blueasa.tistory.com/2353

 

[펌][Mac] Source tree 에서 Github Enterprise 계정 비번이 바뀐 후 인증문제 해결

회사에서는 Github Enterprise 계정을 사용하고있고 sso를 통해 하나의 계정으로 Github Enterprise 계정을 이용합니다. 주기적으로 sso 계정의 비번을 바꿔줘야 하기 때문에 비번을 바꾼 후에는 소스트리�

blueasa.tistory.com

 

반응형
Posted by blueasa
, |
반응형

병합과 재정렬은 대개 한 Topic(작업 단위)의 작업이 끝난 다음, 작업 내용을 Master branch에 반영해야 할 경우 수행하는 작업입니다.

새로운 Topic에 대한 작업을 할 때는 대개 Master Branch에서 새로운 Branch를 따서 작업한 뒤, 나중에 다시 Master Branch에 합치는 순으로 작업을 진행합니다.

병합과 재정렬에 대한 이해는 GIT으로 작업하기 위해 PM 뿐만 아니라 팀원도 알고 있어야 합니다. 병합과 재정렬에 관련된 작업 흐름을 어느 정도 이해하고 있어야 불필요한 추가 작업을 막을 수 있고, '이렇게 해도 되는데 왜 꼭 이렇게 하라고 하는거지?'라는 불만을 갖지 않게 될테니까요.^-^


특정 Commit을 선택해서 반영하기 - cherry-pick

다른 Branch에 있는 Commit을 선별적으로 현재 Branch에 반영하기 위한 명령어입니다. Cherry-pick이라는 이름에서 뭐에 쓰는 건지 예측이 될 것입니다.

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

git cherry-pick {Commit ID}

이 때, 현재 Branch는 작업 내역을 반영할 Branch(대개 Master)여야 하고, 가져오려는 Commit이 여러개인 경우 먼저 작성한 Commit부터 순서대로 가져와야 합니다.

Cherry-pick은 엄연히 말하면 Commit을 가져 오는 것이 아니라, 가져올 Commit과 같은 Commit을 새로 만들어서 현재 Branch에 덧붙이는 작업입니다. 즉, 현재 Branch에 붙는 Commit은 Commit ID가 달라집니다.

왜냐하면 A를 X로 바꾸는 Commit과 B를 X로 바꾸는 Commit은 작업 내용이 서로 다른 Commit이기 때문입니다. 설명이 복잡해 졌는데, 이해가 잘 안간다면 다음 한 문장만 기억해 두면 됩니다.

'Cherry-pick은 Commit을 새로 하는 것과 같다.'


여러 개의 Commit을 반영하기 - rebase

Rebase는 Cherry-pick과 유사하지만, 여러 개의 Commit을 동시에 다룰 수 있습니다. 즉, Cherry-pick으로 하는 작업은 Rebase 명령어로도 할 수 있습니다. 다만, Rebase는 여러 개의 Commit을 하나로 합치거나, 특정 Commit을 건너 뛰는 등 보다 복잡한 작업을 수행할 수 있습니다.


여러 개의 Commit을 순서대로 가져와서 반영하기

대상 Branch의 변경 사항을 모두 가져와서 현재 Branch에 반영하려 할 때 다음과 같은 명령어를 사용합니다. 

즉, 현재 Branch와 대상 Branch의 공통 조상부터 대상 Branch의 마지막 Commit까지의 모든 Commit을 순서대로 하나씩 가져와서 현재 Branch에 덧붙입니다.

git rebase {가져올 Branch 이름}

결과적으로, 대상 Branch는 변경되지 않고 현재 Branch에만 새로운 Commit이 생성되어 덧붙여집니다.


Commit의 순서를 재정렬하고 첨삭하기

Rebase 명령에 -i(interactive) 옵션을 덧붙여 사용하면 Commit들의 순서를 바꾸고 첨삭하거나, 몇 개의 Commit을 하나로 합치는 등의 작업을 수행한 뒤 가져올 수 있습니다.

Rebase 명령과 -i 옵션의 조합은 '리베이시'라고도 불리우며, 병합 작업 뿐만 아니라 현재 Branch에서 최근에 작업한 몇 개의 Commit들을 편집하고자 할 때도 유용하게 사용할 수 있습니다.

예를 들어, 다음과 같이 입력하면 현재 Branch의 HEAD로부터 3개의 Commit들을 편집할 수 있습니다.

git rebase -i HEAD~3

이 때, Rebase 작업 이후 Commit들은 Cherry-pick과 마찬가지로 모두 ID가 바뀝니다.

쉽게 생각해서 위 명령은 HEAD로부터 3개의 Commit들을 현재 Branch에서 모두 '들어낸 뒤', 순서를 바꾸거나 합치는 등의 작업을 하고 다시 하나씩 새로 Commit하는 것입니다.

'리베이시' 명령은 개발을 진행하면서 은근히 많이 사용되므로 눈여겨 보는 것이 좋습니다. 특히 위에서 예로 든 명령의 경우 심심치 않게 자주 사용하게 될 것입니다.


두 개의 Branch를 하나로 합치기 - Merge


3-Way Merge

3-Way Merge란 하나의 Branch를 다른 Branch에 합치는 작업을 의미합니다. 엄연히 말하면 부모 Commit이 둘 이상인 새로운 Commit을 만들어서 현재 Branch에 덧붙이는 작업입니다.

git merge --no-ff {합칠 Branch 이름}

옵션으로 넣은 --no-ff 는 Fast-forward Merge가 가능하더라도, 무조건 3-Way Merge를 수행하라는 의미입니다.

3-Way Merge 작업을 수행하고 나면 합칠 Branch에서 가져온 Commit이 몇 개 였던지 간에 현재 Branch에는 딱 하나의 Commit만 새로 생성됩니다. 따라서, Merge를 취소하고 싶다면 새로 생성된 Commit만 삭제해 주면 됩니다.


Fast-forward Merge

Fast-forward Merge는 합칠 Branch가 현재 Branch와 분기된 이후, 현재 Branch에 새로 생성된 Commit이 없을 경우 현재 Branch를 가리키는 HEAD를 합칠 Branch의 마지막 Commit으로 옮김으로써 Merge를 수행하는 방법입니다.

뭔가 복잡한 설명이 되었는데요, 그림을 보면서 설명해 드리도록 하겠습니다.

ff-merge.png
( 그림 출처: http://www.deferredprocrastination.co.uk/blog/2012/git-un-merge/ )

왼쪽 그림은 Commit B의 위치에서 develop branch를 새로 만든 뒤, 이후 develop branch에서 C, D, E의 세 개 Commit을 작성한 상황을 나타내고 있습니다.

develop branch에서 세 개의 Commit을 새로 작성하는 동안, master branch에는 새로운 Commit이 하나도 추가되지 않았습니다. 이 상황이 바로 Fast-forward Merge가 가능한 상황입니다.

여기에서 Fast-forward Merge를 수행하면 3-Way Merge처럼 두 개의 조상을 갖는 새로운 Commit을 만들어서 master에 덧붙이는 것이 아닌, master branch를 가리키는 Commit Pointer를 E Commit으로 옮기는 것으로 Merge를 끝마치게 됩니다.

즉, 결과적으로 Master branch에서 C, D, E Commit을 새로 작성하고 E commit에 develop이라는 새로운 이름을 붙여 준 것과 같아집니다.

Fast-forward Merge는 수행 속도가 빠르고 불필요한 Branch를 없애 주는 역할을 하지만, 두 개의 branch의 구분이 사라지기 때문에 프로젝트 관리 면에서 모호함이 발생할 수 있습니다. (위 그림을 보면 master branch와 develop branch의 구분이 사라졌음을 알 수 있습니다.)

git merge {합칠 Branch 이름}

Merge 명령에 별도의 옵션을 주지 않으면 기본적으로 Fast-forward Merge를 수행합니다. 단, Fast-forward Merge가 불가능한 조건일 경우 3-Way Merge를 수행합니다.

경우에 따라서 작업 기록을 남겨 두기 위해 Fast-forward Merge를 수행하지 말아야 될 경우가 있습니다. 이 경우 --no-ff 옵션을 주어서 3-Way Merge를 수행하면 됩니다.


Rebase VS Merge

Rebase와 Merge 모두 새로운 작업 내용을 Master branch와 합치는 데 사용할 수 있는 유용한 명령어입니다. 다만, 이 둘을 각각 언제 사용해야 할 지 잘 모르겠다면 다음 문장을 기억하고 있으면 됩니다.

'Merge는 Commit ID가 보존되고, Rebase는 새로운 Commit이 생성되므로 Commit ID가 바뀐다.'

그래도 잘 모르겠다면 PM에게 물어보면 됩니다. PM이 작업을 진행하는 스타일에 따라서 작업 내용을 Main stream branch에 반영할 때 Merge를 사용할 지, Rebase를 사용할지 달라지기 때문입니다.

GIT에 처음 입문하면 Commit ID가 달라지던 말던 작업 내용이 잘 반영되면 그만이지, 뭐가 중요하냐고 생각할 수도 있습니다. 하지만, 프로젝트의 규모가 커지면 이야기가 달라집니다.

원격 저장소에는 가급적 같은 작업을 수행한 Commit이 두 개 이상 존재하지 않도록 유지해야 합니다. 같은 작업 내용을 갖는 Commit이 두 개 이상 존재하면 지저분해지고, 프로젝트 관리상 좋지 않기 때문입니다.

역사가 오랜(?) 오픈소스 작업을 할 때는 Commit Log에 작업을 위한 정보가 담겨 있는 경우가 많고, 따라서 오랜 옛날의 Commit Log를 뒤져야 하는 경우가 많습니다. 이럴 때 같은 작업을 수행한 Commit이 둘 이상이라면 그것들을 모두 살펴봐야 하는 불상사가 발생합니다.

일반적으로, 로컬 저장소에서 병합하고 Push하는지, 혹은 작업 Branch를 Push하고 병합하는지에 따라 무엇을 사용할지가 결정됩니다.

핵심은 같은 작업을 하는 Commit이 둘 이상 발생하지 않도록 하는 것이므로, 다음과 같이 구분해서 사용하면 됩니다.

Rebase

로컬 저장소에서 작업을 위해 개인적으로 만든 Branch를 Main stream branch에 반영하여 Push 하기 위해 사용합니다. 로컬에 개인적으로 만든 Branch는 Push 이후 정리를 하면서 대개 삭제합니다. 대개 Hotfix와 같이 단기간에 끝나는 Topic의 경우 이 방법으로 작업합니다.

Merge

로컬 저장소에서 분기하고 작업한 Branch를 리뷰 등을 위해 원격 저장소에서 Push한 뒤, Review가 끝나고 PM이 Main stream branch에 병합하는 순서로 작업을 진행할 때 사용합니다. Branch가 그대로 유지되기 때문에 나중에 추가 작업을 해야 할 경우나, 큰 규모의 Topic인 경우 이 방법으로 작업합니다.



[출처] https://www.tuwlab.com/ece/22218

반응형
Posted by blueasa
, |
반응형

I love Git. I was very much a TFS purist up until the last year or so, but after using Git for a while now, I’m hooked. Whilst TFS certainly isn’t bad, I love the flexibility and the fact I can muck about to my hearts content in a DVCS without affecting anyone (unless I choose to). That doesn’t mean I love everything though, one of my biggest headaches recently has been tags.

Tags in Git are simply textual markers against specific commits, very much like branches (although tags don’t move). Generally they’re used to mark points in your commit history (i.e. versions etc), but they can – being just text – be used to mark anything really.

So what’s the problem? Well, the issue isn’t with tags themselves, it’s more with the fact they’re very, very annoying to kill. I purposefully say kill and not delete, because deleting a tag is actually very simple, it’s making sure that tag staysdeleted/dead that’s the problem. Once a tag has been pushed to a remote, it is automatically retrieved during any subsequent pulls, at this point the tag exists in the user’s local repository until they choose to delete it. But it also means that said user can also then re-push a single tag – or even worse, all their local tags – to a remote when doing a push.

To illustrate this, consider the following example:

  1. Bob creates the tag ‘foo’ against a commit and pushes this to a remote
  2. Fred pulls from the remote to update his local copy of a branch he’s working on with Jane
  3. Jane does the same as Fred, meaning both Fred and Jane now have Bob’s tag ‘foo’ in their local repos
  4. Bob realises that ‘foo’ is a terrible name for a tag and wants to delete it, so he deletes the tag locally and pushes the delete to the remote
  5. Fred has written some more code he wants to share with Jane, so – using his handy Atlassian SourceTree app – he pushes his changes. But; Fred doesn’t 100% understand what he’s doing, so he checks the “Push all tags” checkbox when doing his push, thus re-pushing the tag which Bob just deleted!
  6. Bob does a further pull later that day, and lo and behold, his poorly named tag ‘foo’ has reappeared in his local repository!
  7. Jane pulls again and also pulls down the once deleted tag, much to Bob’s annoyance

Alright, so the answer here is probably to give Fred some guidance about how to use Git, but it does illustrate the real life problem I had recently, the only difference was that in my situation there were lots more developers involved.

So how do you solve this? Well, the Git documentation states that – by default – tags are not pushed unless you specify otherwise (using the “tags” switch). So actually, Git does a pretty good job of preventing people from automatically sharing all their tags, but tools like SourceTree, which provide a seductive “Push all tags” checkbox when pushing – are clearly too tempting for developers to pass up:

SourceTreePushDialog   

Another option – and probably a better one than just relying on your developers to not push their tags – is to implement a pre-receive server side hook to check whether tags are being pushed and reject the push it the user doesn’t have permission. Unfortunately, if you’re using a hosted Git repository like GitHub or Bitbucket, you’re out of luck as they don’t currently provide the ability for you to edit hooks and unfortunately don’t allow you to apply permissions to tags. This is a real shame as the functionality is already there to control access to branches.

Of course, the final option is just to accept that tags are not really meant to be deleted after they’re pushed, which is all well and good if you and your developers understand this from the start, not so good if not!


[출처] http://thecurlybracket.com/2014/10/11/git-zombie-tags-from-hell/

반응형
Posted by blueasa
, |