How To Merge Local Repo With Remote
Syncing
SVN uses a single fundamental repository to serve as the communication hub for developers, and collaboration takes identify by passing changesets betwixt the developers' working copies and the fundamental repository. This is different from Git's collaboration model, which gives every developer their ain copy of the repository, complete with its own local history and branch structure. Users typically need to share a series of commits rather than a single changeset. Instead of committing a changeset from a working copy to the key repository, Git lets you share entire branches betwixt repositories.
The commands presented below allow yous manage connections with other repositories, publish local history by "pushing" branches to other repositories, and see what others have contributed by "pulling" branches into your local repository.
git remote
The git remote command lets you create, view, and delete connections to other repositories. Remote connections are more like bookmarks rather than direct links into other repositories. Instead of providing existent-time access to some other repository, they serve equally convenient names that can be used to reference a not-so-convenient URL.
For instance, the following diagram shows ii remote connections from your repo into the fundamental repo and another developer'south repo. Instead of referencing them by their full URLs, you tin can pass the origin and john shortcuts to other Git commands.
Usage
git remote Listing the remote connections you accept to other repositories.
git remote -v Same as the above command, merely include the URL of each connectedness.
git remote add <proper name> <url> Create a new connection to a remote repository. Later on adding a remote, you'll be able to use
git remote rm <name> Remove the connexion to the remote repository called
git remote rename <old-name> <new-name> Rename a remote connection from
Give-and-take
Git is designed to give each programmer an entirely isolated development surroundings. This means that information is not automatically passed dorsum and forth between repositories. Instead, developers need to manually pull upstream commits into their local repository or manually push their local commits back up to the central repository. The git remote command is actually just an easier way to laissez passer URLs to these "sharing" commands.
The origin Remote
When you clone a repository with git clone, information technology automatically creates a remote connection called origin pointing back to the cloned repository. This is useful for developers creating a local re-create of a cardinal repository, since it provides an like shooting fish in a barrel way to pull upstream changes or publish local commits. This behavior is also why most Git-based projects call their central repository origin.
Repository URLs
Git supports many ways to reference a remote repository. Two of the easiest ways to access a remote repo are via the HTTP and the SSH protocols. HTTP is an easy mode to let anonymous, read-only admission to a repository. For example:
http://host/path/to/repo.git But, it's mostly not possible to button commits to an HTTP address (yous wouldn't want to allow bearding pushes anyways). For read-write admission, you should use SSH instead:
ssh://[email protected]/path/to/repo.git Y'all'll need a valid SSH business relationship on the host machine, but other than that, Git supports authenticated access via SSH out of the box.
Examples
In add-on to origin, it's often convenient to take a connexion to your teammates' repositories. For example, if your co-worker, John, maintained a publicly accessible repository on dev.example.com/john.git, you could add a connection as follows:
git remote add john http://dev.example.com/john.git Having this kind of admission to individual developers' repositories makes it possible to collaborate outside of the key repository. This tin exist very useful for small teams working on a large projection.
git fetch
The git fetch command imports commits from a remote repository into your local repo. The resulting commits are stored as remote branches instead of the normal local branches that we've been working with. This gives you a chance to review changes before integrating them into your re-create of the project.
Usage
git fetch <remote> Fetch all of the branches from the repository. This also downloads all of the required commits and files from the other repository.
git fetch <remote> <branch> Aforementioned equally the above command, simply only fetch the specified co-operative.
Word
Fetching is what you practise when you lot want to see what everybody else has been working on. Since fetched content is represented equally a remote branch, information technology has admittedly no effect on your local development work. This makes fetching a safety way to review commits before integrating them with your local repository. It's like to svn update in that it lets you see how the primal history has progressed, but information technology doesn't force you to actually merge the changes into your repository.
Remote Branches
Remote branches are just similar local branches, except they represent commits from somebody else's repository. Y'all can bank check out a remote branch simply like a local one, simply this puts you in a detached Caput country (but similar checking out an old commit). You tin can think of them as read-simply branches. To view your remote branches, only pass the -r flag to the git branch command. Remote branches are prefixed past the remote they belong to and so that yous don't mix them upwards with local branches. For example, the next code snippet shows the branches you might see after fetching from the origin remote:
git branch -r # origin/master # origin/develop # origin/some-feature Once more, you can inspect these branches with the usual git checkout and git log commands. If yous approve the changes a remote co-operative contains, you can merge it into a local branch with a normal git merge. So, unlike SVN, synchronizing your local repository with a remote repository is actually a two-step process: fetch, then merge. The git pull command is a convenient shortcut for this process.
Examples
This case walks through the typical workflow for synchronizing your local repository with the cardinal repository'southward master branch.
git fetch origin This volition brandish the branches that were downloaded:
a1e8fb5..45e66a4 master -> origin/master a1e8fb5..9e8ab1c develop -> origin/develop * [new co-operative] some-feature -> origin/some-feature The commits from these new remote branches are shown every bit squares instead of circles in the diagram below. Equally you tin can encounter, git fetch gives you admission to the entire branch construction of another repository.
To encounter what commits have been added to the upstream master, you lot can run a git log using origin/primary as a filter
git log --oneline master..origin/master To corroborate the changes and merge them into your local master branch with the following commands:
git checkout master git log origin/master Then nosotros can use git merge origin/chief
git merge origin/master The origin/master and master branches at present point to the aforementioned commit, and you are synchronized with the upstream developments.
git pull
Merging upstream changes into your local repository is a common chore in Git-based collaboration workflows. Nosotros already know how to practise this with git fetch followed by git merge, merely git pull rolls this into a unmarried control.
Usage
git pull <remote> Fetch the specified remote's copy of the current branch and immediately merge it into the local copy. This is the aforementioned as git fetch <remote> followed by git merge origin/<current-branch>.
git pull --rebase <remote> Same as the to a higher place command, but instead of using git merge to integrate the remote branch with the local one, use git rebase.
Discussion
Yous can think of git pull equally Git's version of svn update. It's an piece of cake manner to synchronize your local repository with upstream changes. The following diagram explains each step of the pulling process.
You start out thinking your repository is synchronized, just so git fetch reveals that origin's version of master has progressed since you lot last checked it. Then git merge immediately integrates the remote principal into the local one:
Pulling via Rebase
The --rebase option can be used to ensure a linear history by preventing unnecessary merge commits. Many developers prefer rebasing over merging, since it'due south like proverb, "I desire to put my changes on tiptop of what everybody else has done." In this sense, using git pull with the --rebase flag is even more than similar svn update than a plain git pull.
In fact, pulling with --rebase is such a common workflow that there is a dedicated configuration option for it:
git config --global branch.autosetuprebase always After running that command, all git pull commands volition integrate via git rebase instead of git merge.
Examples
The following example demonstrates how to synchronize with the fundamental repository's primary co-operative:
git checkout master git pull --rebase origin This just moves your local changes onto the top of what everybody else has already contributed.
git push
Pushing is how you transfer commits from your local repository to a remote repo. Information technology'due south the counterpart to git fetch, but whereas fetching imports commits to local branches, pushing exports commits to remote branches. This has the potential to overwrite changes, so yous demand to be conscientious how you lot use it. These problems are discussed below.
Usage
git push <remote> <co-operative> Push the specified co-operative to
git push <remote> --force Same equally the above command, but forcefulness the push even if it results in a non-fast-forrad merge. Do not use the --force flag unless you're absolutely sure you know what you're doing.
git push <remote> --all Push button all of your local branches to the specified remote.
git push button <remote> --tags Tags are not automatically pushed when you lot push button a co-operative or use the --all choice. The --tags flag sends all of your local tags to the remote repository.
Discussion
The nearly common employ instance for git push is to publish your local changes to a central repository. Later you've accumulated several local commits and are gear up to share them with the residual of the team, you (optionally) clean them upward with an interactive rebase, so push them to the central repository.
The above diagram shows what happens when your local main has progressed by the central repository's master and you publish changes by running git push origin primary. Notice how git push is substantially the same as running git merge master from inside the remote repository.
Forcefulness Pushing
Git prevents y'all from overwriting the central repository's history by refusing button requests when they result in a non-fast-forward merge. And then, if the remote history has diverged from your history, yous need to pull the remote co-operative and merge information technology into your local 1, then try pushing again. This is similar to how SVN makes you synchronize with the fundamental repository via svn update before committing a changeset.
The --strength flag overrides this beliefs and makes the remote repository's branch match your local one, deleting any upstream changes that may accept occurred since you last pulled. The only fourth dimension y'all should ever need to forcefulness push button is when you realize that the commits you but shared were not quite correct and you fixed them with a git commit --amend or an interactive rebase. All the same, yous must exist admittedly certain that none of your teammates have pulled those commits earlier using the --forcefulness pick.
Only Push to Bare Repositories
In improver, you should but button to repositories that have been created with the --blank flag. Since pushing messes with the remote co-operative structure, information technology'south important to never push to another developer's repository. But because bare repos don't have a working directory, information technology'south impossible to interrupt everyone'southward developments.
Examples
The following example describes 1 of the standard methods for publishing local contributions to the key repository. Get-go, it makes certain your local master is up-to-date by fetching the primal repository's copy and rebasing your changes on top of them. The interactive rebase is also a skillful opportunity to clean upwards your commits before sharing them. Then, the git push button command sends all of the commits on your local principal to the fundamental repository.
git checkout primary git fetch origin main git rebase -i origin/master # Squash commits, fix up commit letters etc. git push origin chief Since nosotros already made certain the local chief was upwards-to-date, this should outcome in a fast-forrard merge, and git push should not mutter nigh whatever of the non-fast-forrard bug discussed to a higher place.
Source: https://sillevl.gitbooks.io/git/content/collaboration/syncing/
0 Response to "How To Merge Local Repo With Remote"
Post a Comment