If you don't have a lot of Git experience, do keep in mind there are lots of GUI clients that are useful. Even if you choose not to use one regularly, they are great for initially getting a view / handle on things.
My favorite is SmartGit - it's java and cross platform and made by some awesome Germans. I almost never drop to command line with it, and other than 'stage', my typical single branch workflow is the same as SVN practically. AFAIK, you can also use the GitHub clients without GitHub. There is also TortoiseGit (I don't hear great things). RabbitVCS (not my favorite) And many, many more. - Mark On Wed, Jan 20, 2016 at 7:38 AM Dawid Weiss <dawid.we...@gmail.com> wrote: > > In the current SVN workflow we record the history > > about that and we see all related commits of this merge > > Sigh. My opinion on SVN merges are quite the opposite -- at the > low-level (which I had to go to, unfortunately) they are nothing *but* > recorded merge history -- they're path-copy and aggregated diff > commands that originate from nowhere... The "mergeinfo" property you > refer to is not really a solution here, it's a workaround for an > architectural flaw. > > > So what’s the right way to merge 3 commits from trunk (now master) to > > branch_5x? Cherry-Pick and the commit and push? > > A git merge has two parent branches. So you merge changes on another > branch inclusively (all of them). For example, in the git history of > Solr and Lucene, a "merge" commit between the two projects effectively > means "take all patches from solr + take all patches from Lucene and > apply them". You can amend the merge commit and revert or modify > certain bits, but it can be confusing (and I agree with Mark here). > > My personal preference is to work with individual commits, so yes, the > workflow would be something like this: > > git checkout master > # changeset1 > git add -A . && git commit -m "changeset1" > # changeset2 > git add -A . && git commit -m "changeset2" > # changeset3 > git add -A . && git commit -m "changeset3" > > git checkout branch_5x > git log master # note hashes of commits you wish to apply on the branch > git cherry-pick hash-changeset1 hash-changeset2 hash-changeset3 > > The result would be three commits on master and three (identical) > commits on branch_5x. If a changeset cannot be applied cleanly, git > will let you know -- you can then either abort a cherry pick or modify > the changeset and apply it on the branch. > > Note that if you're working on something you would squash the interim > commits into one and then it's just one cherry pick to any of the > maintenance branches you wish to apply it to. > > > just know how to use TortoiseGit and I see many buttons and checkboxes > there > > that I don’t know. > > Calm down and give it some time, although I have no clue what > TortoiseGit looks like... The advantage of working with command line > is that it's the same everywhere (windows, linux, mac). > > > I want to see that those merges came from trunk/master in history. > > If you cherry pick a commit you won't see it as a merge. It is an > "apply this commit's diff and log to another branch" command, it has > nothing to do with merging. > > > For large feature > > branches where more than one comitter are working on, we should of course > > keep history and not only the final merge. > > You will grow to dislike this type of workflow with git if you then > intend to apply the same feature to another branch... Yes there are > workflows that make heavy use of branches, but they do require some > understanding of what can be merged and where. I think it's not the > right moment to introduce these. > > Think of a patch in Jira -- if it's self contained, you can just take > it and apply it elsewhere. A merge commit of 40 commits that forked > from the mainline is like taking those 40 patches that have occurred > since the branch was forked and applying them successively back to the > mainline. But if you have another branch, forked at a different > "parent" commit then a merge of the feature branch is not just 40 > patches -- their entire diverging history of parent commits needs to > be considered. The closest thing to svn's "merge reintegrate" would be > to copy and rebase those 40 commits from the feature branch and then > apply it again, but this is where you're getting into more advanced > workflows. I'd stick with simple cases, at least at the beginning. > > Dawid > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- - Mark about.me/markrmiller
