On Fri, 26 Apr 2019, 04:22 ckdev101, wrote:
>
> Here is the team make-up:
>
>- Sprint Team #1
>- Sprint Team #2
>- *Shared* DBA across teams
>- Dev. Lead (Myself)
>
> ...
>
> The problem is that the shared DBA needs to constantly and consistently
> make changes *across* teams for
proach (rather that each user having special branches
> on the master).
>
> Have you had a case of having to incoprporate incompatible code that you
> could share?
> Philip
>
> - Original Message -
>
> *Subject:* Re: [git-users] Git branching and merge strategy for merg
hilip
- Original Message -
From: Hugh Gleaves
To: Git for human beings
Cc: philipoak...@iee.org
Sent: Monday, February 06, 2017 7:46 PM
Subject: Re: [git-users] Git branching and merge strategy for merge with lots
of conflicts requiring multiple people
I suspect that you
I suspect that you are perceiving "merging" as a late, final step in the
process. This is where you are erring I think. Merging should be done
frequently, this was conflicts will not accumulate over time and grow in
scale.
Generally "merging" means incorporating changes made outside of some bra
Stephen Morton writes:
> On Thursday, 26 January 2017 16:37:16 UTC-5, Magnus Therning wrote:
>>
>>
>> Stephen Morton > writes:
>>
>> > I'm looking for a git branching and merge strategy for merge with
>> > lots of conflicts requiring multiple people. I can make it work,
>> > and I understand git
Michael writes:
>> Have you looked at git-imerge?
>
> Imerge looks like a really nice tool. How stable/sufficient is it? Why
> is it not part of the normal git distribution?
I've not had any problems with stability, but then I generally try to
avoid ending up in situations where it's needed ;)
On 2017-01-27, at 12:57 AM, Philip Oakley wrote:
>
> It doesn't happen at my work, but one has to ask how / why have we dug the
> hole so deep and wide that this gross merge conflict continues to repeat it
> self as a regular corporate activity, and then how to get out of here/there
> (and so
On Thursday, 26 January 2017 16:37:16 UTC-5, Magnus Therning wrote:
>
>
> Stephen Morton > writes:
>
> > I'm looking for a git branching and merge strategy for merge with lots
> > of conflicts requiring multiple people. I can make it work, and I
> > understand git, but it all seems kind of awkwa
cenarios, and a similar how
> and what for getting out.
>
> Philip
>
> If we don't understand, we won't improve ...
> https://store.xkcd.com/products/try-science
>
> - Original Message -
> From: "Michael"
> To:
> Sent: Friday, Janu
t.
Philip
If we don't understand, we won't improve ...
https://store.xkcd.com/products/try-science
- Original Message -
From: "Michael"
To:
Sent: Friday, January 27, 2017 12:48 AM
Subject: Re: [git-users] Git branching and merge strategy for merge with
lots o
> Have you looked at git-imerge?
Imerge looks like a really nice tool. How stable/sufficient is it? Why is it
not part of the normal git distribution?
I noticed that it was still getting dev work this month, and in the last two
years a bunch of people forked copies of it, and made their own li
On 2017-01-26, at 1:12 PM, Philip Oakley wrote:
>
> Is the project well modularised with no file >100 lines (excepting, maybe,
> well developed libraries that never change),
100 lines per file??
You're joking, right? That's one of those "in theory" things, right?
First, while I might be able
On Thursday, 26 January 2017 16:12:43 UTC-5, Philip Oakley wrote:
>
> - Original Message -
>
> I'm looking for a git branching and merge strategy for merge with lots of
> conflicts requiring multiple people. I can make it work, and I understand
> git, but it all seems kind of awkward and
Stephen Morton writes:
> I'm looking for a git branching and merge strategy for merge with lots
> of conflicts requiring multiple people. I can make it work, and I
> understand git, but it all seems kind of awkward and it feels like
> there must be a better way.
>
> I've got a big git merge to d
- Original Message -
I'm looking for a git branching and merge strategy for merge with lots of
conflicts requiring multiple people. I can make it work, and I understand git,
but it all seems kind of awkward and it feels like there must be a better way.
I've got a big git merge to
On Tue, 28 Aug 2012 12:44:19 -0700 (PDT)
git newbie wrote:
> For a more complicated development environment where there is a
> master branch, a devel branch off of master, and feature branches off
> of devel, how do you create a feature branch so that it's parent is
> the devel branch and not the
Lol. Yea, that's a good point.
On Aug 28, 2012 3:11 PM, "Adam Prescott" wrote:
> On Aug 28, 2012 8:51 PM, "Ryan Hodson" wrote:
> >
> > Or, you can use the -b shortcut to save a step:
> >
> > git checkout develop
> > git checkout -b some-feature
> >
>
> If you're going to use a shortcut, use a sh
On Aug 28, 2012 8:51 PM, "Ryan Hodson" wrote:
>
> Or, you can use the -b shortcut to save a step:
>
> git checkout develop
> git checkout -b some-feature
>
If you're going to use a shortcut, use a shortcut!
git checkout -b some-feature develop
--
You received this message because you are subsc
Hi there. The parent branch will always be the *current* branch, so all you
need to do is:
git checkout develop
git branch some-feature
git checkout some-feature
Or, you can use the -b shortcut to save a step:
git checkout develop
git checkout -b some-feature
In either case, some-feature will h
On Monday, July 2, 2012, jack sparrow wrote:
> From the git repo, i created a new branch1 with the existing tag tag1.
> i made some changes to a set of files, filea, fileb. If i run git
> status
> it shows that the filea and fileb are modified, so far good. Now i
> created
> another branch2 with t
On Mon, Oct 10, 2011 at 03:48:24PM -0700, JP wrote:
[...]
> * I make some changes on the new branch. I do not commit or add these
> changes to the staging area. I have both changed existing files and
> added new files.
> * Using the command "git checkout master" I switch back to my master
> branch
On Mon, Oct 10, 2011 at 5:48 PM, JP wrote:
>
>
> What am I doing wrong? Have I completely misunderstood a very basic
> concept in Git? I don't remember previous versions of Git acting like
> this.
>
As far as I know, they did. You have to commit files in the branch for
their changes to be local t
22 matches
Mail list logo
