GIT for Interview

1. Difference between Distributed & Central version control system.
A. GIT is distributed version control system.
     SVN is central version control system.

Central Version Control System : It is located in one place and people can check out from central location to make their changes and then check everything back in but some times it is problematic if central repository is corrupted or central system is not connected through network. For that we have to take backup manually in local machine.

Distributed Version Control System : Everybody has local repository. Your local repository has all information that remote repository has and till last sync done between local and remote repository. So sometimes, if remote repository is not able to be connected through internet, then we can see every changes as it is also saved in local repository. So every developer has repository in locally. So it is called in distributed version control system.


 2. Check version of GIT installed on your machine.
A. git --version

3. Setting configuration
A.
Set username : git config --global user.name "Manan Shah"
Set email : git config --global user.email "manan0shah@gmail.com"
Check configuration setting : git config --list

4. Get git function help
A.

git help <verb>
git verb --help

i.e git help config
     git config --help

     git help add
     git add -help

5. Setup git in your project
A. Goto finder/folder of project which we want to track, using terminal using cd command and write following command
 git init

6. To check status of untracked files in our repository
A. git status

7. Ignore files which we want to keep untracked. Like personal settings, preferences, etc
A. Create a gitignore file : touch .gitingore
     Write down list of files which we want to ignore to track as below :
     .ds_store
     .xcodeproj
     *.py  (wild card used to ignore files which has py extension)

After this, git status

--------------------------------------------

There are 3 area in area we have knowledge about.
1. Working directory
2. Staging Area
3. Git directory

(image from Pro Git" book : https://git-scm.com/book/en/v2)

1. Working directory : Untracked files reside in working directory. -> Files in red colour in terminal
2. Staging Area : When we use command git add . , then this files added to staging area. Which can be committed. -> Files in green colour in terminal
3. Git directory : When we commit our changes, then it goes to git directory. That can be push to remote directory. git commit -m "message for this commit like changes in setting"

Note : If we want to uncommit changes or remote files from staging area to working directory, then Use git reset 

We can check all commit log using command : git log

------------------------------------------

Cloning git repo

git clone <url_of_remote_git> <local_directory>

git clone https://....../remote_repo.git .    (. means in current folder)

-----------------------------------------

Viewing remote repository info

git remote -v  : Give information about your local repository path for fetch, push

git branch -a : Give list of all local and remote branches

-----------------------------------------

Pushing code

git diff : tells difference between remote and local files changes
git pull origin master : pull all changes made from remote repo to local
git push origin master : push all changes from local to remote repo

-----------------------------------------

Merge branch

Suppose, we have worked on calc branch and we need to merge calc branch into master branch.

git checkout master :  Switch to master branch or in which we have to merge
git pull origin master : Pull all changes in master branch from remote server
git branch --merged : Check branch name in which code is to be merged
git merge calc : Merge calc branch with master branch. It shows number of changes. If any conflicts are there, then  we have to solve it using editing code.
git push origin master : Push merged code to remote master branch

-----------------------------------------

Deleting branch

git branch -d calc : Delete calc branch locally
git branch -a : To check whether branch is deleted or not.
git push origin --delete calc : To delete calc branch remotely

-----------------------------------------------------------------------------------------------------------------

Different parameters for adding files to staging area  :

1. git add -A or git add --all (Default): adding all files from leading directory into staging area
2. git add -A my_dir/ or git add my_dir/ : adding only files located in my_dir into staging area
3. git add -u : adding only modified files into staging area
4. git add -u my_dir/ : adding only updated files located in my_dir into staging area
5. git add . : adding all files in current directory into staging area
6. git add .gitignore : Add only specific file into staging area.

Difference between git add -A and git add . : git add -a add all files in leading directory and git add . only add files from current directory.

-----------------------------------------------------------------------------------------------------------------

Switch to branch without commiting

git stash save "worked on save function" : It will save this branch at this point without commited. And this branch at initial stage.
git stash list : List all stashes here
stash@{0} : On add : worked on save function
git stash apply stash@{0} : Come to our point back using this command. stash will not be dropped.
git stash pop : Come to our point back & drop stash from list.
git stash drop stash@{0} : drop stash@{0}
git stash clear : Clear all stash in list

If we want to do changes from one branch to another branch, then this is most wanted method.

Suppose, I have changed code in master branch.  But I want it to CalC branch. Then,
git stash save "add function" :  save stash on master branch
git checkout CalC :  Switched to CalC branch
git stash pop : apply changes
git add . : add files to staging area
git commit -m "intr" : commit & push


Note : New stash come at top position. Always at 0th position. @{0}.

-----------------------------------------------------------------------------------------------------------------

Git difftool & mergetool

git diff : It shows modification with red(Previous) and green(Current) colour content between previous and current file on terminal window. It is very hard to see where we have changed or what word we have changed. Because git diff shows full line instead of changed word.

So instead of using, there are many diff tool and merge tool available. I,e DiffMerge
Using this tool, we can easily find changes and solve if any conflicts are there just because it is graphically represent instead of just terminal.
For that we have to download and install that tool and configuration with our git. After configuration, check configuration using git config --global --list

Check
diff.tool = diffmerge
merge.tool = diffmerge

happened or not?

Now,
to run that diff tool ,
git difftool : It required permission to open diff tool, press Y to open difftool, and we can see modification clearly with color and word by word.

We can take changes according to we required by simply click on which changes and from which file(previous or current).

git mergetool : To merge branch. If any conflict occur, we can easily solve using this type tool due to visual representation.

-----------------------------------------------------------------------------------------------------------------

To change last commit message,

git commit --amend -m "new message" : It will change message of last commit message.

Hight thank full to Corey Schafer

I took help from following videos  :

1. Git Tutorial for Beginners: Command-Line Fundamentals
2. Git Tutorial: Fixing Common Mistakes and Undoing Bad Commits
3. Git Tutorial: Using the Stash Command
4. Git Tutorial: Diff and Merge Tools
5. Git Tutorial: Change DiffMerge Font-Size on Mac OSX
6. Git Tutorial: Difference between "add -A", "add -u", "add .", and "add *"

If you have any doubts for git, please comment on this blog. 

How to call segue programmatic?

Ans : 

For segue first, We have to set identifier in Class Inspector right side in XCode. Through that identifier, we can call like

performSegue(withIdentifier: "identifier", sender: nil) 

What is Content Hugging and Content Compression Resistance Priority?

Ans : 

The priority really come in to play only if two different constraints conflict. The system will give importance to the one with higher priority. So, Priority is the tie-breaker in the autolayout world.

1. Content Hugging Priority : 

Larger the content hugging priority , the views bound will hug to the intrinsic content more tightly preventing the view to grow beyond its intrinsic content size. Setting a larger value to this priority indicates that we don’t want the view to grow larger than its content.

In above example, we set both label leading, trailing, top and bottom but not set width constraint. So here conflicts will occur. You can see red line between two label showing conflict.

Solution : If we have label's content hugging priority higher than there will be no conflicts as hight priority label will not grow its size more than its content size. See below image :

Blue label has more content hugging priority (251) than green label(250). Blue label's width will be set fixed as its content size.

2. Content Compression Resistance : 

Setting a higher value means that we don’t want the view to shrink smaller than the intrinsic content size. It's simple : Higher the priority means larger the resistance to get shrunk.

Example . One button having large name and auto layout is set on button as its width is become 40. So, button's content is not readable. See image :

Button horizontal compression resistance is 750 and width constraint priority is 1000.

For Solution, let's change horizontal compression resistance to 1000 and width constraint priority less than 1000 i.e 999 . Now see effect on below image :

Button horizontal compression resistance is 1000 and width constraint priority is 999.

If you have any comment, question, or recommendation, feel free to post them in the comment section below!

What is closure? Why we use closure instead of function sometime?

Ans : 

The two most used cases are completion blocks and higher order functions in Swift. 

Completion blocks: for example, when you have some time consuming task, you want to be notified when that task is finished. You can use closures for that, instead of a delegate (or many other things)

func longAction(completion: () -> ()) {

    for index in veryLargeArray {

        // do something with veryLargeArray, which is extremely time-consuming

    }

    completion() // notify the caller that the longAction is finished

}

//Or asynch version

func longAction(completion: () -> ()) {

    

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0)) {

        

        for elem in veryLargeArray {

            // do something with veryLargeArray, which is extremely time-consuming

        }

        dispatch_async(dispatch_get_main_queue(), {

            completion() // notify the caller that the longAction is finished

        })

    }

}

longAction { print("work done") }

In the example above, when you have a time consuming task, you want to know when the for loop finishes iterating through the very large array. You put the closure { println("work done") } as an input parameter for the function which will be executed after the for loop finishes its work, and print "work done". And what happened is that you gave a function (closure) to longAction and name it to completion, and that function will be executed when you call completion in longAction.

Sorted method works using closure.

About how sorted (probably) works: So the idea is, that sorted will go through the array, and compare two consecutive elements (i, i + 1) with each other, and swap them, if needed. What does it mean "if needed"? You provided the closure { (s1: String, s2: String) -> Bool in return s1 > s2 }, which will return true if s1 is greater than s2. And if that closure returned true, the sorted algorithm will swap those two elements, and continues this with the next two elements (i + 1, i + 2, if the end of the array is not reached). So basically you have to provide a closure for sorted which will tell "when" to swap to elements.

Understand Closure

Differences between internal testers and external testers in test-flight?

Ans : 

Both internal and external testers will install your app from the TestFlight app. Once invited, they will be sent an email asking them to install the TestFlight app. Once they have done so, they'll be able to install your beta app...

Internal Testers: Think of these users as employees who receive instant updates to your app without approval/review

• Must be added manually via iTC
• 25 Max allowed
• Once your app is uploaded it's available immediately for internal testers (before it has been reviewed)
• All internal testers must be added as a user in your iTC "Users and Roles" settings, which gives them certain permissions (review other answers and the docs for this). You wouldn't want to give just anyone permissions here.
• Do not have a 60-day time limit

External Testers

• Will only be able to use your uploaded build for up to 60 days. If you add additional builds, they can update, and the 60 days starts over again.
• Will be able to test your app after
  1. You have submitted it for review
  2. It gets approved in TestFlight review and
  3. You set it to be available for testing. The review process us usually instant for new builds with the same version number. If you add a new version number, the review process can take up to 48hrs as of 10/2016.
• Up to 2000 email addresses can be added. Each email address will allow a user to install the app on multiple devices. The email addresses do not need to match their Apple IDs.
• They receive an invite to install your app once your first build is available for testing. If you add a new user after making a build available for testing, they'll immediately receive an invite. All users will receive notifications to install newer versions of the app if you upload additional builds.
• Will be disallowed from using your app after you have pushed it to the official app store (which promptly ends the beta) or 60 days have passed since you started the beta, whichever comes first. If you end the beta without launching in the app store, and they try to open it, it will crash. Yay, Apple UX! If you do push a version to the app store with the same bundleName, version, and bundleID (build number doesn't matter), then your beta testers will automatically receive the app-store version of the app when it goes live.