This ought to keep you out of trouble if you're a downstream user: NEVER git pull NEVER git merge ALWAYS git fetch <remote> ALWAYS git merge --ff-only <remote>/<branch> ALWAYS git rebase <remote>/<branch>
[image: http://stuff.fredcooke.com/IDontAlwaysMergeButWhenIDoI.jpg] rebase -i is your friend if used appropriately. As mentioned, anything you need to know about you can find on the net or in the man page or with --help. But, key: If you want to learn, do. With git, make a new clone and go to town on it, see what magic you can work, you'll learn a lot. And unless you execute a push --force you can't harm your "real" copy. As for the "successful" branching model, yuck... How to make an incomprehensible mess for no reason. A variation on the diagram from the git book, which I don't agree with, and think is misleading and unclear. [image: Image] Explanation: - On the left are files that are not known to git. New files. Files that have not been committed in the past, or have since been removed. - Next to that is the normal default state of a committed and tracked git file. - To the right of that is the same file, modified, and showing a dirty status. - Finally, on the right is a staging area, where you MUST add new files, and where you CAN add existing modified files. The original file<http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository>is misleading in that: 1. It shows adding a new file as making it tracked, when really, it's just staged, and not committed. Sure, git knows about it, but not in a permanent/semi-permanent way. 2. It doesn't show adding a new file as being staged and ready to commit, implying that it's committed by adding it. 3. It doesn't show that you can commit from the modified state without staging anything. Additionally, mine doesn't show that you can remove something from being staged instead of committing it. Insert a big grey line from right to left at the bottom in your mind. Try to avoid messes like this: [image: Image] It's easy to make an incomprehensible mess if you don't understand what you're doing. So try to understand what your goal is before you try to do something. Much like writing code SHOULD be, but often isn't. [1] Fred. [1] http://pragprog.com/the-pragmatic-programmer/extracts/coincidence On Sat, Jul 27, 2013 at 11:44 PM, Arnaud Héritier <[email protected]>wrote: > I don't think we have many things on Maven project side and really few > things on apache side > About the workflow to use with git you have the well known successful > branching model > http://nvie.com/posts/a-successful-git-branching-model/ > At work I adapted / completed it for our internal usage (maybe we could do > the same here) > http://developer.exoplatform.org/docs/scm/git-workflow.html > > There are many cheat sheets and resources on internet, everyone writing its > own when he starts with git :-) > http://developer.exoplatform.org/docs/scm/git-cheatsheet.html > > Myself I really like these ones : > http://www.ndpsoftware.com/git-cheatsheet.html > http://pcottle.github.io/learnGitBranching/ > > Cheers > > > On Sat, Jul 27, 2013 at 10:30 PM, Barrie Treloar <[email protected]> > wrote: > > > On 28 July 2013 00:24, Kristian Rosenvold <[email protected]> > > wrote: > > > It's ok if not pushed, but I think it should be made a lot clearer in > > the guide. > > > > Do we have a "how to" guide for using Git? > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > -- > ----- > Arnaud Héritier > http://aheritier.net > Mail/GTalk: aheritier AT gmail DOT com > Twitter/Skype : aheritier >
