GitHub is an invaluable resource for developers. It offers version control, a place to share your code, and, most importantly, a way to collaborate. However, managing that collaboration can be tough. You will inevitably be faced with many questions:
Should I fork or clone the repo?
Who has access to push?
Should I make a new branch?
What’s the difference between pulling and fetching?
I’ve created a step-by-step guide to help you answer these questions. Let's get started!
1. Make a new GitHub repository
You want a central place where all group members can contribute, so one member should make a new repo. Then:
Add a “ReadMe.md” and a “.gitignore” file for node – You will need the ReadMe file for an introduction to your app and the gitignore file will prevent things like node_modules from being uploaded to GitHub and taking up space
Clone the repository to your local machine – This creates a local copy on your machine and connects it to your GitHub account
Create basic folder structure and push to GitHub – This will prevent each collaborator from having to remake each folder and hopefully decrease errors
git add . git commit -m “first commit” git push
2. Add other members
The person who set up the new repo can then give the other members push access by adding them as collaborators. To do this:
Go to settings
Go to “Collaborators” tab
Search for group members
Each member will get an email invitation that they then need to accept.
3. Clone the repo
Every other member of your group should then clone the repository to their local machine.
At this point, everyone should have a copy of the basic folder structure on their machine. Note that you will not have a repository on your GitHub account, but you can fork it when the project is finished in order to share links to it.
Your commits will be accounted for in your tracker
4. Create a branch protection rule
You don't want to push code that hasn't been reviewed to the master branch, so the admin should create a branch protection rule. To do this:
Go to the “Settings” tab of your repository
Click on the “Branches” tab from the side table
Click “Add Rule”
Type “master” in branch name pattern and select:
“Require pull request reviews before merging”
“Include administrators” – With this setting, the owner of the repo also has to get approval before merging with master
Click the “Create” button
With these settings, at least one person must review code before it can be merged into the master branch.
5. Create a new branch for each new feature
From this point, each member of the group will create a new branch for any feature they are adding to the project. Do this by entering either of these two options:
git checkout -b branchName – This creates the branch and checks it out
git checkout branchName – This checks out the branch
Be sure to always check which branch you are on using “git status” before you begin working!
6. Merge your branch
Once your branch is ready to be merged to master, follow these steps.
While in your branch you will
git add . git commit -m “message” git push origin <branch name> – This creates the branch remotely and pushes to that branch on GitHub
Go to GitHub and create a new pull request
You can compare your branch to any other branch, but you will most likely be comparing to master
You can assign a specific person or not
You will not be able to approve your own pull request
Once someone reviews the pull request. they will resolve any issues or conflicts that come up and approve the pull request to be merged into the master
7. Start each day off right
Begin every day by pulling or fetching from the master to your local master.
Pulling will automatically try to merge the recent commits from master and throw errors if there are any conflicts
Fetching will gather the most recent commits in a branch which you can then view and decide to merge or not
Once you have all the most recent updates on your master you can then merge those changes into your branch:
git checkout <branch you want to update> git merge <branch name you’re merging from>
- You may have to handle merge conflicts at this point. Note that files with merge conflicts are usually a different color in the sidebar.
Create a new branch
git checkout -b <new branch name>
- This branch will start off with a copy of the branch you were on.
Need GitHub help?
Outside of this series of steps, you will run into other issues which can be handled case by case. Here are some helpful resources for those cases.
This post was written by alumna Katy Gibson, who graduated from our Houston campus. Check out her posts on Medium.