Collaborating with Git and GitHub 101

8 min readFeb 26, 2021

In this post, I’m going to look at how to collaborate with the team using Git if you are all beginners. I’ll show how to synchronize with a remote repository, use branches, and make pull requests. And then I’ll give an example of workflow a team may use for working on the project.

This post has the following structure:

Syncing with a Remote Git Repository

git remote
git clone
git fetch
git pull
git push

2. Working with Branches

git branch
git checkout
git merge

3. Making a Pull Request

4. Example

Before we go into the details let define the difference between git vs GitHub:

git is a local VCS software that enables developers to save snapshots of their projects over time. It’s generally best for individual use.
GitHub is a web-based platform that incorporates git’s version control features so they can be used collaboratively. It also includes project and team management features, as well as opportunities for networking and social coding.

Syncing with a Remote Git Repository

Git remote

The git remote command is responsible for creating, viewing, and deleting connections between remote and local repositories.

Hint! Remote connections are more like bookmarks rather than direct links into remote repositories.

Common git remote commands

git remote -v: List the current remotes associated with the local repository including the URL of each remote repository
git remote add [name] [URL]: Create a new connection to a remote repository
git remote remove [name]: Remove the connection to the remote repository

Communicating with a remote Git repo

There are four commands within Git that prompt communication with the remote.

1. Git clone

The git clone command creates a copy of an existing Git repository, including all of the files, branches, and commits. git clone involves cloning the entire repository, and setting its HEAD to the latest commit in the main branch.

Hint! If any changes added to the original repo after you git clone it, they won’t be available to your copy of original repo until you rungit fetch or git pull.

Common git clone commands

git clone username@host:path/to/repository: Create a working copy of a remote repository
git clone /path/to/repository: Create a working copy of a local repository

2. Git fetch

git fetch gives access to the entire branch structure of other repo

The git fetch command downloads commits, files, and refs from a remote repository into your local repo. Fetching is what you do when you want to see what everybody else has been working on.

Hint! git fetch doesn’t integrate any of this new data into your working files. git fetch will never manipulate, destroy, or screw up anything.

Common git fetch commands

git fetch <remote>: Fetch all of the branches from the repository
git fetch <remote> <branch>: Same as the above command, but only fetch the specified branch

3. Git pull

The git pull command is used to fetch and download content from a remote repository and immediately update the local repository to match that content.

Hint! git pull is used with a different goal in mind: to update your current HEAD branch with the latest changes from the remote server.

Common git pull command

git pull <remote>: Fetch and merge changes on the remote server to the local working directory. This is the same as git fetch followed by git merge.

4. Git push

The git push command is used to upload local repository content to a remote repository. Pushing is how you transfer commits from your local repository to a remote.

Common git push commands

git push <remote> <branch>: Push the local branch to the specified remote repository. Creates (if it doesn’t exist) or updates a local branch in the remote repository
git push <remote> -all: Push all local branches to the specified remote repository. Creates (if they don’t exist) or updates all local branches in the remote repository

Working with Branches

A branch represents an independent line of development. Branches serve as an abstraction for the edit/stage/commit process. In Git, branches are a part of your everyday development process. Git branches are effectively a pointer to a snapshot of your changes. When you want to add a new feature or fix a bug — no matter how big or how small — you spawn a new branch to encapsulate your changes. This makes it harder for unstable code to get merged into the main code base, and it gives you the chance to clean up your future’s history before merging it into the main branch.

1. Git branch

The git branch command lists all the branches in the repository and shows what branch you’re currently in

Common git branch commands

git branch: List existing branches in your repository; the current branch will be highlighted in green and marked with an asterisk
git branch -d/-D <branchname>: Delete the specified branch/Force delete the specified branch, even if it has unmerged changes
git branch -m <newbranchname>: Rename the current branch to <newbranchname>
git branch -a: List all remote branches

2. Git checkout

The git checkout command lets you navigate between the branches.

Common git checkout commands

git checkout <branchname>: Switch from one branch to another
git checkout -b <branchname>: Create a new branch and switch to it

Hint! The git checkout command may occasionally be confused with git clone. The difference between the two commands is that clone works to fetch code from a remote repository, alternatively checkout works to switch between versions of code already on the local system.

3. Git merge

The git merge command lets you take the independent lines of development created by git branch and integrate them into a single branch. Git merge will combine multiple sequences of commits into one unified history. In the most frequent use cases, git merge is used to combine two branches.

Hint! Note that all of the commands presented below merge into the current branch. The current branch will be updated to reflect the merge, but the target branch will be completely unaffected.

Common git merge commands

git merge <branchname>: Merge a different branch into the current branch

Making a Pull Request

Pull requests are a feature that makes it easier for developers to collaborate using GitHub. They provide a user-friendly web interface for discussing proposed changes before integrating them into the official project. The general process of using pull-requests is as follows:

A developer creates the feature in a dedicated branch in their local repo.
The developer pushes the branch to a GitHub repository.
The developer files a pull request via GitHub.
The rest of the team reviews the code, discusses it, and alters it.
The project maintainer merges the feature into the official repository and closes the pull request.

https://www.atlassian.com/blog/bitbucket/5-pull-request-must-haves

Example

The example below demonstrates how pull requests can be used in the Feature Branch Workflow. The Feature Branch Workflow assumes a central repository and main represents the official project history. Instead of committing directly to their local main branch, developers create a new branch every time they start work on a new feature.

In the example, James is a developer, and Mia is the project maintainer. main branch of Mia’s GitHub repository represents the official project history.

Hint! To protect main branch from direct git push made by other’s developers, Mia protects her main branch.

To protect your main branch from direct pushes by other project’s collaborators go to Settings of GitHub repository, select Branches in the menu on the left side, and click Add rule in the ‘Branch protection rules’ section

In order to protect main branch, put main in the ‘branch name pattern’ box. And the select “Require pull request reviews before merging”. Now all commits must be made to a non-protected branch and submitted via a pull request with the required number of approving reviews and no changes requested before it can be merged into a branch that matches this rule.

James clones Mia’s GitHub repository

James needs to clone the GitHub repository. This will give him a working copy of the project on his local machine. He can do this by running the following command:

git clone https://github.com/user/repo.git

James develops a new feature

Before he starts writing any code, James needs to create a new branch for the feature. This branch is what she will use as the source branch of the pull request.

Hint! Use name of the feature for branch name. In this case your team will know what changes are included in this branch. Avoid using your name, date or other unrelated and unclear namigs.

#create a new branch for a new feature
git checkout -b new-feature
#edit some files, add and commit changes
git add <file> #if you want to add by file 
git commit -m 'First commit' #include change description
#edit more files
git add . #if you want to add all changed files
git commit -m 'Finished feature'

James pushes the feature to Mia’s GitHub repository

After his feature is complete, James pushes the feature branch to Mia’s GitHub repository with a simple git push:

git push origin some-branch

This makes his changes available to the project maintainer (or any collaborators who might need access to them).

James creates the pull request

James goes to Mia’s GitHub repository and creates a pull request.

2. In the Example Comparisons box, select the branch he made, readme-edits, to compare with main (the original).

3. James looks over his changes in the diffs on the Compare page, makes sure they’re what he wants to submit.

4. When James is satisfied that these are the changes he wants to submit, he clicks the big green Create Pull Request button.

5. If there are no conflicts, Mia can merge James’s pull request. If there would be any conflicts or comments from Mia regarding James’s changes, they should discuss them before the merge.

In the example above, both James and Mia could work on their features independently and then discuss their changes through a pull request. At the same time main branch of Mia’s GitHub repository represents the official project history and it’s protected from any direct changes by other project’s collaborators.