If you answered yes to any of these questions, I strongly encourage you to keep reading.
Git enables efficient access to project changes throughout various phases of development.
You can also show off your coding abilities by posting project code to a reliable host (GitHub.
com).
Git can even track all project changes and store a backup of the most updated version of a project online.
All these benefits come at no cost beyond typing a few simple commands into the terminal.
Setting up a Git RepositoryThe locations where each project is hosted on GitHub.
com are called repositories.
When working with Git, you will be working with one remote repository and one or more local repositories.
A remote repository is a shared repository that is hosted on GitHub and used to track project changes.
A local repository is typically hosted on your local device (computer) and is used to make changes to a project without affecting the remote repository.
You can create a new repository by creating a GitHub account (if you don’t already have one), then click on the “New Repository” button in the top right corner of your account page.
Then all you have to do to set up your first project repository is name it and its ready to use.
Basic Independent WorkflowTo link your remote (online) repository to your local repository (folder/directory on your computer), use the following commands:1.
cd ProjectFolderLocationFor example, say I wanted to link a folder called ProjectFolder that lives in my Desktop.
I would access it by opening Terminal and typing the command, cd Desktop/Project.
2.
git initOnce you have accessed the local location of your project, enter the command, git init, which initializes your directory as a local GitHub repository.
3.
git remote add origin repository_urlNow that your local project repository is initialized, it’s time to link it to the empty remote repository on GitHub.
Enter the command, git remote add origin repository url.
This will establish the link between the remote and local project locations.
4.
git add .
/ git add file_nameNow create or add some files in your local repository then return to the Terminal and enter the command git add followed by a “.
” if you want to add all files.
You can also follow the git add with the name of a file to add individual files (e.
g.
git add my_file).
Note that if your local project folder is empty, this step will not work.
In order to update your remote repository, there needs to be new or adjusted content in the file(s) being added.
This is called staging your changes for commit, because you are adding your changes as a stage of the project to include in the project’s history.
5.
git commit -m “commit message”Now type in the command, git commit -m “commit message”, where the commit message is a brief message saying what changes you’re making to your project (e.
g.
“first commit”).
Using descriptive messages will help you avoid confusion when you need to track changes to your remote project.
This is called committing your changes, which allows your changes to be tracked by GitHub and applied to the updated version of the project.
to be “pushed” into your remote project location.
6.
git push — u origin masterLastly, running the command, git push -u origin master, will “push” the tracked changes to the master branch and update the remote repository.
Note that you only need to add the “-u” for the first push, meaning you are adding a tracking reference to the upstream server you’re pushing to.
This allows you to pull from the master branch using the git pull command, rather than git pull origin master.
Alright, now that you’ve seen the commands, time to apply what you’ve learned! Go to your account page on www.
github.
com and click on “New Repository”.
You will be redirected to a page similar to the page shown below:Sample creation of a new Git repository on GitHub.
Click on “Create Repository”.
GitHub does a great job of providing the necessary documentation and commands whenever a user creates a new remote repository.
Your screen should look something like this:After you create your repository, the next page will always look similar to this.
Click on the clipboard logo with the arrow pointing left to copy the remote repository URL to your clipboard.
You’ll need it in a minute to link the local repository to the remote repository.
Below is an example of properly initializing your local Git repository using Mac OS Terminal:Example initialization of Git repository sample_project.
Note that touch index.
html creates a new blank HTML file.
This is done because your local repository cannot be empty or not changed when running git add or git commit -m “commit message”.
In reality, you would most have previously existing files in your local project directory before linking to the remote repository.
After the repository is initialized, typical independent project workflow is:1) Make changes, add, or delete files in your local repository.
2) cd ProjectFolderLocation3) git add .
/ git add file_name4) git commit -m “commit message”5) git pushExample of typical independent workflow.
Getting Started with Group WorkflowIf you’re working in a group, designate one team member (usually the team lead) to create a new repository for the project.
When creating the repository, it is essential that the project settings are adjusted for how branches are handled.
Navigate to the “Branches” tab on the left of the settings page to click on the checkboxes titled “Protect this branch”, and “Require pull request reviews before merging”.
Saving these branch settings will prevent changes from being updated within the master branch unless changes are reviewed by the team.
Lastly, the team lead needs to perform the initial add, commit, and push workflow to the master branch, and add all team members as collaborators of the project using their personal GitHub usernames.
Once all members are added as collaborators, they will have access to the remote repository and can run the following command:git clone repository_urlAll team members except for the team lead (since the team lead created the repository and initialized it locally already) need to clone the repository into their local project directory in order to begin working.
Cloning a repository will make an exact copy of the most recent version of the remote repository in a specified directory.
This copy will already be set to have an origin, so there is no need to set it again using git remote add origin “repository_url”.
Keep in mind that the location of the project directory needs to be accessed using the Terminal.
For example, to clone a repository into the Documents directory, use the command, cd Documents, then run git clone repository_url.
Also, if you want to clone the repository into a directory within a directory, such as a folder called Projects that live on your Desktop, you would use the command, cd Desktop/Projects, to access the desired location, then run the git clone repository_url command.
It’s important to note that the repository should only need to be cloned ONCE by each team member.
Now, group workflow can finally begin!To clone a repository, navigate to the repository page (assuming you have access to it), then click on the green “Clone or download” button.
Click the clipboard logo with the arrow pointing left to copy the remote repository URL to your clipboard.
How to access the repository’s cloning link.
Before cloning a repository, you have to designate a location for it.
In this example, my all_projects folder from earlier got deleted due to technical difficulties.
But no need to worry because my project is safe on GitHub!.Once you choose a location for the cloned repository, use the cd command to access that location (e.
g.
cd Desktop/all_projects) in the Terminal.
Then run git clone repository_url.
The project will be the same as the most recent updated version and have the same name as the remote repository, which can be changed and updated.
Sample empty container directory before cloning.
Example usage of git clone command.
Contents of sample directory after clone.
The sample directory is inside the all_projects folder.
Group Workflow CommandsNow that the repository is ready and all team members have access to it, the next step is using the proper workflow while making changes to the project.
A standard rule when working in groups on GitHub is that all work in the master branch should be deployable.
This means that once something is in the master branch, it is considered complete.
Before files can be added into the master branch, team members, should use the following commands to ensure a clean workflow process:1.
git checkout -b branch_nameFirst, checkout a new branch before starting any work on the project.
This will ensure that the changes made by each team member do not conflict with the master branch content.
Note that once a branch is created, use the command git checkout branch_name to switch to any existing branch.
2.
git pullRunning this command will update the branch with the content that lives within the master branch.
The purpose of this command is to prevent redundancy by keeping your branch up to date with the most recent master branch content.
Once you run this command, feel free to make as many changes as you want to the project without worrying about harming the master branch.
To pull only from a specific branch, use git pull origin branch_name (e.
g.
git pull origin master, git pull origin different_branch).
3.
git add .
/ git add file_nameWhen working in a group, it’s usually best to stage your changes for commit on a file-by-file basis, rather than adding all files in your local repository.
This varies based on each team’s task distribution among members and organization of branches.
4.
git commit -m “commit message”Add (stage) your changes to be committed.
Commit your changes.
Remember to use an interpretable commit message that describes the changes you made in a concise way.
You can make as many changes (add and commit) as you want while working.
Good practice is to commit every meaningful change made in the context of the project or when a task is completed.
5.
git push origin branch_nameLastly, push your changes to your branch.
Once your changes have been pushed, go online to your team GitHub repository and click on “Make Pull Request”.
Then, all changes will (hopefully) be reviewed by either the team lead, the entire development team, or both.
Mandating review of changes is a great way to provide and receive feedback before updating the remote repository.
Once changes have been reviewed and approved, they will be merged with the master branch.
Check out the group workflow commands in action in the following example:Create a new branch, update your local files, make changes, and push your changes to the remote branch.
Note that git pull is only necessary when you expect that the branch has been updated or changed in some way prior to beginning your work.
For example, if a teammate made a change to your branch the night before, you would use git pull to update your local repository with the updated changes.
Other Important CommandsThere are many more Git commands that are worth knowing, but some of the most useful include:git statusRunning this command will display whether or not your changes have been tracked by Git.
If your changes have been made using the correct workflow, the git status command will show you the changes made to each file as either “created”, “modified”, or “deleted” following the file(s) associated with each change.
Checking the status of your changes can give you some extra confirmation that nothing accidentally happened without your knowledge while you were working on a project.
git remote -vTo check the remote repository URL associated with your local GitHub repository, run git remote -v.
This allows you to confirm that your local project is associated with the correct URL if you encounter errors.
git remote set-url new_repository_urlThis command enables you to adjust the URL associated with your local repository.
Good practice is to use git remote -v to check the URLs before and after running, git remote set-url new_repository_url.
Things to Watch Out For1) Initializing the Wrong Directory as a GitHub Repo:You’d probably be surprised if I told you the number of colleagues who I’ve seen initialize their entire Desktop and/or Documents directories as their first GitHub repositories (over 50 at least).
It’s a common error, but if you want to avoid it, I recommend using the pwd command if you aren’t sure that your terminal is in the right directory.
“Print working directory”, pwd, is a command that displays the current directory you’re in when navigating through files using Terminal.
2) Nested Repositories:One of the most common errors experienced by new GitHub users is initializing repositories within repositories.
To avoid this error, a basic understanding of the hierarchical nature of files stored on your computer is essential.
3) If Your Project is Private or Public:When you create a GitHub repository online, be sure that you know if your project is accessible by other users or not.
If you are looking to display your content, setting a repository as public is a great way to show other programmers what you can do.
However, accidentally displaying a project that you were intending to keep private could put the project at risk of being copied or stolen.
While important to consider, setting your project repository to private using the “Settings” tab above your repository is quick and easy way to eliminate this risk.
Wrapping UpThe need for version control for technical projects is only growing, for reasons of efficiency, reproducibility, and ease of use (with practice).
The goal of this post is to provide a simple guide to the basics of using GitHub for version control.
As someone who went from dreading the use of GitHub for projects to using it for all important coding projects by choice, I understand the struggles of being new to Git.
However, I also understand the benefits of its use and consider it an essential part of my independent or team daily workflow.
I hope this post helps and thank you for reading!Check out https://guides.
github.
com/ for more information.
Go to https://github.
com/ to start using version control today!.. More details