출처

https://stackoverflow.com/questions/2013091/coloured-git-diff-to-html

Git diff를 HTML에 색칠하여 표시하기

저는 파일에서 변경된 단어를 분명히 보기 위해 git diff --color-words를 사용하는 것을 즐깁니다.

하지만 git이나 색칠한 터미널 없이 다른 누군가와 diff를 공유하고 싶습니다. HTML로 색칠된 터미널 출력으로 변환할 수 있는 도구나 방법을 아시는 분이 있으신가요?

7개 답변 중 1개의 답변만 발췌

wget "http://www.pixelbeat.org/scripts/ansi2html.sh" -O /tmp/ansi2html.sh
chmod +x /tmp/ansi2html.sh
git diff --color-words --no-index orig.txt edited.txt | \
/tmp/ansi2html.sh > 2beshared.html

제가 필요했던 것은 ANSI를 HTML로 변환하는 것(converter)이었습니다. 그리고 저는 매우 어지간한 것을 http://www.pixelbeat.org/에서 발견하였습니다.

참고 : --color 또는 --color-words를 포함시키지 않으면 색상이 표시되지 않을 수 있습니다. 이는 아마도 파이핑(|)으로 인해 git diff가 색상을 제외시키기 때문일 수 있습니다.

참고 2 : 특히 Mac을 사용하는 경우 gnu sed 및 awk를 설치해야 할 수 있습니다. brew install gnu-sed gawk로 설치 하십시오. 경로에 수동으로 추가해야 할 수도 있습니다. 예 : ln -s /usr/local/Cellar/gnu-sed/4.2.2/bin/gsed /usr/local/bin/을 사용하십시오.

출처 

http://stackoverflow.com/questions/1186535/how-to-modify-a-specified-commit-in-git

Git에서 특정 commit만 수정하는 방법?

저는 리뷰하면서 commit의 모든 목록을 제출합니다. 만약, 

- HEAD

- Commit3

- Commit2

- Commit1

저는 git commit --amend로 HEAD commit을 수정할 수 있다는 걸 알지만, 어떻게 HEADcommit이 아닌 Commit1을 수정할 수 있을까요?

----

4 개의 답변 중 1개의 답변만 추려냄.

당신은 git rebase를 사용할 수 있습니다. 만약 commit bbc643cd으로 돌아가서 수정하고 싶으시면, 다음을 실행합니다.

$ git rebase --interactive 'bbc643cd^'

기본 편집기로, 수정하고 싶은 commit의 줄에서 'pick'을 'edit'로 변경합니다. 원하는 대로 작업 디렉터리를 변경하고 이전과 같은 메세지로 다음처럼 commit 합니다.

$ git commit --all --amend --no-edit (1)

commit을 변경하고, 다음을 입력하여

$ git rebase --continue

이전 HEAD commit으로 돌아옵니다.

경고 : 이는 모든 자식들까지 포함하여 SHA-1 commit이 바뀌게 됨을 아셔야 됩니다. 다른 말로, 이는 그 지점부터 앞으로 history (commit)을 다시 쓰게 됩니다. 만약 git push --force명령을 사용하여 push를 하면 이를 수행한 저장소는 망가질 수 있습니다.

---

역자주

https://git-scm.com/docs/git-commit

(1) git commit --all --amend --no-edit

--all : -a와 같은 의미로 수정되거나 삭제된 파일을 자동으로 stage 영역으로 올립니다.

--amend : commit을 추가하지 않고 마지막 commit을 수정합니다.

--no-edit : --amend와 결합하여 commit 메세지 변화없이 마지막 commit을 수정합니다.

출처 

http://unix.stackexchange.com/questions/44266/how-to-colorize-output-of-git

git의 출력에 색을 입히는 방법?

git(또는 명령어)에 대한 출력에 색을 입히는 방법이 있을까요?

다음은 예시입니다.

not stage

baller@Laptop:~/rails/spunky-monkey$ git status
# On branch new-message-types
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   app/models/message_type.rb
#
no changes added to commit (use "git add" and/or "git commit -a")
baller@Laptop:~/rails/spunky-monkey$ git add app/models

stage

baller@Laptop:~/rails/spunky-monkey$ git status
# On branch new-message-types
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   app/models/message_type.rb
#

출력은 같아보입니다만, 정보는 완전히 다릅니다. 파일이 위는 unstaged 상태이고 밑은 stage로 이동한 상태입니다.

이 출력에 색을 입히는 방법이 있을까요? 예를들어 unstage된 파일은 빨간색, stage된 것은 녹색으로요?

또는 Changes not staged for commit:는 빨간색, # Changes to be committed:은 녹색으로요?

Ubuntu에서 작업중입니다.

구글링해서 잘 작동하는 답변을 찾았습니다 : git config --global --add color.ui true

하지만 명령어 출력에 색을 추가하는 더 일반적인 해결책을 알고 싶습니다.

----

4 개의 답변 중 1개의 답변만 추려냄.

~/.gitconfig 파일에서 [color] 섹션을 생성합니다. 예를 들면 다음처럼 하실 수 있습니다.

[color]
  diff = auto
  status = auto
  branch = auto
  interactive = auto
  ui = true
  pager = true

[color "status"]
  added = green
  changed = red bold
  untracked = magenta bold

[color "branch"]
  remote = yellow

출처 

http://stackoverflow.com/questions/13040958/merge-two-git-repositories-without-breaking-file-history

파일 히스토리를 없애지 않고 두 개의 Git 저장소를 합치는 방법?

저는 2개의 Git 저장소를 새로운 3번째 저장소로 합치고 싶습니다. subtree 합치기를 사용하는 방법에 대한 많은 글을 찾았고(예를 들어, 어떻게 2개의 git 저장소를 합칩니까? 에 대한 Jakub Narebski의 답변) 이전 보관소로부터 모든 파일을 서브트리로 합치는 commit을 할 때를 제외하고 새로 추가된 파일들은 기록됩니다. 다음 명령어들은 대부분 작동합니다. git log 할 때 이전 저장소로부터 commit 히스토리를 볼 수 있지만 git log <file> 하면 subtree 합치기를 한 그 파일에 대한 하나의 commit만 보여줍니다. 위의 답변에 달란 댓글로 판단하였을 때 이러한 문제를 겪은게 저 혼자만은 아닌듯 보이며 이에 대해 게시된 해결책을 발견하지 못하였습니다.

저장소들을 합치고 각 파일의 히스토리를 남기는 방법이 있을까요?

----

4 개의 답변 중 1개의 답변만 추려냄.

여기에 히스토리를 다시 쓰지 않고 모든 commit  ID들이 유효하게 남아있게 하는 방법이 있습니다. 마지막 결과는 서브디렉터리에 두 번째 저장소 파일들이 있게 됩니다.

1. remote로 두 번째 저장소를 추가합니다.

cd firstgitrepo/
git remote add secondrepo username@servername:andsoon

2. 두 번째 저장소의 모든 커밋을 확실하게 다운 받습니다.

git fetch secondrepo

3. 두 번째 저장소로부터 지역 브랜치를 생성합니다.

git branch branchfromsecondrepo secondrepo/master

4. 서브디렉터리로 두 번째 저장소의 모든 파일을 이동시킵니다.

git checkout branchfromsecondrepo
mkdir subdir/
git ls-tree -z --name-only HEAD | xargs -0 -I {} git mv {} subdir/
git commit -m "Moved files to subdir/"

5. 첫 번째 master(마스터) 브랜치로 두 번째 브랜치를 합칩니다.

git checkout master
git merge branchfromsecondrepo

당신의 저장소는 하나의 root commit 이상 가지겠지만 문제가 되지는 않을 것입니다. 

출처 : http://git-scm.com/docs/git-log

이름

git-log - commit log를 보여줍니다.

요약

git log [<옵션들> [revision range] [[\--] <경로>...]

설명

commit log를 보여줍니다.

주어진 commit에서 부모(parent) 링크를 따라 도달할 수 있는 commit을 나열하지만 앞에 ^가 있는 commit에서 도달 가능한 commit은 제외합니다. 출력은 기본적으로 시간 역순으로 제공됩니다.

이것을 집합 연산으로 생각할 수 있습니다. 명령줄에 지정된 commit에서 도달할 수 있는 commit은 집합을 형성한 다음 앞에 ^가 표시된 커밋에서 도달할 수 있는 커밋을 해당 집합에서 뺍니다. 나머지 커밋은 명령의 출력으로 나오는 것입니다. 다양한 기타 옵션 및 경로 매개변수를 사용하여 결과를 추가로 제한할 수 있습니다.

다음 명령이 이 예시입니다.

$ git log foo bar ^baz

위 명령어는 "foo 또는 bar에서는 도달할 수 있지만 baz에서는 도달할 수 없는 모든 커밋을 나열"을 의미합니다.

특수 표기법 ".."는 "^ "의 약어로 사용할 수 있습니다. 예를 들어 다음 중 하나를 서로 바꿔서 사용할 수 있습니다.

$ git log A B --not $(git merge-base --all A B)
$ git log A...B

이 명령은 git-rev-list[1] 명령에 적용 가능한 옵션을 사용하여 표시되는 내용과 방법을 제어하고 git-diff[1] 명령에 적용 가능한 옵션을 사용하여 각 이 도입하는 변경 사항이 표시되는 방법을 제어합니다.

옵션

--follow

이름 변경을 포함하여 하나의 파일의 history(히스토리)를 조회합니다. (하나의 파일에 대해서만 작동합니다.)

예시)

[root@test test]#  git log --follow --oneline ab.txt
1f61b72 second commit      // a.txt ==이름변경==> ab.txt 
00f7289 test - initial commit // a.txt

--all

<commit>의 명령어에 대하여 refs/의 모든 the refs(참조들) 출력될 것입니다.

--no-decorate

--decorate[=short|full|no]

commit의 the ref(참조) 이름을 출력합니다. short이면 the ref(참조) 이름의 접두사 refs/heads/, refs/tags/, refs/remotes는 출력되지 않을 것입니다. full이면 the ref(접두어를 포함하여)의 전체 참조가 출력될 것입니다. 기본 값은 short입니다.

--graph

출력의 왼쪽 부분에 commit history(커밋 히스토리)를 텍스트 기반의 그래픽 표현으로 그립니다.

이는 그래프 history를 적절히 그리기 위해 commit들 사이에 부가적인 행(line)이 있을 수 있습니다.

--no-walk와 결합해서 사용할 수 없습니다.

이는 기본으로 --topo-order 옵션을 내포하지만, --date-order 옵션도 지정될 수 있습니다.

예시)

 [root@test test]# git log --all --graph --oneline --decorate
* 303c84e (HEAD, dev) test dev - 3
* e0de443 test dev - 2
* dd60246 (master) test master - 1

출처 : http://bitflop.com/tutorials/how-to-create-a-new-and-empty-branch-in-git.html

Git에서 새롭고 비어 있는 branch를 만드는 방법

출처 : http://stackoverflow.com/questions/1282639/switch-git-branch-without-files-checkout

Git: 파일 checkout 없이 git branch 변경하기

7 개의 답변 중 1개의 답변만 추려냄.

옙. 다음처럼 하시면 됩니다.

git symbolic-ref HEAD refs/heads/otherbranch

git reset

출처 : http://gitready.com/advanced/2009/01/17/restoring-lost-commits.html

잃어버린 commit들 복구하기

만약 당신이 마지막 commit을 버리기 위해 git reset --hard HEAD^ 를 실행하였습니다. 그런데 그 변경이 필요하지 않았음이 밝혀졌습니다.  당신은 두 번 다시 완벽하게 알고리즘을 구현할 수 없고 다시 원래대로 복구해야 합니다. 겁먹지 말고 git은 당신의 잃어버린 그 commit을 가지고 있습니다. reset할 때 당신이 버린 commit은 "dangling" 상태가 됩니다. 그것은 git의 데이터로 보관되어 있고 다음 garbage collection 때 치워질 것입니다. 당신이 위 명령을 실행했을 때 부터 git gc를 실행하지 않는다면 당신은 그것을 복구할 수 있습니다.

예를 들어 저는 이 블로그를 위한 코드를 작성하였습니다. 그리고 바로 다음을 실행합니다.

$ git show-ref -h HEAD
  7c61179cbe51c050c5520b4399f7b14eec943754 HEAD

$ git reset --hard HEAD^
  HEAD is now at 39ba87b Fixing about and submit pages so they don't look stupid

$ git show-ref -h HEAD
  39ba87bf28b5bb223feffafb59638f6f46908cac HEAD

우리의 HEAD는 하나의 commit으로 저장된 상태입니다. 이 때 우리는 git pull으로 그것을 원래대로 돌릴 수 있다면 우리의 local repository는 그 commit을 알고 있다고 가정할 수 있습니다. 우리는 그것을 원래대로 돌리기 위해 그 commit의 SHA1이 필요합니다. 우리는 fsck명령으로 그 commit에 대해 알고 있다는 것을 증명할 수 있습니다.

$ git fsck --lost-found
  [... some blobs omitted ...]
  dangling commit 7c61179cbe51c050c5520b4399f7b14eec943754

또한, git은 reflog명령을 사용하여 아직 그 commit에 대해 알고 있다는 것을 확인 할 수 있습니다.

$ git reflog
  39ba87b... HEAD@{0}: HEAD~1: updating HEAD
  7c61179... HEAD@{1}: pull origin master: Fast forward
  [... lots of other refs ...]

결국, 우리는 복구하고자 하는 SHA1:7c61179 을 알았습니다. 만약 현재 branch에 복구하고자 하는 그 commit을 바로 적용하려면, git merge함으로서 그 commit으로 복구할 것입니다.

$ git merge 7c61179
  Updating 39ba87b..7c61179
  Fast forward
    css/screen.css |    4 ++++
    submit.html    |    4 ++--
    2 files changed, 6 insertions(+), 2 deletions(-)

이 명령은 우리의 잃어버린 변화들을 되돌릴 것이고 HEAD가 그 commit을 가리키도록 보장할 것입니다. 여기서부터 평소처럼 작업을 이어서 할 수 있습니다. 또한, 당신은 새로운 branch로 복구할 SHA1을 checkout할 수 있지만 merge가 당신이 그 hash를 가지고 있을 때 잃어버린 commit을 복구하는 가장 빠르고 쉬운 방법입니다. 혹시 당신이 다른 방법을 알고 계시면 댓글을 남겨주세요!

만약 이러한 상황에서 할 수 있는 더 많은 option들을 알고 싶다면, Mathieu Martin’s illustrated guide to recovering lost commits with Git이 충분히 당신에게 도움이 될 것입니다.