I'm getting reintroduced to git. I'm not that familiar with rebasing, and I want to start using it.
The team I'm working with does not allow commits into our master branch. We have to create a feature branch and then create a Pull Request.
When I'm the only person working on a feature branch, I'd like to keep my feature branches up to date with master, and I want my commits to be tacked on at the end before I create my pull request.
So, my plan is to work away on my feature branch and periodically rebase with (on?) master. Will that keep all of my commits at the end of the change history when I'm ready to submit my pull request?
Rebasing a branch on another "re-applies" (fairly smartly, these days) the commits of the currently checked out branch on top of the tip of the target.
So, yes, if you do it over and over again then you will keep your current branch up to date. I think it's a typo in the question, but you do not want to "rebase master" though, you want to rebase on master.
Sometimes, you might get a lot of conflicts, in which case you probably should rather think about merging from this particular point on. Conflict resolution while rebasing is quite a pain since you have to fix the conflicts from the first commit onwards: the very first merge you will do will create conflicts if further commits modify the same piece of code, and so on and so fort. With a merge you fix all of them at once. But them, once you merge you have to keep on merging.