Android pdf viewer

Following link have very good implementation of MU PDF android library

https://github.com/tekinarslan/AndroidPdfViewer

Git Rebase example

Following tutorial will show how to do git rebase.
This tutorial explain what is rebase first and then it will give demo steps of rebasing.

Explanation of rebase
Reference : https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase

git rebase

Rebasing is the process of moving a branch to a new base commit. The general process can be visualized as the following:

From a content perspective, rebasing really is just moving a branch from one commit to another. But internally, Git accomplishes this by creating new commits and applying them to the specified base—it’s literally rewriting your project history. It’s very important to understand that, even though the branch looks the same, it’s composed of entirely new commits.

Usage

git rebase <base>

Rebase the current branch onto <base>, which can be any kind of commit reference (an ID, a branch name, a tag, or a relative reference to HEAD).

Discussion

The primary reason for rebasing is to maintain a linear project history. For example, consider a situation where the master branch has progressed since you started working on a feature:

You have two options for integrating your feature into the masterbranch: merging directly or rebasing and then merging. The former option results in a 3-way merge and a merge commit, while the latter results in a fast-forward merge and a perfectly linear history. The following diagram demonstrates how rebasing onto master facilitates a fast-forward merge.

Rebasing is a common way to integrate upstream changes into your local repository. Pulling in upstream changes with git merge results in a superfluous merge commit every time you want to see how the project has progressed. On the other hand, rebasing is like saying, “I want to base my changes on what everybody has already done.”

Don’t Rebase Public History

As we’ve discussed with git commit --amend and git reset, you should never rebase commits that have been pushed to a public repository. The rebase would replace the old commits with new ones, and it would look like that part of your project history abruptly vanished.

Examples

The example below combines git rebase with git merge to maintain a linear project history. This is a quick and easy way to ensure that your merges will be fast-forwarded.

# Start a new feature
git checkout -b new-feature master
# Edit files
git commit -a -m "Start developing a feature"

In the middle of our feature, we realize there’s a security hole in our project

# Create a hotfix branch based off of master
git checkout -b hotfix master
# Edit files
git commit -a -m "Fix security hole"
# Merge back into master
git checkout master
git merge hotfix
git branch -d hotfix

After merging the hotfix into master, we have a forked project history. Instead of a plain git merge, we’ll integrate the feature branch with a rebase to maintain a linear history:

git checkout new-feature
git rebase master

This moves new-feature to the tip of master, which lets us do a standard fast-forward merge from master:

git checkout master
git merge new-feature

----------------------------------------------------------------------
Demo

Our purpose of demo

Lets say we have following branches.

master:
at first launch master branch have base setup of our project.

module1:
suppose developer 1 worked on module 1. and merge it with master. so master have base setup and module1

module2:
suppose developer 2 worked on module 2. and merge it with master. so master have base setup and module1 and module2



As a result when both developer complete work on module 1 and module 2 we want master branch have both module and module1 and module2 have it's change seperatly.
------------------------------
Steps to achieve it

Lets init git. in Windows open git-bash or in Linux open terminal

1 : cd <your demo folder path>
2 : git init : it will init git in above given folder
3 : In master branch : let's create file named "base-setup.txt" and commit it by these commands. git add -A, git commit -m "base setup in master"
4 : Checkout new branch module1 and add some module 1 file or modify required file and commit changes of module1 branch. we may need following commands.
    git checkout -B module1.
    after this do your work.
    when work completed then use following commands to commit changes in module1 branch.
    git add -A and git commit -m "module1 completed" commands

5 : Lets merge module 1 with master.
    git checkout master
    git rebase module1.
    now if there is conflict then open that file in editor and resolve conflict manually. and run git add -A to resolve that conflict.
    After resolve conflict run "git rebase --continue"
    Now you can check that master have its own files as well as module1's file.
6 : Now follow step 4 and 5 for module2 branch.
7 : After these you can see master have module1 and module2 changes. module1 have only its files. module2 also have only its file.

Conculation : We can use rebase for module management. We can also use this for version management i.e. version 1 have some feature, version 2 have some other feature while master have all feature.