In Phase 1 of our Flatiron SE Bootcamp, we learned the fundamentals of JavaScript, HTML, and CSS. Our Phase 1 Project was centered around creating a Single Page Application. We were assigned partners, and one of the more challenging pieces of designing our first website was navigating GitHub. Before I started at Flatiron, I had never used GitHub before, and it can seem very overwhelming!

It was scary to “push” and “pull” at first, not knowing whether our coding we had slaved over would be saved or disappear in an instant. Eventually, we developed a rhythm and learned the importance of correctly navigating GitHub. Here is a step-by-step process of setting up a GitHub repository for a group project (this demonstration shows how to set up the remote repository first, however, you are able to set up a locally to begin with as well).

1. Create a new repository on GitHub. Make sure to add a unique and descriptive name, a short blurb about what this repository is for, set to private vs. public depending on your project requirements, and decide whether or not to add a README file at this point (you can add later as well).

2. Following the instructions and copy and paste the commands into your terminal. For this option, I chose to have them help set up a totally new repository on the command line. If you already have one setup, you can also choose one of the other options. This step automatically sets up a “main” branch for your repository as well as a README.md file. The README is to give information and instructions for people viewing and using your code.

The highlighted option is the most helpful for beginners. This initializes the repo, makes your first “commit” and sets up your “main” branch.

Copy and Paste the commands into your terminal. Everything preceding “Reinitialized…” is straight from GitHub.

3. You now have a local and remote repository set up! Next, add some edits to your code file, and push the changes up to the “main” branch. It helps to be descriptive with your commit messages so you know what edits were made.

These commands will be your most commonly used throughout your project process. The “git add . ” adds changes from all files you made changes in. You can also specify a file such as “git add index.html” if you want to only add the changes you made in your html file.

git add .
git commit -m "insert description of commit here"
git push

4. Both you and your teammates now need to set up your own branches. It is important to make sure you are always in your own branch when making edits to your coding files. Editing the main branch can lead to pull issues and conflicts within your coding. Once you create your branch with the command “git checkout -B <your branch name here>”, you need to create the remote repository that will be linked to it. The command for this is “git push — set-upstream origin <new branch here>”.

You need to type out “git checkout -B” then enter the name of what you want your branch to be called. After you create the branch in this step, you can then use the command “git checkout <enter your branch here>” without the -B (this is just for setup).

This is linking your new local branch to a remote branch on GitHub.

5. You now have the main branch and your own branch for working on. You and your partners have been coding all day and now it’s time to go home. How do you make sure you all have the correct edits before you leave? Choose one teammate to go first, and follow these next steps carefully!

Get Jensen Lawless’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

6. User1 will follow these steps:

• Push your changes to your own branch. Review the steps here:

git add .
git commit -m "final edits tuesday afternoon anna"
git push

• Checkout into the main branch so you are now in “main”.
• Merge “main” branch with your personal branch.
• You should still be in the “main” branch and you should then push the main branch up to Github. These last few steps look like this:

In this example, the “testing-branch” is User1s personal branch. After you push to your branch, checkout into the main branch, merge the main branch with yours, and push!

7. User2 is up! Once User1 has merged their edits with the main branch and pushed the main branch back up to Github, time for User2.

• User2 should make sure all their edits are saved and follow the same steps to add, commit, and push to their own branch.
• Then, User2 wants to pull the main branch down to their local repository. This is a simple:

git checkout main
git pull

• Usually there will be conflicts to resolve. User2 will have to go in their VS Code or whichever editor you are using and resolve each conflict. Usually this will be if the code they previously had in their “main” branch was overwritten or changed by User1. Be sure to note in your editor the difference between the “incoming changes” and “current changes” and accept the proper ones. This process can be confusing, so go slowly and carefully accept the newer changes you want.
• User2 then goes through a similar process of merging their branch.

User2 added, committed, and pushed their changes to their remote branch. Then they “checkout” to the “main” branch, pulled it down from GitHub (this is the “main” version User1 just pushed up). They then merge with their branch (make sure you are in “main” branch,) then “git merge <User2 branch here>. Then push!

8. Now, the “main” branch on GitHub is updated with both Users edits. User1 can now go into GitHub and “pull” the “main” branch one final time, and this will have both users edits updated in the main branch. Make sure to then merge your branch with the main branch and switch into your branch to make edits! This is a simple:

git checkout main
git pull
git checkout testing-branch
git merge main

9. Hurray!! Both users have now merged their edits with the main branch. As a final check, make sure your branch is merged and updated with the main branch and make sure you start your next round of edits in your branch. You can always check which branch you are in by typing “git branch” in your command line.

And that is it! What once seemed a little overwhelming to me is now second nature, much like the rest of my first Phase at Flatiron. At first, I did not understand the importance of correctly using GitHub in our projects. Why couldn’t we use the Live Share feature on VSCode? Or copy and paste each others edits? Or just code on one computer screen?

Following a process of keeping clean, separate branches helps users keep track of the changes they make and allows partners to work on separate tasks. This can save time and mental energy for all parties involved. You can also write descriptive commit messages to track progress in certain areas, and quickly find the correct version of code you want to use if something goes wrong later on.

And that is it! What once seemed a little overwhelming to me is now second nature, much like the rest of my first Phase at Flatiron.