[haiku-development] Re: Question about git..
- From: Ryan Leavengood <leavengood@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 19 Jul 2012 12:35:37 -0400
On Thu, Jul 19, 2012 at 12:13 PM, Fredrik Modèen <fredrik@xxxxxxxxx> wrote:
>
> Another question how do you usualy work? Having two branches or copies of
> haiku, one with changes you want to commit and one with some test and test
> patches or do you usualy work on one thing and then commit it a serial
> type of working iteration?
This is a general git workflow question, not as much specific to
Haiku, but still worth talking about.
I generally (both for my Ruby day job and for Haiku work) tend to work
on small features in master, and only branch for major changes or
potentially experimental work. Some people like to always branch,
since branching is so cheap in Git.
If I've created a set of related changes which I think are generally
useful, I'll push them up. Since the Haiku git server batches pushes
of several commits into a single "hrev" tag, I try to only push up
sets of related commits. Most other Haiku developers do similar.
If I were to be working on two fairly different bugs or features and
they were taking a while, I might do a branch for both.
Generally I have found it painful to have a bunch of uncommitted
changes since those always show up in git status and git diff. So I
would always recommend committing interim work when it is good enough,
because with git you can always edit commits either with git commit
--amend for the last commit, or with interactive rebasing:
http://schacon.github.com/history.html
If you use branches for the things you are working on, the above will
also be easier since the top commits will generally be related to
those changes.
Once you are happy with something, you just merge it into master (or
maybe use rebase) and then use git pull --rebase to pull in new
changes from the server and rebase your new ones on top, then you can
push your changes up.
--
Regards,
Ryan
Other related posts:
