$ git init//Initialize a git repository$ git status//view the status of the warehouse
$ git Add. Add all modifications to staging area
$ git add *//Ant style Additions modified
$ git Add *controller//Add all modifications of files ending with Controller to staging area
$ git Add hello*//Add all the modifications to the file starting with Hello to staging area for example: Helloworld.txt,hello.java,hellogit.txt ...
$ git add Hello? will be submitted to staging area with the modification of only one file after the start of Hello for example: Hello1.txt,helloa.java if it is HelloGit.txt or Hello.java is not added
Can be added multiple times and then in the commit
$ git commit-m "comment"//commit changes to the staging area to add meaningful gaze information behind the warehouse
$ git diff file//View the modified section when file has been modified (unlike the different diff = = Difference of the latest version in the repository)
$ git log//view git commit information, each time you submit information including gaze, from the latest submission to the longest commit
$ git log--pretty=oneline//simplifies commit information to a single line
Note that the GIT version number (commit ID) is the SHA1 value Ea34578d5496d7dd233c827ed32a8cd576c5ee85
$ git reset--hard head^//Return to the previous version relative to the current version HEAD indicates the current version
$ git reset--hard head^^//Return to the previous version relative to the current version HEAD represents the current version
$ git reset--hard head~100//Return to the previous 100 versions relative to the current version go head for the current version
$ git reset--hard 3628164//Return to the specified version here does not need to write all commit ID git go back to auto-fit
Git's version fallback is very fast because git has a head pointer to the current version inside, and when you roll back the version, git just points the head from the append GPL
$ git reflog//You can view the commit log before the old version after returning to the old version
When we want to return from an old version to a new version but we closed the shell window and couldn't see the previous commit ID, we could
$ git reflog Check to see the previous version of the commit ID
$ git reset--hard 3628164
Workspaces and Staging Area
Workspace: That's all the files that we've created by Git init, but not including the. git Files (repository)
Staging Area: We added the changes via git Add./*/*xxx/xxxx*, all of which are entered into staging area, invisible to the naked eye through the git status can see the state of the modification
What is modification.
For example, you add a new line, this is a change,
Delete a row, is also a modification,
Changed some characters, also a modification,
The deletion of some added some, but also a modification,
Even create a new file, also count as a modification.
Modifications can only be submitted after they have been add to staging area
When file has been modified yet to add
$ git checkout--file//indicates that changes to the discard workspace are returned to their original state (not included and modified to be added to the staging area)
File has been modified and added to staging area, not yet commit
$ git reset head file//Discard file has been added to staging area's modified head to indicate the latest version
If the file modification has been committed to the local warehouse
$ git reset--hard head^//back to previous version
$ rm File//delete files from the file system (there is still a record in git), Git will tell you that a file was deleted when git status
$ git RM file//delete files from git repository (while deleting files from file system) $ git status ok
$ git RM file//delete files from git repository
$ git commit-m "Delete file"//Commit Delete
$ git checkout file//want to recover from Git will appear: Error:pathspec ' README.txt ' did not match any file (s) known to Git.
$ git reset--hard head^//Revert to previous version can recover files
$ rm File//delete files in file system
$ git checkout file//Because it is deleted through the filesystem, it can be restored by checkout
$ ssh-keygen-t rsa-c "youremail@example.com"//Create SSH Key
Because this key is not used for military purposes, so there is no need to set the password, so all the way to enter,
If it goes well, a. SSH directory with Id_rsa and id_rsa.pub two files is generated in the user username directory.
Id_rsa is the private key, can't be leaked out, Id_rsa.pub is the public key, you can tell others and add on GitHub is also this public key
Login to GitHub, open "Account Settings", "SSH Keys" page, click "Add SSH Key", fill in any title, paste the contents of the Id_rsa.pub file in the Key text box
GitHub allows you to add multiple keys. Suppose you have a number of computers that you submit at the company for a while and submit at home for a while, as long as you add each computer key to GitHub, you can push it to GitHub on every computer.
To add a remote library
Do a global configuration
$ git config--global user.name "Zhangsan"
$ git config--global user.email "zhangsan@139.com"
$ git Remote add origin git@github.com:zhangsan/ylez.git//Add a remote repository
Add Origin is the addition of a remote repository
Git@github.com:zhangsan/ylez.git is the address of the remote repository
Git@github.com host Address We can gitlab everyone's own git server
Zhangsan is your user name.
/ylez.git is your warehouse name.
$ GIT push-u origin master//pushes the local master branch to the remote master branch
$ git push-u Origin dev//switch locally to the Dev branch and push the local dev branch to the remote
Cloning a remote repository to a local
GIT supports multiple protocols, including HTTPS, but the native GIT protocol supported by SSH is the fastest.
$ git clone git@192.168.0.8:zhangsan/test.git//Tell a remote repository clone to local
Each time you commit, git strings them into a timeline, which is a branch of the line.
In Git, the default is a master branch, the master branch
The head is strictly not pointing to the commit, but pointing to Master,master is pointing to the commit, so the head is pointing to the current branch
The Master branch is a line, and Git uses master to point to the latest commit, and then head to master
The Master branch moves forward one step at a time, so that as you continue to commit, the master branch line grows longer
Git creates a new pointer called Dev, points to the same commit as Master, and then points the head to dev, indicating that the current branch is on Dev
$ git branch//view all the branches of git
$ git Branch dev//create Dev Branch
$ git checkout dev//switch to a branch that already exists
$ git checkout-b dev//create Dev Branch and switch to Dev branch
$ git branch-d dev//Remove Dev Branch
$ git checkout master//switch to Main branch
$ git merge dev//merge Dev branch to master branch
Updating D17efd8. fec145a
Fast-forward
Readme.txt | 1 +
1 file changed, 1 insertion (+)
Fast-forward information, Git tells us that this merger is a "fast-forward mode", which is to direct master to the current commit of Dev, so the merging speed is very fast
$ git branch-d dev//Remove Dev Branch
Now it's just the master branch, and it feels like nothing's happening again.
Handling conflicts
$ git checkout-b feature1
Switched to a new branch ' Feature1 '
Modify the last line of Readme.txt to read:
Creating a new branch is quick and simple.
$ git Add readme.txt
$ git commit-m "and simple"
[Feature1 75a857c] and simple
1 file changed, 1 insertion (+), 1 deletion (-)
$ git Checkout Master
Switched to branch ' master '
Your Branch is ahead of ' Origin/master ' by 1 commit.
Git also automatically prompts us that the current Master branch is more than 1 commits ahead of the remote Master branch.
On the master branch, change the last line of the Readme.txt file to:
Creating a new branch is quick & simple.
$ git Add readme.txt
$ git commit-m "& Simple"
[Master 400b400] & Simple
1 file changed, 1 insertion (+), 1 deletion (-)
$ git Merge Feature1
Auto-merging Readme.txt
CONFLICT (content): Merge CONFLICT in Readme.txt
Automatic merge failed; Fix conflicts and then commits the result.
$ git status
# on Branch Master
# Your Branch is ahead of ' Origin/master ' by 2 commits.
#
# unmerged paths:
# (use "Git add/rm <file> ..." as appropriate to mark resolution)
#
# both Modified:readme.txt//conflict
#
No changes added to commit (use "git add" and/or "Git Commit-a")
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick and simple.
>>>>>>> Feature1
Git uses <<<<<<<,=======,>>>>>>> to mark the contents of different branches, we modify the following to save:
Creating a new branch is quick and simple.
Re-submit:
$ git Add readme.txt
$ git commit-m "conflict fixed"
[Master 59BC1CB] conflict fixed
You can also see the merging of branches with the git log with parameters:
$ git log--graph--pretty=oneline--abbrev-commit
$ git log--graph--pretty=oneline--abbrev-commit
* 59BC1CB Conflict fixed
|\
| * 75a857c and simple
* | 400b400 & Simple
|/
* FEC145A Branch Test
...
To delete a feature1 branch:
$ git branch-d feature1
Deleted Branch Feature1 (was 75a857c).
Typically, when merging branches, GIT uses fast forward mode if possible, but in this mode, the branch information is discarded when the branch is deleted.
If you want to force the fast forward mode to be disabled, GIT will generate a new commit at merge, so that branching information can be seen from the branch history
$ git merge--no-ff-m "comment" dev//Prepare to merge Dev branch, note the--NO-FF parameter, which means that fast forward is disabled
$ git log--graph--pretty=oneline--abbrev-commit//graphical presentation branching case
* 7825a50 Merge with No-ff
|\
| * 6224937 Add Merge
|/
* 59BC1CB Conflict fixed
...
When repairing a bug with a code name of 101, it is natural that you want to create a branch issue-101 to fix it
When fixing a bug, there is still work to be done but cannot be submitted can freeze progress
In your current workspace (branch)
$ git stash//freezes the current branch modification
See all Stash
$ git Stash list//list all work on-site storage
$ git Stash list
STASH@{0}: WIP on dev:6224937 Add merge
$ git stash apply (stash@{n})//Recovery work site (only one can omit the back if there are multiple can recover a specified stash) but do not delete the stash in the store
$ git stash Drop (stash@{n})//delete the stored work site (only one time can omit the back, if more then specify delete one)
$ git stash pop (stash@{n})//Restore the Stash content also deleted (only one time can omit the back, if more than one to specify the deletion of one)
$ git branch-d branchname//Delete a branch, provided that the branch and the main branch that generated the branch have been merged (merge)
$ git branch-d branchname//Delete a branch, whether or not a merge is forced to delete
When you clone from a remote repository, actually git automatically corresponds to the local master branch and the remote Master Branch, and the default name of the remote Repository is origin.
To view information for a remote library, use git remote:
$ git remote
Origin
Or, use git remote-v to display more detailed information:
$ git remote-v
Origin Git@github.com:michaelliao/learngit.git (Fetch)
Origin Git@github.com:michaelliao/learngit.git (push)
It is not necessary to push local branches remotely, so which branches need to be pushed and which do not.
The Master branch is the main branch, so synchronize with the remote at all times;
The Dev Branch is a development branch, and all members of the team need to work on it, so they need to be synchronized with the remote.
Bug branches are only used to fix bugs locally, there is no need to push remote, unless the boss wants to see how many bugs you have fixed every week;
Whether or not the feature branch is pushed to the remote depends on whether you are working with your little partner to develop it.
Push fails if someone has pushed it before you
$ git push origin dev
To Git@github.com:michaelliao/learngit.git
! [Rejected] Dev, Dev (non-fast-forward)
Error:failed to push some refs to ' git@github.com:michaelliao/learngit.git '
Hint:updates were rejected because the tip of your current branch is behind
Hint:its remote counterpart. Merge the remote changes (e.g. ' git pull ')
Hint:before pushing again.
Hint:see the ' Note about Fast-forwards ' "Git push--help ' for details.
Because the latest submission from your partner is in conflict with the submission you're trying to push, the solution is simple,
Git has prompted us to use git pull to grab the latest commits from Origin/dev, then merge locally, resolve conflicts, and push
$ git pull//Grab remote branch commit to local
The link to the local dev branch and the remote Origin/dev branch is not specified, and the push fails, so first we need to establish a connection between the local branch and the remote branch
$ git Branch--set-upstream Dev Origin/dev//establish local dev branch and remote Dev branch contact
Branch Dev set up to track remote Branch dev from Origin.
Summarize:
View Remote library information, using Git remote-v;
Local new branches are not visible to others if they are not pushed to the remote;
Push the branch from the local, use GIT push Origin branch-name, if push fails, first crawl the remote new commit with git pull;
Create local and remote branches corresponding to the branch, using git checkout-b branch-name origin/branch-name, local and remote branch names are best consistent;
Establish the Association of local and remote branches, using Git branch--set-upstream branch-name origin/branch-name;
From a remote crawl branch, use git pull, and if there is a conflict, deal with the conflict first.
When we publish a version, we usually start with a tag in the repository, so that it's the only version that determines the time of the tag.
Any time in the future, the version of a tag is taken out of the historical version of that tag. Therefore, the tag is also a snapshot of the repository.
Git's tag is a snapshot of the repository, but it's actually a pointer to a commit (much like a branch is right.) However, the branch can be moved and the label cannot be moved, so creating and deleting tags is instantaneous.
Labels are usually on the master branch
$ git Tag v1.0//In the current version of head to hit a name called v1.0 label
$ git tag//view all tags, list out all label names
Tag for history commit (sometimes forget to tag the Monday results Friday only remembered)
$ git log--pretty=oneline--abbrev-commit
6A5819E merged bug Fix 101
CC17032 Fix Bug 101
7825a50 Merge with No-ff
6224937 Add Merge
59BC1CB Conflict Fixed
400b400 & Simple
75a857c and simple
FEC145A Branch Test
D17efd8 Remove Test.txt
$ git tag v0.8 59BC1CB//For commit ID is 59BC1CB ... v0.8 tag on the commit
Labels are not listed chronologically, but are sorted alphabetically. You can use Git show <tagname> to view tag information
You can also create a label with a description, specify the label name with-A,-m to specify the description text:
$ git tag-a v0.1-m "version 0.1 released" 3628164//For commit ID 3628164 ... The commit of v0.1 is tagged with the content of version 0.1 released
$ git tag v0.1//Can view the label information including text description
You can also sign a label with the private key through-s:
$ git tag-s v0.2-m "signed version 0.2 released" fec145a
Signed with PGP signature, therefore, must first install GPG (GnuPG), if not found GPG, or no GPG key pair, will be error:
Gpg:signing Failed:secret Key Not available
ERROR:GPG failed to sign the data
Error:unable to sign the tag
If an error is found, please refer to the GNUPG Help document configuration key.
Use the command git show <tagname> to see the PGP signature information:
$ git show v0.2
$ git tag-d v0.1//delete tag v0.1
$ GIT push-u Origin v1.0//PUSH Tag v1.0 to remote repository
$ GIT push-u Origin--tags//push all tags at once
If the label has been pushed to the remote, to remove the remote label is a bit troublesome, first removed from the local:
$ git tag-d v0.9
Deleted tag ' v0.9 ' (was 6224937)
Then, remove from remote. The Delete command is also push, but the format is as follows:
$ git push origin:refs/tags/v0.9
To Git@github.com:michaelliao/learngit.git
-[deleted] v0.9
Create a special. gitignore file in the root directory of the Git workspace, and then fill in the file name you want to ignore, and git will automatically ignore the files
The principle of ignoring files is:
Ignoring the auto-generated files of the operating system, such as thumbnail images;
Ignoring compile-generated intermediate files, executables, and so on, that is, if a file is automatically generated from another file, the automatically generated file does not need to be put into the repository, such as Java compilation generated by the. class file;
Ignore your own configuration file with sensitive information, such as the configuration file that holds the password.
A complete. gitignore file
# Windows:
Thumbs.db
Ehthumbs.db
Desktop.ini
#project
*.class
*.war
Classes
Target
First checkout the newest code from Git is the code that checkout the main branch Master branch, so we need to checkout the code of the Development Branch again
The Master branch is the latest stable version, and the Dev branch is the latest development version
Be sure to remember to checout from the server instead of creating a new branch locally, if the new feature is to checkout a new sub-branch on the local dev branch after the first 2 steps
Then develop, submit the merge to Dev,push to the code server.
