5

What are the recommended steps for committing changes to the main branch with Eclipse + egit?

I have been using Eclipse and svn for a long time and everything works beautifully there. Whenever I am about to commit a change, my flow is the following:

  • synchronize with workspace
  • look for conflicts
  • when conflicts are found, merge manually and then mark file as merged
  • update
  • commit

In the rare cases where I attempt to commit a group of files without a commit, I am warned about it and can correct the changes nicely.

Even if I update files that are conflicting, it isn't bad to recover from that though I find that synchronizing with workspace first to identify and merge files with conflicts is a much better flow than attempting to merge after an update that failed because of conflicts.

With egit, no flow that I tried worked properly. First, if I mistakenly do a pull from the server and that there are conflicts, I am told there was a conflict but then am very confused about it: I have a hard time retrieving the latest from server and find it impossible to commit my files no matter how much synchronization I do. Even replacing my file with the latest from head and doing another pull and then commit doesn't seem to work anymore.

Even if I follow the same approach I used with svn (synchronize first and merge manually files with conflicts) and follow second with a pull, I still get the same failures I mentioned above, as if my marking a file as merged wasn't accounted for.

So... blank sheet of paper, what are the recommended instructions when I made some changes, want to merge them with the latest code on server (which may include file changes conflicting with my set of changes), and, optionally, want to commit my changes? Pointer to a good egit tutorial is fine if there is one discussing this kind of issues.

Lolo
  • 3,935
  • 5
  • 40
  • 50

1 Answers1

7

I'm not sure if I understood your question correctly. But I'm now trying to give you some hints. We recently converted the repository of our company from CVS to git which was quite challenging as we had a lot of questions focussing on the same problem you are targeting.

First of all I have to say that coming from SVN or CVS you won't be able to do your workflow as you did maybe for years.

Especially working on a small set of files and updating only those via synchronize won't work with git. Here are the steps I take when synchronizing (in terms of getting the latest from the server) with our git.

  1. I commit. Early commit is what saves you a lot of pain! Don't have pending changes when synchronizing with a remote repo, as with egit this could result in quite a bunch of pain.
  2. I fetch. With egit you can put the action into the toolbar or even create a shortcut for it, which makes the fetch quite comfortable.
  3. The result of the fetch will be presented in a dialog. I study the changes, cause this is the best point to do this with egit, as I think. You can read all commit messages and even double click them for opening a commit in the background and study the diff. Yes, this dialog is not modal.. so you can move it on the second monitor.
  4. I do a rebase. Which is similar to a merge but doesn't leave the information from which point you started your temporary development. This is kind of a design decision my company made - to prefer rebase over merge.
  5. If you have conflicts you can use the merge tool to solve them. This is quite similar to the synchronizing you did with CVS. Remember to do a Add to index as it's the new mark as merged. Afterwards you should do Rebase > Continue if you did a rebase.
  6. I do a push. And if nobody pushed in the meantime that's it.

That's my workflow. If that's the right direction I can add more details why I do several steps as I do and how I think the best way is doing them with egit.

Bertram Nudelbach
  • 1,783
  • 2
  • 15
  • 27
  • Could you please advice how to overcome checkout conflict http://stackoverflow.com/questions/18050220/eclipse-egit-checkout-conflict-with-files-egit-doesnt-want-to-continue . For the future now I learned, I should have committed before fetch. – Paul Verest Aug 05 '13 at 05:59
  • 1
    Yes, I'll have a look at it. Might take a couple of minutes ;-) But this problem is one of the reasons a commit before synchronize is a good idea. git gives you a lot of possibilities to deal with that commit afterwards if you don't want to publish it in that way. – Bertram Nudelbach Aug 05 '13 at 06:03
  • a lot of possibilities is what is confusing in the beginning. One needs to know the path. – Paul Verest Aug 05 '13 at 06:05
  • Yes. In my company we saw some frequently made problems and described a best practise how to solve them using egit. I'll have a look if some of them aren't already available on stackoverflow and might describe them here for all .. – Bertram Nudelbach Aug 05 '13 at 06:09
  • Just publish them (for example as examples on GitHub) there link (and copy contents). – Paul Verest Aug 05 '13 at 06:43
  • Yes, but that may take a while as I have to translate them and currently I have only little time. – Bertram Nudelbach Aug 05 '13 at 06:45
  • German would do. and it would be good small start. We also started organizing knowledge in company wiki. – Paul Verest Aug 05 '13 at 06:56
  • I will have to experiment with your suggested flow but this was indeed the kind of answer I was hoping for. Leaving the question open for a few more days in case more suggestions come up. One question: I assume that when you commit, you do not have the "push changes to upstream" checked out, correct? Also, can you say a few more words about rebase vs. merge? Is that a convention everyone needs to have or can each developer chose how they want to approach it? Last: do you use branches with that approach or not? – Lolo Aug 05 '13 at 15:41
  • Could you please say that "push changes to upstream" in other words? Cause I don't get the point. Rebase vs. merge is not a general convention. But we have quite a big repository (4gb) and a lot of changes and found that at some point egit is not quite comfortable displaying the merge paths. For us it is uninteresting from which point a development started. So we just want a sequence of commits in general. that's why we prefer rebase over merge. Personally I use lots of local branches and we have lots of shared branches. The workflow indeed has some additional steps when using local branches. – Bertram Nudelbach Aug 05 '13 at 20:06
  • @BertramNudelbach When I select "commit", Eclipse displays the files to be committed and a checkbox at the bottom gives me the option to "Push the changes to upstream", i.e. to do a push following the commit. If that option isn't checked, I only commit to the local repository, which I believe is what you do in your step 1. Like Paul said, I am also very interested in any details you can post on your process, including your workflow with branches. It is strange how little discussion I saw of this regarding egit and Eclipse specifically. – Lolo Aug 06 '13 at 04:30
  • Ok, normally I choose to don't commit and push. But it doesn't matter. Because when egit tries to commit and then to push. If the push fails, you still have your commit. So here is how I do it: All over the day I commit, cause other people working and a non-fast-forward might happen. When I work at night it's quite unlikely that somebody else pushes, so that's when I use commit&push. http://www.vogella.com/articles/EGit/article.html provides some basic information. I'm gonna make some screencasts about branching. Would it help you if I inform you when they're available? Or is text better? – Bertram Nudelbach Aug 06 '13 at 07:23