I agree it is quite intimidating, but the basic version control features are
pretty basic; if you don’t want to branch/merge, you don’t have to. Neither do
you have to do all the git pull/push to another git instance somewhere else.
You can do basic version control on an entire directory with just two commands:
git init
to start controlling the directory and its contents and
git commit –a
each time you want to save the current state into the repository. At this
point you’ve got the same functionality as old-school rcs, plus the ability to
deal with removing, adding and renaming files.
Others have already been eloquent about good reasons to use git in a more
sophisticated way, so I won’t repeat what they’ve said.
git is something you’re going to be forced to use though, anyway, in other
contexts. If you want to participate in pretty much any open source project
now, you do kind of need to know some basic git stuff. I am by no means a git
expert (I don’t know what re-base actually means, for example)
One thing I started doing recently was deploying a containerised application,
the source of which lives on github. I need to make some changes to the docker
configuration to make it work in our network environment, so I have some local
customisations in a branch. Pulling down new versions from upstream is now
pretty simple (and I’ve had to do that every couple of weeks recently).
Manually re-making my changes would be a PITA, but I don’t have to do that
because git merge does it for me. I’m probably doing it wrong, but updating
the system for me becomes a matter of:
git checkout master
git pull
git checkout sanger_prod
git merge master
# check it all worked
git commit –m “Merged upstream for <reason>”
docker-compose up -d --build
Not too painful.
Tim
On 19/12/2017, 16:11, "Beowulf on behalf of Faraz Hussain"
<beowulf-boun...@beowulf.org on behalf of i...@feacluster.com> wrote:
I am curious what people think of git. On one hand everyone seems to
be using it and proclaiming its virtues. On the other hand it seems
way overkill for how the majority of people code.
I maintain dozens of scripts to manage various HPC environments . None
are more than a few hundred lines long. To do backups of scripts, I
just copy them to some backup folder. Occasionally I might tar them up
and copy them to a different server. I have never had a need to go
back to an older version of my script.
So I tried to learn git but find it very confusing. It seems designed
for teams of developers working on some million+ line of code project.
For my rinky-dinky scripts it just adds a lot of confusion. It seems I
need to "commit" to using git everyday in order for it to be
effective. Otherwise, use it or lose it.
Should I force myself to use git everyday? Or maybe find some
incrementally better way to manage backups of my scripts?
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
--
The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
