Tuesday, December 1, 2015

coding using GIT

I have been using GIT since few months and it was challange as I had been using Visual Source Safe and Microsoft Team foundation Server since last 10 years of my experience and the terms used in GIT were totally different. So, below are few challanges I faced.

What is CLONE: Before started working you have to get the code on your machine. For that you have to clone the code. you can clone directly in source tree from Master branch of repository.              
What is PULL : Whenever you want your code to be updated with other developer changes you need to press pull. but pull is very powerfull command and it will try to get the latest code and try to merge the latest with your changes. So, chances are it will merge something wrongly with your code changes. So, better you can use Fetch and Rebase instead of Pull.

What is MERGE :

What is FETCH : Fetch will just take the latest version but incase any merge required it will not do that automatically. So, chances of getting your code changes merge automatically are not there as in case of Pull. So, you are safe.

What is REBASE : Rebase is a megical command which I should have known few months before rather than right now because I wasted so, much of my time thinking about if my changes will be overwritten by Pull request and just update your changes to the repository and avoid making changes. And lot of time i had to listen from other developers that my code changes pushed to the repository is conflicting with their changes.
So, below is the definition.

          Instead of cramming all changes into a merge commit, a rebase preserves the original commits. The project's history then looks as if it had evolved in a single, straight line. No indication remains that it had been split into multiple branches at some point.
end-situation-for-rebase
After a rebase, it looks as if development had never split into different branches
Let's walk through a rebase operation step by step. The scenario is simple: we want to integrate the changes from branch-B into branch-A, using rebase.

starting-situation-before-rebase
An example scenario before starting the rebase
The command for this is very easy:
$ git rebase branch-B

First, Git will "undo" all commits on branch-A that happened after the lines began to branch out (after the common ancestor commit). Of course, it won't discard them but rather save them away, temporarily.
rebase-step-1
Step 1
Next, it applies the commits from branch-B that we want to integrate. At this point, both branches look exactly the same.
rebase-step-2
Step 2
In the final step, the new commits on branch-A are now reapplied - but on a new position, on top of the integrated commits from branch-B (they are re-based).
The result looks like development had happened in a straight line. Instead of a merge commit that contains all the combined changes, the original commit structure was preserved.
rebase-step-3
Step 3

What is

last Challange.
     
            How to sync our Fork from the Upstream.

Before you can use upstream name you have to define the upstream repository for your fork that you can do through sourcetree.


      1. Open your forked repo in SourceTree.
      2. Select Repository -> Repository Settings in the menu bar.
      3. In the Remotes pane, press Add.
      4. Enter any name you like (often upstream or master) and the URL / path to the parent repo.
      5. Press OK, then OK              

    1. You can open Git Bash widow
    2.  move to your local fork directory then type below. 
Below are the command you can execute in GIT BASH once you have set the upstream.

                               git fetch upstream\master 
                               git rebase upstream\master 

below image will explain what's happening.


No comments:

Post a Comment