1. Macaualy2 Workshop Berkeley 2017
GitHub
Macaualy2 Workshop Berkeley 2017

2. Got Git? Open a terminal ataylor@ ~ which git /usr/bin/git If not:
Make a new account and your login to
Install git on your computer.

3. Steps For Starting
Existing Package? Fork Macaulay2/M2 Choose your own Repo, make changes there and then either push to the workshop repo, or put up a PR to the main repo. More on this in a moment.
New Package? Clone our repo (more in a moment), and just get going, then push it to our repo. Easy!

4. Clone our “Master” Repository
Click on Clone or Download --- choose HTTPS (recommended and necessary unless you have ssh keys setup)
Go to a folder where you want this project to live and type:
git clone

5. What you have Now

6. New Package
Create your package, add, commit and push it (details in a moment) and now you can all work on it in the Workshop Repo.
Consider Branching!

7. Existing Package You have options:
git clone the copy the package of interest into your clone of the workshop repo, push it there and then branch.
Fork using the fork button in the top right corner. You can then work there on your own, and put up a PR request to the main repo when you are ready, or put items in the workshop repo so others can see/work with it.
DO NOT COMMIT TO MASTER FOR

8. Git Workflow: New work in Workshop Repo
New or old folder in our new Workshop repo:
You moved it locally, but everyone wants to see it and branch (see next discussion).
You have new work you want to commit to the main repo.
Git add my_filename
Git commit –m “I have a great new package”
Git push origin master (make sure you are in the Workshop Repo AND that this is only to create the code you want to work on)

9. Git Workflow: Branches
We recommend each person working on a project makes a branch (regardless of forking or new projects):
git checkout –b branch-name
git push origin branch-name
You will now see that you are on this branch. And it exists in the remote repository so others can now check it out. You could even do this and fork into it, many options here.
git fetch
git checkout branch -name

10. Removing a Branch
git push origin --delete branch_name (deletes remote branch) git branch -d branch_name (deletes local branch) This assumes you have no uncommited changes in your local branch. Use with extreme caution!!

11. Git Workflow: Branches
I personally find the git workflow easier to manage if I have a branch where I’m the only one mucking about. I recommend, once your group has a bare minimum of a package in the Workshop Repo (e.g. rees- algebras) that you make your own feature branch (e.g. amelia-rees- algebras, or adding-new-types, or…) This is not required, just recommended and then you can do a PR with your team and merge to the group repo so others have easy access when you are ready. This keeps the merging easier.

12. Git Workflow: Making Changes Redeux
Make some changes in a file.
git add filename
git commit –m “useful message about changes.”
git push origin branch-name
This works well when you are the only person working on a branch, which is the recommend flow.

13. Git Workflow: Merging
Suppose you do all that you needed to for your new feature. Now you want to put that code in the group branch for everyone to use. Please do a Pull-Request.
You can create a new PR online.
Give a message useful to your reviewers about what you changed and assign one or two folks from your group to review. GitHub will tell you if you have conflicts. If you do, try merging the branch above into your branch and resolve the conflicts. More on this on the wiki and when it happens.
Any and all changes to Master should go through a Pull Request and be approved before merging!

14. Git Workflow: Merging
Someone made changes in their branch, merged them into the group branch and you want them in your branch
git checkout your-branch
git merge group-branch
When ready to merge your branch into the group branch, you can use the online tools that are part of your PR or do
git checkout master
git merge branch_name
git push origin master