精华内容
参与话题
问答
  • Git push

    千次阅读 2019-05-28 10:38:48
    在使用git commit命令将修改从暂存区提交到本地版本库后,只剩下最后一步将本地... git push的一般形式为 git push <远程主机名> <本地分支名> <远程分支名> ,例如git push origin master:re...

    在使用git commit命令将修改从暂存区提交到本地版本库后,只剩下最后一步将本地版本库的分支推送到远程服务器上对应的分支了,如果不清楚版本库的构成,可以查看我的另一篇,git 仓库的基本结构。

        git push的一般形式为 git push <远程主机名> <本地分支名>  <远程分支名> ,例如 git push origin master:refs/for/master ,即是将本地的master分支推送到远程主机origin上的对应master分支, origin 是远程主机名,

        第一个master是本地分支名,第二个master是远程分支名。

        1.1 git push origin master

            如果远程分支被省略,如上则表示将本地分支推送到与之存在追踪关系的远程分支(通常两者同名),如果该远程分支不存在,则会被新建

         1.2 git push origin :refs/for/master 

      如果省略本地分支名,则表示删除指定的远程分支,因为这等同于推送一个空的本地分支到远程分支,等同于 git push origin --delete master

        1.3 git push origin

       如果当前分支与远程分支存在追踪关系,则本地分支和远程分支都可以省略,将当前分支推送到origin主机的对应分支 

     1.4 git push

      如果当前分支只有一个远程分支,那么主机名都可以省略,形如 git push,可以使用git branch -r ,查看远程的分支名

     1.5 git push 的其他命令

      这几个常见的用法已足以满足我们日常开发的使用了,还有几个扩展的用法,如下:

        (1) git push -u origin master 如果当前分支与多个主机存在追踪关系,则可以使用 -u 参数指定一个默认主机,这样后面就可以不加任何参数使用git push,

          不带任何参数的git push,默认只推送当前分支,这叫做simple方式,还有一种matching方式,会推送所有有对应的远程分支的本地分支, Git 2.0之前默认使用matching,现在改为simple方式

          如果想更改设置,可以使用git config命令。git config --global push.default matching OR git config --global push.default simple;可以使用git config -l 查看配置

        (2) git push --all origin 当遇到这种情况就是不管是否存在对应的远程分支,将本地的所有分支都推送到远程主机,这时需要 -all 选项

        (3) git push --force origin git push的时候需要本地先git pull更新到跟服务器版本一致,如果本地版本库比远程服务器上的低,那么一般会提示你git pull更新,如果一定要提交,那么可以使用这个命令。

        (4) git push origin --tags //git push 的时候不会推送分支,如果一定要推送标签的话那么可以使用这个命令

     1.6 关于 refs/for

      // refs/for 的意义在于我们提交代码到服务器之后是需要经过code review 之后才能进行merge的,而refs/heads 不需要

     

    展开全文
  • 1.将本地仓库Push到远程仓库需要先创建远程仓库,我用在GitHub上已经建好的hello-world远程仓库来演示。然后使用Git Remote Add添加远程仓库,将本地仓库与远程仓库相互关联,操作如下:2.进入如下界面,点击"+...

            1.将本地仓库Push到远程仓库需要先创建远程仓库,我用在GitHub上已经建好的 hello-world 远程仓库来演示。然后使用Git Remote Add添加远程仓库,将本地仓库与远程仓库相互关联,操作如下:

            2.进入如下界面,点击"+"号添加远程仓库,填写远程仓库URL,点击OK;

            3.此时会需要验证远程仓库账号和密码,我的GitHub上的账号之前已经在IDEA上生成凭证,所以会直接添加成功。这里我以在码云上的Git仓库做示例:

            4.验证成功即关联了远程仓库,下面将本地仓库的提交Push到远程仓库。如下进行操作,打开Push Commit窗口。

            5.如图所示,进行Push提交即可提交到远程仓库了。

            如果远程仓库里已存在之前版本提交的文件而我们的本地仓库中却不存在,会出现如下问题:

    error: failed to push some refs to 'https://....../HelloWorld'
    hint: Updates were rejected because the remote contains work that you do
    hint: not have locally. This is usually caused by another repository pushing
    hint: to the same ref. You may want to first integrate the remote changes
    hint: (e.g., 'git pull ...') before pushing again.

    hint: See the 'Note about fast-forwards' in 'git push --help' for details.

            因为我的远程仓库中已经存在一些提交记录了,而本地却是新建的仓库,也存在和远程提交记录没有关联的提交记录,所以出现了这种问题。

            我们要先将远程的提交拉过来,Pull到本地仓库,与本地仓库合并,IDEA官方的文档是这样解释Pull changes的:

    Pulling changes from a remote repository is a convenient shortcut for fetching and subsequently merging changes. When you pull, you not only download new data, but also integrate it into your local working copy of the project. 点击打开链接

            也就是说Pull操作不仅仅下载远程的新的数据,同时也将数据合并到本地仓库中,Pull操作如下所示:

    Git->Repository->Pull打开Pull Changes页面:

    如果Branches to merge栏没有项目,点击Remote栏最后的刷新按钮进行刷新,

    勾选远程仓库中的主分支master,Pull即变成了可用状态,点击进行Pull即可。

    不幸的是,这次还是出现了不能合并不相关的记录的问题:

    Couldn't merge origin/master: refusing to merge unrelated histories

    因为远程和本地的项目原本是两个不相同的项目,有不相关联的提交历史,解决办法是:

    方法1:使用git命令的--allow-unrelated-histories选项。

    git pull origin master --allow-unrelated-histories

    方法2:在IDEA右下角选择远程主分支master->Rebase onto,将远程提交的内容和历史记录添加到本地提交的内容和历史记录的前面,如下图所示:

    git rebase操作,将把远程仓库的提交历史置于本地仓库的提交历史之前,这样就保证了本地历史和远程历史的一致性。

    当然咯,本地的项目和远程的项目之前没有任何的关联,现在要将两者合并在一起进行管理,这一般是不太可取的,我这里只是想举个例子。一般的还是创建一个新的远程仓库后再将其与本地仓库关联,或者从远程仓库直接clone出本地仓库,这样自然也是相互关联的。

    这是官方文档关于Rebase的介绍:

    • Rebase: select this option to perform rebase during the update. This is equivalent to running git fetch and then git rebase, or git pull --rebase (all local commits will be put on top of the updated upstream head). 点击打开链接

    更多关于rebase的资料可以查阅:http://gitbook.liuhui998.com/4_2.html

    展开全文
  • Gitpush、commit以及pull

    万次阅读 2018-03-24 21:13:36
    当我们创建一个版本库以后,我们需要怎么提交呢?我们先将命令试一遍,再讲其中的原理。...执行完这些命令后,我们去gitHub上看看发生了什么变化:其中git push 就是把文件上传到gitHub上面。让我们...

    当我们创建一个版本库以后,我们需要怎么提交呢?

    我们先将命令试一遍,再讲其中的原理。

    我们在TestGit目录下,新建一个hello.txt文本,内容:HelloWorld


    然后输入命令:

    git add hello.txt
    git commit -m "第一次提交"
    git push
    

    执行完这些命令后,我们去gitHub上看看发生了什么变化:


    其中git push 就是把文件上传到gitHub上面。

    让我们分析一下这几个命令的动作:

    git add hello.txt

    git add 把它添加到仓库/暂存区(个人理解:这个类似于选中的动作,选中它后我们就可以做其它对它的操作) 

    git commit -m  把它提交到仓库, -m 是为了说明,可以填写任意内容,这个是为了记录你对这个文件做了什么操作,方便以后的管理。而 commit -m 是一个很重要的操作,因为它每次提交,都是提交于当前分支(从暂存区提交到当前分支),画个图理解一下:



    其中,工作区为本地目录(可见的目录),版本库就是".git"这个文件夹,"分支"稍后讲解.........

    当我们把暂存区的文件提交到当前分支后,我们就可以git push 上传到gitHub仓库上。

    当我们理解上图add操作后,后面的也很快就理解了。

    当我们这章节已经讲完

    请您们继续往后篇章看

    后面依非常精彩!

    展开全文
  • git push简介

    万次阅读 2012-06-14 20:53:40
    本文整理自:http://web.mit.edu/~mkgray/project/silk/root/afs/sipb/project/git/git-doc/git-push.html ...在git中,我们可以通过git push把本地仓库的更新推到服务器仓库。 $ git push ssh:
    本文整理自: http://web.mit.edu/~mkgray/project/silk/root/afs/sipb/project/git/git-doc/git-push.html
    http://apps.hi.baidu.com/share/detail/11403994 
    在git中,我们可以通过git push把本地仓库的更新推到服务器仓库。
    $ git push ssh://git@dev.lemote.com/rt4ls.git master // 把本地仓库提交到远程仓库的master分支中
    $ git remote add origin ssh://git@dev.lemote.com/rt4ls.git
    $ git push origin master 


    这两个操作是等价的,第二个操作的第一行的意思是添加一个标记,让origin指向ssh://git@dev.lemote.com/rt4ls.git,也就是说你操 作origin的时候,实际上就是在操作ssh://git@dev.lemote.com/rt4ls.git。origin在这里完全可以理解为后者 的别名。
     需要说明的是,默认情况下这条语句等价于提交本地的master仓库到远程仓库,并作为远程的master分支。
     如果想把本地的某个分支test提交到远程仓库,并作为远程仓库的master分支,或者作为另外一个名叫test的分支,那么可以这么做。


    $ git push origin test:master         // 提交本地test分支作为远程的master分支
    $ git push origin test:test              // 提交本地test分支作为远程的test分支
    如果想删除远程的分支呢?类似于上面,如果:左边的分支为空,那么将删除:右边的远程的分支。
    $ git push origin :test              // 刚提交到远程的test将被删除,但是本地还会保存的,不用担心
    更多的内容请参考《git追踪分支

    语法

    git push [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [--prune] [-v | --verbose] [-u | --set-upstream] [<repository> [<refspec>…]]
     

    DESCRIPTION

    Updates remote refs using local refs, while sending objects necessary to complete the given refs.

    You can make interesting things happen to a repository every time you push into it, by setting up hooks there. See documentation for git-receive-pack(1).

    OPTIONS

    <repository>

    The "remote" repository that is destination of a push operation. This parameter can be either a URL (see the section GIT URLS below) or the name of a remote (see the section REMOTES below).

    <refspec>…

    The format of a <refspec> parameter is an optional plus +, followed by the source ref <src>, followed by a colon :, followed by the destination ref <dst>. It is used to specify with what <src> object the <dst> ref in the remote repository is to be updated.

    The <src> is often the name of the branch you would want to push, but it can be any arbitrary "SHA-1 expression", such as master~4 or HEAD(see gitrevisions(7)).

    The <dst> tells which ref on the remote side is updated with this push. Arbitrary expressions cannot be used here, an actual ref must be named. If :<dst> is omitted, the same ref as <src> will be updated.

    The object referenced by <src> is used to update the <dst> reference on the remote side, but by default this is only allowed if the update can fast-forward <dst>. By having the optional leading +, you can tell git to update the <dst> ref even when the update is not a fast-forward. This does not attempt to merge <src> into <dst>. See EXAMPLES below for details.

    tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>.

    Pushing an empty <src> allows you to delete the <dst> ref from the remote repository.

    The special refspec : (or +: to allow non-fast-forward updates) directs git to push "matching" branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name already exists on the remote side. This is the default operation mode if no explicit refspec is found (that is neither on the command line nor in any Push line of the corresponding remotes file---see below).

    --all

    Instead of naming each ref to push, specifies that all refs under refs/heads/ be pushed.

    --prune

    Remove remote branches that don’t have a local counterpart. For example a remote branch tmp will be removed if a local branch with the same name doesn’t exist any more. This also respects refspecs, e.g. git push --prune remote refs/heads/*:refs/tmp/* would make sure that remoterefs/tmp/foo will be removed if refs/heads/foo doesn’t exist.

    --mirror

    Instead of naming each ref to push, specifies that all refs under refs/ (which includes but is not limited to refs/heads/, refs/remotes/, andrefs/tags/) be mirrored to the remote repository. Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end. This is the default if the configuration optionremote.<remote>.mirror is set.

    -n

    --dry-run

    Do everything except actually send the updates.

    --porcelain

    Produce machine-readable output. The output status line for each ref will be tab-separated and sent to stdout instead of stderr. The full symbolic names of the refs will be given.

    --delete

    All listed refs are deleted from the remote repository. This is the same as prefixing all refs with a colon.

    举例:git push origin –delete dev/1.0.8

    删除远程分支dev/1.0.8

    --tags

    All refs under refs/tags are pushed, in addition to refspecs explicitly listed on the command line.

    --receive-pack=<git-receive-pack>

    --exec=<git-receive-pack>

    Path to the git-receive-pack program on the remote end. Sometimes useful when pushing to a remote repository over ssh, and you do not have the program in a directory on the default $PATH.

    -f

    --force

    Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. This flag disables the check. This can cause the remote repository to lose commits; use it with care.

    --repo=<repository>

    This option is only relevant if no <repository> argument is passed in the invocation. In this case, git push derives the remote name from the current branch: If it tracks a remote branch, then that remote repository is pushed to. Otherwise, the name "origin" is used. For this latter case, this option can be used to override the name "origin". In other words, the difference between these two commands

    git push public         #1 git push --repo=public  #2

    is that #1 always pushes to "public" whereas #2 pushes to "public" only if the current branch does not track a remote branch. This is useful if you write an alias or script around git push.

    -u

    --set-upstream

    For every branch that is up to date or successfully pushed, add upstream (tracking) reference, used by argument-less git-pull(1) and other commands. For more information, see branch.<name>.merge in git-config(1).

    --thin

    --no-thin

    These options are passed to git-send-pack(1). A thin transfer significantly reduces the amount of sent data when the sender and receiver share many of the same objects in common. The default is --thin.

    -q

    --quiet

    Suppress all output, including the listing of updated refs, unless an error occurs. Progress is not reported to the standard error stream.

    -v

    --verbose

    Run verbosely.

    --progress

    Progress status is reported on the standard error stream by default when it is attached to a terminal, unless -q is specified. This flag forces progress status even if the standard error stream is not directed to a terminal.

    --recurse-submodules=check

    Check whether all submodule commits used by the revisions to be pushed are available on a remote tracking branch. Otherwise the push will be aborted and the command will exit with non-zero status.

    GIT URLS

    In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent.

    Git natively supports ssh, git, http, https, ftp, ftps, and rsync protocols. The following syntaxes may be used with them:

    • ssh://[user@]host.xz[:port]/path/to/repo.git/

    • git://host.xz[:port]/path/to/repo.git/

    • http[s]://host.xz[:port]/path/to/repo.git/

    • ftp[s]://host.xz[:port]/path/to/repo.git/

    • rsync://host.xz/path/to/repo.git/

    An alternative scp-like syntax may also be used with the ssh protocol:

    • [user@]host.xz:path/to/repo.git/

    The ssh and git protocols additionally support ~username expansion:

    • ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/

    • git://host.xz[:port]/~[user]/path/to/repo.git/

    • [user@]host.xz:/~[user]/path/to/repo.git/

    For local repositories, also supported by git natively, the following syntaxes may be used:

    These two syntaxes are mostly equivalent, except when cloning, when the former implies --local option. See git-clone(1) for details.

    When git doesn’t know how to handle a certain transport protocol, it attempts to use the remote-<transport> remote helper, if one exists. To explicitly request a remote helper, the following syntax may be used:

    • <transport>::<address>

    where <address> may be a path, a server and path, or an arbitrary URL-like string recognized by the specific remote helper being invoked. Seegit-remote-helpers(1) for details.

    If there are a large number of similarly-named remote repositories and you want to use a different format for them (such that the URLs you use will be rewritten into URLs that work), you can create a configuration section of the form:

            [url "<actual url base>"]                 insteadOf = <other url base>

    For example, with this:

            [url "git://git.host.xz/"]                 insteadOf = host.xz:/path/to/                 insteadOf = work:

    a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".

    If you want to rewrite URLs for push only, you can create a configuration section of the form:

            [url "<actual url base>"]                 pushInsteadOf = <other url base>

    For example, with this:

            [url "ssh://example.org/"]                 pushInsteadOf = git://example.org/

    a URL like "git://example.org/path/to/repo.git" will be rewritten to "ssh://example.org/path/to/repo.git" for pushes, but pulls will still use the original URL.

    REMOTES

    The name of one of the following can be used instead of a URL as <repository> argument:

    • a remote in the git configuration file: $GIT_DIR/config,

    • a file in the $GIT_DIR/remotes directory, or

    • a file in the $GIT_DIR/branches directory.

    All of these also allow you to omit the refspec from the command line because they each contain a refspec which git will use by default.

    Named remote in configuration file

     

    You can choose to provide the name of a remote which you had previously configured using git-remote(1)git-config(1) or even by a manual edit to the $GIT_DIR/config file. The URL of this remote will be used to access the repository. The refspec of this remote will be used by default when you do not provide a refspec on the command line. The entry in the config file would appear like this:

            [remote "<name>"]                 url = <url>                 pushurl = <pushurl>                 push = <refspec>                 fetch = <refspec>

    The <pushurl> is used for pushes only. It is optional and defaults to <url>.

    Named file in $GIT_DIR/remotes

     

    You can choose to provide the name of a file in $GIT_DIR/remotes. The URL in this file will be used to access the repository. The refspec in this file will be used as default when you do not provide a refspec on the command line. This file should have the following format:

            URL: one of the above URL format         Push: <refspec>         Pull: <refspec>

    Push: lines are used by git push and Pull: lines are used by git pull and git fetch. Multiple Push: and Pull: lines may be specified for additional branch mappings.

    Named file in $GIT_DIR/branches

     

    You can choose to provide the name of a file in $GIT_DIR/branches. The URL in this file will be used to access the repository. This file should have the following format:

            <url>#<head>

    <url> is required; #<head> is optional.

    Depending on the operation, git will use one of the following refspecs, if you don’t provide one on the command line. <branch> is the name of this file in $GIT_DIR/branches and <head> defaults to master.

    git fetch uses:

            refs/heads/<head>:refs/heads/<branch>

    git push uses:

            HEAD:refs/heads/<head>

    OUTPUT

    The output of "git push" depends on the transport method used; this section describes the output when pushing over the git protocol (either locally or via ssh).

    The status of the push is output in tabular form, with each line representing the status of a single ref. Each line is of the form:

     <flag> <summary> <from> -> <to> (<reason>)

    If --porcelain is used, then each line of the output is of the form:

     <flag> \t <from>:<to> \t <summary> (<reason>)

    The status of up-to-date refs is shown only if --porcelain or --verbose option is used.

    flag

    A single character indicating the status of the ref:

    (space)

    for a successfully pushed fast-forward;

    +

    for a successful forced update;

    -

    for a successfully deleted ref;

    *

    for a successfully pushed new ref;

    !

    for a ref that was rejected or failed to push; and

    =

    for a ref that was up to date and did not need pushing.

    summary

    For a successfully pushed ref, the summary shows the old and new values of the ref in a form suitable for using as an argument to git log(this is <old>..<new> in most cases, and <old>...<new> for forced non-fast-forward updates).

    For a failed update, more details are given:

    rejected

    Git did not try to send the ref at all, typically because it is not a fast-forward and you did not force the update.

    remote rejected

    The remote end refused the update. Usually caused by a hook on the remote side, or because the remote repository has one of the following safety options in effect: receive.denyCurrentBranch (for pushes to the checked out branch), receive.denyNonFastForwards (for forced non-fast-forward updates), receive.denyDeletes or receive.denyDeleteCurrent. See git-config(1).

    remote failure

    The remote end did not report the successful update of the ref, perhaps because of a temporary error on the remote side, a break in the network connection, or other transient error.

    from

    The name of the local ref being pushed, minus its refs/<type>/ prefix. In the case of deletion, the name of the local ref is omitted.

    to

    The name of the remote ref being updated, minus its refs/<type>/ prefix.

    reason

    A human-readable explanation. In the case of successfully pushed refs, no explanation is needed. For a failed ref, the reason for failure is described.

    Note about fast-forwards

    When an update changes a branch (or more in general, a ref) that used to point at commit A to point at another commit B, it is called a fast-forward update if and only if B is a descendant of A.

    In a fast-forward update from A to B, the set of commits that the original commit A built on top of is a subset of the commits the new commit B builds on top of. Hence, it does not lose any history.

    In contrast, a non-fast-forward update will lose history. For example, suppose you and somebody else started at the same commit X, and you built a history leading to commit B while the other person built a history leading to commit A. The history looks like this:

     

     

    
     

     

          B

         /

     ---X---A

     

    Further suppose that the other person already pushed changes leading to A back to the original repository you two obtained the original commit X.

    The push done by the other person updated the branch that used to point at commit X to point at commit A. It is a fast-forward.

    But if you try to push, you will attempt to update the branch (that now points at A) with commit B. This does not fast-forward. If you did so, the changes introduced by commit A will be lost, because everybody will now start building on top of B.

    The command by default does not allow an update that is not a fast-forward to prevent such loss of history.

    If you do not want to lose your work (history from X to B) nor the work by the other person (history from X to A), you would need to first fetch the history from the repository, create a history that contains changes done by both parties, and push the result back.

    You can perform "git pull", resolve potential conflicts, and "git push" the result. A "git pull" will create a merge commit C between commits A and B.

     

     

    
     

     

          B---C

         /   /

     ---X---A

     

    Updating A with the resulting merge commit will fast-forward and your push will be accepted.

    Alternatively, you can rebase your change between X and B on top of A, with "git pull --rebase", and push the result back. The rebase will create a new commit D that builds the change between X and B on top of A.

     

     

    
     

     

          B   D

         /   /

     ---X---A

     

    Again, updating A with this commit will fast-forward and your push will be accepted.

    There is another common situation where you may encounter non-fast-forward rejection when you try to push, and it is possible even when you are pushing into a repository nobody else pushes into. After you push commit A yourself (in the first picture in this section), replace it with "git commit --amend" to produce commit B, and you try to push it out, because forgot that you have pushed A out already. In such a case, and only if you are certain that nobody in the meantime fetched your earlier commit A (and started building on top of it), you can run "git push --force" to overwrite it. In other words, "git push --force" is a method reserved for a case where you do mean to lose history.

    Examples

    git push

    Works like git push <remote>, where <remote> is the current branch’s remote (or origin, if no remote is configured for the current branch).

    git push origin

    Without additional configuration, works like git push origin :.

    The default behavior of this command when no <refspec> is given can be configured by setting the push option of the remote.

    For example, to default to pushing only the current branch to origin use git config remote.origin.push HEAD. Any valid <refspec> (like the ones in the examples below) can be configured as the default for git push origin.

    git push origin :

    Push "matching" branches to origin. See <refspec> in the OPTIONS section above for a description of "matching" branches.

    git push origin master

    Find a ref that matches master in the source repository (most likely, it would find refs/heads/master), and update the same ref (e.g.refs/heads/master) in origin repository with it. If master did not exist remotely, it would be created.

    git push origin HEAD

    A handy way to push the current branch to the same name on the remote.

    git push origin master:satellite/master dev:satellite/dev

    Use the source ref that matches master (e.g. refs/heads/master) to update the ref that matches satellite/master (most probablyrefs/remotes/satellite/master) in the origin repository, then do the same for dev and satellite/dev.

    git push origin HEAD:master

    Push the current branch to the remote ref matching master in the origin repository. This form is convenient to push the current branch without thinking about its local name.

    git push origin master:refs/heads/experimental

    Create the branch experimental in the origin repository by copying the current master branch. This form is only needed to create a new branch or tag in the remote repository when the local name and the remote name are different; otherwise, the ref name on its own will work.

    git push origin :experimental

    Find a ref that matches experimental in the origin repository (e.g. refs/heads/experimental), and delete it.

    git push origin +dev:master

    Update the origin repository’s master branch with the dev branch, allowing non-fast-forward updates. This can leave unreferenced commits dangling in the origin repository. Consider the following situation, where a fast-forward is not possible:

     

     

    
     

     

                o---o---o---A---B  origin/master

                         \

                          X---Y---Z  dev

     

    The above command would change the origin repository to

     

     

    
     

     

                    A---B  (unnamed branch)

                    /

                o---o---o---X---Y---Z  master

     

    Commits A and B would no longer belong to a branch with a symbolic name, and so would be unreachable. As such, these commits would be removed by a git gc command on the origin repository.

    GIT

    Part of the git(1) suite

     
     
     
     
     
    展开全文
  • Git push 代码

    2019-04-20 17:27:16
    一. 把github上面的仓库克隆到本地 二.这个步骤以后你的本地项目文件夹下面就会多出个文件夹,该文件夹名即为你github上面的项目名,如图我多出了个Test文件夹,我们把本地项目文件夹下的所有文件(除了...git ...
  • Git命令行的远程Push EGit Push操作中的冲突问题 同步 工作区与本地库同步 工作区与远程库同步 图标 重点 引言 在团队开发当中,Git Push是多人协作环节中的最重要的一环可能没有之一。同SVN一样,push操作...
  • 【记录】Git pull(拉取),push(上传)命令整理(详细)

    万次阅读 多人点赞 2019-10-03 11:26:31
    前言:博主最近在学习git命令,因为git是一个非常好用的分布式版本管理工具,功能比svn强大,与SVN不同点是Git去中心化,每一个分支都是一个中心,并且支持本地仓库存储,像如今很多大公司都用git做版本控制。...
  • 简略git push 步骤

    千次阅读 2018-05-02 10:10:59
    1. git init创建新仓库,创建新文件夹,打开,然后执行git init2. 创建一个本地仓库使用命令 “git remote add origin git@github.com:yourName/yourRepo.git”,youname是你的GitHub的用户名git remote add origin ...
  • git push命令详解

    万次阅读 2018-11-23 11:12:34
    git push命令用于将本地分支的更新,推送到远程主机。它的格式与git pull命令相仿。 git push &lt;远程主机名&gt; &lt;本地分支名&gt;:&lt;远程分支名&gt; 注意:这里的:前后是必须没有...
  • Git原理杂谈之pull/push命令

    万次阅读 多人点赞 2019-08-01 22:11:24
    这边文章是基于之前三篇文章的后续篇,之前三篇能够帮助小白同学概要性地理解Git的整体原理及快速掌握Git基本技能以进入团队开发,所以建议对Git只...好了废话不多说了,直接进入今天的主题——git push/ git pull命...
  • git push 小结

    万次阅读 2012-04-08 17:23:39
    $ git push ssh://git@dev.lemote.com/rt4ls.git master // 把本地仓库提交到远程仓库的master分支中 $ git remote add origin ssh://git@dev.lemote.com/rt4ls.git $ git push origin master 这两个操作是等价的...
  • Git push 常见用法

    千次阅读 2019-07-02 15:06:48
    Git push 在使用git commit命令将修改从暂存区提交到本地版本库后,只剩下最后一步将本地版本库的分支推送到远程服务器上对应的分支了,如果不清楚版本库的构成,可以查看我的另一篇,git 仓库的基本结构。 git push...
  • Git push流程

    千次阅读 2019-09-06 16:22:07
    Git push流程 单击Maven Projects-domain-Lifecycle-Clean. 干掉target文件夹 删除.idea文件夹. 项目路径下的.idea文件夹要记得删除。 git branch查看分支 git pull,解决冲突. git add . 添加所有 git...
  • git pullgit push 的区别

    千次阅读 2018-11-14 20:36:23
    git pushgit pull是一对推送/拉取分支的git命令。  git push 使用本地的对应分支来更新对应的远程分支 $ git push &lt;远程主机名&gt; &lt;本地分支名&gt;:&lt;远程分支名&gt; 注意...
  • Git fetch和git pull的区别

    万次阅读 多人点赞 2012-06-14 20:56:10
    原文:http://www.tech126.com/git-fetch-pull/ Git中从远程的分支获取最新的版本到本地有这样2个命令:1.git fetch:相当于是从远程获取最新版本到本地,不会自动merge git fetch origin mastergit log -p ...
  • git pullgit push 区别

    千次阅读 2018-06-30 19:28:45
    git pullgit push 区别 结论先行: 1、git pull = git fetch + git merge 2、git fetch 只会将本地库所关联的远程库commit ID 更新到最新 3、git pull 将本地库所关联的远程库commit ID 更新到最新的同时...
  • 文章目录一、git pull1、git pull命令的完整格式2、省略本地分支名3、当前分支与远程分支存在追踪关系(可能有多个追踪关系)4、当前分支只有一个追踪关系。5、拉取远程主机上被他人rebase操作然后强制推送的分支6、...
  • git pullgit push的区别

    千次阅读 2019-05-09 18:12:53
    Git中从远程的分支获取最新的版本到本地有这样2个命令: git fetch:相当于是从远程获取最新版本到本地,不会自动merge git fetch origin master git log -p master..origin/master git merge origin/master ...
  • git pushgit pull的默认行为

    千次阅读 2017-07-04 08:59:44
    转自 ... 一直以来对Git pushgit ... pull命令的默认行为感觉混乱,今天抽空...通常对于一个本地的新建分支,例如git checkout -b develop, 在develop分支commit了代码之后,如果直接执行git push命令,develop分支
  • **$ git push origin 上面命令表示,将当前分支推送到origin主机的对应分支。 如果当前分支只有一个追踪分支,那么主机名都可以省略。 $ git push 如果当前分支与多个主机存在追踪关系,那么这个时候-u选项会指定一...
  • git push & git pull 推送/拉取分支

    万次阅读 多人点赞 2016-09-06 18:40:40
    git pushgit pull是一对推送/拉取分支的git命令。 git push 使用本地的对应分支来更新对应的远程分支。$ git push <远程主机名> <本地分支名>:<远程分支名>注意: 命令中的本地分支是指将要被推送到远端的分支,而...
  • 工具篇:git pullgit pushgit fetch

    千次阅读 2019-04-07 22:32:33
    本地分支与远程分支存可以设定追踪关系,一般git clone后,本地分支会与远程同名分支建立追踪关系。可以为不同名分支建立追踪关系。 git fetch 把远程仓库所有分支代码指针更新到本地指针文件中,但是不把新代码...
  • github 项目上传和下载git push,git pull

    千次阅读 2018-05-21 11:23:52
    首先系统配置git,移步linux 配置git环境,ssh远程登录.1.全局配置信息用户的用户名和email.$ git config --global user.name "liguangxian" $ git config --global user.email "2995183552@qq....
  • git push前请先git pull

    2020-05-21 13:35:29
    你直接git push很容易造成代码冲突,代码冲突解决也简单,可万一你手哆嗦点错了或者项目很大结构很复杂点了不该点的,后面结果谁也说不好,所以为了保险起见,每次都先git pullgit pushgit pull提示有冲突,很...
  • pushpull 简写方法: git add ./ git commit -m "小明修改的" git remote add and origin [SSH] git push origin -u master 当我们在pushpull时,加上-u参数,那么在下一次pushpull时,只需要以下语句就可以...
  • Git pull,Git push不上去问题和解决

    千次阅读 2017-03-05 20:35:31
    问题描述:输入命令行:$ git push origin master显示:To git@github.com:AllenChinese/workSpace.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'git@github....
  • 不知道为什么,最近从 github 上git pushgit pull 的时候总是不太稳定,有时候 pull 了半天都拉不下来,然后中断后重试一次又很顺畅了。 所以我想主动设置git pushgit pull 的超时时间,这样我可以在脚本...
  • git commit、git pushgit pullgit fetch、git merge 的含义与区别 git commit:是将本地修改过的文件提交到本地库中; git push:是将本地库中的最新信息发送给远程库; git pull:是从远程获取最新版本到本地...
  • 前言 git 是一个非常优秀的工具,但是晚饭在使用的过程中遇到...获取远程仓库更新时,使用git pull origin master后出现如下错误 # fatal: refusing to merge unrelated histories 然后根据git pull的提示 # --allo...
  • 解决每次git pullgit push都需要输入账号和密码的问题 每次git pull 或者git push 的时候,都要提示你输入账号和密码,很麻烦。于是在网上找到了解决办法。这j里记录下来,以便以后解决此类问题。 首先进入你的git...

空空如也

1 2 3 4 5 ... 20
收藏数 222,991
精华内容 89,196
关键字:

git push