Git (Quick Commands)

Configure Git for the first time
git config --global user.name "Manglick, Arun"
git config --global user.email "Arun.Manglick@xyz.com"

Working with your repository
I just want to clone this repository
Simply clone this empty repository then run this command in your terminal.
git clone

Note: Clone command implicitly adds the origin remote for you.I.e.
You need not to add git remote add origin if clone is already used.
--------------------------------------------------------------------------------------
Clone Code:
 From the repository in Bitbucket, click the Clone button & Copy Clone Path
 cd local-directory
 $ git clone ssh://git@bitbucket.example.com:7999/PROJ/repo.git

Clone Specific Branch:
 git clone -b
 git clone -b master
 git clone -b onsite_branch
--------------------------------------------------------------------------------------
Push Code:
cd existing-project
git init
git status [-s]
git add --all
git add
git status

 $ git status -s
M README - Modified files have an M
A lib/git.rb  - After added to the staging area (After Commit)
?? LICENSE.txt - New files that aren’t tracked have a ?? next to them,

 Unstaging: Files are staged using above git add command.
To unstage a file (to remove a file or files from the staging area):
- git rm --cached  OR
- git reset  
- git reset --hard origin/branch_to_overwrite

 Undo:
git reset did a great job of unstaging octodog.txt, but you'll notice that he's still there.
Files can be changed back to how they were at the last commit by using the command:
git checkout --
git checkout -- octocat.txt

 Commit Staged Files as below:
git commit -m "Initial Commit"

 --  So far local repo is created. Now to push our local repo to the GitHub server, we'll need to add a remote repo on GitHub
(This command takes a remote repo name (e.g. origin) and a repository URL (e.g.https://github.com/try-git/try_git.git)
(Git doesn't care what you name your remotes, but it's typical to name your main one origin)
git remote add
git remote add origin

 -- Now finally push our local changes to our remote repo...origin in our case.
(The name of our remote is origin and the default local branch name is master)
(The -u tells Git to remember the parameters, so that next time we can simply run git push and Git will know what to do)
git push -u origin master
----------------------------------------------
My code is already tracked by Git
If code is already tracked by Git then set this repository as your "origin" to push to.
cd existing-project
git remote set-url origin
git remote set-url origin
git remote set-url origin

 git push -u origin master
--------------------------------------------------------------------------------------
Pull Code:
 cd existing-project
git pull
--------------------------
cd existing-project
git pull origin master

-- Sometimes when you go to pull you may have changes you don't want to commit just yet.
One option you have, other than commiting, is to stash the changes.
Use 'git stash' to stash your changes, and
Use 'git stash apply' to re-apply your changes after your pull.

Use 'git stash drop' with the name of the stash to remove.
Also you can run 'git stash pop' to apply the stash and then immediately drop it from your stack.

--------------------------------------------------------------------------------------
Undo:
 git checkout -- octocat.txt
--------------------------------------------------------------------------------------
Differences:
 There is a possiblity that three some additions and changes to repo family.
 Let's take a look at what is different from our last commit by using the git diff command.
 In this case we want the diff of our most recent commit, which we can refer to using the HEAD pointer.
 (The HEAD is a pointer that holds your position within all your different commits. By default HEAD points to your most recent commit,)
 git diff HEAD  OR
 git diff --staged

Staged Differences
 Another great use for diff is looking at changes within files that have already been staged.
 Remember, staged files are files we have told git that are ready to be committed.

  git diff  -- That command compares what is in your working directory with what is in your staging area.
  git diff --staged  -- This command compares your staged changes to your last commit

--------------------------------------------------------------------------------------
Branching Out
(When developers are working on a feature or bug they'll often create a copy (aka. branch) of their code they can make separate commits to. Then when they're done they can merge this branch back into their main master branch nd push it to the remote server)
- git branch Branch_Apr

Great! Now if you type git branch you'll see two local branches: a main branch named master and your new branch named  Branch_Apr
- git branch

(Switch between branches)
- git checkout

(Perform both things in one command)
- git checkout -b Branch_Apr
(Notice the phrase “fast-forward” in that merge)

(To check HEAD is pointing to which branch)
- git log --oneline --decorate

(To see the last commit on each branch)
- git branch -v

(To see which branches are already merged into the branch you’re on)
git branch --merged
  Branch_Apr
* master

(Pg 99- Because you already merged in Branch_Apr earlier, you see it in your list.
Branches on this list without the * in front of them are generally fine to delete with git branch -d;
As you’ve already incorporated their work into another branch, so you’re not going to lose anything)

(To see which branches are not merged into the branch you’re on)
git branch --no-merged
  Branch_Apr
* master

(To add branches created by someone else and you are not able to see those branches in your list)
$ git remote update
$ git branch -r
------------------------------------------------------------------------------------------
Preparing to Merge
 Switching Back to master
 - git checkout master

We're already on the master branch, so we just need to tell Git to merge the Branch_Apr branch into it:
- git merge Branch_Apr

Merging Issues: Two Ways:
- Manual -
 - Manually Resolve those conflicts and (Pg -97 ProGit Book)
 - Then run "git add"" on each file to mark it as resolved.Staging the file marks it as resolved in Git.
- Graphically - Use git mergetool
- Finally after merge issue resolved - type "git commit" to finalize the merge commit
- One more Finally - git push origin to finally push merged changes to git

- Merging specific file)(s) between branches (Brutal Force Merge)
Assume you are in master branch and want to merge from dev_i3 branch, use this syntax:--
git checkout .     (To Merge Entire Branch content)
git checkout
git checkout dev_i3 views/shared/nav.cshtml
(Ref Link: https://coderwall.com/p/nf4rqg/git-merge-a-single-file-from-one-branch-to-another)

- Merging specific file)(s) between branches
$ git checkout --patch branch2 file.py
The interactive mode section in the man page for git-add(1) explains the keys that are to be used:
http://stackoverflow.com/questions/18115411/how-to-merge-specific-files-from-git-branches

y - apply this hunk to index and worktree
n - do not apply this hunk to index and worktree
q - quit; do not apply this hunk or any of the remaining ones
a - apply this hunk and all later hunks in the file
d - do not apply this hunk or any of the later hunks in the file
g - select a hunk to go to
/ - search for a hunk matching the given regex
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
K - leave this hunk undecided, see previous hunk
s - split the current hunk into smaller hunks
e - manually edit the current hunk
? - print help
------------------------------------------------------------
Delete Branch (After Merge in Master)
 git branch -d to delete a branch.
 ($onist)

Force delete
 - What if you have been working on a feature branch and you decide you really don't want this feature anymore?
 - You might decide to delete the branch since you're scrapping the idea.
 - You'll notice that git branch -d doesn't work.
 - This is because -d won't let you delete something that hasn't been merged.
 - You can either add the --force (-f) option or use -D which combines -d -f together into one command.
------------------------------------------------------------------------------------------
Check Commit Summary:
git log (To check commit history) OR
git log --summary

Showing Your Remotes
git remote -v

Inspecting a Remote
git remote show origin

Removing and Renaming Remotes
git remote rm origin
git remote rename origin myorigin

Git Differences Tool:
git difftool branch1 branch2
git difftool branch1:file1 branch2:file1
git diff --name-status branch1..branch2

-------------------------------------------------------------------------------------------
Git Stages:
staged:
 - A place where we can group files together before we "commit" them to Git.
 - Files are staged using command: git add
 - To unstage a file (to remove a file or files from the staging area):
 - git rm --cached  OR
 - git reset

unstaged:
 - Files with changes that have not been prepared to be committed.

untracked:
 - Files aren't tracked by Git yet. This usually indicates a newly created file.

 deleted:
 - File has been deleted and is waiting to be removed from Git.


Hope this helps.

Arun Manglick

REST vs SOAP

Posted earlier long back in 2014 … Why REST - http://arun-ts.blogspot.com/2014/08/what-why-rest_6.html

Here again an attempt to find buzz question REST vs SOAP .. J 

Before this, understand REST underlying concepts: 

REST Concepts are referred to as Resources.

• Resources are manipulated by Components.
• Components, request and manipulate Resources via a Standard Uniform Interface.
• In case of HTTP, this interface consists of standard HTTP ops e.g. GET, PUT, POST, DELETE.

 Differences:

REST vs SOAP is not the right question to ask. SOAP is a protocol. REST is an architectural style.

SOAP stands for Simple Object Access Protocol	REST stands for Representational State Transfer.
SOAP is a protocol.	REST is an architectural style. -  REST has defined guidelines for creating services which are scalable.  REST used with HTTP protocol uses its verbs GET, PUT, POST and DELETE.
SOAP transport protocol is HTTP only	REST is protocol independent. It's not coupled to HTTP. Pretty much like you can follow an ftp link on a website, a REST application can use any protocol for which there is an standardized URI scheme. However REST is optimized for the web, due to its support for JSON, hence incredible popularity of REST over HTTP!
SOAP uses services interfaces to expose the business logic. SOAP is focused on accessing named operations, each implement some business logic through different interfaces.	REST uses Consistent/Standard URI to expose business logic. In case of HTTP, this interface consists of standard HTTP ops e.g. GET, PUT, POST, DELETE REST is focused on accessing named resources through a Standard Uniform/Consistent Resource Interface.
SOAP defines standards to be strictly followed.	REST does not define too much standards like SOAP
SOAP defines its own security. e.g. WS-Security, WS-AtomicTransaction, WS-ReliableMessaging etd.	RESTful web services inherits security measures from the underlying transport.
SOAP requires more bandwidth and resource than REST (Due XML Based)	REST requires less bandwidth and resource than SOAP (Due JSON Based)
SOAP permits XML data format only	REST permits different data format such as Plain text, HTML, XML, JSON etc
SOAP based reads cannot be cached.	REST has better performance and scalability.  REST reads can be cached.
SOAP can't use REST because SOAP is a protocol.	REST can use SOAP web services because it is a concept and can use any protocol like HTTP, SOAP.
SOAP is less inter-operable way to implement client-server, as many environments still don't have SOAP toolkits. And some that do have toolkits are based on older standards that can't always communicate with toolkits that implement newer standards.	REST is more inter-operable than SOAP. REST only requires an HTTP library to be available for most operations, and it is Certainly More Inter-operable Than Any RPC Technology (including SOAP).

  

Fundamental REST Principles:

• Client-Server Communication
• Client-server architectures have a very distinct separation of concerns.
• All applications built in the RESTful style must also be client-server in principle. 
• Inter-operable:
• Many people advertize SOAP as being the most inter-operable way to implement client-server programs. But some languages and environments still don't have SOAP toolkits. And some that do have toolkits are based on older standards that can't always communicate with toolkits that implement newer standards.
• REST only requires an HTTP library to be available for most operations, and it is Certainly More Inter-operable Than Any RPC Technology (including SOAP).
• Stateless
• REST encourages each resource to contain all of the states necessary to process a particular client request.
• Thus  server mcompletely understand the client request without using any server context or server session state.
• Cacheable
• Few Approaches to make Cacheable: Link1, Link2
• Entity Tags (ETags) that don’t rely on shared agreement on time
• The Last-Modified HTTP header, which is date-time-centric
• The Vary Header
• When RESTful endpoints are asked for data using HTTP, the HTTP verb used is GET.
• Resources returned in response to a GET request can be cached in many different ways.
• e.g. Cache constraints may be used, thus enabling response data to be marked as cacheable or not-cacheable. Any data marked as cacheable may be reused as the response to the same subsequent request. 
• Uniform Interface
• All components must interact through a single uniform interface.
• Because all component interaction occurs via this interface, interaction with different services is very simple.
• The interface is the same! This also means that implementation changes can be made in isolation.
• Such changes, will not affect fundamental component interaction because the uniform interface is always unchanged. 

Reference: http://stackoverflow.com/questions/19884295/soap-vs-rest-differences

Hope this helps.

Arun Manglick