Git workflow

Git workflow

[Filipp Gunbin]

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
  with `='.

- 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
  <commit>'

Yes, emacs inside emacs!  Leave first string as "pick" and change all
other from "pick" to "fixup".  Save, exit.  Git squashes commits into
one.

- 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
  version.

- 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.

Filipp

Re: Git workflow

[Andreas Schwab]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> Yes, emacs inside emacs!

What's wrong with emacsclient?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Git workflow

[Filipp Gunbin]

On 10/04/2015 08:49 +0200, Andreas Schwab wrote:

> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>
>> Yes, emacs inside emacs!
>
> What's wrong with emacsclient?

I need an interactive editor there, so it probably could be emacsclient
as well.

Filipp

Re: Git workflow

[Lars Brinkhoff]

Filipp Gunbin <fgunbin@fastmail.fm> writes:
> I need an interactive editor there, so it probably could be emacsclient
> as well.

Most likely.  I use emacsclient quite happily for git rebase -i.