Hi-Tech Park HTML5 Tutorials

Hi-Tech Park  All Classes Video Tutorials By Bablu Ahmed at Open IT  Ltd.

Batch Name Download All Tutorials Date
Web D.D-1 Part1 Drive 22-01-16

HTML and CSS Video Tutorial

Bangladesh Skills Development Institute Web Design and Development All Classes Video Tutorials By Bablu Ahmed

Batch Name Download All Tutorials Date
Web D.D-1 Part_4 Drive 26-12-15
Web D.D-1 Part_5 Drive 29-12-15
Web D.D-1 Part_6 Drive 19-01-16
Web D.D-1 Part_7 Drive 19-01-16
Web D.D-1 Part_8 Drive 19-01-16
Web D.D-1 Part_9 Drive 27-01-16
Web D.D-1 Part_10 Drive 27-01-16
Web D.D-1 Part_11 Drive 27-01-16

Basic HTML Video Tutorials

Open IT Web Design and Development All Classes Video Tutorials By Bablu Ahmed

Batch Name Download All Tutorials Date
Web-1 part_one Drive 07-09-15
Web-2 part_one Drive 07-09-15
Web-3 part_one Drive 08-09-15
Web-2 part_two Drive 09-09-15
Web-1 part_two Drive 09-09-15
Web-1 part_three Drive 12-09-15
Web-1 part_four Drive 03-10-15
Web-1 part_five Drive 03-10-15
Web-2 part_four Drive 03-10-15
Web-1 part_six Drive 05-10-15
Web-2 part_five Drive 05-10-15
Web-1 part_seven Drive 05-10-15
Web-1 part_eight Drive 17-10-15
Web-1 positioning Drive 21-10-15
Web-3 positioning Drive 22-10-15
Web-1 submenu Drive 25-10-15

Basic Branching and Merging

Basic Branching and Merging (1)

#git branch develop: New branch create develop

#git branch: To see branch numbers and where I am like master or develop

#git checkout develop: To move develop branch

#cat style.css: To see modified code without editor.

#git merge develop master: To merge develop and master branch or copy develop branch and paste it into master.

#git branch -d develop: Delete develop branch

Basic Branching and Merging (2)

Let’s go through a simple example of branching and merging with a workflow that you might use in the real world. You’ll follow these steps:

  1. Do work on a web site.
  2. Create a branch for a new story you’re working on.
  3. Do some work in that branch.

At this stage, you’ll receive a call that another issue is critical and you need a hotfix. You’ll do the following:

  1. Switch to your production branch.
  2. Create a branch to add the hotfix.
  3. After it’s tested, merge the hotfix branch, and push to production.
  4. Switch back to your original story and continue working.

Basic Branching

First, let’s say you’re working on your project and have a couple of commits already.

A simple commit history.
Figure 3-10. A simple commit history

You’ve decided that you’re going to work on issue #53 in whatever issue-tracking system your company uses. To create a branch and switch to it at the same time, you can run the git checkout command with the -b switch:

$ git checkout -b iss53
Switched to a new branch "iss53"

This is shorthand for:

$ git branch iss53
$ git checkout iss53
To see branches numbers:
$git branch
Creating a new branch pointer.
Figure 3-11. Creating a new branch pointer

You work on your web site and do some commits. Doing so moves the iss53 branch forward, because you have it checked out (that is, your HEAD is pointing to it):

$ vim index.html
$ git commit -a -m 'added a new footer [issue 53]'
The iss53 branch has moved forward with your work.
Figure 3-12. The iss53 branch has moved forward with your work

Now you get the call that there is an issue with the web site, and you need to fix it immediately. With Git, you don’t have to deploy your fix along with the iss53 changes you’ve made, and you don’t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your master branch.

However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you’re checking out, Git won’t let you switch branches. It’s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we’ll cover later on, in Section 7-3. For now, let’s assume you’ve committed all your changes, so you can switch back to your master branch:

$ git checkout master
Switched to branch 'master'

At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. This is an important point to remember: when you switch branches, Git resets your working directory to look like it did the last time you committed on that branch. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it.

Next, you have a hotfix to make. Let’s create a hotfix branch on which to work until it’s completed:

$ git checkout -b hotfix
Switched to a new branch 'hotfix'
$ vim index.html
$ git commit -a -m 'fixed the broken email address'
[hotfix 1fb7853] fixed the broken email address
 1 file changed, 2 insertions(+)
Hotfix branch based on `master`.
Figure 3-13. Hotfix branch based on master

You can run your tests, make sure the hotfix is what you want, and merge it back into your masterbranch to deploy to production. You do this with the git merge command:

$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
 index.html | 2 ++
 1 file changed, 2 insertions(+)

You’ll notice the phrase “fast-forward” in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you’re on, Git simply moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit’s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together – this is called a “fast-forward.”

Your change is now in the snapshot of the commit pointed to by the master branch, and you can deploy the fix.

`master` is fast-forwarded to `hotfix`.
Figure 3-14. master is fast-forwarded to hotfix

After your super-important fix is deployed, you’re ready to switch back to the work you were doing before you were interrupted. However, first you’ll delete the hotfix branch, because you no longer need it – the master branch points at the same place. You can delete it with the -d option to git branch:

$ git branch -d hotfix
Deleted branch hotfix (3a0874c).

Now you can switch back to your work-in-progress branch on issue #53 and continue working on it.

$ git checkout iss53
Switched to branch "iss53"
$ vim index.html
$ git commit -a -m 'finished the new footer [issue 53]'
[iss53 ad82d7a] finished the new footer [issue 53]
1 file changed, 1 insertion(+)
Work continues on `iss53`.
Figure 3-15. Work continues on iss53

It’s worth noting here that the work you did in your hotfix branch is not contained in the files in youriss53 branch. If you need to pull it in, you can merge your master branch into your iss53 branch by running git merge master, or you can wait to integrate those changes until you decide to pull theiss53 branch back into master later.

Basic Merging

Suppose you’ve decided that your issue #53 work is complete and ready to be merged into yourmaster branch. In order to do that, you’ll merge your iss53 branch into master, much like you merged your hotfix branch earlier. All you have to do is check out the branch you wish to merge into and then run the git merge command:

$ git checkout master
Switched to branch 'master'
$ git merge iss53
Merge made by the 'recursive' strategy.
index.html |    1 +
1 file changed, 1 insertion(+)

This looks a bit different than the hotfix merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you’re on isn’t a direct ancestor of the branch you’re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two.

Three snapshots used in a typical merge.
Figure 3-16. Three snapshots used in a typical merge

Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it. This is referred to as a merge commit, and is special in that it has more than one parent.

A merge commit.
Figure 3-17. A merge commit

It’s worth pointing out that Git determines the best common ancestor to use for its merge base; this is different than older tools like CVS or Subversion (before version 1.5), where the developer doing the merge had to figure out the best merge base for themselves. This makes merging a heck of a lot easier in Git than in these other systems.

Now that your work is merged in, you have no further need for the iss53 branch. You can close the ticket in your ticket-tracking system, and delete the branch:

$ git branch -d iss53

Basic Merge Conflicts

Occasionally, this process doesn’t go smoothly. If you changed the same part of the same file differently in the two branches you’re merging together, Git won’t be able to merge them cleanly. If your fix for issue #53 modified the same part of a file as the hotfix, you’ll get a merge conflict that looks something like this:

$ git merge iss53
Auto-merging index.htmlCONFLICT (content): Merge conflict in index.htmlAutomatic merge failed; fix conflicts and then commit the result.

Git hasn’t automatically created a new merge commit. It has paused the process while you resolve the conflict. If you want to see which files are unmerged at any point after a merge conflict, you can rungit status:

$ git status
On branch masterYou have unmerged paths.  (fix conflicts and run "git commit")Unmerged paths:  (use "git add ..." to mark resolution)    both modified:      index.htmlno changes added to commit (use "git add" and/or "git commit -a")

Anything that has merge conflicts and hasn’t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this:

div id="footer">contact : email.support@github.com/div>
div id="footer">
 please contact us at support@github.com
>>>>>>> iss53:index.html

This means the version in HEAD (your master branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the =======), while the version in your iss53 branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this:

div id="footer">
please contact us at email.support@github.com

This resolution has a little of each section, and the , =======, and >>>>>>> lines have been completely removed. After you’ve resolved each of these sections in each conflicted file, run git add on each file to mark it as resolved. Staging the file marks it as resolved in Git.

If you want to use a graphical tool to resolve these issues, you can run git mergetool, which fires up an appropriate visual merge tool and walks you through the conflicts:

$ git mergetool

This message is displayed because 'merge.tool' is not configured.See 'git mergetool --tool-help' or 'git help config' for more details.'git mergetool' will now attempt to use one of the following tools:opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emergeMerging:index.htmlNormal merge conflict for 'index.html':  {local}: modified file  {remote}: modified fileHit return to start merge resolution tool (opendiff):

If you want to use a merge tool other than the default (Git chose opendiff in this case because the command was run on a Mac), you can see all the supported tools listed at the top after “one of the following tools.” Just type the name of the tool you’d rather use.


If you need more advanced tools for resolving tricky merge conflicts, we cover more on merging inSection 7-8.

After you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you. You can run git status again to verify that all conflicts have been resolved:

$ git status
On branch masterAll conflicts fixed but you are still merging.  (use "git commit" to conclude merge)Changes to be committed:    modified:   index.html

If you’re happy with that, and you verify that everything that had conflicts has been staged, you can typegit commit to finalize the merge commit. The commit message by default looks something like this:

Merge branch 'iss53'Conflicts:    index.html## It looks like you may be committing a merge.
# If this is not correct, please remove the file
# and try again.

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.# On branch master
# All conflicts fixed but you are still merging.
## Changes to be committed:
#	modified:   index.html

You can modify that message with details about how you resolved the merge if you think it would be helpful to others looking at this merge in the future – why you did what you did, if it’s not obvious.



In your github fork, you need to keep your master branch clean, by clean I mean without any changes, like that you can create at any time a branch from your master. Each time, that you want to commit a bug or a feature, you need to create a branch for it, which will be a copy of your master branch.

When you do a pull request on a branch, you can continue to work on another branch and make another pull request on this other branch.

Before creating a new branch pull the changes from upstream, your master needs to be up to date.

Create the branch on your local machine and switch in this branch :

$ git checkout -b [name_of_your_new_branch]

Push the branch on github :

$ git push origin [name_of_your_new_branch]

When you want to commit something in your branch, be sure to be in your branch.

You can see all branches created by using :

$ git branch

Which will show :

* approval_messages

Add a new remote for your branch :

$ git remote add [name_of_your_remote]

Push changes from your commit into your branch :

$ git push origin [name_of_your_remote]

Update your branch when the original branch from official repository has been updated :

$ git fetch [name_of_your_remote]

Then you need to apply to merge changes, if your branch is derivated from develop you need to do :

$ git merge [name_of_your_remote]/develop

Delete a branch on your local filesystem :

$ git branch -d [name_of_your_new_branch]

To force the deletion of local branch on your filesystem :

$ git branch -D [name_of_your_new_branch]

Delete the branch on github :

$ git push origin :[name_of_your_new_branch]

The only difference is the : to say delete, you can do it too by using github interface to remove branch : https://help.github.com/articles/deleting-unused-branches.

If you want to change default branch, it’s so easy with github, in your fork go into Admin and in the drop-down list default branch choose what you want.

GIT Flow


To initialize a new repo with the basic branch structure, use:

    git flow init [-d]

This will then interactively prompt you with some questions on which branches you would like to use as development and production branches, and how you would like your prefixes be named. You may simply press Return on any of those questions to accept the (sane) default suggestions.

The -d flag will accept all defaults.

Creating feature/release/hotfix/support branches

  • To list/start/finish feature branches, use:
    git flow feature
    git flow feature start <name> [<base>]
    git flow feature finish <name>

    For feature branches, the <base> arg must be a commit on develop.

  • To push/pull a feature branch to the remote repository, use:
    git flow feature publish <name>
      git flow feature pull <remote> <name>
  • To list/start/finish release branches, use:
    git flow release
    git flow release start <release> [<base>]
    git flow release finish <release>

    For release branches, the <base> arg must be a commit on develop.

  • To list/start/finish hotfix branches, use:
    git flow hotfix
    git flow hotfix start <release> [<base>]
    git flow hotfix finish <release>

    For hotfix branches, the <base> arg must be a commit on master.

  • To list/start support branches, use:
    git flow support
    git flow support start <release> <base>

    For support branches, the <base> arg must be a commit on master.

Showing your appreciation

How to start git repository

Adding an existing project to GitHub using the command line (1)

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenientstaging areas, and multiple workflows.

Learn Git in your browser for free with Try Git.

GIT Download

Quick setup — if you’ve done this kind of thing before:

…or create a new repository on the command line

echo # myproject >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin https://github.com/bablukpik/myproject.git
git push -u origin master

…or push an existing repository from the command line

git remote add origin https://github.com/bablukpik/myproject.git
git push -u origin master

…or import code from another repository

You can initialize this repository with code from a Subversion, Mercurial, or TFS project.

Import code


Adding an existing project to GitHub using the command line (2)

Putting your existing work on GitHub can let you share and collaborate in lots of great ways.

Tip: If you’re most comfortable with a point-and-click user interface, try adding your project with one of our desktop applications. For more information, see “How do I add repositories?” for Mac, and “Adding repositories with GitHub for Windows” for Windows.

Warning: Never git add, commit, or push sensitive information to a remote repository. Sensitive information can include, but is not limited to:

  • Passwords
  • SSH keys
  • AWS access keys
  • API keys
  • Credit card numbers
  • PIN numbers

For more information, see “Remove sensitive data.”

  1. Create New Repository drop-down Create a new repository on GitHub. To avoid errors, do not initialize the new repository with README, license, or gitignore files. You can add these files after your project has been pushed to GitHub.
  2. Open Terminal (for Mac users) or the command prompt (for Windows and Linux users).
  3. Change the current working directory to your local project.
  4. Initialize the local directory as a Git repository.
    git init
  5. Add the files in your new local repository. This stages them for the first commit.
    git add .
    # Adds the files in the local repository and stages them for commit. To unstage a file, use 'git reset HEAD YOUR-FILE'.
  1. Commit the files that you’ve staged in your local repository.
    git commit -m 'First commit'
    # Commits the tracked changes and prepares them to be pushed to a remote repository. To remove this commit and modify the file, use 'git reset --soft HEAD~1' and commit and add the file again.
  1. Copy remote repository URL fieldAt the top of your GitHub repository’s Quick Setup page, click to copy the remote repository URL.
  2. In the Command prompt, add the URL for the remote repository where your local repository will be pushed.
    git remote add origin remote repository URL
    # Sets the new remote
    git remote -v
    # Verifies the new remote URL
  3. Push the changes in your local repository to GitHub.
    git push origin master
    # Pushes the changes in your local repository up to the remote repository you specified as the origin
%d bloggers like this: