Tag Archives: git

How to fork a repo.

Source from: https://help.github.com/articles/fork-a-repo

Fork A Repo

If you’ve found yourself on this page, we’re assuming you’re brand new to Git and GitHub. This guide will walk you through the basics and explain a little bit about how everything works along the way.

Contributing to a project

At some point you may find yourself wanting to contribute to someone else’s project, or would like to use someone’s project as the starting point for your own. This is known as “forking.” For this tutorial, we’ll be using the Spoon-Knife project.

Step 1: Fork the “Spoon-Knife” repository

To fork this project, click the “Fork” button.

Click "Fork"

Step 2: Clone your fork

You’ve successfully forked the Spoon-Knife repository, but so far it only exists on GitHub. To be able to work on the project, you will need to clone it to your local machine.

Run the following code:

git clone https://github.com/<em>username</em>/Spoon-Knife.git# Clones your fork of the repository into the current directory in terminal

Step 3: Configure remotes

When a repository is cloned, it has a default remote called origin that points to your fork on GitHub, not the original repository it was forked from. To keep track of the original repository, you need to add another remote named upstream:

cd Spoon-Knife# Changes the active directory in the prompt to the newly cloned "Spoon-Knife" directory
git remote add upstream https://github.com/octocat/Spoon-Knife.git# Assigns the original repository to a remote called "upstream"
git fetch upstream# Pulls in changes not present in your local repository, without modifying your files

More Things You Can Do

You’ve successfully forked a repository, but get a load of these other cool things you can do:

Push commits

Once you’ve made some commits to a forked repository and want to push it to your forked project, you do it the same way you would with a regular repository:

git push origin master# Pushes commits to your remote repository stored on GitHub

Pull in upstream changes

If the original repository you forked your project from gets updated, you can add those updates to your fork by running the following code:

git fetch upstream# Fetches any new changes from the original repository
git merge upstream/master# Merges any changes fetched into your working files

Create branches

Branching allows you to build new features or test out ideas without putting your main project at risk. In git, branch is a sort of bookmark that references the last commit made in the branch. This makes branches very small and easy to work with.

Pull requests

If you are hoping to contribute back to the original fork, you can send the original author a pull request.

Unwatch the main repository

When you fork a particularly popular repository, you may find yourself with a lot of unwanted updates about it. To unsubscribe from updates to the main repository, click the “Unwatch” button on the main repository.

Click "Unwatch"

Delete your fork

At some point you may decide that you want to delete your fork. To delete a fork, just follow the same steps as you would to delete a regular repository.

How to set up git repo on your own.

Source from: https://help.github.com/articles/create-a-repo

If you’ve found yourself on this page, we’re assuming you’re brand new to Git and GitHub. This guide will walk you through the basics and explain a little bit about how everything works along the way.

Make a new repository on GitHub

Every time you make a commit with Git, it is stored in a repository (a.k.a. “repo”). To put your project up on GitHub, you’ll need to have a GitHub repository for it to live in.

Click New Repository.

Click "New Repository

Fill out the information on this page. When you’re done, click “Create Repository.”

Fill in the info

Congratulations! You have successfully created your first repository!

Create a README for your repository

While a README isn’t a required part of a GitHub repository, it is a very good idea to have one. READMEs are a great place to describe your project or add some documentation such as how to install or use your project. You might want to include contact information – if your project becomes popular people will want to help you out.

Step 1: Create the README file

In the prompt, type the following code:

mkdir ~/Hello-World# Creates a directory for your project called "Hello-World" in your user directory

cd ~/Hello-World# Changes the current working directory to your newly created directory

git init# Sets up the necessary Git files
# Initialized empty Git repository in /Users/<em>you</em>/Hello-World/.git/

touch README# Creates a file called "README" in your Hello-World directory

Open the new README file found in your Hello-World directory in a text editor and add the text “Hello World!” When you are finished, save and close the file.

Step 2: Commit your README

Now that you have your README set up, it’s time to commit it. A commit is essentially a snapshot of all the files in your project at a particular point in time. In the prompt, type the following code:

git add README# Stages your README file, adding it to the list of files to be committed

git commit -m 'first commit'# Commits your files, adding the message "first commit"

Step 3: Push your commit

So far everything you’ve done has been in your local repository, meaning you still haven’t done anything on GitHub yet. To connect your local repository to your GitHub account, you will need to set a remote for your repository and push your commits to it:

git remote add origin https://github.com/<em>username</em>/Hello-World.git# Creates a remote named "origin" pointing at your GitHub repository

git push origin master# Sends your commits in the "master" branch to GitHub

Now if you look at your repository on GitHub, you will see your README has been added to it.

Your README has been created

Git, the first configuration.

First-Time Git Setup

Now that you have Git on your system, you’ll want to do a few things to customize your Git environment. You should have to do these things only once; they’ll stick around between upgrades. You can also change them at any time by running through the commands again.

Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places:

  • /etc/gitconfig file: Contains values for every user on the system and all their repositories. If you pass the option--system to git config, it reads and writes from this file specifically.
  • ~/.gitconfig file: Specific to your user. You can make Git read and write to this file specifically by passing the --global option.
  • config file in the git directory (that is, .git/config) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in .git/config trump those in /etc/gitconfig.

On Windows systems, Git looks for the .gitconfig file in the $HOME directory (%USERPROFILE% in Windows’ environment), which is C:\Documents and Settings\$USER or C:\Users\$USER for most people, depending on version ($USER is %USERNAME% in Windows’ environment). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer.

Your Identity

The first thing you should do when you install Git is to set your user name and e-mail address. This is important because every Git commit uses this information, and it’s immutably baked into the commits you pass around:

<code>$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
</code>

Again, you need to do this only once if you pass the --global option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or e-mail address for specific projects, you can run the command without the --global option when you’re in that project.

Your Editor

Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. By default, Git uses your system’s default editor, which is generally Vi or Vim. If you want to use a different text editor, such as Emacs, you can do the following:

<code>$ git config --global core.editor emacs
</code>

Your Diff Tool

Another useful option you may want to configure is the default diff tool to use to resolve merge conflicts. Say you want to use vimdiff:

<code>$ git config --global merge.tool vimdiff
</code>

Git accepts kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff as valid merge tools. You can also set up a custom tool; see Chapter 7 for more information about doing that.

Checking Your Settings

If you want to check your settings, you can use the git config --list command to list all the settings Git can find at that point:

<code>$ git config --list
user.name=Scott Chacon
user.email=schacon@gmail.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...
</code>

You may see keys more than once, because Git reads the same key from different files (/etc/gitconfig and ~/.gitconfig, for example). In this case, Git uses the last value for each unique key it sees.

You can also check what Git thinks a specific key’s value is by typing git config {key}:

<code>$ git config user.name
Scott Chacon
</code>