Explaining common GitHub workflows

[egyptiankarim]

@DDELS a couple of things that might be interesting to research:

• What's a fork on GitHub?
• How about an issue?
• In what ways are those things related to pull requests?
• How do forks, issues, and pull requests all fit together?

Let's tag @ericahhs into this conversation to follow along.

[egyptiankarim]

Hey hey! @DDELS need any pointers on where to dig up some of this information? I might recommend Understanding the GitHub flow.

[DDELS]

Hey @egyptiankarim sorry it took so long for me to respond,

• A Fork is when you copy a repository to use at your own free will and it doesn't affect the original project.

• Pull requests are a way to let others explain their way of thinking about an idea for the project or let people have a chance to submit changes with reasoning

• Issues are a way to provide suggestions for the project from other people's point of view

• All of of these fit together by providing a way for people to be able to help each other out on a project. And also, it provides a perspective on the project

[egyptiankarim]

@DDELS you've got it! What are some of the things that might happen if multiple people submit pull requests that impact the same code? What are some of the strategies we might employ to avoid such conflicts?

[DDELS]

Hey @egyptiankarim:

• If multiple people submit pull requests that have a impact on the same code, I believe that it will prevent any new pull requests from being submitted. Any new commits will be added to the first pull request.
• Some strategies to use to avoid such issues would be to form a different branch, then decide and review each request before deciding to merge.

[egyptiankarim]

If multiple people submit pull requests that have a impact on the same code, I believe that it will prevent any new pull requests from being submitted. Any new commits will be added to the first pull request.

Not quite. In situations where code is overlapping, the person managing pull requests for the repository has to sort out the conflicts before the code can be merged in.

Some strategies to use to avoid such issues would be to form a different branch, then decide and review each request before deciding to merge.

This is a useful strategy for sure. Another useful thing to do is to spend time organizing the code for a project so that it's grouped logically and in a way that'll support multiple people working on it at the same time without too much concern over people creating merge conflicts.

Excellent! I think we can close out this issue and move onto something else!

[DDELS]

Before we close this issue I had a quick question first, What is the purpose of the security tab? @egyptiankarim @ericahhs

[egyptiankarim]

What is the purpose of the security tab?

Great question! The Security tab is where GitHub communicates potential vulnerabilities in the dependencies for code in any given repository.

Think about it this way: Many software frameworks will carry a manifest file that points all the little bits of a code a larger project relies on (e.g., the Gemfile that comes along with a Jekyll blog, and similarly with a Ruby on Rails project). As those dependencies, which are often times complex software projects of their own, are shown to be vulnerable in some sort of way, it's important to let the people using those vulnerable bits of code to update their stuff or otherwise mitigate the associated risk. GitHub does this via the Security tab.

I currently have a few projects I'm working on that are still not updated to account for some vulnerable dependencies and I can show you what the tab looks like when it has some content in it the next time we tag up. For now, though, if you want more information you can read GitHub's blog post about this functionality: About security alerts for vulnerable dependencies