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:
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 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.
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
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
Hint! If any changes added to the original repo after you
git cloneit, they won’t be available to your copy of original repo until you run
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 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.
git fetchdoesn’t integrate any of this new data into your working files.
git fetchwill never manipulate, destroy, or screw up anything.
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
git pull command is used to fetch and download content from a remote repository and immediately update the local repository to match that content.
git pullis used with a different goal in mind: to update your current HEAD branch with the latest changes from the remote server.
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 fetchfollowed by
4. Git push
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.
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
git branch command lists all the branches in the repository and shows what branch you’re currently in
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
git checkout command lets you navigate between the branches.
git checkout commands
git checkout <branchname>: Switch from one branch to another
git checkout -b <branchname>: Create a new branch and switch to it
git checkoutcommand 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
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.
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.
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
mainbranch from direct
git pushmade by other’s developers, Mia protects her
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 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.