[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fri, 10 Apr 2015 01:34:23 +0300
A lot of things have been said on this list about git recently.
Here I want to just make some points which make my life with git easy.
Sorry for noise if you all know this or use different workflows.
- I start working on brances by creating them with
`git checkout -b <name> origin/<remote_name>'
<remote_name> is usually "master"
This way a later `git rebase' will put commits in the current branch on
top of <remote_name>.
- Review my changes with `vc-dir' (`C-x v d') and diffing from there
- Commit periodically (every day for a long task) all changes with
`git commit -am "message"'
- Push periodically (usually right after commit) with
`git push origin <name>',
where <name> is my current branch
This is just not to lose changes if I lose my computer.
- Then, when it's time to send code for review, I look up in the root vc
log (`C-x v L') the hashtag of the commit just before my first commit
and copy it. This is needed for interactive rebase which I do to
squash all intermediate commits into one:
- open term-mode and run `EDITOR='emacs --no-desktop' git rebase -i
Yes, emacs inside emacs! Leave first string as "pick" and change all
other from "pick" to "fixup". Save, exit. Git squashes commits into
- If there is a need to fix commit message, do this:
`git commit -am "New message" --amend'
- Then, it's time to rebase:
`git fetch && git rebase'
A branch is "remote-tracking" so it knows on top of which remote branch
it is, and rebase functionality uses that knowledge. What happens is
that git fetches all new commits (on all branches) from remote, then
checks out <remote_name> and applies my commits from the current branch
on top of it.
- If I have conflicts at this point, go and resolve them: edit files
containing conflict markers (I remember somewhere in vc exists the
command to go through them one by one, but it didn't work for me),
then `git add' on each file after editing.
- After all conflicts are resolved:
`git rebase --continue'
Squashing commits into one helps to do this resolve-continue procedure
only once, otherwise rebase would stop after each conflicting commit.
- Now we are ready for push:
`git push origin <name>'
- As review goes I make changes just as before, when working on initial
- When I'm done and have a final commit, I do the most important push:
`git push origin <name>:<remote_name>'
So all my changes go to the remote branch as a single commit.
- Very-very rarely I have to merge something (when it's really a
parallel branch and not a catchup with "parent" remote branch), then I
use merge without any clever options.
- If something goes wrong I just make text patch when on a branch (`D'
in *vc-change-log*), create a new branch from scratch and apply the
patch with `patch' command.
- Git workflow,
Filipp Gunbin <=