coderefinery/git-collaborative

Collaborative distributed version control lesson.

Collaborative distributed version control

git-collaborative's Issues

Explain better how and why to start and use issues on GitHub/Lab

Since it’s used later in the testing lesson.

Suggestion for collaborative exercise with a conflict

Idea by @Jyrsa: pair of pairs, first two pairs of two people start with the same basic repository with some existing files, both groups make concurrent changes, first by making well-contained small branches from master and then submit to each other for review and merging.

Then after the "clean" way has been done they can try doing any of a number of things that will cause merge conflicts and try to resolve them.

Mention "draft pull requests"

As alternative to "WIP" PRs.

Make it possible to define exercise URLs in the config file

For simpler reuse in spin-off workshops and courses.

05-hook: Add an example

Hooks episode could use at least one example (preferably not esoteric). I don't know any good ones offhand, though.

Mention "git describe"

Example: git describe --abbrev=7 --long --always --dirty=-feature_smudge-clean.

basically it describes the current state of the repo using the closest tag in history.
so assuming you tag meaningfully what you'd read from a git describe is:
closest tag followed by number of commits current revision has on top
followed by SHA1 of current commit (abbreviated by default)
optionally, if you're in a dirty state you can add a suffix with --dirty
(which by default add -dirty, but you can choose whatever).

(thanks to Roberto for the hint!)

Does protip of `set-url --push` need to be in 03-distributed?

Does the pro-tip in 03-distributed about separate push URLs need to be there? We don't use it anywhere, and it can probably be a bit confusing. (I've been confused by it when I didn't realize I had a separate push URL). But in at practical tips section it could be nice to mention as advanced material.

Related, does anyone use this often? I have once or twice, but I have a feeling that perhaps I should more often.

Episode 03-distributed type-along doesn't need to be in a group

It seems that the type-along in 03-distributed doesn't need to be done in a group. In fact, while helping I was confused because it took some time for me to figure out why it said to break into groups... it was something in automated testing that did the mutual forking and accepting of PRs.

consider teaching this lesson not first thing in the morning

for the reason that if someone shows up late then it's complicated to get them up to date (i.e. adding to the centralized-workflow-exercise). After lunch or starting mid-morning might be better

Style tagged commits in branching model figure

Tagging commits: maybe put an x in the circle, so they stand out a bit.

Forking vs. centralized

Forking workflow is standard for open source projects but may be overkill for small closed-source projects. Discuss recommended workflows for closed source projects. Who should be the maintainer? Emphasize better that central workflow is also fine provided we use protected branches.

Non-bare and bare repositories - Instructions are incomplete.

There is a statement "Clone this repository on the same computer with either --bare or --mirror" and not enough guidance given

add git status in lesson 1

and maybe lesson 2 as well

"Centralized workflow with protected branches" seems misplaced

Move this from the forking episode to the centralized episode.

consider adding origin/HEAD pointer to graphics

because it actually exists. Clarify also why it's there

Collaborative distributed version control - iteration and issue triage

Also update instructor guide.

Update centralized-workflow exercise to reflect the lesson precisely

The graphs should look the same as the lesson. I will do that after #54.

Give hints on how to contribute changes to somebody else's project

• Create issue
• Describe problem/suggestion
• Discuss
• Indicate who is working on it
• Submit PR which references/closes the issue

Explain upstream

I know that popular support is to circumvent going in to details about upstream. But I felt during todays lecture if we explicitly address this rather than avoiding, learners would have a better understanding of the events.

Comment on repository integrity and security

How to make sure to not accidentally accept a back-door exploit in a pull request.

Add Star Wars quote

Luke Skywalker: You know, I did feel something. I could almost see the remote.

Ben Kenobi: That's good. You've taken your first step into a larger world.

(from Star Wars Episode IV - A New Hope)

Cheers to @Jyrsa for the catch!

Check whether bare/nonbare episode is still needed

I just did few tests on my hard drive with bare/nonbare and some of my assumptions about it were wrong. I need to test a bit more but possibly we can avoid that part all together. Opening this issue so that I won't forget.

automated testing for forking-workflow-exercise is missing if instructor mirrors to own github namespace

i think we used to have coderefinery/forking-workflow-exercise connected to Travis, so that we could see the red/green lights on the PRs. This was nice as it gave a hint of what was to come in the testing lesson. Probably we should add to instructor notes that the mirrored repo should be connected to travis

when inviting everyone to repo, use invite link instead

all participants need to be invited to the centralized-workflow-exercise, and it seems simpler to click "copy invite link" and paste it in the shared workshop document. the link is the same for all invited users and following it leads directly to an "accept this invitation" page

Reference "level of git" from centralized collaborative workflow?

Would it be useful to reference the level of git lesson https://coderefinery.github.io/git-intro/14-level/ from "Collaborative distributed version control: Working with remotes and centralized workflow" (https://github.com/coderefinery/git-collaborative/blame/gh-pages/_episodes/01-remotes.md#L250)?

In the tweet exercise add travis test

Here participants don't have to prepare anything and it will test in the background, e.g. length of the tweet. With this people can discover Travis early in the course.

clarify how e.g. github is both bare and non-bare repo

it can be confusing since we do make a commit directly on github in the git-intro demo

Cannot delete repositories in coderefinery

The lesson requires to be able to delete two repositories before a workshop:

• https://github.com/coderefinery/centralized-workflow-exercise
• https://github.com/coderefinery/forking-workflow-exercise

I cannot delete these two repositories.

This method forbids us to have several workshops simultaneuously and also requires anyone to get access to coderefinery organization.

Should we prefer each of us to import the template repositories to our own github username?

Motivate code review

Mainly code quality but also collaborative learning but do not drop the quality aspect.

Color-code the "start of ...", "tag...", "severe bug..." balloons in the branching model figure

Introduce terms before mentioning

In branch design topic git bisect was mentioned in the beginning, but at this point git bisect was not introduced yet. In my opinion good to briefly tell what git bisect actually is.

Consider adding git commands to the branching model figure

Consider adding the proper git command on the arrows. For example, when merging from hotfix to stable, and from stable to master. Also having the commands for tagging would be helfpul.

Reforking exercises from bast/ to coderefinery/ leads to PR landing on bast/

To avoid confusion we might need to go back to what we had before.

In central collab exercise consider first creating a branch before working on master

This would lead to a cleaner history when we accept the PRs and browse the "network".

in forking exercise, let people form groups and choose their own filenames

since it's cumbersome to split people into group and assign group numbers. This means we need to rewrite main.py and test.py in https://github.com/coderefinery/forking-workflow-exercise to read all .py files except main.py

Make it possible to host a spin-off workshop without us doing anything

Consider protecting master branch before collaborative exercise starts

To avoid that somebody manages to push changes before we start.

Add examples to 04-collaborative

04-collaborative could link to some real projects and use them as examples. Could be as simple as for each suggestion, linking to a thread demonstrating that. Or could make the section more example-based.

rebase/force example should IMO move to branch design lesson

IMO this repo is not the most natural place to discuss this advanced concept.

git-collab has pratcical tips, as does git-intro

Both have practical tips... probably both are needed in their respective lessons, but can be coordinated and linked to each other.

The other option is to have all practical tips in git-collab.

See also coderefinery/git-intro#76 and coderefinery/git-intro#164, the second needs re-doing I guess.

I have a feeling there are more practical tips scattered around that can be considered...

Show git rebase command in the branch model figure

It might also be useful to show the rebasing command for feature branches before the merge to master.

Write-protect exercise repos

Once they are prepared.

They will still be modifiable via PRs but just to prevent accidental pushes.

make repos transitions more discoverable / highlight transitions more clearly

Instructor instructions

• ensure the instructor or someone there has access to add collaborators to the CR centralized-workflow-exerciserepo. You can use a fork but people will use the wrong one (unless the instructions are updated) and it will be a big mess!
• People really have to sit next to someone, so that they can see the screens. From the beginning.
• Emphasize use of git graph a lot, just like in git-intro

This issue will be edited.

Collaborative exercise should send PRs from a feature branch

Not from master to master.

include formative assessment questions at the end of teach episode

refer to https://github.com/coderefinery/git-intro/issues/129 for details

Adjust timing

Central repo now takes more time, since we go in detail through PRs but the distributed section will now take a lot less time since many concepts are revisited.

ssh key generation and usage

This seems to be missing. This is probably the best place to put it, not git-intro.

By the way, mac laptops worked the same as linux - ssh-agent was automatically running and you could just ssh-keygen with password and ssh-add and it Just Works. Remind people to run ssh-add next time (unless it automatically adds these days).

add an instructor instruction on how to quickly rewind remote repo if someone pushes prematurely

because the centralized-workflow-exercise depends on no one pushing too early. The shortest way to correct this should be documented so that any instructor can quickly do it

Discuss WIP pull requests