Collaborating With Github Part 1

In my last blog, I talked about pair programming and the benefits of putting it into practice. Today I want to talk to you about a resource that can help you efficiently collaborate with your teammates/coworkers.

During my time at Flatiron School SEI Bootcamp, we collaborated on multiple projects, each of which came with its own hurdles. The main being that we all did not really know how to use GitHub and Git to collaborate. Before diving into how to use GitHub to collaborate, we need to understand what this resource is and what role Git plays. So what is GitHub and what is Git?

What is GitHub?

GitHub is a web-based Git repository hosting service, which offers all of the distributed revision control and source code management functionality of Git. GitHub is a graphical user interphase maintained by Microsoft and was launched back in 2008.

What is Git?

In the simplest way, Git is a software command line tool that is installed locally on the system, it focuses on version control and helps with managing source code history and code sharing. It is maintained by Linux and it was released in 2005. Git is designed to help with coordinating work among programmers, it can also be used to track your changes in any set of files. Its goal is to help with speed, data integrity, and support for distributed non-linear workflows. If you want to learn more about Git visit this site for more git documentation.

Git, however, does not have a user management feature and this is where GitHub comes in. Git is the tool, and GitHub is the service for projects that use Git.

How do GitHub and Git help us with collaboration?

Let’s first talk basics for using GitHub to collaborate, this was explained well by Jonathan Mines. I recommend you read his blog before proceeding.

Okay so you read his blog and now you know some basics about collaborating with GitHub. So what’s next? Great question. Knowing the basics is important but there are a few more things that I think you should know when collaborating with your team using GitHub. There is so much to learn and cover that this will be a multi-part blog. In this blog, we will discuss what follows after the basics when working on a project Solo.

Basic solo Git and Github use.

You are here to learn about how to collaborate with a team, but you see that this title says “solo” usage. The reason for this is that in order to collaborate in a team it is imperative that you are able to use these tools on your solo projects. Here are the concepts that you need to understand for your solo projects and their explanations.

1. Understand the difference between GitHub and Git.

Easy, we defined these two up top. Take a moment to explain to yourself what you remember about the differences. It is totally okay if you need to re-read the descriptions above or see the image below.

2. Understand what a commit is and how to commit to the main branch.

Commit as a noun is a single point in the git history. The entire history of a project is represented as a set of interrelated commits. This is often used by git in the same way. When you are ready to commit your repository snapshot you will need to use this command with a descriptive but short message. See the example below.

$ git commit -m “Implemented user login and logout features 
w/authentication and authorization capabilities”

3. Understand what is the staging phase.

A staging step in git allows you to continue making changes in your working directory until you decide you want to interact with version control, which allows you to record the changes you have made in small commits. A good example of this would be, let us say you have made changes to two files one is for the purpose of a login feature on the front end. The next change you make is adding albums and songs to the seeds.rb file in the backend. A good way to stage these two changes is by doing the following:

$ git add client/src/components/login.js
$ git commit -m "Implemented user login and logout features 
w/authentication and authorization capabilities"

$ git add app/db/migrate/seeds.rb
$ git commit -m "added more Albums and songs to seeds file"

Notice that we separated the staging and committing in this example because we want to easily customize what goes into our commits.

4. Understand what a branch is a how it is helpful/useful.

A branch in GitHub is essentially a unique set of code changes a web developer has created with a unique name. You can have one or more branches in any given project, remember not to mess with the main branch. Instead make branches that are created from the main branch to experiment, and make edits, changes, and additions before eventually rolling back into the main branch. This allows your team to review, approve and merge code that works. Never merge anything into the main branch that has not been tested, or that can break the build. The stability of the main branch allows any new team member to create a branch of the main branch. Note that this will prevent any or most merge conflicts, weeping, gray hairs, and panic attacks. Yes, it’s that serious.

Get Ana Zitzow’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

One way to prevent unapproved or unreviewed merges to the main branch is by setting a requirement for all users/contributors to submit a pull request. This is one way the administrators of a branch can enable protections. What is a pull request? A pull request allows you to notify others of the changes you pushed to a branch in a GitHub repository. This allows a discussion and review between the collaborators and checks that all the set requirements/expectations are included in the change. This also allows a second pair of eyes on changes that can break the build. After the pull request is approved only then can the changes be merged with the base/main branch. Here you can find information on how to create a pull request.

5. Understand the difference between a remote repository Vs. local repository.

The difference is that a remote repository is one that is hosted on a server to which all the designated collaborators can have access. A local repository is one that resides on the computer of that team member. See the image below.

6. Understand how to use Git remote repositories, and how to push/pull to a remote.

First, let’s talk about what a remote is and why you would want to create one or more. A remote is an endpoint which all of the developers eventually sync up with. The “remote” for a branch is a URL from which your local repo fetches changes. In order to collaborate on a Git project you need to learn how to manage your remote repositories.

A remote repository is a version of your project that is being hosted somewhere on a network or the internet. These remote repositories allow you and your team to push and pull data when work needs to be shared on a project. This is what it would look like in practice.

$ git clone git@github.com:victorzarour/project-phase-4.git

IMPORTANT NOTE: by default, this command sets up your local main branch to 
track the remote main branch on the server you just cloned from. This will 
be important to remember later.

When you clone a new repository, the remote repository name will automatically be set to “origin”, you can confirm that by using the command below. If you add -v to the command this displays the URL of your main repository on GitHub.

$ git remote
origin

$ git remote -v
origin git@github.com:azitzow/music-app.git (fetch)
origin git@github.com:azitzow/music-app.git (push)

If you have not created a remote from where you will be fetching the latest version of the main branch you can create it by using the following command.

$ git remote add <name> <url>

$ git remote add Victor https://github.com/victorzarour/project-phase-4

# to fetch the latest version of the main branch you can type:
$ git pull -r victor main

# you can also use the following commands
$ git fetch victor
$ git merge victor/main

The git fetch command goes to your remote project and pulls down all of the data that you do not have from that remote project. This command will also pull all the references to all the branches of that remote, which you can then merge or inspect.

So now if we check what remotes we have it will look like this:

$ git remote
origin
victor

$ git remote -v
origin git@github.com:azitzow/music-app.git (fetch)
origin git@github.com:azitzow/music-app.git (push)
victor https://github.com/victorzarour/project-phase-4 (fetch)
victor https://github.com/victorzarour/project-phase-4 (push)

Now let us learn how to pull from our remotes. Remember how I mentioned above about when you first clone a repository the command automatically tracks the remote main branch? Great, so now running $ git pull will fetch the data from that server and tries to merge it into the code which you are currently working on.

From git version 2.27 onward, git pull will give a warning if the pull.rebase variable is not set. Git will keep warning you until you set the variable.

If you want the default behavior of git (fast-forward if possible, else create a merge commit): git config --global pull.rebase "false"

If you want to rebase when pulling: git config --global pull.rebase "true"

Okay, so you worked on your project and are at a point where you want to share your work with your team, you will need to push your work upstream. You can do this by simply using the git push <remote> <branch> command. This command works on any repositories that you cloned for which you have writing access. For example:

$ git push origin main

Once you have pushed all of your changes upstream, you can pull any changes made by your teammates by using the git pull command. This performs a merge on the retrieved changes. If you encounter a merge conflict and cannot resolve it or you do not want these changes, you can use the git merge --abort to take your branch back to where it was before you pulled the changes.

$ git pull victor main
# Grabs online updates and merges them with your local work

Take some time to digest this before heading over to part two. Take a look at the git commands below that I recommend you should consider knowing perfectly before moving on to part 2. Once the blog is posted you will see the link here.

$ git init 
# this command initializes a brand new Git repository

$ git clone <repository> 
# creates a local copy of a project that already exists remotely

$ git status 
# shows the status of changes made to untracked, modified, or staged 
files.

$ git add <filename> 
# stages a change in the specified file 

$ git add . 
# stages changes made to all the files 

$ git commit -m "message goes here" 
# saves a snapshot of the history of the current project and completes
 the change-tracking process.

$ git remote add <name> <url> 
# adds a new remote in the directory your repository is stored in

$ git remote set-url 
# this allows you to change the URL of an already existing remote

$ git remote -v 
# shows all of your remotes with their URL 

$ git remote 
# shows just the name of all your remotes

$ git push <repository> <branch> 
# sends your local changes to your online repository

$ git pull <repository> <branch> 
# this is a shortcut for completing both git fetch and git merge in 
one command, make sure that you commit your changes before performing this 
command.

$ git merge 
# merges lines of development together and combines changes made on 
two distinct branches

$ git merge --abort 
# this aborts a merge when you are not able to resolve
or you do not want the retrieved changes

$ git branch 
# this shows the branches being worked on locally

Happy coding!!