TASK BASED ON GIT & GITHUB MASTERCLASS

Git PUSH

The git push command is used to transfer or push the commit, which is made on a local branch in your computer to a remote repository like GitHub. The command used for pushing to GitHub is given below:

git push 'remote_name' 'branch_name'

PULL Request

If you make a change in a repository, GIT PULL can allow others to view the changes. It is used to acknowledge the change that you've made to the repository that you're working on. Or also called a target repository.

The simple command to PULL from a branch is:

git pull 'remote_name' 'branch_name'

The git pull command is a combination of git fetch which fetches the recent commits in the local repository and git merge, which will merge the branch from a remote to a local branch also 'remote_name' is the repository name and 'branch_name' is the name of the specific branch.

Using Command line to PUSH to GitHub

1. Creating a new repository.

• You need to create a new repository and click on the plus sign.
• Fill up all the required details, i.e., repository name, description and also make the repository public this time as it is free.

2. Open your Git Bash.

• Git Bash can be downloaded in here, and it is a shell used to interface with the operating system which follows the UNIX command.

3. Create your local project in your desktop directed towards a current working directory.

• pwd stands for 'print working directory', which is used to print the current directory.
• Move to the specific path in your local computer by cd 'path_name'. The cd commands stand for 'change directory' and it is used to change to the working directory in your operating system, and to locate your file, 'path_name', i.e., C:/Users/Dell/Downloads/FaceDetect-master needs to be given. This command can identify the required file that you are looking to work with.

4. Initialize the git repository

• Use git init to initialize the repository. It is used to create a new empty repository or directory consisting of files' with the hidden directory. '.git' is created at the top level of your project, which places all of the revision information in one place.

5. Add the file to the new local repository.

• Use git add . in your bash to add all the files to the given folder.
• 
  
• Use git status in your bash to view all the files which are going to be staged to the first commit.

6. Commit the files staged in your local repository by writing a commit message.

• You can create a commit message by git commit -m 'your message', which adds the change to the local repository.
• 
  
• git commit uses '-m' as a flag for a message to set the commits with the content where the full description is included, and a message is written in an imperative sentence up to 50 characters long and defining "what was changed", and "why was the change made".

7. Copy your remote repository's URL from GitHub.

• The HTTPS or URL is copied from the given GitHub account, which is the place of the remote repository.

8. Add the URL copied, which is your remote repository to where your local content from your repository is pushed.

git remote add origin 'your_url_name'

• In the above code, The 'origin' is the remote name, and the remote URL is "https://github.com/Olivia-Smithcoder100/FaceDetection.git". You can see the remote as GitHub in this case, and GitHub provides the URL for adding to the remote repository.

9. Push the code in your local repository to GitHub

• git push -u origin master is used for pushing local content to GitHub.
• In the code, the origin is your default remote repository name and '-u' flag is upstream, which is equivalent to '-set-upstream.' and the master is the branch, name.upstream is the repository that we have cloned the project.
• Fill in your GitHub username and password.

10. View your files in your repository hosted on GitHub.

• You can finally see the file hosted on GitHub.

Using GitHub Desktop to PUSH to your local content to GitHub.

GitHub Desktop is available to download for any operating system, and it gives the GUI(Graphical User Interface) platform to push your local content from your local repository to a remote repository like GitHub.

You need to open your GitHub account in your browser and the process of creating a new repository, i.e., step 1 is the same as mentioned above in "Using Command line to PUSH to GitHub".

1. Click "Set up in a Desktop".

• You need to click on the button, as shown below where a pop up comes, and you click on "Open GitHub desktop".

2. Cloning in a GitHub Desktop.

• You can click the "Clone" button, as shown below.

After cloning a new clone, the folder is created in your local computer where a hidden directory ".git" is also present.

3. Copy all the required files from your local computer into the clone folder on your computer.

• You need to copy all the required files, images, README files, etc., to the clone folder.

4. Move to GitHub Desktop and commit to master

• You can see the files that are added into the clone folder are seen in GitHub Desktop too. Finally, write your message and push "Commit to master".

5. Publish branch in GitHub Desktop to upload your all files to GitHub.

• You can click on "Publish Branch" to publish your all local content to GitHub.

You can view your repository in GitHub after you have completed all steps.

Steps To Ignore Files in Git | .gitignore file

Sometimes we don’t want to push or check in some files in our system to git repository, using gitignore we can achieve this and ignore files and folders(directories). for that we need to create .gitignore file.

what is .gitignore file

Gitignore file is a normal text file under your repository where we can mention the files and folders(directories) which we want to ignore.

How to ignore files in git

Create a .gitignore file in your repository and mention the file names in it, which you want to ignore.

$ cat .gitignore

.DS_Store
target/
pom.xml.tag
pom.xml.releaseBackup
pom.xml.versionsBackup
pom.xml.next
release.properties
dependency-reduced-pom.xml
buildNumber.properties
.mvn/timing.properties

!/.mvn/wrapper/maven-wrapper.jar

$ cat .gitignore

.DS_Store
target/
pom.xml.tag
pom.xml.releaseBackup
pom.xml.versionsBackup
pom.xml.next
release.properties
dependency-reduced-pom.xml
buildNumber.properties
.mvn/timing.properties

# Avoid ignoring Maven wrapper jar file (.jar files are usually ignored)
!/.mvn/wrapper/maven-wrapper.jar

in the above file ignored .DS_Store file,target/, pom.xml.tag, pom.xml.releaseBackup, pom.xml.versionsBackup, pom.xml.next, release.properties, dependency-reduced-pom.xml, buildNumber.properties, .mvn/timing.properties.

How ignore folders or directories in git

open the .gitignore file and mention the path of directories names and at the end of the directory name you should add /

what if you already added the file to staging

we can revert or unstage a file by using git rm –cached filename

this will move file from staging to working directory. after moving to working directory we can add the file .gitignore

ignore files that already exist on the repository.

if you want to remove the files that already exist in our repository we have to follow below steps

Method: 1

Copy the files which you want to ignore to a temporary folder

Remove them from you project folder or repository.

Commit the changes which remove those files from the repository

Re-added those files to my project folder

Method: 2

ignore with below command

git update-index –assume-unchanged <file>

If you wanna start tracking changes again

git update-index –no-assume-unchanged <file>

• git ignore folder
• multiple gitignore files
• git ignore file command
• git exclude file from commit
• how to ignore the files in git
• gitignore file not working
• gitignore not ignoring file
• git ignore untracked files

Git Branching - Branches in a Nutshell

 What is Git?, Git doesn’t store data as a series of changesets or differences, but instead as a series of snapshots.

When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged. This object also contains the author’s name and email address, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.

To visualize this, let’s assume that you have a directory containing three files, and you stage them all and commit. Staging the files computes a checksum for each one (the SHA-1 hash we mentioned in What is Git?), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area:

$ git add README test.rb LICENSE
$ git commit -m 'Initial commit'

When you create the commit by running git commit, Git checksums each subdirectory (in this case, just the root project directory) and stores them as a tree object in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.

Your Git repository now contains five objects: three blobs (each representing the contents of one of the three files), one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata.

If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it.

A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you start making commits, you’re given a master branch that points to the last commit you made. Every time you commit, the master branch pointer moves forward automatically.

Note: The “master” branch in Git is not a special branch. It is exactly like any other branch. The only reason nearly every repository has one is that the git init command creates it by default and most people don’t bother to change it.

Creating a New Branch

What happens when you create a new branch? Well, doing so creates a new pointer for you to move around. Let’s say you want to create a new branch called testing. You do this with the git branch command:

$ git branch testing

This creates a new pointer to the same commit you’re currently on.

How does Git know what branch you’re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you’re currently on. In this case, you’re still on master. The git branch command only created a new branch — it didn’t switch to that branch.

You can easily see this by running a simple git log command that shows you where the branch pointers are pointing. This option is called --decorate.

$ git log --oneline --decorate
f30ab (HEAD -> master, testing) Add feature #32 - ability to add new formats to the central interface
34ac2 Fix bug #1328 - stack overflow under certain conditions
98ca9 Initial commit

You can see the master and testing branches that are right there next to the f30ab commit.

Switching Branches

To switch to an existing branch, you run the git checkout command. Let’s switch to the new testing branch:

$ git checkout testing

This moves HEAD to point to the testing branch.

What is the significance of that? Well, let’s do another commit:

$ vim test.rb
$ git commit -a -m 'made a change'

This is interesting, because now your testing branch has moved forward, but your master branch still points to the commit you were on when you ran git checkout to switch branches. Let’s switch back to the master branch:

$ git checkout master

Note: git log doesn’t show all the branches all the time. If you were to run git log right now, you might wonder where the "testing" branch you just created went, as it would not appear in the output. The branch hasn’t disappeared; Git just doesn’t know that you’re interested in that branch and it is trying to show you what it thinks you’re interested in. In other words, by default, git log will only show commit history below the branch you’ve checked out. To show commit history for the desired branch you have to explicitly specify it: git log testing. To show all of the branches, add --all to your git log command.

That command did two things. It moved the HEAD pointer back to point to the master branch, and it reverted the files in your working directory back to the snapshot that master points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you’ve done in your testing branch so you can go in a different direction.

Note: Switching branches changes files in your working directory. It’s important to note that when you switch branches in Git, files in your working directory will change. If you switch to an older branch, your working directory will be reverted to look like it did the last time you committed on that branch. If Git cannot do it cleanly, it will not let you switch at all. Let’s make a few changes and commit again:

$ vim test.rb
$ git commit -a -m 'made other changes'

Now your project history has diverged (see Divergent history). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you’re ready. And you did all that with simple branch, checkout, and commit commands.

You can also see this easily with the git log command. If you run git log --oneline --decorate --graph --all it will print out the history of your commits, showing where your branch pointers are and how your history has diverged.

$ git log --oneline --decorate --graph --all
* c2b9e (HEAD, master) Made other changes
| * 87ab2 (testing) Made a change
|/
* f30ab Add feature #32 - ability to add new formats to the central interface
* 34ac2 Fix bug #1328 - stack overflow under certain conditions
* 98ca9 initial commit of my project

Because a branch in Git is actually a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline).

This is in sharp contrast to the way most older VCS tools branch, which involves copying all of the project’s files into a second directory. This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. Also, because we’re recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. These features help encourage developers to create and use branches often.

Let’s see why you should do so.

Note: Creating a new branch and switching to it at the same time. It’s typical to create a new branch and want to switch to that new branch at the same time — this can be done in one operation with git checkout -b <newbranchname>.

Note: From Git version 2.23 onwards you can use git switch instead of git checkout to:

• Switch to an existing branch: git switch testing-branch.
• Create a new branch and switch to it: git switch -c new-branch. The -c flag stands for create, you can also use the full flag: --create.
• Return to your previously checked out branch: git switch -.

PULL Request through Command Line.

You can see the README files below which contains a typo. The README file has the word "contain" misspelled as "containnns". The owner of this repository is MNALO, and Olivia is the collaborator. She will solve the error and submit a PULL Request You'll see the process for making a PULL Request through a particular example given below.

In the file above, you can see a typo in the word "containnns".

1. Fork the Repository.

• "The "Fork" is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project."(Source)

2. Open your bash in your computer.

• You need to move to the required path or folder by using the cd command, and the content can be viewed by using the ls command, which will list all of the present files in the directory and in our case you can see the 'README.md' is present.

3. Make a new branch.

• You can create a new branch by using the git checkout -b 'branch_name'. In the above code, '-b' flag is used to create a new branch, and 'branch_name' is used to give the branch a specific name, and with checkout, the branch is switched to the newly created branch.

4. Make a change by using vim from bash or direct replacement from the original README file.

• You can change the word "containnns" to "contains" in the README file, and the changes with the current status can be viewed by using the following command.

• 5. Adding and Committing a file to the repository.
• You need to add and commit by the following commands.

• 6. Push the repository to the GitHub.
• You need to push the content by git push origin 'branch_name'
• In the above code, the origin is the remote repository, and 'branch_name' is the required branch that you need to upload your local content.

• 7. PULL request for a specific branch on GitHub.
• You can move to your repository in GitHub and see that there is a new branch.
• You can now move to step 8, but there is a need for a local repository update with the upstream repository, read this detailed blog on How To Create a Pull Request on GitHub
• Alternatively, you can do git pull-request in the command line and complete the PULL Request to GitHub, where it will force push your current branch to a remote repository.

• 8. Open a Pull request
• You need to click the button on "Create pull request," to finish the action.

Deleting a Branch after the PULL Request is Merged.

• You need to move to the main page of the repository and click "Pull requests".

• You need to click 'Closed' to see the lists of all the PULL Requests that you've made, but there is only one at the moment which needs to be selected. It is the one related to your branch that you want to delete.

• You can now click 'Delete branch' to complete the action.

The owner of the repository can view all the commits, pull request, etc., made by collaborators and others. The changes made by someone can be significant, quick fixes for a bug, errors, etc., and are added to the project.

• The owner now clicks "Merge pull request". Also, he/she will click "Confirm merge" through the following process.

• The last change made to the README.md file with a corrected typo is below.