Git workflow overview

Git workflow overview

[Ludovic Courtès]

Hi,

Just to clarify things, the following illustrates the typical Git
workflow.

First, we need to get a copy of the repository:

  $ git-clone ssh://SAVANNAH-ACCOUNT@git.sv.gnu.org/srv/git/guile.git
  $ cd guile

Then, imagine we want to fix something both in HEAD and 1.8.  We are
currently in `master' (the equivalent of HEAD), and it is the only
branch that we currently have:

  $ git-branch
  * master

Eventually, we'll want to do things in the `branch_release-1-8' branch
as well, so we need to create a local branch tracking the
`branch_release-1-8' branch at Savannah:

  $ git-branch --track branch_release-1-8 origin/branch_release-1-8
  Branch branch_release-1-8 set up to track remote branch refs/remotes/origin/branch_release-1-8.

We now have the two branches:

  $ git-branch 
    branch_release-1-8
  * master

We want to commit our fix to `master', then push it to the Savannah
repo's `master' branch (after making sure that we are up-to-date), then
to apply it to the 1.8 branch and push it:

    # hack the thing...
  $ git-commit -a -m "The fix."
  $ git-pull                # Check whether we're up-to-date.
  $ git-push
  $ git-checkout branch_release-1-8
  $ git-pull                # Update.
  $ git-cherry-pick master  # Apply the change we made in `master'.
    # fix any conflicts...
  $ git-push                # Push the change to `branch_release-1-8'.

That gives a rough overview of the thing.  For larger changes, it will
be better to use a separate branch locally, using `git-rebase' right
before merging it, etc.  There are surely good tutorials at
http://git.or.cz/ .

Enjoy!

Ludo'.

Re: Git workflow overview

[Han-Wen Nienhuys]

Ludovic Courtès escreveu:
>     # hack the thing...
>   $ git-commit -a -m "The fix."
>   $ git-pull                # Check whether we're up-to-date.
>   $ git-push
>   $ git-checkout branch_release-1-8
>   $ git-pull                # Update.
>   $ git-cherry-pick master  # Apply the change we made in `master'.
>     # fix any conflicts...
>   $ git-push                # Push the change to `branch_release-1-8'.

The dashed forms are being deprecated, so it should be 

  git commit 
  git pull


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: Git workflow overview

[Ludovic Courtès]

Hi,

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> The dashed forms are being deprecated

Really?  I always thought it was the other way round.  :-)

Thanks,
Ludovic.

Re: Git workflow overview

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Just to clarify things, the following illustrates the typical Git
> workflow.

Thanks, this has been very useful; and thanks also for getting the Git
repository up and running!

Now, what am I doing wrong here?  I've created a load of new
.gitignore files, and tried to push them to Savannah's master and
1.8.x branches.  The push to master looks good, but the push to 1.8.x
does nothing:

(We start off on my 1.8.x, whose remote is Savannah's
branch_release-1-8.  I've created and added all the new files, and
committed them to my local 1.8.x.  Then...)

neil@arudy:~/Organized/SW/Guile/guile-git$ git pull
Already up-to-date.
neil@arudy:~/Organized/SW/Guile/guile-git$ git push
Everything up-to-date
neil@arudy:~/Organized/SW/Guile/guile-git$ git checkout -b master
git checkout: branch master already exists

(At this point I did "git checkout master" in another window, so now
we're moving to my local master.)

neil@arudy:~/Organized/SW/Guile/guile-git$ git pull
Already up-to-date.
neil@arudy:~/Organized/SW/Guile/guile-git$ git cherry-pick 1.8.x
Auto-merged .gitignore
CONFLICT (add/add): Merge conflict in .gitignore
Automatic cherry-pick failed.  After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result.
When commiting, use the option '-c fbab080' to retain authorship and message.

(...Edited .gitignore to resolve the conflict...)

neil@arudy:~/Organized/SW/Guile/guile-git$ git push
Counting objects: 82, done.
Compressing objects: 100% (42/42), done.
Writing objects: 100% (47/47), 6.42 KiB, done.
Total 47 (delta 31), reused 0 (delta 0)
To ssh://ossau@git.sv.gnu.org/srv/git/guile.git
   f2060a5..b0ea37d  master -> master

(Now I try switching back to 1.8.x, to see if it might have changed
its mind...)

neil@arudy:~/Organized/SW/Guile/guile-git$ git checkout 1.8.x
Switched to branch "1.8.x"
neil@arudy:~/Organized/SW/Guile/guile-git$ git push
Everything up-to-date

(It hasn't.)

Yours waiting for enlightenment....!

      Neil

Re: Git workflow overview

[Ludovic Courtès]

Hi Neil,

Neil Jerram <neil@ossau.uklinux.net> writes:

> Now, what am I doing wrong here?  I've created a load of new
> .gitignore files, and tried to push them to Savannah's master and
> 1.8.x branches.  The push to master looks good, but the push to 1.8.x
> does nothing:

I had similar troubles when using a local branch name different from
`branch_release-1-8': somehow, Git doesn't memorize the branch name
mapping for push.

The easy fix, of course, it to name local branches like remote
branches---which is what I did, because I was lazy.

The "real" fix involves `.git/config' magic (or `.git/remotes', or
`.git/branches'), to tell Git about the name of the remote branch where
it should push.  git-push(1) mentions several possibilities, but I
haven't tried them.

Alternatively, "git-push origin 1.8.x:branch_release-1-8" should work,
but I haven't tried either.

Maybe you could tell us which trick works best?  :-)


BTW, regarding `.gitignore', it's possible to use glob patterns, like
"*.x", "*.doc", "*.lo", etc.

Thanks,
Ludo'.

Re: Git workflow overview

[Neil Jerram]

Hi Ludo,

ludo@gnu.org (Ludovic Courtès) writes:

> The easy fix, of course, it to name local branches like remote
> branches---which is what I did, because I was lazy.

Thanks very much, that's what I did too, and all is working now.

> The "real" fix involves `.git/config' magic (or `.git/remotes', or
> `.git/branches'), to tell Git about the name of the remote branch where
> it should push.  git-push(1) mentions several possibilities, but I
> haven't tried them.
>
> Alternatively, "git-push origin 1.8.x:branch_release-1-8" should work,
> but I haven't tried either.
>
> Maybe you could tell us which trick works best?  :-)

Something for another day, perhaps.  Right now I'm quite deep into
solving the "make check" crashes that have been reported on IA64, so I
want to concentrate on that as much as possible.

> BTW, regarding `.gitignore', it's possible to use glob patterns, like
> "*.x", "*.doc", "*.lo", etc.

Indeed, and I also realize now that .gitignore entries also apply to
subdirectories.  Taking that into account, I've just committed a much
smaller set of .gitignore's to branch_release-1-8 than I did to
master, and I'll aim in the next few days to rationalize the
.gitignore's in master.

> Thanks,
> Ludo'.

Regards,
     Neil