mirrors
/
micropython
mirror of https://github.com/micropython/micropython.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Articles/clarifications.

Paul Sokolovsky 2016-11-08 23:40:24 +02:00
parent 8e1b3b0108
commit 678b849bbf
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
DevelWorkflow.md

@ -5,7 +5,7 @@ This proposes a "git rebase"/"git rebase interactive" based development workflow
It helps to keep project revision history clean and sane. For example, suppose you changed a block of code in your initial patch and submitted that as a pull request, but got a review comment that given block of code should not be changed and it should be done differently. If you just make another commit which puts original lines back, then you just added 2 noise commits to repository, not giving any value, but complicating other people's lives. For example, suppose later it was found that piece of code in question has some issue. Whoever found that, will proceed to investigate why and how it was done, and see those noise commits. And "git blame" will show you as responsible for that code, whereas you didn't really write it!
## Workflow
1. Don't do any work in "master" branch, it belongs to upstream project. Do any work in topic branches. This isn't really related to "git rebase" workflow, it's part of git best practices at all.
1. Don't do any work in "master" branch, it belongs to the upstream project. Do any work in topic branches. This isn't really related to "git rebase" workflow, it's part of version control systems best practices at all.
2. Pull upstream changes into your master branch, then propagate to your topic branch using "git rebase master".
3. When you think you've done with implementing the feature, do self-review using "git log -p master..HEAD". Watch for forgotten debug code, re-read commit messages for clarity and typos, etc.
4. If you need to do code changes, do new commits to apply small changes you need (like removing a single line with debug printf()). This better be done one by one, with rebase interactive (next step) after each such auxiliary commit, to not lose track. An alternative way to do this is to use git commit --amend which is essentially equivalent to a git commit followed by git rebase -i to squash the two commits together.