On Thu, 16 Mar 2017 04:40:25 -0700 (PDT)
grandemund...@gmail.com wrote:
> Can the following be done within git.
>
> Make changes to a project that is not ready to be committed.
> Have a separate textile to describe. stop working on it for a while.
> When ready to be committed, I copy and paste the textfile in the
> message of the commit.
>
> Is there a git command that keep track of all the description of the
> changes. add them all up in the message when I commit.
Yes, you just need to stop thinking in terms of "how would I _not_
commit" ;-)
What you need is the idea is that 1) branches in Git are dirt-cheap,
and 2) you are not required to push a branch anywhere.
So, your workflow for such a case is:
1) Make changes to a project, decide that they are not ready to be
committed.
At this point, fork a branch off HEAD:
$ git checkout -b whatever
(Put a more sensible name than "whatever".)
Nothing has happened to your changes yet -- Git had merely recorded
the fact the HEAD now points at "whatever" and not at the branch
you had checked out.
Now add your changes and commit.
2) Check out the original branch:
$ git checkout -
Continue working.
3) Now suppose you'd like to continue messing with your "not ready
to commit" changes.
Before recording new changes on that "whatever" branch, you need
to synchronize the state of the project it tracks to the new
developments which had happened on the branch you forked it off.
To do this, you need to "rebase" your changes on top of the updated
"parent" branch. If that parent branch is called "master", you do:
$ git checkout whatever
$ git rebase master
or in one step:
$ gir rebase master whatever
(which would first check "whatever" out and then rebase it on top
of "master").
The result of this command is that your "whatever" branch now looks
just like "master" with your tempoary commits on top.
Now continue hacking away recording new temporary commits.
Repeat steps 2 and 3 until your feature is ready to "be committed" --
as you have already formulated that.
4) When you decide your changes are ready for prime time, you do the
so-called "squash merge":
$ git checkout master
$ git merge --squash whatever
$ git commit
The "--squash" option to `git merge` will make the command not record
a regular merge but:
- Collapse (squash) all the commits which are on "whatever" compared
to "master" into a single change.
- Prepare a commit message which is the concatenation of all the
commit messages of all the squashed commits.
- Exit -- allowing you to run `git commit`, edit the generated
"gross" commit message and proceed.
Delete the "whatever" branch:
$ git branch -D whatever
Executive summary ;-)
There's no need to invent anything new to handle the workflow you need:
use a separate branch which you forward-port (rebase) on top of its
"parent" branch before making new changes on it, and when what you were
developing is ready, squash-merge the result into the original branch.
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
