Lesson 3 Reflections - How to use Git and Github - Udacity

GITHUB is a website which makes it easier for anyone to share their entire repository.

When interacting with GitHub, the information whcih we send and receive are in the form of Git commits.Hence, the changes must be staged and committed before they can be sent.

If there is only one remote in the repository, then it is standard to name it as ORIGIN.

GIT REMOTE is the command to create a new remote:

    git remote add origin https://github.com/therealmccoy/reflections.git

git remote -v

    -v stands for verbose, which means git would now supply more information about the remote.

In most cases the (fetch) and (push) url of the remote would be the same.

In order to send the changes to remote, the command used is GIT REMOTE. It takes two arguments, the remote where the changes need to be pushed and the name of the local branch which is to be pushed.

    git push origin master

By default the name of the branch pushed to remote on Guthub would also have the same name.

TIL: When creating an empty repository on GitHub, it is important to keep it clean, without adding any Read.me or license, if the local repository, does not have it, else, the first push would not work, since remote has some files, which are not present locally, and hence first the files need to be fetched.

TIL: Even though, if remote is deleted on Github and a new repository with the same name is created again, the remote locally would not point it to that url, unless, the url is set via:

    git remote set-url origin git://new.url.here

TIL: Saving Github credentials in Git

    Turn on the credential helper so that Git will save your password in memory for some time. By default, Git will cache your password for 15 minutes.

    On the command line, enter the following:

    git config --global credential.helper cache
    # Set git to use the credential memory cache

    To change the default password cache timeout, enter the following:

    git config --global credential.helper 'cache --timeout=3600'
    # Set the cache to timeout after 1 hour (setting is in seconds)

QUE 1: When would you want to use a remote repository rather than keeping all your work local?

ANS 1: When I would like to share my codebase with some one else or when there are multiple collaborators on my project.

A REMOTE in the local repository, is basically a reference to another repository.

When a repository os cloned, a remote is set up automatically. So CLONE operates on REMOTE.

QUE 2: Why might you want to always pull changes manually rather than having Git automatically stay up-to-date with your remote repository?

ANS 2: This is so that I may have control, when to pull contents created or added by others into my own codebase.

FORKING is making a copy of someone else's work on GitHub servers, before downloading it the local repository.

When a CLONE is made, not only a remote ORIGIN is created in the local repository but it also points to the repository from where it was cloned.

QUE 3: Describe the differences between forks, clones, and branches. When would you use one instead of another?

ANS 3: FORK: When we copy someone else's work on GitHub servers, before downloading it to our local repository. It is very similar to CLONE. Essentially cloning the work on GitHub's server itself.

CLONES: When we copy some codebase from GitHub's servers to our local repository.

BRANCH: Branch is kind of essentially local cloning in the repository itself.

When we just want to have a look at the different files or some codebase of a repository, we FORK it.

When we want to make changes to that codebase, which has been FORKED, we CLONE it.

When we want to experimentally work on local repository, we BRANCH it.

GIT FETCH updates the local copy of the remote branch, leaving the original local master branch as it is.

git pull origin master == git fetch origin + git merge master origin/master

ORIGIN/MASTER shall point to the commit, which was there in the repository, when it was cloned. If I make any other commit, it becomes my MASTER branch.

The commit made by any other collaborator on the  GitHub would point towards the commit already there.

FAST FORWARD MERGE: Criteria: The branch we are merging INTO is an ancestor of the branch we are merging FROM.

QUE 4: What is the benefit of having a copy of the last known state of the remote stored locally?

ANS 5: We can always do GIT LOG and GIT DIFF and then find out the changes/updates.

QUE 6: How would you collaborate without using Git or GitHub? What would be easier, and what would be harder?

ANS 6: It would be very hard. Using combination of email and server requests and comments.

QUE 7: When would you want to make changes in a separate branch rather than directly in master? What benefits does each approach have?

ANS 7: If there are too many changes and collaborators, it is helpful to work with branches, than messing master.

when contributing to a public repository, it’s standard practice to make the changes in a non-master branch within the fork. This way, you can easily keep your master branch up-to-date with master of the original repository, and merge changes from master into your branch when you are ready.