> On Aug 7, 2017, at 5:42 PM, Brian Burch <[email protected]> wrote: > >> Yes, it can get confusing if you are working with active branches >> distributed over a large team, but otherwise quite simple to use, and there >> are plenty of good tutorials around that show the basic usage patterns. >> I keep a cheat sheet with the half dozen commands I use to manage code >> bases. I’ll forward it to you if you’re interested. > > Yes please! Once I am familiar and the Directory project has been migrated, I > could use it to start the wiki page we should have (analogous to the current > SVN page). > > I think I might be tempted to try converting one of my own simple SVN > projects to GIT. I suppose it is time for me to stop being scared of the > dark! (Still, I'm glad it will be the advocates, rather than me, who will be > responsible for migrating this complex collection of sub-projects).
I’ve found 95% of working on an apache directory project is using these commands: git clone proj-name e.g. git clone https://github.com/apache/directory-fortress-core.git will check out latest or git clone --branch 2.0.0 https://git-wip-us.apache.org/repos/asf/directory-fortress-core.git will checkout everything from the last release, 2.0.0 The git clone command copies an existing Git repository. This is sort of like SVN checkout, except the “working copy” is a full-fledged Git repository—it has its own history, manages its own files, and is a completely isolated environment from the original repository. git clone | Atlassian Git Tutorial https://www.atlassian.com/git/tutorials/setting-up-a-repository/git-clone Three more very common commands are: git pull <— give me everything up to the last pushed commit on branch I’m pointing git commit <- commit my latest changes git push <- push my latest commits into the global repository Performing releases of course will do more operations like creating tags but those ops are wrapped inside of our apache directory standard maven release process, automating most of it. Of course some projects require branching because their codebases get busy, and many features are being worked on simultaneously. Typically not the the case in our project. Regardless, you will eventually find yourself needing to understand how branching and merging works, and here is my cheat sheet for those ops. Hope it helps…. --- working with branches --- git fetch <- fetches new branches git branch -a <- shows existing branches git branch name <- create new branch of 'name' git checkout name <- to start working on this branch --- temporarily saving and retrieving uncommmitted changes --- git stash <- to stash uncommmitted changes, so you can pull latest changes, change to another branch, etc git pop <- to retrieve previously saved uncommitted changes --- rename a branch locally and remotely git branch -m old_name new_name git push origin :old_name git push --set-upstream origin new_name --- merge the brnach back to master --- git checkout master git merge name <- will fast-forward changes if no changes to the master since the branch git push <- to synch with global repo --- delete the branch (after merge) git branch -d name <- doesn't remove remotely git push origin :name Shawn
