GitHub Shell Info and Forking

[ebeshero]

develop / add to existing tutorial(s) for DH classes on GitHub to include info on Forking and shell commands.
See ebeshero/DHClass-Hub#92

[RJP43]

This is the fork and branch method that I am leading students through on the new GitHub tutorial. By my understanding, this will allow you to keep the origin forked repo. synced and the individual's development is done in a cloned branch of the forked repo. A general diagram to explain what I mean is below:

And here is the page this diagram is from where you can find more information.

@ebeshero @ghbondar @djbpitt does this seem like a logical process to lead students through? I also will show students how to create their own repos. from scratch as well as what we already discussed regarding the basics of creating an account, downloading the desktop client, etc. One of the biggest things that is new using this way of working in the DH Class Hub is that the instructors (who are collaborators) will need to make sure that if a student posts an issue and wants to add a file to the trouble shooting "garage" we will need to accept that pull request to add the file or files they are trying to have troubleshooted. This isn't really a problem, but it will be different than last semester where students were able to respond to students by pushing code back and forth into that folder without needing the pull request approval. However, we did see most of students took advantage of the markdown feature in the issues and were sharing a large portion of code there so I don't really see this as a problem and more of as just something we need to consider.

[djbpitt]

Dear Becca, Elisa, and Greg,

The most common work flow in my course has been that students control their
own project repo. At the moment they all work in the master branch, and
they probably should be creating separate branches for different
development tasks and merging those into the master when they're completed.
What I don't think they'll do much is fork, since it's fundamentally their
project and their repo.

The work flow in the Greensburg course, though, may be different, since
some of the projects are larger, of longer duration, and not the personal
projects of all of the students involved. In that case the forking model,
illustrated above, seems more appropriate. That's also the model I followed
when I was working on CollateX last month, where it's important that the
master branch of the main repo always be usable, and other contributions
aren't merged into that until they've undergone pretty thorough testing.
What I did there was create my own fork with a master branch and one or two
development ones, and I worked exclusively there. When the development code
seemed solid, I merged it into the master branch of my own fork. I created
and deleted development branches as needed, sometimes working on different
tasks in different development branches at the same time. I didn't issue
pull requests because the lead developer, who maintains the original repo,
can pull from my fork without my requesting it explicitly, but the more
common way of contributing to a project is to make a formal pull request.

I think one possible point of confusion for new users (and perhaps even
some not-so-new users) will be the differences among cloning, branching,
and forking, all of which may sound like "making a copy" to someone who
hasn't yet learned the idiom. That isn't a problem, and the fact that
Greensburg students may be forking more mature projects while Oakland
students work out of a single repo on their own new projects is an
opportunity to illustrate how different work flows are appropriate to
different project circumstances.

Best,

David

On Mon, Jan 4, 2016 at 5:53 PM, Rebecca Parker [email protected]
wrote:

This is the fork and branch method that I am leading students through on
the new GitHub tutorial. By my understanding, this will allow you to keep
the origin forked repo. synced and the individual's development is done in
a cloned branch of the forked repo. A general diagram to explain what I
mean is below:

[image: forkandbranchmethod]
https://cloud.githubusercontent.com/assets/8645521/12102630/0e6cf9d2-b30a-11e5-9283-4c03aefbb2bd.jpg

And here is the page
http://support.rightscale.com/12-Guides/Chef_Cookbooks_Developer_Guide/04-Developer/Source_Control_Management_Systems/GitHub/Clone_vs._Fork/
this diagram is from where you can find more information.

@ebeshero https://github.com/ebeshero @ghbondar
https://github.com/ghbondar @djbpitt https://github.com/djbpitt does
this seem like a logical process to lead students through? I also will show
students how to create their own repos. from scratch as well as what we
already discussed regarding the basics of creating an account, downloading
the desktop client, etc. One of the biggest things that is new using this
way of working in the DH Class Hub is that the instructors (who are
collaborators) will need to make sure that if a student posts an issue and
wants to add a file to the trouble shooting "garage" we will need to accept
that pull request to add the file or files they are trying to have
troubleshooted. This isn't really a problem, but it will be different than
last semester where students were able to respond to students by pushing
code back and forth into that fold er witho ut needing the pull request
approval. However, we did see most of students took advantage of the
markdown feature in the issues and were sharing a large portion of code
there so I don't really see this as a problem and more of as just something
we need to consider.

—
Reply to this email directly or view it on GitHub
#11 (comment)
.

[ebeshero]

@RJP43 Becca and all: Here's what I'm thinking: we can make forking and pull requests a sort of homework assignment in the garage environment of our DH-ClassHub, but still actually permit each student to push there as they've always done, since it's pretty standard practice and probably the most stable and valuable content there is, as you've noted, the Issues board--the help tickets the students work on together. I'm worrying a bit over the immediacy of attention our students sometimes want at 11 PM or after midnight when we're not always online, so maybe DH-ClassHub really ought to be a live environment. (There, I think you convinced me of that, after all!) But if we want them to work from a fork, we can have the class test drive your new and improved tutorial, and maybe a little ways into the course. (We'll start with our little pool of returning students, first, and discuss how best to implement a practice of forking and/or branching.)

Thoughts?
Elisa

[RJP43]

@ebeshero Sounds good! Okay, I need to do some adjustments then I will move the files I have been working with into @djbpitt 's DropBox for review... sorry for the delay.

[ebeshero]

@RJP43 Becca is discovering that any collaborator, or really anyone at all who makes a fork (whether a collaborator or no) seems to be able to make a pull request and is prompted with an offer to automatically merge--and whether that automatic merge is with the original repo or just a way to update the fork(?) is a question I have. Anyway, the question of whether you can make it so collaborators on a repo must all issue pull requests that must be reviewed by someone else is something I see under discussion here:
https://github.com/gitlabhq/gitlabhq/issues/6432

I'd like to get a group of our returning students together (and perhaps some of David's instructors too) to help test some of this--maybe we'll call it "wreck a repo" so we can concentrate on breaking things as much as possible. Becca, let's talk to Nicole, Rob, and Brooke about this tomorrow, okay? David, may I invite Andrew and Alex and/or other instructors to help with this? @djbpitt

[ebeshero]

Okay-- Becca kept working and made more changes, and the invitation to merge automatically was not renewed. I think we clearly need to be testing this a bit to see what's what.

[RJP43]

Working Command Line From a Local Fork:

Created a fork - working on local computer in local fork
if origin is the fork -- origin set to local fork name
in order to be synced to original repo. need to tell GitHub what is upstream from the local forked repo.
Commands:

1. git remote add upstream (then put https link of original repository : identifying what upstream is
2. git remote -v : this quickly verifies that origin is forked repo. and the upstream is original repo.
3. git fetch origin -v : fetching any changes made in origin repo.(local fork)
4. git fetch upstream -v : fetching any changes made in upstream repo. (original)
   this stored upstream changes in an "upstream branch" on the fork
5. git merge upstream/master : merges fork with branch made from the fetched upstream changes
6. git push : pushed changes to local origin (forked repository)

from there created pull request to original repo.

(notes according to experiment on CitySlaveGirls repo. with Dr. B.)

[ebeshero]

@RJP43 Here's a good resource on fetch and merge, vs. pull:
http://longair.net/blog/2009/04/16/git-fetch-and-merge/

[RJP43]

there is a section here in the readme on viewing the open issues from command line of any given repository that I want to include in the tutorial so i am dropping the link here for safe keeping.

[RJP43]

https://developer.github.com/v3/repos/collaborators/ -- adding a collaborator through Git Shell

[RJP43]

@djbpitt
(in both of the following images the remote repo was ahead of my local machine)
git status -uno on a cloned repo. does seem to tell you if you are behind the remote origin

but yes if working in a fork it doesn't tell you if you are behind
this was taken in my forked repo of this repo.

I am going to continue messing with this, but I just wanted to add this here to clarify why I had suggested git status -uno

[djbpitt]

Dear Becca,

Apparently your results with "status -uno" are different from mine. I was
working in a simple configuration, with no forks and just a master branch.
I made changes in my office yesterday and pushed them. At home today the
status check didn't show that clone on my home machine was behind, but the
other commands did. I may have screwed up, or perhaps there's an
inconsistency in the client (I'm in Mac OS), and I can experiment some more
when I'm back on campus on Monday. It's obvious that you aren't wrong
because you're seeing the results you report, so the question is why am I
seeing something different?

Best,

David

On Jan 16, 2016, at 1:23 PM, Rebecca Parker [email protected]
wrote:

@djbpitt https://github.com/djbpitt

(in both of the following images the remote repo was ahead of my local
machine)
git status -uno on a cloned repo. does seem to tell you if you are behind
the remote origin
[image: clonerepo_gitstatus-uno_behind]
https://cloud.githubusercontent.com/assets/8645521/12373789/cd7e8ca8-bc53-11e5-88b3-7619bf038535.jpg
but yes if working in a fork it doesn't tell you if you are behind
[image: forkrepo_opengitstatus-uno]
https://cloud.githubusercontent.com/assets/8645521/12373793/e88ec4c2-bc53-11e5-8058-d19ef9f45325.jpg
I am going to continue messing with this, but I just wanted to add this
here to clarify why I had suggested git status -uno

—
Reply to this email directly or view it on GitHub
#11 (comment)
.

[RJP43]

@djbpitt very interesting! another command I am experimenting with but in the forking environement is git remote -v show upstream. This told me that my local branch was out of date

more to come on this as I experiment further!

@spadafour could you test what we were commenting on in the past two comments of this issue on your mac to see if you get the same results as David. Go to a repo you have cloned where changes have been made (a good one is DHClass-Hub - unless you have that forked - since changes have been made there today) in the desktop client before syncing right click on the repo name and open it in Git Shell. Try this command git status -uno and report back if it shows that your local machine (or branch as it will be called) is behind the remote. Please, if it doesn't look like the image below just reply here saying so

from there you can refer to this issue to sync and then that way you will have also experimented with the commands I commented on in the DHClass-Hub issue.

@andrewntz23 I think you also have a mac if you wanted to experiment with this also

... thanks

[ebeshero]

A useful list of shell commands for GitHub:
https://gist.github.com/hofmannsven/6814451