| Time |
S |
Nick |
Message |
| 00:39 |
|
ironcamel |
we always rebase before we merge a feature/bug branch to our mainline/dev branch |
| 01:47 |
|
pdurbin |
ironcamel: one final rebase at the end when you're done with the feature/bug branch? |
| 11:06 |
|
ironcamel |
pdurbin: yes, we do one fine rebase when we're done with the branch. and we squash all the commits from the feature/bug branch into a single commit. |
| 11:06 |
|
ironcamel |
*final |
| 11:59 |
|
pdurbin |
ironcamel: so... when you are collaborating on a feature branch with other developers, you push it to a central git repo, I assume, so others can pull down the branch. do you ever pull in the latest code from the mainline/dev branch into the feature branch while you're working on it? |
| 12:20 |
|
ironcamel |
yes, and the way to "pull in the latest code from the mainline/dev branch" is to rebase on top of it |
| 12:24 |
|
ironcamel |
so there may be multiple rebases while working on the feature branch, then a final rebase, in which all the commits are squashed, and then merge to the dev branch |
| 12:28 |
|
pdurbin |
ironcamel: ok, so. you rebase develop on top of your feature branch... then you want to push your feature branch to the central repo so the other dev can pull. but you can't push with --force, right? because you've rewritten history. so you use --force. then the other dev goes to pull the feature branch but gets errors. right? |
| 12:30 |
|
ironcamel |
you rebase your feature branch on top of develop. |
| 12:30 |
|
ironcamel |
s/you/i/ |
| 12:31 |
|
ironcamel |
yes, after a rebase, you have to push -f |
| 12:31 |
|
ironcamel |
and other devs who want to look at what you are doing have to do a git reset --hard origin/feature_branch, IF they have alreaded pulled your feature branch before |
| 12:36 |
|
pdurbin |
ironcamel: after they do that reset they can do an easy pull of your rebased feature branch? |
| 12:39 |
|
ironcamel |
after they do the reset, their version of the feature branch will be exactly the same as my version |
| 12:40 |
|
ironcamel |
as i make new commits and push those, they will be able to pull those easily |
| 12:47 |
|
pdurbin |
ok so... |
| 12:47 |
|
pdurbin |
the other dev has already pulled your branch |
| 12:47 |
|
pdurbin |
you rebase and force push |
| 12:47 |
|
pdurbin |
the other dev tries to pull your branch |
| 12:47 |
|
pdurbin |
gets errors |
| 12:48 |
|
pdurbin |
at this point he's effectively done a fetch of your feature branch already, since a pull is a fetch and a merge |
| 12:48 |
|
pdurbin |
(or she) |
| 12:49 |
|
pdurbin |
he does a git reset per above |
| 12:49 |
|
pdurbin |
and then his local branch is the same as the rebased version in the central repo |
| 12:50 |
|
pdurbin |
ironcamel: right? |
| 12:51 |
|
ironcamel |
right |
| 12:51 |
|
pdurbin |
cool |
| 12:52 |
|
pdurbin |
i think the only problem for us in practice might be... I suspect netbeans doesn't know how to do that fancy reset... our devs would have to go to the command line, which many of them don't like |
| 12:53 |
|
pdurbin |
Netbeans can't do a git rebase, either, from what I gather |
| 12:57 |
|
ironcamel |
your IDE seems to be really limiting your team |
| 12:58 |
|
pdurbin |
it does Java EE and JSF well |
| 12:59 |
|
pdurbin |
git support was added recently |
| 12:59 |
|
ironcamel |
does your workflow force you to use your IDE's git thing? |
| 12:59 |
|
ironcamel |
because you guys can just learn git and use it outside of your ide |
| 13:00 |
|
pdurbin |
let's just say that I've tried to write this guide around using git via the IDE: http://dvn.github.com/dvn-sourceforge2github/dvn-dev-on-github/quickstart/ |
| 13:00 |
|
pdurbin |
because that's the preference of the team, to use the IDE and not the command line whenever possible |
| 13:01 |
|
ironcamel |
seems like your team uses their IDE as a crutch |
| 13:02 |
|
pdurbin |
side note: just last night I was surprised I couldn't see all the remote branches with `git branch -a` ... turned out it was because I had done the original clone with Netbeans |
| 13:02 |
|
ironcamel |
which is an inherent danger of using IDE's |
| 13:02 |
|
ironcamel |
well, maybe cause you needed to do a git fetch --all |
| 13:02 |
|
ironcamel |
then git branch -a should show everything |
| 13:02 |
|
pdurbin |
hmm. that may have fixed it. thanks |
| 13:03 |
|
pdurbin |
I don't know that it's fair to say my team uses their IDE as a crutch. folks just aren't very into the command line |
| 13:06 |
|
ironcamel |
not "being into the command line" means you don't want to learn what is actually going on |
| 13:06 |
|
ironcamel |
you want your ide to magically do everything for you |
| 13:07 |
|
ironcamel |
s/^not// |
| 13:07 |
|
ironcamel |
oops |
| 13:07 |
|
ironcamel |
that "not" actually makes sense |
| 13:07 |
|
pdurbin |
makes sense :) |
| 13:24 |
|
* pdurbin |
creates this: using git reset --hard origin/feature_branch · Issue #20 · MarkLodato/visual-git-guide - https://github.com/MarkLodato/visual-git-guide/issues/20 |
| 13:24 |
|
pdurbin |
ironcamel: i mentioned you. i hope you don't mind |
| 13:34 |
|
ironcamel |
np |
| 13:36 |
|
pdurbin |
I googled a bit but couldn't find a nice write up of the workflow you proposed |
| 13:36 |
|
pdurbin |
I like it and I may use it. we'll see :) |
| 14:21 |
|
ironcamel |
i thought it was a pretty standard workflow. i don't see anything special about what we are doing. |
| 14:24 |
|
pdurbin |
destroying local history? :) lots of warnings about git reset out there |
