Re: EDi 9.1 and eGit

On Tue, 2015-08-04 at 09:13 +0000, Paul Nicolay wrote:

I have found this site
https://git-scm.com/book/en/v2/Git-Branching-Rebasing to be really good,
nice and simple and point by point.

Getting a bit less lost :-)

The issue seems to be related to performing a rebase versus merge (on which you can find plenty of discussions about what is the best) which again is linked to branching (again lots of discussions on the internet whether it should be done that often or not) however it still isn't clear to me yet.

What does work for me at this point is...

- Change member A
- Commit and push (gets rejected if someone else changed member A as well)
- Fetch (don't use pull or you'll end up with a rebase)
- Merge (this will bring up the red marks)
- Use the merge tool on the marked conflicts
- Add to index (strange as an svn user, but this marks the conflict as resolved)
- Commit and push (now it will be accepted)

The result of this is a polution of your branch with merge-commits wich apparently can be solved by the rebase (but I still need to figure that out). The fact that pull is doing a rebase in eGit is controlled by Window - Preferences - Team - Git - Configuration : autosetuprebase always.

One thing I've found useful is to have a linked chain of "central"
repositories. I have a local central repository that I push my commits
to, then that repository has github as its upstream. That way if I muck
up I can always fix it/delete it (or mirror/replace the "local central"
from github) before it hits github.

I think by using branches it can help to prevent conflicts.

Master
Development
UserOne
USerTwo

You still need to locally refresh your copy of Development and roll
forward any changes the other user has done and merged back into
Development, but unless you actually need the changes done by the other
developer to complete your changes it makes thing much simpler.

If you need someone else’s changes to complete yours, then that’s more a
project management thing. If your program needs new fields in a file and
that file is being changed by userOne then a new branch, FileChanges,
needs to be created and the changes done and pushed to the central
repository and merged back into the "master" or "development" branch.
(Which you then retrieve/refresh)

If you are both working on the same program, but performing different
changes (userOne is changing how the price is calculated, userTwo is
changing how the initial stock level is ordered) then the who ever
pushes and merges to the master wins... the other user then refreshes
the master and rolls forward (rebases?) the changes to his yet un-pushed
commits.

Any cluttering up of the local commits can also be "squashed" in to a
bigger commit prior to eventually being pushed and merged with the
central repository branches, or you can rebase (from what I can tell) so
your version now looks as if you were always working with the changes
done by the other user.

I'm not totally sure, but I think merging requires a new commit of the
resolved changes and rebasing makes all your commits reflect the changes
by who ever pushed first. It does however, I think, change the commit
id's, so if you have already pushed, then rebased locally things get
more complex.

I think what helps to clarify things is that if two people are doing
changes, there is actually a third person involved... the imaginary
person dealing with the central repository. By only pushing a set of
completed commits, you don't have to bug him very often. By rebasing (I
think) your local repository prior to pushing your set of commits there
should not be any conflicts to resolve.

I think another good rule to clarify things is that commits should only
be pushed when all the work is done and complete, never push commits as
they are done only when the logical group of work is complete. Further
to this I would also say that commits should only be done when the
smaller bit of work is complete and results in a working program (or a
file that can stand on its own, say an include prototype file), or if
you know you are waiting on a change by someone else but want to do your
changes and commits now, go ahead and commit, and rebase and/or squash
the commits into a larger one once you get a successful compile/test and
then finally push.

________________________________________
From: WDSCI-L [wdsci-l-bounces@xxxxxxxxxxxx] on behalf of Paul Nicolay [Paul.Nicolay@xxxxxxxxxx]
Sent: Tuesday, August 04, 2015 09:11
To: Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries
Subject: Re: [WDSCI-L] EDi 9.1 and eGit

Looking at this video; https://www.youtube.com/watch?v=I8lHLSjWBRY I don't see any branches created at all and it is doing the same as I'm trying... however I just started from scratch once more but as soon as I pull changes as second user it marks the project as "rebase w/ merge" (it does show up the red carrets and allows me to merge and commit/push fine however).

I've read lots of things but so far I couldn't find a simple example that explains how to work with two developers (instead they all start with multiple complex branches which doesn't make understanding the basics any easier).

As far as gitignore is concerned... unlike in Svn, you need to add everything to Git yourself or nothing happens with it, so what is the point of having a gitignore (unless you would commit with -a which eGit isn't clearly doing as I don't see any of the Rational files on Github appearing).

Still totally lost :(