Git and GitHub are superb tools for software developers and permit you to experiment in ways that were hard to do before. I use Git a great deal in my work and learned it the hard way, if anyone has questions or problems with these you're welcome to ask me for assistance any time.

 

permit you to experiment in ways that were hard to do before

Can you cite examples? I've had git forced on me several times and suffered through the complexity just enough to get my work done. What am I missing?

 

I'm with @402DF855 someone I was working with tried to foist github onto me, to "share" in a project, but by the time he showed me how to set up an account and access various bits I was decidedly unimpressed and just gave him the files on a USB stick! So what are the real uses of it? and how safe is it for projects that you dont want the world to be able to access?

 

These are interesting responses, and I quite understand. There are two reasons IMHO why some resist Git, these are:

1. Confusing terminology where terms (e.g. "checkout") from SVN etc are used in Git but mean different things.
2. The obsession with the command line interface.

There isn't much we can do about 1., there are some concepts that are (I think) often poorly explained though.

As for 2. there is no need to really use the command line, there are GUI tools (by far the best being SmartGit - free for non commercial users) that make Git much easier to understand and use.

If you've approached Git from a command line perspective or been led by someone who uses only the command line, then like I did, you'll end up screaming, it can be very very bewildering - but Git itself is actually very well engineered once you can get to grasp it.

Here's what Git actually does on plain English.

Git manipulates "repositories" a repository is a folder tree, the root folder is the name of the repo. In the root folder are hidden system folders we can disregard, one of these is .git and is where the Git system stores metadata like user info, branch info and commit history.

The way Git operates is that you can "checkout" any commit anywhere in the history and Git will (effectively) reset the folder tree to look exactly as it did when that commit was created. So by checking out arbitrary commits you can reconstitute the entire folder to tree to a state in the past.

This is not always made clear, it is not obvious either but in reality this is exactly what Git does in terms we can understand. Checking out commits is not like checking out some file or anything like that (as it is in SVN etc) it literally means resetting the folder tree to some prior state.

You can thus go back in time or return to the present, this a fast operation too as Git by design does not archive changes to files but entire files so when you go back three months it takes no more time than going back two days, literally a few seconds.

In SmartGit this is done by double-clicking any commit on any branch, no command line BS.

This is huge power, for example you may work one some intricate code for several weeks, changing it and testing it then one day you test some feature you haven't used or tested for some weeks and the app crashes!

You know that feature behaved fine three weeks ago, what the heck? what's going on?

Well this is easy now, you can simply checkout some point in the past (takes a few seconds) then build test the app, if it works then checkout some later commit and repeat, often within a few minutes you'll discover at what point the break appeared and it can only be in the files that were changed in that transitional commit.

This is a huge help for any developer but for people working on MCUs where the tinniest tweak may have a drastic impact, it is amazingly helpful.

This means you can get some degree of stability, ensure the changes are committed and then experiment, if after a day or two you've totally messed the code then no problem you can either look at what changes you made to discover the problem or simply do a reset of your branch to the last working commit (that is you can if you like just abandon the recent work and be done with it - if you want to).

I had Git and GitHub dumped on my and got little help but had to become productive, I've been through the pain with this and can assure you it's actually very slick - don't let previous bad impressions mislead you!

 

foist github onto me, to "share" in a project

That is what Dropbox is for. Git Hub is for public comment and participation, not for private project management. At least that was my perception and yes I am a GitHub member.

 

That is what Dropbox is for. Git Hub is for public comment and participation, not for private project management. At least that was my perception and yes I am a GitHub member.

The firm I'm collaborating with uses GitHub for inhouse work only but servers appear to be self hosted.

I've been through the pain with this and can assure you it's actually very slick

I'm pretty sure all the features you've described apply to most or all version control systems. Full disclosure: I'm of the opinion that git proves that Satan exists and he writes software. Still, I appreciate your comments and experience. Git is pervasive and I do need to be able to use it, so I might as well make the best of it.

Several years ago, working with a previous client, we used Atlasian and some other tools, can't recall exactly. Most every time I tried to commit changes it'd tell me now I had a "detached head". WTH?

So right now, all I use git for is version control to commit my changes to the group. (For actual version control I use my own version control program, which I wrote 21 years ago.) I use a mix of command line and GUI, but here is what I have to do to commit changes to the group:

1) Fetch (make sure my local repo is up to date with the group's)
2) Checkout my branch
3) Pull - in case someone has made changes
4) Checkout a new temporary branch
5) Update the source code with my changes (using my own version control system)
6) Commit my changes to my branch
7) Go to GitHub and create a Merge Request.
8) Approve the merge request (remember to check Delete Temp branch)
9) Fetch (to copy these last changes to my local)
10) Manually delete stale branch even though I check Delete option
11) Checkout my branch (currently temp branch is checked out)
12) Pull (checkout doesn't seem to copy new changes so a pull is required)
13) Manually delete local temporary branch

Each of these operations have scads of options none of which I understand none of which I need to change. God forbid I change one of the myriad defaults; I'll have to shamefully grovel in front of the rest of the group to fix the damage I inflicted.

 

I love git for fully distributed local branching/merge but not for general close networked workflow where a central hub is the code-base 'Truth'. GIT doesn't restrain, it executes. If the programmer pulls the trigger, it fires the bullet. So keep your little programming finger away from the trigger until you know what will happen when you press Enter. The cryptographic basis for GIT local branches and remote branches (content addressable file-system by cryptographic key) is brilliant.

 

I love git for fully distributed local branching/merge but not for general close networked workflow where a central hub is the code-base 'Truth'. GIT doesn't restrain, it executes. If the programmer pulls the trigger, it fires the bullet. So keep your little programming finger away from the trigger until you know what will happen when you press Enter.

The diagram is quite interesting but I have to ask, what's the reason for fetching from your own fork?

Also all of the actions tagged above (e.g. add, merge, etc) can all be accomplished with a mouse-click in SmartGit. With that GUI tool working with Git becomes very intuitive very quickly, it's a bit like having an enhanced Windows Explorer that is aware of changes to files.

The diagram I think conveys working with Git as more complex than it actually is, at least to the novice.

 

The diagram is quite interesting but I have to ask, what's the reason for fetching from your own fork?

Also all of the actions tagged above (e.g. add, merge, etc) can all be accomplished with a mouse-click in SmartGit. With that GUI tool working with Git becomes very intuitive very quickly, it's a bit like having an enhanced Windows Explorer that is aware of changes to files.

The diagram I think conveys working with Git as more complex than it actually is, at least to the novice.

I think much of the confusion about git comes from the central hub idea synchronization idea. I've often used it just to make a local branch into a travel machine that won't touch the net until it arrives home. Then I can run some diffs and cherry pick changes into the original fork before a commit and push.

GIT is an Assembly Language for version control so it can be complex. Using a HLL tool like SmartGit might be a good idea once you have a handle on what you need to do with commands. Like most people I only use a small subset of git capabilities, I'm not an expert.

 

The firm I'm collaborating with uses GitHub for inhouse work only but servers appear to be self hosted.
I'm pretty sure all the features you've described apply to most or all version control systems. Full disclosure: I'm of the opinion that git proves that Satan exists and he writes software. Still, I appreciate your comments and experience. Git is pervasive and I do need to be able to use it, so I might as well make the best of it.

Several years ago, working with a previous client, we used Atlasian and some other tools, can't recall exactly. Most every time I tried to commit changes it'd tell me now I had a "detached head". WTH?

So right now, all I use git for is version control to commit my changes to the group. (For actual version control I use my own version control program, which I wrote 21 years ago.) I use a mix of command line and GUI, but here is what I have to do to commit changes to the group:

1) Fetch (make sure my local repo is up to date with the group's)
2) Checkout my branch
3) Pull - in case someone has made changes
4) Checkout a new temporary branch
5) Update the source code with my changes (using my own version control system)
6) Commit my changes to my branch
7) Go to GitHub and create a Merge Request.
8) Approve the merge request (remember to check Delete Temp branch)
9) Fetch (to copy these last changes to my local)
10) Manually delete stale branch even though I check Delete option
11) Checkout my branch (currently temp branch is checked out)
12) Pull (checkout doesn't seem to copy new changes so a pull is required)
13) Manually delete local temporary branch

Each of these operations have scads of options none of which I understand none of which I need to change. God forbid I change one of the myriad defaults; I'll have to shamefully grovel in front of the rest of the group to fix the damage I inflicted.

GitHub serves as the safe storage for one's work. A repo can belong to an individual or to an organization.

Teams in an organization generally "fork" an organization's repo, these forks serve as per-user "backups" so to speak.

A fork is often described as a copy of another repo but it isn't (it's a virtual copy) however it's fine to think of it that way.

A "fork" is not a Git concept, it is an abstraction created and invented by GitHub.

We have branches created per-project, the branches appear in the organization repo, our forks and our local repos.

Developers each create commits and from time to time push these to their forks (which exist in GitHub) and thus their work gets backed up.

When ready any developer can create a pull request, which if approved causes the new commits on their fork branch to get copied to the same branch in the organization repo, at that point anyone who pulls from the organization repo will get that developers work.

This is how we each get each others changes.

Rebasing is the key to working this way, to rebase means to regenerate one's commits so that they look as if they were done after someone else's work.

Let me explain that more.

Imagine you and I both start working on project_X - at the time we start the latest commit on that branch might be numbered AFFA1CD0.

I may edit some headers and commit that change, this creates a local commit numbered say 03FA8BC2.

You may edit some source file, commit that change, this creates a local commit numbered 34F7B236.

Now my history looks like: AFFA1CD0 -> 03FA8BC2 and your history looks like AFFA1CD0 -> 34F7B236.

Now how can that be converted into a linear sequence? A branch always consists of a sequential set of parent/child commits, predecessor/successor commits.

How can we combine our work so that a 3rd team member can see the results of our changes?

That is what rebase does, it deals with this very elegantly.

Imagine you are done, you push your commit (34F7B236) to your fork, at that point your fork branch sees: AFFA1CD0 -> 34F7B236 you then create a pull request and it gets merged, that point the branch in the main repo also sees: AFFA1CD0 -> 34F7B236.

Now I do a pull (which is almost always from the main repo) and Git tries to pull the new commit down to me, but it cannot unless I tell it to rebase as part of that pull.

Now rebase does this, it sees that there is bifurcation, the main repo has AFFA1CD0 -> 34F7B236 but my local repo has AFFA1CD0 -> 03FA8BC2.

It detects this and automatically "undoes" my commit, pretending that I did not do the work, that is it pretends my branch ends with AFFA1CD0, then it can pull the new commit down, this is all good and neat.

So locally I have AFFA1CD0 -> 34F7B236 my repo has all your changes, but then it remembers my commits and effectively redoes all of the edits as a set of edits on top of your chnages - that I pulled - it then automatically commits these new changes as say 12CF0BD4, this is all automatic - in SmartGit doing a pull will cause all of this to happen in a second or two.

Now my local branch looks like: AFFA1CD0 -> 34F7B236 -> 12CF0BD4 - my original commit (03FA8BC2) no longer exists but the new one 12CF0BD4 contains exactly the same changes, so it looks in the history as if you made your changes and then I made mine, it looks like we worked sequentially but we didn't.

If I try to push to my fork at this point (and I had already pushed 03FA8BC2) then the push will fail because the fork sees AFFA1CD0 -> 03FA8BC2 yet I'm now trying to make that look like: AFFA1CD0 -> 34F7B236 -> 12CF0BD4.

This is the reason we have "force" - used by me exclusively when pushing to my fork (which nobody else sees really).

Force means - in this case - "Look, I know I told you the history was AFFA1CD0 -> 03FA8BC2 but forget that now, just forget it, the history really looks like this now: AFFA1CD0 -> 34F7B236 -> 12CF0BD4"

And Git will do that, and there is no trace anymore of my original commit 03FA8BC2 yet my new commit (generated by the rebase) 12CF0BD4 contains the exact same changes.

Only when the entire lifecycle is grasped does it all start to make sense, understanding Git partially lets you see just 10% of what it's all about.

Multiple developers working in parallel and relative isolation can readily combine their work to make it look as if they all worked in a sequence one after the other.

 

Thanks for the explanation. I made it about 75% through and I got lost. I'll try again, I'm certain you've provided a helpful description. But in my work with git and GitHub I'm dealing with branches and repos (local, central). I've not witnessed the "fork" nomenclature, so will look for it.

 

<..edited..>Forking has been around since the first source control was invented eons ago. If not done properly, forking can lead to a mess.

Having used multiple different source control systems over the years, I would over simplify it like this. SVN is super easy to use, the downside is if you're remote and disconnected from the server, you have no history. Git is a little more complicated, but you still have the full history with you even when disconnected from the server, which is fantastic if you're remote. You just sync with the server when you're back online, then buy doughnuts for your buddies after merging with their code causes a dozen new bugs.

For a public project GitHub (and similar SVN services) is fantastic because it's accessible to everyone. For a private project
a service like GitHub adds some neat bug tracking and note taking features and gives the convenience of storage in the cloud, but it also includes the risk of storing your source in the cloud where it's online 24/7 just waiting for someone to steal. If your primary IP is your source code, this requires some careful consideration.

 

Forking has been around since the first source control was invented eons ago.

To me fork is a UNIX function to copy a process. I thought the way to create a "fork" in a git repo was to use the command "git checkout -b new_branch_is_copy_of_current_branch". Googling I don't see a "git fork" command. Here is the TortoiseGit menu; I don't see a fork option, but it may be in a submenu somewhere.

 

Fork is not Git specific, fork is a general term. At least the way I've used it over the years. For example, say you've got working code to control a refrigerator and now you've been tasked with writing code to control a microwave. Perhaps the refrigerator code would be a convenient starting point, but the products are very different so ultimately the code will be very different. So at this point you fork your code (basically make a copy), and basically create 2 separate projects that will never be put back together as they will diverge over time. Like a fork in the road; the one path has led you to a point where you now have two diverging paths.

A branch on the other hand would be used where your code will be more similar. For example, you've got product version 1.0, so you create a tag v1.0 and release your product. You're busy working on code 2.0 but your biggest customer says hey there is a bug in v1.0 and we want code with only the fix for that bug, we do not want 2.0 because we don't want to re-test everything. So here you create a branch at tag v1.0 an call it v1.1. You create the fix there, release build v1.1 to your customer, then because the code is similar you merge that fix back into the main trunk and continue developing 2.0. Maybe not the best example, but maybe enough to explain the idea?

 

That's all clear but I would have guessed a branch is a divergence from the trunk or another branch (just like a tree). The branch may be permanent or temporary depending on your needs.

My version of git doesn't have a fork command but it does have a branch command.

c:\src> git fork
git: 'fork' is not a git command. See 'git --help'.

 

My experience with git is not very long. And I only use the basic stuff, like push, pull checkout and merge. But I am loving it so far.

 

Thanks for the explanation. I made it about 75% through and I got lost. I'll try again, I'm certain you've provided a helpful description. But in my work with git and GitHub I'm dealing with branches and repos (local, central). I've not witnessed the "fork" nomenclature, so will look for it.

The fork concept is alien to Git, it seems it was invented by GitHub or someone. The problem it solves is that it forces changes to the primary repo to go through a human pull request process. GitHub is able to handle all that because it doesn't need to know about our local (on our PC) repos.

Without forks (and this is easy to experiment with in GitHub) developers must each have their own branch for some project.

Then I would push to my branch project_x.korporal and you would push to your project_x.402DF855 branch and we'd merge from these into the main project_x branch.

In reality this is exactly how it works because a fork is NOT a copy of a repo (it just looks that way to us). In reality a fork is a per-user set of branches in the main repo.

GitHub makes it look to us like a stand alone repo but the fork is really a virtual repo, the master branch in my fork is likely actually named Korporal.master and they simply hide the "Korporal." part when I peruse my fork, so it looks like I have a copy of the repo, I don't I have my own set of branches.

So merging a pull request from someone's fork is really just merging from one branch to another in the main repo.

 

Git and GitHub are superb tools for software developers and permit you to experiment in ways that were hard to do before. I use Git a great deal in my work and learned it the hard way, if anyone has questions or problems with these you're welcome to ask me for assistance any time.

My experience with git is very limited (push, pull, commit, checkout, branch and merge). I use git with command line with github. But I am loving it so far. I like the idea that it can go back any commit in time and test thing out.

What is the one very useful thing that you think new guy like me should learn? Thanks!

 

This is more than one thing, but these are the features I use most often. Versioning and tags, comments on your check-ins and issues (bug reports with numbers), and stash / pop-stash. When fixing issues (bugs) you should reference the issue number in your check-in comment. In GitHub that will automatically close the issue and give you a hyper link from the check-in note to the issue. Revert is very useful, merge is more useful if you're working with a team where you're constantly having to merge with other peoples changes. Diff on commit is super important as it helps you not forget details for your check-in comments. If you use it long enough, at some point clean-up will be necessary. One of my favorite features is history (log), you can easily jump back and forth to points in history and stash to save your changes. And try something like Tortoise Git. I'm a big fan of the command line, but a UI like Tortoise (if on Windows) can really increase your productivity and makes it easier to leverage some of the features of Git. Here's a screen shot of the Tortoise Git context menu. You right-click on any Git repository folder to pull it up:

 

Git and GitHub are superb tools for software developers and permit you to experiment in ways that were hard to do before. I use Git a great deal in my work and learned it the hard way, if anyone has questions or problems with these you're welcome to ask me for assistance any time.

I've never worked on this tool. I have seen many job description for embedded engineer they ask for experience about Git tools. I have never really needed it yet. When should I use this tool to create an embedded project and where what should I use it for ?