Project Management for Professional Ionic Applications
Tools, techniques, and processes to manage a professional grade project
Merging with Pull Requests
A more formal approach to merging your code
PROModule Outline
- Source Code & Resources PRO
- Lesson 1: Introduction PUBLIC
- Lesson 2: The Agile Methodology PUBLIC
- Lesson 3: Project Planning PUBLIC
- Lesson 4: Initial Client Meeting PRO
- Lesson 5: Planning and Prototyping PRO
- Lesson 6: Diagrams and Documentation PRO
- Lesson 7: User Stories PRO
- Lesson 8: Project Management Overview PRO
- Lesson 9: Setting up the Project PRO
- Lesson 10: Continuous Integration PRO
- Lesson 11: Cypress Dashboard PRO
- Lesson 12: Continuous Deployment PRO
- Lesson 13: A Change Request PRO
- Lesson 14: Planning the First Sprint PRO
- Lesson 15: Merging with Pull Requests PRO
- Lesson 16: Configuring CI for Firebase PRO
- Lesson 17: Sprint One Review PRO
- Lesson 18: Sprint Two Review PRO
- Lesson 19: Sprint Three Review PRO
- Lesson 20: Conclusion PRO
Lesson Outline
Merging with Pull Requests
If you have been following along with the application build, then you will currently be at a point where you have some work in a branch that you are ready to finish and get merged back into the main branch. So far, we have just been manually merging into the main branch with the git merge
command. In this lesson, we are going to look at a more formal alternative: the pull request.
First of all, we are going to need to make sure we have that work we just completed committed and pushed to our remote branch:
git add .
git commit -m "chore: closes #31 set up firebase dev environment"
git push
Remember, this ideally would not be the first time you push to the remote branch. When and how often you push back to the remote branch comes down to personal/team preference, but it is generally a good idea to commit/push for each "thing" you do, or when you're going on your lunch break, or whenever. In general, prefer more commits/pushes over fewer - do what works for you but don't be shy. Work doesn't need to be "finished" or in a nice clean state for you to push to your remote branch, that is part of the reason behind using task branching in the first place. If your commits are "messy" or don't have nice commit messages because you were pushing all the time, these can always be cleaned up with other Git commands before completing your work. Even if you don't know how to use more advanced Git commands, more/messier commits are still going to be better overall than just committing everything all at once.
This is the list of commits I made for this particular task:
wip: #31 setting up firebase
chore: closes #31 set up firebase dev environment
This was a relatively small chunk of work, so I just have one intermediary commit and then the final commit. As you can see, these are quite nicely formatted, however, sometimes you don't want to dedicate the brain power to writing proper commit messages during work. It is totally fine to just do something like this:
add firebase
set up unit tests
fix bug with tests
fix again
still doesnt work
fixed test
chore: closes #31 set up firebase dev environment
Then if you like you can do an interactive rebase with Git to clean up these commit messages/squash them together, but if you don't know how to do that then, again, I still think the above is preferable to not committing frequently.
Thanks for checking out the preview of this lesson!
You do not have the appropriate membership to view the full lesson. If you would like full access to this module you can view membership options (or log in if you are already have an appropriate membership).