GIT course

I've just written a post on using git with suggested branch strategies.

Firmware Version Control with GitHub part 1: Branch Strategy for New Features

You may or ( - hey internet - ) may not like the solutions. And I hope I can learn from critique.

I missed your post. Let me see how it matches with what I am already doing. Sure you have a better pragmatic use of Git than me.

Enrico

I was hoping you'd have a better approach than me. Anything that can simplify the work is welcome.

Also anything that makes it more complex  ...

balearicdynamics  wrote:

 

...  pragmatic use of Git ....

 

Enrico

That is what I am focusing on. Use it as a real help. With the lowest complication level possible.

In my job I have to deal (and love to deal) with formal steps, such as code review and code acceptance. I have built them into my blog.

But for my job, for my open source work here, and everywhere, I try to keep it to an adaptable complexity level.

Where I can introduce the ways of working to someone new in half an hour.

And where I don't risk that people become averse or afraid.

Jan, it is great that this is normal for you. The point is this. I love the use of Git to keep track of my own works. SO I use it by 2013, at least as a constant working tool. And in these past years, I always changed (or optimized, or refined) my git adopted strategy for a similar reason you mention. But I have always worked alone, I mean, my projects (job and not) are always been managed under Git but I always found difficult with the developers to accept this methodology. Developers in big companies when there is not an official methodology rarely adopt a way like keeping track of problems and bugs. So my collaborative experience with Git only relates to the big Open Source projects but in this case, the strategy is right for large teams where every branch of the whole project should be kept under control but is oversized and redundant for small teams (1-5 developers). So I see that you have a more pragmatic approach that has a lot of useful suggestions and advice I can refer to adapting a complex strategy to simplified team management.

Enrico

balearicdynamics  wrote:

 

... But I have always worked alone, I mean, my projects (job and not) are always been managed under Git but I always found difficult with the developers to accept this methodology. Developers in big companies when there is not an official methodology rarely adopt a way like keeping track of problems and bugs. ...

It's a people skill. I work in a > 250.000 employees company.

Then most of the resources I work with are changing external parties that I will never see in person.

That's why I levitate to a simple, explainable, defendable, working process.

If you forget to take any player or stakeholder with you, it's not going to happen.

balearicdynamics  wrote:

 

... But I have always worked alone, I mean, my projects (job and not) are always been managed under Git but I always found difficult with the developers to accept this methodology. Developers in big companies when there is not an official methodology rarely adopt a way like keeping track of problems and bugs. ...

It's a people skill. I work in a > 250.000 employees company.

Then most of the resources I work with are changing external parties that I will never see in person.

That's why I levitate to a simple, explainable, defendable, working process.

If you forget to take any player or stakeholder with you, it's not going to happen.

That's why I levitate to a simple, explainable, defendable, working process.

I translated this in a set of fixed commands, easy to do for anyone.

First of all, we aligned on the branch and pull request naming convention. It's based on a request number that's known to everyone when something/anything needs to be done.

When a developer starts:

mkdir <request number>
cd <request number>
git clone https://<URL>
cd <repositoryname>
git checkout -b <request number>
git push --set-upstream origin <request number>

So the request number is know. That's a given in my org. The URL and repository name are a fixed thing.

Those are fixed attributes of the repository you are working on.

This means that a developer - even if the GIT skills are standard - can execute 6 repeatable commands to prepare a working directory to work on a feature.

There are no decisions to be taken, no fuzzy parts. Just a repeatable activity.

Then, while the developer is working:

Do development work in that freshly created directory.

At any (many!) time, the work can be synced to the remote repository.

$ git commit -a -m "<request number> added new attribute"
$ git push

Again, no decisions to be taken, no fuzzy parts. Just a repeatable activity.

Only if new files are added, there's an additional command:

$ git add *

Whenever a developer needs to add a new module, I set a session to explain how the add commands work. And I explain the .gitignore part and ask attention for temporary files in the working directory.

Because we talk, I'm aware on who has a duty to introduce new modules / source files.

Because it's easy to unexpectedly add unwanted files in a repostitory (.tmp and .bak and .mycopy files are annoying. Files with user names and passwords are a drama) - it's good to have the talk.

Either learn how to remove unwanted files before executing the git add, or learn how git add can be used to only add a specific file or directory. Or if needed, learn how to maintain .gitignore.

Then, when development, documentation and technical unit tests are done, the developers use a step-by-step (short!!! simple !!!) guideline to create the pull request.

The repo owners are trained to do the right validations before approving and merging.

Developers are requested to delete the temporary working directory on their PC once the pull request is accepted. To avoid confusions or goof-ups later.

Project developers get an additional training, because they don't work on the master branch. Their process is the same but they don't use the master branch.

This is again repeatable. Bu because devs may get requests from projects and from live code issues, talking helps. There's a decision to be made on what branch to clone from and what branch to create a pull request for.

Up front sessions avoid mistakes later.

All is focused on No Magic, No Surprises. Repeatable steps.

It also reflects how I prefer to use Git and GitHub: as little complexity as needed to get the job done. No geek credits required. Just be able to perform repeatable activities.....

Discuss below

git add

Great summary J. I copied and pasted it to my note book for my next git effort.