Git -使用笔记

使用Git相关命令

git stash
git pull
git stash pop

git add -u
git add some files

git commit & git commit --amend

git push origin 分支名

git stash详细解读

git stash --help

GIT-STASH(1)                                                                                       Git Manual                                                                                      GIT-STASH(1)

NAME
       git-stash - Stash the changes in a dirty working directory away

SYNOPSIS
       git stash list [<options>]
       git stash show [<stash>]
       git stash drop [-q|--quiet] [<stash>]
       git stash ( pop | apply ) [--index] [-q|--quiet] [<stash>]
       git stash branch <branchname> [<stash>]
       git stash [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
                    [-u|--include-untracked] [-a|--all] [-m|--message <message>]
                    [--] [<pathspec>...]]
       git stash clear
       git stash create [<message>]
       git stash store [-m|--message <message>] [-q|--quiet] <commit>

DESCRIPTION
       Use git stash when you want 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 and
       reverts the working directory to match the HEAD commit.

       The modifications stashed away by this command can be listed with git stash list, inspected with git stash show, and restored (potentially on top of a different commit) with git stash apply. Calling
       git stash without any arguments is equivalent to git stash push. A stash is by default listed as "WIP on branchname ...", but you can give a more descriptive message on the command line when you
       create one.

       The latest stash you created is stored in refs/stash; older stashes are found in the reflog of this reference and can be named using the usual reflog syntax (e.g. stash@{0} is the most recently
       created stash, stash@{1} is the one before it, stash@{2.hours.ago} is also possible). Stashes may also be referenced by specifying just the stash index (e.g. the integer n is equivalent to stash@{n}).
OPTIONS
       push [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [-m|--message <message>] [--] [<pathspec>...]
           Save your local modifications to a new stash entry and roll them back to HEAD (in the working tree and in the index). The <message> part is optional and gives the description along with the
           stashed state.

           For quickly making a snapshot, you can omit "push". In this mode, non-option arguments are not allowed to prevent a misspelled subcommand from making an unwanted stash entry. The two exceptions to
           this are stash -p which acts as alias for stash push -p and pathspecs, which are allowed after a double hyphen -- for disambiguation.

           When pathspec is given to git stash push, the new stash entry records the modified states only for the files that match the pathspec. The index entries and working tree files are then rolled back
           to the state in HEAD only for these files, too, leaving files that do not match the pathspec intact.

           If the --keep-index option is used, all changes already added to the index are left intact.

           If the --include-untracked option is used, all untracked files are also stashed and then cleaned up with git clean, leaving the working directory in a very clean state. If the --all option is used
           instead then the ignored files are stashed and cleaned in addition to the untracked files.

           With --patch, you can interactively select hunks from the diff between HEAD and the working tree to be stashed. The stash entry is constructed such that its index state is the same as the index
           state of your repository, and its worktree contains only the changes you selected interactively. The selected changes are then rolled back from your worktree. See the "Interactive Mode" section of
           git-add(1) to learn how to operate the --patch mode.

           The --patch option implies --keep-index. You can use --no-keep-index to override this.

       save [-p|--patch] [-k|--[no-]keep-index] [-u|--include-untracked] [-a|--all] [-q|--quiet] [<message>]
           This option is deprecated in favour of git stash push. It differs from "stash push" in that it cannot take pathspecs, and any non-option arguments form the message.

       list [<options>]
           List the stash entries that you currently have. Each stash entry is listed with its name (e.g.  stash@{0} is the latest entry, stash@{1} is the one before, etc.), the name of the branch that was
           current when the entry was made, and a short description of the commit the entry was based on.

               stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation
               stash@{1}: On master: 9cc0589... Add git-stash

           The command takes options applicable to the git log command to control what is shown and how. See git-log(1).

       show [<stash>]
           Show the changes recorded in the stash entry as a diff between the stashed contents and the commit back when the stash entry was first created. When no <stash> is given, it shows the latest one.
           By default, the command shows the diffstat, but it will accept any format known to git diff (e.g., git stash show -p stash@{1} to view the second most recent entry in patch form). You can use
           stash.showStat and/or stash.showPatch config variables to change the default behavior.

       pop [--index] [-q|--quiet] [<stash>]
           Remove a single stashed state from the stash list and apply it on top of the current working tree state, i.e., do the inverse operation of git stash push. The working directory must match the
           index.

           Applying the state can fail with conflicts; in this case, it is not removed from the stash list. You need to resolve the conflicts by hand and call git stash drop manually afterwards.

           If the --index option is used, then tries to reinstate not only the working tree's changes, but also the index's ones. However, this can fail, when you have conflicts (which are stored in the
           index, where you therefore can no longer apply the changes as they were originally).

           When no <stash> is given, stash@{0} is assumed, otherwise <stash> must be a reference of the form stash@{<revision>}.

       apply [--index] [-q|--quiet] [<stash>]
           Like pop, but do not remove the state from the stash list. Unlike pop, <stash> may be any commit that looks like a commit created by stash push or stash create.
       branch <branchname> [<stash>]
           Creates and checks out a new branch named <branchname> starting from the commit at which the <stash> was originally created, applies the changes recorded in <stash> to the new working tree and
           index. If that succeeds, and <stash> is a reference of the form stash@{<revision>}, it then drops the <stash>. When no <stash> is given, applies the latest one.

           This is useful if the branch on which you ran git stash push has changed enough that git stash apply fails due to conflicts. Since the stash entry is applied on top of the commit that was HEAD at
           the time git stash was run, it restores the originally stashed state with no conflicts.

       clear
           Remove all the stash entries. Note that those entries will then be subject to pruning, and may be impossible to recover (see Examples below for a possible strategy).

       drop [-q|--quiet] [<stash>]
           Remove a single stash entry from the list of stash entries. When no <stash> is given, it removes the latest one. i.e.  stash@{0}, otherwise <stash> must be a valid stash log reference of the form
           stash@{<revision>}.

       create
           Create a stash entry (which is a regular commit object) and return its object name, without storing it anywhere in the ref namespace. This is intended to be useful for scripts. It is probably not
           the command you want to use; see "push" above.

       store
           Store a given stash created via git stash create (which is a dangling merge commit) in the stash ref, updating the stash reflog. This is intended to be useful for scripts. It is probably not the
           command you want to use; see "push" above.

DISCUSSION
       A stash entry is represented as a commit whose tree records the state of the working directory, and its first parent is the commit at HEAD when the entry was created. The tree of the second parent
       records the state of the index when the entry is made, and it is made a child of the HEAD commit. The ancestry graph looks like this:

                  .----W
                 /    /
           -----H----I

       where H is the HEAD commit, I is a commit that records the state of the index, and W is a commit that records the state of the working tree.

英语好的可以直接使用git stash --help查看相关用法,不好的也没关系,这里简述下具体用法:
git stash -- 能够将所有未提交的修改(工作区和暂存区)保存至堆栈中,用于后续当前工作目录。
git stash save -- 等价于git stash,区别是可以添加一些注释
git stash list -- 查看当前stash中的内容
git stash pop -- 将当前stash中的内容弹出并应用到当前分支的工作目录上。注意该命令将堆栈中最近保存的内容删除(因为栈是先进后出的)。
git stash apply -- 将堆栈中的内容应用到当前目录,不同与git stash pop,gitstash apply不会将该内容从堆栈中删除,这个命令的好处是可以将堆栈中的内容多次应用到工作目录中,适合于多个分支的开发。
git stash drop + name -- 从堆栈中删除指定name的stash
git stash clear -- 清除堆栈中的内容
git stash show -- 查看堆栈中最新保存的stash和当前目录的差异
git stash branch -- 从最新的stash创建分支
因为git stash 初次使用,这里写的详细点

git pull

从当前分支拉取最新代码

git add -u 选项详解

 -u, --update
           Update the index just where it already has an entry matching <pathspec>. This removes as well as modifies index entries to match the working tree, but adds no new files.

           If no <pathspec> is given when -u option is used, all tracked files in the entire working tree are updated (old versions of Git used to limit the update to the current directory and its
           subdirectories).

git commit & git commit --amend

GIT-COMMIT(1)                                                                                      Git Manual                                                                                     GIT-COMMIT(1)

NAME
       git-commit - Record changes to the repository

SYNOPSIS
       git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
                  [--dry-run] [(-c | -C | --fixup | --squash) <commit>]
                  [-F <file> | -m <msg>] [--reset-author] [--allow-empty]
                  [--allow-empty-message] [--no-verify] [-e] [--author=<author>]
                  [--date=<date>] [--cleanup=<mode>] [--[no-]status]
                  [-i | -o] [-S[<keyid>]] [--] [<file>...]

DESCRIPTION
       Stores the current contents of the index in a new commit along with a log message from the user describing the changes.

       The content to be added can be specified in several ways:

        1. by using git add to incrementally "add" changes to the index before using the commit command (Note: even modified files must be "added");

        2. by using git rm to remove files from the working tree and the index, again before using the commit command;

        3. by listing files as arguments to the commit command (without --interactive or --patch switch), in which case the commit will ignore changes staged in the index, and instead record the current
           content of the listed files (which must already be known to Git);

        4. by using the -a switch with the commit command to automatically "add" changes from all known files (i.e. all files that are already listed in the index) and to automatically "rm" files in the
           index that have been removed from the working tree, and then perform the actual commit;

        5. by using the --interactive or --patch switches with the commit command to decide one by one which files or hunks should be part of the commit in addition to contents in the index, before
           finalizing the operation. See the "Interactive Mode" section of git-add(1) to learn how to operate these modes.

       The --dry-run option can be used to obtain a summary of what is included by any of the above for the next commit by giving the same set of parameters (options and paths).

       If you make a commit and then find a mistake immediately after that, you can recover from it with git reset.

OPTIONS
       -a, --all
           Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.

       -p, --patch
           Use the interactive patch selection interface to chose which changes to commit. See git-add(1) for details.

       -C <commit>, --reuse-message=<commit>
           Take an existing commit object, and reuse the log message and the authorship information (including the timestamp) when creating the commit.

       -c <commit>, --reedit-message=<commit>
           Like -C, but with -c the editor is invoked, so that the user can further edit the commit message.

       --fixup=<commit>
           Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details.

       --squash=<commit>
           Construct a commit message for use with rebase --autosquash. The commit message subject line is taken from the specified commit with a prefix of "squash! ". Can be used with additional commit
           message options (-m/-c/-C/-F). See git-rebase(1) for details.

       --reset-author
           When used with -C/-c/--amend options, or when committing after a conflicting cherry-pick, declare that the authorship of the resulting commit now belongs to the committer. This also renews the
           author timestamp.
       --short
           When doing a dry-run, give the output in the short-format. See git-status(1) for details. Implies --dry-run.

       --branch
           Show the branch and tracking info even in short-format.

       --porcelain
           When doing a dry-run, give the output in a porcelain-ready format. See git-status(1) for details. Implies --dry-run.

       --long
           When doing a dry-run, give the output in the long-format. Implies --dry-run.

       -z, --null
           When showing short or porcelain status output, print the filename verbatim and terminate the entries with NUL, instead of LF. If no format is given, implies the --porcelain output format. Without
           the -z option, filenames with "unusual" characters are quoted as explained for the configuration variable core.quotePath (see git-config(1)).

       -F <file>, --file=<file>
           Take the commit message from the given file. Use - to read the message from the standard input.

       --author=<author>
           Override the commit author. Specify an explicit author using the standard A U Thor <author@example.com> format. Otherwise <author> is assumed to be a pattern and is used to search for an existing
           commit by that author (i.e. rev-list --all -i --author=<author>); the commit author is then copied from the first such commit found.

       --date=<date>
           Override the author date used in the commit.

       -m <msg>, --message=<msg>
           Use the given <msg> as the commit message. If multiple -m options are given, their values are concatenated as separate paragraphs.

           The -m option is mutually exclusive with -c, -C, and -F.

       -t <file>, --template=<file>
           When editing the commit message, start the editor with the contents in the given file. The commit.template configuration variable is often used to give this option implicitly to the command. This
           mechanism can be used by projects that want to guide participants with some hints on what to write in the message in what order. If the user exits the editor without editing the message, the
           commit is aborted. This has no effect when a message is given by other means, e.g. with the -m or -F options.

       -s, --signoff
           Add Signed-off-by line by the committer at the end of the commit log message. The meaning of a signoff depends on the project, but it typically certifies that committer has the rights to submit
           this work under the same license and agrees to a Developer Certificate of Origin (see http://developercertificate.org/ for more information).

       -n, --no-verify
           This option bypasses the pre-commit and commit-msg hooks. See also githooks(5).

       --allow-empty
           Usually recording a commit that has the exact same tree as its sole parent commit is a mistake, and the command prevents you from making such a commit. This option bypasses the safety, and is
           primarily for use by foreign SCM interface scripts.

       --allow-empty-message
           Like --allow-empty this command is primarily for use by foreign SCM interface scripts. It allows you to create a commit with an empty commit message without using plumbing commands like git-
           commit-tree(1).

       --cleanup=<mode>
           This option determines how the supplied commit message should be cleaned up before committing. The <mode> can be strip, whitespace, verbatim, scissors or default.

在使用git commit上栽过跟头,所以也记述下:git add files后一般使用git commit,但我一般使用git commit --amend 导致自己的提交和最近的提交代码的同事提交混到一起来了,这个git commit --amend使用git add files后就相当于吧代码追加到同事的提交里面了!特此,记住要对自己用的命令熟悉,了然于胸!

git push origin 分支

将代码提交到对应的分支上!

posted @ 2023-07-28 10:57  合滨  阅读(21)  评论(0编辑  收藏  举报