#51

I made a pull request for the monome/dust repo. Here’s my workflow on a Norns and my computer.

  • Fork repo into my personal account
  • Clone fork onto my computer
  • Create branch based on master for a new thing, named after new thing
  • Add upstream as a new origin to stay in sync with master
  • change the repo on the Norns to track my fork
  • Push Changes to my fork as I’m working, Norns can stay in sync
  • Edits made through Maiden (the Norns IDE) get diffs on device

When I got to a place where my fork + branch is ready, make a PR using Github’s interface. It assumes reasonable defaults and even displays a green button to make a PR.

I think it’s good etiquette to write pull requests with as much information as possible because reading diffs is a special skill. Describe the new features. Don’t describe anything not in the changes, even if the feature in mind is obvious. Future PRs can cover that.

update: another thing I forgot…delete branches when they are merged into master. If you want to do a new thing, even if it’s for the same kind of thing, make a new branch with a new name about only that new thing.

I’m borrowing these conventions from my professional work as a software developer, though with niche software like Monome the rules are more flexible.

5 Likes
#52

This might be useful to some: github released a training platform to learn how to use git/github.

#53

Along with the other replies here, there is also the question of force pushing (a.k.a. history rewriting) and the surrounding etiquette.

While there are no hard and fast rules, I’ve found that in circumstances where a branch is seen as being your own private branch (that just so happens to be in public on GitHub) then force pushing is fine, and even required when tidying up work prior to a PR being accepted.

Whereas in branches that are seen as collaborative and public then force pushing is a no-no.

For most projects this usually means that branches on the main repo are never force pushed to, but that it’s okay to do it on your own forks.

3 Likes
#54

OK, so as requested, a short github intro:

Let me know if (a) it’s helpful, (b) it’s not. If (b), then let me know what’s not clear, and I’ll try to see if I can clarify. Another option I might consider is doing a tutorial session over skype which might shorten the feedback loop. I’ve disabled comments to keep that thread here, and the video isn’t publicly listed.

12 Likes
Crow & end-user documentation
#55

LEGEND!!! Thank you so much. Will be digging in tonight.

1 Like
#56

Thanks for the lesson!

Did I understand it right, that you also need a github software on your computer to do all those things you did in the black text window with the git commands? Like downloading a clone of the repository, making changes to it and pushing it back to your account?

#57

This is a Terminal window. Terminal is an application on MacOS which gives you command line “terminal” to interact with the computer (Old-school UNIX, DOS, etc. use a command line interface).

(not sure what specific application people use for command line on Windows)

No - you can interact with everything from Terminal.

#58

If on Windows, I think you need to install git. It’s not included in the OS.

#59

Okay, I hardly ever use this - and when I don’t know what I am doing but only fulfill orders fron the internet. I think for windows it was the DOS window, which I used a bit back in the nineties. So when you type git clone or push in the terminal your Mac executes that on the GitHub website? Or are those commands part of MacOS?

#60

Ok,so yes, you do need to install either the command line utilities, or a git GUI application. As I mentioned I’m an old school guy so I prefer the command line tools, but the same can be achieved with the GUI.

The commands are run locally on your computer communicating the changes back to the github servers.

Thanks for the feedback, it sounds like I should try to take a step back and explain how to install the tools.

2 Likes
#61
mod action

moved GitHub-specific posts from @GoneCaving, @gnome666, @Leverkusen, @okyeron, @EqualTemperament ; Crow & end-user documentation -> here.

also deleted @okyeron’s call for the mod action to keep things clean.

3 Likes
#62

Ah, okay - thanks! The part you did in the browser was pretty clear to me - I just got confused with the terminal stuff. Knowing that there is something to install clears it up.

On GitHub, is a branch the same as a fork? And where/how can I contribute by reporting bugs. It’s often mentioned to mark them on GitHub, not here on lines. But I could not find it there.

#63

I think of Branches as different variations of the same codebase from the same developer. They can be used to try out new features or ideas, without making them part of the “released” code.

Forks are copies of a codebase (which includes branches) - these are made by other people (not the main developer of that project) so they can work with the code, make other branches, etc. etc.

Look for the Issues tab on the github website.

#64

Forks vs branches, well in this context, the way that @okyeron has described it is fair enough. A fork can also be thought of as a server-side clone. These things get a little more complex when you have a team of developers collaborating on adding sets of features to the same codebase, each of whom has access to push changes to the same repository. That’s usually where branches make sense, but that’s really beyond the scope of what we need here.

2 Likes
#65

I just found out that not every repository has an issues tab. That might had confused me.

#66

We use the “GitFlow” model where I work. I use a variant in my own projects as well, minus forking. Like, I don’t fork my own project and then create PR’s against it.

At any rate, the reason I mention Gitflow is because this explanation of the method might be a helpful illustration of how branching and forking works, or can work.

2 Likes
#67

Just wanted to say that I’ve not forgotten about this thread, and I do plan to take another pass at creating a git intro video (possibly also using the GUI tools). It’s just things have been more than a little busy.

2 Likes
#68

This is probably not the most coherent demo, but I recorded a quick session while sharing the Karplus-rings version of awake this morning:

1 Like
#69

@burns_audio I’m writing my reply here, since it’s not something Scrum/Agile specific:

Git Large File Storage might be interesting for you. Here’s a short article about using it for versioning Ableton Live projects.

That being said, I’ve been storing some pretty large files in my private Bitbucket/GitLab repositories, while playing around with some music related machine learning stuff. Worked fine, even without LFS.

1 Like
#71

All well-covered here already, but wanted to link for posterity an annotated shell session of a typical workflow for something like modifying Teletype firmware.

1 Like