Question: I am new to git and would like to understand what would happen in the following scenario. I have the following branches:

1. Master Branch (currently deployed to Prod)
2. Enhancement #1 - CleanupUntrackedFiles Branch: This was spawned off of Master. I made updates to the gitignore file to not include particular extensions in my repo and I removed those unnecessary files from the repo.
3. Enhancement #2: This was ALSO created off of Master. Code updates are in support of a customer request.

At this point I would like to deliver BOTH Enhancement #1 and #2 into production. Is the best approach to merge these 2 branches together before merging with Master? If that is the case, how would Git know that I would like the files that I removed from Enhancement #1 to stay removed? Would the merge request of Enhancement 2 into Enhancement 1 bring in those old files again since Enhancement #2 was created off of the Master branch?

Thanks in advance for your help.

Answer: 
According to the [GitHub documentation](https://docs.github.com/en/developers/apps/scopes-for-oauth-apps#available-scopes), the scope for public repositories is `public_repo`, and for private repositories is `repo`.

A token with one of those scopes is the most limited access possible for Git push or pull access; however, that token can access all public (respectively, private) repositories and can also be used for certain API access as well. If that's of concern to you, you can use an SSH key for your personal account, or to restrict it even further, a read-write deploy key for the repo in question.
Although it's been two years since the question was asked, there is now a solution from GitHub.

GitHub recently introduced a new feature called "fine-grained personal access tokens".
<https://github.blog/2022-10-18-introducing-fine-grained-personal-access-tokens-for-github>

> 
> **Personal access tokens** (classic) are given permissions from a broad set of read and write scopes. **They have access to all of the repositories and organizations that the user could access**, and are allowed to live forever. As an example, the repo scope provides broad access to all data in private repositories the user has access to, in perpetuity.
> 
> 
> 

> 
> **Fine-grained personal access tokens**, by contrast, are given permissions from a set of over 50 granular permissions that control access to GitHub’s organization, user, and repository APIs. Each permission can be granted on a ‘no access’, ‘read’ or ‘read and write’ basis. As an example, you can now create a PAT that can only read issues and do nothing else – not even read the contents of a repository.
> 
> 
>