38 Replies Latest reply on May 9, 2020 8:45 AM by colporteur

    GIT course

    dougw

      It might be useful to present an introduction and basic user guide to GIT repository …..

        • Re: GIT course
          beacon_dave

          This free eBook download via Apress Open may be of interest in the meantime ?

           

          Pro Git

          • Authors 
          • Scott Chacon
          • Ben Straub

          https://link.springer.com/book/10.1007%2F978-1-4842-0076-6

          5 of 5 people found this helpful
            • Re: GIT course
              balearicdynamics

              I oblige all my collaborators to download and read this book. That is also on my Kindle

              1 of 1 people found this helpful
              • Re: GIT course
                beacon_dave

                Springer Link also have a free textbooks  'Covid 19 package' on the go at the moment:

                https://link.springer.com/search?package=mat-covid19_textbooks&showAll=true

                 

                Amongst others, there are some books on Verilog and VHDL in there and on Python 3, which may be of interest to those doing the PYNQ workshop.

                 

                Peter Corke's book on Robotics and Machine Vision is in there  

                5 of 5 people found this helpful
                  • Re: GIT course
                    balearicdynamics

                    Thank you Dave,

                     

                    this is a very precious link, 543 pages! And there is also the epub version I can convert easily with Calibre to mobi for Kindle. LoL

                    • Re: GIT course
                      michaelkellett

                      Great link, thanks - but:

                       

                      I downloaded the two free books on VHDL and Verilog, these were free so I'm not complaining but should issue a warning.

                       

                      They  re fine if you can't afford anything better but are really the same, very old fashioned, book written with a very hardware logic orientated view and formatted up for two different HDLs.

                       

                      I only did a quick scan but, for example, the Verilog book, although published in 2019 makes no proper mention of the different versions of Verilog or of the existence of System Verilog.

                      The book does not, as far as I could see, even state which version iot was written to support.

                       

                      The VHDL book seems to share the same rather generic first section and uses the same examples throughout - this isn't necessarily a bad thing - it makes it easy to compare the two HDLs.

                      (except it doesn't use recent features of either).

                       

                      The examples are simplistic, the discussion of state machines sticks rigidly to the 3 process model (I haven't written a 3 process FSM in the last 19 years !!) and doesn not even mention the existence of anything else.

                       

                      These books will get you started but only on very simple stuff.

                       

                      Like the man said, "There's no such thing as a free lunch".

                       

                      These books could count as a free biscuit !

                       

                      But thanks again for the link - I've download some about some stuff I know nothing about - which I would never have been able to affords to buy.

                       

                      MK

                       

                       

                       

                      .

                      3 of 3 people found this helpful
                        • Re: GIT course
                          beacon_dave

                          Thanks for the review and heads-up.

                           

                          Could you clarify which books you were looking at, as I found four titles:

                          • Quick start Guide to Verilog
                          • Quick start Guide to VHDL
                          • Introduction to Logic Circuits and Logic Design with Verilog
                          • Introduction to Logic Circuits and Logic Design with VHDL

                          by the same author and I suspect there will be a lot of duplicated content between them. Not sure if you were referring to all four or just two. (Actually I found six titles but two were the earlier 2017 editions of the same title.)

                           

                          From what I've seen it is common for authors to re-write the same content but present one book in Verilog and one in VHDL. Not very helpful if you are starting out and you are unsure of whether to take the Verilog or VHDL routes. Some authors will do it within the same book with the same examples in both Verilog and VHDL which can be helpful to illustrate the differences but the book then tends to be twice the price.

                           

                          I'm not surprised of the hardware logic oriented view as I suspect that a lot of readers trying to get started with FPGA design are coming from a hardware logic oriented education. (Have they started to include programmable logic devices as part of the digital electronics syllabus yet ?). However I have found this as being a bit of an issue now as the FPGA design tools appear to have started to drop the logic schematic based design tools in favour of coding straight in HDL.

                           

                          I notice however that you don't suggest any alternative texts which would be a better option for starting out on.

                           

                          The best I've found so far as an entry level text is:

                          Digital System Design with FPGA: Implementation Using Verilog and VHDL

                          https://www.mheducation.com/highered/product/digital-system-design-fpga-implementation-using-verilog-vhdl-unsalan-tar/97…

                          but it is not a cheap option, and it expects you to have access to a copy of:

                          Programmable Microcontrollers: Applications on the MSP432 LaunchPad

                          https://www.mheducation.com/highered/product/1259836193.html?exactIsbn=true

                          (which is equally not cheap) in order to accelerate some of the microcontroller based project designs covered there using the new-found FPGA skills.

                           

                          The book also expects you to have access to not one but two different FPGA trainer boards, so quickly gets expensive to follow along, or you have to adjust the examples to work with what boards you have (not necessarily bad as it helps reinforce the learning.)

                           

                          I've also found:

                          The Design Warrior's Guide to FPGAs

                          https://www.elsevier.com/books/the-design-warriors-guide-to-fpgas/maxfield/978-0-7506-7604-5

                          useful for some of the history of design leading up to FPGA but this is an old text and stops at around 2004.

                           

                          As above, books are often tied to specific trainer boards (which can often be expensive). Some revised editions of books are still referring to trainer boards that are now no longer even available to purchase. The author appears to have just updated the text to account for recent software updates and re-published.

                          4 of 4 people found this helpful
                            • Re: GIT course
                              michaelkellett

                              It was just the quick start guides I was referring too.

                               

                              To be fair I've never found a truly good book on either VHDL or Verilog but my I do recommend:

                              VHDL-2008 Just the New Stuff, Peter J Ashenden

                              His earlier book "The designer's Guide to VHDL" is quite good too.

                               

                              I learnt a lot of my VHDL stuff from good old internet news groups a long time ago when seriously good people, including from Xinlinx posted there.

                              And I started with a paid for week long course which was pretty good but far from cheap.

                               

                              I've never found a book I'd recommend on Verilog, which may be related to my dislike for it, but I don't know which is cause and which effect.

                               

                              I've only had a very quick look at the "Introduction to Logic Circuits...." pair but they seem to duplicate a lot of the material from the other two books

                               

                              I followed your link to: Digital System Design with FPGA: Implementation Using Verilog and VHDL, but they seem to want money and it's out of stock.

                               

                              MK

                              3 of 3 people found this helpful
                      • Re: GIT course
                        Jan Cumps

                        I'm git sponsor in my company. Want a training ?

                        1 of 1 people found this helpful
                        • Re: GIT course
                          jomoenginer

                          Are you referring to the git command line options or to GitHub?

                           

                          There are many ways to implement a git repo both locally as well as online or in a CI/CD environment.

                           

                          What specifically are you looking for?

                            • Re: GIT course
                              fmilburn

                              Just speaking for myself... I have learned how to do only the most basic things and have never worked collaboratively with someone else as an example.  I have only worked with GitHub and it would be nice to work locally initially. My version control is atrocious before putting something on GitHub. I’ll have a look through the book that Dave linked.

                              2 of 2 people found this helpful
                              • Re: GIT course
                                dougw

                                I first started using GIT because some article or other would refer to the code being available in a GIT repository.

                                I just remember it being strange and confusing when I was trying to use it. A lot of articles on element14 refer to GIT so I thought members might benefit from some tips on what it is and how to use it ….

                                1 of 1 people found this helpful
                                  • Re: GIT course
                                    Jan Cumps

                                    What type of use are you interested in?

                                     

                                    Using other people's repo / getting their latest versions?

                                    Contributing to other peoples repo?

                                    Have a repo to have your code versioned and shared with other people?

                                    Have a repo where other people can contribute to your code?

                                    1 of 1 people found this helpful
                                      • Re: GIT course
                                        dougw

                                        Mostly my uses are:

                                        Using other people's repo / getting their latest versions

                                        Have a repo to have my code versioned and shared with others - such as supporting element14 blogs

                                        The original suggestion of a guide was not primarily for me, but for any members not familiar wit GIT.

                                  • Re: GIT course
                                    balearicdynamics

                                    There are two points that I saw many developers always ignore or not consider in Gip version control.

                                     

                                    1. Repository push should NOT happen only when your program works but when you make a meaningful step

                                    2. How to manage different branches.

                                     

                                    And, IMHO, these are the two most important possibilities from Git to keep a serious development history of your job.

                                      • Re: GIT course
                                        jomoenginer

                                        Well, I think what you are describing are two separate things. Git is just a tool used to move code to a repo and such.

                                         

                                        Branch strategy is an entirely separate topic.  Branching depends on the development environment and the branch strategy.  Most Agile Development encourages pushing changes often to ensure the code is not lost.  However, the idea is to create a development branch and to create feature branches for particular issues where a developer works from and can push changes to.   Once the code is ready to be pushed to the development branch, a code review would be created and the code goes under scrutiny.  In some instances code analysis would take place as the code is pushed to ensure there are no syntax issues or spacing issues as in Python. Once the code has gone through a code review, then a pull request would be mode to merge the code into the development branch.   This continues until there is a release set and all fhe changes are properly merged into the development branch where the code is merged into the master branch.  In some cases a release branch would be made and only select changes are checked into the master branch.  This is just one scenario and could take many forms.

                                         

                                        There are many tools to keep repos in such as GiHub, GitLab, Bitbucket and the old ClearCase.

                                         

                                        This is a deep topic, and could git nasty.

                                        3 of 3 people found this helpful
                                          • Re: GIT course
                                            Jan Cumps

                                            We do almost as you explain, except the review.

                                            That doesn't happen before the pull request, but as part of the pull request approval.

                                            If the review passes, the reviewer approves the pull request.

                                            If not, they use the code comment functionality in devops and reject.

                                             

                                            The developer can then fix code in the existing feature branch. Those commits get automatically added to the pull request when pushed.

                                            The approval count is reset and the review can proceed...

                                            1 of 1 people found this helpful
                                              • Re: GIT course
                                                jomoenginer

                                                I've been in environments where Crucible was used for code review before the pull request to keep the pull request clean.

                                                 

                                                Also, at Intel, the code went through an analyzer and linter when pushed to a branch and would get rejected if there was a failure and everyone assigned to the project got an email of said incident.

                                                 

                                                But, then again, there are folks that still use SVN over Git.

                                                2 of 2 people found this helpful
                                                  • Re: GIT course
                                                    Jan Cumps

                                                    inspired by the discussion, I'm turning the firmware repo for my dc load into a managed project, with branch policies.

                                                    I've been the only committer for this project and for these situations I just create a master branch with commit rights (all my github repos are currently set up like this).

                                                    But I can create a project with board for issue and pull request management, and fiddle out how branch policies work in git.

                                                    Then switch my local repo over to a development branch ...

                                                     

                                                    Here's the locaton: https://github.com/jancumps/msp432/projects/1

                                                    1 of 1 people found this helpful
                                                • Re: GIT course
                                                  balearicdynamics

                                                  Jon,

                                                  Branch strategy is an entirely separate topic.  Branching depends on the development environment and the branch strategy.

                                                  I am sorry but this is totally wrong. Not just IMHO, it is wrong as you read the basis of the Git features and behavior. What is TOTALLY another topic is Agile as well as the tons of other team development methodology. All of them – it is the current trend – tend to abandon SVN and other source control methods moving to Git.

                                                   

                                                  A COLLATERAL but not totally different topic instead is the Git platforms you mention: GitHub (I use for open source) GitLab (I own my license on my AWS server as well as another GitLab for company Git development) and many other; for example, Qt development has its own report. Those you mention are just the most popular, GitHub on top of them.

                                                  developers should not push remotely their local Git database it is just an option when they work on teams, need to share with company or colleagues their development, and so on. As I told these are just tools and options where you can store Git on the cloud. I have tons of my Android development repositories I stored privately on my own AWS server as my local and remote collaborators were accessing the same, using online git commands and SSH for remote connection.

                                                   

                                                  Enrico

                                                   

                                                    • Re: GIT course
                                                      Jan Cumps

                                                      Yayay, GIT wars .

                                                       

                                                      Jon is right that branch strategy is important when working with production vs project code, with several parties working on both.

                                                      If one starts such an exercise without a strategy, it just gets out of hand.

                                                      You will have version control, but a complex release process with the risk of having to resolve merge conflicts (or overwrite fixes done in the production code -> regression) at the very end when you go live.

                                                       

                                                      Doing this pure in GIT, without support of one of the platforms to manage the pull request cycles, is a rough ride.

                                                      It's hard enough with the support of those platforms.

                                                       

                                                      I have experience with branch policies and pull request approaches in Azure DevOps and GitHub. Learning GitLab ...

                                                      • Re: GIT course
                                                        jomoenginer

                                                        balearicdynamics  wrote:

                                                         

                                                        Jon,

                                                        Branch strategy is an entirely separate topic.  Branching depends on the development environment and the branch strategy.

                                                        I am sorry but this is totally wrong. Not just IMHO, it is wrong as you read the basis of the Git features and behavior. What is TOTALLY another topic is Agile as well as the tons of other team development methodology. All of them – it is the current trend – tend to abandon SVN and other source control methods moving to Git.


                                                         

                                                        Yeah, of course I am wrong on this forum.  It's not like I have to deal with this on a daily basis in my day job.  But. hey, thanks again for reaffirming for why I limit my posts here and seriously why I don't like coming to this site anymore. 

                                                         

                                                        Cheers.

                                                          • Re: GIT course
                                                            balearicdynamics

                                                            You expressed an opinion if I am not wrong. Me too. Both are valid, maybe criticizable.

                                                             

                                                            That's all.

                                                            • Re: GIT course
                                                              colporteur

                                                              I'm wrong all the time. Ask my spouse. Why so sensitive?

                                                               

                                                              By your own admission you have minimal experience in Git. I suspect I have less than you. Chances are you might be wrong. The responder interpreted the documentation to suggest your perspective is not correct. It wasn't as though the comments were derogatory or disrespectful. I would expect with a level 8 ranking on the site you have seen worse.

                                                               

                                                              If you are suggesting there are comment vultures sitting waiting for the chance to feed on a wrong response, I say there are few. Those that exist, I suggest are pretty thin because they are not feeding that well. My experience doesn't give me indication they are in abundance on the site.

                                                               

                                                              Looking at your background profile and experience I think you might have some insight that would be of benefit to the community. It is unfortunate we don't have rules of conduct that are more to your liking but that is not surprising. With of 200K members someone is bound to get pissed at something. Confirmation bias will enable you to find details to support your wish to not participate.

                                                               

                                                              I have been asked to change comments on posts. After asking for clarification from the moderator, I have refused. I accept the moderator has the right to remove what someone interprets as inappropriate. That doesn't mean I have to agree.

                                                              2 of 2 people found this helpful
                                                        • Re: GIT course
                                                          Jan Cumps

                                                          We use a single repository for a project.

                                                          No one can commit/push to the master or development branch.

                                                           

                                                          Developers clone from master or project, depending if it is prod support work or project development.

                                                          then create a future branch and commit and push to that very often.

                                                           

                                                          When developers are ready with the work, they create a pull request (we use azure devops for that).

                                                          Code is reviewed by someone from QA team, then approved for merge by master or project branch owner.

                                                          Both these activities are done in azure devops' pull request flow. Managed by notifications.

                                                           

                                                          A developer can also be a reviewer or branch owner, but can't review or approve their own pull requests.

                                                           

                                                          When the pull request is approved, the feature branch is deleted, because its complete and no longer needed.

                                                          Commits and pull requests stay in the system forever.

                                                           

                                                          As a daily activity, I synchronise all approved master pull requests with the development branch and inform the developers of the changed sources.

                                                          2 of 2 people found this helpful
                                                            • Re: GIT course
                                                              balearicdynamics

                                                              The only difference is that I have the habit to never delete branches, also the dead ones. But as you say, this is an approach – very good in my opinion – that is based on a strategy. We adopt almost the same but it is the approach topic. Then branching, pull, joining, requests for merging, forking, and all the other possibilities and features, as the expression of the full potential of Git. I suppose you agree with this.

                                                               

                                                              Years ago, were times when Nokia still was a top company, Symbian and Maemo was the top for mobile OS, Wt was version 3 or 2.xxx and in the group of Nokia developers, I was participating to some stuff in the dev team of what it was expected to be a very advanced, powerful and revolutionary SBC. In the meantime, as a Qt-ambassador, I participated mostly as a tester as a member of the opensource group (many people from Trolltech, some very respectable super-skilled guys from the Qt community, and other very experts Qt developers) in the creation of the porting of Qt under Android. It was the period between 2010 and 2013 and in both the cases I faced with this kind of Git approach; IMHO was the only possible way to keep under control big developer teams working on many different groups of features part of the same project like an operating system is. It was in those years I learned Git used in this extensive way and as much as I learned, as much I appreciated it.

                                                               

                                                              BTW, that powerful and revolutionary SBC become a worldwide success

                                                               

                                                          • Re: GIT course
                                                            Fred27

                                                            I was going to post to say that using Git as a source control tools and using branching for managing work in a team are very different things, but I can see that everyone's already jumped in on this one. No surprise, that people have different firmly held beliefs too. Best we stay away from subtleties like whether to squash merge commits!

                                                             

                                                            A lot of it does depend on how you team works, so I don't think there is a definitive right or wrong with branching strategy. No direct commits to master is probably a fairly consistent approach, although as I have found myself on a one-man team at the moment I find I sometimes bend (OK - blatantly break) this rule.

                                                             

                                                            One thing I'm really appreciating in my current job is that I got a chance to set Continuous Delivery up right from the start. If code in master passes unit tests, it's automatically deployed to AWS.

                                                            1 of 1 people found this helpful
                                                            • Re: GIT course
                                                              jpnbino
                                                              It might be useful to present an introduction and basic user guide to GIT repository …..

                                                              A good introduction I would suggest:

                                                              1. What the Problem I have I would need an SCM
                                                              2. Why git? ( here comes the:  why it is a distributed and easy and work this way... )
                                                              3. How then, do I use git
                                                                1. Here come the basic commands in an interactive way. Here was where I started.
                                                                2. Now that one knows how to deal with doing things within git, it is time to see how workflows happen: There are many, one needs to be reasonable and pick the one that most suits the application or workflows of the existing job.

                                                               

                                                              • Re: GIT course
                                                                colporteur

                                                                I like to see use cases for Git. I have employed it and still left with the question of why.

                                                                 

                                                                As this post responses have demonstrated, there are a variety of applications of Git as there are individuals that have posted.

                                                                 

                                                                I would like to see knowledge on Git depending on the use case. Single user, small team and large team. Does all the options apply across the different groups? What about the type of project you are working on.

                                                                 

                                                                It will be suggested just use what you need. I like to know what I need or what I can gain by taking advantage of options available. I suspect a large development team on a complex projects enables them to experience all the benefits of the application.

                                                                 

                                                                I'm still searching for reasons my small python projects warrant a Git repository?

                                                                • Re: GIT course
                                                                  Jan Cumps

                                                                  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.

                                                                  3 of 3 people found this helpful
                                                                    • Re: GIT course
                                                                      balearicdynamics

                                                                      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

                                                                        • Re: GIT course
                                                                          Jan Cumps

                                                                          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  ...

                                                                          1 of 1 people found this helpful
                                                                          • Re: GIT course
                                                                            Jan Cumps

                                                                            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.

                                                                            1 of 1 people found this helpful
                                                                              • Re: GIT course
                                                                                balearicdynamics

                                                                                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

                                                                                  • Re: GIT course
                                                                                    Jan Cumps

                                                                                    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.

                                                                                    1 of 1 people found this helpful
                                                                                      • Re: GIT course
                                                                                        Jan Cumps
                                                                                        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

                                                                                        3 of 3 people found this helpful
                                                                              • Re: GIT course
                                                                                Jan Cumps

                                                                                I've added a process for creating a release with GIT and GitHub.

                                                                                With project management integrated and automated.

                                                                                 

                                                                                Firmware Release with GitHub: Branch, Issue, Pull Request and Project support

                                                                                 

                                                                                 

                                                                                 

                                                                                =============================================================================

                                                                                 

                                                                                 

                                                                                =============================================================================

                                                                                 

                                                                                 

                                                                                1 of 1 people found this helpful