Last week I began my third week of Flatiron School, a coding bootcamp preparing me to be a full-stack developer in fifteen weeks. Every three weeks we begin a new module which means last week was project week.
This being the first time the majority of us had worked on a collaborative coding project in person, we all experienced some beginner mistakes. What seemed to cause the initial wave of headaches was making sure everyone was properly syncing their work using Github.
What we had been accustomed to was forking and cloning repositories from Github via Learn and working on them individually. When getting all of the green lights lit on the lab, a simple “learn submit” command sends it up and back to Learn. Who knew we’d have to consider what other people were working on? Should I always be working on the master branch? What is a merge conflict? I’d like to take a moment to give a refresher on good Github habits.
In the scenario of our projects, the best practice is for one member of the team to create the repository and add the other members as collaborators. In the repo, go to settings (has a gear icon next to it), and then collaborators. You will need to enter your password, then enter the username(s) of any other collaborators on the project.
Whether you are being added as a collaborator or starting to work on a project that has already been worked on, do not immediately fork and clone the repository as we have done in throughout our coursework. Forking is like maintaining a completely separate copy which for our labs this is the right way to work, though in a project setting you’re asking for complications. Simply clone the repository to your computer and use your terminal to change into that directory.
Begin first by determining what branch you are currently on.
This will inform you whether or not you are on the master branch. To avoid inadvertently changing the master branch, create a new one to work from which you will later merge with the master.
git checkout -b kevy-wevys-new-branch
If at any point you realize you have not switched to a different branch and you are working off of the master branch, simply check the status (git status) and run the checkout command (git checkout -b my-new-branch).
There is nothing to worry about because all of your changes follow you until you make a commit.
Before committing and pushing your code up to Github, it’s necessary to check to see if any changes have been made to the master branch before you merge it with your branch. You want to be sure that when you push your code you include both the changes you made plus the rest of the up to date code.
Switch back to the master branch
git checkout master
Get any changes that have been made to the master branch
Now switch back to the branch you had previously been working on.
git checkout kevy-wevys-new-branch
When you have switched to the other branch, try to see if you can merge the two branches together.
git merge master
If there are any discrepancies, your text editor will prompt you to decide on which lines of code to change and which to delete.
Once you’ve made changes and you’d like to commit, check the status of the repository.
You will see which files have been modified. Add any changed files to be committed.
git add .
Now stage a commit with a comment so anyone viewing the repository can understand what changes have been made.
git commit -m “add thing to thing”
And lastly, push the changes up to github:
Hopefully this clears up some confusion and the next time you partner up for a project, Github version control will be the least of your worries!