Inspired by "5-minute git", I decided to go further and create a guide that takes less time to master git. Of course, this is a very simple git! However, this is useful to independent developers and provides a start for your continued growth.
The benefit of this Guide may be that a high school student is working on his or her first programming project and does not need to share code with anyone. (I think, yes, my son, he wrote a lot of code and didn't spend time learning a version control system. This is written to him and can be used by others .) It makes sense to use git. Unlike the subversion, it is easy to use without a server (all you need to do is regularly back up his hard disk ). In a two-minute guide, there is no time to worry about a server, so this is perfect.
Once again, git is only suitable for an independent developer with a regular backup policy. With a two-minute git backup policy, you can submit files with confidence to know the changed version you can see or restore an earlier version as needed.
Why is this so important? Well, a developer can realize that there will be no more annoying and time-consuming work experience. Under such circumstances, it is important to see the changed version and restore it to an earlier version. At the same time, you can roll back the previous version to give you the freedom to experiment with a new method-no problem, because you can always roll back.
When you have a chance, you must understand staging, branching, and other features, as well as pushing/pulling features from remote storage warehouses. However, what you learn here will still be useful! Note: When a file name is mentioned below, you can easily use the file path.
Start using gitIf you have not installed git, refer to the installation guide on the home page.
When you use git for the first time, assume that you are working in a directory, which is the main directory of your project. The first thing you should do is: git init // It initializes the directory used by git.
Tell git your fileNow you need to tell git which files should be concerned. If you have n files, you can do: git add <file1> <file2>... <Filen> join them. If you want to add each file in the directory, You can do: git Add. // (. indicates the current directory)
Submit changesNext, we need to submit the changes. Any time you want to submit one or more changed files, do: git commit <file1> <file2>... <Filen>-M "this is your commit message" or, put all the files that have changed since the last submission: git commit-a-m "this is your commit message for all changed Files" must contain sufficient descriptions in your submission information, so that you can find out which version you want to return.
View historical recordsNow we need to view the old version in one way. You can view your submission information and the "hash" (a number, indicating the version) of each version. You can use the following command to display one-version-per-line, output per line. Git log -- pretty = oneline this will make you look like the output below, displaying the hash and commit information for each commit
Dbe28a0a1eba45d823d309cc3659069fc16297e3 version 4 I want to submit Release 3 Release 3 Release 2 release notes, you can also use git log for a more detailed output, multiple lines per version, you can use git log -- pretty = oneline -- <FILENAME> to view the changes to a specific file. (Pay attention to the broken line !)
Restore old versionFinally, to restore the file to an earlier version, you only need to use the first few characters of the hash (as long as there are enough differences): git checkout
View changesGenerally, you do not want to retrieve the old version of a file without checking its changes first! To view the differences between a previous version of a file and the current version, you can view the hash: git diff
Last thing -- Optional
-- May add another minuteAlthough you can get many benefits by using only the above features, you will find it useful. If you don't want to be disturbed now, you don't have to try again. Sometimes, you don't know what file changes. To find it, you can do: git status will generate a file list and their status. For example, if a file is not "Git Add"-it will be listed as "untracked". If it is a file you care about, you should add it. I think the "optional" command may be a little bulky in a two-minute guide, because it can list a lot of files that you don't care about. For example, if your programming language is Python, it will display the compilation file. PyC. You may want to do something to solve it. You need to create a file named. gitignore in your project directory. For example, if you are working on a python 2. x project, you may want it to include (at least): *. PyC. Note that. gitignore understands * as a wildcard. If you want to hide the entire directory, You can append a slash to the folder name. For example, in Python 3. X environment, the compiled file is in a directory named _ pycache _, so you need the following in your. in gitignore: _ pycache __/
That's it! Just keep this manualThis is what you need to know when you start using git, as long as your hard disk has a regular backup policy. If you don't want to remember any commands that go beyond the major commit, add this guide to the bookmarks, And you can submit and compare the versions. There is no trouble returning to the old version! Remember, this guide is useful for using git as a simple version. Powerful features such as Branching and staging, and share with others via remote servers, please move to git five-minute guide or even others (?!) A longer git guide!
Link: http://www.garyrobinson.net/2014/10/git-in-two-minutes-for-a-solo-developer.html
Git 2-minute Guide
