> it is very hard to even interview people who are 'white'
This is going to work out sooo well medium term. Esp for a company providing a service with low barrier to entry. Anybody can set up a Git server, or many. In fact a number of other companies are offering Git hosting.
EDIT: They don't have lock-in either. Pulling a project down from Github and pushing it to another remote provider takes only a few minutes, and that customer is gone.
Perhaps it's time for a significant tech company to implode undeniably because of SJW meddling, and serve as an example to other weak CEOs and stupid investors.
You know how we love Apple products because the software is crafted specifically for their hardware. It's the same for Pixelmator in the sense that it's made just for the Mac using Apple frameworks (interesting read about it here) whereas Photoshop has to work on several OSes and is dragging years of old code making it similar in my opinion to iTunes which got bloated along the years.
Having both I systematically go for Pixelmator, it's more intuitive for beginners, more fluid, and just a generally more pleasant experience.
Remember that Pixelmator is a one time purchase where Photoshop can't be bought and requires a paid subscription
Check out this cheatsheet. I have a printed version on my wall. Very convenient. You don't have to buy Tower, the cheat sheet is just focused on git.
Not the OP but Tower is light-years better.
I’d also add:
Paragon’s NTFS for Mac, it’s a bit niche and may not be everyone but helps me write to external hard drives which are NTFS-formatted (extremely common among Windows users)
OmniGraffle. I really like it, much nicer than Visio
Haskell for Mac, if you’re interested in functional programming at all
Time to business. Git is faster, has less merging issues. Being decentralized, you can work while commuting, or while you're not connected.
https://www.git-tower.com/blog/8-reasons-for-switching-to-git/
https://blog.teamtreehouse.com/why-you-should-switch-from-subversion-to-git
Yes, I agree with you. Magit takes away a lot of git's pain. The other client I've seen which also does a fine job is Tower. But, Magit is at an extreme disadvantage to both the CLI and Tower when it comes to performance. Large projects are abysmal to work with in Magit.
Well, if you deleted everything, it won't be that way anymore.
For next time here's a few important commands to know:
git status
tells you what files changed.git diff
tells you what changed in those files.git reset --hard
clears all changesTry this cheat sheet if you want to know more: https://www.git-tower.com/blog/content/posts/54-git-cheat-sheet/git-cheat-sheet-large01.png
Git-Tower has an excellent one. Additionally, they have excellent training and e-book walk-though and provided git sandbox to do exercises to practice. I highly recommend. The cheat sheet is linked on their documentation landing page. Hope this helps!
https://www.git-tower.com/learn/git/ebook/en/command-line/basics/why-use-version-control
You can do stuff like
In short, it provides a structured way to manage development.
Have you already created the repository? You can use Rstudio's version control features which are great. I recommend getting used to using git through the terminal though.
Here is a good cheat-sheet for git commands
If you can provide some more specific questions I will help you as much as possible. I use git quite a lot, and I feel it is very important for everyone to be a good user. It will make your teammates very happy!
Yes there is an easier way, you want to look to the 'commits' of the repo.
Every commit is a screenshot of the code.
Here is a detail description of what a commit is if needed : https://www.git-tower.com/learn/git/commands/git-commit
If you use Github or Bitbucket or any services like those, you'll be able to see what has been change for each commit, what has been added and deleted from each modified files.
In Github and Bitbucket, when you are at the repository address, you can select 'Commits' to access the commits lists, if you click on a commit, you see every modification of repository's code since the previous commit.
If you just need to see the modifications dates and commits messages you can run 'git log' from your local repo on a command line, assuming you get this repo locally and running command on unix OS or with Git Bash for windows installed.
http://gitimmersion.com/ - I find this site to be really helpful.
https://www.git-tower.com/learn/ - This one seems promising as well, never tried it though.
Also, make sure to get familiar with VIM as well, it will help a lot, specifically knowing the key commands. http://bullium.com/support/vim.html has a very comprehensive list of key controls, there's also a vimtutor editor that has a tutorial built in, I'd have to Google how to set it up but that's another viable option.
This is a good intro to what you need to learn. A very important thing to take away from it is the second heading: you cannot break things. Other than that it merging actually pretty self explanatory and git itself will guide you through most of it.
I guess, take an hour or so and go through this Git Tutorial powered by Github. If, after tutorial completion, you still feel difficulty grasping what and how about Git (version control), read this.
If you know a little bit, know basics, basic enough to get the job done but aren't sure about commands of Git, refer to this awesome cheat sheet.
I am sure you can figure out how to compile and work with the project once you are familiar with Git as you mentioned, "I know algorithms and how to code in C++ as well as a CS Degree and learned C++ for a long time.". Isn't compiling one of the first things you should learn in C++? Just curious.
I wish you luck however, no matter, we all have to start somewhere.
I spent today reading this because I have been using VCS to just push commits in a never-ending chain. At least it got utilized a few times referencing old function versions and saving me from some bad data loss once. That said I quit doing it when I got tired because the system wasn't giving me any useful information. That's because I was doing it wrong.
Git +$12/mo for base + lfs storage. How you use it is more important than using it. Today I read most of this:
https://www.git-tower.com/learn/git/ebook/en/desktop-gui/basics/what-is-version-control#start
My intention is to start a new blank project and repo, and then to break my old project into it doing stuff properly. Just using the GUI apps sort of let me put the cart before the horse, and as a result a couple times I broke my repo and had to re-base it losing my useful version history. Don't do that.
I haven't been able to find any good idea other than Git+LFS, either, I'd like to hear other people's input...
Yea, that's definitely a diff program of sort. I'm used to these, which is intended for code which isn't exactly what you're looking for.
I'm glad s3bbi was able to shed more light on it though!
If you don’t mind paying for it, Tower is now available on Windows. Used to be Mac-only. However there’s no Linux version: www.git-tower.com/windows
There’s also a good tutorial if you want to improve your usage of Git on the command line: https://www.git-tower.com/learn/
That's totally normal at the beginning ! https://www.git-tower.com/blog/git-cheat-sheet/ Use this to help you :). I advise you to do the same for other subjects, keep a cheat sheet always next to you and with practice you won't need it anymore. Also you should try to work on little side project, that's the best way to learn stuff in my opinion.
Very different check their website. I have all Affinity apps (both Mac and iPad) and all Pixelmator Apps (also both Mac and iOS).
I really enjoy using Affinity Designer and Publisher but for everything related to photo editing I really prefer using Pixelmator apps over Affinity Photo.
I find the UI/UX much more intuitive and enjoyable. More straight to the point if you will.
Plus Pixelmator uses native Apple frameworks giving them a very native feel.
We use the Tower application to talk to a private Gitlab server. It’s all graphical and they have a really expansive tutorial.
I find it easier than Beckhoff’s default visual studio integration.
Note all of Git only works well with text based files.
1: You can use cherry pick to grab commits from other branches and apply them to the current branch. Check out this article on "rewinding" to older commits
2: You could either make a new repo and just push all your files to it, or you can just add the github repo as a remote origin and push all of your commits/branches to it
3: See #1
For 1 and 3, though, if the changes were small I would consider just doing a git-sneak and manually copying the changes over. Yeah, it's "cheating", but git is a tool and tools are supposed to make your life easier.
The actual f*ck. Did you just create a post that's nothing but a straight copy-paste from the Tower FAQ page? https://www.git-tower.com/learn/git/faq/handling-large-files-with-lfs/
Git out of here.
Git Tower. I've used it since it came out and it has a lot of useful features. I'm generally not a fan of the command line if there's a decent GUI available.
The company changed to a subscription model a couple of years ago, which isn't ideal, especially if you want on-prem functionality (i.e. you're using it on your company's internally hosted GitHub, GitLab, etc. system), which costs another $30 per year extra. My employer pays for my license; if they didn't I'd likely go find something that wasn't subscription based.
I've had situations where someone has done a "rest of the owl" type commit and then we need to go back and fix one thing and can't do it because I can't do various git tricks to change one commit to something else... or I can't cherry pick one change from the "rest of the owl" into a different branch.
Commit Granularity is a good read on the subject.
If you've got an IDE that works well with git, try doing an "interactive rebase" of a branch that you haven't pushed yet.
https://www.jetbrains.com/help/idea/edit-project-history.html#interactive-rebase
https://www.git-tower.com/help/videos/more-productive-in-git/interactive-rebase
Note the caveat of "don't do this on published branches." The key is that if you have small commits, it's easier to fix things later.
You might not want to hear this, but honestly, you should start looking for other jobs.
Have a read, but I'm sorry, your boss is completely incompetent: https://www.git-tower.com/learn/git/ebook/en/desktop-gui/basics/why-use-version-control
Ok, so let's clarify something real quick. Do you have 2 remote repos connected? One is origin and the other is upstream?
If that's the case, you may need to link your remote branch to your local one. Because git would automatically create a local branch if you are checking out a remote branch.
You can see more details with "git branch -a".
Also, check your .git/config file and make sure everything in there looks good.
I'd first do a "git fetch --all" to make sure you have the most up-to-date branch pointers.
Then, do "git branch -u <remote branch with prefix>" this will link your local branch with the remote one.
Here's a link for other strategies: https://www.git-tower.com/learn/git/faq/track-remote-upstream-branch
Not quite. Git and svn work a bit differently. Here's a cheat sheet that should help you transition. If you're just doing local development you don't need a remote so you don't need to push anywhere.
I found this website pretty helpful:
https://www.git-tower.com/learn/git/ebook/en/command-line/basics/what-is-version-control#start
Came to know about it via the odin project
>but I've since lost the code.
ALWAYS use source control! Never write a single line of code if it's not source controlled!
https://www.git-tower.com/learn/git/ebook/en/command-line/basics/why-use-version-control
(Version control == source control)
If I'm reading this right, wouldn't you only be able to revert back to the code for your last commit of that era (before signing the contract) and release that? You can checkout an old project state.
When you click on the merge commit in Tower, you will see its Parent Hashes on the right hand side panel that contains all the commit information.
Usually, by naming convention the commit message should indicate which branch was being merged at the time.
You could also give the command git name-rev. Given a commit, this command will find where it is relative to the local refs. To do this, open Terminal from Tower (File -> Open in Terminal, or you can use the toolbar shortcut), this will take you straight to the repository. Then, try the command git name-rev <SHA>
, replace SHA with the first parent's commit hash to find the branch you were on when the commit was merged, and with the second parent's commit hash to find the branch that was merged.
Regarding the graph, it is only there for one reason: to help you understand when and where branches were merged into each other. You can't rely on a specific arrangement in whatever way; there's no guarantee in "master" being the leftmost branch.
The graph becomes more manageable by reducing it to only certain branches. See here (under "Partial / Combined History") for a hint: https://www.git-tower.com/help/commit-history/display-commits
Hi stranger. I recently needed to use git for this situation as well.
Read through the first chapter. Walks over how to use it to how to transfer their code. https://www.git-tower.com/learn/git/ebook/en/command-line/basics/basic-workflow#start
Here’s a cheat sheet:
https://www.git-tower.com/learn/cheat-sheets/git
Godspeed.
Though I can use the command line git client, I spend most of my source code management time in Tower: https://www.git-tower.com It’s a fantastic UI on top of git’s powerful tools. I’m sure it doesn’t do everything the CLI tool can do, but it handles my day to day tasks quite well.
That logo is used on some of their other cheat sheets
https://www.git-tower.com/blog/command-line-cheat-sheet/
If you download there cheatsheet pack, even the command-line one is different from the one on the webpage.
... Maybe it's authentic.
Github has a great into course... it's not too hard to understand the base concepts. The only thing that's difficult/pesky is merge conflicts. I use this cheat sheet at work whenever I need a reference.
For gamedev Git may not be the best version control system out there when it comes to larger binaries and assets etc. There's other system such as PlasicSCM that's more tailored towards gamedev which intergrates with Unity/Unreal engine as well as a thing they call "GitSync" that may be worth checking out. Several game studios is using it.
https://www.plasticscm.com/games/
I personally use Git-Tower because it's the only one that isn't getting in my way of my work compare of every other GIT gui I've tried. If I'm not using git-tower I'm using the terminal.
This is the app: https://www.git-tower.com/ I bought it after reading good reviews about it.
And yes I have moved to using the command line after this experience. I'll look into what the fetch button in tower does exactly, just to get to the bottom of this.
I can recommend Tower. I've used the Mac version for a couple of years and it's an excellent tool. It's free right now while in Beta, but will go pay-only after that, I'm sure.
Just want to mention that yesterday I received an invite email from Git Tower about the Windows Git Tower beta (I signed up for it back in July). I won't be able to check it out until I wrap up a big project I'm on, but if you're interested in a Git GUI, you might want to try signing up for the beta at:
Right -- rolling back within git is what I meant however.
Main advantages:
The list really goes on.
This would obviously be pertinent to people seeking collaboration tools with a mod team of 2 or more I'd assume, but you'd still be able to get the features if you were modding your own subreddit by yourself. For example for us over at /r/bengals, we have 4 people total that touch the CSS files. Obvious reasons, this whole thing would make sense.
Does that make sense?