How to Create Your First Git Repository
By: Brandon Cantello
Tags: Repositories, Github, Bitbucket, Git, Version Control

As in the previous example, the first thing you want to do is create a new repo on GitHub. In this case however,

do NOT initialize the project with a readme or .gitignore file.

This can lead to some difficulties and early merge conflicts when you are attempting to push up the code that is already on your computer due to the fact that the remote repo now has files that you do not have locally!

Since you are not initializing the repo with any files, GitHub will then direct you to a page with three different options for moving forward. Sit tight for a bit. We will be coming back to this page later so don’t click anything or close the window.

Don’t close this page! We will come back to it later.

Now, in your terminal, cd into the root directory of the project that you would like to add to GitHub. Once in the root directory (the top level folder at the beginning of your project), you need to initialize that directory as a local git repository. This is done by typing:

$ git init

Now you need to add the files that you would like to push to git hub to your local staging. Before doing so, make sure that there are no files containing sensitive information such as passwords, ssh keys, api keys, etc. If there are, you need to create a .gitignore file and add those files to your .gitignore before adding anything to staging. Anything that is in your .gitignore file will literally be ignored by git. This means that it will not be added to staging and pushed up to GitHub. It will remain only on your computer. You can create a .gitignore file by typing:

$ touch .gitignore

For some help creating more comprehensive .gitignore files, check out this site: https://www.toptal.com/developers/gitignore. It generates .gitignore files based on IDE’s or programming languages. You will still need to add your unique password or api files manually, but its a good place to start.

Now you are ready to add your files to staging. That can be done by typing:

$ git add .

The dot after add is necessary. The dot essentially means “every child directory”. This means that every folder that is a child of the root directory, that is not present in your .gitignore , will be added to staging. Think of staging as were your files that you would like to push up to GitHub are being accumulated.

Now that your files are staged, you need to bundle them into a commit and add a short, but descriptive message with lets you and others know what changes to the code base this particular commit contains. This is done my typing:

$ git commit -m “Enter your message here”

Now you need to link your local repo to the remote repo stored on GitHub. Remember that page I said we would come back to? Now’s the time. The top option should say something like “Quick setup — If you’ve done this kind of thing before” and will have a link for you to copy.

You want to use this one

This link should have the same form as the clone link, but incase you forgot, it looks like:

https://github.com/YourUserName/YourRepoName.git

Copy that link and then go back to your terminal. From the command line type:

$ git remote add origin https://github.com/YourUserName/YourRepoName.git

This will point your local repo at the remote repository. If you would like to confirm that the repo is linked correctly, you can type:

$ git remote -v

This will display all remote repos that your local repository is currently pointed to. Now finally it is time to push all your local changes to your newly linked remote repo. This is done by typing:

$ git push -u origin master

And you’re done! Whenever you want to push more code up to GitHub you simply need to add your changes to staging, open a commit, and push that commit to your remote repo. You can combine a few of those steps as follows:

$ git commit -am "Your message"

$ git push

The -am flag combines the add step with the commit/message step. There is also no need to specify where you would like to push to, since the repo is already linked.

One final note: you should NEVER code directly in your master branch. Your master branch should be the clean, functioning code that you can fall back to if the code your are working on needs to be thrown away. In order to maintain a working version of master when coding a new feature or component, you should always create a new branch. This can be done by typing:

$ git checkout -b someBranchName

This should be done from the master branch. By doing so, you make a fresh copy of master to begin coding in. Once your feature is completed, you can merge the working changes back into master by opening a pull request on GitHub. Once that merge is complete, you can delete the feature branch by typing:

$ git branch -d someBranchName

Now you are ready to create a new branch and move on to the next feature! Hopefully you found this little tutorial helpful. Good luck and happy coding!