From 678b849bbfbff4e42bf134ce7bf1394f2f30f3ea Mon Sep 17 00:00:00 2001 From: Paul Sokolovsky Date: Tue, 8 Nov 2016 23:40:24 +0200 Subject: [PATCH] Articles/clarifications. --- DevelWorkflow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DevelWorkflow.md b/DevelWorkflow.md index 983cda7..99e1b9e 100644 --- a/DevelWorkflow.md +++ b/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.