rprimus / github-move

Notes and code (for exercises) for Paul Graham's - Ansi Common Lisp

github-move

Notes and code (for exercises) for Paul Graham's - Ansi Common Lisp

This is being used in conjunction with EECS 325 AI Programming.

github-move's Issues

Invite collaborators

Collaborators

Part of what makes working on GitHub so effective is how easy it is to collaborate. If you want to give others the permission to work in your repository, you can add them as collaborators.

Things to watch out for

Whether your repository is public or private, inviting someone as a collaborator will give them push access to your repository. That means that they'll be able to make changes to the code. Depending on whether or not you have protected branches enabled, they may even be able to change the history on the master branch! Before inviting collaborators, make sure they are people you trust with your code.

⌨️ Activity: Inviting Collaborators

1. Ask for the username of the person you're inviting as a collaborator. If they don't have a username yet, they can sign up for GitHub.
2. Click on the Settings tab for this repository.
3. In the left sidebar, click Collaborators & Teams.
4. Under "Collaborators", start typing the collaborator's username.
5. Select the collaborator's username from the drop-down menu.
6. Click Add collaborator.
7. The user will receive an email inviting them to the repository. Once they accept your invitation, they will have collaborator access to your repository.

---

I won't respond to this issue, just close it when you are done!

About your community score

Step 4: Prepare to collaborate

Public repositories on GitHub have a Community score. This score is based on the documentation, and how easy it would be for new users to help out and contribute to your project.

Your community score

Your score is currently 0 and can be seen here.

I've opened up issues for each one of the items that you should take action on, and started a milestone to help you keep track of them.

To continue with best practices for moving to GitHub, close this issue. Don't worry, the milestone will remain open so you can return to it later.

---

Watch below for my next response

🤖 I'm waiting for you to close this issue before moving on.

Planning the move to GitHub

Step 1: Planning the move

You have a few options when moving your project to GitHub. This course will expose you to these options, help you choose a path, and then guide you down the path you have selected.

I know some people like to get straight to the point while others like more information. For those who like more information, be sure to check out the drop-downs like this one ⬇️

Why move to GitHub?

---

Why move to GitHub?

You may be wondering what this GitHub thing is all about and why you should use it. If this sounds like you, here are a few reasons to make GitHub your project's new home:

• Version control — Everything on GitHub is stored in Git, the best version control system around. Version control allows you to experiment and make mistakes in code without messing up your final product.
• Keep your code in one place — Whether you work on multiple computers or just want to get some important projects off your computer, GitHub is the perfect place to store your projects online.
• Collaboration — Once your code is on GitHub, you can invite others to work on your code with you, share it with the world, or send a link to a friend to help you debug a problem.

---

Where is your project today?

To give you the best information, I need to know a little about your project. In the next activity, you will apply a label to this issue to help me provide the most applicable information to help you move a project to GitHub.

⌨️ Activity: Add a label to this Issue

For this exercise, use the following table to determine which label to apply to this issue.

If your project is ...	Add the label
On your local machine	local
On a different website that includes version control	migration
On another website without version control (e.g. CodePen)	other

1. On the right side of this issue ^📖, look for a section titled Labels
2. Click the ⚙️ gear icon
3. Select the label that describes your project
4. Click the ✖️ x at the top of the label panel when you are finished

For a printable version of the steps in this course, check out the Quick Reference Guide.

---

Watch below for my response

After you have added the label, I will add a new comment to this issue with next steps.

Sometimes I respond too fast for the page to update! If you perform an expected action and don't see a response from me, wait a few seconds and refresh the page for your next steps.

Release your software

Using releases

Why Releases?

Releases are GitHub's way of packaging and providing software to your users. You can think of it as a replacement to using downloads to provide software.

With Releases, you can provide links to binary files, as well as release notes describing your changes.

At their core, Releases are based on Git tags. Tags mark a specific point in the history of your project, so they're a great way to indicate a Release. Releases are ordered by a tag's date in the following way:

If it's an annotated tag, the tag object's date is used.
If it's a lightweight tag, then the commit object's date is used.

⌨️ Activity: Creating a release

1. On GitHub, navigate to the main page of the repository.

2. Under your repository name, click Releases.

3. Click Draft a new release.

4. Type a version number for your release. Versions are based on Git tags. We recommend naming tags that fit within semantic versioning.

5. Select a branch that contains the project you want to release. Usually, you'll want to release against your master branch, unless you're releasing beta software.

6. Type a title and description that describes your release.

   If you'd like to include binary files along with your release, such as compiled programs, drag and drop or select files manually in the binaries box.

   If the release is unstable, select This is a pre-release to notify users that it's not ready for production.

7. If you're ready to publicize your release, click Publish release. Otherwise, click Save draft to work on it later.

You can create releases from the GitHub user interface. Read this detailed documentation when you're ready to implement releases.

---

I won't respond to this issue, just close it when you are done!

Your repository settings

Step 5: Project settings

In your repository, you will see a Settings tab on the right-hand side of the navigation, after Code, Issues, Pull Requests, and other categories. I've opened a milestone to track each of the settings issues.

Project visibility

Repositories can be "owned" by individual user accounts or by organization accounts. If this repository is currently under your own user account but you'd like it to be owned by your organization, don't worry. You can change repository ownership.

Repositories can also be private or public.

A private repository can only be seen by those who are collaborators, administrators, or owners. Permission has to be explicitly granted.

A public repository has code, issues, and pull requests that can be seen by anyone on the internet. Public repositories should always have licenses, so it's clear if others are able to use the project or code in any way. Just because a repository is public doesn't mean that anyone can make changes, though - only collaborators, administrators, or owners can do that.

Add collaborators

If you want to give others permission to edit the code in your repository, you will need to add them as collaborators. In the Settings tab of your repository, find the Collaborators tab on the left navigation. Then, you can invite others to your repository.

Protected branches

Protected branches ensure that collaborators on your repository cannot make irrevocable changes to branches. These branches can also be protected by requiring pull requests to have at least one approved review before they can be merged.

If you want to know more about protected branches, check out this documentation.

Integrations/services

Integrations are tools and services that connect with GitHub to complement and extend your workflow.

Integrations can be GitHub Apps, OAuth Apps, or anything that utilizes GitHub APIs or webhooks. For more information, see "About integrations" in the GitHub Developer documentation.

You can find an integration to install or publish your own integration in GitHub Marketplace and Works with GitHub.

All done?

When you're done, close this issue. I'll open new issues in this repository with your next instructions.

---

Watch below for next steps!

Add a contributing guide

A contributing guide provides important information to those who may be interested in helping you with your project. Without a contributing guide, they might not know what you need help with, how they can get started, or how you like to communicate.

Providing the baseline expectations for a contribution to your project makes it much easier for a new user to contribute to the growth and development of your project. Identifying the processes that you expect to be followed when creating contributions to your project helps reduce the hesitation a new contributor might feel when adding a new contribution because what you are looking for in a contribution is well laid out. The contributing guide is helpful for veteran contributors as well, as it provides a reference point for their review if they are contribting to an area of the project they hadn't previously worked with.

⌨️ Activity: Adding Contributing guidelines

1. Access the Community profile pane

2. Click the Add button on the Contributing row

3. Modify your new file with contributing guidelines for your project, for ideas on what should be included in a contributing guidelines file, read this stellar documentation

4. After editing the CONTRIBUTING.md file, scroll down and click the Commit new file button.

   This is committing your CONTRIBUTING.md file directly to master.

---

I won't respond to this issue, just close it when you are done!

Add an issue or PR template

When you add an issue template and pull request template to your repository, project contributors will automatically see the template's contents in the issue or pull request body. Templates customize and standardize the information you'd like included when contributors open issues. This information can guide contributors to include the information that allows enhancement or bug reports to be reviewed quickly and identify the information that a reviewer would need to succintly review a new pull request.

In Open Source projects, these templates make it very easy for a new contributor to your project to create a bug report, suggest a new enhancement, or potentially contribute a change. By identifying what information the new contributor should provide when creating a new issue or pull request, veteran contributors to the project can easily review and move forward with reported bugs, new enhancements, or contributed pull requests.

⌨️ Activity: Adding Issue and Pull Request template files

1. Access the Community profile pane

2. On the Issue or pull request template row, select the Add drop down and select Issue template or Pull request template

3. Edit the new template file to identify how you want issues or pull requests submitted to your project, for suggestions on what should be included in a template file, read this

4. Afer editing the template file, scroll down and click the Commit new file button

   This is committing your template file directly to master.

Add another template file

---

Add another template file

After using the Community profile pane to create a template file, the option to create the other template file isn't displayed. To create the other template file, perform the following steps:

 - Issue templates are named: `ISSUE_TEMPLATE.md`
 - Pull Request templates are named: `PULL_REQUEST_TEMPLATE.md`

1. On the Code tab of your project, click the Create new file button
2. Enter the name of the template file your project is missing
3. Modify your template file to include the information you want to automatically populate when a user creates an issue or a pull request, for examples of what to include read this
4. Once you have modified your file, click the Commit new file button

> This is committing your template file directly to `master`.

---

---

I won't respond to this issue, just close it when you are done!

Confirm your repository visibility

Private or Public?

Right now, your repository is set to public.

You can change the visibility of a repository to Private ^📖 or Public at any time, but there are some things you should know.

Private Repositories

If your repository is private, then the only people who can see your code are the collaborators ^📖 that you've invited.

Private repositories also aren't free. The price depends on how many collaborators have access to any given repository, but the base price is $7 per month for unlimited private personal repositories.

You might want this repository to be private if it has sensitive information, or depending on the software's license.

Public Repositories

In public repositories, anybody can see your code. All of the millions of open source repositories on GitHub are public, too!

Licenses, code of conduct, other files become even more important when the world can interact with you and your code. There are many benefits to this, but it's also a large responsibility. Keep in mind that once a repository is public and open source, there are certain implications about keeping it public, depending on the license chosen.

It's important to note that public does not equal open source! The license associated with code determines whether or not it is open source.

---

I won't respond to this issue, just close it when you are done!

A few parting words

Nice Work

Congratulations @rprimus, you've completed the core section of this course! 🎉

What went well

Before I say good-bye, I want to recap all the tasks you've accomplished. You:

• Learned what to do with an empty repo on GitHub ✨
• Created a .gitignore and removed bulky binaries
• Used GitHub Importer for the first time or your favorite local tools to push existing code
• Set your code up in a GitHub repository 🎆
• Made some adjustments to make your repository more welcoming to the community

What's Next?

Choose your own adventure! There are some issues already opened in this repository to help you craft this repository's important files, including these:

• Add Documentation
• Release Your Software

There's so much more you can do with GitHub, and you have a solid start. Now...what will you learn next?

Add a README

Your project doesn't have a README.md file. A README.md file is useful for telling other people why your project is useful, what they can do with your project, how they can use it, and more importantly, how they can contribute to your project.

A README is often the first item a visitor will see when visiting your repository. README files typically include information on:

• What the project does
• Why the project is useful
• How users can get started with the project
• Where users can get help with your project
• Who maintains and contributes to the project

⌨️ Activity: Adding a README

1. Access the Community profile pane

2. Click the Add button on the README row.

3. Edit the new README file to describe your projects, using the bullet points listed above ☝️

4. After editing the README file, scroll down and click the Commit new file button.

   This is committing your README file directly to master. Normally, you would create a pull request when making changes to your projects, but README files are very important on GitHub.

---

I won't respond to this issue, just close it when you are done!

Publishing your local project

Step 3: Make the move

Having a project already stored locally enables you to move it to GitHub rather quickly. The following activity provides instructions to move your local project to GitHub using various tools. Select the tool you are most comfortable with and get importing 😄.

⌨️ Activity: Moving your local project

1. In the Code tab of this repository, copy the URL shown under Quick Setup.
2. Follow the instructions below based on what tool you'd like to use locally.

Using the command line

---

Using the command line

1. In your command line, navigate to your project directory. Type git init to initialize the directory as a Git repository.
2. Type git remote add origin https://github.com/rprimus/github-move.git
3. Type git add .
4. Type git commit -m "initializing repository"
5. Type git push -u origin master to push the files you have locally to the remote on GitHub. (You may be asked to log in.)

---

Using GitHub Desktop

---

Using GitHub Desktop

1. In GitHub Desktop, add a local repository by clicking File > Add a Local Repository, and then navigating to your local repository.
2. Create your first commit by typing a summary commit message in the field provided and clicking Commit to master
3. Add the remote by clicking Repository > Repository Settings... and pasting the URL from your repository on GitHub into the "Primary remote repository (origin)" field. Click Save.
4. Click Publish in the top right corner to push your repository to GitHub.

---

Using Visual Studio Code

---

Using Visual Studio Code

1. In Visual Studio Code, open the folder for your project.
2. Click the icon on the left for Source Control.
3. On the top of the Source Control panel, click the Git icon.
4. If the files you see match the repository you want to create, click Initialize Repository.
5. Next to the word CHANGES, click the symbol of the plus sign to stage all of the changes.
   • This is part of the two stage commit. You can use this staging function to create meaningful commits throughout the development process.
6. In the box in the Source Control panel, type a commit message. Something like "initial commit - moving project" could work.
7. Click the checkmark at the top of the Source Control panel.
8. Open the integrated terminal found under View > Integrated Terminal.
9. In your command line, type git remote add origin https://github.com/rprimus/github-move.git
10. In the Source Control Panel, click the expandable three dots that open a menu of options.
11. When asked if you'd like to publish the branch, click Okay.

---

Using Atom

---

Using Atom

1. In Atom, open the folder for your project
2. At the top of your screen, click Packages. Select GitHub, and then toggle the Git Tab from the drop-down menu.
3. Select Create Repository within the Git tab on the right-hand size of your screen.
4. Select Init to accept the default prompt of the pop up window
5. In the Git tab, you can see that your files are ready for staging. It should be accounted for, but double check to make sure that none of your binaries or files that you listed in the .gitignore are listed in this dialog menu.
   - If they are, double check your .gitignore file to make sure they're included or remove them from your directory.
6. Select Stage All
   - This is part of the two stage commit. You can use this staging function to create meaningful commits throughout the development process.
7. In the box at the bottom of the Git panel, type a commit message. Something like "initial commit - moving project" could work.
8. Select Commit
9. Close Atom
10. In your command line, navigate to your project directory.
11. Type git remote add origin https://github.com/rprimus/github-move.git
12. Return to Atom, and select the Up/Down arrow icon at the bottom of your Git Tab
13. Click Push, above the noted dialog.
14. Return to your repository, and note a successful push by finding your files on GitHub's code tab.

---

Using Eclipse

---

Using Eclipse

1. In Eclipse, from the Eclipse Marketplace, install the eGit GitHub plugin.
2. Open your existing project.
3. Display the Git Repositories window by selecting Window > Show View > Other > Git > Git Repositories.
4. Click the Create a Git Repository button on the Git Repositories pane.
5. Make changes to your project and create a commit.
6. Push the master branch.
7. When asked for a remote, paste the URL you copied earlier.
8. Click next, and enter the branch name.

---

---

Watch below for my response

🤖 Once you push your project to GitHub, I'll provide the next steps in your journey.

Set up protected branches

Protected Branches

When you look in the Settings tab of your repository, you'll see Branches on the left side. Here, you can choose to enable something called Protected Branches.

What are Protected Branches?

Protected branches ensure that collaborators on your repository cannot make irrevocable changes to branches. These branches can also be protected by requiring pull requests to have at least one approved review before they can be merged.

You might want to use protected branches if you're working on a team, you have CI tests enabled, or in any case where you want to be sure that the code that gets merged into the master branch meets a certain set of requirements.

If you'd like to enable protected branches, go ahead and do so now, and then close this issue.

Not sure what settings to enable? Check out this article that goes into more detail about the settings for protected branches.

---

I won't respond to this issue, just close it when you are done!

Add a Code of Conduct

Your repository has no Code of Conduct.

Having a Code of Conduct is really important, especially for public repositories. Instead of re-writing the wheel, I want to point you to some of the best instructions around.

⌨️ Activity: Add a Code of Conduct

1. Access the Community profile pane

2. Click the Add button on the Code of Conduct row.

3. Select a Code of Conduct from the left side of the screen and review the Code of Conduct you selected.

4. Add information to the displayed fields then click the Review and submit button.

5. With your file displayed, scroll down and click the Commit new file button.

   This is adding your new file to a new branch that GitHub created for you.

6. With the Open a pull request screen displayed, click the Create pull request button.

7. If you are ready to merge (or apply) your file to the project click the Merge pull request button. If you want to share this change to your repository with someone, share the URL for this pull request or @ mention them in the comment section.

8. After clicking Merge pull request, click Confirm merge.

9. Once the merge is complete (it should happen really quickly) delete your branch by clicking Delete branch.

---

I won't respond to this issue, just close it when you are done!

Add a license

Your repository is public but there's no License. Licenses are vital in public repositories, because they set the rules for how others are allowed to use, change, and contribute to your project.

⌨️ Activity: Adding a License

1. Access the Community profile pane

2. Click the Add button on the License row.

3. Select a license from the left side of the screen and review the license you selected.

4. Add information to the displayed fields and click the Review and submit button.

5. With your file displayed, scroll down and click the Propose new file button.

   This is adding your new file to a new branch that GitHub created for you.

6. With the Open a pull request screen displayed, click the Create pull request button.

7. If you are ready to merge (or apply) your file to the project click the Merge pull request button. If you want to share this change to your repository with someone, share the URL for this pull request or @ mention them in the comment section.

8. After clicking Merge pull request, click Confirm merge.

9. Once the merge is complete (it should happen really quickly) delete your branch by clicking Delete branch.

---

I won't respond to this issue, just close it when you are done!

Preparing the project for Git

Step 2: Prepare the project

Working with Binary files

In general, there are two types of files: text files and binary files.

Text files, like most code files, are easily tracked with Git ^📖 and are very lightweight.

However, binary files like spreadsheets, presentations with slides, and videos don't work well with Git. If your repository already has some of these files, it's best to have a plan in place before you enable Git version control.

You could choose to remove the binary files, or use another tool like git-lfs (Git Large File Storage). We won't get into detail on how to set up git-lfs in this course, but we will talk about .gitignore files next, which are key to protecting your code from becoming bloated with binaries.

Add a .gitignore

As mentioned above, there are files you won't want to store in Git. In addition to avoiding binaries, you will also want to keep build artifacts out of your version controlled code. As we convert your project to a Git repository, it should only include the source code necessary to build or compile your project.

To do this, you will create a file in your current project named .gitignore. When you switch over, Git will use the .gitignore to determine which files and directories should not be tracked under version control.

A .gitignore file should be committed into your repository in order to share the ignore rules with any other users that interact with the repository.

Since the files to be ignored are dependent on the language you are using, the open source community has contributed some great templates for .gitignore files in the github/gitignore repository.

⌨️ Activity: Prepare your repository

1. Remove any binary files from your repository.
2. In your local environment, create a .gitignore file. Use a template or create your own.

When you are finished, close this issue. I will open a new issue with the next steps. 🎉

---

Watch below for my response

🤖 I'm waiting for you to close this issue before moving on.

Add a repository description

Your repository has no description! Let's add one.

⌨️ Activity: Adding a project description

1. Access the Community profile pane
2. Click the Add button on the Description row.
3. Enter a description for your project in the Description field.
4. (Optional) If you have a website related to your project you can add it in the Website field.
5. Click the Save button.

---

I won't respond to this issue, just close it when you are done!

Add documentation

Creating documentation

GitHub Pages is a powerful tool that creates a static web page for GitHub repositories. GitHub Pages looks for an index.html or index.md file, but will also use a README.md file as the home page for the web page.

You can choose to have GitHub Pages look at the master branch, the gh-pages branch, or the /docs directory of the master branch.

⌨️ Activity: Enabling GitHub Pages for Documentation

1. Create a /docs/index.html file in this repository.
2. In the Settings tab of this repository, scroll to "GitHub Pages". Enable GitHub Pages with a source as /docs.
3. Using static web technologies, you can create documentation in this file that will be automatically served as a free web page.

---

I won't respond to this issue, just close it when you are done!

Set up integrations

Set up Integrations

There are many services that integrate with GitHub. These integrations provide specialized solutions to take your software and workflow to the next level.

You can search for and browse integrations in GitHub's Marketplace, and on this "Works with" site.

You might have some integrations set up to sync with your project on another platform, or maybe you are integrating manually. Go ahead and connect these now, and then close this issue when you're done.

---

I won't respond to this issue, just close it when you are done!