UpStream and DownStream

In term of “flow of data”, your repo is at the bottom (“downstream”) of a flow coming from upstream repos (“pull from”) and going back to (the same or other) upstream repos (“push to”).

In terms of source control, you’re downstream when you copy (clone, checkout, etc) from a repository. Information flowed “downstream” to you.

When you make changes, you usually want to send them back “upstream” so they make it into that repository so that everyone pulling from the same source is working with all the same changes.

You cannot always make a branch or pull an existing branch and push back to it, because you are not registered as a collaborator for that specific project.

Forking

Forking is nothing more than a clone on the GitHub server side:

without the possibility to directly push back, with fork queue feature added to manage the merge request
You keep a fork in sync with the original project by:

  1. adding the original project as a remote
  2. fetching regularly from that original project
  3. rebase your current development on top of the branch of interest you got updated from that fetch.

Only contributor can approve the changes you pushed into fork for merge with original code

Clone

When you are cloning a GitHub repo on your local workstation, you cannot contribute back to the upstream repo unless you are explicitly declared as “contributor”.
So that clone (to your local workstation) isn’t a “fork”. It is just a clone.

Git

upstream generally refers to the original repo that you have forked
origin is your fork: your own repo on GitHub, clone of the original repo of GitHub

The general pattern is as follows:

  1. Fork the original project’s repository to have your own GitHub copy, to which you’ll then be allowed to push changes.
  2. Clone your GitHub repository onto your local machine
  3. Optionally, add the original repository as an additional remote repository on your local repository. You’ll then be able to fetch changes published in that repository directly.
  4. Make your modifications and your own commits locally.
  5. Push your changes to your GitHub repository (as you generally won’t have the write permissions on the project’s repository directly).
  6. Contact the Contributor once u have committed your changes in fork to pull it in orginal
Posted in git.

Step 1: Initialize the Working Directory.This is the working Directory where your project resides

 [cloudera@localhost MapReduce]$ git init

Step 2: Add to the Staging Directory as below

 [cloudera@localhost MapReduce1]$ git add *

Step 3: Commit to the Local Repository

[cloudera@localhost MapReduce1]$ git commit -am "Initial Commit"

Step 4: Run this on Terminal to Generate SSH Key

ssh-keygen -t rsa -C "mugil.cse@gmail.com" 

Step 5: Generated SSH Key will be in Users home Directory.It contains both private and Public key

cd /home/cloudera/.ssh
[cloudera@localhost .ssh]$ ll
total 12
-rw------- 1 cloudera cloudera 1671 May  7 21:11 id_rsa
-rw-r--r-- 1 cloudera cloudera  401 May  7 21:11 id_rsa.pub
-rw-rw-r-- 1 cloudera cloudera  395 May  7 21:01 known_hosts

id_rsa contains the private key and id_rsa.pub contains the public key.The Public key is added to the main repository where all the files are pushed at the day end.The public key and private key are verified by some algorithm every time a connection is made.The private key can be shared to user to whom limited access to repository should be given rather than using email adderess as password.

Step 6 : Open the id_rsa.pub which contains the public key which need to be added to the Repository

[cloudera@localhost .ssh]$ cat id_rsa.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAymFMhm8XM8NzuGMNrBzybMhdwkFZtWGSqo2zwkS4tWQGKQDLODD9tV+gXZeqiGWh/JkVq6P+QvwsMdl5kOTg+M33UDtP/dydUQ+eWNE0HoKRypldS5qvUtt/Y0+rOg/cy3U2tN4EWaY3oer0lFEY+esOc2tAogUcqCuyN37ywLB6wa23XKxgPFNpgxGM+rf3r2gVbV81hdHJ7RSTVpsS/BaetZZlvFAgNSo2qbVJlhpTY/GrF1Nhtz3q8oGfoxsUGtU+12JFJXphRQnYO0EJhZLxYSZvIcqb5YWmUZLVOg+HTsncnH1T5/l9tx/AT6IjqIo5ZbV+NxQ6R2F4fD0wEQ== mugil@gmail.com

Step 7: Paste the Git Repository URL as below

[cloudera@localhost MapReduce]$ git remote add origin git@bitbucket.org:Mugil/hadoop.git

Step 8: Now we need to Push the Staged File.

[cloudera@localhost MapReduce]$ git push origin master

Some Times while Pushing it might return back message like below

conq: repository access denied. deployment key is not associated with the requested repository. fatal: The remote end hung up unexpectedly

For that use

 ssh-add ~/.ssh/id_rsa

This Forces the Location of the private key to be set at global level in the System.

Checking SSH Status

>>service sshd status
>>service sshd start
>>chkconfig sshd on
Posted in git.