[zwiteof]

As an aerospace engineer who codes rather than a software engineer, is there a cheatsheet that talks about how to use git from a "when do I commit/merge/etc" rather than a "this the command to perform commit/merge/etc"? Basically, an "Idiot's Guide to Making My Life Easier with Git"

I've tried to use git a few times at work, but I always end up forgetting to use it for awhile when deadlines start creeping up so it becomes "well, the code works in it's current state and it's been 2 months since I committed, so I should probably update the repo" which doesn't seem much better than periodically backing up the folder.

[jcrites]

I have found the tutorials and references on git-scm.com to be effective. http://git-scm.com/doc

Learning and adopting Git was definitely worth it for me and organizations I've worked with. It provides advantages that are difficult to describe in words and best experienced first hand [1]. Once you understand it, it's like a swiss army knife, or a power tool capable of manipulating source code commits any way one desires. The user experience might not be simple, but the semantics are simple in a way that makes operations easy to perform in Git that are challenging in other source control systems.

You can probably take better advantage of source control than checking in on a monthly basis. Personally, I recommend checking in about every 30 minutes to folks I work with. However, we're used to quick release cycles where code might reach production hours after we submit it, not years. I personally favor frequent commits also because it acts as an additional layer of protection against data loss, as well as facilitating frequent code reviews and visibility by coworkers, frequent integration testing, etc. These benefits support developing code as a team, and support a quick release process.

If you'd like to learn Git, then I'd recommend integrating it into your daily habits such that you're committing regularly, perhaps every 30 minutes to an hour. It will be difficult to learn the tool effectively if you use it only once per month.

[1] I'm happy to try if anyone wishes, but there are plenty of arguments out there. I would summarize by saying that Git simply works better than anything else I've used, including CVS, Subversion, Perforce, etc. Upon familiarizing myself with Git, it feels like those tools, through lack of capability, create a lot of problems and friction that Git avoids.

[amk_]

Maybe this will help with the concepts: https://www.dropbox.com/sh/quumaubjftxik1u/AAD15CT1UrNyOuYSx...

The main point is to make your commits small and incremental, with a single commit adding a single feature (or fixing a bug, etc). If you are reading the commit log, there shouldn't be any surprises as to what a particular commit actually changes when applied. If you have a lot of uncommitted changes, remember that you don't have to add them all at once -- use 'git add file1 file2' and make descriptive messages for each change. Also remember that you can 'rebase --interactive' to fix up your commits locally if you want (don't rebase shared/pushed history, though).

[fiatjaf]

I've had this same problem for a time, but then I realized that forcing myself to commit a lot of times and keep commits meaningful (commits must have a message, and so the committed changes must all be related to that message) also forced me to work in a more focused way: one feature/fix at a time. That is very very good.

[nine_k]

Once you made any noticeable change, it's time to commit. Bonus points for only including files / chunks related to the completed change and not other changes in-flight. This ggives you a nice, annotated history and a way to step back to known state. Many commits a day is the norm.

[georgeott]

Here is my daily git workflow:

1 - Clone the repo (only need do this once)

2 - git checkout branchname

3 - Make some file changes

4 - git add filenames

5 - git commit

6 - git pull (make sure you are up to date BEFORE you push to remote repo)

7 - Build and TEST

8 - git push

That's 90% of what I do.

Merging branches is simple.

1 - git checkout destinationBranch

2 - git pull

3 - git merge sourceBranch

4 - build and test

5 - git push

Cheers!