利用Githug学习Github / Githug Challenge Log

Githug是一个入门和辅助学习Github的代码游戏，至今已有54个关卡。通关之后，我对于Github神器有了更多的体会，它值得我们进一步研究。

在这里，我向各位推荐这篇通关秘籍，如果遇到问题可以来这里找到答案。同时，我也想大家推荐匠艺社区Coding Style，在这里我遇到了VIM，遇到了Coding Dojo，遇到了Githug，它们在变成方面给了我莫大的帮助。谢谢！

Author: [Weiming]
Created: 2016/7/6

To learn comprehensive and advanced Github skills, I started to try Githug. Let's crack some rocks!

Repository for Githug: githug repo

If you are stuck, you could refer to here.

This picture explicitly explans the relations among various operations: helpful picture.

1. init

Type git in the shell to get a list of available git commands.
git init initializes a git repository under the current direcotry.

2. config

This level is about setting configurations such as your name and your email address to make your commit authenticate.

Type git help config to get more information, and then you can config some of the variables, like user.name and user.email, as the following in the shell:
git config [variables] [contents with quotes if necessary]

Or you can use git config --global user.name "bob"

Your changes could be reviewed in the config file under directory ./.git/config.

3. add

This level talks about adding new files to the staging area.

To add files to the staging area, you could do the followings:

• git add . # to add all the files in the current directory;

• git add README # to add the specified file only

4. commit

To commit and record changes to the repository, run the following:
git commit -m "Your message"

5. clone

git clone [target repository site]

6. clone_to_folder

git clone [target repository site] [target folder name]

7. ignore

The file .gitignore is used to intentionally ignore specified files in the repository.

> cat .gitignore  # show the content of .gitignore
> git help gitignore  # see more guidance
> gvim .gitignore  # to add your own files

If you change you .gitignore file, say you add some more files that you want them to be ignored, those files are still being tracked. Thus we need to untrack the newly ignored files first, and then make a new commit.
git rm --cached <ignored files>

8. include

Use ! to negate a patern. Add the following to the .gitignore file:

*.a
!lib.a

9. status

Type git status to check the tracked and untracked files.

10. number of files committed

git status

11. rm

rm is used to remove files from the working tree (namely the file disk) and from the index.

12. rm_cached

git rm --cached <files> is used to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left alone.

13. stash

git stash is used to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away in a local stack, and reverts the working directory to match the HEAD commit.

For Chinese unauthorized explanation, refer to: Chinese version

14. rename

git mv -k <old file> <new file> is used for this one.

15. restructure

First, you should commit the stage area because there are files in the working directory, if you check with git status.

Then, you can use mkdir and git mv -k <old files> ... <new directory> to complete the task.

16. log

git log shows the log info for recent commits.

17. tag

git tag new_tag after you commit.

18. push_tags

Technically, this is easy to crack down, using git push --tags # note that push operation doesn't push tags by default.

2016/7/6
However, for the last several levels and this current level included, I have to go through all the following steps again when entering a new level. I think it is because every level will automatically reset the git working space.

git config user.name "name"
git config user.email "[e-mail]"
git commit -m "your message"

2016/7/8
The question above solved.
This is because at the level 2 when I was setting my user.name and user.email, I omitted the parameter --global.

19. commit_amend

Sometims, after you have just make a commit, you find that some of the files are forgotten to be included to the staging area. Instead of make commit for a second time, we recommend:

git add <forgotten_files>
git commit --amend -m "amend forgotten files"

20. commit_in_future

You can specify the time of your commit, instead of using the current system time by doing `git commit -m "time machine" --date "2020-03-03 23:56"

21. reset

git reset # to reset the current HEAD to the specified state
git add <specified files>

22. reset_soft

git commit ...
git reset HEAD~1 --soft            # 1
edit something              # 2
git commit -a -c ORIG_HEAD  # 3

1. This is most often done when you remembered what you just committed is incomplete, or you misspelled your commit message, or both. Leaves working tree as it was before "reset".

2. Make corrections to working tree files.

3. "reset" copies the old head to .git/ORIG_HEAD; redo the commit by starting with its log message. If you do not need to edit the message further, you can give -c option instead.

23. checkout_file

git checkout <your file> ignores the modifications of files in the working space.

24. remote

git remote

25. remote_url

git remote -v # for more information

26. pull

git pull <remote name> <branch name>

27. remote_add

git remote add <remote name> <url>

28. push

git status
git rebase
git push <remote name>

29. diff

git diff shows the difference between two files.

30. blame

git blame <file name> shows the info of each line

31. branch

git branch <new branch name>

32. checkout

git checkout -b <new branch name> # create and switch to the new branch

33. checkout_tag

git checkout <tag name>

34. checkout_tag_over_branch

git checkout tags/<tag name>

35. branch_at

git branch <new branch name> HEAD~1 creates a branch based on the last commit, rather than the latest commit.

36. delete_branch

git branch -d <old branch name>

37. push_branch

git remote
git branch --list --remote
git push <remote name> <new remote branch name>

38. merge

git merge <branch name>

39. fetch

git fetch fetches branches and tags from one or more other repositories, along with the objects necessary to complete their histories.

40. rebase

The feature branch is ready to go into master, user rebase the feature branch onto our master branch.
git rebase master feature

41. repack

repack is used to combine all the objects that do not currently reside in a "pack", into a pack. A pack is a collection of objects, indicidually compressed, with delta compression applied, stored in a single file.

git repack -d # remove the redundant packs after packing

42. cherry-pick

Given one or more existing commits, apply the change each one introduces, recording a new commit for each. This requires your working tree to be clean.

git checkout new-feature
git log
git checkout master
git cherry-pick <the hash of the commit>

43. grep

git grep <your pattern> print lines matching a pattern.

This is indeed a helpful tool !

44. rename_commit

Use rebase to edit the message of a commit
git rebase -i HEAD~2 # HEAD~2 because the commit needing editing is the second last.

Then an interactive editor will open, and change pick to reword on the line you want to make changes. Save and quit. The shell will automatically run and ask for your change in a new window. Make changes and save. All done !

45. squash

Much of the same as the previous level.
The difference is changing pick to squash.

46. merge_squash

git merge --squash <branch name>
git commit -m 'all'

47. reorder

git rebase -i HEAD~3

48. bisect

bisect users a binary search algorithm to find which commit in your project's history introduced a bug.

Worth of digging in

git bisect start
git bisect good
git bisect bad <hash of first commit>
....  # some output
git bisect good  # well, I don't know why we should type good
....  # first bad commit found !

49. stage_lines

man git-add  # another way to view helps for git add

In the interactive add mode, try patch to selectively stage files.

50. find_old_branch

git reflog show <branch name>@{one.week.ago}

reflog records when the tips of branches and references were updated in the local repository.

51. revert

git log
git revert <hash of commit>

Use that to delete one commit that has already been commited, but not pushed.

52. restore

Thanks to great help.

git fsck --lost-found  # show your deleted commit in the dangling area
git reflog  # also shows your deleted commit, in the form of a log
git merge <hash of the commit>  # restore it

53. conflict

When you run into merge conflict after git merge <branch name>, there are ways to resolve the conflict.

Most typically, edit the problematic file and then:

git add <editted file>
git commit -m "resole conflict"

to seal the deal.

54. submodule

Use git submodule add <target repository> [<target directory>] to include the repo.

You can also check the include status by using git submodule status.

55. contribute

More levels? Huh, to be continued ...

For more about Github

廖雪峰Git教程
猴子逗能懂的GIT

2016/7/9