zoukankan      html  css  js  c++  java
  • git 下载单个文件 已经添加多个远程服务器

    It is possible to do (in the deployed repository)

    git fetch
    

    followed by

    git checkout origin/master -- path/to/file
    

    git fetch will download all the recent changes, but it will not put it in your current checked out code (working area).

    git checkout origin/master -- path/to/file will checkout the particular file from the the downloaded changes (origin/master).

    At least this works for me for those little small typo fixes, where it feels weird to create a branch etc just to change one word in a file.

    git checkout from-branch-name -- path/to/the/file/you/want
    

     

    git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>...
           When <paths> or --patch are given, git checkout does not switch
           branches. It updates the named paths in the working tree from the
           index file or from a named <tree-ish> (most often a commit). In
           this case, the -b and --track options are meaningless and giving
           either of them results in an error. The <tree-ish> argument can be
           used to specify a specific tree-ish (i.e. commit, tag or tree) to
           update the index for the given paths before updating the working
           tree.



    2.5 Git Basics - Working with Remotes

    Working with Remotes

    To be able to collaborate on any Git project, you need to know how to manage your remote repositories. Remote repositories are versions of your project that are hosted on the Internet or network somewhere. You can have several of them, each of which generally is either read-only or read/write for you. Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work. Managing remote repositories includes knowing how to add remote repositories, remove remotes that are no longer valid, manage various remote branches and define them as being tracked or not, and more. In this section, we’ll cover some of these remote-management skills.

    Showing Your Remotes

    To see which remote servers you have configured, you can run the git remote command. It lists the shortnames of each remote handle you’ve specified. If you’ve cloned your repository, you should at least see origin – that is the default name Git gives to the server you cloned from:

    $ git clone https://github.com/schacon/ticgit
    Cloning into 'ticgit'...
    remote: Reusing existing pack: 1857, done.
    remote: Total 1857 (delta 0), reused 0 (delta 0)
    Receiving objects: 100% (1857/1857), 374.35 KiB | 268.00 KiB/s, done.
    Resolving deltas: 100% (772/772), done.
    Checking connectivity... done.
    $ cd ticgit
    $ git remote
    origin
    

    You can also specify -v, which shows you the URLs that Git has stored for the shortname to be used when reading and writing to that remote:

    $ git remote -v
    origin	https://github.com/schacon/ticgit (fetch)
    origin	https://github.com/schacon/ticgit (push)
    

    If you have more than one remote, the command lists them all. For example, a repository with multiple remotes for working with several collaborators might look something like this.

    $ cd grit
    $ git remote -v
    bakkdoor  https://github.com/bakkdoor/grit (fetch)
    bakkdoor  https://github.com/bakkdoor/grit (push)
    cho45     https://github.com/cho45/grit (fetch)
    cho45     https://github.com/cho45/grit (push)
    defunkt   https://github.com/defunkt/grit (fetch)
    defunkt   https://github.com/defunkt/grit (push)
    koke      git://github.com/koke/grit.git (fetch)
    koke      git://github.com/koke/grit.git (push)
    origin    git@github.com:mojombo/grit.git (fetch)
    origin    git@github.com:mojombo/grit.git (push)
    

    This means we can pull contributions from any of these users pretty easily. We may additionally have permission to push to one or more of these, though we can’t tell that here.

    Notice that these remotes use a variety of protocols; we’ll cover more about this in Section 4-2.

    Adding Remote Repositories

    We’ve mentioned and given some demonstrations of adding remote repositories in previous sections, but here is how to do it explicitly. To add a new remote Git repository as a shortname you can reference easily, run git remote add [shortname] [url]:

    $ git remote
    origin
    $ git remote add pb https://github.com/paulboone/ticgit
    $ git remote -v
    origin	https://github.com/schacon/ticgit (fetch)
    origin	https://github.com/schacon/ticgit (push)
    pb	https://github.com/paulboone/ticgit (fetch)
    pb	https://github.com/paulboone/ticgit (push)
    

    Now you can use the string pb on the command line in lieu of the whole URL. For example, if you want to fetch all the information that Paul has but that you don’t yet have in your repository, you can run git fetch pb:

    $ git fetch pb
    remote: Counting objects: 43, done.
    remote: Compressing objects: 100% (36/36), done.
    remote: Total 43 (delta 10), reused 31 (delta 5)
    Unpacking objects: 100% (43/43), done.
    From https://github.com/paulboone/ticgit
     * [new branch]      master     -> pb/master
     * [new branch]      ticgit     -> pb/ticgit
    

    Paul’s master branch is now accessible locally as pb/master – you can merge it into one of your branches, or you can check out a local branch at that point if you want to inspect it. (We’ll go over what branches are and how to use them in much more detail in Chapter 3.)

    Fetching and Pulling from Your Remotes

    As you just saw, to get data from your remote projects, you can run:

    $ git fetch [remote-name]
    

    The command goes out to that remote project and pulls down all the data from that remote project that you don’t have yet. After you do this, you should have references to all the branches from that remote, which you can merge in or inspect at any time.

    If you clone a repository, the command automatically adds that remote repository under the name “origin”. So, git fetch origin fetches any new work that has been pushed to that server since you cloned (or last fetched from) it. It’s important to note that the git fetchcommand pulls the data to your local repository – it doesn’t automatically merge it with any of your work or modify what you’re currently working on. You have to merge it manually into your work when you’re ready.

    If you have a branch set up to track a remote branch (see the next section and Chapter 3 for more information), you can use the git pull command to automatically fetch and then merge a remote branch into your current branch. This may be an easier or more comfortable workflow for you; and by default, the git clone command automatically sets up your local master branch to track the remote master branch (or whatever the default branch is called) on the server you cloned from. Running git pull generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you’re currently working on.

    Pushing to Your Remotes

    When you have your project at a point that you want to share, you have to push it upstream. The command for this is simple: git push [remote-name] [branch-name]. If you want to push your master branch to your origin server (again, cloning generally sets up both of those names for you automatically), then you can run this to push any commits you’ve done back up to the server:

    $ git push origin master
    

    This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime. If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected. You’ll have to pull down their work first and incorporate it into yours before you’ll be allowed to push. SeeChapter 3 for more detailed information on how to push to remote servers.

    Inspecting a Remote

    If you want to see more information about a particular remote, you can use the git remote show [remote-name] command. If you run this command with a particular shortname, such asorigin, you get something like this:

    $ git remote show origin
    * remote origin
      Fetch URL: https://github.com/schacon/ticgit
      Push  URL: https://github.com/schacon/ticgit
      HEAD branch: master
      Remote branches:
        master                               tracked
        dev-branch                           tracked
      Local branch configured for 'git pull':
        master merges with remote master
      Local ref configured for 'git push':
        master pushes to master (up to date)
    

    It lists the URL for the remote repository as well as the tracking branch information. The command helpfully tells you that if you’re on the master branch and you run git pull, it will automatically merge in the master branch on the remote after it fetches all the remote references. It also lists all the remote references it has pulled down.

    That is a simple example you’re likely to encounter. When you’re using Git more heavily, however, you may see much more information from git remote show:

    $ git remote show origin
    * remote origin
      URL: https://github.com/my-org/complex-project
      Fetch URL: https://github.com/my-org/complex-project
      Push  URL: https://github.com/my-org/complex-project
      HEAD branch: master
      Remote branches:
        master                           tracked
        dev-branch                       tracked
        markdown-strip                   tracked
        issue-43                         new (next fetch will store in remotes/origin)
        issue-45                         new (next fetch will store in remotes/origin)
        refs/remotes/origin/issue-11     stale (use 'git remote prune' to remove)
      Local branches configured for 'git pull':
        dev-branch merges with remote dev-branch
        master     merges with remote master
      Local refs configured for 'git push':
        dev-branch                     pushes to dev-branch                     (up to date)
        markdown-strip                 pushes to markdown-strip                 (up to date)
        master                         pushes to master                         (up to date)
    

    This command shows which branch is automatically pushed to when you run git push while on certain branches. It also shows you which remote branches on the server you don’t yet have, which remote branches you have that have been removed from the server, and multiple branches that are automatically merged when you run git pull.

    Removing and Renaming Remotes

    If you want to rename a reference you can run git remote rename to change a remote’s shortname. For instance, if you want to rename pb to paul, you can do so with git remote rename:

    $ git remote rename pb paul
    $ git remote
    origin
    paul
    

    It’s worth mentioning that this changes your remote branch names, too. What used to be referenced at pb/master is now at paul/master.

    If you want to remove a remote for some reason – you’ve moved the server or are no longer using a particular mirror, or perhaps a contributor isn’t contributing anymore – you can use git remote rm:

    $ git remote rm paul
    $ git remote
    origin
    

     

     
  • 相关阅读:
    js键盘事件
    jq 插件写法
    js 去除字符串空白符
    C# ExpandoObject用法
    C# dynamic与var的区别
    c# 可选参数与命名实参
    C# 扩展方法
    python运算符
    【HDOJ】3006 The Number of set
    【HDOJ】3205 Factorization
  • 原文地址:https://www.cnblogs.com/studyNT/p/4751932.html
Copyright © 2011-2022 走看看