How to use git

[Ian Wadham]

On 20/08/2016, at 11:51 PM, Ryan Schmidt wrote:
> 
> On Aug 19, 2016, at 10:24 PM, Lawrence Velázquez wrote:
> 
>> Any documentation we write should be written specifically for developers
>> 
>> 	1. who are accustomed to using Subversion, and
>> 	2. want to translate *their MacPorts workflow* to Git.
>> 
>> We shouldn't expend effort rewriting a sloppier version of every generic "this is how version control works" Git tutorial on the Web. There's quite enough of that.
> 
> Maybe what we really need is documentation for MacPorts developers that just covers how to do whatever they need to do, using git. (I don't know if we had such a document for Subversion.) Things like... When first starting to contribute, fork the repo, clone the fork to your Mac; if you already have a fork, update it with the latest changes (how?). Create a branch for your changes. Make your changes in your text editor. Use "git diff" to see the changes. Use "git commit" to commit them. Use "git push" something to push them to GitHub. Submit a pull request on GitHub. When the pull request is accepted, delete your branch.

Fork the repo??

The command for first use is just "git clone".  This gets you a local working copy
of the entire repository and its change history at the current time.

For small changes, edit, test and "git commit -a" (all) or "git commit filename(s)" --- locally.
For large changes, start a local branch and later merge it with your local master branch.
The commands "git status", "git log" and "git diff" help you keep track of changes in
progress and what is committed or uncommitted.

To publish your local commits, first use "git pull --rebase origin master" to fetch the latest
central changes and merge them into your local repository, then use "git push origin master".
The --rebase option gets your changes and the central ones into a reasonably logical
and readable sequence.

Use "git pull --rebase origin master" on its own if you just wish to get up to date with
changes to the central repo.

And that is (almost) all the "gittery" I have  needed and used on KDE development work
in the last 4 years.

The one exception is that, during the run-up to a KDE Applications release, the release
guy makes a branch on the central repository for the new release and development can
then continue on the master branch.  If you are going to fix a bug, you need to retrieve the
new branch from central and make the same fix in two branches.  I can never remember
exactly how to do that… ;-) … but I have the recipe in an email somewhere...

Cheers, Ian W.

> At various step along the way, we could add "historical note" boxes showing how those step were done with Subversion. At some point in the future we'll probably want to remove the Subversion historical information, but still have the git instructions.
> 
>