Question: I want to toDo() work App.class (AllActivity) when button clicked from other example.class.(Activity)

```
public class Otherclass extend AppCompatActivity{

    Button example = (Button)findViewById(R.id.option_language);
            example.setOnClickListener(new View.OnClickListener() {
                @Override
                public void onClick(View v) {
                    example.isChecked();
                }
            });
}

public class App extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        ToDo();
    }

    @Override
    public void onConfigurationChanged(Configuration newConfig) {
        super.onConfigurationChanged(newConfig);
        toDo();
    }

    public void toDo() {
        if(new OtherClass().example.isChecked()) {
           // To do something.
            }
        }
    }
}

```

I wanted to do it. But, I got java.lang.NullPointerException: .isChecked()' on a null object reference

Answer: 
When you say a "`master` (by convention) repo", I assume you mean (1) there's a single "source of truth" repository for the project (which is conventionally called `origin`, not `master`); (2) users/devs clone the `origin`, work in their clones, and push changes to the `origin`.

In that usage, interactions with the `origin` boil down to very few - and in fact writes to the `origin` should always just be `push`es. Things like `rebase` don't *really* occur at the `origin`; it is simply updated to see the result of those operations.

If you want any level of security or audit around the central repo, then this is the correct way to set it up. *But,* it means many of the things you're talking about, you can't directly "see". You won't know (and, honestly, shouldn't care) what commands were used to get a user's local repo into a particular state. You just know what's pushed - and any centrally-enforced rules need to be described in terms of what's pushed.

That means the useful tools are config options on `origin`, and the `pre-receive` hook (and possibly the `update` hook) on `origin` (unless you're in a hosted environment that provides a different security model).

One thing you can do is globally refuse to accept history rewrites. Then if someone rebases a branch after it's been pushed, `origin` simply won't take the push. (The user could still work on a branch, then rebase it before the first time they share it. There is nothing you can do about that, and really no good reason to care.) On the `origin` you'd set `receive.denyNonFastForwards` to `true`.

You can enforce pretty much whatever rule you want with a hook; if you can work out the necessary script. Maybe you want to enforce commit topology rules (e.g. "no non-merges in `master`" a la gitflow), or require signed commits (see below), or whatever.

If the rules are user-specific, or if you want to log potential violations instead of (or in addition to) blocking them, then authentication is a concern. Securing access to the repo - and authenticating who is accessing the repo - is not something `git` really addresses. There are several server environments for hosting git repos - like github, gitlab, TFS. Those types of server provide security options. You could also set your repo up so that the only way to reach it is through authenticated means (properly authenticated http, or ssl).

Accepting commits only if they're signed (or only if they're reachable from a signed tag) is also an option that tells you *something* about who did what, but maybe not what you want to know. (Just because I wrote and signed a commit, doesn't mean anything about who moved a ref to point to that commit and tried to push the result.)

If you can work out authentication, but can't script out detection of every rule - or maybe aren't sure what the rules need to be, but would know "bad behavior" when you see it - then simply logging the authenticated identity with the push's ref list would tell you probably everything you need to know to figure things out "after the fact".
Sounds like what you need is to set up an audit trail. It doesn't seem like there's built-in support for this in git, but you can keep a closer eye on the repo with the help of a couple of hooks. 

* Perhaps you can use one of the hooks from [git-receive-pack,](https://git-scm.com/docs/git-receive-pack) e.g. [pre-receive](https://git-scm.com/docs/githooks#pre-receive), [post-receive](https://git-scm.com/docs/githooks#post-receive), [update](https://git-scm.com/docs/githooks#update), [post-update](https://git-scm.com/docs/githooks#post-update).
* Or [pre-auto-gc](https://git-scm.com/docs/githooks#pre-auto-gc), if there is other transient state that you want to want to capture, which remains until garbage collection as @JonathanWakely wrote.