Shulou(Shulou.com)05/31 Report--

This article mainly explains "case Analysis of Git use skills". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Now let the editor to take you to learn the "Git use skills case analysis" bar!

Basic skills 1. The first step after installation

After installing git, the first thing you should do is to set up your name and email, because this information is used every time you submit:

$git config-- global user.name "someone" $git config-- global user.email "someone@gmail.com" 2. Git is pointer-based

Everything saved in git is a file. When you create a submission, a file containing your submission information and related data (name, email address, date / time, previous submission, etc.) is created and linked to a tree file. This tree file contains a list of objects or other trees. The object (or binary large object) mentioned here is the actual content related to this submission (it is also a file, and although the file name is not included in the object, it is stored in the tree). All of these files use the sha-1 hash value of the object as the file name.

In this way, branches and tags are simple files (basically) containing sha-1 hashes pointing to the submission. Using these indexes brings excellent flexibility and speed, such as creating a new branch by simply creating a file with the branch name and the committed sha-1 index. Of course, you don't have to do this yourself, just use the git command line tool (or gui), but it's really that simple.

You may have heard of an index called head. This is just a simple file that contains the sha-1 index value of the submission you are currently pointing to. If you are resolving a merge conflict and see head, this is not a necessary special position on a particular branch or branch, just indicates your current location.

All branch pointers are stored in .git / refs/heads, head in .git / head, and tags in .git / refs/tags-you can go in and have a look.

3. Two dads (parent node)-you read it right!

When you view the information of a merge commit in history, you will see that there are two parent nodes (different from the case of a regular commit on the working copy). The first parent node is your branch, and the second is the branch you merged.

4. Merge conflict

At present, I believe you have encountered a merger conflict and resolved it. Usually edit the file, remove the logo, and keep the code that needs to be left behind. Sometimes it's nice to see the code before these two changes, for example, before the two branches that are now in conflict. Here is one way:

$git diff-- mergediff-- cc dummy.rb index 5175ddeMagol 0c65895.. 4a00477-puts hello world + + puts "annyong haseyo" end end

If it is a binary file, it is not so easy to compare the differences. Usually all you have to do is test the two versions of the binary to decide which one to keep (or copy the conflicting parts manually in the binary editor). Get a copy of the file from a specific branch (for example, you are merging master and feature123 branches):

$git checkout master flash/foo.fla # or. $git checkout feature132 flash/foo.fla$ # and then. $git add flash/foo.fla

Another way is to export files through git-you can export to another file name, and then when you decide which one to use, copy the correct file selected to the normal file name:

$git show master:flash/foo.fla > master-foo.fla$ git show feature132:flash/foo.fla > feature132-foo.fla$ # check out master-foo.fla and feature132-foo.fla$ # if we decide that the file from feature132 is the correct $rm flash/foo.fla$ mv feature132-foo.fla flash/foo.fla$ rm master-foo.fla$ git add flash/foo.fla

Update: thanks to carl's comments on the original blog post, you can actually use "git checkout-ours flash/foo.fla" and "git checkout-theirs flash/foo.fla" to check out a specific version of the file without having to remember the name of the branch you are merging. Personally, I like to be more precise, but it's also a way.

Remember to add the file to the submission after resolving the conflict (as I did above).

Server, branch and label 5. Remote server

One of the super-powerful features of git is that it can have more than one remote server (in fact, you work on a local repository all the time). You don't have to have write access to all of these servers. You can have multiple servers that can be read (to merge their work) and then write to another repository. Adding a new remote server is simple:

$git remote add john git@github.com:johnsomeone/someproject.git

If you want to view information about the remote server, you can do this:

# display the url$ git remote-v of each remote server # provide more details $git remote show name

You can see the differences between local and remote branches at any time:

$git diff master..john/master

You can also see the changes to the head that are not on the remote branch:

$git log remote/branch..# Note:. There is no end to the specific reference 6. Label

There are two types of tags in git-lightweight tags and annotated tags. Remember in Tip 2 that git is pointer-based, and the difference between the two is simple. A lightweight tag is simply a pointer with a name pointing to a commit. You can point it to another submission at any time. An annotated tag is a named pointer to a tag object with its own information and history. Because it has its own information, it can be signed with gpg as needed.

It is easy to create both types of tags (only one command line switch is different)

$git tag to-be-tested$ git tag-a v1.1.0 # prompts for tag information 7. Establish a branch

Setting up branches in git is easy (and as fast as lightning, because it only needs to create a file that is less than 100 bytes). Create a new branch in the normal way and switch to the past:

$git branch feature132 $git checkout feature132

Of course, if you are sure to switch directly to the new branch, you can do it with a command:

$git checkout-b feature132

It's also easy if you want to rename a local branch (a longer way to show what happened):

$git checkout-b twitter-experiment feature132 $git branch-d feature132

Update: you can also (as brian palmer mentioned in the comments on the original blog post) use only the-m switch of "git branch" in a command (as mike suggested, if you specify only one branch parameter, the current branch will be renamed):

$git branch-m twitter-experiment$ git branch-m feature132 twitter-experiment8. Merge branches

Maybe at some point in the future, you want to merge the changes. There are two ways:

$git checkout master$ git merge feature83 # or. $git rebase feature83

The difference between merge and rebase is that merge tries to handle the changes and create a new commit that mixes the two. Rebase will try to add all the changes you made since the last separation from a branch to the branch's head one by one. However, don't rebase after the branch has been pushed to the remote server-this can cause conflicts / problems.

If you're not sure which branches have unique work-so you don't know which branches need to be merged and which can be deleted, git branch has two switches to help you:

# shows branches that have all been merged into the current branch $git branch-- merged # shows branches that have not been merged into the current branch $git branch-- no-merged9. Distal branch

If you have a local branch that you want to push to the remote server, you can push it up with one command:

$git push origin twitter-experiment:refs/heads/twitter-experiment# origin is the name of our server, and twitter-experiment is the branch name

Update: thanks to erlend's comments on the original blog post-this is actually the same as git push origin twitter-experiment, but with full syntax, you can use a different branch name between the two (so that the local branch can be add-ssl-support and the remote end can be issue-1723).

If you want to delete a branch on the remote server (note the colon before the branch name):

$git push origin: twitter-experiment

If you want to see the status of all remote branches, you can do this:

$git remote show origin

This command may list some branches on the server that used to exist but are no longer there. If you encounter this situation, you can clean it up from your local branch with the following command:

$git remote prune

Finally, if you want to track a remote branch locally, the common way is:

$git branch-track myfeature origin/myfeature$ git checkout myfeature

However, the new version of git automatically sets tracking when you check out a branch with the-b flag:

$git checkout-b myfeature origin/myfeature saves content in storage points, indexes, and file systems. Storage

In git, you can put the current working state into a storage stack, and then you can take it out. The simplest scenario is as follows:

$git stash# do something else... $git stash pop

Many people suggest using git stash apply instead of pop, but if you do, you end up with a long list of repositories. The "pop" is automatically removed from the stack after it is fully loaded. If you have used git stash apply, you can also remove the last item from the stack using the following command:

$git stash drop

Git automatically creates comments based on the current submission information. If you prefer custom information (because it may not have anything to do with the previous submission):

$git stash save "my stash message"

If you want to take a specific storage point from the list (it doesn't have to be the last one), you can list them first and then remove them in the following ways:

$git stash list stash@ {0}: on master: changed to german stash@ {1}: on master: language is now italian$ git stash apply stash@ {1} 11. Interactive add

In the world of subversion, you can only modify the file and submit all the changes. In git you have a much more powerful way to submit partial files or even partial patches. You need to enter interactive mode to submit part of the file or some changes in the file:

$git add-i staged unstaged path * commands * * 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: helpwhat now >

This will get you into a menu-based interactive prompt. You can use the numbers or highlighted letters in the command (if you turn on the highlight in the terminal) to enter the appropriate mode. Then just enter the number of the file you want to manipulate (you can use this format, 1 or 1-4 or 2mem4, 7).

If you want to enter patch mode (press'p' or'5' in interactive mode), you can also enter directly:

$git add-p diff-git a/dummy.rb b/dummy.rb index 4a00477..f856fb0 100644-a git add. RB annyong haseyo @-1 end endstage this hunk 5 + 1 annyong haseyo @ @ class myfoo def say- puts "annyong haseyo" + puts "guten tag" end endstage this hunk.

You can see that there are some options below to add this change to the file, all changes to the file, and so on. Use'?' Command can explain these options in detail.

twelve。 Save / retrieve changes from the file system

Some projects, such as the git project itself, save additional files directly in the git file system without adding them to version control.

Let's start by storing a random file in git:

$echo "foo" | git hash-object-w-- stdin51fc03a9bb365fae74fd2bf66517b30bf48020cb

The target file is saved to the database, but it will be treated as garbage collection if you don't set a pointer to it. The easiest way is to set a label:

$git tag myfile 51fc03a9bb365fae74fd2bf66517b30bf48020cb

Notice that we use the tag myfile here. We can do this when we need to use this file:

$git cat-file blob myfile

This is useful for some tool files that developers may use (passwords, gpg keys, etc.) but don't want to check out to the hard drive every time (especially in practice).

Log and what changes have been made? 13. View the log

If you have been using git for a long time, you will not have used 'git log' to view recent submissions. However, there are some techniques to better apply. For example, you can use the following command to see the specific changes submitted each time:

$git log-p

Or you can just look at what file changes have been made:

$git log-stat

There is a nice alias you can try, showing a short submission name and a nice branch diagram and displaying the submission information on a line (a bit like gitk, but on the command line):

Git config-- global alias.lol "log-- pretty=oneline-- abbrev-commit-- graph-- decorate" $git lol* 4d2409a (master) oops, meant that to be in korean* 169b845 hello world14. Search log

If you want to find a specific submitter, you can do this:

$git log-author=andy

Update: thanks to johannes's comments, I have removed some of the previous confusion here.

Or you want to find some relevant fields in the submission information:

$git log-grep= "something in the message"

There is also a more powerful command called pickaxe to find a submission that contains a specific content that has been deleted or added (for example, the content appears for the first time or is deleted). This tells you when a line has been added (but not if a character in this line has been changed):

$git log-s "todo: check for admin status"

If you change a specific file, such as lib/foo.rb

$git log lib/foo.rb

For example, you have a feature/132 branch and a feature/145 branch, and then you want to see the submissions on these two branches that are not in the master branch (note that the symbol is not there):

$git log feature/132 feature/145 ^ master

You can also use a date in activesupport format to narrow it down to a range of dates:

$git log-since=2.months.ago-until=1.day.ago

Or is used by default to combine queries, but you can easily change to and (if you have more than one query criterion)

$git log-since=2.months.ago-until=1.day.ago-author=andy-s "something"-all-match15. View / modify version

There are many ways to reference a version, depending on which one you remember:

$git show 12a86bc38 # parent node submitted once according to version $git show v1.0.1 # according to tag $git show feature132 # based on branch name $git show 12a86bc38 ^ # git show 12a86bc38~2 # grandfather node $git show feature132@ {yesterday} # time dependent $git show feature132@ {2.hours.ago} # time dependent

Note that it is a little different from the previous section, and the end means the parent node of the submission-the start position means that it is not in this branch.

16. Selection range

The easiest way:

$git log origin/master..new# [old].. [new]-all submissions that you haven't pushed yet

You can also omit [new] and will use the current head.

Looking back in time and regret medicine 17. Reset changes

If you haven't already submitted, you can easily cancel the changes with the following command:

$git reset head lib/foo.rb

The alias' unstage''is usually used because the above looks a bit unintuitive.

$git config-global alias.unstage "reset head" $git unstage lib/foo.rb

If you have submitted the file, you can do two things-if it is the last time you submit it, you can correct it:

$git commit-amend

This cancels the last commit, rolls back the work branch to a state where all changes were marked before commit, and the submission information is ready to be modified or submitted directly.

If you have submitted multiple times and want to roll back all of them, you can reset the branch to the appropriate location.

$git checkout feature132 $git reset-- hard head~2

If you actually want to point the branch to a completely different sha1 (maybe you want to replace the head of one branch with another branch, or a later commit), you can use the following longer approach:

$git checkout foo$ git reset-hard sha

There is actually a quick way (you don't need to switch your work branch to foo and then forward to sha):

$git update-ref refs/heads/foo sha18. Submitted to the wrong branch

Well, let's say you've submitted to master, but it's more appropriate to create a topic branch called experimental. To move these changes, you can create a branch in the current location, roll back the head and check out the new branch:

$git branch experimental # create a pointer to the location of the current master $git reset-- hard master~3 # move the pointer to the master branch to $git checkout experimental before 3 versions

If your change is on the branch of the branch, it will be more complicated. Then what you need to do is switch the branch base somewhere else:

$git branch newtopic startpoint$ git rebase oldtopic-onto newtopic19. Interactive switching basis

This is a great feature that I've seen before but I haven't really understood, and now I think it's very simple. Suppose you submitted 3 times but you want to change the order or edit (or merge):

$git rebase-I master~3

Then this will launch your editor with some instructions. All you have to do is modify these instructions to select / insert / edit (or delete) submit and save / exit. Then after editing, you can use the git rebase-continue command to make each instruction take effect.

If you have any changes, you will switch to the state you were in when you submitted, after which you need to use the command git commit-- amend to edit.

Note: never submit during rebase-only add and then use the parameter-- continue,--skip or-- abort.

20. Clear

If you submit something to your branch (maybe you imported some old repositories from svn), then you want to delete a file from the history:

$git filter-branch-- tree-filter'rm-f * .class' head

If you have already pushed to origin, but then submitted some junk changes, you can also do this on the local system before pushing:

$git filter-branch-- tree-filter'rm-f *. Class' origin/master..head other techniques 21. The previous reference you checked

If you know you've checked a sha-1 before, but then do some reset / fallback, you can use the reflog command to list the recently viewed sha-1 records:

$git reflog$ git log-g # is the same as above, but output 22. 0 using the 'log' format. Branch naming

A lovely tip-don't forget that branch names are not limited to amurz and 0-9. You can use / and in the name. Will be very convenient to build pseudo-namespaces or versions, such as:

$# build version 132 change history $git shortlog release/132 ^ release/131 $# label v1.0.1$ git tag v1.0.1 release/13223. Find out who the killer is.

It's usually useful to find out who changed a line of code in a file. The simplest command to do this is:

$git blame file

Sometimes these changes come from other files (if you merge two files, or if you move a function), so you can use the following command:

$# shows which file the content comes from $git blame-c file

Sometimes it's nice to track changes by clicking on each change and then going back to a long time ago. There is a good built-in gui command to do this:

$git gui blame file24. Data maintenance

Usually git doesn't need to be maintained often, it takes good care of itself. However, you can view the statistics with the following command:

$git count-objects-v

If you take up a lot of space, you can choose to do garbage collection in your local warehouse. This doesn't affect push or anyone else, but it makes some commands run faster and takes up less space:

$git gc

It also makes sense to run integrity checks frequently:

$git fsck-full

You can also add the-auto parameter to the end (if you run this command on the server frequently / daily via crontab), and then it will only perform the fsck action when necessary.

When checking, it is normal to see "dangling" or "unreachable", which is usually the result of fallback head or switching bases. It is wrong to see "missing" or "sha1 mismatch". Ask a professional for help!

25. Restore the lost branch

If you delete the experimental branch with the-d parameter, you can recreate it with the following command:

$git branch experimental sha1_of_hash

If you have visited recently, you can usually use git reflog to find the sha1 hash.

Another way is to use git fsck-lost-found. One of the dangling submissions is the missing head (it's just the head of the deleted branch, and head is referenced as the current head, so it's not in the dangling state).

At this point, I believe you have a deeper understanding of the "case analysis of Git use skills", you might as well come to the actual operation of it! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.