Search options (Page 8 of 14)

To summarize, here is a possible workflow when you work with git:
- create a branch, like 'fix_serial'
the current code will be "branched", so you will have a branch containing exactly the same code as before
- you make a small change
-  you commit it even if the feature is not complete. you include a descriptive changelog of what you did
- you make another small change
-  you commit it
- now, the feature is complete
during all this time, the master branch was unaffected by your changes, and other developers could develop other features independently
- you (and git) will now merge the feature into the master branch
this can be hard because the master branch could have changed
but git is smarter enough to notice if you renamed some files, or if another developer inserted some code in a place you touched.
Git tries to merge automatically, but sometimes it fails.
In this case, you get "conflicts": a part of code that you changed, and a part that another developer changed, are conflicting.
You have to solve it by hand, and once this is done, you commit the conflict resolution.

After that, on github, or with another tool, you are able to browse every commit one by one, and see what code was changed.
You can easily read the changelog to see what happened, then inspect the changes.

So for now, if you are only beginning with git, and if you will be the most active contributor, try to make only small changes, and commit them one by one.

you have to get a clone of a repository, with "git clone"
then "git status" than "git add" for every file you want to commit
then "git commit"
wrtie the changelog
and git push
And your changes should appear immediately on github

If someone else want to develop, he/she can clone your repository, make changes, and make a "pull request".
You will have to read his/her code, and accept it or not.
This is how other developers will be able to help as well.

I hope I was clear enough, if not...
just ask