From 4bcbaeaa72b1a9c4999da672e558cae2e7f1d94b Mon Sep 17 00:00:00 2001 From: Adrien Ollier Date: Sat, 9 Mar 2019 15:54:10 +0100 Subject: [PATCH 1/2] fetch and push with different repositories closes #1173 --- book/06-github/sections/2-contributing.asc | 60 ++++++++++++++++++++++ book/10-git-internals/sections/refspec.asc | 6 +++ 2 files changed, 66 insertions(+) diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 5ee613388..95ac50363 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -43,6 +43,7 @@ Here's how it generally works: 5. Open a Pull Request on GitHub. 6. Discuss, and optionally continue committing. 7. The project owner merges or closes the Pull Request. +8. Put the changes back in your GitHub public repository. This is basically the Integration Manager workflow covered in <>, but instead of using email to communicate and review changes, teams use GitHub's web based tools. @@ -417,3 +418,62 @@ This isn't technically GitHub Flavored Markdown, but it is incredibly useful. In image::images/markdown-08-drag-drop.png[Drag and drop images] If you look at <<_md_drag>>, you can see a small ``Parsed as Markdown'' hint above the text area. Clicking on that will give you a full cheat sheet of everything you can do with Markdown on GitHub. + +[[_fetch_and_push_on_different_repositories]] +==== Keep your GitHub public repository up-to-date + +Once you forked from a GitHub repository, your forked repository lives alone and is autonomous regarding the original one. +In particular, when the original repository has new commits, GitHub informs you by a message like: +[source,text] +---- +This branch is X commits behind :master. +---- +For example: +[source,text] +---- +This branch is 5 commits behind progit:master. +---- + +But your GitHub repository will never be automatically updated by GitHub; this is something that you must do yourself. +Fortunately, this is very easy to do. + +One possibility to do this requires no configuration. +For example, if you forked from `https://github.com/progit/progit2.git`, you can keep your `master` branch up-to-date like this: + +[source,console] +---- +$ git checkout master <1> +$ git pull https://github.com/progit/progit2.git <2> +$ git push origin master <3> +---- +<1> If you were on another branch, return to `master`. +<2> Fetch changes from `https://github.com/progit/progit2.git` and merge them into `master`. +<3> Push your `master` branch to `origin`. + +This just works but it is a little verbose. +Another possibility allows to do the same thing without the need to precise the repositories to pull from and push to. +To do so, you need a few configuration: + +[source,console] +---- +$ git remote add progit https://github.com/progit/progit2.git <1> +$ git branch --set-upstream-to=progit/master master <2> +$ git config --local remote.pushDefault origin <3> +---- +<1> Add the source repository and give it a name. + Here, I have chosen to call it `progit`. +<2> Set your `master` branch follow `progit`. + Then your future fetches will fetch from `progit`. +<3> Define the default push repository to `origin`. + +Now you can fetch from `progit` and push to `origin` as simply as: + +[source,console] +---- +$ git checkout master <1> +$ git pull <2> +$ git push <3> +---- +<1> If you were on another branch, return to `master`. +<2> Fetch changes from `progit` and merge changes into `master`. +<3> Push your `master` branch to `origin`. diff --git a/book/10-git-internals/sections/refspec.asc b/book/10-git-internals/sections/refspec.asc index 19286a7f6..8d1f78074 100644 --- a/book/10-git-internals/sections/refspec.asc +++ b/book/10-git-internals/sections/refspec.asc @@ -120,6 +120,12 @@ If they want Git to do that automatically each time they run `git push origin`, Again, this will cause a `git push origin` to push the local `master` branch to the remote `qa/master` branch by default. +[NOTE] +==== +You cannot use the refspec to fetch from one repository and push to another one. +For an example to do so, refer to <>. +==== + ==== Deleting References You can also use the refspec to delete references from the remote server by running something like this: From 9a48cdaf347c25174d188042ff919881e97cbd42 Mon Sep 17 00:00:00 2001 From: Ben Straub Date: Sun, 10 Mar 2019 17:07:43 -0700 Subject: [PATCH 2/2] Suggest some changes --- book/06-github/sections/2-contributing.asc | 27 +++++++++++----------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 95ac50363..6fe3afc39 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -43,7 +43,7 @@ Here's how it generally works: 5. Open a Pull Request on GitHub. 6. Discuss, and optionally continue committing. 7. The project owner merges or closes the Pull Request. -8. Put the changes back in your GitHub public repository. +8. Sync the updated master back to your fork. This is basically the Integration Manager workflow covered in <>, but instead of using email to communicate and review changes, teams use GitHub's web based tools. @@ -422,13 +422,9 @@ If you look at <<_md_drag>>, you can see a small ``Parsed as Markdown'' hint abo [[_fetch_and_push_on_different_repositories]] ==== Keep your GitHub public repository up-to-date -Once you forked from a GitHub repository, your forked repository lives alone and is autonomous regarding the original one. +Once you've forked a GitHub repository, your repository (your "fork") exists independently from the original. In particular, when the original repository has new commits, GitHub informs you by a message like: -[source,text] ----- -This branch is X commits behind :master. ----- -For example: + [source,text] ---- This branch is 5 commits behind progit:master. @@ -446,13 +442,13 @@ $ git checkout master <1> $ git pull https://github.com/progit/progit2.git <2> $ git push origin master <3> ---- + <1> If you were on another branch, return to `master`. <2> Fetch changes from `https://github.com/progit/progit2.git` and merge them into `master`. <3> Push your `master` branch to `origin`. -This just works but it is a little verbose. -Another possibility allows to do the same thing without the need to precise the repositories to pull from and push to. -To do so, you need a few configuration: +This works, but it is a little tedious having to spell out the fetch URL every time. +You can automate this work with a bit of configuration: [source,console] ---- @@ -460,13 +456,13 @@ $ git remote add progit https://github.com/progit/progit2.git <1> $ git branch --set-upstream-to=progit/master master <2> $ git config --local remote.pushDefault origin <3> ---- + <1> Add the source repository and give it a name. Here, I have chosen to call it `progit`. -<2> Set your `master` branch follow `progit`. - Then your future fetches will fetch from `progit`. +<2> Set your `master` branch to fetch from the `progit` remote. <3> Define the default push repository to `origin`. -Now you can fetch from `progit` and push to `origin` as simply as: +Once this is done, the workflow becomes much simpler: [source,console] ---- @@ -474,6 +470,11 @@ $ git checkout master <1> $ git pull <2> $ git push <3> ---- + <1> If you were on another branch, return to `master`. <2> Fetch changes from `progit` and merge changes into `master`. <3> Push your `master` branch to `origin`. + +This approach can be useful, but it's not without downsides. +Git will happily do this work for you silently, but it won't warn you if you make a commit to `master`, pull from `progit`, then push to `origin` -- all of those operations are valid with this setup. +So you'll have to take care never to commit directly to `master`, since that branch effectively belongs to the upstream repository.