[prev in list] [next in list] [prev in thread] [next in thread] 

List:       macports-dev
Subject:    Re: How to use git
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2016-08-21 3:44:55
Message-ID: 7242D5F3-5608-4016-831F-281435719CB5 () gmail ! com
[Download RAW message or body]


On 20/08/2016, at 11:51 PM, Ryan Schmidt wrote:
> =

> On Aug 19, 2016, at 10:24 PM, Lawrence Vel=E1zquez 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 j=
ust 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 ha=
ve a fork, update it with the latest changes (how?). Create a branch for yo=
ur changes. Make your changes in your text editor. Use "git diff" to see th=
e changes. Use "git commit" to commit them. Use "git push" something to pus=
h 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 worki=
ng 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 file=
name(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 pu=
sh origin master".
The --rebase option gets your changes and the central ones into a reasonabl=
y 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 devel=
opment 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 develo=
pment can
then continue on the master branch.  If you are going to fix a bug, you nee=
d to retrieve the
new branch from central and make the same fix in two branches.  I can never=
 remember
exactly how to do that=85 ;-) =85 but I have the recipe in an email somewhe=
re...

Cheers, Ian W.

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

> =


_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
[prev in list] [next in list] [prev in thread] [next in thread]