GIT Time again - what am I missing?
-
So, as a side project, I've been delving into the git source control world (triggered by Visual Studio incorporating it), and I'm smelling something nasty. As in, what's the point, other than preference? I've insisted all of my development projects be in source control since the mid 80s. Back then, we were heavily developing on VMS, the version control system was CMS. I'm not sure back then we had the concept of branches and what not, but we could tag the code base for a specific release. I ran into one developer who kept his changes as file versions - it's a VMS thing. All it took was one purge command to lose ALL of the history.. shudder. Anyway.... So in the years to follow, I've motored through PVCS, ClearCase (shudder), VSS and SVN. After VSS burned me badly (there are many unflattering stories out there) due to a network outage, I transitioned all of my source control to svn. Supports concurrent development, tags, branches and merging and is far more robust than VSS. This would be about 15 years ago or so. Along comes this git upstart. And all of the comparisons between it and svn generally say git is better for concurrent development, blah blah blah. Oh and it's a distributed model. And it allows for branching, etc. Just like SVN. Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not. I nod to preferences, but can anyone provide real world examples of how git solved a version control problem better than svn? The most common "feature" articles say about git is some mumbling about not needing a central repo which makes no sense to me. Appreciate your thoughts.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
With git, you get two vcs for the price of one. You have a local one and probably a remote one. At work asking for a repo was heavy paperwork. With svn I had no opportunity to put my small projects into version control. With git I can create a local repo without involving paperwork or someone from the sudoers group. In git, the master repo can be protected by using pull requests instead of just giving rights to push into the master repo.
-
See that's the other thing. I would NEVER have company code out on GitHub. Source code is the Crown Jewels and the jewels stay on the premises. I do know you can set up your own server locally, or I think I read about that.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
charlieg wrote:
I do know you can set up your own server locally
You certainly can - I have a Git server on my Synology NAS as a local backup, and I've had a locally installed instance of [Gitea](https://docs.gitea.com/next/category/installation) in the past.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
So, as a side project, I've been delving into the git source control world (triggered by Visual Studio incorporating it), and I'm smelling something nasty. As in, what's the point, other than preference? I've insisted all of my development projects be in source control since the mid 80s. Back then, we were heavily developing on VMS, the version control system was CMS. I'm not sure back then we had the concept of branches and what not, but we could tag the code base for a specific release. I ran into one developer who kept his changes as file versions - it's a VMS thing. All it took was one purge command to lose ALL of the history.. shudder. Anyway.... So in the years to follow, I've motored through PVCS, ClearCase (shudder), VSS and SVN. After VSS burned me badly (there are many unflattering stories out there) due to a network outage, I transitioned all of my source control to svn. Supports concurrent development, tags, branches and merging and is far more robust than VSS. This would be about 15 years ago or so. Along comes this git upstart. And all of the comparisons between it and svn generally say git is better for concurrent development, blah blah blah. Oh and it's a distributed model. And it allows for branching, etc. Just like SVN. Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not. I nod to preferences, but can anyone provide real world examples of how git solved a version control problem better than svn? The most common "feature" articles say about git is some mumbling about not needing a central repo which makes no sense to me. Appreciate your thoughts.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
I used to use SVN years ago. I recall there were a few minor annoyances, but by and large it was a good bit of kit, and TortoiseSVN was a good UI. In more recent years I've used Mercurial. Like Git it lets you have one (or many) local copies of everything on the server, which can be handy for speed or if you might have periods where you can't access the server. It also means that if the server catches fire, there's a fair chance people will have a copy of the source code somewhere. TortoiseHg has Mercurial covered. It's a good UI and like SVN, things work pretty smoothly most of the time. Fairly recently our team moved to Git. So far it seems very much that "Git" is rhyming slang. The Tortoise offering offers far less for Git. There are a lot of Git UIs out there, but it's tough to find a good one, especially if it needs to be free. Visual Studio does sort of okay on that front. As a result, I do a lot on the command line when using Git. Git's concept of branches, to me at least, seems far weaker than Mercurial's. It just seems to keep a record of the latest changeset for each branch and keeps a record of the parent changeset. Finding your branch's parent branch is at best tricky, at worst impossible. For me, Git has few if any advantages over Mercurial, and as a bonus has an unpleasant learning curve and unnecessary complexity. The whole world apparently disagrees with me, but I wouldn't recommend it to anyone as long as Mercurial is available. But if SVN is serving you, there's no shame in sticking with what you know, either. You could give Git or Mercurial a test drive on a personal/mini project if you want to see if the grass is truly greener (spoiler: with Git, it's less grass and more wasteland with bonus fly-tipping).
-
So, as a side project, I've been delving into the git source control world (triggered by Visual Studio incorporating it), and I'm smelling something nasty. As in, what's the point, other than preference? I've insisted all of my development projects be in source control since the mid 80s. Back then, we were heavily developing on VMS, the version control system was CMS. I'm not sure back then we had the concept of branches and what not, but we could tag the code base for a specific release. I ran into one developer who kept his changes as file versions - it's a VMS thing. All it took was one purge command to lose ALL of the history.. shudder. Anyway.... So in the years to follow, I've motored through PVCS, ClearCase (shudder), VSS and SVN. After VSS burned me badly (there are many unflattering stories out there) due to a network outage, I transitioned all of my source control to svn. Supports concurrent development, tags, branches and merging and is far more robust than VSS. This would be about 15 years ago or so. Along comes this git upstart. And all of the comparisons between it and svn generally say git is better for concurrent development, blah blah blah. Oh and it's a distributed model. And it allows for branching, etc. Just like SVN. Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not. I nod to preferences, but can anyone provide real world examples of how git solved a version control problem better than svn? The most common "feature" articles say about git is some mumbling about not needing a central repo which makes no sense to me. Appreciate your thoughts.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Subversion is not distributed. What this means practically is that there's no command like "git push", and this means that committing requites a working network connection to the source control server. You can't rewrite history, because every commit immediately goes to the server. You can't commit when not online, so you're forced to be on a reliable connection if you want to have small, clean commits. And if the upstream subversion server dies, the history is gone, where with git, every client that clones with the default options has a full copy of the history. There are other subtleties, but the above are a large part of why got was created for and adopted by Linux kernel maintainers by Linus himself.
------------------------------------------------ If you say that getting the money is the most important thing You will spend your life completely wasting your time You will be doing things you don't like doing In order to go on living That is, to go on doing things you don't like doing Which is stupid. - Alan Watts https://www.youtube.com/watch?v=-gXTZM\_uPMY
-
So, as a side project, I've been delving into the git source control world (triggered by Visual Studio incorporating it), and I'm smelling something nasty. As in, what's the point, other than preference? I've insisted all of my development projects be in source control since the mid 80s. Back then, we were heavily developing on VMS, the version control system was CMS. I'm not sure back then we had the concept of branches and what not, but we could tag the code base for a specific release. I ran into one developer who kept his changes as file versions - it's a VMS thing. All it took was one purge command to lose ALL of the history.. shudder. Anyway.... So in the years to follow, I've motored through PVCS, ClearCase (shudder), VSS and SVN. After VSS burned me badly (there are many unflattering stories out there) due to a network outage, I transitioned all of my source control to svn. Supports concurrent development, tags, branches and merging and is far more robust than VSS. This would be about 15 years ago or so. Along comes this git upstart. And all of the comparisons between it and svn generally say git is better for concurrent development, blah blah blah. Oh and it's a distributed model. And it allows for branching, etc. Just like SVN. Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not. I nod to preferences, but can anyone provide real world examples of how git solved a version control problem better than svn? The most common "feature" articles say about git is some mumbling about not needing a central repo which makes no sense to me. Appreciate your thoughts.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Git is an excellent tool for a very specific use case that 99.9% of projects don’t fall into. It’s great if you have a massive source base with many geographically dispersed contributors who don’t always have reliable Internet connectivity. Vastly overcomplicated, IMO for anything else.
-
So, as a side project, I've been delving into the git source control world (triggered by Visual Studio incorporating it), and I'm smelling something nasty. As in, what's the point, other than preference? I've insisted all of my development projects be in source control since the mid 80s. Back then, we were heavily developing on VMS, the version control system was CMS. I'm not sure back then we had the concept of branches and what not, but we could tag the code base for a specific release. I ran into one developer who kept his changes as file versions - it's a VMS thing. All it took was one purge command to lose ALL of the history.. shudder. Anyway.... So in the years to follow, I've motored through PVCS, ClearCase (shudder), VSS and SVN. After VSS burned me badly (there are many unflattering stories out there) due to a network outage, I transitioned all of my source control to svn. Supports concurrent development, tags, branches and merging and is far more robust than VSS. This would be about 15 years ago or so. Along comes this git upstart. And all of the comparisons between it and svn generally say git is better for concurrent development, blah blah blah. Oh and it's a distributed model. And it allows for branching, etc. Just like SVN. Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not. I nod to preferences, but can anyone provide real world examples of how git solved a version control problem better than svn? The most common "feature" articles say about git is some mumbling about not needing a central repo which makes no sense to me. Appreciate your thoughts.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Whenever I want to use source-control, I use my SVN that is installed on my own server. However, I have used it with production projects in the past and it works just fine for concurrent development and anything else one may need. Git is Microsoft's replacement where everything is saved online, unless you install Git to a local server. Many don't, so Microsoft gets access to a lot of the source-code that is part of Open Source projects. I find SVN very straight forward to use, once I figure out the links that I have forgotten. However, Git is a completely new ball of wax that I would rather pass on...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
So, as a side project, I've been delving into the git source control world (triggered by Visual Studio incorporating it), and I'm smelling something nasty. As in, what's the point, other than preference? I've insisted all of my development projects be in source control since the mid 80s. Back then, we were heavily developing on VMS, the version control system was CMS. I'm not sure back then we had the concept of branches and what not, but we could tag the code base for a specific release. I ran into one developer who kept his changes as file versions - it's a VMS thing. All it took was one purge command to lose ALL of the history.. shudder. Anyway.... So in the years to follow, I've motored through PVCS, ClearCase (shudder), VSS and SVN. After VSS burned me badly (there are many unflattering stories out there) due to a network outage, I transitioned all of my source control to svn. Supports concurrent development, tags, branches and merging and is far more robust than VSS. This would be about 15 years ago or so. Along comes this git upstart. And all of the comparisons between it and svn generally say git is better for concurrent development, blah blah blah. Oh and it's a distributed model. And it allows for branching, etc. Just like SVN. Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not. I nod to preferences, but can anyone provide real world examples of how git solved a version control problem better than svn? The most common "feature" articles say about git is some mumbling about not needing a central repo which makes no sense to me. Appreciate your thoughts.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Is Git superior to all of those systems that came before it? Maybe, but it doesn't matter. What's important is all of the tooling and devops processes that are now based on Git and the services that have been built around it. That's what makes it essential for most software/IT shops these days. A few years ago I made a tutorial for our users who had the same question as you...what is this and why should I care?
-
Is Git superior to all of those systems that came before it? Maybe, but it doesn't matter. What's important is all of the tooling and devops processes that are now based on Git and the services that have been built around it. That's what makes it essential for most software/IT shops these days. A few years ago I made a tutorial for our users who had the same question as you...what is this and why should I care?
-
"source control is not a backup" true words. But I have it on IT's assurance that they are imaging the VM server hosting our code. Years ago, I submitted an IT ticket to verify our backups. This created a tornado of panic. What do you mean the backup is bad? No, I asked you how do you know it's good. As for your other comments about libraries and common code bases, well I gave up on that 10 years ago. ctrl-c/ctrl-v is our inheritance process :(. I'll admit that we're a very embedded product oriented shop, but I'd still like to see common code isolated to one area. Like I do, but I lost that battle long ago.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
charlieg wrote:
Like I do, but I lost that battle long ago.
Did you mention due diligence and legal costs associated with copyright violations? I like to point that out when someone complains because I insist the find the license. That due diligence comment really makes C level execs perk up.
-
When we were using SVN, I still have it on my local machine, we could do all the work locally too. Perhaps an advantage of Git, which I missed is the concept of the PR (Pull Request). With SVN we were able to commit to trunk without any sort of approval. So I could get changes through to production without anyone else seeing the changes. With Git nothing get's merged into Main unless it has been code reviewed and the PR has been approved. This is a really useful safety net meaning at least one other person has looked at our changes before they are allowed to be merged into Main/Trunk.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
With Git you don't just have all the code on your local machine, you also have (or can have) all the branches, versions and tags on the local machine. That way you can compare or even revert code with any prior version without connecting a centralized server. Now when you want to share your changes, you can connect and push to say GitHub and pull to get changes from other users. Branching in Git is also more lightweight since it isn't a full copy of the code base. BTW, while PRs are useful and desirable when working with other developers, they are a feature of online git services like Github and Gitlab not Git itself. Depending on your settings/configuration, you CAN push changes to main (trunk) without anybody seeing it first.
-
So, as a side project, I've been delving into the git source control world (triggered by Visual Studio incorporating it), and I'm smelling something nasty. As in, what's the point, other than preference? I've insisted all of my development projects be in source control since the mid 80s. Back then, we were heavily developing on VMS, the version control system was CMS. I'm not sure back then we had the concept of branches and what not, but we could tag the code base for a specific release. I ran into one developer who kept his changes as file versions - it's a VMS thing. All it took was one purge command to lose ALL of the history.. shudder. Anyway.... So in the years to follow, I've motored through PVCS, ClearCase (shudder), VSS and SVN. After VSS burned me badly (there are many unflattering stories out there) due to a network outage, I transitioned all of my source control to svn. Supports concurrent development, tags, branches and merging and is far more robust than VSS. This would be about 15 years ago or so. Along comes this git upstart. And all of the comparisons between it and svn generally say git is better for concurrent development, blah blah blah. Oh and it's a distributed model. And it allows for branching, etc. Just like SVN. Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not. I nod to preferences, but can anyone provide real world examples of how git solved a version control problem better than svn? The most common "feature" articles say about git is some mumbling about not needing a central repo which makes no sense to me. Appreciate your thoughts.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
I've had the same thought for awhile now. I loved SVN and sometimes even went as far as copying the server's SVN folder to recreate the history & branches anywhere else in case I needed to. It was quite elegant otherwise (and being a developer of traditional closed-source commercial software it was just perfect). I did everything in command line then and I still do with GIT, but man that thing can lead you to headaches (that most of the time can only be resolved via command line). Probably GIT's only two advantages are: 1.- It's harder to fuck up when you forget to push and you get lost in your thousands of commits. You just git clone somewhere else and start comparing copies in the worst case scenario. 2.- I don't have to cron a backup of the server side SVN repository to backup the entire history & branches...git clone is precisely that.
-
Sounds like how I work. I tool away for a couple of days; if I was on the right track, I compile, zip and save that version to a remote drive with a dated file name. Or start over. Repeat evey few days. No branches, twigs, leafs, buds, flowers, weeds. Sort of like how we did backups in the "old days". Except there are no carts with card trays or portable disk packs.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
For one man teams that are diligent, it can work. When you get to more than one, it rapidly gets out of control. I still remember the day when I was cleaning up the project folder... and I purged all the versions. I had no idea. He almost had an aneurism... took a few deep breaths and explained to me why he had a twitch in his eye :) It's not like I was on a mission, I was trying to help free up some disk space we needed... So, there I was with this "I just took a bite out of a ****-sandwich" on my face. Took a deep breath and said, "let me pull the backup tapes..." Thankfully they were from the day before and good. This was the day I had a career epiphany - delete nothing. Move it, archive it, but delete be bad.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
There's nothing inherently better in GIT compared to other modern source control systems. It does what it advertised to do. The 2 models are just different (centralised vs distributed) I've worked with SourceSafe, RCS, CVS, SVN, GIT and now Team Foundation. I came to love/hate git; mostly because it's so cryptic.
CI/CD = Continuous Impediment/Continuous Despair
The part that had me confused is that ultimately, all code *must* go back to the main server - just like SVN. What I did not comprehend is that when you pull a project from a GIT repo it's almost as if you copied the repo to your local machine. Once you push your changes back to the server, the magic of software kicks in, there is smoke and flashes of light and it all gets put back together. I'm not sure if that justifies hyperventilating over GIT, but I understand the subtle difference now. as other's have commented, it was born of distributed open source development. I live in a proprietary internal network with fiber everywhere, so I just did not see the "glowing" points for GIT. At the end of the day, it's just another source control system.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
charlieg wrote:
Like I do, but I lost that battle long ago.
Did you mention due diligence and legal costs associated with copyright violations? I like to point that out when someone complains because I insist the find the license. That due diligence comment really makes C level execs perk up.
" copyright violations?" Please elaborate, I'm not following you. All of our code belongs to us. As for your description of enterprise level development, holy cow, I've not done anything like that in 20+ years. Thinking back to when I did gave me a headache :)
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
With git, you get two vcs for the price of one. You have a local one and probably a remote one. At work asking for a repo was heavy paperwork. With svn I had no opportunity to put my small projects into version control. With git I can create a local repo without involving paperwork or someone from the sudoers group. In git, the master repo can be protected by using pull requests instead of just giving rights to push into the master repo.
to be fair, that's not an svn issue - it's a process issue. For our SVN server, you want a repo, we RDP in and make a repo, though I see the point that it's a manual operation. We don't have a lot of developers just wanting random repos, so valid point.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
I was using SVN briefly when I was on first job after university so I might not remember it correctly but I remember frustrations it was giving me and I hated it with every piece of my body. Using GIT was a breeze and I instantly got the mental model, so I might be biased for using it for last 14 years and remembering SVN workflow as workflow from hell. So I have a lot to write on the topic - because I feel that GIT is just so much better and it makes me much better developer and development so much easier. Let's start with not needing connection to the server to be able to create commits. When internet is down I still can create commits move them around and publish to server when I want not when SVN wants. Also if I have it locally it is much faster to commit anything than over the network. (almost no one uses fully distributed workflow so yeah) Branching is something you just do in GIT and you don't have to ask anyone because branches don't live on the server. I can do 10 commits then go back to starting point and make new branch in matter of minutes and have different approach developed, I can delete local branch that I don't like and publish stuff I do like. No one will ever see it. Conflicts, I can fetch changes from remote repository and have my local branch separate, I can keep on working on my stuff until I want to merge things while also having possibility to easily switch to. With SVN I am forced to deal with stuff even when I am half way done but I also want to check what is there so I could prepare for it. In general mental model for having undo outside code editor that I can view and cherry pick, staging chunks of files to move parts of my development outside of IDE - because some things can be added by IDE and I can control what I publish in perfect way gives me ease of mind. Where SVN tooling was rudimentary at best, maybe it changed as I not used it.
"Let's start with not needing connection to the server to be able to create commits" This is the key difference that is NOT well explained when comparing GIT to SVN. The fact that you can have all of the source control actions local including comments and what not falls under what I would call a "useful feature." :) In my shop, any developer can create branches and tags and have done so for years. So, when people say "branching is a breeze in GIT as compared to SVN" no brilliant flash of the obvious came to mind. The only thing that MUST be done as an admin is to create a new repo.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
to be fair, that's not an svn issue - it's a process issue. For our SVN server, you want a repo, we RDP in and make a repo, though I see the point that it's a manual operation. We don't have a lot of developers just wanting random repos, so valid point.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
I am an application operator, so I do not have Administrator / root rights anywhere, I don't have remote login rights, etc. With centralized VCS, I need a sudoer to create a repo. With git + TortoiseGit, I can make a local repo anywhere, and at least track my scripts. This is centralized vs. distributed, svn vs. git. (At home I use svn, because, as we say here, everything is beautiful at home, 6 cores, 12 threads, 32 GB of RAM and sudo rigths ;) )
-
So, as a side project, I've been delving into the git source control world (triggered by Visual Studio incorporating it), and I'm smelling something nasty. As in, what's the point, other than preference? I've insisted all of my development projects be in source control since the mid 80s. Back then, we were heavily developing on VMS, the version control system was CMS. I'm not sure back then we had the concept of branches and what not, but we could tag the code base for a specific release. I ran into one developer who kept his changes as file versions - it's a VMS thing. All it took was one purge command to lose ALL of the history.. shudder. Anyway.... So in the years to follow, I've motored through PVCS, ClearCase (shudder), VSS and SVN. After VSS burned me badly (there are many unflattering stories out there) due to a network outage, I transitioned all of my source control to svn. Supports concurrent development, tags, branches and merging and is far more robust than VSS. This would be about 15 years ago or so. Along comes this git upstart. And all of the comparisons between it and svn generally say git is better for concurrent development, blah blah blah. Oh and it's a distributed model. And it allows for branching, etc. Just like SVN. Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not. I nod to preferences, but can anyone provide real world examples of how git solved a version control problem better than svn? The most common "feature" articles say about git is some mumbling about not needing a central repo which makes no sense to me. Appreciate your thoughts.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
The point of GIT, and what it's trying to solve basically boils down to this: 1) The repository lives on your local OS file system. What that offers is a way to version control anything you want (more on text vs. binary ahead), and can sneaker net the entire repository with the copy command without losing version information of changes! All of the deltas and history are all contained in a nice neat folder named .git. 2) You can also (instead of sneaker net) host the source code on a remote server, which allows anyone with the necessary privileges to pull or commit changes. 3) You can apply filters on what files are committed (checked-in for SVN/SourceSafe users) using the .gitignore file. This text file lets you filter out compiler files (e.g. .objs) and auto-generated files (e.g. files that change by the build process and cannot/should not be modified). 4) The real power comes in with the versioning. Every commit from the first repository creation is demarcated with a SHA. Git SHAs are unique identifiers for commits, files, and other objects in a Git repository. 5) What can you do with SHAs? You can branch off of anywhere to create a separate set of commits unique to that branch. Example: You might want to branch at a project release point, so that development can continue while changes are frozen. Here is where real power lies. Devs have the ability to continue to make commits to the branch (e.g. a QA branch when devs get feedback on bugs to make fixes), while development continues along the main line. When the QA branch is blessed and has all of the fixes necessary to promote to release, the changes can be merged back into the main line. While most of that can be automated, some user interaction might (often will) be necessary to resolve conflicts. 6) In projects of 2 or more devs, typically there are multiple concurrent branches. Example: Development, QA and Release. Depending on the shop, some choose to branch to make a latest QA, some merge the latest dev line into a separate QA line. There are variations on the theme, but the takeaway is that you can make Git adapt to your dev culture, and not the other way around. 7) Lastly, there are "stupid Git tricks" that can make life easier (and more complicated, depending on your perspective). Example: One can Rebase to get to a "clean" state. A rebase will simply drop merge commits from the todo list, and put the rebased commits into a single, linear branch. Rebase, along with <
-
" copyright violations?" Please elaborate, I'm not following you. All of our code belongs to us. As for your description of enterprise level development, holy cow, I've not done anything like that in 20+ years. Thinking back to when I did gave me a headache :)
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
"Let's start with not needing connection to the server to be able to create commits" This is the key difference that is NOT well explained when comparing GIT to SVN. The fact that you can have all of the source control actions local including comments and what not falls under what I would call a "useful feature." :) In my shop, any developer can create branches and tags and have done so for years. So, when people say "branching is a breeze in GIT as compared to SVN" no brilliant flash of the obvious came to mind. The only thing that MUST be done as an admin is to create a new repo.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Yeah that is for me "distributed" part that is basically killer feature. Unfortunately people throw "distributed" around like everyone should be mailing patches to Linus himself and other contributors just like it is some holy grail - but no one uses it like that so everyone only gets more confused.