Git On My Level: The Basics of Collaborating on Your First Project

You think you are starting to get the basics of Git down until you stop working on your own. It’s a tale as old as time and from one fellow developer to another, you don’t want your first collaborating experience with git to be on the job. There are so many ways to collaborate with others. Networking is a great tool to not only expand your horizons, but to find someone to work on an open source code project with you.

Photo by Annie Spratt on Unsplash

My first experience collaborating was on a team of two for a real life client! This was such nerve wracking experience, but it was also very challenging. It left me really wishing I hadn’t pushed off understanding the fundamentals of collaborating on Git to the last moment. That being said, here’s your chance to dip your toes in!

Teams on Github

Creating teams is a great way to collaborate on code. You can read some of the Github documentation to get a more in depth understanding of how to do this. Once you have an organization created, you are able to cascade permissions to give your teammates admin, read, or write access to any repositories within the organization. You can send and manage notification settings for different actions and customize the experience to notify key people when certain actions are being taken.

This is important because ‘with a lot of power, comes a lot of responsibility.’ Your teammates will now have the power to do some serious damage to the codebase. This is why it’s important to really hone in on these settings for the organization and apply the correct permissions for your teammates. A good rule of thumb is to only add your teammates to the organization and no one unnecessary.

How To Add Teammates

To add teammates to a team you must have owner or team maintainer permissions.

1. Click your profile avatar on the top right corner of the screen. A menu will drop down and you will select “Your Organizations.”
2. You’ll then be able to select the Organization that you are wanting to add a teammate to.
3. Under the organization you will be able to select “Teams” on the menu below the organization’s name.
4. A list of Teams in the organization will appear in the display area below the menu. Select the Team you are trying to add the Teammate to from the list.
5. After navigating to the desired Team, click “Members” on the menu below the Team name.
6. A list of members will appear in the display area below the menu. Click the green button “Add A Member.”
7. You can do either two things at this point. You can add an existing organization member to the Team you have selected in the input box and they will be added immediately or you can send the person an invite to join your organization through email (entering their email address) or entering their GitHub username.
8. A prompt will then pop up asking you to review and approve the repositories that this teammate will have access to.

Clone The Repository to Your Local Computer

The first step to collaborating on code with teammates is to clone the code base to your local machine. Make sure that you are cloning it and not forking it. You want to collaborate, not branch off.

Here is the code that you can enter from the folder you want to clone the repository into, make sure to substitute YOUR-USERNAME/YOUR-REPOSITORY for the relevant information for your project:

$ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY

Collaborating

There are a couple of best practices that are great to follow when collaborating on code with teammates.

1. Formalize and follow naming conventions for branch naming, tagging, and coding. There are many popular naming conventions. Personally I like to keep it simple with this method here.
2. Each member should work on a separate branch for features. Of course there will still be some instances of common files being edited. When this happens you will need to merge the changes back to the master branch. Unfortunately these merges cannot always be automatic and it does take some human intervention to reconcile the changes made by two different authors. The great news is that a lot of modern IDE’s have tools to help with Git merge conflicts. I personally love Visual Studio Code.
3. Rebase your master branch often. It’s best to keep your version of the master branch up to date as much as possible. This forces you deal with merge conflicts along the way, but it’s the best way to deal with them because it really only impacts your feature branch. The code to rebase is shown below:

git checkout master
git pull
git checkout feature-foo  # substitute name of your feature branch
git rebase master # merge conflicts may occur in feature-xyz

These updates help you rewrite your history in your feature branch. It helps your master mimic the most up to date version of the master on the code base. After testing and fixing the merge conflicts, you are ready to merge your feature back into the master branch.

git checkout master
git pull
git merge feature-foo

If someone else pushes changes before you are able to execute the code above, you may have more merge fixes to tackle before you can merge your feature into the master branch.

By taking the rebasing approach, you do rewrite some of the history of the code base. The opposite approach is to never rebase and to only merge commit. This makes it harder to read the history for various features as they are all mixed up and not in a linear fashion. It makes it harder to review down the road.

4. Squash Commits before merging your code. If every feature had 60+ commits, the number of commits could grow unnecessarily large rather quickly with so many people managing features simultaneously. As a general rule of thumb, only add a 3–5 commits per a feature.

To squash your code run the following:

git rebase -i HEAD~20  # this means you're looking at 20 commits at a time to consider squashing

When this command is executed, a window pops up with a list of commits that you can choose from. Among these choice there is both pick or squash. Picking simply means to retain the commit message. Squashing is the opposite, it means that you will be combining that commit’s message into the previous commit. This is how you edit and clean up your commit history.

After you’ve done some housework, check the git log and make some final edits before merging the feature into the master branch.

git commit --amend

Once you’ve checked everything and have made your final edits, you’ll want to update your feature branch with the new commit history since you’ve edited it.

git push -f

5. Using tags is also a great way to note milestone changes. A tag is a portrait of the branches’ current state. It can be thought of as a named pointer to a specific point in the commit history. An important aspect of coding is documenting and marking important points for quick reflection and further organization. This is an example of how to add a tag:

git tag milestone-id -m "short message saying what this milestone is about"
git push --tags   # don't forget to explicitly push the tag to the remote

Conclusion

The more I looked into collaboration, the more I realized I had to learn. A lot of this knowledge is experiential and often times hard learned. Sometimes you have to make mistakes to really understand the reasoning behind recommended practices. After my first project collaborating with another person, I realized I needed to learn more about this topic as we had a hard time working together because we both had never done so before. Spending time setting standards, naming conventions, rules, and best practices is necessary to eliminate further complications down the road.

You can view an overview of our project here.

Sarah Mendez is a student in the Digital Media program at Utah Valley University, Orem Utah, studying Web & App Development. The following article relates to Web Development in the DGM221R Course and is representative of the skills learned.