Differences

This shows you the differences between two versions of the page.

--- git_github_workflow [2020/01/27 14:36] – [Adding a remote for the public project] rpjday
+++ git_github_workflow [2020/01/27 17:03] (current) – [Clone your personal fork to your local machine] rpjday
@@ Line 21: / Line 21: @@
 ==== Clone your personal fork to your local machine ====
-Once you've made that personal GitHub fork (agin, in my case, ''rpjday/libpod''), you need to make one more copy of the repository -- this one will be clone of your personal fork to your //local// machine, which represents the working tree in which you create new branches and make local changes that you'll push to your GitHub fork for eventual incorporation into the public project, but here's the trick for clarity.
+Once you've made that personal GitHub fork (agin, in my case, ''rpjday/libpod''), you need to make one more copy of the repository -- this one will be a clone of your personal fork to your //local// machine, which represents the working tree in which you create new branches and make local changes that you'll push to your GitHub fork for eventual incorporation into the public project, but here's the trick for clarity.
-Since you'll (shortly) be working with two remotes for this workflow, when you clone your personal fork, select a remnote name other than the default of ''origin'' -- I'll use the remote name of ''rpjday'' to clearly identify that this is my personal fork over at GitHub, not the public project:
+Since you'll (shortly) be working with two remotes for this workflow, when you clone your personal fork, select a remote name other than the default of ''origin'' -- I'll use the remote name of ''rpjday'' to clearly identify that this is the remote corresponding to my personal fork over at GitHub, not the public project:
 <code>
 $ mkdir podman/libpod
 $ cd podman/libpod
-$ git clone https://github.com/rpjday/libpod git
+$ git clone -o rpjday https://github.com/rpjday/libpod git
 </code>
@@ Line 43: / Line 43: @@
 </code>
-In addition, you can verify that your local clone has one registered remote -- your personal GitHub fork:
+In addition, you can verify that your local clone has one registered remote -- your personal GitHub fork with remote name ''rpjday'':
 <code>
@@ Line 58: / Line 58: @@
 In addition to the remote for your personal fork, you need to register a //second// remote representing the public project, as this is where you'll //pull// new content from, including any of your pull requests that are accepted and merged into the public master branch.
-Again, for clarity, choose a remote name other than the default of ''origin'' -- I like to use the project name itself:
+Again, for clarity, choose a remote name other than the default of ''origin'' -- I like to use the project name itself (in this case, ''libpod''):
 <code>
@@ Line 65: / Line 65: @@
 </code>
-You can now verify that your local clone has two registered remotes -- one for pulling new content added to the public project (''libpod'', and the second your personal remote for pushing changes (''rpjday''):
+You can now verify that your local clone has two registered remotes -- one for pulling new content added to the public project (''libpod''), and the second your personal remote for pushing your submitted changes (''rpjday''):
 <code>
@@ Line 97: / Line 97: @@
 </code>
-==== Keeping up to date ====
+==== Keeping up to date with public content ====
-Before you even start contributing to the main project, there are three steps involved in keeping up with everyone else's contributions.
+Even as you're working on contributions to the public project, there is undoubtedly new content being merged into its ''master'' branch from others, and you probably want to keep up with that new content in case you need to rebase any of your work on top of it.
-First, fetch from the upstream ''progit'' remote into the remote tracking branch ''progit/master'':
+First, you can, as often as you like, fetch from the upstream (public project) ''libpod'' remote into your remote tracking branch ''libpod/master'' with:
 <code>
-$ git fetch progit
+$ git fetch libpod
 </code>
-Next, manually merge any new content into your local ''master'' branch:
+Occasionally, you might want to merge that new content into your local ''master'' branch in case you need to do any local rebasing:
 <code>
-$ git merge progit/master
+$ git checkout master
+$ git merge libpod/master
 </code>
-Finally, push this new content to your GitHub fork of the project:
+Finally, whenever you update your local master branch, you should push it to your personal fork (which is how your personal fork at GitHub gets updated):
 <code>
-$ git push origin master
+$ git push rpjday master
 </code>
 Do all of this on a regular basis to keep everything in sync.
-==== Contributing changes ====
+===== Contributing changes =====
-Contributing changes to the main project involves three steps:
+==== The general steps in contributing changes ====
+Contributing changes to the public GitHub project involves three steps:
   * Make and commit some //local changes// (preferably on a feature branch).
-  * Push those changes (that branch) to your GitHub fork.
+  * Push those changes (that branch) to your personal GitHub fork.
-  * Make a "pull request" to have the main project accept your commit(s) on that branch.
+  * Over at GitHub, make a "pull request" to have the main project accept your changes on that branch.
+==== Making some local changes ====
-First, create a new branch, make and commit a silly change:
+For each set of related changes, start a new feature branch with a distinct name that reflects what that branch is doing:
 <code>
-$ git checkout -b topic/rpjday/issue42
+$ git checkout -b rpjday/README_changes
-Switched to a new branch 'topic/rpjday/issue42'
+Switched to a new branch 'rpjday/README_changes'
 $
 </code>
-Make a simple change to ''README.asc'' and commit it:
+For our example, make some trivial changes to the top-level ''README.md'' file, and locally commit those changes on that branch:
 <code>
-$ git checkout -b topic/rpjday/issue42
+$ git commit -a -m "README.md: silly changes"
-Switched to a new branch 'topic/rpjday/issue42'
+[rpjday/README_changes b1a09348] README.md: silly changes
+file changed, 4 insertions(+)
 $
 </code>
+==== Pushing your work ====
+You can continue adding and committing (related) work to this feature branch and, once you're satisfied, you can push that branch to your personal GitHub fork with:
 <code>
-$ git commit -a -m "fix issue42"
+$ git push rpjday rpjday/README_changes
-[topic/rpjday/issue42 77fad5f] topic/rpjday/issue42
-file changed, 1 insertion(+), 1 deletion(-)
-$
 </code>
-<code>
+==== And over At GitHub ====
-$ git show
-commit 77fad5f0aadd229628baa7811b0b49c7580d96f0 (HEAD -> topic/rpjday/issue42)
-Author: Robert P. J. Day <rpjday@crashcourse.ca>
-Date:   Wed Feb 14 07:06:42 2018 -0500
-    fix issue42
+Provided you're logged into your account at GitHub, you'll suddenly see the appearance of a new branch ''rpjday/README_changes''. If you think it's ready to go, you can select "Compare & pull request" to examine and confirm that you want to hand that off to the main project.
-diff --git a/README.asc b/README.asc
+If all goes well and your change is accepted and committed (in this case, into the ''master'' branch), you will have to perform the two earlier steps to fetch and merge your changes into your local clone into the ''master'' branch:
-index d7810fd..126bfd4 100644
---- a/README.asc
+<code>
-+++ b/README.asc
+$ git fetch libpod
-@@ -1,4 +1,4 @@
+$ git merge libpod/master
--= Pro Git, Second Edition
-+= Pro Git, Second Edition (rday change)
- Welcome to the second edition of the Pro Git book.
-$
 </code>
-At this point, you can push this new branch to your GitHub fork:
+In addition, if you have no further need of that local feature, you can delete it:
 <code>
-$ git push origin topic/rpjday/issue42
+$ git branch -d rpjday/README_changes
 </code>
-==== And over At GitHub ====
+==== Adjusting your local branch ====
-Provided you're logged into your account at GitHub, you'll suddenly see the appearance of a new branch ''sillyb''. If you think it's ready to go, you can select "Compare & pull request" to examine and confirm that you want to hand that off to the main project.
+Given the possibility that your pull request might provoke some comments about possible improvements, you can make those local improvements, stage them and commit them on the same branch as before, then force push that branch to replace the older one:
-If all goes well and your change is accepted and committed, you will have to perform the two earlier steps to fetch and merge your changes into your local clone into the ''master'' branch:
 <code>
-$ git fetch progit
+$ git push -f rpjday rpjday/README_changes
-$ git merge progit/master
 </code>
-In addition, you can now delete the ''sillyb'' branch if you have no further use for it.