I never thought of working git/github the way you describe - I ONLY thought of it a way of working with others.
Aa ha, but here is the thing. What is the difference between working by yourself on a project and working with others?
One cannot contain the whole project, or many projects, in ones head all the time. Projects get put aside whilst all the rest of life gets one's attention. Then when one gets back to it, all kind of details about what is what, what is where, and "what the hell was I doing anyway?" are forgotten.
Arguably, the "me" that comes back to a project is not the same "me" that left it a month ago.
Historically we deal with this problem by meticulously taking notes. Engineer's log books and all that. We leave messages to our future selves. The "others".
For software projects git automates that note taking.
With the added bonus that we can share with actual "others" if we so desire.
But, less abstractly, it's great that one can experiment with a new idea, perhaps fail and trash the whole program, and then "git checkout ... ", BOOM, everything is back as it was. No harm done.
This kind of liberates your mind to be adventurous.
My experience of old school source management systems is that one would checkout a file, or a bunch of files, hack on them for days or weeks, then check them back in again when whatever you did looked good.
The whole process was so complex, clunky and slow that one did not want to do that check out/check in thing too often. It was like some horrible office administration chore.
The there is git. Never mind the checkout thing, just hack the files you want like you normally do.
If your changes look good add those files to a possible commit. Then commit them.
This is all so quick and easy one ends up doing it multiple times per day.
So much easier than saving a snapshot of a directory, remembering to adjust the date/version extension to the directory name, remembering which version had what changes/fixes in it. Etc, etc.
I got the idea Heater and potatohead from the first mention. This is true in so many fields of endeavor - having a record (memory) of how one's thinking is changing and evolving is an education in itself and leads to new avenues to explore - good ones are integrated and poor ones can be dismissed (or filed for a more appropriate application).
What did someone say above? Comments are left for the next idiot trying to figure out what you did - often you are the idiot!
This thinking about programming is very instructive - often I am only thinking about the problem I am solving. What a marvelous discussion this has turned in to.
Thanks again to all of you - especially those of you I have not replied to specifically. I really appreciate all the thoughtful responses.
I've been working with BlocklyProp GitHub and BlocklyProp developers since it first came out - I have been leaving input for others and making suggestions for improvement, but really had NO idea what GitHub was actually tracking and allowing to happen. My mind is blown.
This sort of tracking will be great for me and I now understand (at least a bit more fully) what I have been doing and will continue to do with people obviously much smarter than me!
Thanks for the education! It is amazing when you discover big blind spots - things right in front of you that you just aren't aware of - then (of course), once you are aware - they show up everywhere!
I'd also recommend adding branching and rebasing to your workflow. Break off onto a branch, do your work making frequent commits and then rebase to clean up the history before merging the branch into master.
That will add everything. But that may add a lot of binaries and other stuff which are not source but created from the source, which should perhaps not be in the repo.
At this point you could still be changing or creating new files and "git add" them as you like.
3) At this point your code is not actually committed to the repo. You could hack it some more and "git add" it again. When you want to commit it as an actual version you have to use "git commit"
$ git commit -m "My initial git commit"
Now you have a version in the git repo. With a message logged describing what your changes were.
4) You can view your log of changes with:
$ git log
5) You can view the status of your repo with:
$ git status
That will tell you what files you have changed or added that are not yet committed. And other useful stuff.
After that, my day to day working is just, edit some source files, do a "git add" when they look good. Then "git commit". Job done.
Then you might want to put your repo int gighub.com or bitbucket.com for safekeeping and possible sharing. I suggest just signing up for github and following their very clear instructions on how to create a new github repo and get your code into it.
When you have a github or bitbucket repo up then you can do the following:
$ git push
Will push commited changes from your machine to the github repo.
$ git pull
Will pull changes from the github repo to your local machine.
This push/pull thing is neat because you may find yourself hacking your code on different PC's here and there, as I often do. No propblem, push changes from one machine, pull them to another.
Personally, as a beginner I would advise ignoring all talk or branching, merging, rebasing etc. Why?
Because, an important thing to realize is that the repo on your machine, and the one on github are exactly equivalent. There is no "master".
That means that when you hack code on your machine and commit it, it is a branch from github or wherever it came from. Until you push your changes.
If you find you have messed up your branch, you can always just delete the whole directory and "git clone" it back again.
And, well, all that branching, merging, rebasing stuff is complex. I almost never need it.
While I agree it can get complex (and I've got into some massive tangles while learning), I disagree on branching/merging. It doesn't have anything to do with GitHub and can all be done on your local machine and local repo. Say I'm working on a new feature and I get a bug report that comes in or stands in my way. That could get messy if you are doing all of your work on the master branch. If you did this, it's much easier:
1) git branch my_feature (makes a new branch locally)
2) git checkout my_feature (checkout that branch to work on)
3) <do work>
4) git add -u (add all tracked changed files, or specific files, whatever you want to do here)
5) git commit -m "Implemented part 1 of new feature"
* Bug report!!! *
6) git checkout master
7) git checkout -b my_bug_fix (make a new branch and check it out - handy shorthand)
8 ) <do work on bug fix, add, commit, etc>
9) git checkout master
10) <Work on whatever, back to the feature, another bug, etc>
11) git merge my_bug_fix (I'm happy with my bug fix, merge it in to master branch)
12) git branch -d my_bug_fix (cleanup your old merged branches!)
13) git checkout my_feature
14) git rebase master (put the changes in my_feature branch onto the new version of what's in master. Adding interactive flag will let you squash commits, respell messages, etc)
It's a bit confusing at first, but is a wonderful workflow.
If you've messed up your branch you can always checkout and older hash to roll back the whole thing or a specific file. git log is your friend there.
I agree. Git has lots of wonderful features that help when juggling multiple developments, perhaps by different developers, at the same time. All that branching, merging and rebasing stuff. That is what it was designed for.
My only little point was that for a beginner to git, likely one guy with his hobby project, all that is too much to grasp from the get go.
Point is, git helps with the simple stuff as well. Hack code, save version, hack code, save version. Oh poop I messed up today, get back to yesterday's version and start again....
It's quick and easy. The other powers of git can be acquired with time.
Recently I have been trying to explain to our manager types how it would be better to keep our docs in github so that everyone knows what is what, who changed what and when, and track suggested improvements.
Oh no, they just want to juggle files on dropbox or google docs.
Recently I have been trying to explain to our manager types how it would be better to keep our docs in github so that everyone knows what is what, who changed what and when, and track suggested improvements.
Back in the '80s, a fellow QuickBASIC programmer insisted on assigning a value to a variable THREE times and he actually said that it was "to make sure it sticks" (!!!)
He claimed that he'd proven time and again that it was necessary.
His program was a pre-processor for AutoCAD and people actually paid $17,000/seat for this clunky product.
I look at today's bloated .exe files and wonder how much of this mentality there is, out there.
Static analysis tools can catch (and do on well maintained code bases) much of these kind of duplications, unused variables, etc. Now the dependency tree for some desktop apps can indeed make them bloated, but it's certainly better on modern systems with fewer resource constraints than a ground-up development of an existing tool.
I keep hearing this refrain about "poor programming" now a days.
On the other hand we know that people like Google have invested a lot in creating efficient, optimized, programming environments. Like Clang/LLVM for example. There are some very smart and efficiency obsessed guys working on such things. The Chrome browser, for example, may use a ton of memory but it would be much bigger and slower if they had not put that effort in.
So where does the "bloat" come from? Let's look at a simple example, the "Hello World" program:
int main (int argc, char* argv[])
{
printf("Hello World!");
return (0);
}
What is wrong with that? Can probably be written in a few tens of bytes in assembler.
Well, the "Hello World!" probably needs to be in Unicode. Which already requires a huge pile of "bloat" to handle.
Then of course it needs internationalizing, that "Hello World!" should come out in whatever the users language is. Another pile of bloat.
Then of course nobody uses the command line anymore so that needs a GUI Window to open to display the message. Another pile of bloat.
Well, with that GUI you need to support all kinds of fonts, anti-aliasing etc, etc. More bloat.
Now, you might need this program to work on multiple platforms, Linux, Mac, Windows at least. Not to mention iOS and Android. That means using a cross platform GUI toolkit. Another pile of bloat.
It's hopeless. But every byte of that bloat is required.
As to the part of the thread regarding using git/github, there is a udacity course on that. Seems pretty good, but every time I get part way through it, something comes up so have yet to complete the third part. Overall it does do a good job getting across both the use of git and the reasons why behind it and version control systems. Certainly a 7734 of a lot cheaper than say ClearCase.
The link does not work because this forum software is broken. The "(" in the URL ends the URL when it should not. Copy it as text and paste into the browser.
I can't get anything but the first page of this thread in Lynx.
@frank,
Oh my God, ClearCase. I still have nightmares about that beast from my time having to use it at Nokia. Even worse than Visual Source Safe.
Comments
One cannot contain the whole project, or many projects, in ones head all the time. Projects get put aside whilst all the rest of life gets one's attention. Then when one gets back to it, all kind of details about what is what, what is where, and "what the hell was I doing anyway?" are forgotten.
Arguably, the "me" that comes back to a project is not the same "me" that left it a month ago.
Historically we deal with this problem by meticulously taking notes. Engineer's log books and all that. We leave messages to our future selves. The "others".
For software projects git automates that note taking.
With the added bonus that we can share with actual "others" if we so desire.
But, less abstractly, it's great that one can experiment with a new idea, perhaps fail and trash the whole program, and then "git checkout ... ", BOOM, everything is back as it was. No harm done.
This kind of liberates your mind to be adventurous.
My experience of old school source management systems is that one would checkout a file, or a bunch of files, hack on them for days or weeks, then check them back in again when whatever you did looked good.
The whole process was so complex, clunky and slow that one did not want to do that check out/check in thing too often. It was like some horrible office administration chore.
The there is git. Never mind the checkout thing, just hack the files you want like you normally do.
If your changes look good add those files to a possible commit. Then commit them.
This is all so quick and easy one ends up doing it multiple times per day.
So much easier than saving a snapshot of a directory, remembering to adjust the date/version extension to the directory name, remembering which version had what changes/fixes in it. Etc, etc.
I got the idea Heater and potatohead from the first mention. This is true in so many fields of endeavor - having a record (memory) of how one's thinking is changing and evolving is an education in itself and leads to new avenues to explore - good ones are integrated and poor ones can be dismissed (or filed for a more appropriate application).
What did someone say above? Comments are left for the next idiot trying to figure out what you did - often you are the idiot!
This thinking about programming is very instructive - often I am only thinking about the problem I am solving. What a marvelous discussion this has turned in to.
Thanks again to all of you - especially those of you I have not replied to specifically. I really appreciate all the thoughtful responses.
I've been working with BlocklyProp GitHub and BlocklyProp developers since it first came out - I have been leaving input for others and making suggestions for improvement, but really had NO idea what GitHub was actually tracking and allowing to happen. My mind is blown.
This sort of tracking will be great for me and I now understand (at least a bit more fully) what I have been doing and will continue to do with people obviously much smarter than me!
Thanks for the education! It is amazing when you discover big blind spots - things right in front of you that you just aren't aware of - then (of course), once you are aware - they show up everywhere!
Git will be installed shortly - locally!
Jim
See https://git-scm.com/
I'd also recommend adding branching and rebasing to your workflow. Break off onto a branch, do your work making frequent commits and then rebase to clean up the history before merging the branch into master.
Assuming you already have a project started in some directory and assuming you have git installed on your machine I would proceed like this:
1) Create a git repository out of your existing code.
$ cd myProject
$ git init
That will ask a few questions, mostly I just hit "return" and accept the defaults.
2) Add your code to the git repository:
$ git add thisFile otherFile thisDirectory otherDirectory ...
Or you can just do:
$ git add *
That will add everything. But that may add a lot of binaries and other stuff which are not source but created from the source, which should perhaps not be in the repo.
At this point you could still be changing or creating new files and "git add" them as you like.
3) At this point your code is not actually committed to the repo. You could hack it some more and "git add" it again. When you want to commit it as an actual version you have to use "git commit"
$ git commit -m "My initial git commit"
Now you have a version in the git repo. With a message logged describing what your changes were.
4) You can view your log of changes with:
$ git log
5) You can view the status of your repo with:
$ git status
That will tell you what files you have changed or added that are not yet committed. And other useful stuff.
After that, my day to day working is just, edit some source files, do a "git add" when they look good. Then "git commit". Job done.
Then you might want to put your repo int gighub.com or bitbucket.com for safekeeping and possible sharing. I suggest just signing up for github and following their very clear instructions on how to create a new github repo and get your code into it.
When you have a github or bitbucket repo up then you can do the following:
$ git push
Will push commited changes from your machine to the github repo.
$ git pull
Will pull changes from the github repo to your local machine.
This push/pull thing is neat because you may find yourself hacking your code on different PC's here and there, as I often do. No propblem, push changes from one machine, pull them to another.
Then there is cloning, as in:
$ git clone https://github.com/ucb-bar/riscv-sodor.git
Which is good if your machine does not have the repo yet, it just fetches the repo you want.
Personally, as a beginner I would advise ignoring all talk or branching, merging, rebasing etc. Why?
Because, an important thing to realize is that the repo on your machine, and the one on github are exactly equivalent. There is no "master".
That means that when you hack code on your machine and commit it, it is a branch from github or wherever it came from. Until you push your changes.
If you find you have messed up your branch, you can always just delete the whole directory and "git clone" it back again.
And, well, all that branching, merging, rebasing stuff is complex. I almost never need it.
While I agree it can get complex (and I've got into some massive tangles while learning), I disagree on branching/merging. It doesn't have anything to do with GitHub and can all be done on your local machine and local repo. Say I'm working on a new feature and I get a bug report that comes in or stands in my way. That could get messy if you are doing all of your work on the master branch. If you did this, it's much easier:
1) git branch my_feature (makes a new branch locally)
2) git checkout my_feature (checkout that branch to work on)
3) <do work>
4) git add -u (add all tracked changed files, or specific files, whatever you want to do here)
5) git commit -m "Implemented part 1 of new feature"
* Bug report!!! *
6) git checkout master
7) git checkout -b my_bug_fix (make a new branch and check it out - handy shorthand)
8 ) <do work on bug fix, add, commit, etc>
9) git checkout master
10) <Work on whatever, back to the feature, another bug, etc>
11) git merge my_bug_fix (I'm happy with my bug fix, merge it in to master branch)
12) git branch -d my_bug_fix (cleanup your old merged branches!)
13) git checkout my_feature
14) git rebase master (put the changes in my_feature branch onto the new version of what's in master. Adding interactive flag will let you squash commits, respell messages, etc)
It's a bit confusing at first, but is a wonderful workflow.
If you've messed up your branch you can always checkout and older hash to roll back the whole thing or a specific file. git log is your friend there.
My only little point was that for a beginner to git, likely one guy with his hobby project, all that is too much to grasp from the get go.
Point is, git helps with the simple stuff as well. Hack code, save version, hack code, save version. Oh poop I messed up today, get back to yesterday's version and start again....
It's quick and easy. The other powers of git can be acquired with time.
Recently I have been trying to explain to our manager types how it would be better to keep our docs in github so that everyone knows what is what, who changed what and when, and track suggested improvements.
Oh no, they just want to juggle files on dropbox or google docs.
Grrr...
Don't forget physical copies for when the network or site is down.
Way to go!
@Genetix I sympathise with that point of view. I like to stash everything locally.
More and more I find that if there is no network there is no point in continuing.
But this is the beauty of git. If github or bitbucket or whatever goes away, it does not matter. My local repos on my machines are clones.
Have you checked out GitHub pages? Jekyll rendering of anything in a gh-pages branch. Here's an example https://unidata.github.io/unidata-python-workshop/
The docs: https://pages.github.com
Jim
He claimed that he'd proven time and again that it was necessary.
His program was a pre-processor for AutoCAD and people actually paid $17,000/seat for this clunky product.
I look at today's bloated .exe files and wonder how much of this mentality there is, out there.
Back in the C64 days it was amazing what programmers could squeeze into 64K but PC programs are resource hogs.
Small, useful programs can be written in C for PCs. Poor programming and GUIs are the resource hogs.
Far too much!
On the other hand we know that people like Google have invested a lot in creating efficient, optimized, programming environments. Like Clang/LLVM for example. There are some very smart and efficiency obsessed guys working on such things. The Chrome browser, for example, may use a ton of memory but it would be much bigger and slower if they had not put that effort in.
So where does the "bloat" come from? Let's look at a simple example, the "Hello World" program:
int main (int argc, char* argv[]) { printf("Hello World!"); return (0); }What is wrong with that? Can probably be written in a few tens of bytes in assembler.Well, the "Hello World!" probably needs to be in Unicode. Which already requires a huge pile of "bloat" to handle.
Then of course it needs internationalizing, that "Hello World!" should come out in whatever the users language is. Another pile of bloat.
Then of course nobody uses the command line anymore so that needs a GUI Window to open to display the message. Another pile of bloat.
Well, with that GUI you need to support all kinds of fonts, anti-aliasing etc, etc. More bloat.
Now, you might need this program to work on multiple platforms, Linux, Mac, Windows at least. Not to mention iOS and Android. That means using a cross platform GUI toolkit. Another pile of bloat.
It's hopeless. But every byte of that bloat is required.
Easier to use than the command line but not the hog of a full blown GUI.
you're joking, right? Try reading this thread using lynx (https://en.wikipedia.org/wiki/Lynx_(web_browser))
The link does not work because this forum software is broken. The "(" in the URL ends the URL when it should not. Copy it as text and paste into the browser.
I can't get anything but the first page of this thread in Lynx.
@frank,
Oh my God, ClearCase. I still have nightmares about that beast from my time having to use it at Nokia. Even worse than Visual Source Safe.