Any checkout that is not the name of one of your branches will get you a detached HEAD.

The above scenario could be reproduced as below

1. lists the remote branches

   git branch -r
       origin/Feature/f1234
       origin/master
   

2. I want to checkout one locally, so I cut paste:

   git checkout origin/Feature/f1234
   

3. Detached HEAD state

   You are in 'detached HEAD' state. [...])
   

Solution #1:
Do not include origin/ at the front of my branch spec when checking it out:

git checkout Feature/f1234

Solution #2:
Add -b parameter which creates a local branch from the remote

git checkout -b origin/Feature/f1234
git checkout -b Feature/f1234  #it will fall back to origin automatically

But, you have started making changes in the detached branch and you encounter that later. In such case commits will work but changes
won’t be reflected in branch in remote since it is detached. To address such an issue

1. commit changes in detached local branch
2. create a new branch
3. checkout the branch you are already working so the connection with remote would be again established
4. Now the new branch created in local contains your changes and checkout will fetch the original remote branch without changes
5. Do git merge between two and push the code to remote now

git commit -m "....."
git branch my-temporary-work
git checkout master
git merge my-temporary-work

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.

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

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