* Tips for different workflows/use cases
@ 2008-02-03 15:08 Guilhem Bonnefille
2008-02-03 21:49 ` Dmitry Potapov
0 siblings, 1 reply; 2+ messages in thread
From: Guilhem Bonnefille @ 2008-02-03 15:08 UTC (permalink / raw)
To: Git List
Hi,
<my_life>
Up to recently, I used Git as a frontend to many SVN repo. The
workflow is simple: a central SVN and a single "client" desktop.
Now, I started to use Git at office. So I "discover" new problems and
my actual experience is not enougth.
</my_life>
Actually, I discovered two(/three) use cases for which I'm looking the
best (recommended) workflows. My idea is to identify the best
practices to avoid (as possible) complex situations.
1- The same developer uses two repo on two network connected computers.
For any reason, a developer has to work on two computers for the same
project. He sometimes hack on both computers. He uses two git
repositories to keep it work in sync. Note: the two computers are
connected, and the developer can pull/push via ssh.
So, what is the best practices:
- should he decide to push/pull every time from the same repo or
should he only use the "pull" command on each repo (and never push)
- should he decide to create a third repo and use it as central repo.
2- It's a variation of the previous one. Now, one of the two computers
is a laptop. Is there any recommended practices to work with laptop?
3- Now, the two computer are not connected via network. Two possible
solutions to sync our both computers: USB disk and e-mail.
Any recommendation in this context?
I think that such recommendations must be shared on the wiki, for
example on GitWorkflows or GitFaq pages.
--
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Tips for different workflows/use cases
2008-02-03 15:08 Tips for different workflows/use cases Guilhem Bonnefille
@ 2008-02-03 21:49 ` Dmitry Potapov
0 siblings, 0 replies; 2+ messages in thread
From: Dmitry Potapov @ 2008-02-03 21:49 UTC (permalink / raw)
To: Guilhem Bonnefille; +Cc: Git List
On Sun, Feb 03, 2008 at 04:08:07PM +0100, Guilhem Bonnefille wrote:
> So, what is the best practices:
> - should he decide to push/pull every time from the same repo or
> should he only use the "pull" command on each repo (and never push)
If both computers are always online and you can connect at will then
"pull" is the simplest solution. The problem with "push" is that pushing
to the local branch of another that has the working directory attached
to it will give you not exactly what you want. The default refspec for
"push" is only suitable for pushing into a "bare" repository from where
anyone can pull. However, if you do not want to have a separate bare
repository for synchronization, you can avoid by providing suitable
refspec for push.
Let's suppose that you have two computers (computer1 and computer2),
and you can use computer1 to connect to computer2, but computer2 cannot
access to computer1.
In repository on computer1:
git remote add computer2 $COMPUTER2_URL
git config remote.computer2.push "+refs/heads/*:refs/remotes/computer1/*"
Please, note I used 'computer1' in the refspec above. It is the prefix
for local branches that will be added when they appear in the repository
on computer2. If you have only two computers then you can use 'origin'
instead of both 'computer1' and 'computer2' above, which will alow you
to use push and pull without additional arguments.
Now, you can safely push my changes from the current computer (computer1)
to computer2:
git push computer2
Then when you start working on computer2, you can either merge changes:
git merge computer1/master
or if you want to have linear history then you have to use rebase your
local changes on top of computer1
git rebase computer1/master
Note: You should never rebase changes that you published (i.e. that you
share with other peoples), because rebase re-writes history. Also, if
the first thing that you do when you change the computer is to merge
changes for another then you do not need ever use rebase and you still
will have linear history.
Now, you back on computer1, and again you can either merge changes:
git pull computer2
or rebase local changes
git pull --rebase computer2
Note:
'git pull' is equivalent 'git fetch' and 'git merge'
'git pull --rebase' is equivalent 'git fetch' and 'git rebase'
> - should he decide to create a third repo and use it as central repo.
Often it makes sense to create an extra repo. After all, disk space
is cheap and having extra backup never hurts.
>
> 2- It's a variation of the previous one. Now, one of the two computers
> is a laptop. Is there any recommended practices to work with laptop?
I suppose that laptop computer has limited online time. So, you have to
push from it. You can push easier to a central "bare" repo, or directly
to your other computer as I described above (laptop=computer1 and
server=computer2).
>
> 3- Now, the two computer are not connected via network. Two possible
> solutions to sync our both computers: USB disk and e-mail.
> Any recommendation in this context?
Sending patches by emails is good to exchange ideas or to contribute to
mainstream, but you cannot synchronize repositories in this way. If
you really want to synchronize by emails, you should send bundles (man
git-bundle). Bundles can be transfered by emails or using any other
media. Alternatively, you can have a copy of your repository on a USB
disk and synchronize with it using "pull" and "push" commands. However,
if you use a USB disk with VFAT, you should mount it with 'shortname='
'mixed' or 'winnt' on Linux.
Dmitry
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2008-02-03 21:50 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-03 15:08 Tips for different workflows/use cases Guilhem Bonnefille
2008-02-03 21:49 ` Dmitry Potapov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).