Git & GitHub Project Setup Overview in Different Cases
As explained, depending on your role in the project, the approach for the Git & GitHub project setup is different. On this page, we'll explain the key steps of Git & GitHub project setup for each case.
Case 1. Project initiator (owner of the Remote Repository)
In this case, you launch a new Git project from your local computer by initiating a Local Repository yourself. As a project initiator, you also need to set up a Remote Repository for the project to share project documents with your project members. There are four key steps until the project documents are ready to be shared on GitHub.
Step 1. Create a Git Local Repository
As a project initiator, the first thing you need to do is to initiate a Local Repository for the project. git init is the command to create a new Local Repository.
Step 2. Develop code and commit it to the Git Local Repository
Until you start to store or share documents through Remote Repositories on GitHub, you work on the project with the Git system on your local computer. We'll explain a typical workflow of Git local operations in the next chapters (Chapter 5: Edit & Commit, Chapter 6: Work with Branches). In this chapter, we'll cover this step only briefly.
Step 3. Set up a GitHub Remote Repository
When you want to share your project documents on GitHub, you need to create a Remote Repository on GitHub. Creating a Remote Repository is done through the GitHub web platform.
Step 4. Share project documents in the GitHub Remote Repository
In this step, you prepare to share project documents through the Remote Repository. Before uploading your project documents, you need to establish a link between your Local Repository and your Remote Repository by running the git remote add command. To upload the committed documents, run the git push command. When the documents are successfully uploaded, they are ready to be shared with others. To share the documents, you need to invite your project members to the Remote Repository and give them access to your Remote Repository.
Case 2. Project member (collaborator of the Remote Repository)
In this case, a Remote Repository with project documents is already prepared by the project owner. To join and start the project, you need to follow the two steps below.
Step 1. Get access to the Remote Repository
If there is a Remote Repository of the project you are trying to participate in, what you need to do is get access to the Remote Repository where you can obtain the project documents.
Step 2. Clone the Remote Repository
Once you get access to the Remote Repository, you can start to get project documents by running the git clone command. The git clone command brings the project documents onto your local computer while creating a Local Repository. The command also establishes a link between the Local Repository and the Remote Repository so that you can start to interact with the Remote Repository from the command line on your computer.
Case 3: Non-project member (without collaborator access to the original Remote Repository)
In this case, a Remote Repository with project documents is available on the GitHub platform but you may not have collaborator access to the project. Even though you don't have collaborator access, you can initiate a new project using the code in the repository by creating a replica of the repository. There are two key steps for you to follow.
Step 1. Create a replica of an existing Remote Repository (Fork)
As GitHub is an open platform, you can access many repositories created by someone else. You may want to leverage an existing repository to start your new project. In this case, you need to Fork the existing repository. The fork feature creates a replica of the existing repository under your GitHub account. Once you fork a repository, you'll become the owner of the forked repository.
Step 2. Clone the Remote Repository
As in Case 2, you can bring the project documents to your local computer by running the git clone command.
Note: Even if you have collaborator access to the repository or you are the owner of the repository, you can also execute a fork to use the repository for different objectives.
Case Study
In this section, we'll explain the flow of the project setup with three developer role examples.
Roles in the case study
Developer A: The original initiator of the project
Developer B: A team member (collaborator) supporting Developer A on the project
Developer C: An independent developer who wants to leverage existing codes to launch a new project
The following explanation assumes that all developers already have Git software installed on their computers and they already signed up GitHub account and completed PAT or SSH settings.
Developer A's point of view
The objective of Developer A is to start to collaborate with Developer B for the project. He needs to upload his code to his Remote Repository and share it with Developer B.
- Developer A already has some lines of code under a project directory.
- To record version history, he creates a Git Local Repository under the project directory by running the
git initcommand. - Once the Local Repository is initiated, he commits the latest code by running the
git addandgit commitcommands. - To prepare to share the project document, Developer A creates a Remote Repository under his GitHub account.
- To upload his codes to the Local Repository, he creates a link between the Local Repository and the Remote Repository by running the
git remote addcommand. - Once the Remote Repository and the Local Repository are linked, he can upload his code by running the
git pushcommand. - Finally, he needs to allow Developer B to access his Remote Repository. This operation is done on the GitHub web platform.
Developer B's point of view
The objective of Developer B is to get access to Developer A’s Remote Repository for the project and bring the project directory to her local computer to start the project.
- When Developer A gives Developer B permission to access his Remote Repository, an email is sent by GitHub. What Developer B needs to do first is to accept the invitation.
- Next, she needs to link the Remote Repository with her Local Repository and bring the project directory to her local computer by running the
git clonecommand. After cloning the repository, she is ready to collaborate with Developer A.
Developer C's point of view
The objective of Developer C is to launch a project based on Developer A’s existing work. Here we assume that Developer A’s Remote Repository is a public repository.
- The first thing Developer C needs to do is to Fork the repository. The fork feature creates a replica of an existing repository; however, it is no longer linked to the original repository. Fork operation is done through the GitHub web platform. After he creates a new Remote Repository by fork, the new repository is owned by him and he can freely edit the code in his repository.
- To edit the code, he needs to bring the project directory to his local computer by running the
git clonecommand.
Practice Setting
In this course, we’ll use the three GitHub accounts below to demonstrate practice examples so that you can clearly understand different roles.
You can also learn this topic offline. Click 
.