GIT CHEAT SHEET

Configuring a local directory to a remote github repo by the same name

For these examples, we will work with the EF-Magento repository.  Initialize a local repository.
Configure a remote repository, defining a remote master called ‘newbie’, have it track ‘staging’ branch.

Pull GIT ‘staging’ branch:

create a new branch and switch to it (in this case, newbie):

The master branch may change during the
day or days of editing the ‘newbie’ branch.  To update local ‘newbie’ branch with the newest changes from the
‘master’ that came while working on newbie, but also to preserve all
the changes made to ‘newbie’; do this while still in ‘newbie’ branch:

Create a remote branch named myvendor using staging as the reference

Functional branches each act as their own repository. Though primarily useful for keeping contributors’ sources separate until ready to merge; a generous use of branching in a single repository can also help reduce costs while also reducing headaches associated with managing multiple repositories.

As an example, unixteam utilizes many independent branches that are never merged, under one repository called ‘unixteam’.  Each branch manages different files, many share the same name but have different content as found in their branch counter-parts.  To manage how the branches are merged, sources and push destinations, git uses a config file.

Though there are git commands to set the environment configuration, it is usually easier to copy/paste a branch section of an existing (working) config to a new section of the same config, changing the local and remote names, as needed.

Copy, paste and edit sections from the example above if you do not have a good config to sample on your local machine.

Remove the existing local repo and all branches and clone (this may be overkill, see git rebase below):

change directory to the new local home:

change to using a branch, below uses the newbie branch:

optionally, verify an asterisk is next to your branch:

optionally, instead deleting and cloning above, start from cd
EF-Magento, checkout the existing branch, then ‘re-clone’ the branch
while preserving recent changes (it works!):

copy in your changes to the correct path under trunk:

see if local changes are noticed by git — don’t panic if this step yields nothing:

while still in git home MY-Product, git add the files you just copied:

commit the files to the local repo.  comments are required.

merge the local repo with the local origin

ready to push to the remote master — because you are still in newbie branch, that’s where it goes:

THAT’S IT!   To see
the differences between the merged (local) newbie branch and the
(local) master, this command yields the diffs until newbie is merged
with master:

Resolve merge conflicts by keeping YOUR changes
 

Fetch a branch (called staging) from My-Repo without cloning entire repository

remote: Total 19177 (delta 7038), reused 18988 (delta
6852)

Receiving objects: 100% (19177/19177), 66.33 MiB | 8.94 MiB/s, done.
Resolving deltas: 100% (7038/7038), done.
From github.com:TLC-Tech/My-Product
* [new branch]      staging    -> origin/staging

error: src refspec origin does not match any.
error: failed to push some refs to ‘https://admin@github.com/TLC-Tech/myteam.git‘

1)  Switch to the new branch (called staging), then use “–set-upstream” option to push:

1)  Undo and remove history of the most recent commit:

1)  Undo the commit (keep history) and push the fixed branch to remote:

1) Find the commit number in github.

2) Clone the current database, then ‘cherry-pick’ the commit
you found in step 1:

Files are now updated on your local system.

3) To see the diff, rename the cherry-picked clone and
create a new clone and diff on your local system:

4) To update remote, cd into the cherry-picked directory, and
commit/push back to github