In August, we hosted a Girls Who Code meetup at HubSpot and led a workshop for beginners on using git and GitHub. We got feedback following the event that it was a useful, hands-on debut. So if you are new to git, also, follow the steps below to get comfortable making changes to the code base, opening a pull request (PR), and merging code into the master division. Any significant git and GitHub terms are in bold with hyperlinks to the official git reference materials.
Step 0: Install git and create a GitHub accounts
The first two items you’ll want to do would be set up git and generate a free GitHub account.
Follow the instructions here to install git (if it is not yet installed). Be aware that for this tutorial we will be using git on the control line just. While there are a few great git GUIs (graphical user interfaces), I think it’s simpler to find out git utilizing git-specific commands first and then to test a git GUI once you’re more comfortable with this control.
Once you’ve done this, make a GitHub accounts here. (Accounts are free for public repositories, but there is a fee for private repositories.)
Step 1: Create a Neighborhood git repository
To use git we are going to use the terminal. If you don’t have much experience with all the terminal and basic controls, check out this tutorial (especially the’Navigating the Filesystem’ and’Moving Around’ segments ).
To start, open a terminal and then move to where you would like to set the project in your regional machine using the cd (change directory) command. For example, if you have a’projects’ folder on your desktopcomputer, you would do something similar to:
Step 2: Insert a new file into the repo
Go ahead and add a new file into the project, with any text editor you like or operating a touch command.
However, git will not formally keep tabs on the document (that is, set it in a commit – we will talk more about commits next) unless you explicitly tell it .
After creating the file, you may use the git status control to see which documents git knows exist.
What this essentially says is,”Hey, we noticed that you created a new file called mnelson.txt, but if you don’t use the’git add’ control we are not likely to do anything with it”
One of the most confusing parts when you are first learning git is the concept of the staging environment and how it relates to some commit.
A perpetrate is a record of exactly what files you have changed since the last time you made a commit. Essentially, you make changes to your repo (for example, adding a document or modifying one) and tell git to put those files into a commit.
Commits constitute the gist of your project and permit you to return to the state of a project at any stage.
So, how do you tell git which documents to put into a commit? This is the point where the staging surroundings or index come in. As seen in Step 2, once you make changes to your repo, git finds that a file has changed but won’t do anything with it (like incorporating it in a commit).
To add a file into a commit, you first will need to add it into the staging environment. To try it, you may use the git add command (see Step 3 below).
Once you’ve used the git add command to add all of the files you want into the staging environment, you may then tell git to pack them into a commit with the git commit command.
Note: The staging environment, also called’staging’, is the new favorite term for this, but you might also see it called the’indicator’.
Step 3: Add a file to the staging environment
Add a document to the staging environment working with the git add command.
If you rerun the git status control, you’ll see that git has included the document to the staging environment (notice the”Changes to be dedicated” line).
To reiterate, the file includes not yet been inserted to a commit, but it’s going to be.
Step 4: Produce a commit
It is time to create your first commit!
The message at the end of this commit must be something related to what the perpetrate comprises – maybe it is a brand new feature, maybe it is a bug fix, perhaps it’s just fixing a typo. This makes the other people who see your commit sad. Very, very, sad.
Step 5: Develop a new branch
Now that you’ve made a new commit, let us try something a little more advanced.
Say you want to earn a new feature but are worried about making adjustments to the most important project while creating the feature.
Branches allow you to move back and forth between’states’ of a project. As an example, if you would like to add a new page to your website you can create a new branch just for that page without affecting the main part of the project. Once you’re done with the page, you can merge your changes from your branch into the master division. When you create a new branch, then Git keeps track of which perpetrate your division’branched’ off of, so it understands the history behind all the documents.
Let’s say you are on the master division and want to create a new branch to develop your webpage. This control will automatically create a new branch and then’check you out’ onto it, meaning git will move you to that branch, off of the master division.
After running the above command, you can use the git branch control to verify that your branch was created:
The branch name with the asterisk next to it indicates which branch you are pointed to at that given time.
But if you switch back to the master branch and also make more commits, your new branch will not find any of those changes until you merge those modifications on your new division.
Step 6: Create a new repository on GitHub
If you merely wish to keep track of your code anyplace, you don’t have to use GitHub. But should you would like to utilize a team, you can utilize GitHub to modify the project’s code.
After clicking the button, GitHub will ask you to name your repo and provide a brief description:
When you’re done filling out the data, press the’Create repository’ button to produce your new repo.
GitHub will inquire if you want to create a new repo from scratch or if you would like to put in a repo you have created locally. In Cases like This, since we’ve already created a new repo locally, we want to push that on GitHub so follow the ‘….or push an Present repository from the command line’ segment:
(You will want to modify the URL from the first control line to what GitHub lists in this section as your GitHub username and repo title are different.)
Step 7: Push a branch into GitHub
Now we’ll push the commit on your branch to your GitHub repo. This permits other people to see the changes you have made. If they’re approved by the repository’s proprietor, the adjustments can then be merged into the master division.
To push changes onto a new branch on GitHub, you are going to want to run git push source yourbranchname. GitHub will automatically create the division for you about the remote repository:
You may be wondering what that”source” word implies in the command above. What happens is that when you replicate a remote repository to your regional machine, git creates an alias for you. In almost all cases this alias is known as”source .” It’s basically shorthand for the remote repository’s URL. So, to push your changes to the remote repository, then you may have used either the control: git push email@example.com:git/git.
(If that is your first time using GitHub locally, then it might prompt you to log in with your GitHub username and password)
If you refresh the GitHub page, you’ll see note saying a branch with your title has just been pushed into the repository. It is also possible to click on the’branches’ connection to see your branch recorded there.
Now click the green button at the screenshot above. We’re going to make a pull request!
Step 8: Create a Pull Request (PR)
A pull petition (or PR) is a means to alert a repo’s owners you want to generate some adjustments to their code. It allows them to review the code and be sure it looks great before placing your changes on the master division.
That is what the PR page looks like before you have submitted it:
You may see a big green button at the bottom that says’Merge pull ask’. Clicking this means you’re merge your changes to the master division.
Note that this button won’t necessarily be green. In some cases it’ll be grey, which means you are confronted with a merge conflict. This is when there’s a change in 1 file that conflicts with a change in another document and git can’t figure out which variant to use. You’ll need to manually go in and tell git that variant to use.
At times you’ll be a co-owner or even the sole owner of a repo, in which case you may not have to create a PR to merge your changes. However, it is nonetheless a fantastic idea to make one so you can keep a more comprehensive history of your upgrades and also to make sure you always make a new branch when making changes.
Measure 9: Merge a PR
Go on and click the ‘Merge pull request’ button. This may merge your changes to the master branch.
When you are done, I recommend deleting your division (too many branches can become cluttered ), so hit that grey’Delete branch’ button too.
You may double check that your commits were merged by clicking the’Commits’ link on the first page of your repo.
This will show you a listing of all the commits in that branch. You can view the one I simply merged right up top (Merge pull request #2).
You could even understand the hash code of this commit on the right hand side. A hash code is a exceptional identifier for this commit.
Measure 10: Access changes on GitHub back to your computer
Right now, the Shop on GitHub looks a little different than what you need in your regional machine. For example, the commit you made on your division and merged to the master branch does not exist at the master division onto your regional machine.
In order to get the most recent changes you or others have united on GitHub, utilize the git pull source master control (when functioning on the master branch).
This shows you all of the documents which have changed and how they’ve changed.
(You might need to switch branches back into the master division.
Measure 11: Bask in your git glory
You’ve successfully created a PR and merged your code to the master branch. Congratulations! If you want to dive a bit deeper, have a look at the documents in this Git101 folder for more tips and tricks on using git and GitHub.
I also suggest finding some time to work with your staff on simulating a smaller group project such as we did here. Have your team create a new folder with your team name, and add some files with text into it. After that, consider pushing those changes to this remote repo. That way, your staff can start making changes to files they did not originally make and practice utilizing the PR feature. Also, use the git blame and git history tools on GitHub to find familiar with tracking which changes are made in a file and that made those adjustments.
The more you use git, the more comfortable you’ll… git with it. (I couldn’t resist.)