> On Aug 7, 2017, at 5:42 PM, Brian Burch <br...@pingtoo.com> 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

Reply via email to